document_start and Preload Top Hit on iOS and macOS

Hi. I'm trying to port my Safari app extension with an injected content script to a Safari web extension on iOS. Content scripts in a macOS Safari app extension always behave as if run_at document_start were specified in the manifest of a Chrome extension. This is crucial to my extension for several reasons: I need to load my JavaScript before any of the page scripts load, and I need to start fetching my site-specific preferences ASAP.

Unfortunately, document_start doesn't work right with Safari web extensions in Safari 14 or Safari 15 on macOS. This is made even worse if Preload Top Hit is enabled in Safari, but document_start is unreliable even with Preload Top Hit disabled.

I've been testing with Safari on the iOS 15 beta, and I've noticed that document_start does seem to work right (unlike Safari Mac) with Preload Top Hit disabled. However, enabling Preload Top Hit still causes it to be unreliable on iOS.

This is all in contrast to Safari app extensions, which just always load at the start, regardless of whether Preload Top Hit is enabled. Though of course Safari app extensions do not exist on iOS.

I'm wondering if Apple's Safari engineers could comment about this. Are there differences in web extension implementation between iOS and macOS? Can I depend on iOS document_start working right with Preload Top Hit disabled? Is there any way that you could fix the Preload Top Hit behavior? (In my testing, document_start seems to work with preload in Google Chrome.)

The developer forums don't see to allow me to attach a zip file (is this possible?) but I've got a sample Xcode project that can demonstrate this behavior.

Post not yet marked as solved Up vote post of jeffjohnson Down vote post of jeffjohnson
1.6k views
  • I have same issue too, do you have any solution fix it?

Add a Comment

Replies

I am also trying to rewrite a Safari App Extension as a WebExtension and finding document_start for content scripts super unreliable on macOS. I'd like to have my background script watch for webNavigation.onBeforeNavigate, then fetch some info, then pass it to a specific content script using tabs.sendMessage to get it ready as soon as possible. Unfortunately, when using tabs.sendMessage, the content script doesn't appear to have been injected by the time I'm using sendMessage- in fact, if I do a new navigation, the background script appears to send the message to the page I'm navigating away from. Pushing back to .onCommitted has the same problem, and even .onDOMContentLoaded is iffy (appears to not work on first page load but does on refresh?) and frankly too late. I'm really not sure how to get this message from my background script to a content script before the page has visibly loaded for the user.

  • Do you have fix this issue or have any solution?

Add a Comment