Attempting to create a new AWT window, saw a frame, don't work. There are some log messages about registering menus and windows, but no window shows up.

Yep - this code needs to be hooked up.

Reassigning all OJI bugs to george.drapeau@eng.sun.com

Reassigning bug to mark.lin@eng.sun.com Yuup. I'll probably investigate this next.

m12

m13

move to m14. let me know if fixes are available. thx.

mark is dead. long live mark.

moved to assigned to get bugzilla mailing to daemon to shut up. moved milestone to m17 per new sun deployment policy.

reassigning to loki-sun

the dependency was closed because the reporter (who's quit) hadn't provided more information.. investigating whether 14413 can really be closed.

moving off of "NEW" to assigned.

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

Beard, can you take this? Ed

Added a couple of words to the summary to make it come up in Java and MRJ searches, so people have a chance of finding it rather than filing duplicates! Also, loki left Sun months ago. Assigning to default component owner

I have posted a small applet demonstrating this problem at: http://segal.org/FrameTest/ The problem occurs in Netscape 6.0 for Macintosh but not in Netscape 4.73 with the MRJPlugin. Source code for the applet is as follows: import java.applet.*; import java.awt.*; public class FrameTest extends Applet { public void init() { Frame frame = new Frame("A frame"); frame.reshape(100, 100, 300, 300); frame.validate(); frame.show(); } public void paint(Graphics g) { g.drawString("A very simple frame should pop up", 10 , 20); } } // END OF Class FrameTest

qa: junruh

Is anyone looking at this bug ? As of today, it still exists on the mac trunk and branch builds. I do not see the frame pop up with the testcase attached. This however works in 4.x and IE.

I feel that this bug is really important so I am adding this comment to encourage someone to take ownership of it and work on it. I think the bug should get high priority for the following reasons: 1. This bug leaves a major JDK 1.0 class, Frame, unable to function, and makes Netscape 6 fail Java certification. 2. Attempts to use Frame terminate an applet, providing a very bad user experience. 3. Since many applets run in a Frame, this bug makes it difficult for programmers to use their existing applets to find other bugs, further slowing down the process of getting the MRJPlugin for Netscape 6 to work. 4. This works fine with the Netscape 4.x MRJPlugin so it shouldn't be a major effort to get the same thing to work for Netscape 6.

Yep, you win. Somebody is on this one now; Ed Burns is out on vacation this week and so did not update the bug report. We have a new person starting on Mac/OJI bugs; you'll see progress on this bug before too long.

just fyi, frames work in 4.76

Hi Terry, I'm putting this in your list.

Here's diffs to two files to try to fix 6872. It also seems to fix the Java Console bugs: 21971, 27407, 68207, and 31670. I'm using Mozilla 0.7, MacOS 9.1, and based the changes on MRJPlugin 1.0b2, both today's and the original 1.0b2 check-in. Same workaround as was necessary for 4.x. Used Patrick's code to intercept events and handle things ourselves. Placed the necessary calls in TopLevelFrame::showHide(). Re-enable the hack in MRJContext.cp which gives the applet viewer extra time to go away before tossing our new windows. Questions: do I select 'WorksForMe'? Are the existing calls to thePluginManager2->RegisterWindow/UnregisterWindow useful/dangerous/redundant? Hmm. Bugzilla is not allowing me submit attachments. Here's the file: http://homepage.mac.com/tnoyes/.Public/Sun/Diffs%20for%206872

Hi Terry, Great to see someone getting some leverage on these bugs! Keep up the good work. I'm adding Mike Pinkerton and Simon Fraser to the cc: list as possible Mac reviewers. Terry, I don't know if you've already had an induction on this sort of stuff, but I figure its better to hear it twice than not at all. If you're looking to get reviews and have this stuff checked in (i.e. you're happy with the patch as it now stands) there are a few things you can do to indicate this: 1/ Send mail to reviewers@mozilla.org describing the changes and requesting reviews and super reviews (cc: appropriate people as desired) 2/ Add the keywords 'patch' and 'review' 3/ If there are lots of attachments, specify which should be reviewed in the status whiteboard 4/ While you're making all those changes, may as well add a comment inviting people to come get it while its hot :) That's what I do, but of course, the full process is described here: http://www.mozilla.org/hacking/reviewers.html Apologies if you knew all this already. Bit of pent up desire to get some of these fixed on my part, I suspect. Welcome aboard!

Add keywords 'patch' and 'review'. Should I make a compiled plug-in available for people to play with?

A couple of comments on the patch: 1. Are you using spaces everywhere? I've started to bite the bullet and just use 4-spaces instead of tabs. CodeWarrior Pro 5's IDE (v4.0.4) has an option for that. 2. I don't like all of the WORKAROUND_6872 comments. I'd prefer seeing the code in an #ifdef rather than surrounding it with these comments. 3. Perhaps all of this code should go in another source file, rather than being added directly to TopLevelFrame. It will make it easier to extract later when the browser gets fixed. BTW, you should "accept" your bugs rather than leaving them as new, so I can tell you're working on them.

Ok, I'll go to spaces instead of tabs, but all the other files seem to use tabs. Put stuff into a separate .cpp and .h file (have to add .cpp to project or xml file, of course). Thanks for the tip, I'll ACCEPT bugs.

Terry, have you asked for review on these?

Yes, on 2/19. E-mailed reviewers@mozilla.org

I'm reviewing again.

With this new patch, r=beard.

Have you asked for sr=scc on this?

Yes, on 3/16

Simon would also be a good candiate for super review.

sr=sfraser

Pending cvs id request approval...

April Update: no estimate on getting write access to the tree. Anyone else is welcome to check in these changes. For those interested, you can see when this patch lands by checking the cvs log for mrjplugin.xml, http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/plugin/oji/MRJ/plugin/MRJPlugin.xml as that file will be updated.

i can help land this once the tree opens and the waves upon waves of carpools clear up.

Going to check these changes in as soon as tree is open.

Checked in changes.

Thanks, Patrick. Just did a clean pull, build, and test and believe that bug #6872, bug #21971, bug #27407, bug #68207, bug #31670, and bug #69352 have been addressed. Time for new bug reports to roll in.

The fix for bug #6872 landed yesterday, and I've tested successfully with a yesterday build and a today build. Changing to FIXED. (The patch fixed bug #6872, bug #21971, bug #27407, bug #68207, bug #31670, bug #69352, bug #72585, and bug #74189)

Verified with the commerical trunk 200140608 Mac build.