Safari web extension [WIP]

[cheif]

Description

This creates a Safari web extension-wrapper around the current code, with the idea of being able to run Vimium natively in Safari (See #3610). I've basically just taken the steps from other users in that issue and wrapped it up in a PR for now, with the hope that we can collaborate on this here.

Status

Right now this is runnable, but not everything is working, as in #3610 (comment) some commands doesn't work (see below).

How to test

1. Get the branch for this PR.
2. Open Vimium/Vimium.xcodeproj in XCode (You'll need XCode, I'm running XCode 12.5)
3. Run the project, then you'll need to make sure that you have enabled running unsigned extensions in safari: https://developer.apple.com/documentation/safariservices/safari_web_extensions/running_your_safari_web_extension
4. On further launches you'll just need to build in XCode, and it should reload properly.
5. For debugging, open Develop>Web Extension Background Pages>Vimium in Safari.

Things to test

• Test through all known features, to make sure that they work as expected.
• Test on iPad/iOS

Known bugs:

• Commands requiring the clipboard (yy, visual mode copy, P, etc.)
• B doesn't have access to bookmarks (bookmarks-API isn't supported in safari)
• F loads a URL in the currently selected tab rather than a new one
• X doesn't seem to restore the last closed tab (sessions-API isn't supported in safari)

Questions/considerations

• Right now this PR adds a Vimium folder with an .xcproj, this is what was created by running xcrun safari-web-extension-converter, but might not be the desired folder structure
• Some code in main.js is running conditionally on whether or not we're on chrome, is this safe, or should we find a way to trigger it in similar conditions in safari?
• The manifest.json was changed to have a broader matches for one .css file, is this safe or do we need to do something smarter here?
• In feature request: Safari support on macOS Big Sur with new Web Extension API #3610 there were some discussions on using other artwork, since the current logo has the Chrome logo in the background.

[cheif]

Looking into the API availability a bit, and it seems like the sessions API isn't available in safari (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs#sessions), which is the reason for X not working.

