Intent to Ship: Dispatch mouse transition events after layout
104 views
Skip to first unread message
Dave Tapuska
Aug 9, 2017, 10:25:19 AM8/9/17
to blink-dev
dtap...@chromium.org,lan...@chromium.org
None
Highlight of current issues and proposals
Mouse events (mouseenter/leave/out/over) are not sent when the node under the mouse changes during layout.
This then represents an incorrect state in that the hover state of where the mouse actually doesn't match the current hover state of the document.
To fix a variety of issues we will start dispatching mouse transitional events and update the hover state shortly after layout has been executed.
This will match Firefox behavior.
The current implementation causes an illogical representation of the world. After a layout the mouse may be over a different node but it still maintains the hover status of when the mouse last move. The next immediate mouse move will cause the hover state to be updated.
We are proposing to update this state shortly after a layout. It will use the same machinery that is used to update the hover position after a scrolling event.
Firefox: Shipped
Edge: No public signals
Safari: No public signals
Web developers: No signals
Minor compatibility risk. Currently Firefox generates these events after layout and in Chrome the events would have been generated after the first mouse move after the layout. So all we really are is changing the timing of the events.
Dimitri Glazkov
Aug 9, 2017, 11:52:13 AM8/9/17
to Dave Tapuska, blink-dev
LGTM1. Have y'all thought about how you would determine breakages? Perhaps identify a class of bugs that would be reported and watch for them?
:DG<
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wnvY6j7HKpz4HXR8CayfbCF-_r9ZJFcS95rkjvvz4mNrA%40mail.gmail.com.
Dave Tapuska
Aug 9, 2017, 11:59:20 AM8/9/17
to Dimitri Glazkov, blink-dev
I find that input bugs tend to get routed quite correctly and per revision bisects are awesome. We will certainly watch for breakage reports but we have had this on as an experimental feature for about a month now and we haven't received any reports yet.
I debated whether this feature required an intent to ship or not as it really is plumbing underneath. But I'm erring on the side of caution to communicate this change with a wider community as a we've had a number of people looking for these fixes.
dave.
On Wed, Aug 9, 2017 at 11:51 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:
LGTM1. Have y'all thought about how you would determine breakages? Perhaps identify a class of bugs that would be reported and watch for them?:DG<
On Wed, Aug 9, 2017 at 7:25 AM Dave Tapuska <dtap...@chromium.org> wrote:
Highlight of current issues and proposals Mouse events (mouseenter/leave/out/over) are not sent when the node under the mouse changes during layout. This then represents an incorrect state in that the hover state of where the mouse actually doesn't match the current hover state of the document. To fix a variety of issues we will start dispatching mouse transitional events and update the hover state shortly after layout has been executed. This will match Firefox behavior. The current implementation causes an illogical representation of the world. After a layout the mouse may be over a different node but it still maintains the hover status of when the mouse last move. The next immediate mouse move will cause the hover state to be updated.We are proposing to update this state shortly after a layout. It will use the same machinery that is used to update the hover position after a scrolling event.Firefox: Shipped Edge: No public signals Safari: No public signals Web developers: No signals Minor compatibility risk. Currently Firefox generates these events after layout and in Chrome the events would have been generated after the first mouse move after the layout. So all we really are is changing the timing of the events.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wnvY6j7HKpz4HXR8CayfbCF-_r9ZJFcS95rkjvvz4mNrA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx45jXeha5psBOBZK9hCWHTmY7JLgomp9G9dqEaPvL%2BdxA%40mail.gmail.com.
Dimitri Glazkov
Aug 9, 2017, 2:07:01 PM8/9/17
to Dave Tapuska, blink-dev
SGTM.
On Wed, Aug 9, 2017 at 8:59 AM Dave Tapuska <dtap...@chromium.org> wrote:
I find that input bugs tend to get routed quite correctly and per revision bisects are awesome. We will certainly watch for breakage reports but we have had this on as an experimental feature for about a month now and we haven't received any reports yet.I debated whether this feature required an intent to ship or not as it really is plumbing underneath. But I'm erring on the side of caution to communicate this change with a wider community as a we've had a number of people looking for these fixes.dave.On Wed, Aug 9, 2017 at 11:51 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:
LGTM1. Have y'all thought about how you would determine breakages? Perhaps identify a class of bugs that would be reported and watch for them?:DG<
On Wed, Aug 9, 2017 at 7:25 AM Dave Tapuska <dtap...@chromium.org> wrote:
Highlight of current issues and proposals Mouse events (mouseenter/leave/out/over) are not sent when the node under the mouse changes during layout. This then represents an incorrect state in that the hover state of where the mouse actually doesn't match the current hover state of the document. To fix a variety of issues we will start dispatching mouse transitional events and update the hover state shortly after layout has been executed. This will match Firefox behavior. The current implementation causes an illogical representation of the world. After a layout the mouse may be over a different node but it still maintains the hover status of when the mouse last move. The next immediate mouse move will cause the hover state to be updated.We are proposing to update this state shortly after a layout. It will use the same machinery that is used to update the hover position after a scrolling event.Firefox: Shipped Edge: No public signals Safari: No public signals Web developers: No signals Minor compatibility risk. Currently Firefox generates these events after layout and in Chrome the events would have been generated after the first mouse move after the layout. So all we really are is changing the timing of the events.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wnvY6j7HKpz4HXR8CayfbCF-_r9ZJFcS95rkjvvz4mNrA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Chris Harrelson
Aug 10, 2017, 5:06:52 PM8/10/17
to Dimitri Glazkov, Dave Tapuska, blink-dev
Hi Dave,
Could you comment on (a) web platform interop testing for this behavior, and (b) updating the HTML spec to match?
Chris
On Wed, Aug 9, 2017 at 11:06 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:
SGTM.
On Wed, Aug 9, 2017 at 8:59 AM Dave Tapuska <dtap...@chromium.org> wrote:
I find that input bugs tend to get routed quite correctly and per revision bisects are awesome. We will certainly watch for breakage reports but we have had this on as an experimental feature for about a month now and we haven't received any reports yet.I debated whether this feature required an intent to ship or not as it really is plumbing underneath. But I'm erring on the side of caution to communicate this change with a wider community as a we've had a number of people looking for these fixes.dave.On Wed, Aug 9, 2017 at 11:51 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:
LGTM1. Have y'all thought about how you would determine breakages? Perhaps identify a class of bugs that would be reported and watch for them?:DG<
On Wed, Aug 9, 2017 at 7:25 AM Dave Tapuska <dtap...@chromium.org> wrote:
Highlight of current issues and proposals Mouse events (mouseenter/leave/out/over) are not sent when the node under the mouse changes during layout. This then represents an incorrect state in that the hover state of where the mouse actually doesn't match the current hover state of the document. To fix a variety of issues we will start dispatching mouse transitional events and update the hover state shortly after layout has been executed. This will match Firefox behavior. The current implementation causes an illogical representation of the world. After a layout the mouse may be over a different node but it still maintains the hover status of when the mouse last move. The next immediate mouse move will cause the hover state to be updated.We are proposing to update this state shortly after a layout. It will use the same machinery that is used to update the hover position after a scrolling event.Firefox: Shipped Edge: No public signals Safari: No public signals Web developers: No signals Minor compatibility risk. Currently Firefox generates these events after layout and in Chrome the events would have been generated after the first mouse move after the layout. So all we really are is changing the timing of the events.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wnvY6j7HKpz4HXR8CayfbCF-_r9ZJFcS95rkjvvz4mNrA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx45jXeha5psBOBZK9hCWHTmY7JLgomp9G9dqEaPvL%2BdxA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx4mkyqa7h5s-wH%3DLEX1eOgaF0-cgfc4311Rq5H0fpnjBg%40mail.gmail.com.
Dave Tapuska
Aug 10, 2017, 5:18:25 PM8/10/17
to Chris Harrelson, Dimitri Glazkov, blink-dev
a) There are some layout tests that I can move over to web platform tests
b) The lifecycle of events is largely unspecified in any spec though.
Would it make sense to add it to the event loop explainer? The problem with doing it part of the eventloop explainer is that we do it after a timeout (20ms). For example this code exists in shipping Chrome but only executes if the hovered node was removed. Now we are essentially doing it all the time.
Chris Harrelson
Aug 10, 2017, 5:25:32 PM8/10/17
to Dave Tapuska, Dimitri Glazkov, blink-dev
On Thu, Aug 10, 2017 at 2:18 PM, Dave Tapuska <dtap...@chromium.org> wrote:
a) There are some layout tests that I can move over to web platform tests
That would be great, thanks.
b) The lifecycle of events is largely unspecified in any spec though.Would it make sense to add it to the event loop explainer? The problem with doing it part of the eventloop explainer is that we do it after a timeout (20ms). For example this code exists in shipping Chrome but only executes if the hovered node was removed. Now we are essentially doing it all the time.
Naively I would say yes it does make sense to put it there. Rather than a 20ms timeout, specify it happens in a subsequent async task?
Philip Jägenstedt
Aug 14, 2017, 7:25:56 AM8/14/17
to Chris Harrelson, Dave Tapuska, Dimitri Glazkov, blink-dev
On Thu, Aug 10, 2017 at 11:25 PM Chris Harrelson <chri...@chromium.org> wrote:
On Thu, Aug 10, 2017 at 2:18 PM, Dave Tapuska <dtap...@chromium.org> wrote:a) There are some layout tests that I can move over to web platform testsThat would be great, thanks.b) The lifecycle of events is largely unspecified in any spec though.Would it make sense to add it to the event loop explainer? The problem with doing it part of the eventloop explainer is that we do it after a timeout (20ms). For example this code exists in shipping Chrome but only executes if the hovered node was removed. Now we are essentially doing it all the time.Naively I would say yes it does make sense to put it there. Rather than a 20ms timeout, specify it happens in a subsequent async task?
What does Firefox do? All else equal, matching an existing implementation is good.
I think the spec that needs to be changed is https://w3c.github.io/uievents/, as it currently says "A user agent MUST dispatch this event when a pointing device is moved onto the boundaries of an element or one of its descendent elements."
I definitely think we should do this, all that is missing is putting it into a spec against which tests can be written, so that other can implement the same behavior without reverse-engineering Gecko or Chromium.
P.S. I think this will allow an old fullscreen+hover hack to be removed, yay!
Dave Tapuska
Aug 14, 2017, 9:46:30 AM8/14/17
to Philip Jägenstedt, Chris Harrelson, Dimitri Glazkov, blink-dev
What is good is that our implementation actually matches firefox relatively closely. We both synthesize mousemove events in these cases now (but don't actually fire the mousemove to the DOM). In case of scroll events, Firefox uses a 100ms timer and then attaches the synthetic mousemove to the next refresh activity (I believe this is vsync). In the case of layouts the synthetic mousemove is attached to the next refresh activity.
In Chrome's implementation the event is fired after scroll with 100ms delay, and after a layout 20ms. We will in the future align these to use the rAF signal because it will be more optimal. However this change is just building on machinery we've had in Chrome for quite some time.
I've proposed some modification to the spec here:
https://github.com/w3c/uievents/pull/155We do have a layout test for this that I can convert to a test in the uievents WPT test directory. I can move this test in the same CL when enabling by default.
Do you require it to be merged into the spec in order for this intent-to-ship to be approved? Because I believe the editor is OOO this week and I'd like to get this in before Friday before the feature freeze.
dave.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeX0baRwzwyS4255022BYkemKWgGsmLkM221j60fpUxVw%40mail.gmail.com.
Philip Jägenstedt
Aug 14, 2017, 11:23:35 AM8/14/17
to Dave Tapuska, Chris Harrelson, Dimitri Glazkov, blink-dev
On Mon, Aug 14, 2017 at 3:46 PM Dave Tapuska <dtap...@chromium.org> wrote:
What is good is that our implementation actually matches firefox relatively closely. We both synthesize mousemove events in these cases now (but don't actually fire the mousemove to the DOM). In case of scroll events, Firefox uses a 100ms timer and then attaches the synthetic mousemove to the next refresh activity (I believe this is vsync). In the case of layouts the synthetic mousemove is attached to the next refresh activity.In Chrome's implementation the event is fired after scroll with 100ms delay, and after a layout 20ms. We will in the future align these to use the rAF signal because it will be more optimal. However this change is just building on machinery we've had in Chrome for quite some time.I've proposed some modification to the spec here:https://github.com/w3c/uievents/pull/155We do have a layout test for this that I can convert to a test in the uievents WPT test directory. I can move this test in the same CL when enabling by default.Do you require it to be merged into the spec in order for this intent-to-ship to be approved? Because I believe the editor is OOO this week and I'd like to get this in before Friday before the feature freeze.
It's not a requirement, it's just a thing that can fall between the cracks, and also reviewing the change is a bit easier if it's already merged.
In https://github.com/w3c/uievents/pull/155 there are no details of the timing here, are the tests you would upstream no more strict about the timing either?
Chris is OOO for a bit so we should not wait for his further feedback. LGTM1 assuming that spec change and corresponding wpt tests are landed well before the change reaches the stable channel. Can you also file bugs for Edge and WebKit to do the same thing, pointing to the change/tests?
Rick Byers
Aug 15, 2017, 1:09:08 PM8/15/17
to Philip Jägenstedt, Dave Tapuska, Chris Harrelson, Dimitri Glazkov, blink-dev
LGTM3 (Philip was actually the 2nd). I agree matching Firefox here is relatively low risk, and this is an area that was really unspecified before. Thanks for submitting a spec PR and (ultimately) a WPT for this.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfUeWdCA%2B2uaH%2BNhqmOUz-3_D3fob96y9iUay5OQnBfHA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages