Closed
Bug 156583
Opened 22 years ago
Closed 16 years ago
Stray QuickTime, Real, or Java plugin frame can appear after switching to another tab
Categories
(Core :: Widget: Cocoa, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.9.1b2
People
(Reporter: chrispetersen, Assigned: stuart.morgan+bugzilla)
References
()
Details
(Keywords: verified1.9.0.6)
Attachments
(2 files, 1 obsolete file)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
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.
Keywords: qawanted
Reporter | ||
Comment 2•22 years ago
|
||
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.
Reporter | ||
Comment 3•22 years ago
|
||
Tested with Chimera 2002-07-10-05 NB.
Comment 4•22 years ago
|
||
->bnesse, the quicktime plugin frame overdraw issue
Assignee: saari → bnesse
Comment 5•22 years ago
|
||
*** Bug 161558 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 7•22 years ago
|
||
*** Bug 170634 has been marked as a duplicate of this bug. ***
Comment 8•22 years ago
|
||
->sfraser
Comment 9•22 years ago
|
||
Fixed by the checkin for bug 176649.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 10•22 years ago
|
||
Marking verified in 2002-10-25-14 trunk
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 11•22 years ago
|
||
Chimera nightly 2002-10-25-14
Reporter | ||
Comment 12•22 years ago
|
||
Hmm. I can still reproduce this issue under 10.1.5 but not 10.2.1 (using the
same build (2002-10-30-04)
Reporter | ||
Comment 13•22 years ago
|
||
Reopening based on my latest comments
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 14•22 years ago
|
||
another observation: resizing doesn't seem to clear away this problem,
unfortunately. (still 10.1.5-only)
Comment 15•22 years ago
|
||
*** Bug 166124 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
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•22 years ago
|
||
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.
Reporter | ||
Comment 18•22 years ago
|
||
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.
Reporter | ||
Comment 19•22 years ago
|
||
Comment 20•21 years ago
|
||
This bug still ocures in 2003081002 NB.
Comment 21•21 years ago
|
||
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•20 years ago
|
||
still true with 2004090408 (v0.8+).
Comment 23•20 years ago
|
||
*** Bug 263917 has been marked as a duplicate of this bug. ***
Comment 24•20 years ago
|
||
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•20 years ago
|
||
This same behavior is seen in Mozilla builds and being tracked with Bug 162134.
Comment 26•20 years ago
|
||
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.
Status: REOPENED → ASSIGNED
Comment 27•20 years ago
|
||
*** Bug 283120 has been marked as a duplicate of this bug. ***
Comment 28•20 years ago
|
||
I filed bug 285550 specifically on the QuickTime scrolling issue.
Comment 29•19 years ago
|
||
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...
Updated•19 years ago
|
Summary: Stray QT movie frames can appear in other tabbed pages → Stray QuickTime or Java frame can appear after switching to another tab
Updated•19 years ago
|
Priority: -- → P2
Target Milestone: --- → Camino1.0
Comment 30•19 years ago
|
||
I can't reproduce this anymore (on Tiger at least). Can someone try on Panther?
(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•19 years ago
|
||
I still get it on 10.4.0 with build 2005071708
Comment 33•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
Woops, sorry for the dupe posts and the messed up link. It should be http://img39.imageshack.us/img39/4877/freesnap0014dz.png
The dupe had Real in its summary, so adding it back here....
Summary: Stray QuickTime or Java frame can appear after switching to another tab → Stray QuickTime, Real, or Java frame can appear after switching to another tab
Comment 39•19 years ago
|
||
*** Bug 334848 has been marked as a duplicate of this bug. ***
Comment 40•18 years ago
|
||
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•18 years ago
|
||
Tweaking summary to make it easier to find.
Summary: Stray QuickTime, Real, or Java frame can appear after switching to another tab → Stray QuickTime, Real, or Java plugin frame can appear after switching to another tab
Comment 42•18 years ago
|
||
*** Bug 343105 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Target Milestone: Camino1.1 → Camino2.0
Comment 43•18 years ago
|
||
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
Assignee | ||
Comment 44•18 years ago
|
||
Any bug that is still open is assumed to still exist; there's no need to comment to that effect.
Updated•18 years ago
|
Assignee: sfraser_bugs → nobody
Status: ASSIGNED → NEW
QA Contact: chrispetersen → plugins
Comment 46•17 years ago
|
||
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•17 years ago
|
||
Still happening in Camino 1.6RC1.
Assignee | ||
Comment 48•17 years ago
|
||
This is probably covered by bug 277067; we should re-test once that patch lands.
Comment 49•16 years ago
|
||
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.
Assignee | ||
Comment 50•16 years ago
|
||
Hm; I'll trace HidePlugin in a debugger when I get a chance and see if there's anything obviously wrong.
Comment 51•16 years ago
|
||
Just thought I'd update, still occurs in latest trunk.
Assignee | ||
Comment 52•16 years ago
|
||
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?
Assignee | ||
Comment 53•16 years ago
|
||
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.
Assignee: nobody → stuart.morgan+bugzilla
Status: NEW → ASSIGNED
Attachment #345440 -
Flags: review?(joshmoz)
Attachment #345440 -
Flags: review?(joshmoz) → review?(smichaud)
Comment 54•16 years ago
|
||
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.
Attachment #345440 -
Flags: review?(smichaud) → review+
Assignee | ||
Updated•16 years ago
|
Attachment #345440 -
Flags: superreview?(roc)
Attachment #345440 -
Flags: superreview?(roc) → superreview+
Assignee | ||
Comment 55•16 years ago
|
||
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.
Attachment #345440 -
Flags: approval1.9.0.4?
Comment 56•16 years ago
|
||
Comment on attachment 345440 [details] [diff] [review]
Hide plugins when removing ChildView from a window
Moving approval request to 1.9.0.5.
Attachment #345440 -
Flags: approval1.9.0.4? → approval1.9.0.5?
Comment 57•16 years ago
|
||
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.
Attachment #345440 -
Flags: approval1.9.0.5?
Attachment #345440 -
Flags: approval1.9.1b2?
Updated•16 years ago
|
Attachment #345440 -
Flags: approval1.9.1b2? → approval1.9.1b2+
Comment 58•16 years ago
|
||
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•16 years ago
|
||
Attachment #345440 -
Attachment is obsolete: true
Comment 60•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 16 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 61•16 years ago
|
||
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.
Attachment #345440 -
Flags: approval1.9.0.6?
Updated•16 years ago
|
Attachment #345440 -
Flags: approval1.9.0.6? → approval1.9.0.6+
Comment 62•16 years ago
|
||
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.
Assignee | ||
Comment 63•16 years ago
|
||
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
Keywords: fixed1.9.0.6
Comment 64•16 years ago
|
||
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
Status: RESOLVED → VERIFIED
Component: Plug-ins → Widget: Mac
Keywords: fixed1.9.0.6 → verified1.9.0.6
Product: Camino → Core
QA Contact: plugins → mac
Target Milestone: Camino2.0 → mozilla1.9.1b2
Version: unspecified → Trunk
Comment 65•16 years ago
|
||
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.
Component: Widget: Mac → Widget: Cocoa
QA Contact: mac → cocoa
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•