Closed Bug 449293 Opened 16 years ago Closed 10 years ago

Flash video freezes when browsing a folder (menu) in the Bookmark Bar (and when showing certain other native menus)

Categories

(Camino Graveyard :: Plug-ins, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: ihartchris, Assigned: smichaud)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.2pre) Gecko/2008080500 Camino/2.0a1pre (like Firefox/3.0.2pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.2pre) Gecko/2008080500 Camino/2.0a1pre (like Firefox/3.0.2pre)

I have a couple folders in my Bookmark Bar and when I click on any of them with a flash video playing in the current tab, the video freezes (although the audio continues).

Reproducible: Always

Steps to Reproduce:
1. Have at least one folder in Bookmark Bar
2. Play a video using the flash plug-in
3. Click on the folder in Bookmark Bar
Actual Results:  
Flash video freezes (but its audio continues).

Expected Results:  
Flash video should continue to play.
I can't reproduce this in 2008080200, so either this is a regression since then, it's Intel-only (I'm on PPC), or it's a bug in an older version of the Flash plugin (I have 9.0r124).

cl
Yes I see that issue as well.
With Flash 10b2 d525 /Intel 10.5.4.
So far, I got back to 1.9.0.1pre 2008063022. Looking further in the past as soon as I find the CD with older builds.
Ok, I can repro that as far as the 2006123101 (1.2+) build (but the bug is older). Both Flash 9.0r124 and 10d525.

In older (2007) builds, other steps to see the freeze:
* open the 'About Camino' box and select something in it
* click on any top level menu item

Those steps I can't reproduce in the more recent builds (that changed between build 2007091902 and build 2007092001).

I can't reproduce all this with Gran Paradiso and Minefield builds.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sounds a lot like a missed part of bug 356720/bug bug 338225/bug 395397 (which issues in turn were caused by the threadmanager's appshell rewrite, bug 326273).  Looks like thread manager landed 2006-05-09 or -10.

(In reply to comment #3)
> In older (2007) builds, other steps to see the freeze:
> * open the 'About Camino' box and select something in it
> * click on any top level menu item
> 
> Those steps I can't reproduce in the more recent builds (that changed between
> build 2007091902 and build 2007092001).

That's when bug 356720/bug bug 338225/bug 395397 landed, so it stands to reason  this is something those fixes missed.
Keywords: regression
Works in 2006051001
Fails in 2006051101

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=Camino&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-10+01%3A00&maxdate=2006-05-11+01%3A00&cvsroot=%2Fcvsroot

--> Bug 326273, the new threadmanager (big surprise)

Note that at that time, audio died (after a few seconds) as well, whereas the current state of the bug is only video dies.

In addition to bookmark folders on the Bookmark Bar, I can also trigger video death by:

1) opening any pop-up menu in Camino preferences(!), e.g. the default browser pop-up in General, or the one in the Customize Toolbar sheet

2) opening the search field's menu (e.g., to add  YouTube OpenSearch)

3) opening the back or forward toolbar button's menu

4) opening the tab bar's overflow menu

It's rather bizarre that these random cases are still broken (and that they only stop the video portion); other native context or drop menus don't cause this (nor do in-page <select>s when they pop up a native menu).

Steven, any idea why your appshell rewrite didn't fix this case (and/or why only the video is killed)?  Is this maybe a Core:Plug-ins bug instead?
Summary: Flash video freezes during browsing of a folder (menu) in the Bookmark Bar → Flash video freezes when browsing a folder (menu) in the Bookmark Bar (and when showing certain other native menus)
Version: unspecified → Trunk
(In reply to comment #5)

> Note that at that time, audio died (after a few seconds) as well, whereas the
> current state of the bug is only video dies.

yeah, the audio part stopped 'freezing' between 2007091902 and 2007092001 - see comment 3.

Note that, all the time the flash video continues to load/download (I use a 10 minutes long youTube thingie for testing; the 'loading' progress bar never stopped).

PS - SilverLight2b2 is also affected, based on samples on silverlight.net.

(In reply to comment #5)

> Steven, any idea why your appshell rewrite didn't fix this case
> (and/or why only the video is killed)?

I don't know, but I suspect that my appshell code (and Mats Palmgren's
parallel changes to the Gecko event loop) are (for whatever reason)
simply not being invoked in this case.

This may have something to do with the following difference between an
embedder's event loop (i.e. Camino's event loop) and a non-embedder's
event loop:  In Camino, [NSApp run] is called from NSApplicationMain()
(which is in turn called "automatically" from startup code), while in
non-embedders [NSApp run] is called "explicitly" (in
nsAppShell::Run()) from XRE_main().

In any case, if you run Camino in gdb and break while a Flash movie is
"running" (whether or not the video has stopped as a result of
following one of this bug's STRs), you'll see that Cocoa events are
being processed directly from [NSApp run] (without any trace of the
Gecko event loop on the stack).  But if you run a non-embedder (say
Firefox) in gdb and break while a Flash movie is running (with or
without one of this bug's STRs), you'll see that Cocoa events are
being processed via the Gecko event loop (and via my rewritten
appshell code).

So it's not clear what's causing this bug, or how to go about fixing
it.  Which means that it'll probably be a while before it gets fixed
:-(
These traces may help to pin down the problem.
Assignee: nobody → smichaud
Status: NEW → ASSIGNED
Actually, my traces suggest there may be a bug in the following (undocumented) Cocoa method.  So far I've only tested on OS X 10.5.4.  Could someone test on 10.4.11?

-[NSCarbonMenuImpl popUpMenu:atLocation:width:forView:withSelectedItem:
  withFont:withFlags:withOptions:]
Eiichi, do you see this bug on 10.4.11?
(In reply to comment #11)
> Eiichi, do you see this bug on 10.4.11?

Yes, I can confirm this bug on 10.4.11.
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: