Firefox android unresponsive if playing certain flash video in full screen on Lollipop

RESOLVED WONTFIX

Status

()

Firefox for Android
Plugins
RESOLVED WONTFIX
3 years ago
4 months ago

People

(Reporter: csuciu, Assigned: snorp)

Tracking

(Blocks: 1 bug, {regression})

39 Branch
ARM
Android
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox36 unaffected, firefox37 unaffected, firefox38 wontfix, firefox38.0.5 wontfix, firefox39 wontfix, firefox40 wontfix, firefox41 affected, firefox42 affected, fennec+)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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

Updated

3 years ago
Component: General → Plugins

Updated

3 years ago
tracking-fennec: --- → ?
Assignee: nobody → snorp
tracking-fennec: ? → +
Blocks: 1030897
(Reporter)

Comment 1

3 years ago
Now that bug 1118216 was fixed, this issue is reproducible on Firefox 37 also
status-firefox37: --- → affected
I'm tracking 37+ as this issue results in Fennec becoming unresponsive.
tracking-firefox37: --- → +
tracking-firefox38: --- → +
tracking-firefox39: --- → +

Comment 3

3 years ago
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.
status-firefox36: --- → unaffected
Can you still reproduce on Firefox 37.0b6?
Flags: needinfo?(mihai.g.pop)

Comment 5

3 years ago
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.
status-firefox37: affected → unaffected
Flags: needinfo?(mihai.g.pop)
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.
Flags: needinfo?(mihai.g.pop)
Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c5b90c003be8&tochange=993eb76a8bd6
Flags: needinfo?(mihai.g.pop)
Narrower range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ed1ba3752db1&tochange=591c8d3c3540

I don't see anything obvious.

Comment 9

3 years ago
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
Blocks: 1138723

Updated

3 years ago
Summary: Nightly becomes unresponsive if playing certain flash video in full screen → Nightly becomes unresponsive if playing certain flash video in full screen on Lollipop
status-firefox40: --- → ?
tracking-firefox40: --- → +
Michael, any idea why this could be caused by your patch? Thanks
Flags: needinfo?(michael.l.comella)
Summary: Nightly becomes unresponsive if playing certain flash video in full screen on Lollipop → Firefox android unresponsive if playing certain flash video in full screen on Lollipop
(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?
Flags: needinfo?(snorp)
Flags: needinfo?(michael.l.comella)
Flags: needinfo?(catalin.suciu)
(Reporter)

Comment 12

3 years ago
> 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
Flags: needinfo?(catalin.suciu)
(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.
Flags: needinfo?(snorp)
This is too late for 38 but we will be happy to take a patch for 39.
status-firefox38: affected → wontfix
We could still take a patch for this in early beta. snorp is this something you may have time to look into?
Flags: needinfo?(snorp)
(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.
Flags: needinfo?(snorp)
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?
Flags: needinfo?(rrayborn)
(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)

Comment 20

3 years ago
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.
Flags: needinfo?(rrayborn)
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!
Flags: needinfo?(snorp)
Flags: needinfo?(rtanglao)
Keywords: regression
(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
Flags: needinfo?(rtanglao)
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.
status-firefox38.0.5: --- → wontfix
status-firefox39: affected → wontfix
status-firefox40: ? → affected
status-firefox41: --- → affected
tracking-firefox41: --- → +
Flags: needinfo?(snorp)
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!
Flags: needinfo?(snorp)
We're not working on it. The tracking flags for Fennec doesn't match the tracking-firefox ones.
Flags: needinfo?(snorp)
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.
status-firefox40: affected → wontfix
status-firefox42: --- → affected
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.
Flags: needinfo?(snorp)
I think we can clear the Firefox tracking flags, but lets leave the Fennec one.
tracking-firefox37: + → ---
tracking-firefox38: + → ---
tracking-firefox39: + → ---
tracking-firefox40: + → ---
tracking-firefox41: + → ---
Flags: needinfo?(snorp)

Comment 31

2 years ago
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.

Comment 32

4 months ago
Flash is going away (bug 1381916), so there's no point in pursuing this further.
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.