Keep track of new pages in Safari without using canLoad

[kzar]

Background

The Safari extension API provides ​several events for keeping track of when windows and tabs are opened, loading, finished loading, closed etc.

Listening to these events from the extension's background page, specifically beforeNavigate, allows us to see when a page has started loading. This is useful because Adblock Plus needs to keep track of all the open pages.

In Safari pages are also "pre-rendered" when the user starts typing a website URL into the address bar. This way the page is rendered for them more responsively as the work was started before they even finished typing. This means that several beforeNavigate events could fire as the user types a URL, even if the user changes his mind and never actually navigates to a new page.

Previous to Safari 7 the beforeNavigate events that were fired during prerendering would be given a new SafariBrowserTab event.target. As of Safari 7 however the SafariBrowserTab of the existing visible page is reused.

This ​made it difficult for us to use the beforeNavigate event to keep track of open pages. (How do you know if the new URL for the tab will ever replace the existing one?) and so ​we eventually used a different approach for keeping track of the open pages.

Instead of listening for the beforeNavigate event we started sending messages sychronously from each new page's content script to tell the background page that a new page had started loading. This has worked pretty well ever since, but with ​the recent deprecation of the only way to send messages synchronously canLoad we need to reconsider.

(Worst still, ​apparently if the new content blocker API is used canLoad will be disabled!)

What to change

Stop using canLoad to keep track of pages in Safari. Investigate using the beforeNavigate and other events to do so, taking care to consider prerendered pages.

Hints for testers

The changes we made here fundamentally affect how Adblock Plus for Safari keeps track of tabs, pages and frames. As far as possible we need to thoroughly test that nothing has broken in any supported version of Safari.

Some possible problems:

• The options page might look all broken, if the backgroundProxy fails to communicate.
• The options page might look OK but then when adding subscriptions or filters nothing appears to happen. (The options page never received the message back to say the subscription got added.)
• The icon animations could break, especially when switching between tabs and windows and opening new pages.
• Ad blocking itself could break, including the counter of blocked adverts.
• The differentiation between prerendered pages (Safari "prerenders" pages in the background as you start typing a URL, even before you hit enter!) and the currently visible page could get confused. So for example if you start typign a new URL maybe the page will be prerendered and the block counter for the current page gets increased by mistake.
• The "block element" feature might stop behaving properly. (Important to test edge cases, like blocking elements inside frames and checking that the Adblock Plus popup correctly displays the "Cancel" button when opened while the dialog is still open.)
• Lots of other things I'm probably missing!

[abpbot]

A commit referencing this issue has landed:
​https://hg.adblockplus.org/adblockpluschrome/rev/792135b6c4eb

[Ross]

Safari builds look to be working as expected (in general) across all Safari versions. There are some specific issues such as #3877 and #3915.

ABP 1.11.0.1593 / ABP 1.11.0.1592
Safari 6.0 / OS X 10.8
Safari 7.1.8 / OS X 10.9.5
Safari 8.0.6 / OS X 10.10.3
Safari 9.1 / OS X 10.11