Although I know which part of my code is causing the problem, it requires WME to be in a certain state, and I haven't been able to get this to happen yet... FF and Chrome, Production and Beta, they all behave as expected.

So are you running any other scripts that affect the WME user interface, or doing anything else to WME to cause it to change its appearance compared with the native look?

Whilst I can simply put in a fix, I'd like to understand how and why WME is getting into a state that would trigger the problem, as it may have implications for other things my code does...

For those users with an interest in the recurring phantom popup issue, a quick update is in order:

Twister-UK wrote:I'm still no closer to understanding why popups sometimes remain onscreen after the associated marker has been deselected

I've finally confirmed something I'd suspected for a while but had never been able to prove... from time to time, WME will leave something tagged as being highlighted even though your mouse pointer is no longer anywhere near it, and especially if the something in question is no longer visible in the current map view either. This complements another problem I've noticed from time to time in WME, where it completely fails to recognise that an object *does* have the mouse pointer hovering over it and therefore *should* be highlighted...

When this occurs, and if the something in question is an object type for which popups are enabled, and if no other popup has been generated which takes precedence, then URO+ will assume that the object data is telling the truth, that the object really is being highlighted by the user, and generate a popup accordingly.

Although there doesn't appear to be much I can do about this if the object is still onscreen, I can at least block these rogue popups from being generated by objects that are no longer visible... And if the object is still onscreen, it may simply be enough to move your mouse pointer over and then off it again to reset the highlight state.

shmupi wrote:Seems to broken under the new beta WME

The WME team did it again

Meh Will look into this when I get some time later in the week - it's a holiday weekend here so I'm too preoccupied with family stuff right now to be doing any development work... why do the Waze devs always seem to release script-breaking updates at the most inconvenient times for anyone else to do much about it???

3.75 auto-hides the popup whenever a native WME drop-down menu is opened, and implements the partial workaround for the "stuck highlight" problem noted earlier. It also introduces support for the URs submitted via the Waze Speed Limit tool. And for the pirates amongst us, it's now compatible with the latest beta release...

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

Unless there's a devious combination of filter settings that does something I didn't intend it to do, then this won't be possible, as markers get hidden as soon as any one of the enabled filters is triggered rather than requiring them all to be triggered.

For all users, 3.76 adds an "invert state/age filters" option for UR filtering to allow the sort of filtering options as requested by RussPA a few posts up, and quietly kills itself if an editor profile page is opened in Chrome.

For pirates, closure cloning now works again...


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

SuperDave1426 wrote:Would it be possible for URO+ to look for the new [Caltrans] tag that appears on it, and provide a custom icon like it does for TrafficCast markers? BTW, TrafficCast markers are still appearing - this doesn't replace them apparently, it's just additional so far that I've seen.

Spreading like the plague in LA, by the looks of things... There's also a bunch of [LADOT] ones there too, which I'm assuming are coming from the city transportation department.

I'll see about adding support for these two tags in the next version, although I may have to just start using a generic marker for these state/city level tags, otherwise I can see myself spending more time designing new markers than writing code or map editing

With these two new MP tags appearing, it also feels like time to expand the MP filtering capabilities to include tagged-MP support in the same way that tagged URs can be filtered independently of their actual report type (missing road etc)...

roadtechie wrote:Recently ran across an issue with the new [WSLM] marker. The only way to make this marker appear is if it is in the title of the UR. If you add it at a later date it will not change the marker to the custom one. Also, any reason for [WSLM] to not be on by default? I am using V3.76 with chrome

I didn't include comment-level support for [WSLM] simply because there didn't seem to be any point - unlike a normal UR that you might want to convert into a tagged UR after it's been submitted (e.g. if you sent a quick UR whilst driving and didn't have time to include the tag there and then), the WSLM app guarantees the tag will be present every time (unless you've managed to hold onto one of the really early versions...).

Were you just testing to see if it could be done in the same way as other UR tags, or do you have an actual reason why you'd like to see this added?


Custom markers have never been enabled by default due to the increased processing requirements they place on the system. If you install URO+ new, you'll be given the option of having them all auto-enabled the first time the script starts up, otherwise it's up to the user to enable the ones they want.

voludu2 wrote:in PA, before WSLM, we just used the fill-in-the-blank custom marker with "mph" and were pretty happy with the "?" marker

Does that one work if it doesn't appear until a later comment?

Yes, the other tags (including the custom one) are searched for within the comments as well as the UR description, it's only [WSLM] which is description-only at present

The second error is being thrown because the code which checks to see if you've changed any feed filter settings isn't able to find the filter checkboxes, which in turn suggests the code that adds those checkboxes into the feed sidebar hasn't been able to run. Unfortunately, the checkbox testing code assumes the checkboxes will be present and so doesn't bother to test for completion of the checkbox addition code first - the rapidly incrementing error counter is then due to the code attempting to test all of the non-existent checkboxes on a regular interval...

Now, it appears that the feed filter checkboxes are missing because of the first error shown in your console - during the script initialisation, the feed filter is set up after URO loads and parses its saved settings, and as this first error is occurring during that process, the remainder of the initialisation code will fail. URO meanwhile knows that it's called the initialisation function and so assumes everything is OK to let it continue on into normal operation, which it does, hence why the second error then occurs.

What's odd about this first error is that it seems to suggest that at least one of the saved settings has been saved in a way that URO itself shouldn't be able to achieve, and which is then preventing URO from realising that the setting doesn't contain anything it's able to parse.

In the TM console, can you enter localStorage.UROverviewCamWatchList and let me know what it says in return. If it says anything other than "undefined", please can you then enter localStorage.removeItem("UROverviewCamWatchList"), then repeat the previous command and let me know what it says now.