I'd like to clarify if this is related to issue I'm facing: disabled inputs block CSS transition events.
Behavior is the same in FF 56 & FF 66 (Build ID 20190211185957).

(In reply to ZeroUnderscoreOu from comment #50)

I'd like to clarify if this is related to issue I'm facing: disabled inputs block CSS transition events.
Behavior is the same in FF 56 & FF 66 (Build ID 20190211185957).

If you have a reduced test case, I'd be happy to have take a look.

Testcase file. It has 4 buttons (2 <Inputs>, 2 <Buttons>, 2 enabled, 2 disabled). Fifth button triggers styling changes, which leads to transitions. Handler logs events info to console.

In Firefox, transition events on disabled elements get "eaten". This is highlighted by a separate listener for an element which is inside a disabled button.

Console output in Firefox:

transitionend from Input_Enabled to Window
transitionend from Button_Enabled to Window
transitionend from Span_Enabled to Window
transitionend from Span_Disabled to Span_Disabled

In Chrome:

transitionend from Input_Enabled to Window
transitionend from Input_Disabled to Window
transitionend from Button_Enabled to Window
transitionend from Span_Enabled to Window
transitionend from Button_Disabled to Window
transitionend from Span_Disabled to Span_Disabled
transitionend from Span_Disabled to Window

I expect Firefox to behave the same way Chrome does, in this particular case.
Tested on Firefox 66.0b8 (Build ID 20190214195736) & Chrome 72.0.3626.109 64 bit, Windows 7 x64.

@smaug, I'm unsure where to find what controls the transition dispatching - but it's indeed not dispatching "transitionend" for disabled input elements? Any pointers would be helpful.

Add the needed events to https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/dom/html/nsGenericHTMLElement.cpp#1962

(I wonder if we'll change that list to be black list including only eClick or so)

(In reply to Olli Pettay [:smaug] from comment #54)

Add the needed events to https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/dom/html/nsGenericHTMLElement.cpp#1962

Thanks!

(I wonder if we'll change that list to be black list including only eClick or so)

Yeah, might make sense. There is also that other more bogus stuff we might be able to get rid of:

  // FIXME(emilio): This poking at the style of the frame is slightly bogus
  // unless we flush before every event, which we don't really want to do.
  if (aFrame && aFrame->StyleUI()->mUserInput == StyleUserInput::None) {
    return true;
  }

Anyway, will add the event cases to the switch and we can wait and see other web compat issues come up.

ZeroUnderscoreOu, the patch in bug 1530239 will be landing soon to fix the transitions issue (just doing final checks before merge). Thank you for reporting the issue and for the test case - it was quite helpful!

Glad I was able to help. Thank you for your work!

Also fixing for CSS Animations 🎉 They had the same issue (bug #1531605).

I may be doing something wrong, but for me (Firefox 66.0.5 - Linux) the issue still persists. Events are not dispatched when the element is disabled. Example here: https://codepen.io/anon/pen/vWMNjV

This bug was specifically about manually-dispatched (via dispatchEvent) events. That testcase is using actual click events generated by user interaction, which is a very different situation.

robbendebiene, please follow:
https://bugzilla.mozilla.org/show_bug.cgi?id=1540995