Closed
Bug 287088
Opened 20 years ago
Closed 15 years ago
::first-line incorrectly applied to entirety of child element that spans past first line
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
People
(Reporter: jonathan.snook, Assigned: tnikkel)
References
()
Details
Attachments
(4 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 In the page at http://www.snook.ca/technical/ff_first-line.html, only the first line of text should be uppercase. In Firefox, the style is being applied to the entire child element (span). Reproducible: Always Steps to Reproduce: 1. Create a block level element and apply a style to it using the :first-line selector. 2. add an inline child element whose contents extend onto more than one line. Actual Results: Any style applied to the block level element gets applied to the entirety of the child element. Expected Results: Only the portion of the child element that occurs on the first line should have the style applied. See http://www.w3.org/TR/CSS21/selector.html#q20 for more information.
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: :first-line incorrectly applied to entirety of child element that spans past first line → ::first-line incorrectly applied to entirety of child element that spans past first line
Comment 1•20 years ago
|
||
After resizing everyone turns back to normal. This is not happening for all styles by the way, I will attach a testcase using 'background' instead of 'text-transform' as well.
Comment 2•20 years ago
|
||
Comment 3•20 years ago
|
||
I'm pretty sure we have a bug on this already (the problem has to do with the continuing lineframes sharing the first-line style context for some reason...)
Keywords: qawanted
Whiteboard: DUPEME
Comment 4•19 years ago
|
||
This bug looks like fixed to be in current trunk...someone can confirm?
Comment 5•19 years ago
|
||
Ok, forget it, only the testcase - background:lime works for me. The other one does not.
Updated•19 years ago
|
Attachment #178134 -
Attachment description: testcase - background:lime → testcase - background:lime (does not show the bug)
now this works, for both testcases, using the trunk Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060205 Firefox/1.6a1 ID:2006020505
Assignee: dbaron → nobody
QA Contact: ian → style-system
Comment 7•17 years ago
|
||
(In reply to comment #6) > now this works, for both testcases, using the trunk The first testcase does not work for me using a current trunk build. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007102104
| Assignee | ||
Comment 8•15 years ago
|
||
The two testcases currently in this bug do not show the problem because there needs to be a scrollbar because we reflow first assuming a scrollbar, if it turns out a scrollbar is not needed another reflow is targeted at the viewport and that extra reflow corrects the problem. So this testcases uses a very tall div to ensure a scrollbar so that the problem is visible.
| Assignee | ||
Comment 9•15 years ago
|
||
So the problem is this. We create a continuation of the textframe, then we create an empty continuation for the inline (span), then a continuation of the Line frame. When we reflow the continuation of the Line frame (nsFirstLineFrame::Reflow) we pull the empty continuation for the inline (span) and reparent its style context. Then when we reflow the empty continuation for the inline (span) we pull the continuation of the textframe in nsInlineFrame::Reflow, but that function does not do any style context reparenting.
| Assignee | ||
Comment 10•15 years ago
|
||
So this patch fixes the problem but I still want to think about a few things. If I can restore the optimization to work in the first-line case. Are there other places we could be pulling frames in a first-line situation where we need to reparent style contexts.
Assignee: nobody → tnikkel
| Assignee | ||
Updated•15 years ago
|
| Assignee | ||
Comment 11•15 years ago
|
||
This restores the optimization.
Attachment #412159 -
Attachment is obsolete: true
Attachment #414005 -
Flags: review?(roc)
Comment on attachment 414005 [details] [diff] [review] patch + nsFrameManager* frameManager = inFirstLine ? + aPresContext->FrameManager() : nsnull; I think you can just set frameManager unconditionally.
Attachment #414005 -
Flags: review?(roc) → review+
| Assignee | ||
Comment 13•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/d9880a999a3d
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
You need to log in
before you can comment on or make changes to this bug.
Description
•