Closed Bug 1318293 Opened 3 years ago Closed 3 years ago

Deviceorientation events no longer working for Firefox Android


(Firefox for Android :: General, defect)

49 Branch
Not set



Tracking Status
blocking-fx --- ?
fennec 54+ ---


(Reporter: electroteque, Assigned: droeh)


(Keywords: DevAdvocacy, platform, regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce:

Samsung S3  Android 6
Samsung S4 - Android 5

 window.addEventListener( 'deviceorientation', function(event) {
        var log = document.getElementById("log");
        console.log("deviceorientation ", event);
    }, false );

Actual results:

Since the orientation data changes both Firefox stable and nightly have broken deviceorientation events. These events used to function and now do not. Other people are experiencing the same issue on a Samsung S4 and some other phones. 

Expected results:

deviceorientation event should be dispatching.
This demo doesn't work

These people complaining also. Definite regression and a bizarre one.
I made a quick demo using webvr control functions. 

In Firefox stable it uses the deprecated api. the values there are all empty too which used to work before so possibly related to this. 

In Firefox nightly it seems to use Web VR1 but no display is available for cardboard mode, similar to Chrome sadly.
Confirming, as I've been trying to track this down too, when I noticed orientation support was broken in A-Frame.

I narrowed the regression to first-broken in Firefox 51 (current beta version). Both 49 and 50 (current release version) work fine.

I tried using mozregression to narrow further but am getting errors - it cannot install the apks.

However, I'm not sure it's Firefox Android:

* works in release (49) and beta (50) on Android, but broken on aurora (51) and nightly (52)

* works on all channels*.

(* I've noticed in Nightly that sometimes that latter URL works for a while but then sometimes stops working.)
Ever confirmed: true
I have firefox stable 49 on Android 6. I'll have to confirm what the go is with the Samsung S7.
OK this is going to do people's heads in. So Nexus supoosably gets the event dispatched according to another ticket. I have just got confirmation the event is being dispatched on a Samsung S7, same version number 49.0.2
Thanks so much Sorina! Super helpful.

Kip, any idea if these could've caused this regression? or some interaction between these changes and A-Frame's use of the orientation API on mobile?

ec7229cceafc	kearwood — Bug 1250244 - Part 9: Update test_interfaces.html,r=bz
cc38fe6bde47	kearwood — Bug 1250244 - Part 8: Implement WebVR DOM Events,r=bz
7b1349cb7487	Kearwood (Kip) Gilbert — Bug 1250244 - Part 7: Implement WebVR 1.0 API,r=bz
a4140fefc590	Kearwood (Kip) Gilbert — Bug 1250244 - Part 6: Replace VRStateValidFlags with VRDisplayCapabilityFlags,r=gw280
6dddf6d0a9f6	Kearwood (Kip) Gilbert — Bug 1250244 - Part 5: Rename VRDevice to VRDisplay,r=bz
320c566370cc	Kearwood (Kip) Gilbert — Bug 1250244 - Part 4: Remove Cardboard VR Support,r=gw280
a7f822e39e67	Kearwood (Kip) Gilbert — Bug 1250244 - Part 3: Remove Oculus 0.5 Runtime support,r=gw280
80977f3eaea6	Kearwood (Kip) Gilbert — Bug 1250244 - Part 2: Remove old VR rendering paths,r=gw280
d055dafd4a32	Kearwood (Kip) Gilbert — Bug 1250244 - Part 1: Remove FullScreenOptions parameter from Element.RequestFullScreen,r=bz
Flags: needinfo?(kgilbert)
Bug 1250244 removes Cardboard VR support (patch 4), which breaks support for
This change does not affect the DOM "deviceorientation" events.
Eugen why was Cardboard support removed from Web VR 1 ? 

I don't use polyfills because they are extremely bloaty if it can do it internally why not.

What I have to do is if WebVR 1 support is available try that, then if no display is available fallback to Three.js stereoeffect/cardboard distortion and deviceorientation. 

It is this deviceorientation which has stopped dispatching events, it is working on Chrome. I'm sure the orientation data has been fixed up, as it was using old Android api's right ? 

I have to do something similar for Chrome. It will detect a Cardboard display but it's canPresent capability is disabled so it's not usable either ! 

The point of removal is here

I had no idea and made a bug ticket about just that
(In reply to Daniel from comment #9)
> Eugen why was Cardboard support removed from Web VR 1 ?

Sorry, I wasn't involved with the WebVR implementation, Kip should be able to answer that.
The removal of native WebVR support for cardboard should not have affected the deviceorientation API.  This support had not provided any benefit over the polyfills for Cardboard in terms of latency or rendering performance.  WebVR's optimized rendering path is being updated to support more platforms, such as OSX and Linux.  At that point, it would be worth re-enabling this on Android / Cardboard to bring these benefits to mobile.  A more detailed roadmap with a timeline will be made public shortly.
Flags: needinfo?(kgilbert)
Ok not a problem. I commented back on the other ticket. 

Hopefully the events can be dispatched appropriately again soon.
tracking-fennec: --- → ?
Assignee: nobody → droeh
tracking-fennec: ? → 50+
Summary: Deviceorientation events no longer working for Firefox Android → Cardboard support removed in Firefox for Android
Assignee: droeh → nobody
Hi that issue has nothing to do with this in fact, the polyfill would also be affected because of this ticket. 

I don't use the polyfill because it's severely bloaty. I am using three.js features directly however. 

As far as WebVR fallback goes I am already doing this also. It's not just an empty display that is an issue, Chrome reports of a Cardboard display but has presenting disabled. That has to be taken into account also then do a fallback.
First, happy new year and thank you to the generous developers !
I also confirm that 'deviceorientation' event are never fired.
My platform:
Firefox for Android 50.1.0 
Android 4.1.2
LG E440

Thank you in advance for any help on that subject,

Kind regards,
This was intended? 
Bug 1250244 - Part 4: Remove Cardboard VR Support,
(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #17)
> This was intended? 
> Bug 1250244 - Part 4: Remove Cardboard VR Support,

From the various reports, it may or may not be related. It is unclear at this point.

Orientation in the basic Hello World example of A-Frame is functional on Firefox Android up to 53 (currently Beta). From 54 (currently Aurora) onward it no longer is functional.
Duplicate of this bug: 1356921
Adding the DevAdvocacy keyword as we've got duplicates filed, threads on Reddit and StackOverflow.

Tim, who's the right person to evaluate and prioritize this so we don't ship a Firefox Android with orientation broken?
Flags: needinfo?(timdream)
Keywords: DevAdvocacy
I am confused. 

- Up until comment 5 this bug is talking about deviceorientation event being broken.
- Regression window was identified on comment 6.
- On comment 7 it was asked if WebVR changes breaks things. On comment 11 :Kip said no.
- However between comment 13 and comment 14 the bug summary was suddenly changed.

snorp, what prompted the change? If that's simply because a misread of the bug, let's go back to comment 6 and take a look other possible regressed bugs. I can see bug 1292323 changed WrapForJNI a bit. And bug 1255628. It would be great if we have some CI to safe guard this too.
blocking-fx: --- → ?
Flags: needinfo?(timdream) → needinfo?(snorp)
Summary: Cardboard support removed in Firefox for Android → Deviceorientation events no longer working for Firefox Android
I think I was also confused on this bug, but it's clear now that we're just talking about the deviceorientation events. Dylan, you've looked at this before, can you please figure out what's going on?
Assignee: nobody → droeh
tracking-fennec: 50+ → 54+
Flags: needinfo?(snorp) → needinfo?(droeh)
It looks like WindowCannotReceiveSensorEvent is returning true for (some?) orientation events; specifically, disabled = !principal->Subsumes(topPrincipal); (line 248 of nsDeviceSensors.cpp for me) seems to be the sticking point. I'm not really familiar with nsIPrincipal, but I'll continue to investigate.
Flags: needinfo?(droeh)

(In reply to Daniel from comment #0)

This works for me on nightly.

(In reply to Daniel from comment #1)
> This demo doesn't work
> These people complaining also. Definite regression and a bizarre one. 
> firefox_on_android_device_orientation/

Both the example and the example from the reddit thread are broken due to a permissions issue -- it looks to me like we are wrongly deciding things are backgrounded when they aren't. Filed as a separate bug (bug 1358506). I doubt it's specific to deviceorientation, we just (embarrassingly) happen to have a broken example on that uses this sensor event.

(In reply to Dietrich Ayala (:dietrich) from comment #3)
> * works in release (49) and beta (50) on Android,
> but broken on aurora (51) and nightly (52)
> * works on all channels*.

The aframe example is broken due to dropped WebVR support, it would seem. The other, as you said, works fine.

Ultimately I don't think deviceorientation is broken in general: the deviceorientation example on is broken due to a change in how we handle permissions for device sensor events, but sensor events (including orientation) are working fine otherwise as far as I can tell. If anyone has other examples of deviceorientation brokenness on nightly, please post them; otherwise I think we can resolve this.
So the orientation api definitely working again in Firefox ? 

like here ?

I'll spend some time testing it again with / without webvr.
Flags: needinfo?(electroteque)
(In reply to Daniel from comment #26)
> So the orientation api definitely working again in Firefox ? 
> like here ? 
> I'll spend some time testing it again with / without webvr.

I see "deviceorientation" on the page and get the deviceorientation messages in the console, which seems to be the expected behavior.
Alright, looks like we can close this.
Closed: 3 years ago
Resolution: --- → INVALID
Guys, I just downloaded the last version of nightly and orientation DOES NOT WORK. I tryed the demo file up there, and it is never notified. Please, the last version with this feature is 46.0a1. That's 2016 :(
Flags: needinfo?(droeh)
Can you specify which demo (multiple are linked in the comments) you think is broken, what behavior you're expecting, and what behavior you're actually seeing? Thanks.
Flags: needinfo?(droeh)
Sorry Dylan, I should mention which demo. This simple one:

The expected behaviour is that the listener to the "deviceorientation" event is triggered. But it is never called.

Flags: needinfo?(droeh)
Alright, I tried that with my own build and the latest nightly build and see the device orientation as expected. Maybe there's something device-specific going on here? What phone/phones are you testing on?
Flags: needinfo?(droeh)
I follow the same steps as in v 46.0a1. I just install the .apk, then I open the apps administration to check all the permissions for nightly (in Android 6.0) and finally I open the browser and navigate to that demo. It is not working in my case. I am using a Huawei ALE-L23 (known as P8). Thanks for your time
Flags: needinfo?(droeh)
Is it a regular P8 or a P8 Lite? If it's a P8 Lite, it looks like it doesn't have a gyroscope (see,Huawei%20P8/phones/9358,9127 under "Sensors"), in which case I wouldn't expect deviceorientation events to fire. I'm not sure why it would've worked on older versions, though.
Flags: needinfo?(droeh)
Dylan, I have the Lite version but if I use an old version or the current version of Firefox for Android, the event fires the listener. And it is not a "random number", I'm playing this game in Chrome and FFX 46 ->
Flags: needinfo?(droeh)
The lack of "deviceorientation" events on devices without gyroscopes looks like a real regression, but unrelated to this bug. I've reopened bug 1356921 and will handle it there.
Flags: needinfo?(droeh)
You need to log in before you can comment on or make changes to this bug.