Intent to Ship: Send Mouse Events to Disabled Form Controls

92 views
Skip to first unread message

Dave Tapuska

unread,
Sep 13, 2017, 4:35:39 PM9/13/17
to blink-dev

Contact emails

dtap...@chromium.org


Explainer

N/A


Spec

https://html.spec.whatwg.org/multipage/forms.html#enabling-and-disabling-form-controls:-the-disabled-attribute


Summary

Events that have no activation behavior should be sent to form controls. That is the HTML Spec specifically identifies that "click" should be prevented to disabled form controls but it appears that all mouse events aren't sent to form controls. This proposal changes that all mouse events (other than click) are sent to disabled form controls.


Motivation

Rationalizing the platform. There is no need for these events to be hidden from a disabled form control they currently are sent for targets inside a disabled button and for other events like touchstart/touchend.


Risks

Interoperability and Compatibility

Possibly some sites may start getting mouse events when they don't expect them; specifically mousedown/mouseup. Firefox already sends mousemove, mouseover, mouseout, mouseenter, mouseleave, pointermove, pointerover, pointerout, pointerenter, pointerleave, wheel so these events shouldn't really surprise web developers.


Where Chrome is deviating from Firefox is that we will send mouseup/down to match the specification but avoid sending the click event entirely.


Edge: No signals

Firefox: Shipped (as commented above)

Safari: No signals

Web developers: Positive



             Chrome Status shows us that on 0.04% of sites we will be dispatching events now.


Ergonomics

N/A


Activation

Easy to start taking advantage of just add the listener.


Debuggability

Quite easy.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

Yes it will be. Currently there is a layout test that just needs to move over to WPT.


Link to entry on the feature dashboard

https://www.chromestatus.com/features/5685077795143680


Chris Harrelson

unread,
Sep 13, 2017, 4:42:43 PM9/13/17
to Dave Tapuska, blink-dev
LGTM1

--
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/CAHXv1wk-7J6CefpK517MhYQwRtifqozNuQUYxwe8BLPJXek5RA%40mail.gmail.com.

PhistucK

unread,
Sep 14, 2017, 5:31:18 AM9/14/17
to Chris Harrelson, Dave Tapuska, blink-dev
I think dispatching mouseup and mousedown is pretty risky. I think disabled might frequently be used to deny interactions with a control in a quick and easy way and this could break things. For application that only rely on client side logic to prevent those stuff (say, because the operation is legal at the backend, but this specific front end mode is read-only), it might have severe consequences.

I do not see a significant issue with the rest, but they bear some risk as well, since only Firefox dispatches them at the moment.

While the alternative is easy ([disabled] { pointer-events: none; }, right?), I think it may have severely negative impact and perhaps even trigger security issues in insecurely coded applications.

If other browser (not just Firefox) had positive signals and plan on converging sort-of-at-the-same-time - that is one thing. Without that, in my opinion, this should not move forward.


PhistucK

Rick Byers

unread,
Sep 18, 2017, 4:03:14 AM9/18/17
to PhistucK, Chris Harrelson, Dave Tapuska, blink-dev, Olli Pettay
I agree there's some compat risk here.  The fact that the events do get delivered to child nodes and bubble up through disabled form controls mitigates this somewhat.  I don't see any easy way to quantify the risk for the 0.04% of page views, so I think we should just make sure we understand the state here, and give matching the spec a try.  We can always revert at the first significant sign of breakage and re-evaluate using the data we gained.

In terms of making sure we understand the state, I have a few questions:
  • do Edge, IE or Safari send mousedown/mouseup?
  • It's surprising to me that firefox would send all those other events but not mousedown/mouseup.  Have you looked for bugs around this?  Perhaps Olli can shed some light onto the history here?  Would he (or others at Mozilla) support matching us if we can show it's reasonably web compatible for Chrome?
  • Have Microsoft or Apple folks said anything about this?  Eg. perhaps there's some history when the spec has changed.  If not, can you at least ask them?  If they had some reason (other than just fear over compat) to not make this change, then we might want to discuss some spec changes first.
  • Will our built-in form control behavior be impacted at all?  Eg. do we have any internal listeners which should be modified to check the disabled state? 

smaug

unread,
Sep 18, 2017, 4:30:02 AM9/18/17
to Rick Byers, PhistucK, Chris Harrelson, Dave Tapuska, blink-dev
On 09/18/2017 11:03 AM, 'Rick Byers' via blink-dev wrote:
> I agree there's some compat risk here. The fact that the events do get delivered to child nodes and bubble up through disabled form controls
> mitigates this somewhat. I don't see any easy way to quantify the risk for the 0.04% of page views, so I think we should just make sure we understand
> the state here, and give matching the spec a try. We can always revert at the first significant sign of breakage and re-evaluate using the data we
> gained.
>
> In terms of making sure we understand the state, I have a few questions:
>
> * do Edge, IE or Safari send mousedown/mouseup?
> * It's surprising to me that firefox would send all those other events but not mousedown/mouseup.
What is surprising about that? mousedown/up are after all often used very similarly to clicks.

For a long time Gecko didn't fire any events on disabled form controls.
(CVS says 1999 http://52.25.115.98/viewvc/main/mozilla/content/html/content/src/nsHTMLInputElement.cpp?r1=1.68&r2=1.69& )
Since then we've added more events to the non-disabled events list, starting
from mousemove.

mousedown/up do sound a bit risky, comparing to the other events. I would expect some broken sites.
And internally mousedown does cause some default handling, like opens <select>. But changing such default handling to check disabled state should be fine.
I think I'm not against trying to start dispatching mousedown/up, though the whole click handling is still not defined properly (at least last time I
looked at it). So might be worth to spend some time to sort this historical mess up in the spec level before trying to ship anything random which
other browsers don't do.



> Have you looked for bugs around this? Perhaps
> Olli can shed some light onto the history here? Would he (or others at Mozilla) support matching us if we can show it's reasonably web compatible
> for Chrome?
> * Have Microsoft or Apple folks said anything about this? Eg. perhaps there's some history when the spec has changed. If not, can you at least ask
> them? If they had some reason (other than just fear over compat) to not make this change, then we might want to discuss some spec changes first.
> * Will our built-in form control behavior be impacted at all? Eg. do we have any internal listeners which should be modified to check the disabled
> state?
>
> On Thursday, September 14, 2017, PhistucK <phis...@gmail.com <mailto:phis...@gmail.com>> wrote:
>
> I think dispatching mouseup and mousedown is pretty risky. I think disabled might frequently be used to deny interactions with a control in a
> quick and easy way and this could break things. For application that only rely on client side logic to prevent those stuff (say, because the
> operation is legal at the backend, but this specific front end mode is read-only), it might have severe consequences.
>
> I do not see a significant issue with the rest, but they bear some risk as well, since only Firefox dispatches them at the moment.
>
> While the alternative is easy ([disabled] { pointer-events: none; }, right?), I think it may have severely negative impact and perhaps even
> trigger security issues in insecurely coded applications.
>
> If other browser (not just Firefox) had positive signals and plan on converging sort-of-at-the-same-time - that is one thing. Without that, in my
> opinion, this should not move forward.
>
>
> ☆*PhistucK*
>
> On Wed, Sep 13, 2017 at 11:42 PM, Chris Harrelson <chri...@chromium.org <javascript:_e(%7B%7D,'cvml','chri...@chromium.org');>> wrote:
>
> LGTM1
>
> On Wed, Sep 13, 2017 at 1:35 PM, Dave Tapuska <dtap...@chromium.org <javascript:_e(%7B%7D,'cvml','dtap...@chromium.org');>> wrote:
>
> Link to Intent to Implement <https://groups.google.com/a/chromium.org/d/msg/Blink-dev/rhNbsYDBJes/Jvmtv6IbBwAJ>
>
> Contact emails
>
> dtap...@chromium.org <javascript:_e(%7B%7D,'cvml','dtap...@chromium.org');>
>
>
> Explainer
>
> N/A
>
>
> *Spec*
>
> https://html.spec.whatwg.org/multipage/forms.html#enabling-and-disabling-form-controls:-the-disabled-attribute
> <https://html.spec.whatwg.org/multipage/forms.html#enabling-and-disabling-form-controls:-the-disabled-attribute>
>
>
> Summary
>
> Events that have no activation behavior should be sent to formcontrols. That is the HTML Spec specifically identifies that "click" should
> be prevented to disabledformcontrolsbut it appears that all mouse events aren't sent to formcontrols. This proposal changes that all mouse
> events (other than click) are sent to disabledformcontrols.
>
>
> Motivation
>
> Rationalizing the platform. There is no need for these events to be hidden from a disabledformcontrolthey currently are sent for targets
> inside a disabledbutton and for other events like touchstart/touchend.
>
>
> Risks
>
> Interoperability and Compatibility
>
> Possibly some sites may start getting mouse events when they don't expect them; specifically mousedown/mouseup. Firefox already sends
> mousemove, mouseover, mouseout, mouseenter, mouseleave, pointermove, pointerover, pointerout, pointerenter, pointerleave, wheel so these
> events shouldn't really surprise web developers.
>
>
> Where Chrome is deviating from Firefox is that we will send mouseup/down to match the specification but avoid sending the click event
> entirely.
>
>
> Edge: No signals
>
> Firefox: Shipped (as commented above)
>
> Safari: No signals
>
> Web developers: Positive
>
>
>
> Chrome Status shows us that on 0.04%
> <https://www.chromestatus.com/metrics/feature/popularity#DispatchMouseEventOnDisabledFormControl> of sites we will be dispatching events now.
>
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> Easy to start taking advantage of just add the listener.
>
>
> Debuggability
>
> Quite easy.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> Yes it will be. Currently there is a layout test
> <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/forms/mouseevent_disabled_form_control.html?q=mouseevent_disabled_form_control.html&sq=package:chromium&l=1>
> that just needs to move over to WPT.
>
>
> Link to entry on the feature dashboard <https://www.chromestatus.com/>
>
> https://www.chromestatus.com/features/5685077795143680 <https://www.chromestatus.com/features/5685077795143680>
>
>
> --
> 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
> <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsu...@chromium.org');>.
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wk-7J6CefpK517MhYQwRtifqozNuQUYxwe8BLPJXek5RA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
> --
> 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
> <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsu...@chromium.org');>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_bFkqBXc6o0hArBqSMxnv_gPX8MNKLW6UoY1mL4%3D8o6A%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_bFkqBXc6o0hArBqSMxnv_gPX8MNKLW6UoY1mL4%3D8o6A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
> --
> 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/CABc02_%2BVZ5M9czPsWCCjpkN3k2hyFkJeCJvRN1hcg6H8ku75eg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BVZ5M9czPsWCCjpkN3k2hyFkJeCJvRN1hcg6H8ku75eg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-Es%3D79P9vSogwZozar8eqtXS-eEKa4FjNR6bb7ZqHGHA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-Es%3D79P9vSogwZozar8eqtXS-eEKa4FjNR6bb7ZqHGHA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Philip Jägenstedt

unread,
Sep 25, 2017, 8:12:30 AM9/25/17
to smaug, Rick Byers, PhistucK, Chris Harrelson, Dave Tapuska, blink-dev
If I'm reading this thread right, we intent is to match Firefox and additionally dispatch mousedown and mouseup.

Rationalizing the web platform is certainly a good thing, but there's also the question of how quickly we can converge on something, so that web developers get to enjoy the consistent behavior. It might be easier to get everyone on board with something more conservative. Specifically, how about supporting the union of all events that any browser fires? Would that be exactly Firefox's behavior?

Input from Edge and WebKit would be move valuable here, and whatever they're most happy with seems like a good choice. Dave, have you reached out to them yet?

Dave Tapuska

unread,
Sep 25, 2017, 2:04:30 PM9/25/17
to Philip Jägenstedt, smaug, Rick Byers, PhistucK, Chris Harrelson, blink-dev
So to clarify the behavior:

IE/Edge
- Sends mousemove events to the event path (but not to the disabled target).
- Sends mouseup/down/click to targets inside disabled buttons (but not the disabled target itself).

Firefox:
- Sends mousemove events to event path
- No mouseup/down on an disabled form
- Never targets events to an element inside a button

Chrome (current) / Safari
- Never sends mousemove when over a disabled target (to nothing on the event path)
- Sends mouseup/down/click to eventpath (up to disabled element) when inside a target inside a disabled button (but not when the hit test is the button itself).

Chrome (proposed)
- Send mousemove, mouseup/down events to event path
- Don't send a click if a disabled form is in the event path

Because Firefox never sends events to targets inside the button element it doesn't have this weird behavior that IE/Edge/Safari/Chrome do in sending a mouseup/down/click event to the event path but only when the item hit tested isn't a disabled form control itself.

There is one minor change that is impacted with our internal form control handling due to this change. For example if you have a checkbox inside a disabled button you can no longer toggle its setting, however this matches what Firefox does. Also allowing the mouseup/down allows disabled textareas with scrollbars to be able to be resized (crbug.com/762709)

So no browser agrees on all the events that should be sent. I'll reach out to Microsoft/Safari to see if I can get some comments on this.

dave.

>             To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org
>             <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsubscribe@chromium.org');>.

