Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008032604 Minefield/3.0b5pre Quicktime plugin stays open and on top of all other tabs. The only way to close the Quicktime popup is to close the Firefox window it self/restarting Firefox. Steps to reproduce: 1. Load http://www.apple.com/macbookpro/features.html 2. Click on any of the images under "Multi-Touch meets MacBook Pro." the fire up the demonstration videos. 3. Hit pause on the right-hand side QT movie player before it the clip has ended. 4. Close the popup. Actual result: The QT portion of the popup stays open and on top of all other tabs. See screenshot
+'ing this so JST can take a look. I see this happening as well.
I'm unable to reproduce this on Windows. Marking Mac only, please speak up if there's anything here pointing at this being on other platforms than the Mac as well.
See also bug 156583 comment 26, bug 403532, and possibly bug 277067. My uneducated guess is that this and bug 403532 are duplicates of bug 156583, now that everyone's on Cocoa.
Successfully reproduced. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5 Macbook Pro, 10.5.2.
I'm claiming this is a mac plugin widget level bug, not something I know the first thing about. Reassigning to Josh. Josh, please pass this along to whomever would be a better owner if you're not the right owner.
Not sure if its the latest nightly, or maybe the new Quicktime update (7.4.5), but I can no longer reproduce this bug. Yay?
Created attachment 313622 [details] screenshot Confirmed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040404 Minefield/3.0pre Some Notes to the steps to reproduce: - I was not anytime able to reproduce this when i opened the quicktime links in a new tab - but i was able to reproduce this anytime when i used the popup's when i click on one of this images on http://www.apple.com/macbookpro/features.html like described inb comment #0 - In difference to comment #0 i was also only able to see this wrong quicktime image only on the next tab i used, this problem was also gone when i was going back to this back (like going to another tab and back) Maybe a refresh problem ?
(In reply to comment #8) > - In difference to comment #0 i was also only able to see this wrong quicktime > image only on the next tab i used, this problem was also gone when i was going > back to this back (like going to another tab and back) That's consistent with the behavior we typically saw in Camino in bug 156583, although the persistence did vary somewhat depending on the phase of the moon. :P
Over to Matthew Gregan for a bit, he said he'd take a look. I'll take it back if necessary when my other blockers are done.
FWIW this looks like just a painting bug. We don't redraw on the new tab, and if you scroll we'll draw the right thing when you scroll back. So for some reason the quicktime is drawing once on top of the new tab.
This is ugly but easily worked around (close the popup window, navigate through tabs) so I'd love a fix but not clear we should block on this...
See Comment #7. Was anyone able to reproduce this after the Quicktime update?
Created attachment 314787 [details] testcase Open the testcase, then switch to another tab, the plugin content will draw over the top of the other tab's content every time for me. The fact that the plugin is position:fixed and positioned seems to make a difference, if I remove the fixed position div containing it, I can only reproduce the problem sometimes. And yes, I still see the bug with QT 7.4.5 on Leopard.
What's happening here is that we don't notify the plugin that it is no longer visible until too late. When switching tabs, we don't call SetWindow with a zero sized clip rect. This does happen the next time the idle event timer fires for the plugin, but by then it is too late. What ends up happening is: 1. Switch tabs 2. We paint the content area of the new tab 3. The plugin happens to paint again (and does so over the top of the new tab content) 4. The idle timer fires and calls SetWindow with a zero sized clip rect Once #4 occurs, the plugin will no longer paint, but we don't repaint the area the plugin has clobbered until something forces that area to be invalidated, e.g. changing window focus, scrolling, or switching tabs. There's a chance that the idle timer fires before we paint the new tab content, in which case the plugin does not paint over the top of us.
Which makes this a duplicate of bug #277067.