Closed Bug 827042 Opened 7 years ago Closed 7 years ago

[Regression Firefox v17 -> v18] Flash video stop playing if the context menu is visible

Categories

(Core :: Layout, defect)

18 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox18 - ---
firefox19 - ---

People

(Reporter: bugs, Assigned: roc)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

I found a regression between Firefox v17 and v18+.
I have tested it on WinXP and Win7 on five different computers.
It could be that more plattforms (and many users) are affected.

STR
a) open a Flash video in Firefox 17
b) right click into the video (context menu is now visible)
c) video and audio are still playing
d) open the same video in Firefox 18 or higher
e) right click into the video (context menu is now visible)
f) video stop playing but the audio I can still hear
g) if I click outside the flash content (to close the context menu) the video will jump to the "audio time position" and continue to play

I have captured a demo video, where you can see it:
http://youtu.be/KmFHymlh40o
Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/c6970a82a686
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121210 Firefox/20.0 ID:20121210104701
Bad:
http://hg.mozilla.org/mozilla-central/rev/00e26dece6ea
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121210 Firefox/20.0 ID:20121210105701
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c6970a82a686&tochange=00e26dece6ea


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/bb0dbeb26f1d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121209 Firefox/20.0 ID:20121209213450
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b30a1fff2d07
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121209 Firefox/20.0 ID:20121209213651
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bb0dbeb26f1d&tochange=b30a1fff2d07

Triggered by:
1869f4cbee0b	Robert O'Callahan — Bug 785348. Part 1: Track when we've called into plugin code. While we're in plugin code, never run the refresh driver. r=mats


Regression window(beta)
Good:
http://hg.mozilla.org/releases/mozilla-beta/rev/32929d7d0a1f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121208 Firefox/18.0 ID:20121210165657
Bad:
http://hg.mozilla.org/releases/mozilla-beta/rev/58ed9187f536
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121210 Firefox/18.0 ID:20121210181258
Pushlog:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=32929d7d0a1f&tochange=58ed9187f536

Triggered by:
03e46d0d171f	Robert O'Callahan — Bug 785348. Part 1: Track when we've called into plugin code. While we're in plugin code, never run the refresh driver. r=mats,a=lsblakk
Blocks: 785348
Status: UNCONFIRMED → NEW
Component: Plug-ins → Layout
Ever confirmed: true
Keywords: regression
That makes sense.

We could hack around this by avoiding blocking the refresh driver while we process mouse and keyboard input events. But I don't think the behavior in this bug is all that bad.
This was also reported as a Flash 11.5 issue on FF 16 - bug 797830
(In reply to Paul Silaghi [QA] from comment #3)
> This was also reported as a Flash 11.5 issue on FF 16 - bug 797830
That was Flash bug.

This bug is Firefox bug introduced by bug 785348.
Nominating this for tracking Firefox 18 since it's a regression seemingly correlated to fixing bug 785348.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #5)
> Nominating this for tracking Firefox 18 since it's a regression seemingly
> correlated to fixing bug 785348.

Thanks ashughes. Agree with roc in comment 2 that this bug doesn't have significant user impact. We'll definitely get this fixed for FF19, and will consider a fix for an 18.0.1 (if we have one).
Duplicate of this bug: 825172
Attached patch backout patchSplinter Review
I tried backing out bug 827042 with this patch, but it didn't fix the bug. Which is odd.
Assignee: nobody → roc
FYI

Jeromie Clark wrote:

This is expected behavior. 

Managing focus between Flash, the Browser and the Context Menu (particularly in the NPAPI plug-in) created a number of intractable problems related to focus, which negatively impacted player stability.

We ultimately chose to freeze video rendering while the context window was displayed in order to avoid a host of stability problems that were otherwise seeing.  For what it’s worth, this change closed a number of long-standing Mozilla bugs.
Does this behavior start with a specific Flash version? If so, I'd be happy to know which version that is.
WONTFIX based on comment #9. Thanks MrX1980.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Duplicate of this bug: 854470
(In reply to MrX1980 from comment #9)
> We ultimately chose to freeze video rendering while the context window was
> displayed in order to avoid a host of stability problems that were otherwise
> seeing.
What about the sound of the video ? Now it's stopping after ~10s after right clicking on the video. Is it expected ?
Flags: needinfo?(jeclark)
My observation is that this behavior varies by platform.  Given that we feel that playing video for long periods of time with an overlapping context menu open is not a mainstream use-case, it's probably not something we're going to prioritize unless it severely impacted the mainstream user experience in some way.  

Audio continues to play on Mac when the context menu is open, and video rendering resumes in reasonable sync with the position of the audio stream with the context menu is closed.  

On Windows, it looks like audio continues until we hit the end of the buffer, then both audio and video resume from that point when the context menu is closed. 

Given the significant difference between the native Mac and Windows implementations for Firefox, my interpretation is that the developers engaged in the work chose the most sane behavior given the context on that individual platform. 

What there a particular use-case or situation that you feel is severely impacted here that I might not be considering?
Flags: needinfo?(jeclark)
(In reply to Jeromie Clark from comment #14)
> What there a particular use-case or situation that you feel is severely
> impacted here that I might not be considering?
Nothing particular, I was aware of the video freeze, but didn't know exactly what should happen with the audio part. I agree this is not a major issue, but considering it's not reproducible on any other browser (Chrome, Safari, Opera, IE), it could be fixed.
The implementation for Firefox on Windows Vista and higher is actually unique and significantly more complex that the implementation on other platforms.  

See the following for details:  http://blogs.adobe.com/asset/2012/06/inside-flash-player-protected-mode-for-firefox.html

While possible, the change would most likely be non-trivial and I personally feel that the time would be better spent improving the user experience elsewhere.
Duplicate of this bug: 932724
Hello Jeromie,

I am a developer for 8 Ball Pool, a Miniclip game.

You were asking for a particular use-case that can be severely impacted through this bug.
Our game relies on timeout mechanisms to detect when an opponent leaves or is cheating.
A lot of our users are using this flaw to explore this timeout mechanism, causing the opponent to lose the game, because when the context menu is shown, the app freezes and stops sending heartbeats.
Right now we're on a situation where our Firefox userbase is around 20%. In numbers, that represents about 580k unique daily visitors using Firefox (only for this particular game).
Since this is impacting the game experience severely, we are thinking of more drastic measures. We cannot place anything to detect the freeze within the applet, as it's frozen. Our only alternative would be to block the browser, making the game work properly for the other 80% of people.

It would really be a drastic measure for us to do this, but we wouldn't have a choice, as this is impacting our business revenue. I ask you guys to reconsider this, please, as we really like Firefox and a lot of our users do as well.

Thank you.

(In reply to Jeromie Clark from comment #14)
> My observation is that this behavior varies by platform.  Given that we feel
> that playing video for long periods of time with an overlapping context menu
> open is not a mainstream use-case, it's probably not something we're going
> to prioritize unless it severely impacted the mainstream user experience in
> some way.  
> 
> Audio continues to play on Mac when the context menu is open, and video
> rendering resumes in reasonable sync with the position of the audio stream
> with the context menu is closed.  
> 
> On Windows, it looks like audio continues until we hit the end of the
> buffer, then both audio and video resume from that point when the context
> menu is closed. 
> 
> Given the significant difference between the native Mac and Windows
> implementations for Firefox, my interpretation is that the developers
> engaged in the work chose the most sane behavior given the context on that
> individual platform. 
> 
> What there a particular use-case or situation that you feel is severely
> impacted here that I might not be considering?
I've filed a bug on your behalf here: 
https://bugbase.adobe.com/#bug=3657256

It's unlikely that we'll change the behavior with regard to rendering video frames when the context menu is up.  We might be able to do something more clever in the game context (when no video is rendering), but I can't make any promises.

I've opened the bug to the engineering team for investigation.  I suggest we track this as new bug on the Mozilla side as well, as we still feel that the behavior in the video case is preferable to the stability problem that was addressed and short-circuits a bunch of other complexity related to timeline and a/v sync that would be problematic in the video use-case.
Blocks: 920672
Duplicate of this bug: 1054705
You need to log in before you can comment on or make changes to this bug.