Bug 54820 – REGRESSION: Knob of a disabled range control is draggable

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Alexey Proskuryakov]

See bug URL. I can drag the knob as if the control was not disabled.

Has the range control been rewritten to use shadow DOM?

[chris reiss]

Having a look, same problem in QtTestBrowser, not in Chrome ...

[chris reiss]

looks like this fixes it.  how does one write a layout test for such a thing ?


Index: Source/WebCore/html/shadow/SliderThumbElement.cpp
===================================================================
--- Source/WebCore/html/shadow/SliderThumbElement.cpp	(revision 78999)
+++ Source/WebCore/html/shadow/SliderThumbElement.cpp	(working copy)
@@ -158,6 +158,12 @@
         return;
     }
 
+    HTMLInputElement* input = static_cast<HTMLInputElement*>(shadowHost());
+    if (input->isReadOnlyFormControl() || !input->isEnabledFormControl() ) {
+        HTMLDivElement::defaultEventHandler(event);
+        return;
+    }
+ 
     MouseEvent* mouseEvent = static_cast<MouseEvent*>(event);
     bool isLeftButton = mouseEvent->button() == LeftButton;
     const AtomicString& eventType = event->type();

[Dimitri Glazkov (Google)]

(In reply to comment #2)
> looks like this fixes it.  how does one write a layout test for such a thing ?
> 
> 
> Index: Source/WebCore/html/shadow/SliderThumbElement.cpp
> ===================================================================
> --- Source/WebCore/html/shadow/SliderThumbElement.cpp    (revision 78999)
> +++ Source/WebCore/html/shadow/SliderThumbElement.cpp    (working copy)
> @@ -158,6 +158,12 @@
>          return;
>      }
> 
> +    HTMLInputElement* input = static_cast<HTMLInputElement*>(shadowHost());
> +    if (input->isReadOnlyFormControl() || !input->isEnabledFormControl() ) {
> +        HTMLDivElement::defaultEventHandler(event);
> +        return;
> +    }
> + 
>      MouseEvent* mouseEvent = static_cast<MouseEvent*>(event);
>      bool isLeftButton = mouseEvent->button() == LeftButton;
>      const AtomicString& eventType = event->type();

There are lots of examples in existing LayoutTests. For example:

http://google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/LayoutTests/fast/repaint/slider-thumb-drag-release.html&exact_package=chromium

[Alexey Proskuryakov]

Can anything be done to make mistakes like this less likely to occur elsewhere? It doesn't seem like it should be the job of every element that may end up being in a shadow tree to check if the host is disabled.

[chris reiss]

Let me try putting the mouse-event/shadow logic in the parent object, RenderBlock ...

[Dimitri Glazkov (Google)]

(In reply to comment #4)
> Can anything be done to make mistakes like this less likely to occur elsewhere? It doesn't seem like it should be the job of every element that may end up being in a shadow tree to check if the host is disabled.

This is a good question. Do shadow DOM subtrees of disabled hosts hear events? Hixie, WDYT?

[Shinya Kawanaka]

Created attachment 101808 [details]
Patch

[Alexey Proskuryakov]

> Can anything be done to make mistakes like this less likely to occur elsewhere? It doesn't seem like it should be the job of every element that may end up being in a shadow tree to check if the host is disabled.

This question still stands.

Also, what is the reason to add the checks in two places?

[Shinya Kawanaka]

(In reply to comment #8)
> > Can anything be done to make mistakes like this less likely to occur elsewhere? It doesn't seem like it should be the job of every element that may end up being in a shadow tree to check if the host is disabled.
> 
> This question still stands.
> 
> Also, what is the reason to add the checks in two places?

They were necessary to make the slider work correctly on Mac. Just adding the code in RangeThumbSlider cannot disable the slider correctly on Mac, the other platform can though.

However, it is true that this patch does not answer the question. So I try to add some code in HTMLInputElement to disable shadow elements in all input type.

[Kent Tamura]

(In reply to comment #8)
> Also, what is the reason to add the checks in two places?

A change for RangeInputType.cpp disables moving the thumb by clicking on the track not on the thumb, and a change for SliderThumbElement.cpp disables dragging the thumb.

Shinya, your test looks not to cover the former case.

[Shinya Kawanaka]

Created attachment 101979 [details]
Patch

[Shinya Kawanaka]

kent,

I've changed the test to cover the click on the knob and the click not on the knob.
However I omitted vertical slider version, because I don't think it is necessary to cover this scenario.

Alexey,

> Do shadow DOM subtrees of disabled hosts hear events? Hixie, WDYT?

This patch does not answer this question yet, however I prioritized fixing this regression bug.

[Kent Tamura]

(In reply to comment #12)
> > Do shadow DOM subtrees of disabled hosts hear events? Hixie, WDYT?
> 
> This patch does not answer this question yet, however I prioritized fixing this regression bug.

I agree with Shinya.  We should discuss it thoroughly in another bug.
I don't think we should stop delivering events in such case.

[WebKit Review Bot]

Comment on attachment 101979 [details]
Patch

Clearing flags on attachment: 101979

Committed r91827: <http://trac.webkit.org/changeset/91827>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.