| Visibility state is not updated when minimising, obscuring or switching workspaces on Linux | |||||
| Reported by andyearn...@gmail.com, Sep 17 2013 | Back to list | ||||
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1626.0 Safari/537.36 Steps to reproduce the problem: 1. Visit http://jsfiddle.net/abNUu/ 2. Confirm that cycling to another tab and back again will log "hidden", followed by "visible" to the console. 3. With the tab active again, minimise the browser and maximise again. Confirm that neither action caused a new state to be logged to the console. What is the expected behavior? The Page Visibility API specification[1] gives the following as examples that may cause the visibility state to be 'hidden': - The User Agent is minimized. - The User Agent is not minimized, but the page is on a background tab. - The User Agent is about to unload the page. - The User Agent is about to traverse to a session history entry. - The Operating System lock screen is shown. Also, for the document.hidden property: "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." What went wrong? As far as I can tell, Chromium on Linux (unsure about other operating systems) only updates the state when the tab is changed and not for any other reason. Likewise, getting the document.webkitHidden property returns "true" only when the tab is not active in the browser window, but "false" when the browser window is minimised, on another workspace, obscurred by another window, etc. Did this work before? N/A Chrome version: 31.0.1626.0 Channel: dev OS Version: Ubuntu 13.04 Flash Version: Shockwave Flash 11.8 r800 [1]: http://www.w3.org/TR/page-visibility/
Comment 1
by
bro...@gmail.com,
Dec 11 2013
,
Dec 13 2013
Able to reproduce the issue. This is a Non-Regression Issue. Existing from M27 builds. Note: The same behavior is seen in FF and IE also.
,
Dec 17 2013
Moving all non essential bugs to the next Milestone.
,
Mar 3 2014
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
,
Jun 15 2014
This issue is still reproducable in Chrome. Firefox is working just fine. Couldn't confirm for IE.
,
Jan 9 2015
Still a problem and reproducible on Mac OS X's Chromium too. An additional case where the page should be considered hidden is if Chromium is set to full screen and then swiped away in Mac OS X Mountain Lion and Yosemite.
,
Jan 25 2015
I would like to add that on Windows 8.1, both locking the machine (Win-L) and switching window focus (Alt-Tab) do not trigger this event, whereas I'd expect them to. Minimizing the window does fire the event as expected however. I'm running Chrome version 40.0.2214.91 m.
,
Feb 20 2015
Here is a patch: https://codereview.chromium.org/944763002/ It only works for Ubuntu Unity so I'm trying to support GNOME3 and other Linux desktops.
,
Mar 24 2015
Somewhere between Chrome 40 and Chrome 42, this appears to have been fixed for Mac OS X, and surprisingly all bases are now covered, even when the window is obscured by another window. Can someone on the thread verify that this is still broken on Linux?
,
Apr 9 2015
Chrome: 41.0.2272.118 (Official Build) Ubuntu 14.04 fvwm 2.6.5 Minimize/restore: works Switching tab: works Switching workspaces: does not work Covering with opaque window: does not work Switching to a different VT: does not work starting xscreensaver: does not work
,
Apr 10 2015
Version 41.0.2272.118 (64-bit) Mac OS X - minimize doesn't work.
,
Apr 11 2015
#11, it must have been fixed in 42 then.
,
Jun 26 2015
CrOS also has the same issue: https://code.google.com/p/chromium/issues/detail?id=502379
,
Aug 8 2016
Now it works both on Linux and OS X. Closing. |
|||||
| ► Sign in to add a comment | |||||