If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

F8 in debugger does not completely stop the world

NEW
Unassigned

Status

()

Firefox
Developer Tools: Debugger
P3
normal
3 years ago
2 months ago

People

(Reporter: nagisa, Unassigned)

Tracking

(Depends on: 2 bugs, Blocks: 2 bugs)

33 Branch
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [devtools-platform])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
Created attachment 8457522 [details]
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.
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

3 years ago
Created attachment 8458063 [details]
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.
(Reporter)

Comment 3

3 years ago
Created attachment 8458071 [details]
Not-so-minmal test case with fixed styles
Attachment #8458063 - Attachment is obsolete: true
(Reporter)

Comment 4

3 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

3 years ago
Attachment #8458071 - Attachment is obsolete: true
(Reporter)

Updated

3 years ago
Attachment #8458063 - Attachment is obsolete: false
Created attachment 8458698 [details]
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

Updated

3 years ago
Blocks: 1074448

Updated

2 years ago
Whiteboard: [devtools-platform]
You need to log in before you can comment on or make changes to this bug.