Closed Bug 162134 Opened 22 years ago Closed 7 years ago

[OSX] Java applets draw on wrong tabs

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: bill+mozilla-bugzilla, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, testcase, top100, Whiteboard: [sg:spoof][adt1][need info][ETA: vendor update])

Attachments

(14 files)

realplayer test case
252 bytes, text/html
Details
Real testcase for 20030308
35.67 KB, application/pdf
Details
tab draws through plug-in
105.86 KB, application/pdf
Details
Text draws through loading image
141.64 KB, image/jpeg
Details
Screenshot of issue from comment #161
89.66 KB, image/png
Details
Patch that helps Java in Camino
2.53 KB, patch
Details | Diff | Splinter Review
Patch to get mac widget to invalidate plugins on widget hide
1.62 KB, patch
Details | Diff | Splinter Review
Screenshot of Comment #64 testcase
257.22 KB, image/png
Details
Screenshot of Comment #81 testcase
204.39 KB, image/jpeg
Details
Screenshot - Quicktime draws over other applications
204.66 KB, image/jpeg
Details
QT redraw on embedded mov
184.61 KB, image/jpg
Details
QT redraw on embedded mov
184.61 KB, image/jpg
Details
image leftovers
186.62 KB, image/png
Details
Tabs drawing
109.66 KB, image/png
star_82
: feedback+
Details 
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.
Summary: using apple java plug-in applets draw on wrong tabs → plug-ins draw on wrong tabs
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.
Assignee: joe.chou → babak.mahbod
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.
QA Contact: pmac → petersen
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
Assignee: mahbodb → peterl
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. ***
Priority: -- → P3
Target Milestone: --- → Future
*** Bug 194328 has been marked as a duplicate of this bug. ***
The patches in bug 191821 may affect this.
Summary: plug-ins draw on wrong tabs → Java plug-ins draw on wrong tabs
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.
Summary: Java plug-ins draw on wrong tabs → plug-ins draw on wrong tabs
Summary: plug-ins draw on wrong tabs → (java and real) xpcom plug-ins draw on wrong tabs
*** 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?
Keywords: realplayer
Summary: (java and real) xpcom plug-ins draw on wrong tabs → (Java and Real) XPCOM plug-ins draw on wrong tabs
Component: OJI → Plug-ins
*** 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.
Summary: (Java and Real) XPCOM plug-ins draw on wrong tabs → [OSX] (Java and Real) XPCOM plug-ins draw on wrong tabs
*** Bug 200329 has been marked as a duplicate of this bug. ***
Summary: [OSX] (Java and Real) XPCOM plug-ins draw on wrong tabs → [OSX] (Java and Real) XPCOM plug-ins draw on wrong tabs and leave detritus during scroll
*** 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?
Flags: blocking1.4b?
Flags: blocking1.4b? → blocking1.4b+
It seems that the carbon widget code isn't setting up the clip properly for the
plugin, as the cocoa widget code does.
Assignee: peterl → sfraser
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.
Keywords: top100
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. ***
Flags: blocking1.4b-
Flags: blocking1.4b+
Flags: blocking1.4+
*** 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. ***
Keywords: testcase
*** Bug 206613 has been marked as a duplicate of this bug. ***
*** Bug 206768 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
(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.
Assignee: sfraser → peterl
*** Bug 207157 has been marked as a duplicate of this bug. ***
adt: nsbeta1+/adt1
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]
Whiteboard: [adt1] → [adt1][ETA: 5/29]
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.
Flags: blocking1.4+ → blocking1.4?
Whiteboard: [adt1][ETA: 5/29] → [adt1][ETA: vendor update]
Peter, 
In that case should this be an evangelism bug?  If so, please remove the
nsbeta1+ keyword.  Thanks.
Whiteboard: [adt1][ETA: vendor update] → [adt1][need info][ETA: vendor update]
Keywords: nsbeta1+
<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.
Flags: blocking1.4?
*** 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.
Summary: [OSX] (Java and Real) XPCOM plug-ins draw on wrong tabs and leave detritus during scroll → [OSX] (Java, Real, QuickTime) XPCOM plug-ins draw on wrong tabs and leave detritus during scroll
*** 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. ***
Blocks: majorbugs
*** 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. ***
Summary: [OSX] (Java, Real, QuickTime) XPCOM plug-ins draw on wrong tabs and leave detritus during scroll → [OSX] (Java applet, Real, QuickTime) XPCOM plug-ins draw on wrong tabs and leave detritus during scroll
*** 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. ***
Severity: normal → major
*** 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?
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.
Flags: blocking-aviary1.0mac?
*** Bug 258947 has been marked as a duplicate of this bug. ***
*** Bug 260055 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a4?
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. ***
Flags: blocking1.8a4? → blocking1.8a4-
*** 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. ***
Flags: blocking-aviary1.0mac?
*** 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).
Blocks: 277067
*** 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. ***
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.
Flags: blocking1.8b?
Flags: blocking-aviary1.1?
*** 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?)
Flags: blocking1.8b?
Flags: blocking1.8b2?
Flags: blocking1.8b-
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.)
Assignee: peterl-bugs → sfraser_bugs
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.
Status: NEW → ASSIGNED
> 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.
Summary: [OSX] (Java applet, Real, QuickTime) XPCOM plug-ins draw on wrong tabs and leave detritus during scroll → [OSX] Java applets draw on wrong tabs
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
Attachment #175193 - Attachment mime type: image/png → image/jpg
Attachment #175194 - Attachment mime type: image/png → image/jpg
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. ***
*** Bug 291127 has been marked as a duplicate of this bug. ***
*** Bug 293899 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b3?
Flags: blocking1.8b2?
Flags: blocking1.8b2-
No longer blocks: majorbugs
*** Bug 296556 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking1.8b2-
Flags: blocking1.8b-
Flags: blocking1.8a4-
Flags: blocking1.4b-
*** Bug 298791 has been marked as a duplicate of this bug. ***
*** Bug 299903 has been marked as a duplicate of this bug. ***
We're not gonna make this for 1.1
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 301224 has been marked as a duplicate of this bug. ***
*** Bug 301111 has been marked as a duplicate of this bug. ***
*** Bug 301943 has been marked as a duplicate of this bug. ***
*** Bug 304270 has been marked as a duplicate of this bug. ***
*** Bug 306773 has been marked as a duplicate of this bug. ***
Is this fixed now?  I stopped seeing this after upgrading to the Firefox 1.5
betas...  Java seems to behave itself now.
(In reply to comment #254)
> Is this fixed now?  I stopped seeing this after upgrading to the Firefox 1.5
> betas...  Java seems to behave itself now.

It's weird.  It seems to be a bit better now (Mozilla/5.0 (Macintosh; U; PPC Mac
OS X Mach-O; en-US; rv:1.9a1) Gecko/20051001 Firefox/1.6a1) in that you don't
get continuous draw-through, but sometimes you still get "leftovers" after
switching tabs.  The animation doesn't draw through, but you get a still frame
on the tab you switched to.  I'll attach a screenshot.
The JEP contains some fixes for this bug, and workarounds bug 277067.
Attached image image leftovers — 

    
    

    
  
