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 126.96.36.199 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
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?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
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.
Status: RESOLVED → UNCONFIRMED
Component: Layout: R & A Pos → English US
Product: Core → Tech Evangelism
Resolution: INVALID → ---
Version: Trunk → unspecified
Assignee: nobody → english-us
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: layout.r-and-a-pos → english-us
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 ago → 10 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.