Nightly can not parse match pattern

[an-electric-sheep]

the script below fails with the following error: Error: @match could not parse pattern

// ==UserScript==
// @name        match test
// @namespace   https://github.com/an-electric-sheep/
// @version     1
// @match       *://*.twitter.com/*
// @grant       none
// ==/UserScript==

It works on FF stable. I suspect that it would break a lot of scripts soon.

[janekptacijarabaci]

Last good: Firefox 54.0a1 (2017-02-09)
Built from https://hg.mozilla.org/mozilla-central/rev/b772e0f4138540113e91a46c99bb0d14ecc8acca

First bad: Firefox 54.0a1 (2017-02-10)
Built from https://hg.mozilla.org/mozilla-central/rev/25a94c1047e793ef096d8556fa3c26dd72bd37d7

Pushlog
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b772e0f4138540113e91a46c99bb0d14ecc8acca&tochange=25a94c1047e793ef096d8556fa3c26dd72bd37d7

Bug #1337629 is the suspect.

Steps to reproduce:

1. Open Scratchpad
2. Menu: "Environment-Browser"
3. Insert the code:

var url = "http://*.twitter.com/*";
var ioService = Components.classes["@mozilla.org/network/io-service;1"]
    .getService(Components.interfaces.nsIIOService);
alert(ioService.newURI(url, null, null));

4. Run
5. The result:

Firefox 54.0a1 (2017-02-09)

alert: http://*.twitter.com/*

Firefox 54.0a1 (2017-02-10)

Exception: [Exception... "Component returned failure code: 0x804b000a
(NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]"  nsresult: "0x804b000a
(NS_ERROR_MALFORMED_URI)"
location: "JS frame :: Scratchpad/1 :: <TOP_LEVEL> :: line 15"  data: no]

[valenting]

Hi, this looks to me like it is abusing URIs. Is there a specific reason why it's creating a URI using that pattern? How is it matching an actual URI vs a pattern URI.
Understanding this would help in deciding whether to backout bug 1337629 or not.

[an-electric-sheep]

@valenting it's using the URI to safely extract the various URI parts (scheme, host, path) before applying regular expressions to the individual parts. I assume the idea was to avoid implementing a custom URI parser for match patterns.

MatchPattern.jsm

[an-electric-sheep]

Also note that for me this had the effect of silently removing or failing to load an already installed script. This was fairly surprising and I don't know if it would have been able to recover from that, i.e. if the script wasn't just gone until it is reinstalled.

[janekptacijarabaci]

The testing branch:
https://github.com/janekptacijarabaci/greasemonkey/tree/_testBranch_matchPattern

I did not make a pull request yet (it's not well tested)...

[DanaMW]

I had the same issue last night with Firefox developer. GM removed FBP script due to the two @match lines in his script with parsing errors. I removed the 2 lines and was able to load the script from disk to reinstall it.
GM was also missing a disabled script upon restart from the update of FF along with the purity script. The removed disabled one reloaded from clipboard without error. Neither script was removed from the gm_scripts folder thankfully, just wouldnt load. Hope any of this helps, here if you need me.
Parse error on these two;
// @match http://.facebook.com/
// @match https://.facebook.com/

[DanaMW]

Beta seems to be working fine.

[valenting]

Beta hasn't been updated yet. It will be soon.

…

On 17 February 2017 at 04:24, Dana MW Chester ***@***.***> wrote: Beta seems to be working fine. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2480 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYyOVjQCE0xIK_k-M2OecXJ6tXrpr0Vks5rdRL1gaJpZM4L-WHI> .

[arantius]

I think arantius/greasemonkey@9cb9467 fixes this. Confirmation would be nice.

[arantius]

I rewrote that to arantius/greasemonkey@1531f34 and I'm pushing it out to the beta channel now.

[GuardianMajor]

I cannot confirm on the profile mentioned in #2481 because I had no choice but get it functional and had to scratch it and start over, a complete waste of hours.

Not to mention in the process I find, that deleting/removing a script apparently doesn't actually remove/delete it, on the drive in the profile it keeps it all, which makes no sense why it is doing that - since I deleted these scripts for a reason, why are you collecting them?

Explains the errors that arise when a new script has the same name as an old one (deleted but not really gone) you didn't remove and causes issues. This should really be looked into, even though not directly related to issue being addressed here.