Intent to Implement: Send Mouse Events to Disabled Form Controls
129 views
Skip to first unread message
Dave Tapuska
Mar 16, 2017, 10:22:17 AM3/16/17
to blink-dev
dtap...@chromium.org
https://html.spec.whatwg.org/multipage/forms.html#enabling-and-disabling-form-controls:-the-disabled-attribute
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.
Jake made this the subject of his blog post recently.
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.
Firefox: Shipped
Edge: No public signals
Safari: No public signals
Web developers: Positive
Likely little compatibility problems. As indicated in the github issue have asked this for some time from jQuery.
None
Yes
https://crbug.com/696686
https://www.chromestatus.com/features/5685077795143680
No. Going to implement it as an experimental web platform feature for one release and then try to ship.
PhistucK
Mar 16, 2017, 11:09:21 AM3/16/17
to Dave Tapuska, blink-dev
No link to the GitHub issue, but, anyway - I think this should be use counted first (disabled elements that have event listeners added for non-click mouse events that are currently disregarded). I hope that it helps, because I would guess enterprise systems might be more affected.
☆PhistucK
On Thu, Mar 16, 2017 at 4:22 PM, Dave Tapuska <dtap...@chromium.org> wrote:
dtap...@chromium.org https://html.spec.whatwg.org/multipage/forms.html#enabling-and-disabling-form-controls:-the-disabled-attribute 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.Jake made this the subject of his blog post recently. 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. Firefox: Shipped Edge: No public signals Safari: No public signals Web developers: Positive Likely little compatibility problems. As indicated in the github issue have asked this for some time from jQuery. None Yes https://crbug.com/696686 https://www.chromestatus.com/features/5685077795143680 No. Going to implement it as an experimental web platform feature for one release and then try to ship.
--
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.
Dave Tapuska
Mar 16, 2017, 11:14:23 AM3/16/17
to PhistucK, blink-dev
There was some discussion on the github issue here: https://github.com/w3c/pointerevents/issues/177.
I think trying to measure this is difficult because the mouse events bubble. Adding a mouseup/down/move listener high up the hierarchy should be counted as having an effect and I think user activity trackers will drown out any usefulness of this data. And what is a good benchmark for making such a change? Firefox already sends these events so the real debate for us is whether mouseup/down should be sent as well.
dave.
PhistucK
Mar 16, 2017, 11:17:53 AM3/16/17
to Dave Tapuska, blink-dev
Getting the data for direct events (on that element) would at least provide a lower bound, I guess...
☆PhistucK
Boris Zbarsky
Mar 16, 2017, 11:26:24 AM3/16/17
to Dave Tapuska, blink-dev
On 3/16/17 10:22 AM, Dave Tapuska wrote:
> Firefox: Shipped
Not quite.
What Firefox ships is that we have a whitelist of events that are not
affected by the disabled state. Those are, at this moment:
mousemove, mouseover, mouseout, mouseenter, mouseleave, pointermove,
pointerover, pointerout, pointerenter, pointerleave, wheel,
DOMMouseScroll, MozMousePixelScroll
All other events are affected. This includes "mousedown", "click",
"mouseup", all non-mouse events, etc.
https://bugzilla.mozilla.org/show_bug.cgi?id=1220048 tracks some open
questions on our end about how this should work, including some data on
the rather weird Chrome behavior as of the time that bug was filed.
With all that in mind, what is the actual behavior being proposed here,
both for "click" and non-"click" events?
-Boris
> Firefox: Shipped
Not quite.
What Firefox ships is that we have a whitelist of events that are not
affected by the disabled state. Those are, at this moment:
mousemove, mouseover, mouseout, mouseenter, mouseleave, pointermove,
pointerover, pointerout, pointerenter, pointerleave, wheel,
DOMMouseScroll, MozMousePixelScroll
All other events are affected. This includes "mousedown", "click",
"mouseup", all non-mouse events, etc.
https://bugzilla.mozilla.org/show_bug.cgi?id=1220048 tracks some open
questions on our end about how this should work, including some data on
the rather weird Chrome behavior as of the time that bug was filed.
With all that in mind, what is the actual behavior being proposed here,
both for "click" and non-"click" events?
-Boris
Dave Tapuska
Mar 16, 2017, 12:21:06 PM3/16/17
to Boris Zbarsky, blink-dev
Yes Firefox shipped a subset of events. I called this out on the chromestatus issue in the notes section; as the site only allows Shipped/Not Shipped selection. It appears the notes were not copied into this semi-automatic Intent to Implement.
Chrome already fires pointer events at disabled form controls (it was a recent change).
Only MouseEvents are subject to our "isDisabledFormControl", all other UA events don't go through that code path. Thanks for bringing up that issue in the bugzilla report. It is related to how our code handles shadow DOM with disabled form controls; the check is being bypassed because the hit tested node is a div inside the <input element>. I believe the spec is indicating that the actual target of the element and not the shadow dom target so that ultimately is an implementation flaw we can address.
Hmm; the shadow dom one is tricky wonder if don't stop propagation of "click" events on a disabled form control. But that creates interesting issues for capturing event listeners. Should a checkbox inside a disabled button be allowed to activate? jsbin is giving me issues in saving a snapshot but Firefox and Chrome differ here.
Is the spec ultimately trying to prevent the activation behavior of the disabled element? And really dispatching the click element would be ok (cause clearly we are doing it in some scenarios today) just not doing the activation behavior for disabled form controls is a no-op.
dave.
Boris Zbarsky
Mar 16, 2017, 12:24:32 PM3/16/17
to Dave Tapuska, blink-dev
On 3/16/17 12:21 PM, Dave Tapuska wrote:
> Is the spec ultimately trying to prevent the activation behavior of the
> disabled element?
I think in the end the spec is just trying to spec whatever UAs do, for
> Is the spec ultimately trying to prevent the activation behavior of the
> disabled element?
something with a long history and compat constraints like this.
The real question is what those compat constraints are.
> And really dispatching the click element would be ok
> (cause clearly we are doing it in some scenarios today) just not doing
> the activation behavior for disabled form controls is a no-op.
provide custom activation behavior, honestly.... But I don't have data
to prove this one way or the other.
-Boris
smaug
Mar 16, 2017, 12:24:35 PM3/16/17
to Dave Tapuska, Boris Zbarsky, blink-dev
On 03/16/2017 06:21 PM, Dave Tapuska wrote:
> Yes Firefox shipped a subset of events. I called this out on the chromestatus issue in the notes section; as the site only allows Shipped/Not Shipped
> selection. It appears the notes were not copied into this semi-automatic Intent to Implement.
>
> Chrome already fires pointer events at disabled form controls (it was a recent change).
>
> Only MouseEvents are subject to our "isDisabledFormControl", all other UA events don't go through that code path. Thanks for bringing up that issue in
> the bugzilla report. It is related to how our code handles shadow DOM with disabled form controls; the check is being bypassed because the hit tested
> node is a div inside the <input element>. I believe the spec is indicating that the actual target of the element and not the shadow dom target so that
> ultimately is an implementation flaw we can address.
>
> Hmm; the shadow dom one is tricky wonder if don't stop propagation of "click" events on a disabled form control. But that creates interesting issues
> for capturing event listeners. Should a checkbox inside a disabled button be allowed to activate? jsbin is giving me issues in saving a snapshot but
> Firefox and Chrome differ here.
>
> Is the spec ultimately trying to prevent the activation behavior of the disabled element? And really dispatching the click element would be ok (cause
> clearly we are doing it in some scenarios today) just not doing the activation behavior for disabled form controls is a no-op.
>
Dispatching click would most probably break web sites.
> Yes Firefox shipped a subset of events. I called this out on the chromestatus issue in the notes section; as the site only allows Shipped/Not Shipped
> selection. It appears the notes were not copied into this semi-automatic Intent to Implement.
>
> Chrome already fires pointer events at disabled form controls (it was a recent change).
>
> Only MouseEvents are subject to our "isDisabledFormControl", all other UA events don't go through that code path. Thanks for bringing up that issue in
> the bugzilla report. It is related to how our code handles shadow DOM with disabled form controls; the check is being bypassed because the hit tested
> node is a div inside the <input element>. I believe the spec is indicating that the actual target of the element and not the shadow dom target so that
> ultimately is an implementation flaw we can address.
>
> Hmm; the shadow dom one is tricky wonder if don't stop propagation of "click" events on a disabled form control. But that creates interesting issues
> for capturing event listeners. Should a checkbox inside a disabled button be allowed to activate? jsbin is giving me issues in saving a snapshot but
> Firefox and Chrome differ here.
>
> Is the spec ultimately trying to prevent the activation behavior of the disabled element? And really dispatching the click element would be ok (cause
> clearly we are doing it in some scenarios today) just not doing the activation behavior for disabled form controls is a no-op.
>
> dave.
>
> On Thu, Mar 16, 2017 at 11:26 AM, Boris Zbarsky <bzba...@mit.edu <mailto:bzba...@mit.edu>> wrote:
>
> On 3/16/17 10:22 AM, Dave Tapuska wrote:
>
> Firefox: Shipped
>
>
> Not quite.
>
> What Firefox ships is that we have a whitelist of events that are not affected by the disabled state. Those are, at this moment:
>
> mousemove, mouseover, mouseout, mouseenter, mouseleave, pointermove, pointerover, pointerout, pointerenter, pointerleave, wheel, DOMMouseScroll,
> MozMousePixelScroll
>
> All other events are affected. This includes "mousedown", "click", "mouseup", all non-mouse events, etc.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1220048 <https://bugzilla.mozilla.org/show_bug.cgi?id=1220048> tracks some open questions on our end
> On Thu, Mar 16, 2017 at 11:26 AM, Boris Zbarsky <bzba...@mit.edu <mailto:bzba...@mit.edu>> wrote:
>
> On 3/16/17 10:22 AM, Dave Tapuska wrote:
>
> Firefox: Shipped
>
>
> Not quite.
>
> What Firefox ships is that we have a whitelist of events that are not affected by the disabled state. Those are, at this moment:
>
> mousemove, mouseover, mouseout, mouseenter, mouseleave, pointermove, pointerover, pointerout, pointerenter, pointerleave, wheel, DOMMouseScroll,
> MozMousePixelScroll
>
> All other events are affected. This includes "mousedown", "click", "mouseup", all non-mouse events, etc.
>
> about how this should work, including some data on the rather weird Chrome behavior as of the time that bug was filed.
>
> With all that in mind, what is the actual behavior being proposed here, both for "click" and non-"click" events?
>
> -Boris
>
>
> --
> 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
>
> With all that in mind, what is the actual behavior being proposed here, both for "click" and non-"click" events?
>
> -Boris
>
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> <mailto:blink-dev%2Bunsu...@chromium.org>.
>
>
> --
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> <mailto:blink-dev+...@chromium.org>.
Dave Tapuska
Mar 21, 2017, 9:49:57 AM3/21/17
to smaug, Boris Zbarsky, blink-dev
I believe Gecko does something such as if a disabled form control exists on the event path then it doesn't dispatch the event? Boris, Olli can you confirm?
Doing something like that for the click event would certainly rationalize dispatching the click event.
dave.
Doing something like that for the click event would certainly rationalize dispatching the click event.
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>.
--
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+unsubscribe@chromium.org>.
--
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.
smaug
Mar 21, 2017, 2:23:03 PM3/21/17
to Dave Tapuska, Boris Zbarsky, blink-dev
On 03/21/2017 03:49 PM, 'Dave Tapuska' via blink-dev wrote:
> I believe Gecko does something such as if a disabled form control exists on the event path then it doesn't dispatch the event? Boris, Olli can you
> confirm?
Currently Gecko cuts the event path to the disabled form control (control is not in the path)
> I believe Gecko does something such as if a disabled form control exists on the event path then it doesn't dispatch the event? Boris, Olli can you
> confirm?
>
> Doing something like that for the click event would certainly rationalize dispatching the click event.
>
> dave.
>
> On Thu, Mar 16, 2017 at 12:24 PM, smaug <sm...@welho.com <mailto:sm...@welho.com>> wrote:
>
> On 03/16/2017 06:21 PM, Dave Tapuska wrote:
>
> Yes Firefox shipped a subset of events. I called this out on the chromestatus issue in the notes section; as the site only allows Shipped/Not
> Shipped
> selection. It appears the notes were not copied into this semi-automatic Intent to Implement.
>
> Chrome already fires pointer events at disabled form controls (it was a recent change).
>
> Only MouseEvents are subject to our "isDisabledFormControl", all other UA events don't go through that code path. Thanks for bringing up that
> issue in
> the bugzilla report. It is related to how our code handles shadow DOM with disabled form controls; the check is being bypassed because the hit
> tested
> node is a div inside the <input element>. I believe the spec is indicating that the actual target of the element and not the shadow dom target
> so that
> ultimately is an implementation flaw we can address.
>
> Hmm; the shadow dom one is tricky wonder if don't stop propagation of "click" events on a disabled form control. But that creates interesting
> issues
> for capturing event listeners. Should a checkbox inside a disabled button be allowed to activate? jsbin is giving me issues in saving a
> snapshot but
> Firefox and Chrome differ here.
>
> Is the spec ultimately trying to prevent the activation behavior of the disabled element? And really dispatching the click element would be ok
> (cause
> clearly we are doing it in some scenarios today) just not doing the activation behavior for disabled form controls is a no-op.
>
> Dispatching click would most probably break web sites.
>
>
> dave.
>
> On Thu, Mar 16, 2017 at 11:26 AM, Boris Zbarsky <bzba...@mit.edu <mailto:bzba...@mit.edu> <mailto:bzba...@mit.edu
>
> On 03/16/2017 06:21 PM, Dave Tapuska wrote:
>
> Yes Firefox shipped a subset of events. I called this out on the chromestatus issue in the notes section; as the site only allows Shipped/Not
> Shipped
> selection. It appears the notes were not copied into this semi-automatic Intent to Implement.
>
> Chrome already fires pointer events at disabled form controls (it was a recent change).
>
> Only MouseEvents are subject to our "isDisabledFormControl", all other UA events don't go through that code path. Thanks for bringing up that
> issue in
> the bugzilla report. It is related to how our code handles shadow DOM with disabled form controls; the check is being bypassed because the hit
> tested
> node is a div inside the <input element>. I believe the spec is indicating that the actual target of the element and not the shadow dom target
> so that
> ultimately is an implementation flaw we can address.
>
> Hmm; the shadow dom one is tricky wonder if don't stop propagation of "click" events on a disabled form control. But that creates interesting
> issues
> for capturing event listeners. Should a checkbox inside a disabled button be allowed to activate? jsbin is giving me issues in saving a
> snapshot but
> Firefox and Chrome differ here.
>
> Is the spec ultimately trying to prevent the activation behavior of the disabled element? And really dispatching the click element would be ok
> (cause
> clearly we are doing it in some scenarios today) just not doing the activation behavior for disabled form controls is a no-op.
>
> Dispatching click would most probably break web sites.
>
>
> dave.
>
> <mailto:bzba...@mit.edu>>> wrote:
>
> On 3/16/17 10:22 AM, Dave Tapuska wrote:
>
> Firefox: Shipped
>
>
> Not quite.
>
> What Firefox ships is that we have a whitelist of events that are not affected by the disabled state. Those are, at this moment:
>
> mousemove, mouseover, mouseout, mouseenter, mouseleave, pointermove, pointerover, pointerout, pointerenter, pointerleave, wheel,
> DOMMouseScroll,
> MozMousePixelScroll
>
> All other events are affected. This includes "mousedown", "click", "mouseup", all non-mouse events, etc.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1220048 <https://bugzilla.mozilla.org/show_bug.cgi?id=1220048>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1220048 <https://bugzilla.mozilla.org/show_bug.cgi?id=1220048>> tracks some open questions on
> our end
> about how this should work, including some data on the rather weird Chrome behavior as of the time that bug was filed.
>
> With all that in mind, what is the actual behavior being proposed here, both for "click" and non-"click" events?
>
> -Boris
>
>
> --
> 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
>
> On 3/16/17 10:22 AM, Dave Tapuska wrote:
>
> Firefox: Shipped
>
>
> Not quite.
>
> What Firefox ships is that we have a whitelist of events that are not affected by the disabled state. Those are, at this moment:
>
> mousemove, mouseover, mouseout, mouseenter, mouseleave, pointermove, pointerover, pointerout, pointerenter, pointerleave, wheel,
> DOMMouseScroll,
> MozMousePixelScroll
>
> All other events are affected. This includes "mousedown", "click", "mouseup", all non-mouse events, etc.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1220048 <https://bugzilla.mozilla.org/show_bug.cgi?id=1220048>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1220048 <https://bugzilla.mozilla.org/show_bug.cgi?id=1220048>> tracks some open questions on
> our end
> about how this should work, including some data on the rather weird Chrome behavior as of the time that bug was filed.
>
> With all that in mind, what is the actual behavior being proposed here, both for "click" and non-"click" events?
>
> -Boris
>
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> <mailto:blink-dev%2Bunsu...@chromium.org>
> <mailto:blink-dev%2Bunsu...@chromium.org <mailto:blink-dev%252Buns...@chromium.org>>.
>
>
> --
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> <mailto:blink-dev%2Bunsu...@chromium.org>
> <mailto:blink-dev+...@chromium.org <mailto:blink-dev%2Bunsu...@chromium.org>>.
>
>
> --
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> <mailto:blink-dev%2Bunsu...@chromium.org>.
>
>
> --
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> <mailto:blink-dev+...@chromium.org>.
Reply all
Reply to author
Forward
0 new messages