124108 - Site uses javascript dropdown lists, which are opened without any need. This slow down performance

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: Other, defect)

Description

[Auke]

When visting www.tweakers.net and selecting a link with the right mouse button,
we have to wait until mozilla opens one of the javascript boxes (when reachting
the dropdom menus of mozilla, eg file, edit, view, search, etc, the NEAREST (to
the mousepointer) dropdown box opens) When a box has opened, it will not close
anymore (never?).

This decreases performance, especially when switching tabs (tweakers.net is a
site where tabs are very useful).

The performance decrease could be related to bug 65509.



Steps to reproduce:
1. go to www.tweakers.net
2. open a link with richt mouse botton; open in new tab.
3. it takes 'years' before the tab is really openened

Reproducibility: Always

Add:
At university i use moz 0.9.8 (x-terminal based) now, but i think it is also
reproduceable with mozilla 0.9.7 windows build (home use).

Comment 1

[Phil Schwartau]

Browser, not engine. Reassigning to Browser-General until we can get
more information.

I don't think I'm seeing the bug with Mozilla trunk binaries dated 2002-02-04
on WinNT and Linux. I go to any link at http://www.tweakers.net, right-click
on it, and open it in a new tab. It takes about 5 to 7 seconds over my
T1 connection for the new tab to complete loading.

I never get unwanted dropdown lists. Am I doing something wrong?

Comment 2

[Auke]

First i should say that under windows (AMD 500Mhz) the 'bug' is there, but
mozilla is more responsive than under Linux (2x Pentium III - 700Mhz, about 10
users(?)), so it is less noticable. Under windows, it is not always that they
stay open, but mostly. (Perhaps under linux, it is so slow that it looks forever).

Perhaps you switch back to the 'main' tab after opening in a new tab. Otherwise
move your mouse over one of the drop down menus and then go (point) to the
menubar or buttons/url bar. Mostly the drop down boxes will open and stay open.

After pointing the 'dropped' down menus again (no clicking), they will mostly
close again.

Comment 3

[Phil Schwartau]

Confirming the reported behavior using Mozilla trunk binary 2002020409 on WinNT.

STEPS TO REPRODUCE
1. Load the given URL
2. Mouseover the "inloggen" menu item near the top of the page
3. A submenu appears below "inloggen"
4. Move your mouse slowly beyond the bottom of the submenu
5. The submenu disappears

So far, so good. This is what should happen. Try the same thing again:

6. Mouseover the "inloggen" menu item near the top of the page
7. A submenu appears below "inloggen"
8. Now move your mouse slowly beyond the TOP of the submenu
   (The mouse goes above "inloggen" and out of the document,
    towards the Mozilla toolbars)
9. The submenu does NOT go away; it remains displayed on the screen

Comment 4

[Phil Schwartau]

The show/hide functions for the site are in this file:

          view-source:http://www.tweakers.net/x/j.js.dsp

NOTE: Mozilla falls into the |is.ie| branch of their code. That is, 
      |is.ns| evaluates to false and |is.ie| evaluates to true
      in what follows. You can see this yourself by loading the site,
      typing in these javascript: URLs, and hitting <Enter>:

                    javascript:alert(is.ns);
                    javascript:alert(is.ie);


function show(id) {
  if (is.ns) document.layers[id].visibility = "show"
  else if (is.ie4) document.all[id].style.visibility = "visible"
  else if (is.ie) document.getElementById(id).style.visibility = 'visible'
}

function hide(id) {
  if (is.ns) document.layers[id].visibility = "hide"
  else if (is.ie4) document.all[id].style.visibility = "hidden"
  else if (is.ie) document.getElementById(id).style.visibility = 'hidden'
}

function hideall() {
  hide('m0');hide('m0a');hide('m0b')
  hide('m1');hide('m1a');hide('m1b')
  hide('m2');hide('m2a');hide('m2b')
  hide('m3');hide('m3a');hide('m3b')
  hide('m4');hide('m4a');hide('m4b')
  hide('log');hide('loga');hide('logb');
}


These functions are written correctly. You can see this yourself 
by typing these javascript: URLs and hitting <Enter>:

                    javascript:show('log');
                    javascript:hide('log');

Comment 5

[Phil Schwartau]

The show/hide functions are bound as event handlers in the following file:

          view-source:http://www.tweakers.net/x/m.js.dsp

For example:

document.write("<div id=logt><a href=\"javascript:void(null)\"

                onclick=\"window.open('/ext/login.dsp?location=",location,"', 
                         '_blank','toolbar=no,location=no,menubar=no,width=450,
                         height=275,status=no,scrollbars=yes');\"
 
                onmouseover=\"hideall();
                              show('log');
                              show('loga');
                              show('logb');
                              return true\">


                <img src='g/log1.gif'    etc.  etc.

Comment 6

[Phil Schwartau]

The problem is, every <DIV> at the site is coded in a similar manner: 

1. The first thing the onMouseOver handler does is hideAll();
2. There is no onMouseOut handler !!!


So what happens when you move your mouse below the bottom of a 
submenu is that you hit a <DIV> below it. This triggers the 
onMouseOver handler of the lower <DIV>, which does a hideall().
Thus the submenu disappears.

This was a poor way to code it. It should have been done on a 
onMouseOut handler of the <DIV> the mouse is leaving. Because
of this mistake, we see the behavior reported in this bug.

Namely, when you move your mouse ABOVE the "inloggen", say, there
is no other <DIV> above it. You have reached the upper limit of the
document. So no more onMouseOver handlers fire, and thus no hideAll().
So the submenu remains visible.

Comment 7

[Phil Schwartau]

Note: the same problem occurs in NN4.7, IE6 when you access this site.
The same reason explains why; it's not just a problem in Mozilla.

Reassigning to Evangelism. The site should be made aware of this
and encouraged to use onMouseOut handlers to prevent it. Although,
since the same thing happens in every browser, I'm not sure this is
our problem. I will let the Evangelism folks decide. 

I believe this site is an important one, and I know there have already
been a number of bugs filed against it; although not for this specific 
issue.

Comment 8

[Mathieu Pillard [:mat]]

seems to be working now...

Comment 9

[Brant Gurganus]

VERIFIED FIXED 2002120508

Comment 10

[Bob Clary [:bc] (inactive)]

resolved euro west non-.com url bugs to other