Closed Bug 3490 Opened 26 years ago Closed 23 years ago

[INLINE-H] line-breaking bug caused by -ve margin-right on inline elements [LINE] {ll}

Categories

(Core :: Layout, defect, P4)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: ekrock, Assigned: waterson)

References

()

Details

(Keywords: css1, helpwanted, testcase, Whiteboard: [Hixie-P2] (high profile: css1 test suite))

Attachments

(3 files, 3 obsolete files)

This text: This element is unstyled save for a background color of gray.. It contains an inline element of class two, giving it an aqua background and a -10px margin looked like this: Page margin | This element is unstyled save for a background | color of gray.. It contains an inline element of class two, giving it an aqua background | and a -10px margin This was with browser window width set to 2/5 screen width.
Oh yeah, Seamonkey 3/2 viewer.
Assignee: peterl → kipp
Component: Style System → Layout
Status: NEW → ASSIGNED
Summary: negative margin on inline element is set relative to page left margin instead of current text position → line-breaking bug
Some how the content in this page triggers an interesting line-breaking bug. depending on the width of the window either the line breaks before the span with the negative left margin or not...
*** Bug 5469 has been marked as a duplicate of this bug. ***
Summary: line-breaking bug → {css1} line-breaking bug caused by negative margins on inlines
Summary: {css1} line-breaking bug caused by negative margins on inlines → {ll} line-breaking bug caused by negative margins on inlines
Target Milestone: M17 → M13
Updating to default Layout Assignee...kipp no longer with us :-(
Why are you re-reassing layout bugs? Do NOT touch layout bugs. The bugs are assigned to Kipp so they can stay neatly organized until we have a new owner for the block/inline code.
mass moving all Kipp's pre-beta bugs to M15. Nisheeth and I will prioritize these and selectively move high-priority bugs into M13 and M14.
Summary: {ll} line-breaking bug caused by negative margins on inlines → {ll} {css1} line-breaking bug caused by negative margins on inlines
Keywords: css1
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...
Summary: {ll} {css1} line-breaking bug caused by negative margins on inlines → {ll} line-breaking bug caused by negative margins on inlines
kipp is very unlikely to fix these, since he's not working ont he project any longer. so I'll take a look.
Assignee: kipp → buster
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
this is at risk for FCS. very bad, since it's a CSS1 compliance issue
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: M16 → M19
Note, BTW, that this is a _bug_ and not merely a lack of support for the spec. IIRC, what we are doing is rather bad/buggy/broken, as opposed to just not what it says in the spec.
Keywords: testcase
Summary: {ll} line-breaking bug caused by negative margins on inlines → line-breaking bug caused by negative margins on inlines {ll}
Target Milestone: M19 → M21
redistributing bugs across future milestones, sorry for the spam
Nom. nsbeta2, recc. nsbeta2 6/22 with fall-through to nsbeta3+ if not fixed. CSS1 non-compliance problem that's showing up on official W3C test suite. Also per Ian's comments this is a situation where we break the standard and possible render that feature unusable, rather than just displaying in an ugly way.
Keywords: nsbeta2
[nsbeta2-] since Steve Clark says this is less important than the [P-Margin] bugs he's looking at right now.
Whiteboard: [nsbeta2-]
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M21 → Future
Considering this bug is marked nsbeta2-, with a recommendation of nsbeta3+ from Eric Krock, are we to assume that this bug being marked Future is an error? This bug occurs on the Official CSS1 Test Suite too, so is quite high-profile.
brought back from the dead
Target Milestone: Future → M19
Nominating nsbeta2,nsbeta3,rtm. Recc. nsbeta2+, falling through to nsbeta3+ and rtm+ if necessary. This is a W3C CSS1 Official Test Suite compliance bug.
Keywords: nsbeta3, rtm
Sorry, to clarify: this is not an nsbeta2 stopper, but I'd permit checking in prior to nsbeta2 if we have a fix. Recc. nsbeta2+[some lenient date-], falling through to nsbeta3+ hard stop if not fixed during nsbeta2. This is a W3C CSS1 Official Test Suite compliance bug. Clearing [nsbeta2-] to trigger re-evaluation.
Whiteboard: [nsbeta2-]
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
Summary: line-breaking bug caused by negative margins on inlines {ll} → [INLINE-H]line-breaking bug caused by negative margins on inlines {ll}
QA Contact: chrisd → py8ieh=bugzilla
Whiteboard: [nsbeta2-] → [nsbeta2-] hit during nsbeta2 standards compliance testing
Ian: has this been fixed? It looks okay using 7_27_04 build on Win 98.
It doesn't look ok on Win2000 commerical build 6.0.17.2000072811. It looks exactly the same as shown in the screenshot attached.
ChrisD found something important: The problem only occurs if the RIGHT margin (in left-to-right flowing and left aligned text) is negative. The other margins are irrelevant. Does this help in the fixing?
Approving for beta3: high-profile compliance test site.
Whiteboard: [nsbeta2-] hit during nsbeta2 standards compliance testing → [nsbeta2-] [nsbeta3+] hit during nsbeta2 standards compliance testing
See also related bug 46918, which shows a mundane but more serious problem with positive right margins on inline elements.
Summary: [INLINE-H]line-breaking bug caused by negative margins on inlines {ll} → [INLINE-H] line-breaking bug caused by -ve margin-right on inline elements [LINE] {ll}
I'll take in hopes that it might be related to the other bug.
Assignee: buster → waterson
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M19 → M18
I think the exact condition when this bug happened is when the line would be broken a word earlier if the -10px margin would not there. As you gradually shrink the window from a wide width, you can see that every time you get to a point where you should knock one word down to the next line, it knocks down the whole beginning of the inline element, for about 10 px (I think).
The problem starts here: http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsLineLayout.cpp#1167 Specifically, we subtract from the space available on the line *both* the left and right margins. We can't correctly subtract the right margin until we've decided to fit the entire span onto a single line. With negative margins set, this causes us to over-estimate the amount of space available on the line. We panic later in nsLineLayout::CanPlaceFrame() when we realize that we can't fit the entire span onto the line: http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsLineLayout.cpp#1270 ...which forces the span down to the next line.
Attached patch half-assed fix (obsolete) (deleted) — Splinter Review
The above fix makes it so that the right margin does not come into play in computing the amound of space left on the line. This means that we'll botch some cases with *positive* margins on inline elements. For example, the second paragraph in the test case I'm about to attach (when displayed at 620x400, "viewer's" default size).
Although I can't see the new problem, it sounds worse than the old...
In general, I think that the usage of positive margin values will be >> 10x more frequent than the usage of negative margin values, so I'd be very reluctant to take a fix that improved negative margin handling at the cost of messing up positive margin handling in some cases.
Priority: P3 → P2
PDT thinks this is a P4
Priority: P2 → P4
Whiteboard: [nsbeta2-] [nsbeta3+] hit during nsbeta2 standards compliance testing → [nsbeta2-] [nsbeta3+][PDTP4] hit during nsbeta2 standards compliance testing
We know exactly where this bug is being triggered, right? All we need is a better algorithm.
next train...
Whiteboard: [nsbeta2-] [nsbeta3+][PDTP4] hit during nsbeta2 standards compliance testing → [nsbeta2-] [nsbeta3-][PDTP4] hit during nsbeta2 standards compliance testing
Target Milestone: M18 → Future
Attached patch work-in-progress for a fix (obsolete) (deleted) — Splinter Review
Started looking at the problems with inline elements and margins, padding, and borders. The way it's been written works only if the inline box never needs to split: the margins, borders, and padding are all subtracted from the "available width" that's given to the child frame. The above patch is work-in-progress: since nsTextFrame's are the only frames that can be split, I tried adding some special case logic that allows the available width be the the computed available width, but with the right margins, borders, and padding added back from all the containing inline frames. This logic is used *unless* the frame is the last unsplittable text. (One of the problems with this patch is that I don't figure that out quite right currently!)
Attached patch oops, forgot a file. try this patch instead. (obsolete) (deleted) — Splinter Review
Requesting a triage on this bug. It's nominated but doesn't have a - or +. Are we going to fix this for rtm ?
Whiteboard: [nsbeta2-] [nsbeta3-][PDTP4] hit during nsbeta2 standards compliance testing → [nsbeta2-] [nsbeta3-][PDTP4][rtm-] hit during nsbeta2 standards compliance testing
Keywords: nsbeta2, nsbeta3, rtmmozilla1.0
Whiteboard: [nsbeta2-] [nsbeta3-][PDTP4][rtm-] hit during nsbeta2 standards compliance testing → hit during nsbeta2 standards compliance testing
Keywords: mozilla0.9, nsbeta1
Whiteboard: hit during nsbeta2 standards compliance testing → [Hixie-P2] (high profile: css1 test suite)
waterson: if you're at a loss of what to fix next, I would recommend looking at this bug and its sister, bug 46918. :-)
Blocks: 104166
I do not see this problem anymore on win98 buildID: 2002-01-02-06trunk.
I still see it.
Target Milestone: Future → mozilla0.9.9
Depends on: 46918
Attachment #12990 - Attachment is obsolete: true
Attachment #15417 - Attachment is obsolete: true
Attachment #15418 - Attachment is obsolete: true
Should be fixed along with bug 46918.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
VERIFIED FIXED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: