Doesn't work at all anymore on Mojave

[julian-weinert]

I don't like these kinds of issue reports, but I don't know what else to say.
Just a few minutes ago I installed the last update (from 5 days ago) and the script injection completely stopped working.

I couldn't get any logs on any page. Please let me know if I can somehow gather more helpful information.

System Information:

macOS version: 10.14.6 (18G8022)
Userscripts version: 3.2.0
Safari version: 4.0.3 (14610.4.3.1.7)

[quoid]

@julian-weinert

I don't like these kinds of issue reports, but I don't know what else to say.

If you could provide more detail on what isn't working, that would be helpful. Is it the UI? Script injection?

Edit: I see now you mentioned script injection.

You mentioned something about logs, so I imagine it is script injection, but I am just guessing.

If it is script injection, it helps to get an example of a real userscript that does not work for you. Most of the time I can quickly figure out what is going wrong just by seeing that.

[quoid]

@julian-weinert

In version 3.2 the way @match works changed, that could have something to do with your issue.

[julian-weinert]

Oh, thanks for the quick reply. Following your comment I tried it using // @include *://*/* in the header and console.log('HELLO'); as test in the first line.

Doesn't come through. Still not 100% sure if I got it right, but I do think so

[quoid]

@julian-weinert can you link the entire userscript and tell me what url you are trying on? that match pattern seems valid to me.

here's a simple test script:

// ==UserScript==
// @name        TestScript
// @description This is your new file, start writing code
// @match       *://*/*
// ==/UserScript==

console.log("This is a test script");

[julian-weinert]

Good lord am I stupid. During my test I disabled the script and couldn't see my changes actually "worked"
Now I'm getting the total wildcard to work (as in your test script, which works as well), but my other matches still don't work.

I'm trying to run against google images and YouTube. The images one comes from here https://gist.githubusercontent.com/bijij/58cc8cfc859331e4cf80210528a7b255/raw/viewimage.user.js but after you pointed me to the matching I see that it won't work. This is my attempt for now

// @include         *://*google.*/search*tbm=isch*
// @include         *://*google.*/imgres*

The YT one should match any youtube URL and can be found here https://gist.github.com/julian-weinert/425fa15d7117785e84cad6fbf8df460c

[julian-weinert]

Also completely ignoring the host does not work properly: *://*/search*tbm=isch*

[quoid]

The YT one should match any youtube URL and can be found here https://gist.github.com/julian-weinert/425fa15d7117785e84cad6fbf8df460c

Issues:

• *://*.youtube.*

  • wildcards can't be used (currently) on tlds (com, net, etc..) as per the docs, specifically note the part that says If '*' is in the host, it must be the first character
  • a path must be included
  • Fix: *://*.youtube.com/*

• *://*.youtu.be*

  • a path must be included
  • this pattern would have been valid pre version 3.2!
  • Fix: *://*.youtu.be/*

[quoid]

Also note, that the author of the google script is using @include which for this extension is a fallback to @match. @include has a slightly different syntax and not currently supported.

[quoid]

@julian-weinert the google images one is harder to work around because matching only happens on the protocol, host and path, not the full url (which is utilized in the userscript). To be clear, in a google image search the path is only /search; the url parameters are not part of the path so checking against them is not possible with @match.

There's ways around this in the actual code, but it will take some work to fork it and update the code for an additional check.

If @include is implemented into the extension it will open more possibilities, but it is not currently supported and might be a little bit before it is supported.

[julian-weinert]

Oh, that's pretty sad, since it did support that in the past.

Problem is that google as well as many other pages is not US-exclusive... Meaning I will need to add a @match statement for any TLD in existence, since I don't know what google owns and what not.
Google is the problem that the image search URL does not differ from any other search.

Meaning all this pattern matching is now pretty useless and I will need to include the script in any page and code the rest up in JavaScript.

May I ask out of interest why you chose to remove so much functionality? Feels like a big step backwards to me

[julian-weinert]

Oh and big thanks for your prompt explanations!

[quoid]

@julian-weinert

I'll try to implement @include properly this week for more versatility with match patterns.

That'll allow for wildcard matching against full urls.

Sign up for the beta if you'd like to get the build early.

[quoid]

@julian-weinert You can read more about the rationale for the change here #107