Skip to content
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

Open
andymcarter opened this issue Oct 12, 2017 · 9 comments

Comments

@andymcarter
Copy link

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.

@pbugnion
Copy link
Member

pbugnion commented Oct 12, 2017

With continuous_update set to False, the view only sends update to the model when the browser sends the change event. With continuous_update set to True, the view sends updates to the model in response to both change and input events. The difference between these is described thoroughly here.

When @jasongrout implemented continuous_update, he rationalized defaulting to False for text boxes as (PR #1545):

I default continuous_update to False for the textboxes because I figured if people were typing, that's typically what is wanted.

That makes sense for inputs which are purely text, but maybe it makes less sense for inputs which also allow mouse interaction, like {Float,Int}Text. If Jason approves, we could change the defaults to continuous_update is True.


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])

@jasongrout
Copy link
Member

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?

@pbugnion
Copy link
Member

pbugnion commented Oct 12, 2017

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 <enter> or <up-arrow>, <down-arrow>).

@andymcarter
Copy link
Author

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.

@jasongrout
Copy link
Member

@pbugnion - do you know if there is a bug report for Chrome?

@pbugnion
Copy link
Member

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>

@jasongrout
Copy link
Member

Possibly relevant: https://bugs.jquery.com/ticket/8169

@pbugnion
Copy link
Member

pbugnion commented Oct 13, 2017

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 <mouse-up>, which seems similar to what Firefox does.

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?

@jasongrout jasongrout added this to the 7.1 milestone Oct 13, 2017
@jasongrout jasongrout changed the title continuous_update on IntText requires mouseout before updating document Chrome bug: continuous_update on IntText requires mouseout before updating Oct 13, 2017
@jasongrout
Copy link
Member

I updated the title to note that we should document this bug of Chrome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants