Closed Bug 138452 Opened 23 years ago Closed 23 years ago

Links in DHTML menu are not working.

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 132592

People

(Reporter: mavos, Assigned: jst)

References

(
URL
)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020419 BuildID: 20020419 The links on the drop-down menus at the top of the page, as well as the menu above the middle image don't work. Reproducible: Always Steps to Reproduce: 1. Choose a DHTML menu. 2. Click a link. Actual Results: Nothing happens. Expected Results: Mozilla should follow the link. I have a feeling the menu disappears before the link is activated, turning the link into nothing (whatever was behind the menu). I'm not sure if this is a problem with Mozilla or with the JavaScript on this page, but I assume it's working in IE.
WFM win2k RC1
WFM too ! 2002041814 - WinXP
WFM, win98, build 2002041903
WFM OS X/1.0 RC1. Martin, can you revisit the page and copy any javascript errors you find in your console?
There are no relevant JavaScript errors in the console.
WFM RC1 Debian Woody Linux
WFM - trunk build 2002042908 on win-xp
Blocks: 113492
I have the same problem with RC3 on RH 7.2 and same for galeon(mozembed). tested with following link - http://www.javastudy.co.kr (It's in Korean but you can find the pull down menu just below the banner)
Forgot to mention that it works find with RC3 on Win98SE. Only linux build seems to have the problem.
At http://www.elotrolado.net the same error. I have asked to some users of the web that are using Mozilla and it's runs correctly with Windows version of Mozilla, but I couldn't click the menus with my Linux (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 same error). I think this bug wasn't on older Linux versions of Mozilla ( < 0.9.7 )
Can somebody confirm this bug in Linux? We know it works fine in Windows.
Keywords: qawanted
Summary: Links i DHTML menu are not working. → Links in DHTML menu are not working.
WFM Moz 1.0 Debian
Should be *confirmed*, *resolved* or assigned. Works in Build: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020608. Which is Mozilla 1.1Alpha, work frozen SeaMonkey build
I don't know if I can change it to confirmed, but I'll try. The bug definitely exists, as I (along with a small number of other people) see it with different versions of Mozilla, including 1.0, on different Linux distributions. It seems like the menu disappears so quickly when clicked, the link is no longer a link when you release the button. Links are triggered when the mouse buton is released but the context menu appears men the right button is pressed, so right click -> Open Link in New * works fine.
Confirming on basis of comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Bug remains on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 Debian distro not using DEBs of Mozilla.
Reporter: Do you use a Debian based build ?
Reporter uses Gentoo Linux - not Debian based.
Reporter: I don't mean your system i mean your mozilla build itself. Do you use a build from ftp://ftp.mozilla.org ?
That makes sense... :-) Ok, the Mozilla I use now is one that I built myself. I have tried a build from mozilla.org but the bug appeared in that one too.
-> DOM0
Assignee: Matti → jst
Component: Browser-General → DOM Level 0
QA Contact: imajes-qa → desale
Something is probaly wrong with Linux/*NIX implementations of Windows UI managers. Reporter: Install a nightly build, Report versions of the following: Mozilla XFree86 Freetype Run from console: Mozilla > (debug file)
Mozilla 2002061108 XFree86 4.2.0 Freetype 9.0.3 But there is no output to console and the menu is still not working.
Please have a look at bug #132968, which mentions this URL along with a number of similar problematic sites.
*worksforme*. I did a clean install RedHat 7.0 pending RedHat rawhide download. I used a old build and I don't yet have a SeaMonkey nightly to prove this. Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; 0.8.1) Gecko/20010326 Installed using regular installer to /usr/local/mozilla. $ rpm -q XFree86 freetype XFree86-4.0.1-1 freetype-1.3.1-7 As for console output: e.g mozilla > /tmp/mozilla.log then attach /tmp/mozilla.log. Oh yes, document users document.layer(s) :-(. There may be ways to do this: Sounds like this may not be caused by mozilla: Possible causes: glib (gtk) networking protocols: if document if fully loaded, menus don't appear (including the huble stop button). xlib (highly unlikley)
*** Bug 160155 has been marked as a duplicate of this bug. ***
I have the bug, with Build ID 2002072204 It is only on pages built with dreamweaver or golive. On pages made by hand the problem doesn't exist. It is only on linux. On windows/macosX the problem doesn't exist. I can confirm that from 1.0 to 1.1b the problem remains. I think that in 1.0RC1 the problem doesn't exist.
This link reproduces the problem. http://www.tvdemente.loc/error_mozilla.php I found that: <a href="link" onMouseOut="MM_swapImgRestore()" onMouseOver="MM_swapImage('Image100','','/imagenes/home/caminantes_f2.gif',1); MM_showHideLayers('Layer4','','show')" target="_top"><img name="Image100" border="0" src="/imagenes/home/caminantes.gif" width="132" height="16"></a> works, but a lot of graphics designers use this: <a href="link" onMouseOut="MM_swapImgRestore(); MM_showHideLayers('Layer4','','hide')" onMouseOver="MM_swapImage('Image74','','/imagenes/home/cinedemente_f2.gif',1); MM_showHideLayers('Layer4','','show')" target="_top"><img name="Image74" border="0" src="/imagenes/home/cinedemente.gif" width="132" height="16"></a> as you can see, onthe second one there is a showhidelayers call. without it the link works, also, if i call showhidelayers with a settimeout of 10 ms the link works. This point me to think that the problem is hidding the layer causes the link disappears before it got the event click.
Anyone have DHTML code dating back to as far as 08/1/02 which according to Bonsai is the last good tree of SeaMonkey. As for the site, it needs some help with standards
Problem remains on 1.1 and on 1.2a
yes, it remains in 1.1
I'm wondering: those that can see this bug, can you also see it on the other sites mentioned in bug #132968, besides this one?
In mozilla 1.1 i can't see the menus of the page on bug 132968
All sites mentioned in this bug and bug #132968 now work for me with 1.2a. Even www.iconmedialab.se.
As I said on 2002-09-14 04:40 the problem was on 1.2a also. I have reinstalled my Debian weeks ago and now with Mozilla 1.2a (Gecko 2002091016) it runs correctly. I use Debian Sarge, but I install the Mozilla of www.mozilla.org not from the .deb files of Debian. It's posible the fail it's on libstdc++2.9-glibc2.1 library ? Please note here what distro do you use if you have this bug.
I have upgraded now to Mozilla 1.2b (Gecko 2002101612) and runs correctly.
mmm, after installing programs and working with my Debian I have another time the same problem. The last packages I have installed were xchat, xmms-crossfade, xmms-modplug and tftp. I think the problem will be with xchat and it's dependencies. http://packages.debian.org/testing/net/xchat.html
WFM linux RH7.1 + all updates local built mozilla (1.3a 2002112116 local build xchat 1.8.10
WFM too! Phoenix 0.4 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4) Redhat Linux 7.3
This menu works correctly, even if http://www.iconmedialab.se/ don't work. http://dhtmlcentral.com/projects/coolmenus/
I think I have found the bug. I have installed Mozilla 1.2 Final (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126) and I have the problem with the menus. I have reinstalled on my Debian the library libstdc++2.9-glibc2.1 with one: apt-get install --reinstall libstdc++2.9-glibc2.1 and I solved the problem with menus. I think the problem it's on libstdc++2.10-dev or libstdc++2.10-glibc2.2. They will rewrite some file and the bug appears. Someone could test it ?
I have been having this problem, and not only on this site. It has always been after running the same X session for a while. That is, everything has been fine until after some days when the menus on some sites have stopped working. At all times the behavior has been the same in Mozilla, Phoenix and Netscape 7. A few weeks ago I upgraded to SuSE 8.1 (from 7.1), and after that I had no problems for about 15 days, running the same X session all the time, so I thought the upgrade had solved it. But yesterday, I found that the problem had reappeared just as before. Therefore, re comment #41, it would be great if you could keep your currrent X session as long as possible, to see if the same happens to you after some time.
comment 28 is on track the click fires mouseout (why?) and that closes the menu before the click handler does its magic. dupe of "onMouseOut triggered by mouse click prevents menu from working" *** This bug has been marked as a duplicate of 132592 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
No longer blocks: 113492
I use mozilla in a debian 30r0 and sometimes the dhtml menus in the web that netvicius said, work and sometimes it don´t.
You need to log in before you can comment on or make changes to this bug.