steps to reproduce: use the new version of OSX remove MRJPluginCarbon.plugin from the bundle go to above URL load a page, this bug for instance open the URL listed on this bug in a new tab, I did it with command-click wait for the java applet to load and start exclaiming its exciting news switch back to the first tab expected results: java applet stays on its own dang tab actual results: java applet draws all over any other tab in the same window kit: 6C115, Moz 2002072308 (1.1b), pismo 400

there are similar reports (bug 116766, bug 162102) but I am unable to reproduce on a current CVS, Linux.

R.K.Aa: this bug was filed about the Apple java plug-in, so I wouldn't expect to be able to reproduce this on linux. On Mac, I've only seen this problem with the Apple plug-in. The MRJ plug-in hasn't exhibited this problem. Confusing factors are: Apple plug-in is for 10.2; Mozilla MRJ plug-in doesn't work yet on 10.2. When the Mozilla MRJ plug-in works on 10.2 this will probably be easier to pinpoint. I suspect this will turn out to be a dup of bug 162102, but I don't see the data yet to call it. The java plug-in on Windows and 10.2 could be not implementing something properly that the Mozilla MRJ plug-in does or maybe the MRJ plug-in works around a Mozilla problem. Both cases would make this a dup of bug 162102.

I'm seeing this with RealPlayer plug-in too now. Attaching testcase. Old Summary: using apple java plug-in applets draw on wrong tabs New Summary: plug-ins draw on wrong tabs I'll ask for confirmation in the other related bugs.

You'll need to have tabs set to 'load links in the background' and 'middle click or control click of links on a web page' for this test case to work as-is.

Re-assign to Babak.

I can only reproduce this issue when using the branch OS X build (2002-10-14-05) when toggling between tabs. Tested under 10.2.1. Steps to reproduce 1) Load this applet in the first tab: http://mozilla.org/quality/browser/standards/html/applet_align_middle.html 2) Create a second tab and the go to a url like apple.com 3) Now, click on first tab to bring to front. 4) Click on second tab to bring to front again. 5) Continue steps 3 & 4 a few times. The applet in tab 1 will randomly paint in the second tab's window.

I can reproduce this issue described in the comment 7 regarding applets. Same thing applies to real content as well. Steps to reproduce: 1)Go to http://www.weather.com/activities/verticalvideo/vdaily/weekendoutlook.html?from=nchomepage 2) After real plugin has been initialzed, press command T to create a new tab. 3) Real content should appear in this tabbed window.

Reassigning to Peter L

Tested under 2002-12-18-08 CFM trunk under 10.2.2 with Real Player One (9.0b2) plug in.

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

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

The patches in bug 191821 may affect this.

Why was the summary prepended with Java? The real-player problem testcased in comment #4 is still a problem with 1.3b. Please change it back if I'm missing something unstated, but this doesn't seem to be java-specific.

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

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

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

Does this belong on plug-ins rather than OJI?

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

Does this still happen in recent builds? I might have fixed it.

Simon, how recent? Bug 196655 , resolved/dup to this bug, is against 2003030703.

I just tried it against the 1.3 candidate build, and it's still happening. Even more excitingly it's overwriting the toolbar now too. :) Attaching screenshot.

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

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 Reproducible: Always Steps to Reproduce: 1. Go to www.orf.at 2. Click on one of the top-headlines (not all have a ticker, so try) 3. Click on another tab and scroll Actual Results: The ticker not only runs in this different tab (Bugzilla Bug 104532), but it also multiplies itself. Screenshot at Bug 197347

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

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

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

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

This bug seems to have become more visible since the release of Apple's Java 1.4.1 update.

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

greetings from bug 196424. first noticed this problem over at the bbc website: http://news.bbc.co.uk/2/hi.html their ticker draws all over the place if you scroll and if you switch to another tab, it draws through. this isn't considered major? most of the bbcnews website becomes unreadable because of this.

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

Very annoying problem especially on the BBC news site, should probably be bumped up a priority notch.

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

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

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

I think this is a dupe of 104532, which amounts to that status bar should only reflect the status of the currently selected tab.

Felix, this bug isn't about the status bar, it's a drawing bug with plug-ins. Perhaps related to this bug: I've noticed on 2003040708, that if I have a blinking text insertion-point cursor in a textarea, like this one I'm typing in now, and I open a new tab, sometimes (but not always) the cursor blinks through to the other tab.

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

This appears to be fixed in recent Camino builds. Can the code be incorporated into the MachO builds of the Mozilla trunk?

It seems that the carbon widget code isn't setting up the clip properly for the plugin, as the cocoa widget code does.

Hrm, setting the clip region of the port doesn't do any good, for either plugin. We also set the clipRect on the NPWindow to be empty, and they ignore that too. I think this is a problem with those plugins. I'm not sure what we can do to fix it.

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

Simon, naive question: if the problem is with the plug-ins, wouldn't Camino also suffer? Confirmed same behavior on 1.0.0.

Camino's drawing environment is a little different, because it's a Cocoa app, though I have to look into the difference in behaviour. What is 1.0.0 ?

>What is 1.0.0 ? The Finder version string on the oldest version of Mozilla I still have on my hard drive.

Anyone know how Safari avoids this problem? It passes comment 8's testcase (which Mozilla and Camino both fail) with flying colors.

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

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

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

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

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

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

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

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

(Build 2003052208) For News.BBC.CO.UK, the ticker crawl still stays at the physical location it was first displayed, and scrolling up/down results in multiple "ghosts" of the crawl line speared across the Navigator panel.

reassigning to Peter.

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

adt: nsbeta1+/adt1

I took a look at this bug in the debugger and it looks like we are correctly calling SetWindow(NULL) on the plugins when it gets hidden (either by switching tabs or changing CSS visibility) so it looks like bugs in the plugins. I've contacted Apple and they'll fix their Java plugin to correctly respond to SetWindow(NULL) calls which should fix this bug. Real Player needs to be updated for Mach-O and they'll fix this at the same time.

Peter, In that case should this be an evangelism bug? If so, please remove the nsbeta1+ keyword. Thanks.

<aol>me too!</aol> CC'ing self. As someone already mentioned, the BBC ticker is a fine example: http://news.bbc.co.uk/ Other examples include this display of Lunar phases, and another of Jupiter and its moons: http://home.attbi.com/~psmcd/app.html And the Yahoo! game "Text Twist", and their crossword: http://games.yahoo.com/games/downloads/tx.html http://games.yahoo.com/games/gen/cwpuz/puz_030530.html Note that the second link will probably only be available for about two weeks from today; you can get to the current set of available crosswords at: http://games.yahoo.com/games/cw.hf2k This is with Mozilla 1.4rc1, OSX 10.2.6, Apple Java 1.4.1 Steps to reproduce are as indicated elsewhere. 1. open new window. 2. open new tab. 3. switch back to first tab, load any of the pages with Java applets that update themselves 4. switch to second tab. watch applet paint through. 5. switch to first tab. scroll. watch applet output in old positions not get cleaned up. 6. give an applet focus (the crossword applet is great for this). 7. switch to second tab. 8. type. note that java applet still has focus, and merrily paints through to second tab.

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

I'm also seeing this with the Quicktime Plug-In now: http://www.path.unimelb.edu.au/~dersch/html/Micros.html The image overdraws where the controller should be on scroll. This appears to be a very common plug-in coding mistake. Assuming that all the plug-ins are really broken, would it be possible to mimic the work-around that Safari uses? With Safari shipping with 10.3 as the default browser, plug-in vendors will likely test against that, so this problem may recur frequently if we don't implement whatever work-around Safari uses. I know, inelegant, hackish, etc., but perhaps the problem is already as pervasive as it is because IE does something similar?

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

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

mozilla1.4 shipped. unsetting blocking1.4 request.

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

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

Anthony Foiani mentioned, over on bug 158972, comment #11: >If it hasn't already been mentioned, it looks like there might >be some crossover with bug 184755. which, in turn, mentions that there are 5 or 6 places a java plug-in gets re-drawn per scroll, looks like at least 3 for other plug-ins. So, somebody looking at this might need to check all those places for correct behavior.

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

Sometimes the inverse happens - the page content from another tab draws in place of the plug-in. Attaching screenshot w/ QuickTime Player.

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

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

I had hope that Java 1.4.1 Update 1 would help: "improved Java applet support for Safari and other web browsers that support the Java Internet Plug-In; improved drawing correctness and performance" but it doesn't.

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

I have seen the same behavior under Windows ME with dual monitors (GeForce 4 with two monitor supported)

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

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

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

In Panther, this problem can draw over the screen of another user with Fast User Switching. e.g., start loading: http://whatisthematrix.warnerbros.com/rl_cmp/qtvr_apart_2.html and switch to another user. The plug-in draws on the other user's screen. So the problem doesn't seem to be constrained to drawing over other Mozilla windows, it's going all weird at a lower level.

Personally, I think it's pretty sad that this bug has been in the system for over a year and nothing's been done about it. Come on guys, other browsers don't have this problem, it can't be fundamentally unsolveable. I recently reported 4 bugs to Firebird and they were all fixed within a week, yet this one bug I've been dealing with for over a year! Get your acts together, please. I could 42 duplicates of this bug, doesn't that say something?!? This is the kind of thing that makes me lose faith in the open source philosophy.

> it can't be fundamentally unsolveable The problem is not under our control. We're doing everything we can to tell plugins not to draw when they are in non-visible tabs (by setting their 'plugin window' to null), but the plugins are ignoring this. The bug has been acknowledged by the author of Apple's Java plugin, at least. Fixing this bug requires the plugins to be revved, and, since Mozilla now has little clout with plugin developers, this is unlikely to happen.

>since Mozilla now has little clout with >plugin developers, this is unlikely to happen. This might be a dumb question - I've never tried anything like this, but I'll throw it out just in case: If the issue is the Carbon drawing environment (vs. Cocoa) and Mozilla is the last Carbon browser of import (so it's not being noticed), would it be feasible to embed a Cocoa drawing widget just for plugins, then hand that off to the plugins to draw in? I think I saw some sample code on the ADC site for doing the cross-toolkit embedding. Maybe some Camino code could be reused once the drawing area is setup? I also wonder if there's an OS bug here too - nothing should be able to draw through to different user screens. I was going to file a bug in radar, but I'm not clueful enough about this to write a good bug. noise: please don't berate the Mozilla volunteers.

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

could someone explain how it's a plugin problem if safari doesn't have the same bug? (same question from comment 47, seems not to have been answered.) if it doesn't happen in safari, then it would seem to me that its a mozilla problem, not a plugin one.

> could someone explain how it's a plugin problem if safari doesn't have the same bug? Safari is a Cocoa-native app, though I'm not sure how it's able to allow plugins to draw with QuickDraw. Camino is a Cocoa app which uses NSQuickDrawView for rendering, and has a bunch of hacks because plugins expect to be living in a Carbon world, where there is a single GrafPort per window (unlike the NSQDView model of a GrafPort per cocoa view). Throw Quartz Extreme into the mix, and things get very messy.

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

Also of note is that applets take input from other tabs too. I noticed at this page: http://www.esbuy.com/dvblbefisped.html there is a java navigation applet, which when you switch to other tabs still does its thing if you mouse over the right spot. I wonder if keypresses go through as well - could somebody craft a full-window-size clear window applet with some fancy DOM that would load invisibly behind a page and steal key input from other tabs?

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

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

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

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

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

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

Just to confirm, Apple's Java 1.4.2 came out today, and it did not fix this.

This is an interesting case - text from the "previous" tab is drawn in the place of an image on the current tab that is in the process of loading. Once the image is "loaded" the draw-through doesn't occur. Don't know the internals of how this works - does something get marked "done" when something like an image loads? Could there be an bug in the code to handle "undone" page bits? Any chance plugins aren't marked done? I know, stabbing in the dark. A slow network connection is probably necessary for recreating this. Who thought my 26k line would ever come in handy? :)

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

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

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

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

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

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

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

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

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

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

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

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

(In reply to comment #87) > . Camino is a Cocoa app which uses NSQuickDrawView for > rendering, and has a bunch of hacks because plugins expect to be living in a > Carbon world, where there is a single GrafPort per window (unlike the NSQDView I just wanted to add I'm seeing this same bug on my site www.rant.st on a scrolling stock ticker applet. Its only in moz 1.7 on OSX with the trash page on scroll and bleed thru tabs in same window. However, I'd like to add just in case its not known, that this does *not* happen in the latest Camino release. Also, this same ticker fails on Safari as just a blurred line. IE OSX works ok as well.

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

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

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

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

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

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

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

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

I am using Mozilla 1.7.2 (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; nl-NL; rv:1.7.2) Gecko/20040803) and I am still seeing this. Based on the massive number of duplicates, I can see a lot of people are unhappy about this one. I checked bug 197813 to see if this is related to the old Java 1.3.1 plugins that Mozilla normally uses, but from what I can see, this is unrelated. BTW, that bug says this error is not limited to Mac OSX. With the new good press and high momentum Mozilla and Firefox enjoy, is there any chance of nudging Apple into action here?

This is a security issue now: <http://secunia.com/advisories/12392/>

The plugin that is being developed with Bug 197813 doesn't exhibit this bug. Tested with version 0.8.3 of the new plugin on build 2004082408 of Mozilla running under OS X 10.3.5.

To be explicit, this bug also exists in Firefox, and is very annoying, as my homepage contains a Java applet. It is a highly visible issue that could potentially drive people away, and should really be fixed for Firefox 1.0, if at all possible. Nominating to block aviary 1.0mac.

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

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

bug 258275 is also a duplicate of this bug. Can someone please mark it as such?

Bug 197813 isn't a complete fix, but it is much better than the current Java plugin.

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

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

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

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

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

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

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

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

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

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

I just had an interesting problem that may be closely related... Rather than a tab drawing through the plugin, I just had a plugin (Java) that floated over all the tabs. I'm attaching a couple of screenshots (I can't reproduce it); if you think it's a separate bug just let me know and I'll re-file.

screenshots are too big to attach. URLs: http://andrew.cmu.edu/user/bmills/JavaBug.png http://andrew.cmu.edu/user/bmills/JavaBug2.png http://andrew.cmu.edu/user/bmills/JavaBug3.png (Number 3 has the tab that actually contains the Java applet)

Now I can't *not* reproduce it. http://www.housing.cmu.edu/ Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1

You are seeing the exact behavior described for this bug.

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

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

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

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

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

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

With the release of Firefox 1.0, a ton of people are seeing this bug. For every one person who reports this bug, there must be thousands of people who hit is without reporting it. Maybe we should have a petition website where we can enlist users to encourage Apple to get this fixed.

From http://developer.apple.com/java/faq/#anchor4 4: What J2SE version do Java applets run under inside a browser? Apple’s Safari browser only supports Java applets under J2SE 1.4.x. Other browsers are currently developed to specifically use our 1.3.1 implementation, and will need to be updated. If you would like to see your favorite browser use 1.4.x on Mac OS X, please contact the vendor and ask them to work with Apple to adopt the newer version.

http://javaplugin.sourceforge.net/Readme.html The Java Embedding Plugin is a utility that allows other web browsers than Apple's Safari to use the most recent versions of Java (1.4.X) on Mac OS X. When used together with an updated version of Mozilla's MRJ Plugin Carbon (included in this distribution), the Java Embedding Plugin's functionality is currently available to recent versions of Mozilla, Firefox and Camino. But in principle any web browser could use one of the Java Embedding Plugin's two APIs to add support for Java 1.4.X.

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

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

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

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

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

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

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

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

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

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

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

The developer of the Java Embedding Plugin can't replicate this bug in Firefox. Here are the steps I follow to show the bug when running Firefox. Load up http://www.fantasyasylum.com Open a new tab and load http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official Select a bunch of the text and then de-select it Change back to fantasy asylum and then back to the Google page. Drawing problems are now evident. Is anyone else able to see this bug in Firefox when following the same steps I've followed?

For me the drawing problems are there as soon as open a new tab. I didn't have to follow any of the subsequent steps (like selecting text and switching tabs) to see the java scroll box of the first page in the new tab. P (In reply to comment #161) > The developer of the Java Embedding Plugin can't replicate this bug in Firefox. > Here are the steps I follow to show the bug when running Firefox. > > Load up http://www.fantasyasylum.com > > Open a new tab and load > http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official > > Select a bunch of the text and then de-select it > > Change back to fantasy asylum and then back to the Google page. Drawing problems > are now evident. > > Is anyone else able to see this bug in Firefox when following the same steps > I've followed?

