webRequest & webNavigation API behaviour issues

Ignoring the fact that we still need to use MV2 in order to use webRequest in Safari (with the persistent: true flag set, a requirement not needed in FireFox MV2), there are certain requests that never have a request side event raised for them, but do have their associated response side events raised.

I've noticed this specifically for cases where the request contains a raw or binary request body.

A simple way to reproduce this, is to log into Twitter which uses binary payloads. You will notice if you add listeners to any of onBeforeSendHeaders,onSendHeaders, or onBeforeRequest that you get zero events for any request that would be the login request. Now if you also add a listener to onResponseStarted however, you will get a response event for the login request (including the requestId of the request that never had a request side event raised).

Please could Safari just do what FireFox and Chromium do and have the request body be stored in either requestBody.formBody (if the payload was of a form-like mime type), or if not just have the raw data stored in requestBody.raw.

At this point, I'd even take the requestBody being a parsed form object OR a binary array, but having the request event just swallowed by the browser, I'm assuming due to it being unable to parse it to an object, is poor.

The webRequest API for Safari is completely unaligned to Chromium based browsers and FireFox. In Chromium webRequest works just fine with MV3 service workers, and in FireFox it works just fine with non-persistent background scripts.

As for webNavigation, the APIs behaviour seems unaligned too. I mean, entering a new URL into the address bar of the current tab doesn't even raise a navigation event. This seems like one of the most basic navigation related actions that an extension would want to know about. :exploding-head:

These are great pieces of feedback. Can you please file them on https://feedbackassistant.apple.com? I think there are three distinct pieces of feedback here.

  1. webRequest not working with non-persistent background pages
  2. raw/binary support for webRequest request events
  3. webNavigation events not being fired for navigation

Re: #3, what version of Safari are you testing this on? Safari 17 had a change where your extension is now required to have permission to access the URL that the webNavigation event would be generated for. A sample extension reproducing this would be ideal for this bug report.

Lastly, when you are reproducing #3, do you have "Preload Top Hit in Background" turned on in Safari Search Settings?

These are great pieces of feedback. Can you please file them on https://feedbackassistant.apple.com? I think there are three distinct pieces of feedback here.

  1. webRequest not working with non-persistent background pages
  2. raw/binary support for webRequest request events
  3. webNavigation events not being fired for navigation

Re: #3, what version of Safari are you testing this on? Safari 17 had a change where your extension is now required to have permission to access the URL that the webNavigation event would be generated for. A sample extension reproducing this would be ideal for this bug report.

Lastly, when you are reproducing #3, do you have "Preload Top Hit in Background" turned on in Safari Search Settings?

  1. webNavigation events not being fired for navigation

Checked on Safari Version 17.2.1 (19617.1.17.11.12) and "Preload Top Hit in Background" turned on and off

webNavigation events does not work for new URL pages and for new pages from "Start Page" as well

webRequest & webNavigation API behaviour issues
 
 
Q