-
Notifications
You must be signed in to change notification settings - Fork 948
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
document Chrome bug: continuous_update on IntText requires mouseout before updating #1753
Comments
With When @jasongrout implemented
That makes sense for inputs which are purely text, but maybe it makes less sense for inputs which also allow mouse interaction, like For anyone interested in trying this out: import ipywidgets as widgets
important_widget = widgets.IntText(continuous_update=False)
other_widget = widgets.Text()
def on_change(change):
other_widget.value = str(important_widget.value)
important_widget.observe(on_change, names=['value'])
widgets.VBox([important_widget, other_widget]) |
This is an interesting wrinkle, thanks for pointing it out. Do we think that people will mostly be clicking the buttons rather than typing? What browsers do this? |
Firefox and Safari seem to do the 'right thing' -- responding to mouse clicks by sending change events at least when the user depresses the mouse. Chrome (61) is the offender here -- it only sends the change event when the user's mouse moves away from the input, or on blur. All three browsers do what we expect for keyboard events (i.e. send the change event in response to the user pressing |
Yes I was using Chrome, thanks for the in-depth explanation. I am hooking up some bqplot charts to widgets, just running dummy functions at the moment so I might switch back to false when I have more expensive functions in place. |
@pbugnion - do you know if there is a bug report for Chrome? |
A brief look hasn't revealed anything. I'll spend more time checking this tomorrow, and, if not, I can try submitting one. Here's a minimal HTML snippet that demonstrates the behaviour. <html>
<head>
<script>
window.onload = () => {
var element = document.getElementById('example-input');
element.onchange = () => console.log('change');
element.oninput = () => console.log('input');
}
</script>
</head>
<body>
<input id="example-input" type="number" />
</body>
</html> |
Possibly relevant: https://bugs.jquery.com/ticket/8169 |
I found this bug report for Chromium. The developers seem to agree that the current behaviour is a bug that was introduced in Chrome 58. The design would be to dispatch change on I would personally be in favour of just waiting it out until the Chrome bug is fixed. Maybe we could add a note in the documentation? |
I updated the title to note that we should document this bug of Chrome |
I was having difficulty figuring out why widgets were slow to interact with a changing IntText when modified by the up and down arrows. With continuous_update set to False (default), the IntText actually requires a mouseout (i.e. move the cursor off the widget button) before the observed function occurs.
Is this intended behaviour? I would have expected the function to fire once I had stopped depressing the mouse key if I wanted to change the IntText by a large amount at once e.g. increase from 10 to 30, and see the reaction as soon as I stop holding the mouse key when the text hits 30.
The text was updated successfully, but these errors were encountered: