Changeset 246764 in webkit

Timestamp:

Jun 24, 2019 3:22:42 PM (5 years ago)

Author:

Chris Dumez

Message:

Pages using Google's anti-flicker optimization may take ~5 seconds to do initial paint
​https://bugs.webkit.org/show_bug.cgi?id=199173
<rdar://problem/45968770>

Reviewed by Geoffrey Garen.

Source/WebCore:

Pages using Google's anti-flicker optimization [1] take ~5 seconds to do initial paint when
analytics.js load is blocked by a content blocker.

To address the issue, this patch introduces a quirk behind an experimental feature flag that
calls window.dataLayer.hide.end() on the page when the load of ​https://www.google-analytics.com/analytics.js
is blocked by a content blocker. Note that this is more robust than dropping the 'async-hide'
class from document.documentElement since the class name is customizable by the caller.
A message is logged in the console when the quirk causes window.dataLayer.hide.end() to get called
early.

[1] ​https://developers.google.com/optimize/

• contentextensions/ContentExtensionsBackend.cpp:

(WebCore::ContentExtensions::ContentExtensionsBackend::processContentRuleListsForLoad):

• page/Settings.yaml:

Source/WebKit:

Add experimental feature for the quirk.

• Shared/WebPreferences.yaml:

Location:

trunk/Source

Files:

• WebCore/ChangeLog (modified) (1 diff)
• WebCore/contentextensions/ContentExtensionsBackend.cpp (modified) (2 diffs)
• WebCore/page/Settings.yaml (modified) (1 diff)
• WebKit/ChangeLog (modified) (1 diff)
• WebKit/Shared/WebPreferences.yaml (modified) (1 diff)

trunk/Source/WebCore/ChangeLog

@@ +1 @@
+2019-06-24  Chris Dumez  <cdumez@apple.com>
+
+        Pages using Google's anti-flicker optimization may take ~5 seconds to do initial paint
+        https://bugs.webkit.org/show_bug.cgi?id=199173
+        <rdar://problem/45968770>
+
+        Reviewed by Geoffrey Garen.
+
+        Pages using Google's anti-flicker optimization [1] take ~5 seconds to do initial paint when
+        analytics.js load is blocked by a content blocker.
+
+        To address the issue, this patch introduces a quirk behind an experimental feature flag that
+        calls window.dataLayer.hide.end() on the page when the load of https://www.google-analytics.com/analytics.js
+        is blocked by a content blocker. Note that this is more robust than dropping the 'async-hide'
+        class from document.documentElement since the class name is customizable by the caller.
+        A message is logged in the console when the quirk causes window.dataLayer.hide.end() to get called
+        early.
+
+        [1] https://developers.google.com/optimize/
+
+        * contentextensions/ContentExtensionsBackend.cpp:
+        (WebCore::ContentExtensions::ContentExtensionsBackend::processContentRuleListsForLoad):
+        * page/Settings.yaml:
+
 2019-06-24  John Wilander  <wilander@apple.com>
 

trunk/Source/WebCore/contentextensions/ContentExtensionsBackend.cpp

@@ -44 +44 @@
 #include "Page.h"
 #include "ResourceLoadInfo.h"
+#include "ScriptController.h"
+#include "ScriptSourceCode.h"
+#include "Settings.h"
 #include <wtf/URL.h>
 #include "UserContentController.h"
@@ -232 +235 @@
         if (results.summary.blockedLoad)
             currentDocument->addConsoleMessage(MessageSource::ContentBlocker, MessageLevel::Info, makeString("Content blocker prevented frame displaying ", mainDocumentURL.string(), " from loading a resource from ", url.string()));
+        
+            // Quirk for content-blocker interference with Google's anti-flicker optimization (rdar://problem/45968770).
+            // https://developers.google.com/optimize/
+            if (currentDocument->settings().googleAntiFlickerOptimizationQuirkEnabled() && url == "https://www.google-analytics.com/analytics.js"_str) {
+                if (auto* frame = currentDocument->frame())
+                    frame->script().evaluate(ScriptSourceCode { "try { window.dataLayer.hide.end(); console.log('Called window.dataLayer.hide.end() in frame ' + document.URL + ' because the content blocker blocked the load of the https://www.google-analytics.com/analytics.js script'); } catch (e) { }"_s });
+            }
     }
 

trunk/Source/WebCore/page/Settings.yaml

@@ -154 +154 @@
   initial: false
 
+googleAntiFlickerOptimizationQuirkEnabled:
+  initial: true
+
 # This is a quirk we are pro-actively applying to old applications. It changes keyboard event dispatching,
 # making keyIdentifier available on keypress events, making charCode available on keydown/keyup events,

trunk/Source/WebKit/ChangeLog

@@ +1 @@
+2019-06-24  Chris Dumez  <cdumez@apple.com>
+
+        Pages using Google's anti-flicker optimization may take ~5 seconds to do initial paint
+        https://bugs.webkit.org/show_bug.cgi?id=199173
+        <rdar://problem/45968770>
+
+        Reviewed by Geoffrey Garen.
+
+        Add experimental feature for the quirk.
+
+        * Shared/WebPreferences.yaml:
+
 2019-06-24  John Wilander  <wilander@apple.com>
 

trunk/Source/WebKit/Shared/WebPreferences.yaml

@@ -54 +54 @@
    humanReadableName: "Block top-level redirects by third-party iframes"
    humanReadableDescription: "Block top-level redirects by third-party iframes"
+   category: experimental
+
+GoogleAntiFlickerOptimizationQuirkEnabled:
+   type: bool
+   defaultValue: true
+   humanReadableName: "Quirk to prevent delayed initial painting on sites using Google's Anti-Flicker optimization"
+   humanReadableDescription: "Quirk to prevent delayed initial painting on sites using Google's Anti-Flicker optimization"
    category: experimental