InputType::disabledAttributeChanged and InputType::readonlyAttributeChanged should happen after the attribute has actually changed. This way if the InputType looks at the state, it would correctly get the new value, not the old value.
Created attachment 134649 [details] [PATCH] Proposed Fix Saw this while looking at: <http://webkit.org/b/82558> Toggling <input type="range"> readonly or disabled state while active breaks all click events It doesn't really make sense to call the changed function until the value has actually changed!
Comment on attachment 134649 [details] [PATCH] Proposed Fix OK. How do we observe this?
(In reply to comment #2) > (From update of attachment 134649 [details]) > OK. How do we observe this? This doesn't change any existing behavior. The only user of these InputType functions doesn't turn around and change the readonly / disabled state of the input. But if someone wanted to do that than this ordering would matter. I had a patch that used these functions and this confused me. To fix the problem we did not go with that patch, but I still wanted to fix this issue.
(In reply to comment #3) > (In reply to comment #2) > > (From update of attachment 134649 [details] [details]) > > OK. How do we observe this? > > The only user of these InputType functions doesn't turn around and > change the readonly / disabled state of the input. I typo'd. This should have said, ".. doesn't turn around and check the state..."
Comment on attachment 134649 [details] [PATCH] Proposed Fix This looks correct to me. I see why you cannot test this, no InputType rely on the attribute value in response to disabledAttributeChanged() or readonlyAttributeChanged().
Comment on attachment 134649 [details] [PATCH] Proposed Fix Clearing flags on attachment: 134649 Committed r112589: <http://trac.webkit.org/changeset/112589>
All reviewed patches have been landed. Closing bug.