I’m using the st.number_input in my streamlit app. I noticed that it renders as a st.text_input widget whenever I open the app in my Phone or Tablet vs when I do it on my computer browser.
I’m hosting the app on an AWS EC2 instance (running Amazon-Linux); I’ve seen this behavior in other apps done by other people as well. Is this a bug?
As an extra: Whenever I click the “increase” button in the st.number_input-widget as fast as I can, the app crashes and the streamlit port is “killed” in the process. What could be the cause of this? When I run the app locally this doesn’t happen vs running it on the cloud (AWS) where this app-crash occurs whenever the widget is clicked fast.
It would be helpful if you could share a minimum reproducible example showing st.number_input being rendered as st.text_input. Do you mean the +/- feature to the right is not appearing for the widget?
A possible reason for the app to crash when the increase button is pressed really fast would be that with each click, the app is being re-run. Consequently, multiple clicks would trigger multiple re-runs and if the max computational resource has been reached then the app may crash. A possible solution is to embed the st.number_input widget inside an st.form so that adjustments would not trigger the app to re-run with each interaction.
Hi @dataprofessor ,
As examples the following two apps may serve. I can’t show my code, unfortunately, but it’s basically the same issue, the st.number_input widget rendering differently in both mobile vs pc.
Just as a side note, again, regarding the app crashing. Maybe it can occur due that I access the app via http only, instead of https? If you have some references of where I could find possible solutions to this sort of issue I’d appreciate it. I’m just starting out on the server-management side of things.
I’m having the same issue, but the cause seems to be different.
I have an app that I’m hosting on AWS and I am also seeing the st.number_input render as st.text_input. The app has multiple pages and I noticed that the number input was working fine when I had the code that calls st.number_input in the main code for the page. Then I moved the st.number_input into a separate file and put it into a method in another class. The code is the same, it now just calls that class/method, which should render the number input, but the display looks like text_input.
I tried replacing st.number_input with st.text_input and it threw an error (as expected since I left the inputs the same), and then I changed it back but continue to get the original issue.
To be clear, the input box looks exactly like text_input, the data is aligned left and there are no +/- buttons on the right.
There seem to be two separate things happening here, although I’m still not sure why.
In my app, I absolutely was seeing the number input correctly rendered when the code was in the page’s main code and then incorrectly rendered when the code was moved to another page as a method in a class.
However, when trying to recreate this example more simply, I was getting the number input to render incorrectly in the main page’s code. Here, the number input box renders incorrectly when st.number_input is within a column->container->column. It does not render incorrectly when st.number_input is just within column->container.
import streamlit as st
def main():
table_display_cols = st.columns([1, 3, 1])
with table_display_cols[1]:
with st.container(border=True):
user_number_1 = st.number_input('This is a number input')
row_cols = st.columns(3)
with row_cols[0]:
user_number_2 = st.number_input('This is also a number input')
if __name__ == '__main__':
main()
Interesting, I see it correctly in wide mode too. So maybe this goes back to the OP’s point that the browser can affect the way it’s displayed
Still, that doesn’t really explain why it works for me sometimes and not other times depending on the code itself. I feel like there are a few different underlying issues here at this point
In this case it’s not the browser but the available horizontal space, which of course depends on the code.
As a matter of fact, if a number_input shrinks beyond a certain minimum, the buttons dissapear, which I don’t think is incorrect but an intentional way of allowing narrow widgets to display. Now, if you have an example where two widgets render differently while having the same with, that couldn’t be explained that way.
Of the two apps linked above, the first one didn’t work and with the second one I was unable to reproduce the issue.
Thanks for stopping by! We use cookies to help us understand how you interact with our website.
By clicking “Accept all”, you consent to our use of cookies. For more information, please see our privacy policy.
Cookie settings
Strictly necessary cookies
These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.
Performance cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.
Functional cookies
These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.
Targeting cookies
These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.