Status

()

Core
Widget
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: gal, Unassigned)

Tracking

(Blocks: 4 bugs, {dev-doc-complete})

Trunk
dev-doc-complete
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-kilimanjaro:+, blocking-basecamp:-)

Details

(Whiteboard: [tracker][k9o:p1:fx15], URL)

(Reporter)

Description

6 years ago
Both Gyroscope and Accelerometer APIs are rendered useless in their current state because of web devs inability to stop the content from rotating when the device does. This is a must-fix.
(Reporter)

Updated

6 years ago
Blocks: 673923

Comment 1

6 years ago
I don't quite understand this bug.

Comment 2

6 years ago
There is currently no way to stop the browser to reflow your content after a orientationchange. So when you rotate a mobile device, your content rotates as well. This is often not desired. If you want to use gyroscope information for instance (i.e. to move a ball on a gameboard), your device will switch orientation randomly and there's no way to translate or manage the action.
Version: unspecified → Trunk

Comment 3

6 years ago
This bug is important for phone apps as well.  When you put a phone up to your head it changes to a landscape orientation, making it more difficult to end the call, for example.

I propose we add this to the <meta name="viewport"> tag. Perhaps something like this:

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, orientation=portrait, orientation-lock=yes">

Comment 4

6 years ago
+1. This makes sense. 

However, when cluttering the meta viewport namespace, I vote for the inclusion of a nice JS API to control the meta viewport. Something like

navigator.viewport.orientation = 'portrait';

A simple key/value object like this might just be enough for the job.

Comment 5

6 years ago
We've been thinking about this for iOS too.

Another option we're considering is firing an event after the device orientation has changed but before we rotate the viewport, and allowing the author to preventDefault. Paul's suggestion of a JS flag is also something we're considering - but it would likely be a bitfield of sorts (e.g. supportedOrientations = LandscapeLeft | LandscapeRight)

I think we do need a flag in the meta viewport for setting the initial orientation on launch though. Or maybe a new meta keyword.

Comment 6

6 years ago
+ 1 for firing an event after the device orientation has changed.

Comment 7

6 years ago
Seems like all the good ideas are already there:

preventDefault for orientation change event - this would be the most useful and important imo.

