WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
72987
CSS 2.1 failure: first-letter-nested-004.htm fails
https://bugs.webkit.org/show_bug.cgi?id=72987
Summary
CSS 2.1 failure: first-letter-nested-004.htm fails
Robert Hogan
Reported
2011-11-22 15:05:19 PST
Need to check each text child until a line-break or a text node that is not all whitespace is found.
Attachments
Patch
(99.59 KB, patch)
2011-11-26 08:58 PST
,
Robert Hogan
no flags
Details
Formatted Diff
Diff
Patch
(32.21 KB, patch)
2012-03-31 10:02 PDT
,
Robert Hogan
no flags
Details
Formatted Diff
Diff
Archive of layout-test-results from ec2-cr-linux-03
(7.17 MB, application/zip)
2012-03-31 11:41 PDT
,
WebKit Review Bot
no flags
Details
Patch
(32.77 KB, patch)
2012-04-01 07:35 PDT
,
Robert Hogan
no flags
Details
Formatted Diff
Diff
Patch
(142.81 KB, patch)
2012-04-12 14:00 PDT
,
Robert Hogan
eric
: review+
webkit.review.bot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from ec2-cr-linux-02
(6.26 MB, application/zip)
2012-04-12 19:26 PDT
,
WebKit Review Bot
no flags
Details
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Robert Hogan
Comment 1
2011-11-26 08:58:27 PST
Created
attachment 116658
[details]
Patch
Robert Hogan
Comment 2
2012-01-16 15:09:16 PST
Hi Julien, Can you take a look at this? Thanks!
Julien Chaffraix
Comment 3
2012-01-17 14:14:31 PST
Comment on
attachment 116658
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=116658&action=review
Robert, this is not an area of the code I know enough to review this patch. I just looked over the patch quickly.
> Source/WebCore/rendering/RenderBlock.cpp:-5746 > -
Unrelated change, it is also arguably better this way.
> Source/WebCore/rendering/RenderBlock.h:477 > + RenderObject* firstLetterInChild(RenderObject* currChild, RenderObject* &firstLetterBlock); > + RenderObject* firstLetterInChildren(RenderObject* currChild, RenderObject* &firstLetterBlock);
I find the 2 functions' name confusing. Especially since the second calls the first. Adding a verb would likely help. If those 2 functions had a really different name, it would also reduce the confusion between the 2.
Robert Hogan
Comment 4
2012-03-31 10:02:18 PDT
Created
attachment 134963
[details]
Patch
WebKit Review Bot
Comment 5
2012-03-31 11:41:21 PDT
Comment on
attachment 134963
[details]
Patch
Attachment 134963
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/12253863
New failing tests: fast/css/first-letter-capitalized-edit-select-crash.html
WebKit Review Bot
Comment 6
2012-03-31 11:41:28 PDT
Created
attachment 134969
[details]
Archive of layout-test-results from ec2-cr-linux-03 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Robert Hogan
Comment 7
2012-04-01 07:35:40 PDT
Created
attachment 134998
[details]
Patch
Eric Seidel (no email)
Comment 8
2012-04-10 10:58:12 PDT
Comment on
attachment 134998
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=134998&action=review
> Source/WebCore/rendering/RenderBlock.cpp:6046 > +RenderObject* RenderBlock::firstLetterInSibling(RenderObject* currChild, RenderObject* &firstLetterBlock)
I'm not sure "inSibling" is the right name here. This method seems to have little to do with being a sibling to anything. maybe InNode? or underNode? I also might call currChild "root" and have a separate currChild. Also, I wonder if we could pull the addFirstLetter call outside of this function? Could it be done in the caller, right before returning currChild?
> Source/WebCore/rendering/RenderBlock.cpp:6055 > + // If we call addFirstLetter(), currChild will be destroyed.
Always, or just could be?
> Source/WebCore/rendering/RenderBlock.cpp:6067 > + if (currChild->style()->styleType() == FIRST_LETTER) {
I'm confused what this check is for.
> Source/WebCore/rendering/RenderBlock.cpp:6072 > + } else if (currChild->isReplaced() || currChild->isRenderButton() || currChild->isMenuList())
Is button and menu-list not replaced? Why do they need separate checks?
Robert Hogan
Comment 9
2012-04-12 14:00:01 PDT
Created
attachment 136967
[details]
Patch
WebKit Review Bot
Comment 10
2012-04-12 19:26:04 PDT
Comment on
attachment 136967
[details]
Patch
Attachment 136967
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/12390777
New failing tests: media/video-loop.html accessibility/aria-disabled.html http/tests/xmlhttprequest/xmlhttprequest-unsafe-redirect.html fast/canvas/webgl/shader-precision-format.html media/video-pause-immediately.html media/video-muted.html fast/loader/text-document-wrapping.html
WebKit Review Bot
Comment 11
2012-04-12 19:26:10 PDT
Created
attachment 137027
[details]
Archive of layout-test-results from ec2-cr-linux-02 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-02 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Robert Hogan
Comment 12
2012-04-13 13:35:28 PDT
(In reply to
comment #11
)
> Created an attachment (id=137027) [details] > Archive of layout-test-results from ec2-cr-linux-02 > > The attached test failures were seen while running run-webkit-tests on the chromium-ews. > Bot: ec2-cr-linux-02 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
These failures are unrelated to my patch - I don't see them locally.
Robert Hogan
Comment 13
2012-04-13 13:58:57 PDT
(In reply to
comment #8
)
> (From update of
attachment 134998
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=134998&action=review
> > > Source/WebCore/rendering/RenderBlock.cpp:6046 > > +RenderObject* RenderBlock::firstLetterInSibling(RenderObject* currChild, RenderObject* &firstLetterBlock) > > I'm not sure "inSibling" is the right name here. This method seems to have little to do with being a sibling to anything. maybe InNode? or underNode? I also might call currChild "root" and have a separate currChild.
I've improved the names I think.
> > Also, I wonder if we could pull the addFirstLetter call outside of this function? Could it be done in the caller, right before returning currChild?
Not really, I think. I've refactored the patch quite a bit so I'm not sure if this is still a concern.
> > > Source/WebCore/rendering/RenderBlock.cpp:6055 > > + // If we call addFirstLetter(), currChild will be destroyed. > > Always, or just could be?
Refactoring has made this a non-issue.
> > > Source/WebCore/rendering/RenderBlock.cpp:6067 > > + if (currChild->style()->styleType() == FIRST_LETTER) { > > I'm confused what this check is for.
Added a comment.
> > > Source/WebCore/rendering/RenderBlock.cpp:6072 > > + } else if (currChild->isReplaced() || currChild->isRenderButton() || currChild->isMenuList()) > > Is button and menu-list not replaced? Why do they need separate checks?
This is existing code. As far as I can tell they will only be isReplaced() if they are inline, which I guess they will be most of the time, but not if display is set otherwise.
Eric Seidel (no email)
Comment 14
2012-04-13 14:24:30 PDT
Comment on
attachment 136967
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=136967&action=review
This looks good as far as I can tell.
> Source/WebCore/rendering/RenderBlock.cpp:5967 > + if (child->isText()) {
Is this function hot? Do we need to worry about ordering the cases such that it's most likely to return early?
> Source/WebCore/rendering/RenderBlock.cpp:5997 > + // We found a lower-level node with first-letter, which supersedes the higher-level style
Should end with a period.
Robert Hogan
Comment 15
2012-05-08 11:24:57 PDT
Committed
r116438
: <
http://trac.webkit.org/changeset/116438
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug