375003 - Drop-down menus at www.coloradorapids.com do not display correctly.

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Peter S.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070322 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070322 Minefield/3.0a3pre

Go to www.coloradorapids.com and mouse-over the menu marked "Home, News, Team, etc."

The drop-down menus display to the right of where they should be.  (They should drop down directly beneath the corresponding category.)

Reproducible: Always

Steps to Reproduce:
1. Go to www.coloradorapids.com and mouse-over the menu marked "Home, News, Team, etc."

2. The drop-down menus display to the right of where they should be.
Actual Results:  
The drop-down menus display to the right of where they should be.

Expected Results:  
Menus should drop down directly beneath the corresponding category.

Default theme, same profile, other testers in the nightly threads have reported the same results.

Comment 1

[Arie Paap [:wildmyron]]

Attachment: minimal html, spaghetti javascript

I've made some progress in reducing this, but there's still a mess of javascript that I haven't had time to sort through.

Regression some time between 2007031104 and 2007032004

Notes:
the .NavMenu {margin-left:90px} rule in the style is needed for the bug to show up. this might be a clue.

another site that exhibits the problem is http://www.fesa.wa.gov.au/internet/default.aspx

I'll probably poke at this some more, but I don't really know an efficient way of sorting through the javascript mess. Ideas welcome.

Comment 2

[Arie Paap [:wildmyron]]

I forgot to mention that this gives warnings in the Error console:

Warning: Error in parsing value for property 'height'.  Declaration dropped.
Source File: file://<path>/progress.html Line: 0

These warnings don't appear in the 2007031104 build which positions the submenu correctly

Comment 3

[Steve England [:stevee]]

Works:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031512 Minefield/3.0a3pre

Broken:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031513 Minefield/3.0a3pre

Bonsai regression range:
- http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-15+11&maxdate=2007-03-15+14&cvsroot=%2Fcvsroot

Comment 4

[Bill Gianopoulos [:WG9s]]

(In reply to comment #3)
> Works:
> - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031512
> Minefield/3.0a3pre
> 
> Broken:
> - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007031513
> Minefield/3.0a3pre
> 
> Bonsai regression range:
> -
> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-15+11&maxdate=2007-03-15+14&cvsroot=%2Fcvsroot
> 

From that regression range, I would suspect bug 372365.  In any event, this is a layout bug.

Comment 5

[Martijn Wargers (dead)]

Thanks!

Comment 6

[Martijn Wargers (dead)]

Attachment: more minimal html

In older builds, the clientLeft property doesn't seem to take into account the margin value, while current trunk builds do.
So this bug seems like a tech evangelism issue to me. I suspect there is a IE-special code-path in the site script so that this is not happening in IE.

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase #3

This is the first testcase with some added logging.

Seems like table.offsetLeft have regressed.
In a 20070314 build I see:
  adding <TABLE id=NavBarCtl_Menu1> parent's offsetLeft=8 offsetTop=8

In a 20070321 build:
  adding <TABLE id=NavBarCtl_Menu1> parent's offsetLeft=98 offsetTop=8

Comment 8

[Mats Palmgren (inactive)]

When comparing with IE7 it looks more like it's TD.offsetLeft that is wrong
and that TABLE.offsetLeft is now correct.  Before bug 372365 they were
*both* wrong in such a way that if you add them the result would be right.
I'll leave TABLE.offsetLeft as is because I think it's correct now and
try to fix TD.offsetLeft to be more like what IE7 does.

Comment 9

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

Whatever you do, can you make sure it's consistent with this?
http://dump.testsuite.org/2006/dom/style/offset/spec

Comment 10

[Michael Mak]

www.airliners.net also rendered incorrectly.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070323 Minefield/3.0a3pre ID:2007032308 [cairo]

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

http://www.fillarikellari.fi/ has also the same problem.

Comment 16

[Biju]

Affected package:
dhtmlxMenu at http://www.scbr.com/docs/products/dhtmlxMenu/index.shtml



Regression range:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070317
Minefield/3.0a3pre
has issue...


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070315
Minefield/3.0a3pre
works fine...

Comment 18

[Peter S.]

http://www.midnightriders.com/

There's another affected site.

Comment 20

[Mats Palmgren (inactive)]

Attachment: Testcase #4

Comment 21

[Mats Palmgren (inactive)]

Attachment: Testcase #5

Comment 22

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

We added in the origin of the parent in some table cases.
While developing the testcases I also found that clientLeft/Top have an error
in some cases when using a left margin.
This patch fixes all the testcases and URLs on all duped/dependent bugs AFAICT.
I intend to make mochitests from Testcase #4 and #5.

Comment 23

[Mats Palmgren (inactive)]

Attachment: Mochitests

Comment 24

[Mats Palmgren (inactive)]

Checked in to trunk at 2007-06-13 17:08 PDT.

-> FIXED