Twister-UK wrote:I describe it as an "attempt" only because I don't understand why having WMETB installed is causing the issue

Having spent some more time observing the interaction between URO+ and WMETB, the source of the original problem has now been identified... If WMETB starts up after URO+, it calls the uroWazeBits() function (which URO+ has already called by this point as part of its own startup procedure) to reinitialise the layer indices used by URO+. Previous to 3.20, calling this function twice wasn't an issue.

As of 3.20 however, uroWazeBits() also initialises the window.confirm() interceptor code, required by the "inhibit pending questions prompt" option. The way this code was written in 3.20 worked just fine provided it was called once. The JS environment provided by Firefox also coped quite nicely with the code being called multiple times, however the JS environment provided by Chrome was somewhat less tolerant of multiple calls. And by somewhat less tolerant what I actually mean is completely and utterly intolerant, to the point of throwing a hissy fit as soon as the intercepted confirm() function was called for the first time...

The fix I put in to 3.21 was simply to rewrite the interceptor code in a style which seemed to meet the general Google consensus on how this sort of code ought to be written, which conveniently allows the code to be called multiple times without ill-effect. So I think it's safe to upgrade 3.21 from being an "attempt" at a fix to being an actual fix.

doctorkb wrote:Does TB's calling of uroWazeBits() make sense? Should we remove that from TB to avoid future issues?

I recall there was some problem a while ago where having URO+ and TB installed would cause WME to misbehave and that TB was tweaked to fix this, so I'd hazard a guess that the uroWazeBits() call is related to this fix, however as I was unaware until these past few days that TB has been making this call, I don't know for certain why it's doing it, when it started doing it, or whether removing it would cause a problem.

Based on the comment added to the console log when TB calls the function, it's something to do with layers, and since the only thing uroWazeBits() does in relation to layers is to get the layer indices for all the layers URO+ later uses, I'd suspect that having TB installed as well has (or had) the potential to alter the layer indices, such that when URO+ then came to try accessing a layer using the previously stored index, that index was now pointing to a different layer.

However, looking at the layer indices listed in the console by URO, I can't see any changes between those listed during the initial function call and those listed following the TB-initiated call, so it may be that further changes in TB and/or WME have rendered this fix redundant.


In short: I don't know for certain why TB is making that call or whether it's still required, but since it now seems that having it make that call is no longer an issue, I'd suggest leaving it alone for now.

Thanks, that confirms what I suspected would be the reason for it. Given this fix was implemented in the first place, there must have been situations when TB *did* alter the layer indices, and if that's still true then the fix needs to stay in place.

That UR has been submitted with the following fragment of HTML in both the .description and .guestUserName properties:
When URO+ (or LMUR, for that matter) builds the popup for this UR and copies in the description text, the embedded javascript runs and causes the alert box to appear... I've now updated both URO+ and LMUR to remove HTML from these properties before displaying them in the popup.

3.22 sanitises the contents of the .description and .guestUserName properties prior to displaying the popup for a UR, to avoid the problem noted by Szata76.


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

All options are stored in the browser localStorage, so they persist across script (un)installations.

Before we do anything else, please can you go into the Misc tab, scroll down to the bottom, and click the "Backup" button, then copy the highlighted text from the text box below this and paste it into a PM to me - this will send me a copy of your current messed-up settings, which I'd like to see in order to understand why your CWL tab is now misbehaving and, more importantly, put in a fix to stop it happening again...

Once you've PM'd me your current settings, you can clean out your CWL by following these steps:

1. Load Chrome and disable URO+
2. Open the javascript console (Ctrl+Shift+J)
3. Open WME
4. In the console, type localStorage.UROverviewCWLGroups = "" and localStorage.UROverviewCamWatchList = ""
5. Enable URO+ and reload WME

Your CWL tab should now be operational again, albeit with no cameras and only the default "No group" group... Depending on how badly messed up your CWL settings were, I might be able to repair the damage and send you back whichever settings were recoverable so you can restore them into URO+ again.

3.23 now correctly handles "unknown server" cameras in the CWL, resolving the problem noted by nhanway.

It also adds the ability to remove all such cameras from the CWL, as nhanway's problem appears to have been triggered by a specific set of circumstances which would prevent these cameras from ever being correctly handled... If a camera was added to the CWL in a version of URO+ prior to 3.11.1, no server information would be saved with that camera. In theory, as soon as the user upgraded to 3.11.1 or later, any unknown server cameras would then be tagged with their server information the next time they were retrieved from the relevant server.

However, if the camera was deleted in the period between being added to the CWL and having its server info updated, URO+ would be unable to determine whether or not the camera had been deleted or was on a different server, and so it would remain in a state of constant limbo - always being shown as an unknown server with no ability to be removed from the CWL (other than by deleting the entire list...)

Having a camera in this limbo state doesn't in itself cause the issue seen by nhanway, however having cameras in this state in the CWL could, in the right circumstances, then trigger a long-standing bug in the code used to initialise the CWL mouse event handlers - it's this bug that was responsible for nhanway's issue.


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

The current development version can now filter Places again, with support added for private places. Popups for place update markers is in progress. Also seeing if I can do something about that bloody awful green managed area highlight...

I'm almost tempted not to bother trying to fix the green fog of despair (especially since my initial look into it suggested it wasn't going to be quite as simple as it could have been), because given how well this change has been received, it's one of those things Waze really should be forced into fixing themselves rather than relying on the goodwill of the editing community to sort out on their behalf.

3.24 fixes various compatibility issues with the latest WME release, adds basic popups for place update markers (further enhancements to follow), adds private place filtering, and inhibits all popups whilst dragging stuff around.


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi