Submenu appears at the bottom of the menu and can't be clicked

VERIFIED FIXED in mozilla1.9.1b3

Status

()

P3
normal
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: toutenkarton-bug, Assigned: dbaron)

Tracking

({regression, verified1.9.1})

Trunk
mozilla1.9.1b3
regression, verified1.9.1
Points:
---
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081103 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081103 Minefield/3.1b2pre

When the cursor moves over the orange menu on the left, the submenu appears at the bottom of the menu. It's impossible to click because it desappears before.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.centrespiriteaugustinlesage.fr
2. Move the cursor on the orange menu on the left
3. See the result
Actual Results:  
The submenu appears at the bottom of the menu

Expected Results:  
With all the others browsers, the submenu appears on the right of the area you have selected.
Confirmed on Windows XP, latest trunk. This happened for the first time on 5 Jun 2008:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-06-05+01%3A00%3A00&enddate=2008-06-05+23%3A00%3A00
Component: General → Style System (CSS)
Keywords: regression
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → style-system
Hardware: Macintosh → All
Version: unspecified → Trunk
Flags: blocking1.9.1?
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
Keywords: qawanted
An Linux it regressed between 2008-06-05-02-mozilla-central and 2008-06-06-02-mozilla-central.
This is a regression from http://hg.mozilla.org/mozilla-central/rev/e30af5899328
Assignee: nobody → dbaron
Blocks: 423306
Created attachment 349306 [details]
partly simplified testcase
Created attachment 349312 [details]
slightly more simplified

I removed one of the default display:none to show that there's an incremental layout bug here.

Note that things look much better if the <font> element is removed.
Attachment #349306 - Attachment is obsolete: true
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Created attachment 349328 [details]
mostly simple

This is also influenced by the quirks.css rule for dd not inside dl.
> This is also influenced by the quirks.css rule for dd not inside dl.

Actually, the only thing influenced by that was my theory that there was an incremental layout bug.  Because of quirks.css, the initial value of 'display' is 'inline'.  The regression regressed 'block' and 'inline' differently, but I don't see any incremental layout differences once I account for that.
Created attachment 349333 [details]
fully simplified, display:block
Created attachment 349334 [details]
fully simplified, display:inline
So what's happening here is that InitAbsoluteConstraints uses the outer div as cbFrame.  This is correct for the use of cbFrame when testing direction, but wrong for the call to CalculateHypotheticalBox, since there's an anonymous block inside it that has more finely-divided line boxes.

So I think in the one caller that uses GetNearestContainingBlock, we actually now want two different answers in the two places that use the result of the function.
Comment on attachment 349487 [details] [diff] [review]
patch

Full reftests pass on Linux, so requesting review.

You probably first want to have a look at bug 423306, which caused this.
Attachment #349487 - Flags: superreview?(bzbarsky)
Attachment #349487 - Flags: review?(bzbarsky)
Whiteboard: [needs review]
Comment on attachment 349487 [details] [diff] [review]
patch

Makes sense.
Attachment #349487 - Flags: superreview?(bzbarsky)
Attachment #349487 - Flags: superreview+
Attachment #349487 - Flags: review?(bzbarsky)
Attachment #349487 - Flags: review+
Whiteboard: [needs review] → [needs landing]
Fixed in mozilla-central (and thus also on mozilla-1.9.1):
http://hg.mozilla.org/mozilla-central/rev/5d6db13efa26

Then backed out due to a Mac startup crash, whose underlying cause was actually
bug 466399:
http://hg.mozilla.org/mozilla-central/rev/2d0df3bbef22
http://hg.mozilla.org/mozilla-central/rev/acfda488bc5c

Then relanded, and thus again fixed in mozilla-central (and thus also on
mozilla-1.9.1):
http://hg.mozilla.org/mozilla-central/rev/0dfccaf1d58d
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla1.9.1b3
Keywords: fixed1.9.1
verified FIXED (using attached testcases) on builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090618 Shiretoko/3.5pre ID:20090618042848

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090610 Shiretoko/3.5pre ID:20090610031356

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090618 Minefield/3.6a1pre ID:20090618031143
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.