917090 - Visibility state is not updated when the browser window is obscured or on another workspace

Status: NEW

(Firefox :: General, defect)

Description

[Andy Earnshaw]

The W3C specification for the Page Visibility API states the following for the document.hidden property[1]:

> On getting, the hidden attribute MUST return true if the Document contained by
> the top level browsing context (root window in the browser's viewport) [HTML5] 
> is not visible at all. The attribute MUST return false if the Document 
> contained by the top level browsing context is at least partially visible on 
> at least one screen.

At least on Ubuntu 13.04 (unsure about other operating systems and currently unable to verify), this only holds true when the tab is not active or the browser is minimised.  In other cases, such as when the lock screen is shown (e.g. by pressing Ctrl+Alt+L) or when the workspace is switched, the document is not visible to the user but the property returns "false".

Lazily "borrowing" a test page created for https://bugzilla.mozilla.org/show_bug.cgi?id=777825, you can verify the issue by visiting http://app1.ianbicking.org/visibilitytest.html and then proceeding to lock the screen, switch workspaces, obscure the window, etc.

[1]: http://www.w3.org/TR/page-visibility/#dom-document-hidden

Comment 1

[Ian Bicking (:ianbicking)]

I believe the specification specifically says you are not supposed to indicate the page is hidden in circumstances when another application has focus and overlaps the window, as this can interfere with complementary applications like screen readers.  In other words the specifically disallows any state change because the window is obscured.  But that wouldn't preclude a hidden state with the lock screen or when switching workspaces.

Mac also does not report any hidden state for a locked screen or changing workplaces.

Comment 2

[Andy Earnshaw]

(In reply to Ian Bicking (:ianb) from comment #1)
> I believe the specification specifically says you are not supposed to
> indicate the page is hidden in circumstances when another application has
> focus and overlaps the window, as this can interfere with complementary
> applications like screen readers.  In other words the specifically disallows
> any state change because the window is obscured.  But that wouldn't preclude
> a hidden state with the lock screen or when switching workspaces.
On the contrary, the spec states in several locations that the document is considered hidden if it is not at least partially visible to the user on any screen. This implies that maximised or large windows completely covering the document should be counted as "hiding" it. 

The exception, as you say, is for accessibility apps such as magnifiers that repaint the document within their own windows. I'm not sure how one would differentiate these, however. I would guess that other types of application may need this exception also, such as a screenshot creator.

Comment 3

[Ioana (away)]

Reproducible on:
Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 (20130924030202)

Comment 4

[Andy Earnshaw]

The event also fails to trigger under the same circumstances in Mac OS X Lion, including where Firefox is set to fullscreen and then swiped away so that it is no longer visible (which is similar to how switching workspaces behaves in some Linux desktop managers).

Comment 5

[:Harald Kirschner :digitarald]

Eric, fyi to analyze and prioritize in the performance backlog. Chrome is working on it for OSX: https://webplatform.news/issues/2019-03-27#web-pages-can-now-detect-when-chrome-s-window-is-covered-by-another-window . This could make a good dent into performance and battery usage, if enough users have Firefox windows open that are covered by other windows – both by applying background throttling to hidden windows but also sites potentially using visibility state for throttling their own code (to be proven how much that adds).

Comment 6

[esmyth]

Harald, thanks for the ping. Taking to investigate.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.