Two issues regarding the st.number_input widget (rendering in Mobile vs PC)

Two issues regarding the st.number_input widget.

  1. 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?

  2. 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.

Hi @A.A.Garcia

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.

Hope this helps!

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.

Any update here?

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.

Update on my side:

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.

I have the app set up on

With the source code here:

And repasted here:

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__':

It seems to be a matter of horizontal space. Your app renders as expected in wide mode for me (1920 pixels wide, no scaling).

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.

It does seem like the only way I can get the “issue” now is when the number_input isn’t wide enough, so I’m not sure what was happening before

Thanks for the help