Title: [203184] branches/safari-602.1.40.1-branch/Source/WebCore
- Revision
- 203184
- Author
- [email protected]
- Date
- 2016-07-13 13:32:57 -0700 (Wed, 13 Jul 2016)
Log Message
Merged r203172. rdar://problem/27306545
Modified Paths
Diff
Modified: branches/safari-602.1.40.1-branch/Source/WebCore/ChangeLog (203183 => 203184)
--- branches/safari-602.1.40.1-branch/Source/WebCore/ChangeLog 2016-07-13 20:31:37 UTC (rev 203183)
+++ branches/safari-602.1.40.1-branch/Source/WebCore/ChangeLog 2016-07-13 20:32:57 UTC (rev 203184)
@@ -1,3 +1,46 @@
+2016-07-13 Babak Shafiei <[email protected]>
+
+ Merge r203172.
+
+ 2016-07-13 Antti Koivisto <[email protected]>
+
+ v2: WebContent crash due to RELEASE_ASSERT(!m_inLoadPendingImages) in StyleResolver::~StyleResolver()
+ https://bugs.webkit.org/show_bug.cgi?id=159722
+
+ Reviewed by Andreas Kling.
+
+ We have crashes where a StyleResolver is deleted underneath pseudoStyleForElement (key parts of the stack):
+
+ 0 WebCore::StyleResolver::~StyleResolver
+ 3 WebCore::AuthorStyleSheets::updateActiveStyleSheets
+ 4 WebCore::Document::styleResolverChanged
+ 5 WebKit::WebPage::viewportConfigurationChanged()
+ 6 WebKit::WebPage::mainFrameDidLayout()
+ 9 WebCore::FrameLoader::checkCompleted
+ 13 WebCore::ResourceLoader::cancel
+ 19 WebKit::WebLoaderStrategy::loadResource
+ 24 WebCore::Style::loadPendingImage
+ 27 WebCore::StyleResolver::pseudoStyleForElement
+ 29 WebCore::RenderTreeUpdater::updateBeforeOrAfterPseudoElement
+ 33 WebCore::Document::recalcStyle
+
+ This appears to be happening when a content blocker blocks a resource load for an image referenced from a stylesheet
+ and triggers synchronous cancellation of the load. With engine in suitable state this can clear style resolver.
+
+ No test, don't know how to make one. This is very timing and engine state dependent.
+
+ * dom/AuthorStyleSheets.cpp:
+ (WebCore::AuthorStyleSheets::updateActiveStyleSheets):
+
+ We have an existing check here that prevents destruction of the style resolver when we are in the middle of
+ a style resolution. However the old inStyleRecalc() bit no longer covers the render tree update phase. Pseudo
+ elements are resolved during render tree update.
+
+ Fix by adding a check for inRenderTreeUpdate() bit too.
+
+ This just fixes a regression. A proper fix would be to gather all resources during style resolution
+ and trigger the loads afterwards.
+
2016-07-07 Babak Shafiei <[email protected]>
Merge r202923.
Modified: branches/safari-602.1.40.1-branch/Source/WebCore/dom/AuthorStyleSheets.cpp (203183 => 203184)
--- branches/safari-602.1.40.1-branch/Source/WebCore/dom/AuthorStyleSheets.cpp 2016-07-13 20:31:37 UTC (rev 203183)
+++ branches/safari-602.1.40.1-branch/Source/WebCore/dom/AuthorStyleSheets.cpp 2016-07-13 20:32:57 UTC (rev 203184)
@@ -291,10 +291,10 @@
bool AuthorStyleSheets::updateActiveStyleSheets(UpdateFlag updateFlag)
{
- if (m_document.inStyleRecalc()) {
- // SVG <use> element may manage to invalidate style selector in the middle of a style recalc.
- // https://bugs.webkit.org/show_bug.cgi?id=54344
- // FIXME: This should be fixed in SVG and the call site replaced by ASSERT(!m_inStyleRecalc).
+ if (m_document.inStyleRecalc() || m_document.inRenderTreeUpdate()) {
+ // Protect against deleting style resolver in the middle of a style resolution.
+ // Crash stacks indicate we can get here when z resource load fails synchronously (for example due to content blocking).
+ // FIXME: These kind of cases should be eliminated and this path replaced by an assert.
m_pendingUpdateType = FullUpdate;
m_document.scheduleForcedStyleRecalc();
return false;
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