>             To view this discussion on the web visit
>             https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wk-7J6CefpK517MhYQwRtifqozNuQUYxwe8BLPJXek5RA%40mail.gmail.com
>             <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wk-7J6CefpK517MhYQwRtifqozNuQUYxwe8BLPJXek5RA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
>         --
>         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
>         <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsubscribe@chromium.org');>.
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org
> <mailto:blink-dev+unsubscribe@chromium.org>.

smaug

unread,
Sep 25, 2017, 2:37:07 PM9/25/17
to Dave Tapuska, Philip Jägenstedt, Rick Byers, PhistucK, Chris Harrelson, blink-dev
On 09/25/2017 09:04 PM, Dave Tapuska wrote:
> So to clarify the behavior:
>
> IE/Edge
> - Sends mousemove events to the event path (but not to the disabled target).
> - Sends mouseup/down/click to targets inside disabled buttons (but not the disabled target itself).
>
> Firefox:
> - Sends mousemove events to event path
> - No mouseup/down on an disabled form
> - Never targets events to an element inside a button
>
> Chrome (current) / Safari
> - Never sends mousemove when over a disabled target (to nothing on the event path)
> - Sends mouseup/down/click to eventpath (up to disabled element) when inside a target inside a disabled button (but not when the hit test is the
> button itself).
>
> Chrome (proposed)
> - Send mousemove, mouseup/down events to event path
> - Don't send a click if a disabled form is in the event path
>
> Because Firefox never sends events to targets inside the button element it doesn't have this weird behavior that IE/Edge/Safari/Chrome do in sending a
> mouseup/down/click event to the event path but only when the item hit tested isn't a disabled form control itself.
FWIW, the current plan is to change <button> handling in Gecko, but need to sort out what the spec should say.
(What Chrome does is quite far from the current spec)


