Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"You have made too many edits" warning does not disappear on save #1120

Closed
Sellyme opened this issue Sep 16, 2023 · 8 comments
Closed

"You have made too many edits" warning does not disappear on save #1120

Sellyme opened this issue Sep 16, 2023 · 8 comments
Assignees
Milestone

Comments

@Sellyme
Copy link

Sellyme commented Sep 16, 2023

Description

When using Rapid in Power User mode, it's possible to make a large number of changes without being forced to save in order to continue. At some point, a red warning message at the bottom of the screen reading "You have made too many edits to back up. Consider saving your changes now." appears.

After saving, this warning stays visible, leading to an unusual situation where the editor is simultaneously saying I've made zero edits (top-right) and "too many edits" (bottom-right):
image

Version

2.1.1

What browser are you seeing the problem on? What version are you running?

Firefox Developer 118.0b8 (64-bit)

The OS you're using

Windows 11 Pro N

Steps to reproduce

  • Open Rapid in poweruser mode

  • Make many (~100) changes to the map, until the api-status error footer appears with the "You have made too many edits[...]" message appears

  • Save your changes.

  • Note that the footer remains with a no longer valid error message.

The browser URL at the time you encountered the bug

https://rapideditor.org/edit#background=Bing&datasets=fbRoads,msBuildings&map=18.08/32.48759/107.10261&overlays=osm-gps&poweruser=true

The auto-detected useragent string for your browser (leave blank if you're manually filling this form out)

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0

@Sellyme
Copy link
Author

Sellyme commented Sep 18, 2023

This is likely related to issue #1060, possibly whatever fix was applied for that missed this portion of the UI.

@simonschaufi
Copy link

simonschaufi commented Jan 29, 2024

@bhousel Can this bug be fixed please? It should be quite easy to fix :)

@bhousel
Copy link
Contributor

bhousel commented Jan 29, 2024

@bhousel Can this bug be fixed please? It should be quite easy to fix :)

Sorry! To be honest, I thought we fixed this already. I'll take a look..
(I agree that it should be easy, and it's probably like #1060)

@bhousel bhousel added this to the v2.2.5 milestone Jan 29, 2024
@bhousel bhousel self-assigned this Jan 29, 2024
@simonschaufi
Copy link

simonschaufi commented Jan 29, 2024

It still shows up after 170 changes and stays there after saving the changes.

@bhousel
Copy link
Contributor

bhousel commented Jan 29, 2024

Yep, that number is less an actual number, and more to do with how complex the thing is being edited. Waterways, landuse, coastlines, and similar things can really fill the storage up, because we try to store what it looked like before the user started their edits.

@simonschaufi
Copy link

simonschaufi commented Jan 29, 2024

The number can stay the same but the message should be gone after save, that's the whole point ;)

I've also noticed a huge performance impact after about 200 changes, so that is usually when I save.

bhousel added a commit that referenced this issue Feb 8, 2024
(re: #1120)

By making it this way, other code doesn't need to listen to a special 'reset'
event to know it's time to redraw the UI.

This also moves the reset from `initAsync` to `startAsync`, because it
can dispatch events, and we shouldn't be dispatching events during 'init'

This also adjusts the `storage_error` event to be a `backup` event,
but unsure whether I want to keep it this way or not.
bhousel added a commit that referenced this issue Feb 8, 2024
(re: #1120, re: #1304)

Added dedicated `getRateLimit` and `setRateLimit` functions in the OSM service
This simplifies the `uiStatus` code a bunch.
@bhousel
Copy link
Contributor

bhousel commented Feb 9, 2024

Over the past few days I've done a bunch of work on how we surface the status issues to the user, and can confirm that this is fixed now 👍

@bhousel bhousel closed this as completed Feb 9, 2024
@simonschaufi
Copy link

simonschaufi commented Feb 9, 2024

Thank you very much! Can you also release that please?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants