Schmap blocks Firefox for Android users from using site (requires window.orientation)



6 years ago
2 months ago


(Reporter: miketaylr, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [clientsniff][country-us] [notcontactready], URL)


(1 attachment)



6 years ago
Credit to @brianloveswords for reporting this.

Some initial triage here:

if (is_iphone || android) {
  var supportsOrientationChange = "onorientationchange" in window,
      orientationEvent = supportsOrientationChange ? "orientationchange" : "resize";
window.addEventListener(orientationEvent, function() {
  if (window.orientation != 0)

`window.orientation` appears to be a webkit-ism, so we fail and they give us a blank page with the following message: This website does not support landscape view. Please turn your phone vertically to continue..." :/


6 years ago
See Also: → 735494

Comment 1

6 years ago
(IMHO this is something we should support in core rather than contacting websites about)

Comment 3

6 years ago
Perhaps we should start a wider discussion on the compat list. Last night I found more than one blog post or stack overflow suggesting using `window.orientation` as a way to detect mobile devices.
Jet, this bug highlights another webkit specific property, window.orientation, that impacts web compatibility. Can you please review for feasibility and practicality of implementing this feature?

Mike/Hallvord - Can you please start a list of non standard properties that impact Web compatibility? Another property that we know of is WebkitPoint.
Flags: needinfo?(bugs)

Comment 5

6 years ago
Unassigned until we decide what we want to do here.
Assignee: miket → nobody
Anne: is window.orientation already on our WebAPI hit list?
Flags: needinfo?(bugs) → needinfo?(annevk)

Comment 7

6 years ago
We have screen.orientation, but that doesn't get us anywhere with window.orientation (/me wonders about a js-shim to map between values...).

Comment 8

6 years ago
Jet, I raised it here:
Flags: needinfo?(annevk)
I don't think we should implement this. Window.orientation is not very useful since it doesn't expose landscape vs. portrait mode, just "default orientation" vs "rotated".

We have implemented screen.orientation instead which at this point is a web standard:
It seems that we have waded into the Web standard vs defacto standard waters again. I tend to side with Web standards unless we have evidence that Window.orientation has substantial use on the mobile Web. Can we scrape some top list of sites to attempt to answer this question?
I wonder what the new products such as the Microsoft surface reacts to window.orientation 
And what is the User Agent for these products.
> Identifying touch-enabled systems
> Internet Explorer 10 introduces the "Touch" UA string token. 
> If this token is present at the end of the UA string, the 
> computer has touch capability, and is running Windows 8 
> (or later). This UA string will be transmitted on a touch-enabled 
> system running Windows 8: 
> Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; Touch)

Comment 13

6 years ago
My hunch is that window.orientation is widely deployed, especially on "WebKit-first" mobile sites and apps. 

See and This is also one of the pain-points for Sencha Touch support, e.g., getWindowOrientation:function(){return window.orientation} in

Do we have any tools like the old Opera MAMA that allow us to grep over a corpus of data?

Comment 14

5 years ago
Going to remove contactready for now, until we have a better idea what we're going to do here.
Whiteboard: [clientsniff][country-us][contactready] → [clientsniff][country-us]
> Do we have any tools like the old Opera MAMA

Compatipede is way better than MAMA now ;-) - this is just to note that bug 920734 is gathering the requested data.
Summary: Schmap blocks Firefox for Android users from using site → Schmap blocks Firefox for Android users from using site (requires window.orientation)
AFAIK we support the proposed standard equivalent, but prefixed: screen.mozOrientation

I don't know how stable the spec is, but I don't like the idea of contacting the site and suggest they add code to use a moz prefixed property. IMO there are two ways to resolve this:

a) We decide we should support window.orientation (pending feedback from Chrome telemetry in bug 920734 - I'm not to optimistic if around 10% of sites we have open bugs for did read window.orientation in my test run, I assume Chrome devs will find too high usage to drop it)


b) We decide that spec is stable enough, un-prefix our screen.mozOrientation and contact Schmap about using it.

I'll label this as notcontactready for now.
Whiteboard: [clientsniff][country-us] → [clientsniff][country-us] [notcontactready]
The new spec is pretty stable at this point, though our implementation lags a bit. Would be great if someone got us up to latest spec.

The test says it is fixed, but it's not. You might have a trigger on displaying content or something like. The first call displays the content and the bogus message.
Flags: needinfo?(hsteen)
Test fails correctly for me here (I may have fixed it already..)
Flags: needinfo?(hsteen)

Comment 20

4 years ago
This is fixed now (by Bug 920734).
Last Resolved: 4 years ago
Resolution: --- → FIXED


2 months ago
Component: Mobile → Mobile
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.