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
same here: 2002042823 on linux no JS errors in the console.. .. once a dropdown menu appeared.. weired..
Hi, really crazy, it once appeared ... my script isn't buggy, you can see it in http://www.assistance4all.de/new/files/default.js. Bye, Peter
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" ...
Hi, nice ascertainment ... Mozilla seems to miscalculate ... is there any workaround, and, if there isn't one, when will the bug be fixed? Thanks, Peter
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?
Hi! > 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. Bye, Peter
<div onmouseover="show('menu_services');" onmouseout="hide('menu_services');" style="left: 174px; width: 191px"> Change that to: <div onmouseover="if (event.target == this) show('menu_services');" onmouseout="if (event.target == 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. :)
see test1 and test2.
Hi, 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, Peter
Any update on this?
Peter? What's the state of this?
Hi there, only URL change from http://www.assistance4all.de/new/ to http://www.assistance4all.de/. Sorry, my co-worker is back again ... I'll make a notice an report again when he's back. Thanks for your patience, Peter
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
Peter, is the site that shows the problem still available? Testing http://www.assistance4all.de/ 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 http://www.assistance4all.de/ - 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. Peter
I'm looking at http://www.assistance4all.de/ 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 http://www.assistance4all.de/ 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. Peter
Boris again, which build do you use? Peter
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. Peter
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...
Hi, it doesn't matter to me. I'll say him that the bug is fixed. Thanks! Greetings from Germany Peter
-> WORKSFORME (standard resolution when we don't know what fixed it).
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
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.