>
> There is one minor change that is impacted with our internal form control handling due to this change. For example if you have a checkbox inside a
> disabled button you can no longer toggle its setting, however this matches what Firefox does. Also allowing the mouseup/down allows disabled textareas
> with scrollbars to be able to be resized (crbug.com/762709 <http://crbug.com/762709>)
>
> So no browser agrees on all the events that should be sent. I'll reach out to Microsoft/Safari to see if I can get some comments on this.
>
> dave.
>
> On Mon, Sep 25, 2017 at 8:12 AM, Philip Jägenstedt <foo...@google.com <mailto:foo...@google.com>> wrote:
>
> If I'm reading this thread right, we intent is to match Firefox and additionally dispatch mousedown and mouseup.
>
> Rationalizing the web platform is certainly a good thing, but there's also the question of how quickly we can converge on something, so that web
> developers get to enjoy the consistent behavior. It might be easier to get everyone on board with something more conservative. Specifically, how
> about supporting the union of all events that any browser fires? Would that be exactly Firefox's behavior?
>
> Input from Edge and WebKit would be move valuable here, and whatever they're most happy with seems like a good choice. Dave, have you reached out
> to them yet?
>
> > On Thursday, September 14, 2017, PhistucK <phis...@gmail.com <mailto:phis...@gmail.com> <mailto:phis...@gmail.com
> <mailto:phis...@gmail.com>>> wrote:
> >
> > I think dispatching mouseup and mousedown is pretty risky. I think disabled might frequently be used to deny interactions with a control
> in a
> > quick and easy way and this could break things. For application that only rely on client side logic to prevent those stuff (say, because the
> > operation is legal at the backend, but this specific front end mode is read-only), it might have severe consequences.
> >
> > I do not see a significant issue with the rest, but they bear some risk as well, since only Firefox dispatches them at the moment.
> >
> > While the alternative is easy ([disabled] { pointer-events: none; }, right?), I think it may have severely negative impact and perhaps even
> > trigger security issues in insecurely coded applications.
> >
> > If other browser (not just Firefox) had positive signals and plan on converging sort-of-at-the-same-time - that is one thing. Without
> that, in my
> > opinion, this should not move forward.
> >
> >
> > ☆*PhistucK*
> >
> > On Wed, Sep 13, 2017 at 11:42 PM, Chris Harrelson <chri...@chromium.org <mailto:chri...@chromium.org>
> <javascript:_e(%7B%7D,'cvml','chri...@chromium.org <mailto:chri...@chromium.org>');>> wrote:
> >
> > LGTM1
> >
> > On Wed, Sep 13, 2017 at 1:35 PM, Dave Tapuska <dtap...@chromium.org <mailto:dtap...@chromium.org>
> <javascript:_e(%7B%7D,'cvml','dtap...@chromium.org <mailto:dtap...@chromium.org>');>> wrote:
> >
> > Link to Intent to Implement <https://groups.google.com/a/chromium.org/d/msg/Blink-dev/rhNbsYDBJes/Jvmtv6IbBwAJ
> <https://groups.google.com/a/chromium.org/d/msg/Blink-dev/rhNbsYDBJes/Jvmtv6IbBwAJ>>
> >
> > Contact emails
> >
> > dtap...@chromium.org <mailto:dtap...@chromium.org> <javascript:_e(%7B%7D,'cvml','dtap...@chromium.org
> <mailto:dtap...@chromium.org>');>
> > To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsu...@chromium.org <mailto:blink-dev%252Buns...@chromium.org>');>.
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wk-7J6CefpK517MhYQwRtifqozNuQUYxwe8BLPJXek5RA%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wk-7J6CefpK517MhYQwRtifqozNuQUYxwe8BLPJXek5RA%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
> >
> >
> > --
> > 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
> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsu...@chromium.org <mailto:blink-dev%252Buns...@chromium.org>');>.
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_bFkqBXc6o0hArBqSMxnv_gPX8MNKLW6UoY1mL4%3D8o6A%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BVZ5M9czPsWCCjpkN3k2hyFkJeCJvRN1hcg6H8ku75eg%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BVZ5M9czPsWCCjpkN3k2hyFkJeCJvRN1hcg6H8ku75eg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
> >
> > --
> > 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
> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org <mailto:blink-dev%2Bunsu...@chromium.org>>.
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-Es%3D79P9vSogwZozar8eqtXS-eEKa4FjNR6bb7ZqHGHA%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/43c6c96a-ff09-5d60-f97b-f5de4d1e3167%40welho.com>.
>
>

Dave Tapuska

unread,
Sep 27, 2017, 12:07:22 PM9/27/17
to smaug, Philip Jägenstedt, Rick Byers, PhistucK, Chris Harrelson, blink-dev
In an offline discussion Apple has expressed the same concern Firefox has around the mousedown/up. I withdraw my request to ship with the caveat that I'll revisit this in another 3 or so releases.

I'll try to add new UMA metrics in M63 to further quantify the 0.04% based on the mousedown/up. As I largely suspect that 0.04% is largely dominated by the mousemoves on disabled form controls and I should be able to calculate the number of pages that have a mousedown/up event handler and are in the event path if we dispatched these events.

dave.

        >             To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org
        <mailto:blink-dev%2Bunsubscribe...@chromium.org>
        >             <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsubscribe@chromium.org <mailto:blink-dev%252Bunsubscri...@chromium.org>');>.

        <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wk-7J6CefpK517MhYQwRtifqozNuQUYxwe8BLPJXek5RA%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
        >
        >
        >         --
        >         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
        <mailto:blink-dev%2Bunsubscribe...@chromium.org>
        >         <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsubscribe@chromium.org <mailto:blink-dev%252Bunsubscri...@chromium.org>');>.

        <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BVZ5M9czPsWCCjpkN3k2hyFkJeCJvRN1hcg6H8ku75eg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
        >
        > --
        > 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
        <mailto:blink-dev%2Bunsubscribe...@chromium.org>
        > <mailto:blink-dev+unsubscribe@chromium.org <mailto:blink-dev%2Bunsubscribe...@chromium.org>>.

Philip Jägenstedt

unread,
Sep 30, 2017, 6:38:15 AM9/30/17
to Dave Tapuska, smaug, Rick Byers, PhistucK, Chris Harrelson, blink-dev
That's great Dave, hope that we can sort this out in a way that everyone can eventually get behind!

        >             To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
        <mailto:blink-dev%2Bunsu...@chromium.org>
        >             <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsu...@chromium.org <mailto:blink-dev%252Buns...@chromium.org>');>.

        <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wk-7J6CefpK517MhYQwRtifqozNuQUYxwe8BLPJXek5RA%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
        >
        >
        >         --
        >         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
        <mailto:blink-dev%2Bunsu...@chromium.org>
        >         <javascript:_e(%7B%7D,'cvml','blink-dev%2Bunsu...@chromium.org <mailto:blink-dev%252Buns...@chromium.org>');>.

        <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BVZ5M9czPsWCCjpkN3k2hyFkJeCJvRN1hcg6H8ku75eg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
        >
        > --
        > 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
Reply all
Reply to author
Forward
0 new messages