API for "home screen" app locking display, listening for "wake up" button, etc.

RESOLVED WORKSFORME

Status

()

Core
General
RESOLVED WORKSFORME
6 years ago
5 years ago

People

(Reporter: cjones, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sec-assigned:curtisk:749365])

There are two main use cases I know of for such an API

 (1) Allow a "home screen" app to lock the screen and disable button input, turn off the display, listen for a "user tried to wake up" notification, and turn on the display + unlock the screen/buttons.

 (2) Allow games/dialer/etc. to prevent the display from going to sleep in the middle of something important.

This API is quite exploitable, so needs to be privileged and not allowed by default.  It's also vulnerable to accidental DoS, e.g. someone navigates away from a page that locked input but didn't set up a matching unlock, so the UA will need to make sure these things are automatically released.  Could maybe fold into whatever provisions we already have for releasing things like keyboard-input focus on navigation.

Comment 1

6 years ago
This sounds interesting. As a first step, I'd be much more interested if things like "user triggers sleep button" would fire events so devs could have a short timeframe to do whatever they need to do (like when exiting iOS apps, they have a couple ms to save stuff). Something like "onbrowserpause". I think we have a separate ticket for this one though.
Duplicate of this bug: 681455

Comment 3

6 years ago
(In reply to Paul Bakaus from comment #1)
> This sounds interesting. As a first step, I'd be much more interested if
> things like "user triggers sleep button" would fire events so devs could
> have a short timeframe to do whatever they need to do (like when exiting iOS
> apps, they have a couple ms to save stuff). Something like "onbrowserpause".
> I think we have a separate ticket for this one though.

I like the idea of an "onBrowserPause" and "onBrowserResume" events, similar to how many mobile devices handle such events (Windows Phone, Android, and iOS, to name a few).

However, I'm not sure if we need to "prevent" sleeping.  If there's no input after X amount of time, the device usually sleeps.  In what instance would somebody *not* want that to happen?  Unless a video is playing, in which case browsers usually can detect that behavior, and react appropriately.  This is something that could be too easily abused.

The only addition I think that we should implement are the pause/resume events that Paul suggested.

Comment 4

6 years ago
(In reply to Paul Bakaus from comment #1)
> This sounds interesting. As a first step, I'd be much more interested if
> things like "user triggers sleep button" would fire events so devs could
> have a short timeframe to do whatever they need to do (like when exiting iOS
> apps, they have a couple ms to save stuff). Something like "onbrowserpause".
> I think we have a separate ticket for this one though.

Sorry, I just checked, bug #674701 basically wants the same thing.
>  (2) Allow games/dialer/etc. to prevent the display from going to sleep in the middle of something 
> important.

This is orthogonal; let's do it separately.
Summary: API for screen/power management → API for "home screen" app locking display, listening for "wake up" button, etc.
(In reply to Justin Lebar [:jlebar] from comment #5)
> >  (2) Allow games/dialer/etc. to prevent the display from going to sleep in the middle of something 
> > important.
> 
> This is orthogonal; let's do it separately.

If you open a bug for power management, could you mention it here? (or just clone this one)
Filed bug 697132.
Blocks: 715782
Keywords: sec-review-needed
assinged to me for sec action to schedule a meeting
Whiteboard: [secr:curtisk]
Depends on: 749365
Whiteboard: [secr:curtisk] → [sec-assigned:curtisk:749365]

Updated

5 years ago
Blocks: 715784

Updated

5 years ago
No longer blocks: 715782
This work is covered by other bugs -> WFM. Reopen if these other pieces don't surface or don't meet the original report.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
Flags: sec-review?(curtisk)
dveditz - clee closed the secreview bug as invalid, do we still need to do any kind of review here?
Flags: needinfo?(dveditz)
This got chopped up into other APIs/bugs and covered there.
Flags: sec-review?(curtisk)
Flags: needinfo?(dveditz)
You need to log in before you can comment on or make changes to this bug.