Edit, dito for bookmarks (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs#bookmarks) which I guess is the reason for B not working.

[gdh1995]

content_scripts/file_urls.css is only to make some text like file names selectable on file:///*, so if Safari has no such problem then it can be removed when packing as a Safari extension.

[gdh1995]

BTW, if I only write extensions and always use them by loading unsigned extensions, do I need an Apple Developer account (which means US $99 per year) yet?

[cheif]

content_scripts/file_urls.css is only to make some text like file names selectable on file:///*, so if Safari has no such problem then it can be removed when packing as a Safari extension.

Hmm, I tried just creating a local test.html and opening it, but it seems like the safari extension can't run at all on file:// url:s, so it's probably safe to strip it for safari.

[cheif]

BTW, if I only write extensions and always use them by loading unsigned extensions, do I need an Apple Developer account (which means US $99 per year) yet?

Yeah, I think that should be possible, although I guess the "load unsigned" stuff might toggle off after restarting etc. as well, haven't looked into it much myself though.

[cheif]

I've managed to fix the F issue by directly communicating with the bg-page (instead of simulating a CMD-click), this seems to be done in a lot of other cases, so I think the change should be pretty safe.

[gdh1995]

No. Your change will prevent pages using JavaScript listeners and doing whatever they want. Please consider about update lib/dom_utils.js#simulateClick to make Vimium work on Safari in a similar way as on Firefox.

[cheif]

No. Your change will prevent pages using JavaScript listeners and doing whatever they want. Please consider about update lib/dom_utils.js#simulateClick to make Vimium work on Safari in a similar way as on Firefox.

Hmm, I think I understand the problem, although I'm not able to get it working the way I thought.
The MouseEvent that's created/dispatched in simulateMouseEvent is handled by safari, but for some reason the metaKey is ignored. So if I just change simulateClick to have something like Utils.isFirefox() || Utils.isSafari() then a link will be opened in both the current tab + a new tab.

I guess we could just tailor the behaviour specifically for F on Safari, or do you see a better way of doing it? (that could be done with something like:

if Utils.isSafari() && modifiers.metaKey { 
  simulateClickDefaultAction(element, modifiers)
}

[cheif]

I've also looked into the yanking/pasting a bit, and I managed to get the yanking working by using the Clipboard API, although I can't get pasting working through that. Perhaps because it needs to happen in a user-interaction chain, some more info here.

Re: the clipboard-API, would it be safe to switch to using that, instead of using the execCommand stuff currently in use?

[gdh1995]

Well, an ideal way is to hook the process of event propagation, and append event.preventDefault() if only no page code calls it.

But the code will be too complicated ... Seems we have to skip normal event dispatching directly.

[gdh1995]

I'm not sure. I suggest we only call navigator.clipboard on Safari, since it has too strict limits.

[gdh1995]

As far as I know, there will not exist any reliable method to read or paste from an extension, in Manifest V3 (https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/), which is very annoying, but it seems nothing can be done. navigator.clipboard adds a much stricter limits for such shortcut kinds of extensions.

[abnerf]

@cheif hey, thanks for the work! I just managed to build and install your branch locally here. Honestly, it works just fine!
Although I understand that some people will miss those features you listed above that are not working, I don't think they are a blocker to get a first release of this work out (in case everyone agrees this is a good tech solution).

The most pressing part now seems to be how to properly release a first version considering that annual fee that was mentioned above.

[cooperpellaton]

If GitHub sponsors/some other contribution method is enabled I'll gladly donate the amount for the Apple developer account registration.

[philc]

I'm happy to cover the annual fee. I just haven't gotten around to reviewing this and trying this out. I will once I get some time. Thank you @cheif for all of the great work thus far.

…

On Wed, Aug 25, 2021 at 10:57 AM Cooper Pellaton ***@***.***> wrote: If GitHub sponsors/some other contribution method is enabled I'll gladly donate the amount for the Apple developer account registration. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3885 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACDFVYLXWZXZBZBHV654DT6UVJBANCNFSM5CB2LYAQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[abnerf]

I believe I found a couple problems this morning which I am not sure if it is happening only on my side.

1. Shift+F says it will open on a new tab, but always loads in the same/current tab
2. On a Google's result page, I used F to navigate to a link and it worked, I hit back and tried again. It only showed "Collecting hints" but never actually showed the hints. I had to close the tab to get it back working.

[cheif]

I believe I found a couple problems this morning which I am not sure if it is happening only on my side.

1. Shift+F says it will open on a new tab, but always loads in the same/current tab
2. On a Google's result page, I used F to navigate to a link and it worked, I hit back and tried again. It only showed "Collecting hints" but never actually showed the hints. I had to close the tab to get it back working.

1. Is a "known" issue in this PR, that's probably solvable, although I'm not sure which way to solve it is preferable, I'd appreciate some help/directions on how to solve this.
2. Interesting, sounds like it might have crashed maybe, can you make this happen again, and if it happens check for logs, both in Develop>Show Web Inspector and Develop>Web Extension Background Pages>Vimium, this should give some clues into what's happening.

[abnerf]

I believe I found a couple problems this morning which I am not sure if it is happening only on my side.

1. Shift+F says it will open on a new tab, but always loads in the same/current tab
2. On a Google's result page, I used F to navigate to a link and it worked, I hit back and tried again. It only showed "Collecting hints" but never actually showed the hints. I had to close the tab to get it back working.

1. Is a "known" issue in this PR, that's probably solvable, although I'm not sure which way to solve it is preferable, I'd appreciate some help/directions on how to solve this.
2. Interesting, sounds like it might have crashed maybe, can you make this happen again, and if it happens check for logs, both in Develop>Show Web Inspector and Develop>Web Extension Background Pages>Vimium, this should give some clues into what's happening.

I was able to reproduce the problem a few times with both inspectors open, but they did not show anything useful there. By reloading the page everything goes back to normal. Sorry, couldn't provide more info.

[SamirHafez]

Has anything changed with regards to Web Extensions on Safari this past year?
IMO, there is still good appetite for having full fledged Vimium on Safari