I've just tested to load files like https://.../foo.user.js?version=1&s=0, and the install dialog appeared...

Edit: Strange, tested that again, this time nothing happened. Maybe my browser stripped it away.
See @arantius' answer, you can forget about what I wrote...

It's always been this way. See #2130 and #1683 .

This is caused by the Match Pattern Array in user-script-detect.run.js, which is used when adding the webRequest.onHeadersReceived listener, containing only '*://*/*.user.js'. Contrary to the Match Pattern calling the last portion of the Match Pattern the "path"¹, it actually matches against the URL path and URL query string.

This can be resolved by changing:

{'urls': ['*://*/*.user.js'], 'types': ['main_frame']},

to

{'urls': ['*://*/*.user.js', '*://*/*.user.js?*'], 'types': ['main_frame']},

in src/bg/user-script-detect.run.js. Adding the second entry in the Match Pattern Array matches all URLs where the URL path ends in .user.js, but which have a query string.

1. The Match Pattern documentation calling that portion "path" is, unfortunately, confusing (legacy from Chrome documentation). I've updated the Match Pattern page to be more explicit about what is being matched against.

I encountered this when attempting to load a userscript from a GitHub private repository. While the original URL for the userscript contains no query string, GitHub redirects that URL to one that contains a ?token=. This prevents Greasemonkey from installing from GitHub private repositories.

TM, on the other hand, has no trouble doing so. I did not test to see if TM stumbles over there being a query string when the original URL contains one. For the GitHub private repository URLs, TM detects the first webRequest, prior to the redirect. Thus, its detection of userscript URLs doesn't see a URL with query string.

@makyen Just to be sure, are you sure the question mark isn't a special sign like the asterisk, in whatever method is used here for wildcards?

Secondly, what if there are two question marks in a url? In a normal url, I believe the second one will be part of the query string and is taken like a literal question mark.

@Cerberus-tm Yes, the ? has no special meaning in Match Patterns. Unlike regexes or globs, the only special character is *, and the special string <all_urls>.

HTML5 requires an additional ? to be percent encoded.¹ If, for some reason, it wasn't, then in the specific case that you describe, it would still match. The second * would match the subsequent ?. It matches anything. The added Match Pattern is only looking for a ? immediately following the .user.js, which, in the vast majority of cases, will indicate that there is a URL path that ends with .user.js followed by a query string. However, if for some reason the additional ? was not percent-encoded, then there would be the possibility of erroneous matches, but that would require .user.js? to be somewhere in the query string.

Unfortunately, Match Patterns are quite limited. There are URLs which are already misidentified based on the the existing first Match Pattern. In fact, the workaround for getting GM to recognize a script that it currently does not is to add an additional fake parameter to the query string so the URL ends with .user.js.

The only way to be sure would be to add additional logic to test the URL in the webRequest.onHeadersReceived to see if it really matches the desired pattern. In fact, that's what's intended. The Match Patterns are intended to be simple matches that are a first round of elimination for what's being watched. The goal, from the browser's POV, is to spend as little time on an extension's match as possible when it does not match. This is primarily done by making the first test for matching quite simple, in order to eliminate the significant majority of URLs from further consideration.

1. I'd need to re-read the spec to verify where it's all restricted. The specific HTML5 spec. section referenced by the linked Wikipedia page is for <form> submission. So, it's likely to be percent-encoded in the significant majority of cases, but I'm unsure if all cases are covered. I don't think that they are.

@makyen Ah, that all makes sense.
Being able to install scripts from additional (trustworthy) sites would be nice.

An additional use case is installing GreaseMonkey scripts from private Github repos. In private repos, when viewing the 'Raw' of a file, Github appends a ?token=xxx to the URL, so GreaseMonkey doesn't pick up on it.

Example:

https://raw.githubusercontent.com/usenrame/reponame/master/myscript.user.js?token=ABC123

It would be great if this PR could be reviewed as it would allow querystring params.

Since a few weeks, I have a similar issue with Firefox, when I open my HTML overview page for installation of Greasemonkey scripts. Firefox adds a useless ? as an empty query, which prevents the link to be installed.

My silly page works like this (simplified):

function addEntry(table, id) {
    var id = 'SCRIPTBASE';
    var filename = id + '.user.js';
    var source = '<a href="https://github.com/Eselce/REPOSITORY/blob/master/' + filename + '">' + filename + '</a>';
    var install = '<form method="GET" action="./' + filename + '" target="_blank" rel="noopener noreferrer">' +
                        '<input type="submit" value="Install" /></form>';

    // now putting source and install into several columns of the table
    var tr = document.createElement('tr');
    var td = document.createElement('td');
    td.innerHTML = source;
    tr.appendChild(td);
    td = document.createElement('td');
    td.innerHTML = install;
    tr.appendChild(td);
    table.appendChild(tr);
}

This worked for a long time. Now there's a useless ? at the end of the installation link (not produced by my code).

I could complain that it's a Firefox bug/feature, but I would like to recognize links with queries by Greasemonkey as provided in the Pull Request #3026!

Forms are not links. You're asking for that behavior. If you want a link, use a link (an A tag).

Thank you for the answer, you are right, forms are not exactly links, only the action is.
(This may explain, why Firefox changed its behaviour to sth. similar to Chrome, Opera or Edge.)
A form was an easy possibility to create an Install button, submitting with no parameters.
(Sample overview page is https://eselce.github.io/OS2.scripts/)

I hate to say it, but Tampermonkey and Violentmonkey acknowledge this.
I don't want to lose even more users to other script managers.

Two of the most annoying obstacles for everyday users are now occurring only with Greasemonkey:

• The source code is shown to them without installation. They need to delete the ? in the URL input line.
• They have to open pages in new windows because of the Execute in frames bug Execute in frames #2574 .

This is so sad, I would like them to use Greasemonkey, but how can I recommend that, if they get problems?

This will allow users to host their script on more sites e.g. dropbox that generate links containing query.