Orientation setters and getters for fine control (and also a way to check what's available).

Meta tags (initial-orientation, orientation-lock) for when you really don't need to rotate the device. Least necessary of all, but nice to have.

I would use every single one the day you would release them - that's how badly we need them.

Comment 8

6 years ago
+1 to the idea of adding a preventDefault() method to the event fired by the orientation change event or to add something in the viewport meta tag to prevent the page from rotating. I also agree with Kamil Trebunia that we should be able to control the device rotation with a setter. This feature is an absolute must-have for game development.

Comment 9

6 years ago
The meta tag + preventDefault() solution feels natural.

In terms of setter API, why not simply have the meta tag's value attribute change kick off the change?
Keywords: dev-doc-needed

Comment 10

6 years ago
Do we have some form of consensus here?

How about an event "orientationwillchange" that is fired before the page rotates? Calling preventDefault() will stop the rotation. The current "orientationchange" event remains the same.

Should these events be prefixed? "mozOrientationWillChange" and "webkitOrientationWillChange" (I don't know there is a tendency to camel case things when they are prefixed)

Next up, a <meta> tag that suggests what the orientation should be. This works fine for pages launched from a home screen of sorts, but I'm not sure what should happen if you visit such a page. Should the browser rotate if the page says it must? That sounds like a possibly confusing user experience.

<meta name="supported-orientations" content="portrait=yes,landscape=no">

available flags are:

portrait
portrait-upside-down
landscape (alias for landscape-left and landscape-right)
landscape-right
landscape-left

(Hopefully they are self-explanatory)

I wonder if we need another meta tag for suggesting a launch orientation?

Lastly, it seems that people think the API to rotating the device via JS should be setting this meta tag. Agreed?

Comment 11

6 years ago
beforeorientationchange would be a more consistent event name.

As an aside, it would be great if these proposals were discussed on a standards list.

Comment 12

6 years ago
(In reply to Anne van Kesteren from comment #11)
> beforeorientationchange would be a more consistent event name.

Sure. That's me thinking Cocoa. 

Also, I forgot to mention the important case of the meta tag: no value means supports all orientations. I don't think we need to add an "all".

> 
> As an aside, it would be great if these proposals were discussed on a
> standards list.

What list? Hopefully one I'm already subscribed to.

Comment 13

6 years ago
Hey Dean,

slight changes:

- beforeorientationchange (I agree with Anne here)

- meta name "orientation" instead of "supported-orientations". I don't think there's need for more verbosity, "orientation" should be pretty self-explanatory imo.

- flags:

portrait
portrait-primary
portrait-secondary
landscape
landscape-primary
landscape-secondary

This works better for tablets and phones that per default are not in portrait (e.g. Motorola Xoom). Not sure if primary/secondary is better, looking forward to more suggestions. window.orientation uses degrees, which I don't think is any better.

- don' think we need a meta tag for launch orientation. If you want to launch in portrait, you set the 'orientation' meta to only portrait. When the page is loaded, you can still use the JS API to override the meta tag. Solves the usecase.

- JS API:

window.lockOrientation()
 -> locks the orientation to the current value in window.orientation, writes to meta tag

window.lockOrientation({ portrait: 1, landscapePrimary: 1 })
-> locks the orientation to the values passed in, changes orientation when the current doesn't match the passed values. Writes to meta tag.

window.releaseOrientation()
-> Removes all orientation locks. Rotates the viewport back to the 'natural' orientation if you're currently locked in. E.g. site is in portrait mode, but phone is held so it would be landscape naturally.

window.changeOrientation would *not* work, as it would result in all weird side effects (you trigger a change, it rotates and then automatically rotates back as the device isn't locked.. etc).

Comment 14

6 years ago
<meta> would be www-style http://dev.w3.org/csswg/css-device-adapt/
beforeorientationchange would be public-geolocation I guess.
Following a discussion on IRC with Anne, it seems that he was confusing deviceorientation and orientation. The former has a spec which is part of geolocation [1] but doesn't fulfill this API goals.

There were a lot of good ideas mentioned in this bug and we should definitely move to a more visible place to continue that discussion. I would suggest DAP WG [2] or www-style. I think DAP would be an appropriate place for the JS API and we should discuss CSS additions in www-style.
For those interested, I might begin a discussion in mozilla's dev-webapi mailing list [3] in the next few days to get some feedbacks.

[1] http://dev.w3.org/geo/api/spec-source-orientation.html
[2] http://www.w3.org/2009/dap/
[3] https://www.mozilla.org/about/forums/#dev-webapi
Summary: API to block orientationchange → screen orientation API (lock, change, ...)
Blocks: 715782
Depends on: 720794
Depends on: 725397
Blocks: 710398
Depends on: 740188
Depends on: 740192
No longer depends on: 725397
Keywords: dev-doc-needed
Summary: screen orientation API (lock, change, ...) → Screen Orientation API
Whiteboard: [tracker]
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Saw the spec, has this landed, didn't see any attachments so I wanted to find out if it's just the specification at the moment?
This is a tracker bug. The feature has landed, see bug 720794 and bug 740188.

Updated

5 years ago
blocking-kilimanjaro: --- → +
Whiteboard: [tracker] → [tracker][k9o:p1:fx15]

Updated

5 years ago
Blocks: 746388

Updated

5 years ago
Blocks: 746446
Depends on: 748183

Updated

5 years ago
Whiteboard: [tracker][k9o:p1:fx15] → [tracker][k9o:p1:fx15][qa+]

Updated

5 years ago
Whiteboard: [tracker][k9o:p1:fx15][qa+] → [tracker][k9o:p1:fx15][qa+:geo]

Updated

5 years ago
Depends on: 760735

Updated

5 years ago
blocking-basecamp: --- → ?
Not blocking on metabugs for Basecamp.
blocking-basecamp: ? → -

Updated

5 years ago
Whiteboard: [tracker][k9o:p1:fx15][qa+:geo] → [tracker][k9o:p1:fx15]
Keywords: dev-doc-needed
This has been documented, some time ago ;-)
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.