1039795 - F8 in debugger does not completely stop the world

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Simonas Kazlauskas [:nagisa/:simukis]]

Attachment: Video with behaviour captured

Steps to reproduce:
1. Open http://getbootstrap.com/javascript/#tooltips;
2. Open developer tools’ Debugger;
3. Hover on any of the buttons under “Four Directions”;
4. Click F8 while hovering over the button;

Observe that moving mouse out from the button won’t hide the tooltip – the world for the page has stopped.

Now move the mouse over onto the developer tools (i.e. try opening Inspector tab). Observe tooltip disappearing i.e. world not being reliably stopped.

Video with behaviour attached.

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

I'm pretty sure this is native code that is hiding the tooltip in this case. Can you point to a specific part in the JavaScript code of that page that gets executed?

A JS debugger only blocks JS code from execution, not native code.

Comment 2

[Simonas Kazlauskas [:nagisa/:simukis]]

Attachment: Not-so-minmal test case

I made not-so-minimal test case which still reproduces the issue.

Every time tooltip is hidden at least a little bit of javascript is executed to remove the tooltip element from the DOM. The code which does it is line 315 in the attached file. I added a line above it to modify DOM and display UNIX time into another div so it is more obvious.

The steps to reproduce are the same: open debugger → hover on button → click f8 → move mouse over onto developer tools.

In the ideal case the time should not appear/change and tooltip should not be removed from the DOM.

Comment 3

[Simonas Kazlauskas [:nagisa/:simukis]]

Attachment: Not-so-minmal test case with fixed styles

Comment 4

[Simonas Kazlauskas [:nagisa/:simukis]]

Odd. The case with inlined styles does not work to reproduce the issue (i.e. its behaviour is correct).

Please download attachment #8458063 [details] instead.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: Minimal test case

I've created a minimal test case that reproduces the problem. Still looking into why it happens.

Comment 6

[Panos Astithas (he/him) [:past] (please ni?)]

Forgot to repeat the STR:
1. Open attachment 8458698 [details] in a tab and open the debugger.
2. Go to the events pane and click to break on mouseout events.
3. Move the mouse cursor over the button and hit F8 to pause.
4. Observe that leaving the content window will run the event handler and not pause execution (although I've got a pause at one time).

Comment 7

[Eddy Bruel [:ejpbruel]]

I suspect that this is related to bugs 801304 and 1044074. The gist of those bugs is that nested event loops don't properly suppress all events. Something similar might be going on here.

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

No time for this in the near future unfortunately.

Comment 9

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

I can't reproduce this bug any more.

@JanH: do you still see this?

Honza

Comment 10

[Jan Henning [:JanH]]

No idea. I only added the dependency because the logic for the visual viewport events is basically a copy of the logic for scroll events, but without the changes from bug 1044074 because both things were developed in parallel. As such I'm guessing the changes from bug 1044074 need to be applied to the visual viewport events, too, but I've never tried verifying in how far the visual viewport events might cause problems like this for real.

Comment 11

[Jason Laster [:jlast]]

Lets re-open if we see this behavior in the wild.