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)

defect
Not set
normal

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.
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
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.
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
This bug looks like fixed to be in current trunk...someone can confirm?
Ok, forget it, only the testcase - background:lime works for me. The other one does not.
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
Blocks: 317892
Assignee: dbaron → nobody
QA Contact: ian → style-system
(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

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.
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.
Attached patch wip (obsolete) — Splinter Review
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
Keywords: qawanted
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: DUPEME
Attached patch patchSplinter Review
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+
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.

Attachment

General

Creator:
Created:
Updated:
Size: