1897187 - visibilitychange event are not reliable for DevTools panel documents

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Nicolas Chevobbe [:nchevobbe][PTO back September 7]]

While investigating Bug 1896461 , I encountered a few issues with the visibilitychange event. We are using it to be able to halt some computation when some panels / the tools are not visible for the users, but the event misbehaves (at least from my testings on osx). On a tab with DevTools docked (no matter to which side) console panel selected:

• visibilitychange is not fired when another DevTools tab is selected (e.g. an iframe is hidden). We are dispatching the event ourselves (https://searchfox.org/mozilla-central/rev/7a8904165618818f73ab7fc692ace4a57ecd38c9/devtools/client/framework/toolbox.js#2794-2819)
• visibilitychange is not fired when another Firefox tab is selected
• visibilitychange is fired when a window is minimized/restored or when exiting screen saver, even when DevTools were opened in another tab than the selected one

---

(I couldn't find existing DOM bugs for this, sorry if this is a duplicate)

Comment 1

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1897187 - [devtools] Expose a notification in the parent process to know when a BrowsingContext becomes active/inactive. r=#dom-core

This is useful for DevTools in order to track the <browser> element activeness
and replicate the activeness on DevTools <browser> element.
As DevTools Frontend code runs in the parent process, we can't easily listen to
tab's 'visibilitychange' event.

Comment 2

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1897187 - [devtools] Use base class for all in-browser hosts. r=#devtools

Comment 3

[Alexandre Poirot [:ochameau]]

Comment 0 is still valid regarding the lack of visibilitychange events following these STR.

But they are missing because Firefox frontend code manually toggles <browser> element's docShellIsActive when moving between tabs.
This is typically set to false from here and to true from here.

It means that DevTools should by some means synchronize tab's <browser> element with DevTools <browser> element's docShellIsActive attributes.
This is what the attached patch queue is about:

• expose a parent process notification so that DevTools can know when the tab's <browser> element changes visibility.
  So that we avoid putting DevTools logic in various places in Firefox frontend. There is a couple of places where we toggle docShellIsActive...
  (* a code cleanup in devtools hosts)
• some logic in devtools to synchronize the docShellIsActive attributes.

Unfortunately I wasn't able to use this attribute for DevTools inner panels and controls their visiblity when switching for example between console and debugger. They are loaded in nested xul:iframe and couldn't manage to have a workable nested top level browsing context for them... It looks like <xul:browser type="content"> nested into another <xul:browser type="content"> doesn't create a nested top level BC.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e9e076423956
https://hg.mozilla.org/integration/autoland/rev/8cc106e2fa14
[devtools] Expose a notification in the parent process to know when a BrowsingContext becomes active/inactive. r=dom-core,smaug
https://github.com/mozilla-firefox/firefox/commit/dcb3d567122c
https://hg.mozilla.org/integration/autoland/rev/2e487d1ee915
[devtools] Use base class for all in-browser hosts. r=devtools-reviewers,jdescottes

Comment 5

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/8cc106e2fa14
https://hg.mozilla.org/mozilla-central/rev/2e487d1ee915