These tags work in current browsers, but I couldn't get it to work with gecko: <div id="ShowTab1" style="position:absolute; left:0px; top:59px; width:138px; height:30px; z-index:2; visibility:visible"> <div id="NoShowTab1" style="position:absolute; left:0px; top:59px; width:138px; height:190px; z-index:2; visibility:hidden"> I use these, and switch between the two via javascipt and the z-index.

Can you give me a better test case? I made a simple test case and it works for me...Also, the url you've given me is a frame-set. Which frame-cell has the problem page? thanks...

Email from dustin: Here's the frame link: http://www.e-corp.com/home_nav.asp when i looked at it in gecko, all the text in the hidden divisions was shown. now that i think about it, it could be a javascript or a css problem, because javascript unhides layers according to which image you click on. Thanks, Dustin

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Probably fixed, but since you are the minister of things positioned absolute (ahem), I figured you should look into it.

Looks like it works to me, too

Using the 3/26 build, there is still bug behavior. The frame should display with 8 orange menu items. When clicked on, the orange bar turns yellow and a drop down menu displays. Geckco is displaying the 8 menu items in yellow, not orange. Clicking on them does not display a drop down menu and, at the end of the items there is residual drop down information from the 'Press Room' section. Reopening bug.

You're describing three separate problems, and they need to be addressed in three separate bugs. We need very specific test cases that determine whether each of the problems are layout of HTML or DOM The problem is it is very time consumming to narrow these kind of bugs down

unlikey this is going to be fixed in M6. chris, any luck in trying to get to a narrower test case?

Using 6/14 Apprunner, the display problems spelled out in the 3/26 comments no longer appear. However, drop down (using the frame link from 12/14 comments) do not work. It looks to be a javascript problem but that is not my expertise so I am unable to break down the sample test case further. Reassigning back to engineer.

Chris -- Running viewer under NT looks exactly like Nav4.5. I need a test case to see what the problem is, or we should close this.

I tested the frame link using 6/19 Viewer and Apprunner on NT: Nav 4.5 behavior: When you click on a dark orange option, two things happen - (1) orange link turns yellow and you get a drop down menu (2) a new window comes up related to the first drop down item. Viewer behavior: When you click on a dark orange option, a new window comes up related, but the dark orange option does NOT turn yellow and a drop down menu DOES NOT display. Apprunner behavior: When you click on a dark orange option, nothing happens. However, the console does indicate that a page is loading.

Ah -- missed that. Thanks Chris. Kevin -- let's start with widgets, but this could be a script or event bug. Please take a closer look.

Looks like they are using document.layers to display and animate the drop-down menus. document.layers[moveobj].ypos = parseInt(document.layers[moveobj].top) if (document.layers[moveobj].ypos > (tabtops[movetab] - mfactor)) { for(movetab; movetab < arraylen; movetab++) { moveobj = tabs[movetab] document.layers[moveobj].ypos = parseInt(document.layers[moveobj].top) document.layers[moveobj].ypos -= 5 document.layers[moveobj].top = document.layers[moveobj].ypos} setTimeout("objslide()",30)} Are we supporting document.layers? Vidur, Please take a look at the document.layer code in the far left frame.

Wow, this one's been around. The original initial layout issues look OK. The nifty sliding menus aren't going to work because our lack of JS access to the document.layers array. Passing along to ekrock to put on our layers pile.

INVALID. LAYER, ILAYER, document.layers[] not supported in Gecko/Nav5. Closed. Notified reporter and site owner via template at http://sites.netscape.net/ekrock/fixit/layer.html

Verified invalid

Moving all [LAYER] bugs to Evangelism component for tracking and open-source evangelism by mozilla community members of sites that need to upgrade to support web standards such as HTML 4.0 (instead of LAYER/ILAYER) and the W3C DOM (instead of Nav4 document.layers[] or IE document.all()). Sites should be lobbied to do the upgrade using the email templates that are linked to from http://www.mozilla.org/newlayout/bugathon.html#layerbugs . When a site's owner has confirmed receipt of the message requesting an upgrade, the bug should be marked with the keyword evangelized to indicate that evangelism for that bug is complete. When the site finishes the upgrade and supports standards, the bug should be closed.

Marking bug evangelized and clearing cc:s.

Reopening to register fact that this page isn't yet upgraded (until it is, at which point we'll close the bug).

SPAM:Changing QA contact on 111 evang bugs as I am now the new QA contact for this component. Sorry about the spam zach

Reassigning Evangelism bugs to me, the component's new owner. I would like to take this opportunity to thank nobody@mozilla.org for all of his dedication, contributions, and hard work, and wish him luck at his new job. Thanks, nobody.

Removing the evangwanted keyword from 49 evangilizm bugs that also have the evangelized keyword. Having both of these keywords on a bug makes it really hard to do a query for all open evangilizm bugs that are evangwanted. Sorry for the spam.

Sorry about this problem. I somehow screwed up the keyword changes. Sorry about this spam.

Site has been evangelized.

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.

it's dead jim