Closed brendankenny closed 1 year ago
cycle through execution contexts for the queries for this kind of audit (probably good in general)
Target manager can listen to Runtime.executionContextCreated
(and keep association with what session/target it came from), and GlobalListeners
gatherer can loop through each when collected the listeners for the main target's window
.
Eventually bfcache failures reasons will cite source locations, which would have really helped here. (@brendankenny could link to it)
cycle through execution contexts for the queries for this kind of audit (probably good in general)
This seems like a good path forward. We will go through just the main frame contexts.
From an issue @rviscomi ran into:
An extension can inject an unload listener into the main frame and the bfcache audit will fail on this reason, but the
no-unload-listeners
audit will pass, and a user looking in the DevTools Elements panel or runninggetEventListeners(window)
in the console will similarly find no'unload'
listeners. This ends up very challenging to debug.To repro:
yarn chrome --port=9222 --enable-extensions
https://chrome.google.com/webstore/detail/hdokiejnpimakedhajhdlcegeplioahd
), ignore the log-in screenhttps://example.com
and run Lighthouse in DevToolsnode cli/index.js https://example.com --port 9222 --view
on the command lineThis is due to the
'unload'
listener being added inside a content script injected ondocument_start
, which runs in an isolated execution context. Unlessno-unload-listeners
starts runningDOMDebugger.getEventListeners
on awindow
reference from the isolated context, those listeners are invisible to the user (similar to how users need to know to pick the other execution context in the DevTools console dropdown forgetEventListeners(window)
to show the injected script'sunload
listeners).Lighthouse could