Closed Bug 1043102 Opened 10 years ago Closed 7 years ago

[BrowserAPI] Orientation Management API

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Project Flags:
tracking-b2g +

People

(Reporter: alive, Assigned: wchen)

References

Details

See https://groups.google.com/forum/#!topic/mozilla.dev.webapi/f1kF6O-ypUI

We will need:
mozbrowserorientationlockrequest event
setOrientation method
unsetOrientation method
feature-b2g: --- → 2.2?
Blocks: 1083605
I think we need to rethink if we want to move orientation to per-mozbrowser frame as this bug originally specified.

Reading https://w3c.github.io/screen-orientation/ I found that the API have since changed to async, which means if we route the information to System app main thread, System app should be able to grant/deny orientation on per-request basis*, thus fulfill our use cases.

I also worry that binding orientation management with mozbrowser API will further complicate things and making the scope of this bug bigger than we need.

So if Alive agree with what I said above this bug should be simply converted to implementing the latest spec draft (again, with an additional "chrome"-facing API that route the decision-making to System app).

* the System app obviously need manifestURL to tell which app made the request.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #2)
> * the System app obviously need manifestURL to tell which app made the
> request.

Per offline conversation with Alive, the above assumption is incorrect. We would need to identify the frame where the request is come from, not the app, in order to properly respond to the request (and unlock when the frame is gone).
I think it would be great if we can get together next week in Portland for a quick chat on what we're planning to do here.  It would be great to come up with a plan to fix this issue, and give gaia control over orientation locking.
Me and Alive discussed this in Taipei. Based on that discussion I sent a proposal to the dev-webapi thread linked to in comment 0. Does that proposal not work? I do remember that it relied on updating the orientation API to the latest spec, but that should be fine I hope?
(In reply to Jonas Sicking (:sicking) from comment #5)
> Me and Alive discussed this in Taipei. Based on that discussion I sent a
> proposal to the dev-webapi thread linked to in comment 0. Does that proposal
> not work? I do remember that it relied on updating the orientation API to
> the latest spec, but that should be fine I hope?

I don't see anything wrong with that proposal, but I may be missing some of the requirements.  If both you and Alive think that the proposal is sufficient, then let's find someone to implement it (and the new orientation API too.)
feature-b2g: 2.2? → ---
tracking-b2g: --- → +
not in v2.2 scope, but continue for future release.
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #6)
> (In reply to Jonas Sicking (:sicking) from comment #5)
> > Me and Alive discussed this in Taipei. Based on that discussion I sent a
> > proposal to the dev-webapi thread linked to in comment 0. Does that proposal
> > not work? I do remember that it relied on updating the orientation API to
> > the latest spec, but that should be fine I hope?
> 
> I don't see anything wrong with that proposal, but I may be missing some of
> the requirements.  If both you and Alive think that the proposal is
> sufficient, then let's find someone to implement it (and the new orientation
> API too.)

Alive, do you know if we ever found someone who can implement this proposal?
Flags: needinfo?(alive)
(In reply to Andrew Overholt [:overholt] from comment #8)
> (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
> comment #6)
> > (In reply to Jonas Sicking (:sicking) from comment #5)
> > > Me and Alive discussed this in Taipei. Based on that discussion I sent a
> > > proposal to the dev-webapi thread linked to in comment 0. Does that proposal
> > > not work? I do remember that it relied on updating the orientation API to
> > > the latest spec, but that should be fine I hope?
> > 
> > I don't see anything wrong with that proposal, but I may be missing some of
> > the requirements.  If both you and Alive think that the proposal is
> > sufficient, then let's find someone to implement it (and the new orientation
> > API too.)
> 
> Alive, do you know if we ever found someone who can implement this proposal?

No we don't have a dedicated person on gecko side right now. Appreciate if you could find someone, and I could co-work with him/her in gaia side. Thanks!
Flags: needinfo?(alive)
Blocks: 938035
Assignee: nobody → wchen
William,

Do you need help from Gaia System team to figure out what the system-facing Browser API changes should be?
Flags: needinfo?(wchen)
If there are needs that are not fulfilled by the W3 spec (https://w3c.github.io/screen-orientation), please let me know.
Flags: needinfo?(wchen)
(In reply to William Chen [:wchen] from comment #11)
> If there are needs that are not fulfilled by the W3 spec
> (https://w3c.github.io/screen-orientation), please let me know.

Also me, as I co-edit the spec. Otherwise, just file a bug on the spec - like to the GH repo is in the spec itself.
(In reply to William Chen [:wchen] from comment #11)
> If there are needs that are not fulfilled by the W3 spec
> (https://w3c.github.io/screen-orientation), please let me know.

Also me, as I co-edit the spec. Otherwise, just file a bug on the spec - like to the GH repo is in the spec itself.
(In reply to William Chen [:wchen] from comment #11)
> If there are needs that are not fulfilled by the W3 spec
> (https://w3c.github.io/screen-orientation), please let me know.

I am confused. Are you talking about implementing the web-facing API documented in the spec (and bug 1131470)? That's not this bug per my understanding.

This bug is about enabling B2G System UIs hosted in System app to be able to involved in the decision of whether or not to allow a specific web content to lock the orientation. We had offline chat about getting that API into Browser API; if you have some other ideas please let us know.
Flags: needinfo?(wchen)
See my email here: https://groups.google.com/d/msg/mozilla.dev.webapi/f1kF6O-ypUI/7cN7L8B5pg0J

I think it'll be easier to implement the BrowserAPI for orientation management, if we at the same time also update the orientation API to follow the updated spec. This because the updated spec is more async.
But yes, this bug is about implementing the BrowserAPI extensions needed for Gaia's system app.
In that case, yes, please put me in touch with someone from the Gaia team so I can find out what the requirements are for the browser API side.
Flags: needinfo?(wchen)
The link in comment 15 should describe the requirements. But please do check with Alive (who filed this bug) as well since he'll be the main consumer of the BrowserAPI and so should know the requirements.
It seems to me that the new spec satisfies the points in the post from comment 15, and I haven't heard back about whether there are any additional requirements. In any case, I've moved implementation to bug 1131470 and I'll leave this bug to implement additional browser specific feature (if any).
Quoting from the email linked to in comment 15:

> On the top level mozbrowser API, add the ability to call
> setOrientation("landscape-primary"). This would set the orientation of
> all pages of all pages inside the embedded iframe and its descendants.
...
> We also need to add a "orientationlockrequest" event to the mozbrowser
> API. This event is fired any time a page inside the mozbrowser iframe
> calls "screen.lockOrientation". The event would have a
> `setResult(bool)` function. When setResult(false) is called, we reject
> the promise returned from lockOrientation with a "NotSupportedError"
> error. When setResult(true) is called, we resolve the promise returned
> from lockOrientation.

There's a few more details in the post, but the above is the important parts.
Correct me if I am wrong. We are going to make orientation API being async to be consistent with w3c spec in bug 1131470; then for b2g we will need to route the lock request to gaia system to let it to decide what to happen, or even reject the orientation lock call, in this bug. Also, we need to get and/or set orientation state per browser(tab) to avoid bug 1160660.
Is there any work still happening on this bug?
Flags: needinfo?(wchen)
(William's been out this week but I expect him back around Nov 16)
No plans here
Flags: needinfo?(wchen)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.