Repository: streamlit/streamlit

Issue:
Sliders should show current value [regression] [Baseweb]
# Summary

(via @tvst: )

Our sliders right now require you to hover in order to see the selected value. This makes it really hard to understand what the user selected.   I reported this before, but I just spent some time debugging my app thinking it was broken because I was reading the wrong  slider value.   Frustrating.

I understand this is the new behavior of sliders in Base Web, but we have alternatives:

**1. Roll back Base Web to a previous version**

    This is the preferable solution in order to get this fix out ASAP. Even if we decide it's only a temporary solution.

2. Try to find a solution using the latest Base Web

3. Copy/paste the old Baseweb slider into our own repo and modify it there. Their slider is based on another library, btw (I forget which), so maybe we should just use that library directly instead?


## Is this a regression?

yes 

# Debug info

- Streamlit version: 0.75-special
Allow hiding tracebacks
Currently, when a Streamlit app throws an exception, we print the traceback to the browser. This isn't necessarily the right thing to do for all apps; we should allow this to be configurable.

Maybe a `[client] showTracebacks = false` option? And presumably, if tracebacks are disabled, we should filter them at the server level, so that the client never even receives the string, in case the user is worried about leaking internal app details.

(Related discussion here: https://discuss.streamlit.io/t/dont-show-users-tracebacks/1746)


Discussion:
Here's an approach from @bh-streamlit: https://codesandbox.io/s/base-web-overrides-usage-forked-id7p3?file=/src/example.js:1013-1053 that would probably work best. 

Essentially the concept is to pass the value as the child of the thumb so we would create our own value instead of relying on baseweb's display value. Quite brilliant!

We would just need to get the styling in and make sure it doesn't conflict with baseweb's logic. From an initial look, I think its fine. 
I've exposed stack traces to users on a publicly available app, and felt pretty bad about it (because it looks so unprofessional). In my case, I think it was a NameError because I deleted a variable that I subsequently tried to use. I don't know exactly what my desired behavior would have been, but a message like "Oops. Something went wrong here" would have been better than a stack trace. Though I was glad that everything before the stack trace still showed on the page. So, if my error was at the bottom of the program, the user can still see something useful.

Anyway, here are my thoughts on this:

1. It'd be nice if I could see the tracebook while developing, but have it hidden from users.
2. Personally, I'm more concerned about the tracebook being ugly/confusing than I am about any security risks associated with exposing app internals. It wouldn't bother me at all if it showed up in the console.
3. I'd love to be able to set up a system where I'm notified of exceptions in prod, even if they aren't shown to users. I bet we showed stack traces to dozens of users before I found out about it. It'd be nice to improve that.

If we were doing better engineering, we'd handle this with conventional exception handling. But, we use streamlit primarily to make development faster/easier. So, it'd be a win to spend less time working through exception handling.

I'll never want to show stack traces to users, so I'd take advantage of an option to get that without writing a lot of our own exception handling.
@tconkling Any update on this? 
Right now, when my app loses connection to the remote API, I get a connection error which displays the full API URL. Is there a way to hide it? 

The error I am getting looks like this one here
https://discuss.streamlit.io/t/connectionerror-with-flask-server/5525/2


cc: @astrojams1 to bring to his attention
I agree we should be prioritizing this sometime soon and is particularly problematic for public-facing apps given it could expose secrets.

In the meantime, I believe the best workaround is to catch exceptions before they bubble up beyond the script’s context.

Resolving patch:
diff --git a/e2e/scripts/st_columns.py b/e2e/scripts/st_columns.py
--- a/e2e/scripts/st_columns.py
+++ b/e2e/scripts/st_columns.py
@@ -27,5 +27,5 @@
 
 
 # Variable-width columns
-for c in st.beta_columns((1, 2, 4, 8)):
+for c in st.beta_columns((1, 2, 3, 4)):
     c.image(CAT_IMAGE, use_column_width=True)


Test patch: