Opened on 04/08/2019 at 10:28:01 AM

Closed on 08/29/2019 at 05:43:18 PM

#7447 closed defect (rejected)

Tab loading indicator shown indefinitely when Adblock Plus is installed and enabled

Reported by: greiner Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords: closed-in-favor-of-gitlab
Cc: kzar, sebastian, ukacar, mjethani Blocked By:
Blocking: Platform: Chrome
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by mjethani)

Environment

Ubuntu 18.10
Chromium 73 or Opera 58
Adblock Plus 3.5.1

How to reproduce

  1. Create an empty HTML page and add a <script> tag in its <body> with the below content.
  2. Access HTML page through local web server
  3. Whitelist page
  4. Reload page
window.addEventListener("load", function()
{
  let iframe = document.createElement("iframe");
  document.body.appendChild(iframe);
  
  let doc = iframe.contentWindow.document;
  doc.write("");
});

See also https://www.pixfuture.com/adtests/hb.html

Observed behaviour

Tab's loading indicator keeps spinning regardless of whether page is whitelisted.

Expected behaviour

Tab's loading indicator goes away quickly.

Notes

  • When Adblock Plus is uninstalled / totally disabled the problem no longer happens.
  • We can't reproduce the problem on Firefox 66.0.2.
  • This appears to be a bug in Chrome (see https://crbug.com/951694)

Attachments (0)

Change History (10)

comment:1 Changed on 04/08/2019 at 10:29:55 AM by kzar

  • Cc sebastian added

comment:2 Changed on 04/08/2019 at 10:31:02 AM by greiner

  • Description modified (diff)

comment:3 Changed on 04/08/2019 at 10:54:16 AM by kzar

  • Cc ukacar added
  • Description modified (diff)

comment:4 Changed on 04/08/2019 at 11:05:56 AM by greiner

  • Description modified (diff)
  • Summary changed from Tab loading indicator shown indefinitely when whitelisted to Tab loading indicator shown indefinitely when Adblock Plus is installed and enabled

The example code's behavior was independent of whether Adblock Plus was installed, unlike what we see on the linked page. Therefore I updated the code in the ticket description to match the page's behavior.

comment:5 Changed on 04/10/2019 at 12:03:19 AM by sebastian

  • Cc mjethani added

comment:6 Changed on 04/10/2019 at 10:26:03 PM by mjethani

I'm able to reproduce this with the following sample extension on Google Chrome Canary (Version 75.0.3759.4 (Official Build) canary (64-bit)):

{
  "manifest_version": 2,
  "name": "chrome-postload-bug-example",
  "version": "1",
      
  "content_scripts": [
    { 
      "all_frames": true, 
      "matches": ["<all_urls>"],
      "match_about_blank": true,
      "run_at": "document_end",
      "js": ["content.js"]
    }
  ]
}
// content.js
console.log("content.js");

This appears to be an issue with Chrome. If there's a content script that must run at document_end, with the HTML in the issue report above, the page will continue to appear to load forever. This is the case even if the content script is blank.

comment:7 Changed on 04/10/2019 at 10:38:31 PM by sebastian

Nice find! We should file a Chrome bug. Other than that, I don't see anything we can do about it.

comment:8 Changed on 04/11/2019 at 07:40:21 AM by mjethani

I have reported it now at https://crbug.com/951694

comment:9 Changed on 04/11/2019 at 07:41:39 AM by mjethani

  • Description modified (diff)

comment:10 Changed on 08/29/2019 at 05:43:18 PM by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from new to closed

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.

Add Comment

Modify Ticket

Change Properties
Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
 
Note: See TracTickets for help on using tickets.