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?
Having a look, same problem in QtTestBrowser, not in Chrome ...
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();
(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
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.
Let me try putting the mouse-event/shadow logic in the parent object, RenderBlock ...
(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?
Created attachment 101808 [details] Patch
> 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?
(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.
(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.
Created attachment 101979 [details] Patch
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.
(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.
Comment on attachment 101979 [details] Patch Clearing flags on attachment: 101979 Committed r91827: <http://trac.webkit.org/changeset/91827>
All reviewed patches have been landed. Closing bug.