Serious bug in Top Menu III with Firefox

[peterhoa]

Web designers/web masters should be aware of this serious bug with Top Navidation Bar III and firefox browsers. The bug is that each time you mouse over a menu item in a TopMenu III menu bar it sends two page reload commands to to the server. So, for example, if a pull down menu has ten items and you want to select the last one (ie you mouse over 9 items) then it will send 18 reload commands to the server. This only happens with Firefox (I'm using the latest version), not with IE. It happens even if you don't select an item. Just mousing over the menu items sends multiple reload commands.

I noticed this when I saw my modem lights flashing each time I moused over menu items. This is strange -- simply mousing over menu items should not transmit anything over the network. I then monitored it at the server and confirmed it. It's potentially very serious if you are using server-side scripts and processes (asp, CGI etc) as they get called each time you mouse over a menu item.

You can see this for yourself by using the demo menu at the top of the TopMenu III page on this web site. Use dial-up and watch your modem lights. If you look at your sever logs you will see a whole pile of new log entries each time you mouse over a menu item. You should see none.

I have emailed the developer several times over the past few days but haven't received a response as yet.

[ddadmin]

Hmmm I don't see how JavaScript could do this- reload a webpage without even navigating to it first. Does the Reload animation at the upper right of your FF browser start to animate when you move the mouse over the menu items?

Let me know if you don't hear back from the author in a few days, and I'll consider bringing this to his attention.

[jscheuer1]

What happens when you unplug your modem? Nothing, no errors, the menus still drop down. If it were reloading, I imagine there would be some sort of error. In fact, if I reload the page with the modem disconnected, I do get an error. Additionally, depending upon your OS, whenever you are connected to the internet there is traffic over the modem, checking for updates and/or mail, fending off attacks (if you have your firewall configured), etc. Your ISP may be pinging you as well for whatever reason(s).

[peterhoa]

ddadmin: you say you don't see how this could happen. It is very similar to a bug that previously existed in TopLevel III. Here is a quote from BrotherCake's web site at http://www.brothercake.com/dropdown/...tributors.html which shows mouse over definitily used to (and still does with Firefox) cause page reloads: (it's a slightly different problem, but the principle is the same: mouse over causing requests to the server for no reason):

"... for highlighting a problem where the blank, spacing images were being continually reloaded on each mouseover, putting undue strain on a server. To solve this problem, which is apparently a bug in the browser itself, I removed the use a spacing gif entirely, which had positive side effects for the efficiency of the script in general. Version 2.1.1 is now available at Dynamic Drive. Nice one "

He talkes about a bug in the browser itself -- but given the problem only happens with Firefox and only with TopMenu III (and I've tested it on at least 50 other menus at various sites) I would class the problem as very much a bug with this script. No other scripts cause the reloads.

So, it's definitly possible. Although the previous bug was fixed by brothercake it appears there is another one which has not been fixed. I'm professional web devloper -- I've been monitoring my server and the mousever causes two hits (ie reload requests) for each item moused over.

Also: it's not about my modem or ISP. I've been testing it on my local server as well. I only mentioned the modem so anybody can test it by seeing that the lights flash when you mouse over. My real evidence is from my server logs (locally, not across the Internet). But look: test it yourself. I can assure you it sends reloads. You don't see the page re-loading or the re-load animation spinning. All these have been turned off by the java script. But, as I say a huge amount of traffic is being sent to my server and ASP.net pages are fire up each time you mouse over a menu item. And you can test it easily using the demo on the TopMenu III page.

[cr3ative]

peterhoa: Could you post your full system specifications please? I'm sitting here right now playing with the menu, and experiencing no reloading from the server at all with Firefox. My switch lays unblinking.

Also, the quote you found is referring to images reloading, not the page itself reloading.

/edit: Also, if you could post parts of your server logs as evidence, that might help.

[peterhoa]

Windows XP. Firefox 1.0.4. Nothing unusual with my configs. And I've tested it on three machines, all with the same result.

Yes I know the previous was about imagies. My point for mentioning it was to illustrate that mouseover events in scripts can cause (if the scripts are so written) requests to the server.

Ignore it if you like. I've had to move on. The scripts buggy and as it is it can't be used by any web designer who has ASP, CGI or other scripts.

[ddadmin]

In the past, IE5.5 and less would reload the image involved in a mouseover repeatedly onMouseover, which was fixed in IE6. JavaScript definitely is capable of reloading elements on the current page erroneously, but I really don't see how it would reload a remote webpage without even navigating to it first.

I'll wait for more info to be posted, and if needed, refer the author of Top Menu III to this thread.

[peterhoa]

I'm not really clear why you think loading an image repeatedly on mouse over is any different from loading the html page itself. Both are simply http get commands. They are both the same. The only difference is the URL.

But anyway, I have undertaken full testing. I can reproduce the problem 100% of the time using ASP or ASPX (.net) web pages. Using straight htm or html pages is not a valid test due to local caching. ASP and ASPX pages are not normally cached by the browser, hence all requests are sent thru to the server and can be seen in the logs.

The only contents of the web pages are one word ("hello") and the four lines of javascript necessary to call the menu bar. The menu bar I'm using is the default that I downloaded from dynamic drive, with the config file renamed to customoriginal.js. I have made no changes (in this test). Note that none of the links point to my web site. Obviously not, as I haven't customized the menu.

With IE when I call up the page there are a few lines in the IIS server log which show the http get for the page, plus the requests for the JS files. When I mouse over menus nothing is sent to the server.

With Firefox, on the other hand, each time I mouse over a menu item it sends requests to the server. These are simply http get requests for the page. Where do they come from? The web page contains nothing except the word "hello" and the menus. Mousing over the menus causes the http gets to be sent to the server -- dozens of them. It may be a bug in Firefox (the version I'm using is 1.0.4 downloaded from the Firefox site three days ago). But it only happens with Top Navigation Bar III, so I regard that as a Top Navigation Bar III bug.

I have attached the server log entries. The first few lines are from my IE test. Note it behaves as you would expect. The seond large number of entries is from firefox. Note: ALL ENTRIES WERE CAUSED BY MOUSING OVER THE PULL DOWN MENU. AT NO TIME WAS REFRESH OR ANY OTHER KEY HIT ON MY BROWSER. AT NO TIME WAS A MENU ITEM SELECTED. Look at the times: they were all made within a few seconds of each other as I slowly moused through all the menu items. I have also attached the aspx/ASP script file (zMenuBarTest.ASPX which I have renamed to a txt file so you can view it in notepad) so you can see it contains nothing except the menu and a body of "hello".

I get these results consistently on multiple PCs and (not that it's even slightly relevant) using multiple servers. The server side is obviously completely irrlevant as the issue is the http gets being generated from the Firefox browser in response to mouseover events.

I would appreciate it if you could notify the developer. He has not replied to any of my messages. Turn off word-wrap in notepad when you view the attachements.

[ddadmin]

I'm not really clear why you think loading an image repeatedly on mouse over is any different from loading the html page itself. Both are simply http get commands. They are both the same. The only difference is the URL.

Well, it's different because with reloading an image, there is code you can trace back to inside the menu that instructs the browser to load the image, such as for an onMouseover image effect. The fact that it's reloading is where the oddity lies, and in this case, can be attributed to a IE4-5 bug. But with the page reloading onmouseover, there isn't any code I can see that would cause an activation of this action, onmouseover that is.

I'm not saying there is or isn't a problem, as honestly, I haven't tried to duplicate what you're saying. I'll look over your logs later this week and decide if I should bring the author's attention to this thread.

[peterhoa]

I've heard back from James at Brothercake about this and he confirms that it sounds like the problem he already knew about with Firefox. It's what he calls a "bug" in firefox, but which mozilla calls a "feature" -- Firefox makes additional server requests in certain situations. He pointed me to discussions he's had with them about this but he says they won't fix it. He said he's fixed the problem (ie worked around the problem) in later versions of his products but wasn't aware that the one on DynamicDrive was affected.

If anybody is concerned about server load, or their web hosting company charges them based on in-bound traffic (which most do) they should be very careful. Unless you monitor your server logs or notice server processes firing up when they shouldn't, you would not be aware of this serious problem.

For my part, I have now moved to a CSS standards compliant menu bar which "should" be immune from these types of problems in the future.