Last Comment Bug 673922 - Screen Orientation API
: Screen Orientation API
Status: RESOLVED FIXED
[tracker][k9o:p1:fx15]
: dev-doc-complete
Product: Core
Classification: Components
Component: Widget (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://dvcs.w3.org/hg/screen-orientat...
Depends on: 720794 740188 740192 748183 760735
Blocks: webapi gecko-games k9o-web-platform 746446 b2g-demo-phone
  Show dependency treegraph
 
Reported: 2011-07-25 07:49 PDT by Andreas Gal :gal
Modified: 2013-08-15 13:52 PDT (History)
47 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
-


Attachments

Description Andreas Gal :gal 2011-07-25 07:49:53 PDT
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.
Comment 1 Olli Pettay [:smaug] (vacation Aug 25-28) 2011-07-25 08:46:47 PDT
I don't quite understand this bug.
Comment 2 Paul Bakaus 2011-07-26 00:35:56 PDT
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.
Comment 3 Matthew Phillips 2011-08-24 04:46:11 PDT
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 Paul Bakaus 2011-08-24 05:10:03 PDT
+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 Dean Jackson 2011-08-24 13:14:29 PDT
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 Wojciech Bednarski 2011-08-25 01:02:34 PDT
+ 1 for firing an event after the device orientation has changed.
Comment 7 Kamil Trebunia 2011-08-25 01:28:20 PDT
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 Andres Pagella 2011-08-26 07:54:11 PDT
+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 Alex Russell 2011-08-26 16:21:05 PDT
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?
Comment 10 Dean Jackson 2011-10-12 17:12:15 PDT
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 Anne (:annevk) 2011-10-12 17:19:29 PDT
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 Dean Jackson 2011-10-12 20:43:25 PDT
(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 Paul Bakaus 2011-10-13 02:06:53 PDT
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 Anne (:annevk) 2011-10-13 02:10:10 PDT
<meta> would be www-style http://dev.w3.org/csswg/css-device-adapt/
beforeorientationchange would be public-geolocation I guess.
Comment 15 Mounir Lamouri (:mounir) 2011-12-28 10:43:20 PST
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
Comment 16 Martin Best (:mbest) 2012-03-30 12:50:24 PDT
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?
Comment 17 Mounir Lamouri (:mounir) 2012-03-30 12:57:58 PDT
This is a tracker bug. The feature has landed, see bug 720794 and bug 740188.
Comment 18 Dietrich Ayala (:dietrich) 2012-07-24 13:12:36 PDT
Not blocking on metabugs for Basecamp.
Comment 19 Jean-Yves Perrier [:teoli] 2013-08-15 13:52:25 PDT
This has been documented, some time ago ;-)

Note You need to log in before you can comment on or make changes to this bug.