[Script] WME Color Highlights - 2.33 Sept 2020

[turbomkt]

I think it also throws a lot of errors in the console - possibly the source for the slow down?

[turbomkt]

With the WME tab selected, hit F12. It's the debug console used by developers. Odds are, you will see errors scrolling constantly.

[turbomkt]

I'm not seeing that. It worked for me every time I tried it yesterday and in a test just now. What version are you using? Mine is showing 2.27.

[turbomkt]

Would it be possible to change the color of the 'Filter by City' option which is currently in yellow? It is very difficult to see it on Primary Street segments. Thanks for considering.

If they don't update the script, you can change the color using hex color codes at line 384. Search google for "hex color picker" and you should be able to find something that works better for you.

[Twister-UK]

With both the latest versions of WMECH and WMERC installed (with no other add-ons running), the Routes tab doesn't show up when two segments are selected. Problem exists both in FF and Chrome.

Unlike the above posters I don't seem to have any difficulty in selecting two segments - clicking just once on each segments causes WME to show both segments as highlighted and also brings up the "2 segments selected" note in the sidebar - so WME appears to be in the correct state for WMERC to initialise its tab.

[Twister-UK]

With both the latest versions of WMECH and WMERC installed (with no other add-ons running), the Routes tab doesn't show up when two segments are selected. Problem exists both in FF and Chrome.

Do you have the latest version of WMERC - v1.18? Routes has it's own tab now.

Yes - the copy in FF updated itself and I didn't have it installed in Chrome so that was a fresh install straight from the web store. WMECH was also checked to be running at the latest version in both browsers too. If I disable WMECH then the routes tab appears alongside the General/Closures tabs as expected for the 1.18 update, it's only when both scripts are running together that the tab fails to appear.

[Twister-UK]

And now it's working just fine in both browsers... *sigh*, unpredictable code behaviour like this makes me pleased I'm not a script writ... oh, wait

Haven't looked into the inner workings of WMERC recently, could this have been caused by some glitch on the Waze servers, or does it only start to access those once you click on the tab to generate the routes?

[Twister-UK]

When I open editor with places turned on, this thing happens after I click on any place.

I fixed an issue that was occurring on Firefox (v2.2). Let me know if that fixes it.

Just in case the issue you're referring to is something else, then FYI this fix also resolves the WMECH-WMERC interaction problem I mentioned earlier - it reappeared a short while ago and I realised it was due to the order in which the two scripts were being initialised. If WMECH got initialised first, it added its selectionManager event handler to the listeners list before WMERC added its handler, and when the WMECH handler then failed due to the undeclared lastSelection variable, it prevented the WMERC handler from being called.

[Twister-UK]

Seems to be an initialisation issue - I'm seeing a "WME Highlights: not logged in - will initialise later" message in the debug console maybe half the times I load a WME session (with or without any other scripts loaded), after which WMECH doesn't then appear to attempt its initialisation later on. Reloading WME until this message doesn't appear then allows WMECH to initialise OK and appear as normal in the sidebar.

[Twister-UK]

It's now failing the majority of the time, but only when using Firefox, with or without other scripts being enabled.

In FF, the first run of initialiseHighlights() always seems to fail on the test for window.Waze.map, but always then succeeds on the second attempt. Once past this point, there then appears to be a 50:50 chance that the "not logged in" test further down the function will then cause the function to exit early. On the same PC, Chrome never seems to need to retry this function, nor does it ever seem to get caught by the login test - WME setup times in Chrome seem to be sufficiently fast compared with Firefox that it manages to stay one step ahead of WMECH

If WMECH trips over the login test, the problem is then that the login event handler added to Waze.loginManager isn't firing when WME gets around to logging me in, and so initialiseHighlights never gets called again...