Created attachment 8573883 [details] logNightly.txt Nexus 5/7 with Android 5.0.2 Nightly 39.0a1 (2015-03-05) 1. go to www.intel.com/museumofme 2. tap on the fullscreen button Result: Nightly becomes unresponsive triggering the 'Nightly isn't responding. Do you want to close it?' popup message unable to reproduce on devices with Android < 5.0
Now that bug 1118216 was fixed, this issue is reproducible on Firefox 37 also
I'm tracking 37+ as this issue results in Fennec becoming unresponsive.
Tested on Nexus 5 (Android 5.0.2) and Nexus 7 (Android 5.0.2) and the issue is not reproducing on Firefox 36.0.2 Build2.
Can you still reproduce on Firefox 37.0b6?
I was not able to reproduce this issue on Firefox 37 Beta 4 and Beta 6 on Nexus 5 (Android 5.0.2) and Nexus 7 (Android 5.0.2). However this is still reproducing on latest Aurora and latest Nightly. P.S. This issue does not affect Youtube desktop site, it only affects embed videos.
Mihai, can you find a regression range in 38 where this broke? It's very strange that any recent change could've caused this to show up again. The code in question is *very* racy, though, and it's going to be hard to pretty difficult to fix. What's happening: 1) User presses fullscreen button in Flash plugin instance, and Flash calls anp_window_requestFullScreen() 2) We end up in nsPluginInstanceOwner::RequestFullScreen(), which adds the fullscreen SurfaceView to GeckoApp 3) Gecko returns from nsPluginInstanceOwner::RequestFullScreen(), where Flash then waits on some mutex or semaphore which seems to resolve once the full screen view's surface is created. 3) GeckoApp needs to hide the LayerView, because for some reason the Flash SurfaceView will not display when it's stacked on top of that. 4) When we hide the LayerView, it receives a surfaceDestroyed() callback, and we send a synchronous event to pause the compositor. 5) Since the Gecko thread is stuck in Flash waiting for the fullscreen surface to appear, we are deadlocked. I don't see a super easy solution here. We could preemptively pause the compositor in nsPluginInstanceOwner::RequestFullScreen(), but we'd then need to know that we don't need to send one later on in surfaceDestroyed(). Gross.
Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c5b90c003be8&tochange=993eb76a8bd6
Narrower range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ed1ba3752db1&tochange=591c8d3c3540 I don't see anything obvious.
fx-team regression window: http://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=8d5f10959b2c&tochange=ae4c0736cb3c It's strange, but it seems that has something to do with bug 1138723
Michael, any idea why this could be caused by your patch? Thanks
(In reply to Sylvestre Ledru [:sylvestre] from comment #10) > Michael, any idea why this could be caused by your patch? Thanks Not directly. My best guess is that I omitted <item name="windowActionBar">false</item> from the theme because I didn't think it was used (but I didn't really did into it - silly me!). I had already filed bug 1139248 as a followup to investigate. Here's a test build: https://people.mozilla.com/~mcomella/apks/mcomella-1140359_01.apk Can anyone repro using this build? Catalin? Snorp?
> Here's a test build: > https://people.mozilla.com/~mcomella/apks/mcomella-1140359_01.apk > > Can anyone repro using this build? Catalin? Snorp? I'm still able to reproduce using this build. Tested on Nexus 7 with Android 5.0.2. Test page: www.intel.com/museumofme
(In reply to Michael Comella (:mcomella) from comment #11) > Here's a test build: > https://people.mozilla.com/~mcomella/apks/mcomella-1140359_01.apk To be clear, I added back the removed windowActionBar attribute for this build. My next best guess is there's something in the Material theme that isn't present in the previous themes. It probably has something to do with the new fullscreen APIs that allow drawing under the system status bar and the navigation bar. Leave NI for snorp to see if he has any ideas.
(In reply to Michael Comella (:mcomella) from comment #13) > (In reply to Michael Comella (:mcomella) from comment #11) > > Here's a test build: > > https://people.mozilla.com/~mcomella/apks/mcomella-1140359_01.apk > > To be clear, I added back the removed windowActionBar attribute for this > build. > > My next best guess is there's something in the Material theme that isn't > present in the previous themes. It probably has something to do with the new > fullscreen APIs that allow drawing under the system status bar and the > navigation bar. > > Leave NI for snorp to see if he has any ideas. Yeah, I really have no idea. This code was racy as hell before, so it's not impossible that something seemingly unrelated like this could have caused a problem.
This is too late for 38 but we will be happy to take a patch for 39.
We could still take a patch for this in early beta. snorp is this something you may have time to look into?
(In reply to Liz Henry (:lizzard) from comment #16) > We could still take a patch for this in early beta. snorp is this something > you may have time to look into? No patch yet, but I'm hoping to look at this today.
Don't see this on the support.mozilla.org forums! However the problem reproduces on my Samsung Galaxy 6 Edge and Samsung Galaxy Tablet S 10.4 both on Lollipop. Therefore I would support getting this fixed sooner rather than latter given the fact that the problem happens on a flagship phone and flagship tablet. Rob do we see this in input.mozilla.org?
(In reply to Roland Tanglao :rolandtanglao from comment #18) > Don't see this on the support.mozilla.org forums! However the problem > reproduces on my Samsung Galaxy 6 Edge and Samsung Galaxy Tablet S 10.4 both > on Lollipop. correction: i can't reproduce the problem on the S6 edge but I CAN repro it on the Tab S 10.4 (both on Lolliop)
We do have a few reports of this. Not enough for me to make any claims about a trend: Samsung Galaxy Alpha [might be Lollipop, but could be KitKat]: https://input.mozilla.org/en-US/dashboard/response/5384341 ASUS Zenphone 2 [Lollipop]: https://input.mozilla.org/en-US/dashboard/response/5375348 I'll ping the bug if I see anything else.
Zenphone 2 is x86 and can't run Flash. http://www.asus.com/Phones/ZenFone_2_ZE551ML/specifications/
Snorp, still not too late to take a fix for this for 39 beta, if you have time to work on it. We are heading into beta 4 now. Roland what version of Firefox were you trying on your tablet? Can you see if this affects 40 and 41? Thanks!
(In reply to Liz Henry (:lizzard) from comment #22) > Snorp, still not too late to take a fix for this for 39 beta, if you have > time to work on it. We are heading into beta 4 now. > > Roland what version of Firefox were you trying on your tablet? Can you see > if this affects 40 and 41? Thanks! well this appears to be some sort of heisenbug :-), i can now reproduce the bug on the Samsung S6 edge running Lollipop on all Firefoxen: 1. Firefox 38.0.5 release 2. Fireofox 39 beta 3. Firfox 41 nightly from june 8, 2015 so i take it liz we still don't have a fix for this!
:lizzard I also tested FF38.0.5, 39 beta and 41 nightly on Samsung Tab S 10.4 running Lollipop 5.0 and the problem still reproduces
Roland, thank you for testing! I changed the flags to mark these versions as affected. Wontfix for 39 at this point as we are heading into beta 6 of 7. We can still take a patch for 40. snorp if you disagree and want to get in a fix for this, just let me know.
Snorp, this bug is currently tracking for FF40 release. Are you investigating/working on a fix? If not, could you please help find an owner? Thanks!
We're not working on it. The tracking flags for Fennec doesn't match the tracking-firefox ones.
This bug is now wontfix for 40. Given how long this has been around without blowing up in the wild, I think we can probably stop tracking this.
Snorp, this bug has been around for a few releases now. Tracked since FF38 and Fennec+ too. Do you think the impact is low here and there is no point in tracking it? Or are we planning to fix it in FF41? Appreciate your help here.
I think we can clear the Firefox tracking flags, but lets leave the Fennec one.
Hi, I have a similar issue but it's for the HTML5 videos watched on full screen: I'm using the latest Firefox for android on my Samsung galaxy note 2 10.1“ tab (GT-N8010, Android 4.4.2) and I have the following issue :I open an embedded video in any site, an example - https://vimeo.com/78961286 , play it fullscreen and then when I'm done I'm trying to escape full screen by showing the soft buttons and clicking on the back button but it doesn't work. I'm trying the video player controls, then trying the back button of the tablet but nothing works. The video stays fullscreen and I have to kill the Firefox process and restart the app in order to continue browsing with FF. A similar issue occurs when I'm playing any video even without going into fullscreen mode - in that case I can't navigate away from the video and since it's not fullscreen I can only close the tab and reopen the site to watch other videos. Hope it can be fixed.
Flash is going away (bug 1381916), so there's no point in pursuing this further.