(In reply to comment #256)
> The JEP contains some fixes for this bug, and workarounds bug 277067.

I didn't install the JEP.  Is it installed by default in Deer Park? (Also, my
Firefox 1.0.7 on the same machine does still have the animation drawing through
problem.)

Sounds like the artifacts I'm seeing are from bug 277067, so possibly this bug
is fixed?

    
    

    
  
(In reply to comment #258)
> I didn't install the JEP.  Is it installed by default in Deer Park?

Yes

> Sounds like the artifacts I'm seeing are from bug 277067

Yes

> so possibly this bug is fixed?

Perhaps.
No longer blocks: 277067
Depends on: 277067

    
    

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

    
    

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

    
  
Whiteboard: [adt1][need info][ETA: vendor update] → [sg:spoof][adt1][need info][ETA: vendor update]

    
    

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

    
    

    
  
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060105 SeaMonkey/1.5a

It still seems to be happening to an extent.  Only what's happening now is that some applets flash on the new tab and then disappear, and others leave a still image (or part of one) on the new tab.
Assignee: sfraser_bugs → nobody
Status: ASSIGNED → NEW
QA Contact: chrispetersen → plugins

    
    

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

    
    

    
  
I went through the most recent comments (#240 and after) and checked those duplicate bugs to see if there were still any working testcases.  I found 3 but the only issue is that they don't disappear immediately on switching but appear for a fraction of a second.

http://www.us.map24.com/
http://radar.weather.gov/radar.php?rid=dax&product=N0R&overlay=11101111&loop=yes
http://www.epemag.wimborne.co.uk/

The quicktime issue is still alive and kicking (see URL from #233 http://www.hangdogproductions.com/video.html) and Bug 403532.

    
    

    
  
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0 ID:2008051202

http://www.sandiegozoo.org/videos/elephants_snow_day2-25-05.html

I hadn't seen this for some time but on FX 3RC1, the embedded real player at the above site is coming through on other tabs

    
    

    
  
(In reply to comment #267)

I see this too, though only on the trunk (aka the 1.9.0 branch).

The problem starts happening with the 2006-09-29-trunk nightly --
i.e. with the switch to Cocoa widgets.

If this has been a problem (on the trunk) for so long, I wonder why
there've been so few reports.  Could it be that it only happens with
the current version of the Real plugin?

I tested on OS X 10.5.3 with the current Real plugin (whose version
appears to be 10.1).


    
    

    
  
I'm on 10.4.11 and a version of Real Plug-In dated 4/27/2007 (no version string in Finder or about:plugins).  I get the current frame drawing through tabs, but not the full motion video (of example in comment 267).



    
    

    
  
Another good test case can be found at this <A href="http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzahy/rzahyaclco.htm"> site</A> (at ibm.com).  It's way to hard to download and isolate at the moment though.

    
    

    
  
(In reply to comment #270)

What you report isn't this bug's general problem, but is a specific
bug in the Java Embedding Plugin (which is bundled with Mac distros of
Mozilla.org browsers, and which provides Java support on the Mac).

Or more likely it's a newly uncovered Apple bug that the JEP will need
to learn how to work around.

The testcase you've given is the only example of it that I'm aware of.

Please open a new bug on this issue -- either at
https://bugzilla.mozilla.org or at the JEP's bugs tracker
(http://sourceforge.net/tracker/?atid=649116&group_id=107955&func=browse).

Thanks in advance for your new bug.

By the way, I was able to reproduce your report in Firefox 3.0.7 on OS
X 10.5.6.  I don't see it in Safari (on OS X), or in Firefox 3.0.7 on
Windows XP.

    
    

    
  
I'm having a similar issue with Java on firefox.  I recently signed up for playsega.com which uses java applets to play old genesis games.  When loading the games in firefox they appear to load fine but the images appear off centered and if you switch tabs the applet shows on all tabs.  Strangely enough if you try to play a different game they will not load at all unless you close firefox and reopen it.  

They seem to work without any issue at all in Safari.

I'm using Java Plug-in 1.6.0_17 on OS X 10.6.2 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7

I have tried it on my desktop running Windows Vista ultimate, firefox 3.5.7 and the latest java plugin and there is no such problem.  

I can reproduce this every time as well.

I'd be more than happy to include even more information but Im not sure what the cause of this error is.

    
    

    
  
(In reply to comment #272)

I'll bet playsega.com's Java applets use Java3D.  If so, what you report is a dup of bug 425278.

    
    

    
  
I suspect the problem I noticed is related to Java, so I will report it here.
When I enter a URL into http://keepvid.com/ and it finds a useable link, a Capcha-type window opens with distorted nonsense words for me to type to show that I am a human being.

It does not show in Firefox 3.5.7 in Mac OS X 10.6.2, but it does in SeaMonkey 2.0.1 and in Camino 2.0.1, as well as in Safari 4.0.4.

    
    

    
  

      
      
      
      

        Attached image
          
        Tabs drawing
        — 
      

    


  

        Attachment #471128 -
        Flags: feedback+

    
    

    
  
Tabs drawing. See attachment.

    
    

    
  
test1

    
  
Flags: wanted-fennec1.0?
Flags: in-testsuite+
Flags: in-litmus+

    
    

    
  
apologies to the people who's CC just got remove and put back.  The vandal has been banned.
Flags: wanted-fennec1.0?
Flags: in-testsuite+
Flags: in-litmus+

    
    

    
  
I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: