Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extension no longer works in Safari 18 #325

Closed
abarkalo opened this issue Sep 17, 2024 · 5 comments
Closed

Extension no longer works in Safari 18 #325

abarkalo opened this issue Sep 17, 2024 · 5 comments

Comments

@abarkalo
Copy link

System

  • OS name: [e.g. Windows, Ubuntu]
  • OS version: [e.g. 10]
  • Browser name: [e.g. Chrome, Firefox]
  • Browser version: [e.g. 60]
  • Extension version: [e.g. 1.0.0]

Bug description

Logs

// REPLACE WITH LOGS
@dessant dessant changed the title doesn't work on Mac OS Sequoia Extension no longer works in Safari 18 Sep 18, 2024
@dessant
Copy link
Owner

dessant commented Sep 18, 2024

Thanks for the bug report, the extension no longer works on iOS 18, iPadOS 18 and macOS 15. Web extensions should work without disruptions in new Safari versions, but Apple has introduced regressions and bugs in the extension API with each new Safari release in the past year. Some of the documented APIs do not behave as expected, or they only work on some devices.

@xeenon, it is becoming untenable to keep our browser extensions working in Safari with the amount of bugs your team is introducing with each release. This time web extension messaging seems to be broken in Safari 18.

I understand that mistakes happen, but when it keeps happening, it can only be attributed to lack of care, and your team's negligence is causing financial loss and grief for others. Your team should see the amount of chargebacks and negative reviews browser extensions have been getting on the App Store since Safari 17.4 was released. The regressions introduced in Safari since that release have been breaking extensions, and this situation seems to be getting worse with each release. We are running out of workarounds to keep our projects working in Safari.

Who is responsible for all this financial loss, reputational damage and wasted time? When you folks push out these buggy releases, do you sometimes think about how you're affecting other people's lives?

@dessant dessant pinned this issue Sep 18, 2024
@xeenon
Copy link

xeenon commented Sep 18, 2024

@dessant We’ve recently resolved the background page issue from 17.4 with a fix in 17.6.1, and I’ve also addressed a messaging regression, which may help with the issues you're seeing once that is released.

I understand how disruptive these bugs have been, and going forward, we’re committed to adding regression tests that run on every WebKit commit to prevent issues like these from reoccurring. We currently have around 500 tests for all extension APIs, and we’re adding more with each change.

If you have any more details on the specific issue you're seeing with your extension, I’d love to take a look. Let’s work together to get things back on track.

@abarkalo
Copy link
Author

when will 17.6.1 be posted in Apple Store?

@dessant
Copy link
Owner

dessant commented Sep 25, 2024

A new version of Search by Image will be released in the next few days that restores compatibility with Safari 18.

Here are the main regressions I have found in Safari 18 in the past week:

Unresponsive background page

Manifest v2 extensions that use non-persistent background pages become unresponsive after 30 seconds on all tested mobile and desktop devices in Safari 18, the background script does not wake up, and the extension does not work until the browser is restarted.

On the developer forum there are several people claiming that on some devices the issue was never resolved in Safari 17.6.1, and that the regression was reintroduced in Safari 18 beta. Developers have submitted plenty of bug reports to Apple in the past 6 months about this issue, but Safari 18 was still released in this state, breaking manifest v2 extensions, again.

Manifest v3 extensions are not spared either, there are claims about service workers becoming unresponsive when a different app is moved to the foreground, and despite what the Safari 18 release notes tell you, the service worker of a manifest v3 extension is still not visible in the Develop menu, so it's difficult to extract logs and debug extensions.

Broken messaging APIs

Extension pages loaded in iframes can no longer connect to the content script of the top-level document with tabs.connect, event handlers registered with runtime.onConnect in the content script are no longer called for a connection initiated this way. This appears to be a different issue from the messaging regression described on the developer forum.

This was the last remaining extension messaging API that still worked in Safari for communicating between these two context types to achieve seamless two-way communication in a secure way. Messages sent from the background script using tabs.sendMessage are still not received by the extension page, so the only way to message the iframe using the extension API is to connect from it to the background page, save the messaging port, and keep the background page alive using various tricks. We have opted to ping the iframe instead from the content script using contentWindow.postMessage and let the extension page know that there is a new message to be fetched from the background page using runtime.sendMessage.

Tab id no longer constant

The id of a tab now changes when a website is redirected to an extension page, or a new tab is set up with an extension page which is then redirected to a public website. This is an intentional change according to an Apple engineer. Safari 18 is the only browser that behaves in this specific way and it breaks basic assumptions about the identity of a tab, but nobody bothered to document the breaking change in the Safari 18 release notes.

This behavior change may cause issues when the tabIds rule condition will be implemented in Safari for session-scoped declarativeNetRequest rules. For example, you may no longer be able to load an extension page in a new tab and set up request handling for the tab using its tabId, to then load a website in the same tab.

Final thoughts

I don't think that the negligent attitude of this team at Apple will change for the better. They don't seem to grasp the harm they have caused to other people, otherwise we would have seen some apologies by now, at least when they talk to individual developers.

When bugs are fixed in a Safari web extension API, they often seem to be fixed in a way that solves the use case in the bug report, but ignores the rest of the API, or how changes affect other parts of the browser.

I also doubt that extension APIs are manually tested by the engineers that approve pull requests, otherwise we wouldn't see all these regressions in almost every release that not only break some obscure use cases, but completely break sample web extensions published by Apple in the developer guide.

The level of instability shown by Safari is unprecedented in the browser extension ecosystem of the past 10 years. Not even Samsung Internet is this unstable, despite their extension API being kept in closed beta for years. Samsung Internet was actually a joy to work with once the initial API differences have been sorted out.

I was hesitant to single people out, but this sentiment of contempt towards a group of people that destroy my work has only grown stronger, especially when I've noticed that this is a pattern of behavior within this team, and that extension developers have been pleading for help on Apple forums after they've invested their money to gain access to this platform, only to be asked if they've tested the latest version, or to be told that the issue is now fixed in the latest Safari release, when it really wasn't.

I believe that the level of what is acceptable has long been surpassed, and it's all too comfortable for these people to hide behind the obscurity that such a large company provides, while our incomes are at stake. I have lost a bunch of money to chargebacks on the App Store from the moment these broken Safari versions have started being released this spring, and the chargebacks coupled with the negative reviews also had a negative effect on the search result rankings of my extensions on the App Store. I can imagine what some of the businesses on the App Store have been going through in the past 6 months, and they should brace for an even worse end of year thanks to Safari 18.

@dessant
Copy link
Owner

dessant commented Sep 29, 2024

Search by Image 8.0.1 has been published, the latest release restores compatibility with Safari 18. You can download the update now if you go to the App Store page of Search by Image and tap on the Update button.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants