Menus are positioned with the wrong offset

RESOLVED WORKSFORME

Status

P3
normal
RESOLVED WORKSFORME
11 years ago
4 years ago

People

(Reporter: stephend, Unassigned)

Tracking

({regression, testcase})

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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
(Reporter)

Comment 1

11 years ago
Created attachment 286202 [details]
Script's source
(Reporter)

Updated

11 years ago
Flags: blocking1.9?

Comment 2

11 years ago
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.
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
Sounds like a layout problem
Component: DOM → Layout: R & A Pos
QA Contact: general → layout.r-and-a-pos
Created attachment 286952 [details]
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
Mats fiddled with offsetLeft stuff recently-ish, iirc. Mats, it seems to me current trunk builds are doing it correctly, right?
Keywords: testcase
Flags: blocking1.9? → blocking1.9+
I agree.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
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.
(Reporter)

Updated

11 years ago
Status: RESOLVED → UNCONFIRMED
Component: Layout: R & A Pos → English US
Flags: blocking1.9+
Product: Core → Tech Evangelism
Resolution: INVALID → ---
Version: Trunk → unspecified
(Reporter)

Updated

11 years ago
Assignee: nobody → english-us
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: layout.r-and-a-pos → english-us
(Reporter)

Comment 9

10 years ago
This now WFM using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090105 Shiretoko/3.1b3pre
Status: NEW → RESOLVED
Last Resolved: 11 years ago10 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.