Redirect of default search engine only works once per tab on iOS

[waynesbrain]

I created a Userscript here to redirect from the default search engine to a non-Apple-approved search engine. The script works fine from a new tab as you can see in the attached video.

However, it does not work on a tab which already has a page loaded. (It can be any page, not just the intended target search engine's page as shown in the video.)

Environment

• iOS 18.2
• iPhone 11
• Default search engine: Ecosia
• Userscript redirects requests meant for Ecosia to Brave.
• Possibly related to If you search in Safari from Spotlight while Safari is closed, the @run-at request script will not work. #683

Screencap

ScreenRecording_01-05-2025.19-22-18_1.MP4

[waynesbrain]

I found one open source extension which performs this function:

• https://apps.apple.com/app/customize-search-engine/id6445840140
  • Source https://github.com/Cizzuk/CSE
  • via https://old.reddit.com/r/ios/comments/1cztie3/safari_custom_search_engine/

I don't know enough about iOS software development to know what it might be doing differently OR if this bug actually exists in that extension. I may test it out later on. I didn't see any issues similar to this one.

However, looking at their code I can see that they do all of the work right in their beginRequest handler whereas the Userscript which I've created is registering a declarativeNetRequest.

Other notes:

• I have seen suggestions to use a specific iOS app for this, either xSearch or Hyperweb. While I don't mind paying for one of those, I wanted to keep the number of extensions that I load to a minimum.
• Searching via the iOS "Look Up" context menu item allows the Userscript to work.
• I'm not sure it's related to If you search in Safari from Spotlight while Safari is closed, the @run-at request script will not work. #683 anymore since Spotlight does exist on iOS and I would assume it works similarly to "Look Up". I haven't tested it since I didn't allow Siri search to access Safari that way.

[ACTCD]

I think this is an upstream issue.

Our implementation is actually quite simple, just registering those DNR rules.

In other words, if the rule has no errors and the registration is successful, the rest is irrelevant to the extension.

Simple debugging I did find many issues with Safari in "Redirect".

For example, similar to your feedback but slightly different, if I click on a link in a page that complies with the DNR rule, it redirects normally.

But if I just type the URL into the new tab's address bar, it either keeps loading or appears to be canceled.

And debugging DNR related issues in Safari is very difficult, there isn't any clear debugging interface there.

[ACTCD]

I don't think it's related to #683, and I'm having a similar issues in macOS Safari.

Since the issue does not appear to be specific to "new tabs", a new issue with a more broadly described description is being tracked.

• declarativeNetRequest type redirect unreliable in Safari #769

And it looks like it's an internal issue in Safari that we can't handle in this project.

I will close this issue, if you have anything to add please continue to comment.

[waynesbrain]

Thanks for your time and for fighting the good fight!

Also, I see now what the open source CSE extension found above does. It waits until the default search engine page is loading and then it redirects to the target unapproved search engine. While this causes a very slight but acceptable delay, I don’t love that the request is being sent out twice.

Furthermore, I assume that I could probably do the same exact thing with a Userscript.

[ACTCD]

I assume that I could probably do the same exact thing with a Userscript.

Yes you can.

But for DNR, there seems to be nothing we can do except submit a bug report to Apple and wait for them to fix it.