Closed Bug 141412 Opened 19 years ago Closed 19 years ago

Mozilla doesn't show dropdown menu when I use div's instead of a table


(Core :: DOM: CSS Object Model, defect)

Not set





(Reporter: Peter.Thomassen, Assigned: jst)





(1 file)

please move your mouse pointer on to one of
the menus on the top. If you are over "Leistungen", "Referenzen" or "Wir über
uns", a dropdown menu should appear. On Windows and Mac, that's no problem, but
on a Linux machine nothing happens! I think, this is a but.
When you go to, you see (almost) the same design,
but it is not based on a div-construction but on a table layout. It is the same
JavaScript function, and the fields are both div and identificated by the same
id, the only difference is that in / the div is in a td, and in /new/ the div is
in another div.

However, I think this is a bug - or have I done anything wrong?

Tested: Mozilla 1.0.0 RC1, Mozilla 0.9.9, Mozilla 0.9.8 on Macintosh, Linux and
Win32. Only Linux has the problem.

same here: 2002042823 on linux

no JS errors in the console..
.. once a dropdown menu appeared.. weired..
really crazy, it once appeared ... my script isn't buggy, you can see it in

when I mouseover the word "Leistungen", CPU usage jumps to 100% and then droped
back to normal ... but nothing happened at all.
oops ... i have found a way to open it ... you can open the drop down by
selecting the word "Leistungen" ...
nice ascertainment ... Mozilla seems to miscalculate ... is there any
workaround, and, if there isn't one, when will the bug be fixed?

Here is what I see on this page (trunk build 2002-04-30-10):

1)  Hover on the space around "Leistungen" (say 1cm to the left of the "L")
2)  Popup menu appears
3)  Slide mouse pointer right to point at the "i" in "Leistungen"
4)  Popup menu disappears, "Leistungen" is underlined

Without looking at the code, I would guess the page is listening to onmouseout
events to close the menu and we fire onmouseout when we move from the <div> to
the text.. (known problem).  Does checking that the target of the onmouseout
event is "this" fix the issue, by any chance?

> Does checking that the target of the onmouseout
> event is "this" fix the issue, by any chance?

I don't know what you mean. Each dropdown menu has an id. My script uses
getElementById, and the display propertie is changed by this id.

<div onmouseover="show('menu_services');" onmouseout="hide('menu_services');"
     style="left: 174px; width: 191px">

Change that to:

<div onmouseover="if ( == this) show('menu_services');"
     onmouseout="if ( == this) hide('menu_services');"
     style="left: 174px; width: 191px">

I suspect that you're seeing onmouseover events targeted at children of the
<div> that are bubbling up to the div.... So you're hiding the menu, even though
the mouseout was out of some text, not out of the <div>.  Doing the hiding only
when the target is the div should help.

If that does _not_ help, then we look further for the problem.  :)
Attached file testcase
see test1 and test2.
I can't test it, because I only have a Win32 machine. On Monday, my co-worker
returns, and he will test it.

Thanks for your patience,
Blocks: 113492
Any update on this?
Peter?  What's the state of this?
Hi there,

only URL change from to

Sorry, my co-worker is back again ... I'll make a notice an report again when
he's back.

Thanks for your patience,
Hi again,

my co-worker is on vacation at the moment. But I've sent him an email, and he
answered that his Mozilla build is about two weeks old, and the bug isn't fixed
in it.

BTW: The table layout isn't available anymore. Excuse me, but I'm not the only
one who has full access to our site.

Peter, is the site that shows the problem still available?  Testing everything works fine in my Linux build...

Also, see comment 8.  Did you guys ever try that?
Hi there,

I've just tried the workaround proposed in comment 8. On Win32 it doesn't make
any difference, Linux I couldn't test. If you're quick you can see it on
"Leistungen" at - within the next hour.

But I don't think that it makes any sense, because this method makes Internet
Explorer not to show the menu.

I'm looking at as I write this, and the menus come
up beautifully (Linux build).  Peter, what build are you using on Windows?  What
problem are you seeing (note that comment 0 said the problem was Linux-only....)
Hi Boris,

> I'm looking at as I write this,
> and the menus come up beautifully (Linux build).

I can't test that.

>  Peter, what build are you using on Windows?

2002102308 ... about a week old.

>  What problem are you seeing (note that comment 0 said the problem was
> Linux-only....)

Yes, and there's no problem with Mozilla on Windows machines. I said the if
construct changed nothing on Windows systems, i.e. the menus appear as before.

The problem is that my co-worker (I don't know which build he uses) says on his
Mandrake machine these menus do not appear without the if construct. If they do
with it I can't say.
You just said the menus did _all_ appear on your Linux machine. That's curious
because I only inserted the if construct in the first menu.

Boris again, which build do you use?

Oh, sorry.  I thought I had listed the ID.  Trunk build 2002-10-25-08.  The
menus were working fine for me without the if() thing as well, which is why I
said what I said in comment 15....  Since I _was_ able to reproduce the problem
earlier, sounds like we fixed something somewhere....

Thanks for clarifying that this is working correctly on Windows, Peter.
Hi Bob,

on Windows, everything worked fine ever.
Sorry, I've read over in comment 15 that it's ok with your build.

If you've too much time ;-), it would be nice if you could download an older
build - about 2 weeks - as my co-worker uses. It would be good to be able to say
him that the bug is fixed now.

Good idea.  ;)  so the first menu (the one you changed) works in all build I
tried.  The second one works in build 2002-10-03-08 but not 2002-09-03-08.  I
could hunt down the exact date in there when the behavior changed if anyone
really cares...

it doesn't matter to me. I'll say him that the bug is fixed. Thanks!

Greetings from Germany
-> WORKSFORME (standard resolution when we don't know what fixed it).
Closed: 19 years ago
Resolution: --- → WORKSFORME
No longer blocks: 113492
Component: DOM: Views and Formatting → DOM: CSS Object Model
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.