Closed Bug 1657059 Opened 4 years ago Closed 3 years ago

Blank browser toolbox "windowGlobal is null from frame-helper.js"

Categories

(DevTools :: Framework, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED INACTIVE

People

(Reporter: jdescottes, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

While trying to reproduce issues with MBT, I was trying to open the Browser Toolbox while tabs were loading. I have had several instances of a blank toolbox with the following log:

console.error: 
"Exception while opening the toolbox" 
"
  Error: Protocol error (TypeError): can't access property \"browsingContext\", 
  windowGlobal is null from: server11.conn0.watcher23 
  (resource://devtools/server/actors/descriptors/watcher/target-helpers/frame-helper.js:253:27)
" 

I seem to get it regularly with the following STRs:

  • open a tab to https://www.leboncoin.fr/
    (I click on the link from the about:newtab suggestions, clean profile, probably geolocalized though)
  • immediately after that, while the tab loads, open the MBT

The stack that leads to the error is:

shouldNotifyWindowGlobal@resource://devtools/server/actors/descriptors/watcher/target-helpers/frame-helper.js:257:17
getFilteredRemoteBrowsingContext/<@resource://devtools/server/actors/descriptors/watcher/target-helpers/frame-helper.js:182:29
getFilteredRemoteBrowsingContext@resource://devtools/server/actors/descriptors/watcher/target-helpers/frame-helper.js:181:5
createTargets@resource://devtools/server/actors/descriptors/watcher/target-helpers/frame-helper.js:24:60
watchTargets@resource://devtools/server/actors/descriptors/watcher/watcher.js:140:30

From what I can see, we get the errors because of "temporary" iframes. For instance, one of them is used to perform a oauth2 autentication and is later discarded.

If I bail from shouldNotifyWindowGlobal when windowGlobal is null, the Browser Toolbox loads, but the website is no longer usable (cannot click anywhere etc...) until the BrowserToolbox is closed. As if we were pausing a thread and not resuming it.

There is also very frequently an error about preNest/windowUtils:

DBG-SERVER threw an exception: SecurityError: Permission denied to access property "windowUtils" on cross-origin object
Stack: preNest@resource://devtools/server/actors/utils/event-loop.js:157:31
enter@resource://devtools/server/actors/utils/event-loop.js:76:30
_pushThreadPause@resource://devtools/server/actors/thread.js:314:15
onAttach@resource://devtools/server/actors/thread.js:466:12
onPacket@resource://devtools/server/devtools-server-connection.js:379:58
receiveMessage@resource://devtools/shared/transport/child-transport.js:66:16

Fixing it doesn't avoid blocking the page either.

Edit: I confirmed that attaching the thread is responsible for blocking the page https://searchfox.org/mozilla-central/rev/72a1334982cadde0ca8b3d3583877afea80f5639/devtools/client/framework/toolbox.js#780-820

See Also: → 1657194

The severity field is not set for this bug.
:ochameau, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(poirot.alex)
Severity: -- → S2
Flags: needinfo?(poirot.alex)

This sounds like a thread actor deadlock issue.
They ahve been improved by Bug 1682780 and should happen less frequently.
As a matter of fact I can't repro with the initial STRs, so lowering to S3.

Let's block this on Bug 1678741 which is about fixing all the potential thread actor deadlocks.

Severity: S2 → S3
Depends on: 1678741
See Also: → 1682780

This might be fixed by work done in Bug 1120863 - Browser toolbox starts blank and doesn't function with pending updates

Feel free to reopen if you are still experiencing this issue.

Honza

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INACTIVE
See Also: → 1120863
You need to log in before you can comment on or make changes to this bug.