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)
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.
Reporter | ||
Comment 1•26 years ago
|
||
Oh yeah, Seamonkey 3/2 viewer.
Updated•26 years ago
|
Assignee: peterl → kipp
Component: Style System → Layout
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...
Updated•26 years ago
|
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
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.
Updated•25 years ago
|
Summary: {ll} line-breaking bug caused by negative margins on inlines → {ll} {css1} line-breaking bug caused by negative margins on inlines
Comment 7•25 years ago
|
||
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...
Updated•25 years ago
|
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
Comment 10•25 years ago
|
||
this is at risk for FCS. very bad, since it's a CSS1 compliance issue
Comment 11•25 years ago
|
||
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}
Comment 12•25 years ago
|
||
redistributing bugs across future milestones, sorry for the spam
Reporter | ||
Comment 13•25 years ago
|
||
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
Comment 14•25 years ago
|
||
[nsbeta2-] since Steve Clark says this is less important than the [P-Margin]
bugs he's looking at right now.
Whiteboard: [nsbeta2-]
Comment 15•25 years ago
|
||
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
Comment 16•25 years ago
|
||
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.
Comment 17•25 years ago
|
||
Reporter | ||
Comment 19•25 years ago
|
||
Nominating nsbeta2,nsbeta3,rtm. Recc. nsbeta2+, falling through to nsbeta3+ and
rtm+ if necessary. This is a W3C CSS1 Official Test Suite compliance bug.
Reporter | ||
Comment 20•25 years ago
|
||
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-]
Comment 21•25 years ago
|
||
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
Updated•25 years ago
|
Summary: line-breaking bug caused by negative margins on inlines {ll} → [INLINE-H]line-breaking bug caused by negative margins on inlines {ll}
Updated•25 years ago
|
QA Contact: chrisd → py8ieh=bugzilla
Whiteboard: [nsbeta2-] → [nsbeta2-] hit during nsbeta2 standards compliance testing
Comment 22•25 years ago
|
||
Ian: has this been fixed? It looks okay using 7_27_04 build on Win 98.
Comment 23•25 years ago
|
||
It doesn't look ok on Win2000 commerical build 6.0.17.2000072811.
It looks exactly the same as shown in the screenshot attached.
Comment 24•25 years ago
|
||
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?
Comment 25•25 years ago
|
||
Approving for beta3: high-profile compliance test site.
Whiteboard: [nsbeta2-] hit during nsbeta2 standards compliance testing → [nsbeta2-] [nsbeta3+] hit during nsbeta2 standards compliance testing
Comment 26•25 years ago
|
||
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}
Assignee | ||
Comment 27•25 years ago
|
||
I'll take in hopes that it might be related to the other bug.
Assignee: buster → waterson
Status: ASSIGNED → NEW
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M19 → M18
Comment 28•25 years ago
|
||
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).
Comment 29•25 years ago
|
||
Assignee | ||
Comment 30•25 years ago
|
||
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.
Assignee | ||
Comment 31•25 years ago
|
||
Assignee | ||
Comment 32•25 years ago
|
||
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).
Assignee | ||
Comment 33•25 years ago
|
||
Comment 34•25 years ago
|
||
Although I can't see the new problem, it sounds worse than the old...
Reporter | ||
Comment 35•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Priority: P3 → P2
Comment 36•24 years ago
|
||
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
Comment 37•24 years ago
|
||
We know exactly where this bug is being triggered, right? All we need is a
better algorithm.
Assignee | ||
Comment 38•24 years ago
|
||
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
Assignee | ||
Comment 39•24 years ago
|
||
Assignee | ||
Comment 40•24 years ago
|
||
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!)
Assignee | ||
Comment 41•24 years ago
|
||
Comment 42•24 years ago
|
||
Requesting a triage on this bug. It's nominated but doesn't have a - or +. Are
we going to fix this for rtm ?
Assignee | ||
Updated•24 years ago
|
Whiteboard: [nsbeta2-] [nsbeta3-][PDTP4] hit during nsbeta2 standards compliance testing → [nsbeta2-] [nsbeta3-][PDTP4][rtm-] hit during nsbeta2 standards compliance testing
Updated•24 years ago
|
Whiteboard: [nsbeta2-] [nsbeta3-][PDTP4][rtm-] hit during nsbeta2 standards compliance testing → hit during nsbeta2 standards compliance testing
Updated•24 years ago
|
Keywords: mozilla0.9,
nsbeta1
Whiteboard: hit during nsbeta2 standards compliance testing → [Hixie-P2] (high profile: css1 test suite)
Comment 43•24 years ago
|
||
waterson: if you're at a loss of what to fix next, I would recommend looking at
this bug and its sister, bug 46918. :-)
Comment 44•23 years ago
|
||
I do not see this problem anymore on win98 buildID: 2002-01-02-06trunk.
Comment 45•23 years ago
|
||
I still see it.
Assignee | ||
Updated•23 years ago
|
Target Milestone: Future → mozilla0.9.9
Assignee | ||
Updated•23 years ago
|
Attachment #12990 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #15417 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #15418 -
Attachment is obsolete: true
Assignee | ||
Comment 46•23 years ago
|
||
Should be fixed along with bug 46918.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•