F8 in debugger does not completely stop the world

RESOLVED FIXED

Status

defect
P3
normal
RESOLVED FIXED
5 years ago
23 hours ago

People

(Reporter: nagisa, Unassigned)

Tracking

(Depends on 1 bug, Blocks 3 bugs)

33 Branch
x86_64
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [devtools-platform])

Attachments

(3 attachments, 1 obsolete attachment)

Reporter

Description

5 years ago
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.
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.
Reporter

Comment 2

5 years ago
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.
Reporter

Comment 3

5 years ago
Attachment #8458063 - Attachment is obsolete: true
Reporter

Comment 4

5 years ago
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.
Reporter

Updated

5 years ago
Attachment #8458071 - Attachment is obsolete: true
Reporter

Updated

5 years ago
Attachment #8458063 - Attachment is obsolete: false
Posted file Minimal test case
I've created a minimal test case that reproduces the problem. Still looking into why it happens.
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).
Assignee: nobody → past
Status: NEW → ASSIGNED
Priority: -- → P3
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.
No time for this in the near future unfortunately.
Assignee: past → nobody
Status: ASSIGNED → NEW
Blocks: 962491
Depends on: 1044074, 801304
Blocks: dbg-r2c
Whiteboard: [devtools-platform]

Updated

11 months ago
Product: Firefox → DevTools

Updated

5 months ago
Depends on: 1515778
Whiteboard: [devtools-platform] → [debugger-mvp] [devtools-platform]

I can't reproduce this bug any more.

@JanH: do you still see this?

Honza

Flags: needinfo?(jh+bugzilla)

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.

Flags: needinfo?(jh+bugzilla)

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

Status: NEW → RESOLVED
Last Resolved: 23 hours ago
Resolution: --- → FIXED
Whiteboard: [debugger-mvp] [devtools-platform] → [devtools-platform]
You need to log in before you can comment on or make changes to this bug.