110505 - cx-basis.de - link not working

Status: VERIFIED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Olaf]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011
BuildID:    2001101117

- go to http://www.cx-basis.de/
- click on that really fine car ;-)
- move your mouse to "Werkstatt" => a menu appears
- try to klick a word on that menu. Won't work with Mozilla, but NS 4.7x

Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

Over to parser.  layout.  There are issues here with nested <a> tags, though...

Comment 2

[Chris Petersen]

Confirming issue. The problem occurs on the http://www.cx-basis.de/pages/home.html.
Mousing over the top four graphics on right will generate a sub-menu. None of
the  items in the sub-menu are functional.

Comment 3

[Dimitrios]

Is this page working on NS6.x ? I am asking because its browser detection can
distinguish NS6 from NS4.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 5

[rubydoo123]

Within hte js, there is a funciton called checkBrower. You can see the function 
if you type this in the location bar:
javascript:alert(checkBrowser)

when I execute the function:
javascript:alert(checkBrowser ()), the returned value is this:
[object Window]

which I don't think is the correct data necessary for the remainder of the 
functions. So, I am wondering if this isn't a sniffing bug. Assigning this over 
to evang for a look. If I am wrong, please hand it back over.

Comment 6

[Jacek Piskozub]

-> Europe: West (Germant belongs to that Tech Evangelism component)

Comment 7

[z-aillon.c-obsolete2]

It's not that checkBrowser function at the least: it is correct.  It assigns a
browser object with properties of ns5, ie4, etc as booleans, such that they call
obj.ie4 or obj.ns5 to tell whether or not the browser supports that feature. 
This is the way the ultimate browser sniffer from DevEdge works too.

This might still be evang, and someone would need to run Venkman on it maybe to
tell with any amount of certainty.  Leaving here for now

Comment 8

[Mats Palmgren (inactive)]

I think my testcase clearly shows that this is a bug. Try clicking in the 'L' in
'LINK' in the testcase - it does not work. Try clicking the 'K' - it works.
To me it seems like events are "clipped" by the parent viewport.
I have seen similar code to make popup menus on other sites too.
Reassigning to "Browser/DOM Events" for further triage.

Comment 9

[saari (gone)]

The simplified case works now, but original site still does not

Comment 10

[Mats Palmgren (inactive)]

Attachment: Testcase #2

There is a second bug that makes the site not work. When two links are nested
the
click events goes to the outer one and hover events does not seem to work at
all.
See IE6 for correct behaviour.

Comment 11

[rubydoo123]

removing myself from the cc list

Comment 12

[Vladimir Ermakov]

The site has been closed, testcases work for me, except for the nested links,
which doesnt make any sence anyways, how would you decide to go into the inner
link not the outer, and why would you ever have them nested anyways.
Resolving wfm

Comment 13

[Olaf]

site is not closed, works great with some other Browser, e.g. OffByOne. I asked
the webmaster why Mozilla is locked out.

Comment 14

[Olaf]

Webmaster told me they were working on their website, they'll investigate
Mozilla problems beginning of next year

Comment 15

[Vladimir Ermakov]

verifying