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.
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
(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
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
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
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.
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 :-)
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.
14 years ago
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.
14 years ago
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
14 years ago
*** Bug 238239 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.