1659484 - classList.remove removes more classes than specified

Status: NEW

(DevTools :: Debugger, defect, P3)

Description

[pavel.belskiy2]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Experimenting with animations and grids, i stumbled upon a strange inconsistency between Chrome and Firefox. Investigating a bit further, i noticed in firefox devtools that Element.classList.remove() function sometimes(but quite reproducible) removes more classes than is specified by the arguments.

Firefox nightly also appears to have the bug.

Actual results:

I uploaded an example on codepen: https://codepen.io/jagh121/pen/KKzMgeq. The clickable element is highlighted with light-blue background. Clicking on it once will start a transition(which adds display: hidden at the end). Clicking again should start reverse animation, showing the elements. This works in chrome as designed.
In firefox, the second transition doesn't work: the 'hiding--leave-active' class that contains 'transition' property is removed almost immediately, on 'el.classList.remove(hiding--${substyle});' line (substyle is 'leave' string). This single line removes 2 classes in this moment, although only single class name is given. As result, elements are shown immediately and no transition happens.

Expected results:

classList.remove shouldn't remove classes that arent in its argument list

Comment 1

[pavel.belskiy2]

This is actually turned out to be quite confusing behavior of devtools

or 2 behaviors, actually.

1. Transitions will continue to run in background even if a breakpoint is triggered and the debugger is active. Looks like they are on a separate thread(?) and that thread is not paused when a breakpoint is triggered, making debugging harder if transitions can change state of a program while it's being debugged in line stepping mode.

2. At the same time, if the debugger is already paused on a breakpoint, javascript can still run(handlers like transitionend, see point 1.) If transitionend handler(s) have breakpoints set, they will not trigger.

Comment 2

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

It seems this is a devtools issue per comment 1.

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report!

(In reply to pavel.belskiy2 from comment #1)

1. Transitions will continue to run in background even if a breakpoint is triggered and the debugger is active. Looks like they are on a separate thread(?) and that thread is not paused when a breakpoint is triggered, making debugging harder if transitions can change state of a program while it's being debugged in line stepping mode.

2. At the same time, if the debugger is already paused on a breakpoint, javascript can still run(handlers like transitionend, see point 1.) If transitionend handler(s) have breakpoints set, they will not trigger.

This sounds like typical run to completion bug (JS isn't completely paused when sitting at a breakpoint)

Honza