Hi all,
I recently noticed that my JS console is filled with error messages about scripts not being able to find various Waze map objects whenever I visit an editor profile page.
First, I’d like to provide a friendly reminder to our generous script authors to please update the userscript header to adjust for this relatively recent change. Second, I’d like to double-check with any ROW editors here about whether the following @includes would work? Do you guys also use the same domain and path for the editor profile page as we do in the USA?
// @include https://editor-beta.waze.com/*editor/*
// @include https://www.waze.com/*editor/*
// @exclude https://www.waze.com/*user/editor/*
Thanks much!
I had noticed the same issue a while ago, but forgot to make a topic about it. So thanks for that 
Important update!
It was just brought to my attention that the path for localized pages is actually something like:
https://www.waze.com/en-GB/user/editor/Olestas
This means to exclude the editor profile page, it should of course be something like this:
@exclude https://www.waze.com/*user/editor/*
ahh…thanks…
ur advise really2 help
For scripts bundled up as Chrome extensions rather than being run via Tampermonkey, am I right to think that Chrome ignore the includes/excludes in the script header and runs the script on any URLs matching the patterns on the “permissions” line of the manifest.json file, because it appears that all of my scripts (and pretty much every other one I’ve got installed too) are running on the editor profile pages despite being blocked from doing so in Firefox?
If so, does any Chrome-savvy scripter have any advice on how to tweak the manifest file to replicate the same exclude definition and tidy things up for Chrome users too?
Thanks,
Chris
No idea about the Chrome-related issue, but the notification I got for your message reminded me to make a post about a change in how cross-origin requests in TamperMonkey are handled: users will get a confirmation message if your script attempts to request information from an outside source if that domain was not listed with a @connect tag.
So basically, all scripts using GM_xmlHttpRequest using resources other than waze.com will need to add one or more @connect tags to prevent this.
Someone at the Greasyfork forums explains it here and the documentation can be found here.
So, I learned about the exclude-matches and exclude-globs options that can be added to the content_scripts section of the manifest file, however these don’t seem to do anything for .js files… As there doesn’t seem to be any other means to inhibit an extension from being started on a given page, I’ve gone down the route of programmatically halting the extension code during its initialisation stage if it detects it’s being run on a user profile URL. Not quite as neat a solution, but preferable to having the code sitting there indefinitely waiting for what it thinks is a normal WME page to finish loading :?