401154 - Menus are positioned with the wrong offset

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: English US, defect, P3)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Build ID: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007102504 Minefield/3.0a9pre

This works fine using 2.0.0.8 on all platforms; sadly, I don't yet have a regression date.  Too much other stuff going on right now, sorry.

Summary: Menus are positioned with the wrong offset

Steps to Reproduce:

1. Load http://www.topotarget.com
2. Mouse-over the menus on the left

Expected Results:

Menus should appear to the right

Actual Results:

Menus fly out to the left, instead

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Script's source

Comment 2

[Gérard Talbot]

Whatever the problem is with Firefox, I can assure you that the DHTML menu code has bugs since it does not render (or renders wrong) in Opera 9.24, Opera 9.50 beta build 9613 and in Safari 3.0.3 build 522.15.5. Appropriate object feature support detection instead of user agent string detection is most likely the culprit here.

http://www.topotarget.com/layers_special.js
is the browser sniffing script based on the user agent string and is an old, unreliable and incorrect one.

Comment 3

[Ria Klaassen (not reading all bugmail)]

Maybe I misunderstand the bug, but on trunk I miss the arrow of the first sub-menu. On the spot where the arrow should be, I see the capital letter appear of the menu-item.
Screenshot comparison branch-trunk: http://img207.imageshack.us/img207/8610/comparisonsf2.png

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Sounds like a layout problem

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase

The code on the site basically is climbing up the tree while storing and counting the offsetLeft value. See function get_x_position in the testcase.
It looks to me this doesn't work anymore, because current trunk builds give more correct values for the offsetLeft property for the various elements and the get_x_position function makes (currently false) assumptions on which elements to take into its calculation.

With current trunk build I get as result:
TD--0
TR--0
TBODY--0
TABLE--1
TD--0
TR--0
TBODY--0
TABLE--220
BODY--0
HTML--0
#document--undefined
get_x_position() --0
getBoundingClientRect() --221

With a branch build, I get:
TD--0
TR--0
TBODY--0
TABLE--0
TD--219
TR--219
TBODY--219
TABLE--0
BODY--0
HTML--0
#document--undefined
get_x_position() --219

Comment 6

[Martijn Wargers (dead)]

Mats fiddled with offsetLeft stuff recently-ish, iirc. Mats, it seems to me current trunk builds are doing it correctly, right?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I agree.

Comment 8

[Martijn Wargers (dead)]

It seems to me this should perhaps be a tech evangelism bug, since Mozilla changed its behavior here (although to something more correct) and this site has now been suffering from that.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

This now WFM using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090105 Shiretoko/3.1b3pre