Language bar misplaced at Firefox help website

RESOLVED FIXED

Status

()

Core
Layout: Block and Inline
P2
normal
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Gérard Talbot, Assigned: roc)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7b -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

14 years ago
When visiting the Firefox help site, I noticed that the language bar was
misplaced to the left of the page and partly covered, clipped by the left
navigation "main menu" div while this same language bar is placed to the right
side of the page when viewing with Firefox 0.8 and Opera 7.5 PR3.

Actual results: language bar shown on the left side of the page.

Expected results: language bar shown on the right side of the page. 

Using Mozilla 1.7b 2004031309 under XP Pro SP1.

Preliminary testcase coming.
(Reporter)

Comment 1

14 years ago
Created attachment 144028 [details]
Preliminary testcase

I'll eventually remove one by one the css declarations which do not impact on
the bug. For now, we can see that the div.spacer1 (yellow bordered div) is
positioned OUTSIDE the div.top (green bordered div) in Mozilla 1.7b build
2004031309 when it is INSIDE in Firefox 0.8 build 20040206.
This is a regression from bug 235558 -- removing the overflow property fixes the
issue.

Misc code is for code-level bugs, btw....  which this is certainly not. 
"Layout" is the component for "I have no idea where this should go".
Component: Layout: Misc Code → Layout: Block and Inline
OS: Windows XP → All
QA Contact: core.layout.misc-code → core.layout.block-and-inline
Hardware: PC → All
(Reporter)

Comment 3

14 years ago
(In reply to comment #2)
> This is a regression from bug 235558 -- removing the overflow property fixes the
> issue.
> 

Correct!

> Misc code is for code-level bugs, btw....  which this is certainly not. 
> "Layout" is the component for "I have no idea where this should go".

Correct again... when filing the bug, I had no idea what was causing it; so I
put it there for the moment hoping to figure what eventually the appropriate
component.

Reduced testcase coming

(Reporter)

Comment 4

14 years ago
Created attachment 144029 [details]
Reduced testcase

When removing the 
overflow:hidden
declaration to div.spacer1, the layout bug disappears.
Attachment #144028 - Attachment is obsolete: true
(Reporter)

Comment 5

14 years ago
Created attachment 144031 [details]
Cleaner reduced testcase


You may resolve this bug as duplicate of bug 235558. No problem.
Attachment #144029 - Attachment is obsolete: true
Definitely it should stay the right size... Shouldn't be hard to fix.
Assignee: nobody → roc
Keywords: regression
Priority: -- → P2
(In reply to comment #5)
> You may resolve this bug as duplicate of bug 235558. No problem.

Um... If bug A's fix causes bug B, bug B should absolutely NOT be resolved as a
duplicate of bug A.
Flags: blocking1.7b?
I won't be able to fix this today, maybe not even tonight. I have a very big
work deadline on Friday and I'm not sleeping much :-)
Created attachment 144092 [details]
really reduced testcase

This is quite minimal.
OK, I'm not sure how to fix this. Let me try to explain what's going on.

The problem at hand is to compute the "preferred size" (in XUL terms) of a
nsGfxScrollFrame. For a long time now, a scrollframe with a computed width has
passed that width down to the nsBoxToBlockAdapator that manages the scrolled
block, so the scrolled block is reflowed with that as the anticipated available
width, and we discover the height that will be necessary to display the scrolled
block without scrollbars at that width.

Recently I tried to improve this so that if the scrollframe has a computed
maximum width, but no computed width, then we'll fall back to the computed
maximum width as the available width when we reflow the scrolled block.
Basically we're assuming that we'll be able to grow the scrollframe up to that
limit, and we're looking to see how high the block then wants to be. [Without
this fix, we have no width constraint on the scrolled block, so it generally
assumes it can fit on one line, and the scrollframe concludes that its preferred
height is one line. Then when the scrollframe discovers (in XUL box layout) that
it can't really grow wide enough to fit the scrolled block on one line, it's too
late --- we're already commited to one line. This situation occurs not only on
scrollframes with CSS max-width, but also on floating scrollframes, because
their HTMLReflowState->mComputedMaxWidth is set to the width of the containing
block. I will attach a testcase showing that before my fix, floating
scrollframes with more than one line of text were triggering this one-line
sizing bug.]

That is all working. The problem is that the whole solution is abusing the
meaning of availableWidth when reflowing the scrolled block. What's happening in
this testcase is that the innermost DIV is seeing the availableWidth and saying
"aha! I'm auto-width, so I should be as wide as the available width". That
forces the scrolled block, and eventually the scrollframe, to be wide enough to
fit the innermost DIV.

So what I really want is to reflow the scrolled block with availableWidth
treated as unconstrained for the purposes of sizing auto-width children etc, but
treated as constrained for line wrapping. I'm not sure we can do this.

One thing which I want to try is whacking the scrolled block width constraint
into the reflow state's mComputedMaxWidth instead of mComputedWidth, in
nsBoxToBlockAdaptor::Reflow. I have no idea whether this can or should work :-).
Created attachment 144099 [details]
testcase as described

This shows that older builds would screw up multi-line floating scrollframes.
This should work in current builds --- at the expense of causing the regression
in this bug :-(
> I have no idea whether this can or should work :-).

It doesn't seem to work...

If we can't come up with a solution, I'm not even sure which bug(s) we should
ship with.
Note that most of this pain is because nsGfxScrollFrames are really XUL boxes.
If they were regular frames that behaved more like blocks, this probably
wouldn't be nearly as hard. Maybe we should  separate XUL scrollframes from
HTML/CSS scrollframes.

Updated

14 years ago
Flags: blocking1.7b?
Flags: blocking1.7b-
Flags: blocking1.7?
My guess is that we're going to have to back out the fix for 235558 and live
with it (and other bugs that don't seem to have been reported, like multi-line
overflow:hidden floats) until someone can rewrite HTML scrollframes to not suck.
just making sure we get this resolved for 1.7, it breaks sites that are in the
top100 for camino (eg, versiontracker).
The backout is approved and reviewed, I just haven't had time to check it in
(and babysit tinderbox)
Ok, I checked in the backout.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 18

14 years ago
*** Bug 238239 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking1.7?
You need to log in before you can comment on or make changes to this bug.