Hi everyone, I’ve scripted up an add-on that automatically (or manually) resets your layers in WME to your preferred setting. The layers include ones that are not typically saved by WME (though not yet residential places nor closed URs & MPs… but soon).
As of version 0.2 (Beta), the feature list includes:
Saving of your preferred layers setting
Automatic or manual (magic wand icon) reset of layers
Ignore switching off of the layer if the PL links to a UR, MP, Place, Camera, or Junction Box.
A (presently buggy) toggler (eye icon) to review layers that were removed from a permalink
A WME Beta/Production Editor toggler in the left sidepanel that forces all permalinks to be loaded in Beta or Prod.
Removes any language specifications in a permalink
Darkens the Cities layer polygon so they can be seen against the satellite image
Makes the Area Managers polygon more see-through, which is necessary to be able to see the map underneath in areas with several AMs
Adjusts the Roads layer to be slightly translucent so that the actual road in the satellite image underneath can be seen without needing to toggle on/off.
As this is very much still in beta, bug reports and suggestions are welcomed and appreciated!
Without even looking (yet) I can tell this is going to be an immense help.
If I’m not mistaken, I think it’s important to note that this intercepts PLs as they’re initially loading: this differs from the other recent Layer reset, which completely reloads a tab after it’s already opened in WME. RIght?
One suggested option – Keep UR layer: If a &mapUpdateRequest is found in the PL, it would automagically keep, or turn, the UR layer on, regardless of the favored / current layers.
Oh! I totally forgot to mention that… Yes, that feature has been included in this version as well. Thanks for reminding me! The script will ignore switching off of that layer if it is part of the PL. Currently this is true for the following: URs, MPs, Places, Cameras, Big Junctions.
Re the difference among existing methods— As far as I know, there are currently two main scripts available: (1) Iainhouse’s bookmarklet and (2) Vaindil’s WME Layers Link Remover.
As advertised, the bookmarklet is useful for whenever you need to reset your layers to your preferred setting, regardless of whether you had changed the layers yourself or you had clicked a PL infected by &layers=. However, the bookmarklet cannot intercept the URL and it relies on how quickly the user can manually activate the bookmarklet.
Within the last month or couple months, Vaindil has updated his layers remover script so that it is now 100% successful at catching PLs with layers and redirecting (technically “replace()”) the URL with one without &layers=. This is achieved upon startup of loading the main page contents (with onload()) and then stopping its process before the map loads. If he wanted to optimize his script even more, he could use a DOMContentLoaded event listener instead, which will start execution of the script even sooner. However, with a fast connection and modern computer, this difference is practically imperceptible. I would recommend his script over mine if all you are looking for is removal of &layers= from PLs. The downside is that it does not actually reset your layers, and WME will load whatever layers that are saved from a previous WME session.
WME Keep My Layers addresses the limitations of both these methods and includes some bonuses as well. While the language and beta/production-editor interceptors work similarly to Vaindil’s script (albeit at DOMContentLoaded), the removal of layers is slightly delayed because it checks for layers than cannot be specified with the &layers= query. However, if there’s demand for it, I can also add the option to use the faster interception method for basic layers.
I forgot to note that the resetting of layers is delayed, but does not redirect, so it only loads that one page. KML will either interject early and replace the settings before Waze loads them, or toggle them off immediately. Its success in achieving the former currently depends a lot on connection/computer speed and the other scripts that are also loading in parallel. That said, I’m working on optimizing it so that it will be able to replace the settings early for the majority of situations.
I usually run Firefox, currently 43.0.3, with Greasemonkey. I just loaded KML and didn’t see the toggle to be able to use it, so I unloaded all my scripts to start from scratch.
After doing that, I finally found KML, of all places, at the bottom of my layers column. The problem is that the only component I can get any reaction from is the Save Selected Layers. The others, Reshow removed layers (buggy), Apply Keep My Layers and KML Settings don’t react when I click on them.
I tried sending a screenshot, but Preview gave me the message “Sorry, the board attachment quota has been reached.” It was only a 234K PNG file.
The panel swap only shows up when you click a segment or any other map feature. The Beta toggle only shows in the user info panel, but now I realize that the panel swap remains when toggling between panels, which causes an interference btwn the two. In the next revision, I’ll have the beta toggler only show when nothing is selected.
On Firefox 44b4 (beta) the script causes WME to no longer load. I get a white window, but I can still hover over the SVG elements of the map and see them being highlighted (streets, nodes, …).
The issue at hand is that the script stops working when the bootstrap function is called as Firefox 44 no longer allows any assignment of unsafeWindow (it’s a constant with an undefined value).
As I’ve posted in several other topics by now (I’ll try to write up something for the wiki today): the code in the bootstrap to get an unsafeWindow no longer works anyway as Google has removed that bug.
Short answer: just remove this piece of code and the script will load:
EDIT: something else I’ve noticed is that the @grant statements in the meta block include a @grant none. This statement prevents the other @grant rules from working. Just removing that line allowed the script to execute further. Now I’ve got a ReferenceError for “$” at line 569, probably because jQuery hasn’t started yet at that point.
This I’ve fixed with this code instead of using jQuery:
But in the end I still get a console error saying the script gives up, even though I don’t see any other messages saying that the script is trying… Weird.
Thanks, Glodenox! You’re always so helpful. This is all new territory for me, since I primarily work in Matlab and python for scientific computing.
I was wondering — since FF no longer allows assignments of unsafeWindow, could you recommend an alternative way for another WME script to share some of its functions? Injecting the code via require/imports is not an option.
Btw, I caught that typo awhile ago, but I might have wrongly assumed that no one had downloaded that version of the script and forgotten to change the version #. Sorry about that! Try getting the update and see if that fares any better? I’ll remove the old bootstrap lines soon and push that update through… once i get back to my computer.
Btw, @grant none and @grant GM_* executes fine in my Chrome browser. I generally don’t like working within a sandbox in the beginning since my aim is just to get the code to work. lol! During the pruning and refining stage, I’ll eventually step into the sandbox. However, that being said, I have not paid attention to whether it currently needs the looser restrictions.
I’ve just noticed I’ve made an error in my assessment on what’s causing the unsafeWindow issues. In Firefox unsafeWindow is an object, but the bit of code about Components in front of it is causing the issue as bGreasemonkeyServiceDefined would remain false, even though we already have an object in unsafeWindow. I’ve just successfully executed this code in Firefox 44 in a userscript:
console.log(unsafeWindow); // Window object in the context of https://www.waze.com/en-GB/editor
console.log(typeof unsafeWindow); // object
if ("undefined" === typeof unsafeWindow) { // Will equal to false
unsafeWindow = (function() {
var dummyElem = document.createElement('p');
dummyElem.setAttribute('onclick', 'return window;');
return dummyElem.onclick();
})();
}
So if you want to use unsafeWindow somewhere in a script to expose some functions of your script, you don’t even need to do something special as it will be available. But I think you’re already running within the sandbox without you knowing it. When you start adding functions to unsafeWindow, it’s probable that you’ll run into this. (exportFunction() and cloneInto() will help if you run into issues)
EDIT: hmm, just noticed unsafeWindow is not available in Google Chrome (with TamperMonkey). That is a problem. Gah, and we’re in the full sandbox the very moment we provide ourselves the permission to use unsafeWindow with @grant. That’s going to be an issue.
Glodenox:
I’m wondering if you are seeing the same problems with the current version of FF as you are with the beta. I’m guessing you are. I’m running 43.0.3, the current stable one and instead of bugging TheLastTaterTot, as she said she doesn’t use FF, I thought if you had any ideas you could continue to either post to the forum or PM me. I use a MBP running El Capitan, the latest Mac OS and generally prefer that over Chrome. Chrome on the Mac seems to have issues with Google Chrome Helper as explained at Google Chrome Helper for Mac
That seems very likely indeed. The errors I’m getting don’t seem like something that could be related to the beta version of Firefox. But considering that this script is still under active development, that isn’t really an issue. The scripts I develop often don’t work on Google Chrome straight away either.
Also, FYI: from the moment you’re adding a @grant with a GM_* function, you’ll be running within the sandbox mode in Firefox. As you are using the GM_setValue and GM_getValue methods, Firefox applies the sandbox mode, making $ for jQuery unavailable (which is the current issue I’m running into). If you think you don’t need any other GM_* but setValue and getValue, you may want to consider replacing them with localStorage, which provides the same functionality. As such you could remove those two @grant rules and the script might run fine in Firefox (I haven’t tested yet).
When it is running, I can NOT open both WME and WME beta sessions and the toolbox toggle between them stops working.
Also, both mouse over and clicking on isn’t properly opening pop-up info for URs, MPs and Places. The ballons are there but don’t work much of the time.
Also, the ‘toggle’ in the left bar in beta disappears after loading finishes so I can’t switch it unless I catch it fast.
NOTE: some of these odd actions may be from some other script or recent beta updates because they didn’t go away just now when I turned off MWEkML.
Chrome and Win7ent with current updates.
Additional info: Now, I can’t open beta at all IF WMEkML is turned on. I must disable it to use beta.
We need a way, within it, to turn it off so that we can change things and save the new configuration. As it is now, as soon as I re-enable it, it recalls the old settings and forces me back to WME.
Thanks.