(In reply to comment #162) Just to make sure -- you were using the Java Embedding Plugin (and Firefox 1.0)?

When I switch back to the Google page I can still see the "High Voltage News" scrolling. I use Mozilla 1.7.5 and Java Plug-Ins 0.8.9.

Java did launch. I'm not sure if I was using the java Embedding Plugin. How would I find out? How else could a Java applet be embedded in a page? Sorry. I am using Firefox 1.0, on Mac OS X.3.7, with every last bloody update installed. P (In reply to comment #163) > (In reply to comment #162) > > Just to make sure -- you were using the Java Embedding Plugin (and > Firefox 1.0)? > >

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

The case in #161 repros for me as well (Firefox 1.0, MacOS X 10.3.7), and here's another instance of the bug, a clock applet: <http://www.time.gov/timezone.cgi?Eastern/d/-5/java>

(Following up comment #161 and comment #163) I'm the developer of the Java Embedding Plugin, which seems to (mostly) resolve this bug. http://javaplugin.sourceforge.net/ As best I can tell, the problem is completely resolved in recent versions of Firefox (e.g. 1.0) and Camino (e.g. 0.8.2), and partially resolved in Mozilla (1.7.3, 1.7.5 and 1.8a). The remaining issues with Mozilla are, I believe, Mozilla's fault (I'll deal with this in a separate message, after I've had a chance to file a bug report). But Jeff Leigh has found a way (detailed in his comment #161) to make the problem occur even with Firefox 1.0 and the latest versions of the Java Embedding Plugin (0.8.8 and 0.8.9). I'm not able to reproduce what he reports. So the question is, are any of you able to? If anyone using the latest version of the JEP (currently 0.8.9) and either Firefox or Camino can consistently make an applet draw in the "wrong" tab (whether or not you follow the instructions in comment #161), please post here and give a detailed description of what happens and how you can make it happen. > The case in #161 repros for me as well (Firefox 1.0, MacOS X > 10.3.7), and here's another instance of the bug, a clock applet: > <http://www.time.gov/timezone.cgi?Eastern/d/-5/java> Sorry, but I do have to ask: Were you using a recent version of the Java Embedding Plugin?

Steven, I am unable to dupe either case (comment #161 or #167) I'm testing with an hourly Tinderbox build from last night (Jan. 3) and MRJ and JEP v. 0.8.8 (just now realized I haven't updated to 0.8.9 on this machine :-/ )

(In reply to comment #168) > Sorry, but I do have to ask: Were you using a recent version of the > Java Embedding Plugin? How do I find out?

(In reply to comment #170) The short answer is "if you have to ask, you're not using it" :-) But here's another, slightly more long-winded answer: Look in your "/Library/Internet Plug-Ins/" and "~/Library/Internet Plug-Ins/" directories for files named "JavaEmbeddingPlugin.bundle" and "MRJPlugin.plugin". If you find either of these files in your "~/Library/Internet Plug-Ins/" directory (the "Library/Internet Plug-Ins/" directory under your home directory), drag them out -- having them there will just confuse you. If you find both files in your "/Library/Internet Plug-Ins/" directory, you're _probably_ using some version of the Java Embedding Plugin. To make sure, use "Get Info" on both files. If your "MRJPlugin.plugin" file's version is something like "1.0-JEP-0.8.9", you got it from the Java Embedding Plugin. The "Get Info" version number for "JavaEmbeddingPlugin.bundle" should be something like "0.8.9". The two version numbers need to match. For more information see http://javaplugin.sourceforge.net/

(In reply to comment #171) > (In reply to comment #170) > > The short answer is "if you have to ask, you're not using it" :-) > Yes. I reached the same conclusion. At first I visited the site, and noted that the bug was there (with FF 1.0, X.3.7). So, I followed your link, installed the new plugin, and the bug was gone. In fact, rendering of the clock seemed sharper, too. Kudos. So, I'm straight. In about 5 minutes I verified that the latest JEP (0.8.9) fixes the problem. P

I just installed the plugins as mentioned (without rebooting) but the bug is still there and Mozilla freezes sometimes. I have 2004123106, Mac X.3.7, Java 1.4.2

(In reply to comment #173) Take another look at my comment #168. I'm looking for people who can reproduce this bug (bug 162134) with the latest version of the JEP and either Firefox or Camino. You're using a Mozilla nightly. The freezes are a separate issue, which I'm not able to reproduce. If you'd like to pursue this, please file a bug report at: http://sourceforge.net/tracker/?atid=649116&group_id=107955&func=browse Among other things, I'll need URLs where the freezes happen and as detailed a description as possible of what actions seem to trigger them.

I just reproduced this in FF 1.0 with the standard plugins, then installed the latest JEP and confirmed that it went away. So the JEP does indeed solve this.

Using the latest version of the JEP (downloaded today) and Firefox 1.0 (on Mac OS X 10.3.7), I saw the issue described by comment #161 on the first try. But then after that, I could only reproduce it sporadically...not every time. I've attached a screenshot of what I saw. I loaded the first page into a tab, then loaded the Google page in another tab, then highlighted some of the text and clicked outside it, and then clicked back and forth and saw it. But like I said, I've been going crazy trying to reproduce it more, because it doesn't happen for me MOST of the time...only 2 or 3 times after at least a dozen attempts... I'd also like to note that since installing the JEP, I have not seen applets drawing on the wrong tab on sites where I used to see it, which I am very happy about since my homepage uses a Java applet. So thanks!

Tom Hessman wrote: > Using the latest version of the JEP (downloaded today) and Firefox 1.0 > (on Mac OS X 10.3.7), I saw the issue described by comment #161 on the > first try... I think the effect you're seeing there is a separate issue from the main problem Java applets and other plug-ins have had with drawing. Take a look at this page, for instance: http://www.duckware.com/jexepack/index.html This page doesn't use any Java applets or Real or QT or Flash, just a JavaScript that doodles multi-colored line across a web page. The effect leaks through from one tab to another -- so apart from how plug-ins work, I think there a more general problem with tab panes being properly respected by other tab panes. All in all, I take this as very good news!

> This page doesn't use any Java applets or Real or QT or Flash The page has applets all over it.

My bad. I'd somehow gotten the impression that the drawing was being done by a JavaScript, not a Java applet, but now that I look at the page source... yep. There's the applet -- spinner.class.

(In reply to comment #176) Thanks!! Just before I read your message, something I'd done in Firefox had caused the problem to happen once. Then I read your message ... and now I've found a very simple way to reproduce the problem well over 50% of the time! I still have no idea _why_ this "works", but at least now I have something to play with. Here are the steps I followed: 1. Start Firefox 1.0. 2. Visit http://www.fantasyasylum.com/, and wait for the news ticker applet to start. 3. Open a new tab. 4. Type a few characters in the new tab's location bar. 5. Use the mouse to switch back and forth between tabs. You should often see bits of the fantasyasylum news ticker applet in the blank tab after you've switched away from the fantasyasylum tab. 6. Delete the characters in the blank tab's location bar. 7. Use the mouse to switch back and forth between tabs. Now you should never see debris from the news ticker applet when switching to the blank tab. Please let me know how/if this procedure works for you. My procedure doesn't "work" in Camino.

(In reply to comment #180) > (In reply to comment #176) > > Thanks!! > > Just before I read your message, something I'd done in Firefox had > caused the problem to happen once. Then I read your message ... and > now I've found a very simple way to reproduce the problem well over > 50% of the time! I still have no idea _why_ this "works", but at > least now I have something to play with. > > Here are the steps I followed: > > 1. Start Firefox 1.0. > > 2. Visit http://www.fantasyasylum.com/, and wait for the news ticker > applet to start. > > 3. Open a new tab. > > 4. Type a few characters in the new tab's location bar. > > 5. Use the mouse to switch back and forth between tabs. You should > often see bits of the fantasyasylum news ticker applet in the blank > tab after you've switched away from the fantasyasylum tab. > > 6. Delete the characters in the blank tab's location bar. > > 7. Use the mouse to switch back and forth between tabs. Now you > should never see debris from the news ticker applet when switching > to the blank tab. > > Please let me know how/if this procedure works for you. > > My procedure doesn't "work" in Camino. > > Am able to duplicate in Firefox, now with JEP and MRJ 0.8.9 and FF nightly (Jan. 4) See screenshot: http://home.comcast.net/~joelcraig23/images/Picture_1.png No bleed-through in Camino.

(In reply to comment #180) > Please let me know how/if this procedure works for you. Your procedure works for me, using the exact steps you describe. I dare say that the applet bled through "most" of the time (while characters were in the address bar of the empty tab), but it was there at least 50% of the time...

I can also reproduce the problem stated in #180. Using the latest version of the JEP (downloaded today) and Firefox 1.0 (on Mac OS X 10.3.7)

(Following up comment #180) Now that I have your attention, let's continue our journey into the heart of wierdness :-) I've come to the tentative conclusion that, when using JEP 0.8.9 and Firefox 1.0, an applet will only draw to the "wrong" tab when the tab to which you're switching has highlighted text in its location bar -- an applet in the "first" tab (the one you're switching away from) will only draw into the "second" tab (the one you're switching to) if the second tab's location bar contains highlighted text. If this is true, then (presumably) something that happens only when a tab's location bar contains highlighted text is causing the applet from the "first" tab to be made invisible only after the "second" tab has been displayed for the first time. The procedure I described in comment #180 demonstrates debris appearing in the "second" (blank) tab when its location bar contains highlighted text, and not appearing when its location bar contains no text at all. Here's a procedure that demonstrates debris not appearing when the "second" tab's location bar contains non-highlighted text: 1. Make sure you've installed JEP 0.8.9. 2. Start Firefox 1.0. 3. Visit http://java.sun.com/applets/jdk/1.4/demo/applets/Animator/example4.html. 4. Open a new tab, and in it visit http://www.fantasyasylum.com/. 5. Click once on the text in the second tab's location bar -- "http://www.fantasyasylum.com/" will be highlighted. 6. Switch to the first tab -- no debris should appear. 7. Switch to the second tab -- "http://www.fantasyasylum.com/" will no longer be highlighted, but the text-entry cursor will be flashing in the second tab's location bar; no debris should appear. 8. Switch to the first tab -- no debris should appear. 9. Switch to the second tab -- "http://www.fantasyasylum.com/" will now be highlighted, and debris from the Animator applet in the first tab should now appear in the second tab. 10. Switch back and forth a few more times between tabs -- debris should never appear in the first tab but almost always in the second tab. 11. Switch to the second tab, delete the highlighted text in its location bar (the Delete key will do the job), and click the mouse somewhere in the content area of the second tab's window (i.e. make the text-entry cursor disappear from the second tab's location bar). 12. Switch back and forth a few more times between tabs. Now the text in both tabs' location bars should be non-highlighted, and no debris should appear in either tab.

(Following up comment #168) > I'm the developer of the Java Embedding Plugin, which seems to > (mostly) resolve this bug. > > http://javaplugin.sourceforge.net/ > > As best I can tell, the problem is completely resolved in recent > versions of Firefox (e.g. 1.0) and Camino (e.g. 0.8.2), and > partially resolved in Mozilla (1.7.3, 1.7.5 and 1.8a). The > remaining issues with Mozilla are, I believe, Mozilla's fault (I'll > deal with this in a separate message, after I've had a chance to > file a bug report). I've opened bug 277067 ("Mozilla mistimes changing Java applet visibility when switching tabs"). I expanded the scope to include the problems with Firefox we've discovered here. I strongly suspect that both problems are, on some level, the same. I'm also pretty sure that both are the browsers' fault (i.e. are due to bugs in Mozilla and Firefox).

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

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

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

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

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

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

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

Another site that causes this problem: http://members.cox.net/gretnawx/Data/current_weather.htm

another one is this http://musica.libero.it/lifegateradio/pl_libero/plmac.htm

Well, at least the last example seems to cause the misdrawing issue for me even though I am using JEP and a trunk build from 2 days ago (although I am using the optimized g4 builds so not official). Since I'm not actually clear how firefox knows which plugin to use (both java plugins are listed though JEP is newer...I presume this was what all that bit about checking the file modification time was about. Unless, I'm very confused doesn't this show that JEP doesn't resolve these issues. Also, how would one check if a case belonged in the 'mistiming redraw' bug or just in this bug? Or is this something one would need to add debugging statements to a plugin to discover. Finally if this is really a cocoa/carbon API issue shouldn't it be fairly easy to whip up a short little program documenting the API error? Or was this assertion just a guess since we don't really know what is going on?

(In reply to comment #195) > Well, at least the last example seems to cause the misdrawing issue > for me even though I am using JEP and a trunk build from 2 days ago This page doesn't use any applets. And as of this morning, at least, it's broken on OS X -- nothing shows up in what I assume is its ticker. If you look at the page source you'll see no applet tags but two embed tags -- one (commented out) for the Flash plugin and one for the Windows Media Player! I assume the problems you had were with the Flash plugin, before it was commented out -- too bad that happened, because it's never been completely certain that this bug (bug 162134) is only an issue with Java applets. > how firefox knows which plugin to use (both java plugins are listed > though JEP is newer...I presume this was what all that bit about > checking the file modification time was about. Yes. > I'm very confused doesn't this show that JEP doesn't resolve these > issues. It doesn't resolve them completely. But it does a _much_ better job than Apple's Java Applet.plugin, even on Mozilla. The issues that remain are relatively minor. And (I think) they're caused by bugs in Mozilla and Firefox. > Also, how would one check if a case belonged in the 'mistiming > redraw' bug or just in this bug? Or is this something one would > need to add debugging statements to a plugin to discover. That's one of the reasons (the main reason) I added the "-Djep.debug.visibility" flag to JEP 0.8.9. Java Applet.plugin can't (of course) give you this information. I suppose I could add similar debugging code to the MRJ Plugin JEP, to see if there is any difference in how the Mozilla-family browsers behave when using Java 1.3.1. > Finally if this is really a cocoa/carbon API issue shouldn't it be > fairly easy to whip up a short little program documenting the API > error? While this is possible, I think it's unlikely. The timing issues are in Carbon-only browsers. In any case we certainly don't know _which_ API there might be an issue with.

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

We're not going to be able to hold 1.8b1 for this, but it would be really nice to fix this somehow. (Yes, I've read comment 83, but is there nothing we can do?)

I don't buy that. Safari doen't show this problem (with tabs), so they must be fixing it somehow. This bug should be attacked as hard as possible because it is a killer. The first time a user sees this, it will go right back to Safari/IE/Opera.

(In reply to comment #198) > We're not going to be able to hold 1.8b1 for this, but it would be really nice > to fix this somehow. (Yes, I've read comment 83, but is there nothing we can do?) Well, I think a good start would be to try and narrow down exactly what API has the error or problem. At the moment we seem to have a much to vague grasp of what is going on to say what is or is not possible. The fact that safari doesn't have this bug doesn't necessarily mean it is fixable (they use a completly differnt java plugin interface no?) but without much more detail about what is going wrong I think it is silly to assume their is no workaround.

Some reason why this really is hard: 1. When the plugin API was developed, oh, 8-10 years ago, no-one had heard of browser tabs. A plugin was either in the window, or it wasn't. There is no affordance in the NPAPI for the browser to tell a plugin that it is in a non-visible tab. As a result, we've had to use SetWindow(NULL) type things, but these require the plugin authors to pay attention to them. Not all plugins do. 2. The Mac OS X browser and plugin space is complex. Not only are there both CFM and Mach-O plugins, but the drawing environments in the different browsers are different: Safari is a pure cocoa app, Camino uses QuickDraw in a cocoa framework, and mozilla/ff are pure QuickDraw. This affects stuff like tab drawing, and drawing coordinates. 3. Some plugins draw on threads (Java), so you have synchronization issues tell it not to draw. 4. Some plugins (QuickTime, Real) do Quartz Extreme acceleration stuff, which can interfere with the browsers attempts to do clipping or hide widgets in non-frontmost tabs. There are obvious bugs in some plugins related to this (Director draws at the wrong offset when using the hardware renderer). Finally, Mozilla has less clout with plugn vendors than Apple does. It's hard to get them to address the bugs in their plugins that we need to get fixed.

I realize the symptoms are completely different and please forgive my ignorance of relevant architecture, but if QuickDraw vs Quartz is potentially part of the problem here, is there any chance that Javier's patch for bug 245407 will have any bearing on this issue?

No, bug 245407 has no bearing on this. It just affects images.

I looked again at this. First off, the issue is worse in Firefox/Mozilla than Camino because Camino has this: <http://lxr.mozilla.org/mozilla/source/widget/src/cocoa/nsChildView.mm#1178> Mac widget needs to do something similar, but we'll have to feed the notfication all the way down the widget hierarchy when a widget is made invisible. Second, I have a minor patch that makes Java better (tested in Camino, because it relies on the code above). I also was not able to see any problems with QuickTime. However, Real contents is most serious; it draws over all tabs, and even resizing the window or getting the page to redraw does not erase the Real bits. It seems that they are being drawn to the screen via OpenGL or something that is bypassing clipping. (Interestingly, if the plugin is scrolled partially offscreen, it doesn't stomp over other tabs. I bet it falls back into a software rendering path there.)

mInstance->SetWindow(nsnull) is a no-op (since ns4xPluginInstance::SetWindow() does a null-check and bails) so there's no point calling it. Rather, make sure the clip rect is empty if the plugin is not visible, and call mInstance->SetWindow(mPluginWindow) which (depending on the plugin) may or may not get it to take notice.

Hrm. I can almost fix Real by sending it a fake nsPluginEventType_ScrollingEndsEvent event at hide time (maybe this gets it to notice the changed clipping bounds). It draws once over the new tab, but is at least erasable. I'm testing with the plugin installed by RealPlayer 10.0.0 (v325).

If you need any info from the Real side, the mac guys are on player-dev@helixcommunity.org & can hopefully answer any questions. I'm a linux guy myself.

If all else fails, can't you lie to the plugin and tell it the window's withdrawn/hidden or offscreen?

Would transitioning all of Mac gfx to Quartz probably fix this, Simon? (Yes, it would be a monumental task, I know. Just curious.)

I don't think moving to Quartz would help. Regarding Java specifically, there are several issue so to be aware of: 1. There are potentially 3 java plugins out there: i) Apple's "Java Applet" plugin ii) Netscpe's "MRJ Plugin" (now unmaintained) iii) Steven Michaud's "Java Embedding Plugin" (JEP). The latter 2 both have fewer drawing problems on scrolling, and in tabs. For simplicity, I was testing with only the Apple plugin, since it's the worst offender. 2. Drawing issues are worse in Firefox than Camino. For reasons that I don't fully understand, Camino is much better behaved plugin-wise. I don't believe that it's simply because Camino is Cocoa, because plugins in Camino actually draw to a a window-level GrafPort. Clipping etc. should be set up the same for plugins in both browsers. I have a patch that helps prevent some Java applets drawing through tabs in Firefox, with Apple's plugin. I can fix the drawing of this one: <http://java.sun.com/applets/jdk/1.4/demo/applets/Animator/example4.html> But this one still draws through tabs, and leaves crud while scrolling: <http://members.cox.net/gretnawx/Data/current_weather.htm> I do not understand why these applets behave differently. If anyone can enlighten me, that would be good. Finally, perhaps we should just ship the Java Embedding Plugin, since it fixes these, and other Java issues, and allows Mozilla browsers to run the Java 1.4 VM.

This patch does for Mac widget what Camino does when hiding tabs. It should help with the timing issue described in bug 277067.

> Finally, perhaps we should just ship the Java Embedding Plugin, since it fixes > these, and other Java issues, and allows Mozilla browsers to run the Java 1.4 VM. FYI, its current licence is BSD.

The problem on this site: <http://members.cox.net/gretnawx/Data/current_weather.htm> appears to only have to do with the scrolling marquee at the top of the page. This site is operated from my hometown and I check it frequently; since I installed the Java Embedding Plugin for Firefox I have not had trouble with any of the other scripts (such as moon phase) -- just the marquee. It appears that code specific to the marquee and not to the moon phase causes the problem.

(In reply to comment #213) > The problem on this site: > > <http://members.cox.net/gretnawx/Data/current_weather.htm> What plugin and browser are you using? I am using a recent g4 optimized firefox trunk build with the JEP and can't reproduce any junk in other tabs. It's good to see progress being made to narrow down the exact cause of this bug and in what API the problem rests. Though it might take some work I don't think we can really say much about whether the problem is solveable or not until we have a much better idea exactly where the bug is coming from.

(In reply to comment #214) > (In reply to comment #213) > > The problem on this site: > > > > <http://members.cox.net/gretnawx/Data/current_weather.htm> > > What plugin and browser are you using? I am using a recent g4 optimized firefox > trunk build with the JEP and can't reproduce any junk in other tabs. > Firefox 1.0 20041107 JEP 0.8.9

> Created an attachment (id=174692) [edit] > Patch to get mac widget to invalidate plugins on widget hide > > This patch does for Mac widget what Camino does when hiding tabs. It > should help with the timing issue described in bug 277067. I've now compiled this patch into CVS versions of Mozilla and Firefox (pulled this morning), and tested both of them with the latest JEP (0.9.0). It seems to make no difference with Mozilla -- the problem (as described at bug 277067) is as bad as ever. It also seems to make no difference with Firefox when using the procedure described above in comment #180. It _might_ help a bit when using the procedure described here in comment #184 ... but it's hard to tell. The waters are muddied by the fact that an unrelated post-Firefox-1.0 change has a fortunate (but entirely accidental) side effect on this problem (see https://bugzilla.mozilla.org/show_bug.cgi?id=277067#c12). Patched Firefox's behavior is (I think) pretty definitely better than Firefox 1.0's with comment #184's procedure ... but then so also is that of the latest Firefox nightly (2005-02-18-08-trunk).

> > Finally, perhaps we should just ship the Java Embedding Plugin, > > since it fixes these, and other Java issues, and allows Mozilla > > browsers to run the Java 1.4 VM. > > FYI, its current licence is BSD. I thought the MPL was compatible with a BSD-style license. What I envision is the Mozilla-family distros including a snapshot of the JEP (once the JEP is out of beta). The JEP would continue to maintain its separate existence (and keep its current license).

I'm having a hard time getting a patch that works for both JEP and Real. The RealPlayer plugin has a requirement that we have to call SetWindow() on it any time the location or clipping change. If I do this, then JEP in Firefox is OK, but JEP in Camino doesn't draw at all. Stephen, I think we should define from scratch how tab swapping interacts with plugins, fix Firefox and Camino to follow that, and then fix JEP accordingly. There's no point you wasting time hacking around our bugs :) Here's what I suggest: * Before the tab hosting plugin is hidden, we set the clip rect on each plugin to an empty rect, and call SetWindow() on the plugin. * After the tab hosting a plugin is shown (this maybe later, at paint time), we reset the clip rect on each plugin, and again call SetWindow(). Now let's make this the same in FF, Mozilla and Camino, and figure out where we deviate from it.

> Stephen, I think we should define from scratch how tab swapping > interacts with plugins, fix Firefox and Camino to follow that, and > then fix JEP accordingly. Excellent idea. Maybe one day there'll be an API for tabbed browsing, but for now I'll settle for this :-) > Here's what I suggest: > > * Before the tab hosting plugin is hidden, we set the clip rect on > each plugin to an empty rect, and call SetWindow() on the plugin. > * After the tab hosting a plugin is shown (this maybe later, at > paint time), we reset the clip rect on each plugin, and again > call SetWindow(). Over the next few days I'll rescan the code, do some tests, and think through the implications of this. In the meantime do keep working on your own, and don't be afraid to fiddle with this. If we keep in touch, it should be possible to iron out any problems that may arise.

Now that I understand some of the issues here, there are two problems: 1. Apple's Java plugin has multiple redraw issues (we'll address this by using the JEP) 2. There are issues with plugins that use QuickTime (which includes the Real plugin), which only affect Camino. I've spun those off into a Camino- specific bug, bug 283120. I'll leave this bug open for the Java issues. If anyone sees plugin drawing issues in Mozilla/Firefox which do *NOT* involve Java, please comment here.

Quicktime still has scrolling problems for the test cases in comment #64, and comment #81. Simon, do you have a sense at this point whether that's the same issue as through-tab drawing?

Camino Quicktime tab drawing issues are covered by bug 156583. Camino Quicktime scrolling issues are covered by bug 160435.

(In reply to comment #222) > Camino Quicktime tab drawing issues are covered by bug 156583. > Camino Quicktime scrolling issues are covered by bug 160435. So those should be changed to Core to cover Mozilla/Firefox?

Bill: I tried scrolling and switching tabs with a QT movie in FF and didn't see the same kind of issues that Camino shows. The movie area does go blank sometimes, but that's a different issue. If you see scrolling issues in FF, please post a screenshot (in an image format like PNG please, not pdf).

Perhaps a clue - taking a screenshot of the scrolling problem with cmd-shift-4 does not result in a picture file with the damage. I got these with a timed-screenshot from Grab. This is with a SeaMonkey nightly from last week.

Bill: do you see this on any non-QT VR pages?

This attachment is mostly an illustration that the Quicktime plugin is out of its mind. Here it's drawing over Apple Mail (content loaded in a Mozilla window). I would guess this behavior is also what causes it to draw through Fast User Switching logins.

Simon: I've only seen it with QTVR. See URL in bug 171382.

I get the Quicktime redraw issue on my own page with embedded mov files. I have a single frame mov displayed when the page loads, and it loads the actual mov file when clicked on. When you scroll the page before clicking on any of them, when you do, one of them (and this may be an issue with the embedding code on the page?) one of them bleeds off the window onto the desktop. It actually plays in place, but it flashes the opening frame of the mov on top of the edge of the window, which then erases the portion on opt of the window, but the remmnant that was outside the edge of the window is left on the desktop. This is in Mozilla 1.7.5, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 OSX 10.3.8

I get the Quicktime redraw issue on my own page with embedded mov files. I have a single frame mov displayed when the page loads, and it loads the actual mov file when clicked on. When you scroll the page before clicking on any of them, when you do, one of them (and this may be an issue with the embedding code on the page?) one of them bleeds off the window onto the desktop. It actually plays in place, but it flashes the opening frame of the mov on top of the edge of the window, which then erases the portion on opt of the window, but the remmnant that was outside the edge of the window is left on the desktop. This is in Mozilla 1.7.5, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 OSX 10.3.8

Comment on attachment 175193 [details] QT redraw on embedded mov Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217

That URL in the screen capture is http://www.hangdogproductions.com/video.html, and I created the page in Golive CS.

Do the Java fixes released today (Feb. 23) affect this bug?

I've posted patches that (as far as I can tell) completely fix bug 277067's timing problem (which can lead to ghosts when switching tabs that contain plugins). Please check them out! https://bugzilla.mozilla.org/show_bug.cgi?id=277067#c23

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

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

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

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

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

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

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