WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
143320
[New Block-Inside-Inline Model] Implement the correct painting order for blocks inside inlines
https://bugs.webkit.org/show_bug.cgi?id=143320
Summary
[New Block-Inside-Inline Model] Implement the correct painting order for bloc...
Dave Hyatt
Reported
2015-04-01 15:02:48 PDT
The painting order has to match the old continuation-based model.
Attachments
Patch (just for ews)
(20.27 KB, patch)
2015-04-01 15:03 PDT
,
Dave Hyatt
no flags
Details
Formatted Diff
Diff
Patch
(32.02 KB, patch)
2015-04-02 09:19 PDT
,
Dave Hyatt
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Dave Hyatt
Comment 1
2015-04-01 15:03:15 PDT
Created
attachment 249944
[details]
Patch (just for ews)
WebKit Commit Bot
Comment 2
2015-04-01 15:06:09 PDT
Attachment 249944
[details]
did not pass style-queue: ERROR: Source/WebCore/rendering/InlineFlowBox.cpp:1135: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] Total errors found: 1 in 14 files If any of these errors are false positives, please file a bug against check-webkit-style.
Dave Hyatt
Comment 3
2015-04-02 09:19:22 PDT
Created
attachment 249984
[details]
Patch
Darin Adler
Comment 4
2015-04-02 09:40:26 PDT
Comment on
attachment 249984
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=249984&action=review
Is this enough testing to cover all the code?
> Source/WebCore/rendering/EllipsisBox.cpp:143 > +bool EllipsisBox::nodeAtPoint(const HitTestRequest& request, HitTestResult& result, const HitTestLocation& locationInContainer, const LayoutPoint& accumulatedOffset, LayoutUnit lineTop, LayoutUnit lineBottom, HitTestAction hitTestAction)
Argument list here is getting out of hand. Can we further merge some of these intro structs and classes?
> Source/WebCore/rendering/InlineElementBox.cpp:74 > + PaintPhase newPhase = (paintInfo.phase == PaintPhaseChildOutlines) ? PaintPhaseOutline : paintInfo.phase; > + newPhase = (newPhase == PaintPhaseChildBlockBackgrounds) ? PaintPhaseChildBlockBackground : newPhase;
This seems like a strange way to write it. How about a switch? PaintInfo subtreePaintInfo = paintInfo; switch (subtreePaintInfo.phase) { case PaintPhaseChildOutlines: subtreePaintInfo.phase = PaintPhaseOutline; break; case PaintPhaseChildBlockBackgrounds: subtreePaintInfo.phase = PaintPhaseChildBlockBackground; break; default: break; } Or if you want it to look more compact, you can use this kind of formatting (and we can change the coding style guidelines to allow it). switch (subtreePaintInfo.phase) { case PaintPhaseChildOutlines: subtreePaintInfo.phase = PaintPhaseOutline; break; case PaintPhaseChildBlockBackgrounds: subtreePaintInfo.phase = PaintPhaseChildBlockBackground; break; default: break; } The ? : seem harder to read.
Dave Hyatt
Comment 5
2015-04-02 11:35:57 PDT
Fixed in
r182279
.
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