@lucka-me

Thank you for investigating this and bringing it to my attention.

Can you provide some urls that are failing?

I won't pretend to be an expert when it comes to CORS, but my understanding is that the policy is set in the headers by the site admins. If a website is denying cross-origin-access via Access-Control-Allow-Origin, shouldn't that be respected?

Personally, I haven't dealt with any failures, yet.

The URLs I pull from is limited. Here are some examples:

• https://www.k21p.com/example.user.js
• https://cdn.frankerfacez.com/script/ffz_injector.user.js
• https://gist.githubusercontent.com/quoid/99af8bad49d9f674d8ea7b10f0d18c44/raw/test.css
• https://greasyfork.org/scripts/369400-local-youtube-downloader/code/Local%20YouTube%20Downloader.user.js
• any url from greasyfork

@quoid

I did another experiments just now, and found that the Access-Control-Allow-Origin is not set in the headers of the failing scripts, so I think the Fetch API will be denied if Access-Control-Allow-Origin is not set or does not include the safari-extension://xxx-xxx-xxx.

Here are some denied examples:

• https://iitc.modos189.ru/build/release/total-conversion-build.user.js
• https://brainstorming.azurewebsites.net/OPR_brainStorming/OPR_brainStroming.user.js

@lucka-me Thank you for the reply

It's been my understanding that having no Access-Control-Allow-Origin policy means no cross origins are allowed. The lack the this policy and the subsequent failure makes sense (if my understanding is correct) and I can verify that those urls fail for me too.

If a website admin has a resource shared online and a restrictive cross origin policy (either explicit or by the lack of a policy), would the method in this PR fail to respect that policy?

I am not sure how I feel about circumventing the header policy.

This was a consideration when I originally, and somewhat reluctantly enabled the feature. It's possible that the current implementation is too restrictive or I expect too much from Access-Control-Allow-Origin and admins. Further, the method I use to get required code is similar to the method in the PR, perhaps the point is moot.

@quoid

I'm not sure why they don't set the Access-Control-Allow-Origin, here is my guess:

I investigated the Tampermonkey in Chrome, and no network activity was logged in the Dev Tools when updating a script in the extension's manager page, so I guess it load scripts from the extension and there won't be any CORS limitation. If other user script managers also do in the same way, some website admins may not notice the Access-Control-Allow-Origin because the managers they use work fine without it being set.

And here is maybe another perspective: The user scripts are downloaded and executed in different places (or origins?): they are downloaded in the manager page, but executed in the @include page. So the cross origin policy should be ignored by the manager...?

As for the @required tag, I used to think they are loaded when injecting the user scripts like await addScriptTagAndLoad(requiredURL) and TIL they're preloaded when add the script...

@lucka-me

I think your implementation is an improvement so I will roll it into a future update, hopefully the next one. I will investigate request cancellations as well.

Thanks for bringing this to my attention, and I really appreciate the PR.

@lucka-me rolled this into v3.1.0 branch. It will be in the next beta build, which will go out shortly. If you want to sign up for beta releases, you can do that here.

Thanks again