Andreas Gal :gal Reporter
	Description • 13 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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 1 • 13 years ago

I don't quite understand this bug.

	Paul Bakaus
	Comment 2 • 13 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.

	Matthew Phillips
	Comment 3 • 13 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">

	Paul Bakaus
	Comment 4 • 13 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.

	Dean Jackson
	Comment 5 • 13 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.

	Wojciech Bednarski
	Comment 6 • 13 years ago

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

	Kamil Trebunia
	Comment 7 • 13 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.

	Andres Pagella
	Comment 8 • 13 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.

	Alex Russell
	Comment 9 • 13 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?

	Dean Jackson
	Comment 10 • 13 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?

	Anne (:annevk)
	Comment 11 • 13 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.

	Dean Jackson
	Comment 12 • 13 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.

	Paul Bakaus
	Comment 13 • 13 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).

	Anne (:annevk)
	Comment 14 • 13 years ago

<meta> would be www-style http://dev.w3.org/csswg/css-device-adapt/
beforeorientationchange would be public-geolocation I guess.

	Mounir Lamouri (:mounir)
	Comment 15 • 13 years ago

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

	Martin Best (:mbest)
	Comment 16 • 12 years ago

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?

	Mounir Lamouri (:mounir)
	Comment 17 • 12 years ago

This is a tracker bug. The feature has landed, see bug 720794 and bug 740188.

	Dietrich Ayala (:dietrich)
	Comment 18 • 12 years ago

Not blocking on metabugs for Basecamp.

	Jean-Yves Perrier [:teoli]
	Comment 19 • 11 years ago

This has been documented, some time ago ;-)