Title: [266132] branches/safari-610.2.2-branch/Source/WebKit
- Revision
- 266132
- Author
- [email protected]
- Date
- 2020-08-25 10:45:17 -0700 (Tue, 25 Aug 2020)
Log Message
Cherry-pick r266099. rdar://problem/67742560
CrashTracer: com.apple.WebKit.WebContent at com.apple.WebKit: WebKit::PDFPlugin::createScrollbar
<rdar://problem/67473335> and https://bugs.webkit.org/show_bug.cgi?id=215787
Reviewed by Tim Horton.
To quote Tim from r264945:
No new tests; timing is such that I can't reproduce without inserting
intentional delays into the main thread hops, which is further than
I'm willing to go for a test.
This is a speculative fix due to the aforementioned reproducibility issue.
* WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::receivedNonLinearizedPDFSentinel): Check on the main thread whenever this is called,
instead of when deciding to dispatch to the main thread.
(WebKit::PDFPlugin::threadEntry): We can't do this check on the background thread when considering the dispatch
to the main thread, as the flag might've changed by then. Let's *just* check it on the main thread.
(WebKit::PDFPlugin::adoptBackgroundThreadDocument): We can't do the check on the background thread when
(WebKit::PDFPlugin::updateScrollbars): This is where the crash itself is. All of the Obj-C code in here is
safe to do after destroy(), up until the very end when we get into pluginView() derefencing.
So it seems prudent to add another check here.
(WebKit::PDFPlugin::documentDataDidFinishLoading): In addition to receivedNonLinearizedPDFSentinel and
adoptBackgroundThreadDocument, this is the final of the (3) calls that end up calling installPDFDocument,
so for added coverage it seems like a prudent place to add the check.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@266099 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Modified Paths
Diff
Modified: branches/safari-610.2.2-branch/Source/WebKit/ChangeLog (266131 => 266132)
--- branches/safari-610.2.2-branch/Source/WebKit/ChangeLog 2020-08-25 17:45:13 UTC (rev 266131)
+++ branches/safari-610.2.2-branch/Source/WebKit/ChangeLog 2020-08-25 17:45:17 UTC (rev 266132)
@@ -1,3 +1,62 @@
+2020-08-25 Alan Coon <[email protected]>
+
+ Cherry-pick r266099. rdar://problem/67742560
+
+ CrashTracer: com.apple.WebKit.WebContent at com.apple.WebKit: WebKit::PDFPlugin::createScrollbar
+ <rdar://problem/67473335> and https://bugs.webkit.org/show_bug.cgi?id=215787
+
+ Reviewed by Tim Horton.
+
+ To quote Tim from r264945:
+ No new tests; timing is such that I can't reproduce without inserting
+ intentional delays into the main thread hops, which is further than
+ I'm willing to go for a test.
+
+ This is a speculative fix due to the aforementioned reproducibility issue.
+
+ * WebProcess/Plugins/PDF/PDFPlugin.mm:
+ (WebKit::PDFPlugin::receivedNonLinearizedPDFSentinel): Check on the main thread whenever this is called,
+ instead of when deciding to dispatch to the main thread.
+ (WebKit::PDFPlugin::threadEntry): We can't do this check on the background thread when considering the dispatch
+ to the main thread, as the flag might've changed by then. Let's *just* check it on the main thread.
+ (WebKit::PDFPlugin::adoptBackgroundThreadDocument): We can't do the check on the background thread when
+ (WebKit::PDFPlugin::updateScrollbars): This is where the crash itself is. All of the Obj-C code in here is
+ safe to do after destroy(), up until the very end when we get into pluginView() derefencing.
+ So it seems prudent to add another check here.
+ (WebKit::PDFPlugin::documentDataDidFinishLoading): In addition to receivedNonLinearizedPDFSentinel and
+ adoptBackgroundThreadDocument, this is the final of the (3) calls that end up calling installPDFDocument,
+ so for added coverage it seems like a prudent place to add the check.
+
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@266099 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2020-08-24 Brady Eidson <[email protected]>
+
+ CrashTracer: com.apple.WebKit.WebContent at com.apple.WebKit: WebKit::PDFPlugin::createScrollbar
+ <rdar://problem/67473335> and https://bugs.webkit.org/show_bug.cgi?id=215787
+
+ Reviewed by Tim Horton.
+
+ To quote Tim from r264945:
+ No new tests; timing is such that I can't reproduce without inserting
+ intentional delays into the main thread hops, which is further than
+ I'm willing to go for a test.
+
+ This is a speculative fix due to the aforementioned reproducibility issue.
+
+ * WebProcess/Plugins/PDF/PDFPlugin.mm:
+ (WebKit::PDFPlugin::receivedNonLinearizedPDFSentinel): Check on the main thread whenever this is called,
+ instead of when deciding to dispatch to the main thread.
+ (WebKit::PDFPlugin::threadEntry): We can't do this check on the background thread when considering the dispatch
+ to the main thread, as the flag might've changed by then. Let's *just* check it on the main thread.
+ (WebKit::PDFPlugin::adoptBackgroundThreadDocument): We can't do the check on the background thread when
+ (WebKit::PDFPlugin::updateScrollbars): This is where the crash itself is. All of the Obj-C code in here is
+ safe to do after destroy(), up until the very end when we get into pluginView() derefencing.
+ So it seems prudent to add another check here.
+ (WebKit::PDFPlugin::documentDataDidFinishLoading): In addition to receivedNonLinearizedPDFSentinel and
+ adoptBackgroundThreadDocument, this is the final of the (3) calls that end up calling installPDFDocument,
+ so for added coverage it seems like a prudent place to add the check.
+
2020-08-19 Alan Coon <[email protected]>
Cherry-pick r265792. rdar://problem/67420555
Modified: branches/safari-610.2.2-branch/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm (266131 => 266132)
--- branches/safari-610.2.2-branch/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm 2020-08-25 17:45:13 UTC (rev 266131)
+++ branches/safari-610.2.2-branch/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm 2020-08-25 17:45:17 UTC (rev 266132)
@@ -705,13 +705,14 @@
{
m_incrementalPDFLoadingEnabled = false;
+ if (m_hasBeenDestroyed)
+ return;
+
if (!isMainThread()) {
#if !LOG_DISABLED
pdfLog("Disabling incremental PDF loading on background thread");
#endif
callOnMainThread([this, protectedThis = makeRef(*this)] {
- if (m_hasBeenDestroyed)
- return;
receivedNonLinearizedPDFSentinel();
});
return;
@@ -887,8 +888,6 @@
[m_backgroundThreadDocument preloadDataOfPagesInRange:NSMakeRange(0, 1) onQueue:firstPageQueue->dispatchQueue() completion:[&firstPageSemaphore, this] (NSIndexSet *) mutable {
if (m_incrementalPDFLoadingEnabled) {
callOnMainThread([this] {
- if (m_hasBeenDestroyed)
- return;
adoptBackgroundThreadDocument();
});
} else
@@ -983,6 +982,9 @@
void PDFPlugin::adoptBackgroundThreadDocument()
{
+ if (m_hasBeenDestroyed)
+ return;
+
ASSERT(!m_pdfDocument);
ASSERT(m_backgroundThreadDocument);
ASSERT(isMainThread());
@@ -1216,6 +1218,9 @@
void PDFPlugin::updateScrollbars()
{
+ if (m_hasBeenDestroyed)
+ return;
+
bool hadScrollbars = m_horizontalScrollbar || m_verticalScrollbar;
if (m_horizontalScrollbar) {
@@ -1524,6 +1529,9 @@
void PDFPlugin::documentDataDidFinishLoading()
{
+ if (m_hasBeenDestroyed)
+ return;
+
addArchiveResource();
m_documentFinishedLoading = true;
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
