W3C home > Mailing lists > Public > public-device-apis-log@w3.org > November 2016

[sensors] Issues caused by visibility state restriction semantics

From: Rick Waldron via GitHub <sysbot+gh@w3.org>
Date: Wed, 02 Nov 2016 15:21:57 +0000
To: public-device-apis-log@w3.org
Message-ID: <issues.opened-186831730-1478100111-sysbot+gh@w3.org>
rwaldron has just created a new issue for 
https://github.com/w3c/sensors:

== Issues caused by visibility state restriction semantics ==
> When the visibility state of the Document in the top-level browsing 
context changes, let current_visibility_state be the result of running
 the steps to determine the visibility state of the Document. If 
current_visibility_state is "visible", enable the sensor task source, 
otherwise, disable it.

This was added as a result of the conversation that took place in this
 issue: https://github.com/w3c/sensors/issues/81

This is problematic, consider these two use cases: 

- A fitness tracking application: I open the web app on my phone and 
hit "start tracking"; the accelerometer and gyroscope start emitting 
data to the app. Then I put the app in the background and open spotify
 to select music for my run—and off I go. None of my steps are 
recorded because the app wasn't "visible". 
- A map-centric application: I open the web app on my phone and enter 
my destination. A geolocation sensor finds my current location and I 
hit "Walking Directions From Here". A set of possible ways to walk 
appears and from the results, I select the best way to my destination 
and hit "Navigate". The app's text to speech starts telling me which 
way to go. I'm on my way! Down the block I have to wait for a "Walk" 
signal at the intersection, so I switch to another browser window 
"tab" to check my email. The map application is no longer tracking me 
because the gps and magnetometer stopped when the app wasn't 
"visible".


These are only two examples, but they describe things that native 
applications can take for granted, and capabilities that web 
applications must have to be a desirable target platform. If Generic 
Sensor defines this behavior, it should do so in way that makes it 
clear that the behavior can be overridden. 


----------------

To make sure I understood how browsers were implementing 
`document.visibilityState` semantics, I reviewed and observed the 
following: 

- Brave 0.12.7 (Desktop)
  - visibility changes when tab focus changes, not application focus
- Chrome  54.0.2840.71 (Desktop)
  - visibility changes when tab focus changes, not application focus
- Chrome  54.0.2840.68 (Android)
  - **visibility changes when tab focus and application focus 
changes**
- Firefox 51.0a2 (Desktop)
  - visibility changes when tab focus changes, not application focus
- Microsoft Edge
  - visibility changes when tab focus changes, not application focus
- Mobile Safari
  - **visibility changes when tab focus and application focus 
changes**
- Safari
  - visibility changes when tab focus changes, not application focus  



Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/149 using your GitHub account
Received on Wednesday, 2 November 2016 15:22:04 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:52 UTC