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

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Mike Taylor [:miketaylr]]

Credit to @brianloveswords https://twitter.com/brianloveswords/status/382672513136070656 for reporting this.

Some initial triage here: https://gist.github.com/miketaylr/6694112

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

`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..." :/

Comment 1

[Mike Taylor [:miketaylr]]

Attachment: 2013-09-24 21.21.17.png

Comment 2

[Hallvord R. M. Steen [:hallvors]]

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

Comment 3

[Mike Taylor [:miketaylr]]

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.

Comment 4

[Lawrence Mandel [:lmandel] (use needinfo)]

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.

Comment 5

[Mike Taylor [:miketaylr]]

Unassigned until we decide what we want to do here.

Comment 6

[Jet Villegas (inactive)]

Anne: is window.orientation already on our WebAPI hit list?

Comment 7

[Mike Taylor [:miketaylr]]

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

[Anne (:annevk)]

Jet, I raised it here: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0358.html

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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:

http://www.w3.org/TR/screen-orientation/

Comment 10

[Lawrence Mandel [:lmandel] (use needinfo)]

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?

Comment 11

[Karl Dubost💡 :karlcow]

I wonder what the new products such as the Microsoft surface reacts to window.orientation 
And what is the User Agent for these products.

Comment 12

[Karl Dubost💡 :karlcow]

> 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

[Mike Taylor [:miketaylr]]

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

See https://bugzilla.mozilla.org/show_bug.cgi?id=735494#c4 and https://github.com/jquery/jquery-mobile/blob/master/js/jquery.mobile.support.orientation.js. This is also one of the pain-points for Sencha Touch support, e.g., getWindowOrientation:function(){return window.orientation} in http://extjs.cachefly.net/touch/sencha-touch-2.0.0/sencha-touch-all.js.

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

Comment 14

[Mike Taylor [:miketaylr]]

Going to remove contactready for now, until we have a better idea what we're going to do here.

Comment 15

[Hallvord R. M. Steen [:hallvors]]

> 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.

Comment 16

[Hallvord R. M. Steen [:hallvors]]

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)

or 

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.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 18

[Karl Dubost💡 :karlcow]

@hallvord

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.

Comment 19

[Hallvord R. M. Steen [:hallvors]]

Test fails correctly for me here (I may have fixed it already..)

Comment 20

[Mike Taylor [:miketaylr]]

This is fixed now (by Bug 920734).