I’m seeing the following error in the JS console. I’m using Chrome version 41.0.2272.118 m.
Uncaught TypeError: Cannot read property 'innerHTML' of undefinedIt’s being triggered from uroTenthSecondClick() on line 4784.
I’m getting literally hundreds of these in a row, and I’m not sure if it is what is causing URs to display super slow, or something else is causing URs to display slow, and causing this error.
RickZabel gave me a heads-up about this yesterday following the latest WME update - it’s been fixed in the current development code which is rapidly approaching release status, so please bear with me for a short while longer…
3.42 introduces the following changes:
- Place filtering is not applied to places which are being created
- Further improvements to the way comment counts are handled
- Further improvements to the way URO+ co-exists with URComments (thanks again to RickZabel)
- Reset option to revert all settings to their installation defaults
- Popup border style adjusted to avoid visual glitching in Firefox
- Compatibility update for latest WME release
Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/detail/uroverview/amdamgkgchnbaopmphhjapmjcdghdphi
1 Like
Thank you very much for the quick update release. Appreciate all the hard work you have poured in 
Noticed a little issue on the UR pop up, it seems that the pop up will not go away unless I move my mouse rather far away. The previous version was working fine. Am I over sensitive or is this working as designed? I’m on Firefox + Greasemonkey 
URO+ does not show anymore if URs were open from Livemap. Is it not possible anymore?
Nothing has changed here, URO+ can only identify Livemap URs if they were posted by someone who wasn’t logged-in to Livemap.
It’s working as designed - one of the bug fixes in this version was to prevent the popup closing too quickly making it difficult to move the mouse pointer from the UR marker onto the popup. This delaying of the closure means that when you do move away from the UR/popup, you can get your mouse pointer further away before the popup closes, however it’s not how far you move the mouse that determines when the popup closes - if you move it just 1 pixel off the UR/popup and then leave it alone, the popup will still close after the same delay.
Since the update, more and more often I am seeing ‘stuck place data’.
The SAME place data pops up or hangs on the screen. It moves to different places as the mouse is moved.
I can NOT see the usual UR content preview pop up by mouseovering a UR.
I can click on the UR and open it and service it.
Love URO+.
Wish it gave the same kind of data on mouseover of restricted turn arrows and closures that it gives on restricted segments.
Hmm, can this time delay be shortened? I seem to prefer the previous version. LOL :lol:
aHA! If I stop running away from it, it will stop chasing me! Thanks.
I hated it. I run zoom-0 and use the popups to open in a new window. I could somethimes open a UR after 4 or 5 tries, sometimes have to zoom in tighter.
So, easy fix (says the guy who doesn’t have to code it). Make the default value match the current one, which is safe, but make the delay configurable so those in the know and without need for the lag are able to shorten it.
Okay, I think there is a misunderstanding in what the original complaint is.
The problem that I am encountering is when the mouse moves over a UR that is very close to the one selected, URO+ opens the popup for the 2nd UR.
The time delay is not fixing this issue… it is still extremely hard to mouse over to “open in new window” in an area with a lot of URs close together.
A side effect of the increased delay AND the tendency to grab a new UR is that I can click a UR, then when I mouse to the popup to enter a comment, if I pass over another UR, it pops that UR’s window up on top of the original information window, and I have to wait 3-4 seconds for it to clear.
I think a fix for this would be to cut the new delay time down by about 75%, but ALSO add a delay time for when the popup appears when mousing over a UR. A short enough delay would not be too noticeable, and it could help prevent the loss of the desired popup.
Moving the popup a bit closer to the UR would help a bit as well. I recall that it was moved away because it was causing problems with URs near the edges of the screen and the popup was overlaying the UR making it impossible to open.
Just want to pop in and say that the problem I had mentioned, about not being able to get to the popup before it closed, and having to try multiple times, is definitely fixed.
I do occasionally get a popup that’s ‘stuck’, especially if I get a popup right before I click-drag the map to scroll it, until I get another popup, but my original issue isn’t an issue anymore.
I will agree that if there’s another popup-maker in between the UR and its popup, you pretty much can’t reach the popup for the UR since traveling the distance to get to the popup will always trigger the other thing’s popup. Easiest example is the UR in the middle of an area place. It’s often hard to get to the popup of the UR without accidentally triggering a popup of the place it’s surrounded by, because of that gap between UR and popup. I don’t have too much trouble, and basically file it as a limitation of the app, but if it could be addressed that’d be cool too.
URO+ is broken.
As it starts to load, it blanks the left column area and the area stays blank.
If I disable it, and f5, the column is visible.
The problem happens if BOTH URO+ and Color Highlights are active.
The text column disappears under other circumstances, even if Color Highlights is disabled.
For example, when I am using URComments to handle a URO, as soon as I enter a comment and send it, the text column to the left clears and doesn’t want to display again, as long as that comment is open, even if I F5, as long as the comment is in the URL, the column is blank.
I wish Waze would stop breaking our tools!
Chrome Version 42.0.2311.90 m up-to-date on win7
I think something with wme.
Was working, then I got a notification about a Toolbox update & the production editor stopped working as described above. The beta editor is working properly (with scripts running) though…
They were doing something to WME yesterday.
I was getting odd things happening with saves all day (only part of an edit was saved, or saved operation would partially revert after the next save…)
Last night I was having issues with new or updated places alternately reverting (or going away) then coming back after a save or refresh, and any saves that involved adding a new junction wwere extremely flaky… Sometimes erroring out, then on resave “they have changed”… then back-arrow through all (40!) edits, hit refresh, and everything is there, so the edit actually did “take”
WME was also running extremely slowly.
If you’re using the DrivesTabEnhancer option, please try disabling it and reloading the WME session - I’m seeing random problems with the data returned from the server when DTE is initialising, which is causing the DTE code to get stuck and thus preventing the rest of URO from initialising correctly…