156583 - Stray QuickTime, Real, or Java plugin frame can appear after switching to another tab

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P2)

Description

[Chris Petersen]

Build: 2002-07-09-05 NB
Platform: OS X 10.1.5
Expected Results: No stray movie frames should appear in another tabbed page
What I got: While playing a QT movie , switching to another tab results in a
single movie frame stamped on tabbed page.

Steps to reproduce:

1) Go to url
2) Create a new tab
3) Switch back to first tab and click movie to start it.
4) As movie starts to play, switch to second tab.
5) Notice , a single still frame appears in the second tabbed page.

Comment 1

[Greg K.]

Confirmed using Chimera/20020708, except that not just one frame appears in the
other tab; the movie plays continuously in the other tab.

I'm pretty sure this is a duplicate; adding qawanted.

Comment 2

[Chris Petersen]

This bug is a offshoot of http://bugzilla.mozilla.org/show_bug.cgi?id=147902
which has been fixed. That bug would show flash and qt movies on other tabbed
page. There is a slight paint issue now with QT movies and tabs which is
mentioned in this report. Resizing the window will take care of the problem for
now. 

Comment 3

[Chris Petersen]

Tested with Chimera 2002-07-10-05 NB.

Comment 4

[saari (gone)]

->bnesse, the quicktime plugin frame overdraw issue

Comment 5

[Brian Nesse (gone)]

*** Bug 161558 has been marked as a duplicate of this bug. ***

Comment 6

[Simon Fraser [no longer active]]

One of our more serious plugin bugs.

Comment 7

[Chris Petersen]

*** Bug 170634 has been marked as a duplicate of this bug. ***

Comment 8

[sairuh (rarely reading bugmail)]

->sfraser

Comment 9

[Simon Fraser [no longer active]]

Fixed by the checkin for bug 176649.

Comment 10

[Chris Petersen]

Marking verified in 2002-10-25-14 trunk 

Comment 11

[Chris Petersen]

Chimera nightly 2002-10-25-14

Comment 12

[Chris Petersen]

Hmm. I can still reproduce this issue under 10.1.5 but not 10.2.1 (using the
same build (2002-10-30-04)

Comment 13

[Chris Petersen]

Reopening based on my latest comments

Comment 14

[sairuh (rarely reading bugmail)]

another observation: resizing doesn't seem to clear away this problem,
unfortunately. (still 10.1.5-only)

Comment 15

[sairuh (rarely reading bugmail)]

*** Bug 166124 has been marked as a duplicate of this bug. ***

Comment 16

[Xavier Snelgrove]

One way to fix it is to start the QT movie, and then stop it, the bug seems not
to be there if you are not on the first frame of the movie.

Comment 17

[Jeremiah Blatz]

Just a note, this bug still happens with the 2003011004 build (1/10/03). Also,
contrary to Phil Defer's note, the quicktime "showed through" the foreground tab
even when the movie wasn't on the first frame. HOWEVER, the movie did not show
through while playing, only when stopped. Resizing the window does not make it
go away.
I noticed this while looking at http://www.guerrillanews.com/redux/qt_hi.html, FYI.

Comment 18

[Chris Petersen]

This problem can also occur when the page contains multiple embedded QT objects.
See test case. Reproduces under 10.2.3 using the 2003-02-08-07 NB.

1) Open test case
2) Movie 1 start to play automatically, The second movie is static.
3) Press command-E to create a tab with the page's source. Notice the movie
frame appears in this tab.

Comment 19

[Chris Petersen]

Attachment: A test case that contains two embed element that reference a QT movie

Comment 20

[Jasper]

This bug still ocures in 2003081002 NB.

Comment 21

[Kurt Weinschenker]

When I open the testcase in a new tab, nothing happens.  I get two quicktime
symbols, but that's it.  Is this testcase broken?

Went to URL in Comment #17, saw this bug still happening there.  Stray movie
frames happened when I grabbed the scrollbar, and moved it up and down with the
mouse.

Camino nightly 20040208, Mac OS 10.2.3.

Comment 22

[Ludovic Hirlimann [:Usul]]

still true with 2004090408 (v0.8+).

Comment 23

[louis bennett]

*** Bug 263917 has been marked as a duplicate of this bug. ***

Comment 24

[TT]

I'm seeing this with Java applets on Mozilla 1.8a4 for OS X, so I'd like to
extend this bug to include Java applets.  A good test case is
http://www.cheaptickets.com/trs/cheaptickets/flighttracker/flight_tracker_graphic.xsl

It is a Java flight tracker, and the above URL will select a random flight.

Comment 25

[Jeff Leigh]

This same behavior is seen in Mozilla builds and being tracked with Bug 162134.

Comment 26

[Simon Fraser [no longer active]]

Plugins that use QuickTime to get bits onto the screen (e.g. with
DecompressSequenceFrame etc) cause drawing problems in Camino on tab switching,
and during scrolling.

The issue here is that QT displays frames on a timer, so that even if we set the
plugins clipping rect to empty on tab switch, QT can blit some frames onto the
screen later. This is why Real and QT frames can leak through tabs.

On scrolling, page content other than the plugin content can get messed up; it
gets drawn at the wrong offset. This is probably related, but may require a
separate fix.

A possible fix here involves using some QuickDraw calls to draw to the same
GrafPort that the plugins use (which is the WindowRef's port, not any
NSQuickDrawViews's port). This should invoke a sychronization mechanism between
QuickDraw and QuickTime to flush any pending frames to the screen.

Comment 27

[Simon Fraser [no longer active]]

*** Bug 283120 has been marked as a duplicate of this bug. ***

Comment 28

[Simon Fraser [no longer active]]

I filed bug 285550 specifically on the QuickTime scrolling issue.

Comment 29

[Samuel Sidler (old account; do not CC)]

This bug is a bit different on Tiger. With 10.4, changing tabs twice removes the
remnants. In Panther, the remnants stayed until the offending tab was closed.
I'm not sure what's changed or if it helps, but it's something...

Comment 30

[Samuel Sidler (old account; do not CC)]

I can't reproduce this anymore (on Tiger at least). Can someone try on Panther?

Comment 31

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #30)
> I can't reproduce this anymore (on Tiger at least). Can someone try on Panther?

I see comment 0 on 10.3.9.  At some point, the frame disappears, or a switch to
a third tab like in comment 29 makes the frame disappear.

We need a stable testcase, but in the meantime I've put the Serenity trailer in
for the URL.

Comment 32

[Julian Pellico]

I still get it on 10.4.0 with build 2005071708

Comment 33

[Kurt Weinschenker]

Somewhat fixed under 10.3.9, with QT 7, but not perfect.  When I switch between
tabs, the frame is there.  When I scroll in the tab with the stray QT frame, the
stray frame disappears.

Tested with Camino 2005091804 (v1.0a1+).

Comment 34

[davedit]

I still see this problem with Quicktime videos and Camino, as of 11/20 trunk on 10.4.3.

Additionally, I encountered this problem with RealPlayer.[url=http://img39.imageshack.us/img39/4877/freesnap0014dz.png]Sample picture here[/url]. However, I could not get rid of the stray frame by opening up multiple tabs or switching tabs. In fact, on the original page with the video - www.nfl.com - if I scrolled down the page quickly, the frame from the video would duplicate and scroll down the page with me. If I scrolled back up, it would rejoin the video.

Comment 35

[davedit]

I still see this problem with Quicktime videos and Camino, as of 11/20 trunk on 10.4.3.

Additionally, I encountered this problem with RealPlayer. [url=http://img39.imageshack.us/img39/4877/freesnap0014dz.png]Sample picture here[/url]. However, I could not get rid of the stray frame by opening up multiple tabs or switching tabs. In fact, on the original page with the video - www.nfl.com - if I scrolled down the page quickly, the frame from the video would duplicate and scroll down the page with me. If I scrolled back up, it would rejoin the video.

Comment 36

[davedit]

Woops, sorry for the dupe posts and the messed up link. It should be http://img39.imageshack.us/img39/4877/freesnap0014dz.png

Comment 37

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The dupe had Real in its summary, so adding it back here....

Comment 38

[Samuel Sidler (old account; do not CC)]

-> 1.1

Comment 39

[Stian Haklev]

*** Bug 334848 has been marked as a duplicate of this bug. ***

Comment 40

[dan]

yep, this bug is still extant. the java applet at http://freesound.iua.upf.edu/filesUploadApplet.php will still stray into adjacent tabs. 10.4.4 Intel. Camino 1.0 Intel.

Comment 41

[Chris Lawson (gone)]

Tweaking summary to make it easier to find.

Comment 42

[Chris Lawson (gone)]

*** Bug 343105 has been marked as a duplicate of this bug. ***

Comment 43

[Jonathan M.]

Still present in 2007032701 trunk 1.2 and 1.0.4

you can see it in this movie:

http://homepage.mac.com/jmujica/camino/bug156583.mov

Comment 44

[Stuart Morgan]

Any bug that is still open is assumed to still exist; there's no need to comment to that effect.

Comment 46

[Peter Gerdes]

This is also happening on firefox 3.0b1.  See bug 403532.  Are these the same bug (and hence should be merged) or not?  Also Bug 162134 is relevant since it seems to be the same problem but for java applets in firefox.

Comment 47

[davedit]

Still happening in Camino 1.6RC1.

Comment 48

[Stuart Morgan]

This is probably covered by bug 277067; we should re-test once that patch lands.

Comment 49

[philippe (part-time)]

Unfortunately, the patch in bug 277067 doesn't same to have fixed the issue for Camino.
Testing with the 2.0a1pre (1.9pre 2008042317) tinderbox build. The equivalent Minefield tinderbox build (Gecko/2008042317 Minefield/3.0pre) works correctly.

test case in bug 425715, and movie trailers on Apple's QuickTime site.

Comment 50

[Stuart Morgan]

Hm; I'll trace HidePlugin in a debugger when I get a chance and see if there's anything obviously wrong.

Comment 51

[davedit]

Just thought I'd update, still occurs in latest trunk.

Comment 52

[Stuart Morgan]

nsChildView::Show, and thus HideChildPluginViews, is never called when we switch tabs, just when we make new ones. Who calls it when switching tabs in Firefox?

Comment 53

[Stuart Morgan]

Attachment: Hide plugins when removing ChildView from a window

Actually, this is trivial to fix by having ChildView hide plugins when it is being removed from a window just as it would when being hidden by Gecko, since the same principle applies--we need to tell the plugin that it's not supposed to be drawing any more.

Comment 54

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 345440 [details] [diff] [review]
Hide plugins when removing ChildView from a window

This looks reasonable to me.

I haven't tested it, but I can't foresee it causing trouble.

Comment 55

[Stuart Morgan]

Comment on attachment 345440 [details] [diff] [review]
Hide plugins when removing ChildView from a window

Requesting 1.9.0 branch approval. This is very low risk, and given that it wasn't required for Firefox's fix I suspect that only embeddors actually end up exercising this code path during anything but window teardown.

Comment 56

[Samuel Sidler (old account; do not CC)]

Comment on attachment 345440 [details] [diff] [review]
Hide plugins when removing ChildView from a window

Moving approval request to 1.9.0.5.

Comment 57

[Daniel Veditz [:dveditz]]

Comment on attachment 345440 [details] [diff] [review]
Hide plugins when removing ChildView from a window

Needs to land on mozilla-central for testing before we land on the branch.

Comment 58

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 345440 [details] [diff] [review]
Hide plugins when removing ChildView from a window

a=beltzner, back it out if it causes test failures (better yet, make sure it won't cause test failures!)

Comment 59

[Josh Aas]

Attachment: fix v1.0 (un-bitrotted)

Comment 60

[Dave Townsend [:mossop]]

Pushed: http://hg.mozilla.org/mozilla-central/rev/b2c97f9a0936

Comment 61

[Stuart Morgan]

Comment on attachment 345440 [details] [diff] [review]
Hide plugins when removing ChildView from a window

Re-requesting 1.9.0 branch approval; see comment 55.

Comment 62

[Daniel Veditz [:dveditz]]

Comment on attachment 345440 [details] [diff] [review]
Hide plugins when removing ChildView from a window

Approved for 1.9.0.6, a=dveditz for release-drivers.

Comment 63

[Stuart Morgan]

Landed on CVS trunk

Checking in widget/src/cocoa/nsChildView.mm;
/cvsroot/mozilla/widget/src/cocoa/nsChildView.mm,v  <--  nsChildView.mm
new revision: 1.367; previous revision: 1.366

Comment 64

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verfied on 1.9.1 and 1.9.0 with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090117 Shiretoko/3.1b3pre Ubiquity/0.1.4 ID:20090117020415

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6

Comment 65

[Samuel Sidler (old account; do not CC)]

Henrik: This actually belongs in Widget:Cocoa, but should probably be verified on 1.9.0 using Camino and confirming that the issue actually existed prior to the fix landing.

Comment 66

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Yes, the bug still existed in 1.9.0 prior to this patch; for instance, in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.6pre) Gecko/2008120800 Camino/2.0b1pre (like Firefox/3.0.6pre)

The bug no longer exists in things like 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.6pre) Gecko/2009010300 Camino/2.0b2pre (like Firefox/3.0.6pre)

Confirming the "verified1.9.0.6" keyword.