::first-letter applies to entire line following <br> at start of block

VERIFIED FIXED

Status

()

defect
VERIFIED FIXED
12 years ago
10 years ago

People

(Reporter: nm127, Assigned: roc)

Tracking

({regression, verified1.9.0.2, verified1.9.1})

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
wanted1.9.1 +
blocking1.9.0.1 -
wanted1.9.0.x +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(5 attachments)

Reporter

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; hu; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; hu; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3

The sentence "This line should be green." is yellow and has red background at test case http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/xhtml/full/flat/css3-modsel-180a.xml

Reproducible: Always

Steps to Reproduce:
1. Open test case at http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/xhtml/full/flat/css3-modsel-180a.xml

Actual Results:  
The sentence "This line should be green." is yellow and has red background.

If the window is resized so that the sentence wrap to multiple lines, then the second line will be green. Then, if the window is resized again so large that the senence would fit into one line, the second line remains.

Expected Results:  
The sentence "This line should be green." is green.

If the window resized, the sentence wraps and unwraps as needed.
Reporter

Comment 1

12 years ago
The screenshot was created with:
Mozilla/5.0 (X11; U; Linux i686; hu; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3
Reporter

Comment 2

12 years ago
Reporter

Comment 3

12 years ago
The sentence "This line should be green." is still displayed in two lines like this:

This
line should be green.
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → style-system
Component: Style System (CSS) → Layout: Block and Inline
QA Contact: style-system → layout.block-and-inline
Summary: W3C CSS3 Selector test fails: "::first-letter after <br> (ID #180a)" → ::first-letter applies to entire line following <br> at start of block
Ouch.
And that is a regression from Gecko 1.8.1

Further more, the :first-letter should not be applied at all, per
http://www.w3.org/TR/css3-selectors/#first-letter

(Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008062020 Minefield/3.1a1pre)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Keywords: regression
OS: Linux → All
Hardware: PC → All
Version: unspecified → Trunk
Posted file testcase
Flags: blocking1.9.0.1?
nsCSSFrameConstructor::WrapFramesInFirstLetterFrame treats the BR frame as inline since it's an eLineParticipant, so it carries on and wraps the following text frame in an nsFirstLetterFrame. Then during reflow, firstLetterStyleOK is correctly returning false during reflow of the text line --- since it's not the first line --- but nsFirstLetterFrame still has the first-letter style. It only turns off the first-letter style when it creates a continuation and here, since firstLetterStyleOK is false, the text frame doesn't break internally so nsFirstLetterFrame never gets a chance to create a continuation without the first-letter style.
Posted patch fixSplinter Review
This approach is very simple and fixes the bug. I think it's the best approach; modifying nsFirstLetterFrame to handle cases where the first-in-flow should not have first-letter style seems hard.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #326395 - Flags: superreview?(dbaron)
Attachment #326395 - Flags: review?(dbaron)
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
I wonder if this is also causing bug 431341.  Will experiment.
alas, while I do still suspect the interpolation of nsFirstLetterFrame is causing bug 431341, this patch does not cure it.
Comment on attachment 326395 [details] [diff] [review]
fix

r+sr=dbaron
Attachment #326395 - Flags: superreview?(dbaron)
Attachment #326395 - Flags: superreview+
Attachment #326395 - Flags: review?(dbaron)
Attachment #326395 - Flags: review+
Pushed a50ca180ed3e
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Works perfectly with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/2008073016 Minefield/3.1a2pre

Based on comment 8, this sounds a simple fix. Can this be ported to the 1.9.0.x branch ?
Flags: wanted1.9.0.x?
Yeah, we should get this on 1.9.0.x. roc, can you request approval on a 1.9 patch?
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Comment on attachment 326395 [details] [diff] [review]
fix

Approved for 1.9.0.2. Please land in CVS. a=ss
Attachment #326395 - Flags: approval1.9.0.2? → approval1.9.0.2+
Verified for 1.9.0.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2) Gecko/2008090212 Firefox/3.0.2.
verified FIXED on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090413 Minefield/3.6a1pre ID:20090413031052

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090413 Minefield/3.6a1pre ID:20090413031052
Status: RESOLVED → VERIFIED
ack, here's the build ID for Shiretoko Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090413 Shiretoko/3.5b4pre ID:20090413031313
You need to log in before you can comment on or make changes to this bug.