WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
130101
Ensure that layout milestones complete in all cases
https://bugs.webkit.org/show_bug.cgi?id=130101
Summary
Ensure that layout milestones complete in all cases
Antti Koivisto
Reported
2014-03-11 16:34:24 PDT
In some testing scenarios milestones fail to complete.
Attachments
patch
(7.49 KB, patch)
2014-03-11 17:10 PDT
,
Antti Koivisto
darin
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Antti Koivisto
Comment 1
2014-03-11 17:10:20 PDT
Created
attachment 226451
[details]
patch
Pratik Solanki
Comment 2
2014-03-11 17:13:02 PDT
<
rdar://problem/14651144
>
Darin Adler
Comment 3
2014-03-12 09:51:47 PDT
Comment on
attachment 226451
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=226451&action=review
Some risk in changing the order of things here, but seems obviously a step int he right direction.
> Source/WebCore/dom/Document.cpp:2490 > + if (!m_bParsing && view() && !view()->needsLayout()) > + view()->fireLayoutRelatedMilestonesIfNeeded();
It’s hard to understand the relationships here. I think that future me would understand this better if the function the document called on FrameView was named something more like “document emptiness status may have changed”, and that function would then turn around and do this: if (!needsLayout) fireLayoutRelatedMilestonesIfNeeded within the FrameView class.
> Source/WebCore/page/FrameView.cpp:4129 > + Page* page = frame().page(); > + if (page)
I’d put the variable inside the if statement.
Antti Koivisto
Comment 4
2014-03-13 08:42:39 PDT
https://trac.webkit.org/r165534
Antti Koivisto
Comment 5
2014-03-13 08:45:47 PDT
> It’s hard to understand the relationships here. I think that future me would understand this better if the function the document called on FrameView was named something more like “document emptiness status may have changed”, and that function would then turn around and do this: > > if (!needsLayout) fireLayoutRelatedMilestonesIfNeeded > > within the FrameView class.
Didn't do this. That would essentially be another finishedParsing function which we already have in multiple places. Some sort of bigger cleanup is needed.
> I’d put the variable inside the if statement.
It is used below too.
Simon Fraser (smfr)
Comment 6
2014-03-13 09:03:49 PDT
Comment on
attachment 226451
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=226451&action=review
Should we make a way to layout-test milestones?
> Source/WebCore/page/FrameView.cpp:2669 > + if (auto* page = frame().page()) { > + if (auto* scrollingCoordinator = page->scrollingCoordinator())
Why auto here...
>> Source/WebCore/page/FrameView.cpp:4129 >> + Page* page = frame().page(); >> + if (page) > > I’d put the variable inside the if statement.
but no auto here? I'd prefer less auto, not more.
Antti Koivisto
Comment 7
2014-03-13 10:40:49 PDT
https://trac.webkit.org/r165534
https://trac.webkit.org/r165543
(iOS build fix)
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