Hmm, not sure if that helps or not, because that was also the offending option for the rest of us up until the 1.54 release, so quite why it’s still causing problems for you within your particular browser environment is a bit of a head scratcher. At least for now you’ve got a workaround though…
With that option disabled, do you see any of the console errors thrown by editor-assets.waze.com, or indeed anything else that looks like it might be a native part of WME?
Also, are you using Safari or another browser here? If it’s Safari, would you be able to try something else to see if the problem still exists there?
Also also, although you’ve been testing with no other WME addons enabled, do you have any other generic addons available which might still be interacting with WME in some way - e.g. adblockers etc - and if so does the problem still exist if literally the only thing running alongside WME is FUME?
I’ve noticed that since the most recent WME prod release + FUME I am now able to click save and still pan around on the map (Disable map blocking during save)
Please can you open WME, right click on the save button and select the “Inspect” option from the popup menu. The dev console window should now open with the Elements tab selected and centred on the page element defining the save button. Screengrab that section of the tab - I need at least the line containing the save button element itself, plus 5-10 lines above it - and post it here so I can see what the page elements structure looks like in your browser.
The error message which is being thrown suggests the element FUME needs for this option isn’t present, though it’s not clear from the error whether it’s not present at all, or just not present at the specific moment when FUME tries to use it, so the elements screengrab should help answer that question…
Here is a screenshot with the Move user/notification buttons disabled, not sure if that matters.
Thanks!(unavailable attachment: Screenshot 2023-12-14 at 9.07.25 AM.png)
No, either way works, I just needed to know if the elements I’m expecting to be there are there, and they are…
So this suggests the problem is in the timing of when that bit of the FUME code fires after you ask WME to open the HN editor - it’s a bit convoluted in order to deal with the somewhat bizarre way that bit of the UI behaves, and may therefore have a time-specific dependency in there I’m not seeing on my setup. Which are always a fun sort of bug to resolve.
A timing thing makes sense to me, although I know nothing about writing scripts. In the last month or so I’ve noticed a lot of scripts ‘sometimes’ not loading all the features or not behaving quite right and other times working fine. Generally it’s not consistent enough for me to mention anything to the author. This is one thing that always is happening. Let me know if there is anything else I can do to help. That option is nice but is an option I can easily live without. I won’t be offended if it’s too much of a headache to deal with.
This will cause FUME to perform it’s topbar prep for the HN editing controls slightly earlier, which may or may not have a beneficial effect on whatever’s causing your system to dislike the previous fix I put in for this problem…
10 second guide to script editing in TamperMonkey:
Open the Tampermonkey dashboard via the TM drop-down menu
Find the desired script and click on its pencil icon in the Actions column over on the right of the screen
Make the required changes in the script editor that should now have opened
Yeah, that was more a case of “here’s something that’s easy for you to try which might have an effect”, as opposed to “here’s something I think should have an effect, but it requires far more changes to the code”.
So now we know the easy route isn’t a fix, I’ll play around with some other ideas here and let you know how to go about testing them once they’re ready…
1.56.257 now also fixes the problem with the house number editor if you use the keyboard shortcut to access the editor, rather than clicking on the sidepanel button to get there. With thanks to Keith for the nudge in the right direction here…
I too am having the exact same problem as ojlaw - entering HN mode makes Waze wonky. With FUME disabled, I can enter HN mode no problem. Also using Chrome on a Macbook. The workaround of disabling the “Move user info/notification buttons” worked for me. That was a “nice to have” option, but not essential. Just wanted to add in here that ojlaw isn’t the only one having this issue.
Even after updating to 1.56? If so, does it make any difference whether you use the keyboard shortcut or the side panel button to enter HN editing mode?
For me it seems to be better with 1.56. I haven’t really been on WME much during the holidays so I only did a quick check. With the Move user info checked, entering and exiting HN mode with keyboard shortcuts worked. The user info buttons do go back to the right side though. Here is a quick vid. This is with other scripts running. I can send more details next week when I have more time.
well, forum is giving me attitude uploading the video. so no video.
If you’re just trying to report that they move back to the right whilst in HN editing mode, then that’s the expected behaviour of this fix - the problem with the blank topbar is because the way the HN editing UI now configures itself is based on a presumption that certain other parts of the topbar will be in certain places based on the native UI layout, so when FUME moves them around, the HN editing setup code doesn’t know what to do and leaves you stuck in no mans land…
Rather than trying to come up with a perfect fix that would allow the HN setup to complete and then reapply the move info/notification option again (which might then cause further unknown issues needing further workarounds…), I just took the path of least resistance and had FUME temporarily disable that option whilst in HN editing mode, hence why you see things move around as you enter it.
However, once you exit HN editing mode again, the option should then be reapplied so that the generai purpose WME UI continues to look the way you want it to based on your FUME settings. So if you were instead trying to report that the info/notification buttons aren’t moving back to where you want them to be once you exit HN editing mode, then that’s not the intended behaviour and I would therefore like to know more…
So the user info/notification buttons do behave as you suggest if I don’t use keyboard shortcuts. Using the ‘esc’ key to exit HN mode instead of the 'Exit house numbers mode" button causes the user info/notification buttons to stay on the right side after exiting HN mode.
Yeah, that’s basically the same problem as with the fix originally not being applied when using the keyboard shortcut to enter HN mode - I wasn’t even aware that the Esc key could be used to exit HN mode, so FUME only knows you’ve left HN mode (and thus it needs to reapply the move option) if you click the exit button… I’ll see if I can get it to work for either method of exiting.
Yeah, I keep forgetting that this is in the code - it was part of the legacy stuff I inherited from Iain, so it doesn’t always come to mind quite as readily as bits of the code I’ve written myself… So in the meantime I’ve already come up with an alternative way around the problem
