Submenus remain fixed relative to browser window in Netscape

Having problems with DHTML Menu? There is usually somebody here who knows the answer.
Post Reply
JMM
Advanced
Advanced
Posts: 13
Joined: Tue Nov 11, 2003 10:47 pm

Submenus remain fixed relative to browser window in Netscape

Post by JMM » Tue Nov 11, 2003 11:04 pm

I apologize if this issue has been addressed previously. I did do a search, but it is difficult to tell whether people are describing the same problem I am experiencing.

I am using menu Version 5.0 Release Candidate 22.0 Built: Tuesday November 11 2003 - 11:38.

I have a horizontal primary menu that is positioned using screenposition="center" and a top offset, which triggers vertical submenus that are positioned using screenposition="center" and left and top offsets.

I'm on Windows XP. In IE 6, once the submenu is displayed, as the browser window is scrolled up and down the submenu maintains its position relative to the other elements of the page, the desired behavior. In Netscape 7.1, as the browser window is scrolled up and down the submenu maintains its position relative to the browser window -- that is, it maintains a fixed distance from the top of the browser window and does not maintain its position relative to the other elements of the page.

I guess the first question is which is the intended behavior? It would seem to me that it must be the IE behavior, because in both browsers the main horizontal menu behaves the same -- maintaining its position relative to other elements of the page -- even though it is positioned using a top offset just as the submenus are.

See http://www.capitalandanimalhospital.com, mouse over the Services link, then mouse off of it without mousing over one of the other links. The Services menu will appear and remain in the left bar. Then scroll your browser window up and down.

User avatar
kevin3442
Milonic God
Milonic God
Posts: 2460
Joined: Sat Sep 07, 2002 12:09 am
Location: Lincoln, NE
Contact:

Post by kevin3442 » Wed Nov 12, 2003 2:18 am

I've never seen this one come up before. This is indeed odd. You get the same behavior -- ie6 vs. ns7 -- with any submenu. Just bump up _menuCloseDelay or set keepalive=1 to see the behavior. The submenu follows the rest of the elements on the page when scrolling in ie6, but stays put in the same screen position in ns7... and it's not like you see when followscrolling is at work... there's no movement at all, like it's locked into position on the screen. On a lark, I tested this with older RCs. It does the same thing all the way back to RC11 (stopped there, 'cause I have a gap back to RC6).

Since main menus (alwaysvisible=1) don't seem to have the same problem, I thought it could be fixed effectively in JMM's application by opening and closing the submenus with a function call from the onfunction property in main menu items, then having the function not only open a submenu but also turn on it's alwaysvisible property. That worked up through RC19, but crashed and burned after that. Maybe this is an issue that warrants further looking into? Should it go in the Bugs topic... John, Dave?

Kevin

User avatar
John
 Team
 Team
Posts: 5967
Joined: Sun May 19, 2002 8:23 pm
Location: Phoenix, AZ
Contact:

Post by John » Wed Nov 12, 2003 5:32 am

Noticed another interesting thing here. When looking at your page initially I show no scroll bars at all. So, I started squeezing up the window to make them appear, and as I did so I noticed everything moved except the menu in question (essentially your bug, but another way of seeing it). When I had a smaller window and released the mouse, the NS resize fix kicked in (window reload), and the menu popped back into the proper place. I think there's a clue in here somewhere, but I'm just too tired to catch it right now.

Kevin - yes, please put this in the bug topic.
John

User avatar
Andy
Milonic
Milonic
Posts: 3307
Joined: Sun May 19, 2002 8:23 pm
Location: Menu Developer
Contact:

Post by Andy » Wed Nov 12, 2003 12:08 pm

Is it a bug? Err, I'm not sure.

The fix is to declare a position of absolute for each of the sub menus.

The reason for the "bug" is down to Netscape 7.0 and other objects like Flash. When we use a position of absolute, the menu appears behind Flash.

So by default we use a position of fixed, this fixes the Flash problem but creates the problem seen. Normally the menu is moved about by the menu code but in this instance it's fixed in place.

The following snippet should solve it for now:

Code: Select all

with(milonic=new menuname("home")){
style=CAPAH_left_navbar_style;
menuwidth=139;
screenposition="center"
position="absolute";
top=159;
left="offset=-272";
overflow="scroll";
keepalive=1;
Cheers
Andy

User avatar
kevin3442
Milonic God
Milonic God
Posts: 2460
Joined: Sat Sep 07, 2002 12:09 am
Location: Lincoln, NE
Contact:

Post by kevin3442 » Wed Nov 12, 2003 5:30 pm

Andy wrote:...So by default we use a position of fixed,...
I'm confused then... the position property occurred to me as a possbility, but when I read the doc, it said:
position is used to declare a relative position. By default this property is set to absolute so is only needed for setting the menu relative to other HTML objects or for embedding inside a table cell.
So, I didn't investigate position any further. Did the default change? Is the default currently fixed for all browsers, or is it browser dependent? Just wondering for future reference.

Cheers,

Kevin

User avatar
Andy
Milonic
Milonic
Posts: 3307
Joined: Sun May 19, 2002 8:23 pm
Location: Menu Developer
Contact:

Post by Andy » Wed Nov 12, 2003 6:18 pm

It's only fixed for Netscape 6/7 and Mozilla the rest are absolute.

These are the only browsers that support fixed positioning properly.

The default for them is fixed unless it's a main menu. Fixed is very similar to absolute but it cures the overlapping problem so it's important for us to use it. We'd rather not but as always our hands are tied by browser restraints.

Cheers
Andy

JMM
Advanced
Advanced
Posts: 13
Joined: Tue Nov 11, 2003 10:47 pm

Post by JMM » Wed Nov 12, 2003 7:18 pm

Thanks to everyone for your input.
Andy
The following snippet should solve it for now
Yes, that solved that particular problem. Thanks!

Post Reply