Fails to preserve URLs as is

[jaekyeom]

It fails to preserve URLs as is. For instance, try suspending and unsuspending http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=PREFIX+foaf%3A+%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0D%0A%0D%0ASELECT+%3Fperson+%3Fname+where+%7B%0D%0A+++%3Fperson+foaf%3Aname+%3Fname+.%0D%0A%7D+LIMIT+100&format=text%2Fhtml&CXML_redir_for_subjs=121&CXML_redir_for_hrefs=&timeout=30000&debug=on&run=+Run+Query+.

Specifications:

• Extension version: 7.0.85
• Browser & version: Chrome 66.0.3359.181
• Operating system & version: macOS Sierra 10.12.6

[fwextensions]

That's probably because of the uri= in the URL. Calling gsUtils.getHashVariable("uri", "blah#uri=http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=PREFIX+foaf%3A+%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0D%0A%0D%0ASELECT+%3Fperson+%3Fname+where+%7B%0D%0A+++%3Fperson+foaf%3Aname+%3Fname+.%0D%0A%7D+LIMIT+100&format=text%2Fhtml&CXML_redir_for_subjs=121&CXML_redir_for_hrefs=&timeout=30000&debug=on&run=+Run+Query+") returns "http://dbpedia.org/sparql?default-graph-". It doesn't look like the code handles a URL with a uri= substring already in it.

[fwextensions]

Interestingly, my QuicKey extension unsuspends that page to the correct URL. It assumes everything from the uri= to the end of the string is the unsuspended URL, which might be a bad assumption if TGS ever changes the hash format.

[jaekyeom]

Let's make the great suspender great again...

@fwextensions Thanks for looking into this issue.
So, I guess it is just a matter of splitting hashStr into only two pieces based on the first occurrence of uri= here.

[fwextensions]

Right. Looks like changing that line to this would fix it:

valuesByKey.uri = hashStr.split('uri=').slice(1).join("");

That joins the split pieces back together, in case the uri gets split into multiple pieces. I changed it in an alpha build and it does seem to work.

But just slicing at the index of "uri=" might be a little more straightforward. Or matching with a regex, since one's used to pull out the # anyway, something like this:

var match = urlStr.match(/^[^#]+#(.*?)&?uri=(.+)$/);

if (!match) {
    return false;
}

hashStr = match[1];
valuesByKey.uri = match[2];

And using a new URLSearchParams() to parse the key/values would probably be a little safer than just splitting on &.

Anyway, it looks like assuming uri is the very last parameter is a safe assumption since it has to be, given that it's not URI-encoded. Otherwise, any params in the URI would get mixed in with TGS's.

[deanoemcke]

Thanks for this.
I'll try to fix this asap.

[deanoemcke]

I have pushed a fix for this (40ce23f)