Steps to reproduce bug: 1. Go to http://www.atomfilms.com 2. If you don't have the Shockwave Flash, select the HTML Only page 3. BUGBUG: The menu bars on the top ("Now Showing, Film Catalog, Film News, Atom Store") and bottom ("About Atom | Submit Film | Partners | Site Map | Contact Us") of the page are cut off horizontally by the huge graphic in the center of the page. Under IE4 and Netscape 4.51, the menu bars are drawned correctly. I found this bug on Windows 98. I don't know if this bug is on other platforms.

Actually, it's OBJECT tag and not plugins. The problem is that the OBJECT frame code isn't setting the max-element-size correctly. You can see by looking at the debug output: created stream for http://www.atomfilms.com/top_nav.swf nsLineLayout: ObjectFrame(embed)(9)@01059770 didn't set max-element-size! nsLineLayout: ObjectFrame(embed)(9)@01059770 didn't set max-element-size!

This URL renders black for me, Win32 apprunner. Resummarizing per troy's comment.

It crashes now on string conversion added by scc. Scott, mMimeTypeDescriptionArray can be null, we should allocate it somehow differently to avoid the crash. DOMMimeTypeImpl(nsPluginTag* aPluginTag, PRUint32 aMimeTypeIndex) { NS_INIT_ISUPPORTS(); mDescription.AssignWithConversion(aPluginTag->mMimeDescriptionArray[aMimeTypeInd ex]); mSuffixes.AssignWithConversion(aPluginTag->mExtensionsArray[aMimeTypeIndex]); mType.AssignWithConversion(aPluginTag->mMimeTypeArray[aMimeTypeIndex]); } Reassigning to scc for having a look.

Dude, I just change the assignment that was already there to be |AssignWithConversion|. If |mMimeDescriptionArray| can be |0|, then this was a bug before my change as well, and the fix is obvious. No description array --> no description; therefore, make the current method invocation conditional if ( aPluginTag->mMimeDescriptionArray ) mDescription.AssignWithConversion(aPluginTag-> mMimeDescriptionArray[aMimeTypeIndex]); similarly if any of the other members can be |0|. |mDescription| will already have been default initialized to the empty string by it's own constructor. Assigning back to you to make the fix, if you deem it appropriate, and to possibly `fix' the other cases as well? You have the knowledge of what string sources are allowed _not_ to exist... so you have to do the typing :-) Hope this helps

Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because the Netscape engineer it is assigned to is overburdened.

Ok Marc, this one is similar to the one I sent you the other day. Actually, this is the problem.

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

Looks like this is causing a problem on the Shockwave.com, under games now. They probably changed their HTML. This happens on Mac and Windows, chaning platform to all. CC:ing table god Karnaze as the table is too wide. But, this may be a problem in core layout. Clearing milestone for new triage. Debug window spits out: nsLineLayout: ObjectFrame(object)(0)@05CF963C didn't set max-element-size! nsLineLayout: ObjectFrame(object)(3)@05BEA7CC didn't set max-element-size!

Probably a dup of 72427. Leaving open because not sure.

Reassigning to myself.

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

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

Petersen/Shrirang: When verifying the fix for THIS bug, can you also be sure that ALL of the dups, of dups, of dups are verified FIXED by THIS patch too.....Thanks!

The patch is in.

A 0.9 user on Win2000 keeps seeing a dup of this, bug 72427. He filed it as bug 81812. All tricks seem to fail - the page with flash persistantly sizes wrong. Did this fix make it into 0.9?

The patch was checked in but only initializes the max element sizes. Maybe a bug has been marked as a dup of this incorrectly. Also, to make matters worse, some of the cases only failed in an optimized build.

I don't think this made it to mozilla 0.9, but I may be wrong. What's the build date of the Win2000 user?

2001050515

Marking verified fixed in the May 25th build.

2001-06-12-22-trunk (win32) build shows this bug again.

Shouldn't this therefore be reopened? In all honesty, I think bug 86075 should be marked as a dup of this, important comments shuttled over, and this bug reopened. Why do we need two bugs open for the same problem?