Be sure to do this in Tampermonkey
You must be new here… No offense really.
Just saying Waze developers have not and will not take scripts into consideration when they make their changes. It’s always been a shoot first, ask questions second. They will make the changes and then they will try to assist us with what to do to get around what broke. However, they WILL NOT change anything about their development lifecycle or timeline to accommodate scripters. It has nothing to do with Waze Editors either. Scream all you want at staff, they will not make changes to their lifecycle because you tell them “We use X Y Z script and you broke it!”
Look at the scripting community as a whole over the past 10+ years. There are literally hundreds of scripts that arguably make the WME experience night and day better. However, Waze has only incorporated a very small (less than 5) into WME natively in that timeframe. They have asked for FEATURES we want to see taken from scripts and placed into native WME, but that’s all. I mean, why has it taken literally the ENTIRE LIFE of Waze to finally get them to try to incorporate Junction Angle Info (JAI) into native WME? Something as critical as the departure angle of a segment-out from a node and segment-in changes what is both spoken and shown on the displays. Critical to how the map operates in the client. However, they are just now trying to bring that in.
Don’t get me wrong, they are listening. But that’s all they are doing. Listening. Until they start actually showing they are adding more than just the few items they have in the past, I wouldn’t put much weight to their words. Actions speak louder.
What I WOULD do, I WOULD learn to use WME WITHOUT scripts. There may actually come a time that most scripts become useless in the state they are headed with reusable containers in the backend code. Without giving a proper API (which they never will do as they have said on many occasions lately: WME was never meant to be an API), scripts will lose the ability to interact with the containers. At least easily. I, for one, will not be spending hundreds, nay thousands, of hours trying to figure out how to manipulate WME again. Won’t happen.
i did not make any demands. i politely asked for consideration.
as indicated i have no problem stepping back from editing if changes made to the interface make certain tasks more difficult. i don’t disagree that the WME devs have any sort of obligation to make sure scripts work. however, since we are all volunteers doing this as a hobby they should feel an obligation to how editors use WME if it’s important that updates are made in a timely manner.
No, I’m not. @nimper2000
Hi G_W1Z,
The team is working on the feature to allow close handled UR/PURs by clicking the “save” button. We will keep you posted.
About the “add” button, I missed that comment. May I ask you to open a related suggestion in the Uservoice section?
Regards,
Nataliia
Hi S_Jay_,
Could you please share the link to the segment where you faced this behaviour? I couldn’t recreate it on my side.
Thank you in advance,
Nataliia
Hi Everyone,
About the issue with scripts, I want to say, that we will address your concerns shortly and update you.
Thank you for the feedback and sorry for the inconvenience.
Regards,
Nataliia
Hi Nataliia,
I can’t link the ones from my original screenshots because I deleted them. But I created 3 other ones that show the same behavior on my side:
Test1 (no problems with Chrome in full screen; sidebar too narrow if not in full screen):
https://waze.com/editor?env=row&lat=53.54015&lon=10.24163&zoomLevel=18&mapComments=6685207.67114218.1262930
Test2 (sidebar too narrow):
https://waze.com/editor?env=row&lat=53.54015&lon=10.24163&zoomLevel=18&mapComments=6685207.67114218.1262867
Test3: (sidebar too narrow)
https://waze.com/editor?env=row&lat=53.54015&lon=10.24163&zoomLevel=18&mapComments=6685207.67114218.1262868
Thank you Sebastian. I see that in the first place the scroll bar is displayed correctly but it becomes wider and covers elements of the left panel after we hover the pointer over the scroll bar. Is the behaviour same on your side?
Regards,
Nataliia
I have a problem very similar to the bug discovered (and reportedly fixed) in Beta.
Difference is that the script tab is not dissapearing, but instead of it will not stay active and the left panel after deselecting the segment (landmark etc.) have no active tab, so I must again manually select the script tab.
Anyone else with this issue?
Hi,
First of all thank you for the great feedback and for letting us know that some scripts are being affected.
As some said, we make sure to collect all feedback in Beta before we release a new version to production.
(If you are not part of the Beta community, that’s your chance :D, feel free to reach out and we will add you)
One of the objective is to make sure scripts are not being affected. If critical scripts are affected we can hold a release to production for some time so that script authors have time to adjust.
We give heads up to the scripter community of potential breaking changes and make sure to support them through the update if needed.
Throughout the latest beta releases we haven’t received any report and that’s why it reached production.
We understand how important scripts are for the community, and how valuable it’s your work.
We strive to improve the the native WME editing experience, while trying not to break any community scripts, and integrating some of the functionalities currently available by scripts.
Feel free to report to the script authors, if needed we can help with that and we will work with them to find a solution as fas as possible.
Thank you,
Ruben
1 Like
It does look a bit differently on my side. Hovering the pointer over the scroll bar doesn’t change anything for me. Even without hovering, the left content of the panel gets covered. But your scroll bar has rounded edges. Maybe there are more aspects that have an influence on the display (OS, design settings, screen resolution?)
In my opinion the border of the Map Comment content is too far to the right. It’s almost right to the edge of the sidepanel:
When a scrollbar is needed, it covers parts of the content:
For reference you can see that the border of the content for a road segment (https://waze.com/editor?env=row&lat=53.54134&lon=10.24091&zoomLevel=18&segments=406408680) is much more to the left and leaving space for the scrollbar:
Thank Sebastian for the answer and additional investigations. I guess you are right, for sure there are more aspects that should be taken into account.
We will open an internal issue for this. Could you please check on your side (when you have a chance) for which map object you see this UI issue with the scroll bar? (Places, Junction Boxes, etc).
Thank you in advance,
Nataliia
The auto-fill for street names and place names is case sensitive. Can that please be made case insensitive? Below clip from an incognito session.
Hi Hans,
Thank you for the report. We have an internal issue for this and the team is working on it. We will update you when we have more news.
Regards,
Nataliia
For staff, please keep in mind that many scripters will wait until after the beta is released to start fixing their scripts. They do this because they don’t know what changes will be made between the day the beta is released and when it goes to production. Because of that, we are accustomed to not having scripts available in beta and can’t report everything before that beta goes to production.
1 Like
Autocomplete for the Street field in the Address pane is now case-sensitive.
Can you please revert to the previous behaviour and make it case-insensitive?
EDIT: Sorry. I see this was reported already. I got too sucked in to the scripts discussion to notice. 
1 Like
And to the community: Please note that script offers do have the opportunity to plan for production releases, but they—for perfectly valid reasons, don’t get me wrong—choose not to.
So the reason your scripts break immediately upon a production WME release is not because staff changed things without notice. Most often, staff gives us (through beta) plenty of notice. If you want your own advance warning, as Ruben said, sign up for WME Beta. We can’t talk about what’s in beta outside of beta channels, so you won’t hear about it otherwise.
What script authors choose to do with that notice may vary, but many choose to wait until production before reacting. That is their choice. They have ample opportunity to adjust scripts while new features and changes are still in beta, but many choose not to.
That is not reason to delay a production release. The timing between beta and production makes absolutely no difference if a script writer chooses not to address WME changes until a production release anyway.
Again—that is a valid choice. But it means that anger at WME developers for “not delaying production releases” is misguided, misdirected, and unfair.
As an example, URC-e has been broken in beta for several weeks. That is ample time to adjust. The best we can do is notify URC-e’s author of the changes. In this case, he chose not to adjust until the changes hit production, and that’s fine. Don’t blame staff for that, that’s not staff’s fault.
Don’t blame anyone. Just chill, be patient, bring your feedback calmly to the person who can actually do something about it, check your sense of entitlement before you open the browser, and understand that the sky isn’t going to fall down because you can’t filter automagically respond to URs for a few days.
You’re welcome!
No issues:
- Road segments (I tried to check every road type; general-, closures- and Lanes-Tab)
- Walking trails
- Roundabouts
- Residential places
UI issue:
- Map comments (point & area)
- Drives-Tab
- Events-Tab
- Settings-Tab
- Places (point & area); border around the “Chosen/Suggested categories” field
- Speed/red light cameras
- Junction boxes
Not identified:
- Railroad crossings
I chose to wait because of the bug reported in the link in MajkiiTelini’s post above. I “thought” the issue would be fixed in production release. It was not. While it was semi-fixed (the script tab no longer disappeared), it did not get 100% fixed as the ACTIVE (denoted as having the ‘active’ class) tab is not being restored when a map element is deselected. (See MajkiiTelini’s post above).
I KNEW there was an issue with the width of the container as Waze decided for some unknown reason to me to set the width to 330px, which is 30px wider than they have set for “max-width” of the side panel. They set the max width to 300, but they set the side panel root container to 330px. I hard code 300px for my inner containers, but this was being overwritten by their higher dependency of the 330px via their new CSS update. I forced mine to be priority with an !important flag. Again, I THOUGHT they’d catch this before release to production, but they didn’t.
That being said, Ruben, Nataliia: There are two bugs here:
- The “active” CSS class is being removed from the entire DOM tree under the #side-panel container when an element is selected/deselected. This is causing the active script tab to no longer be selected upon the deselection of the map element (place, segment, etc). Further, if that script has sub-tabs (URC-E, GIS-L, are two examples) that also utilize the “active” CSS class, they are being stripped as well. So if you do manually select the script tab to make it active again, the tab will be blank because the “active” tag was removed from the sub-tab by your selection / deselection process.
- You are manually setting the width to 330px for the side-panel. Which is wider than the max width you have coded at 300px. So 10% of the panel ends up being hidden behind the left side of the map.