Page MenuHomePhabricator

Decide how we are going to handle editing sections
Open, Needs TriagePublic

Assigned To
Authored By
Aug 17 2023, 8:12 AM
Referenced Files
F47027807: T344410_ER_Safari1.webm
Tue, Apr 16, 7:26 PM
F47027747: T344410_ER_Chrome1.webm
Tue, Apr 16, 7:26 PM
F41668557: 2024-01-12_16-01-24.png
Jan 13 2024, 12:22 AM
F41668555: 2024-01-12_16-00-32.png
Jan 13 2024, 12:22 AM
F41668548: 2024-01-12_15-33-44.png
Jan 13 2024, 12:22 AM
F41668543: 2024-01-12_15-32-26.png
Jan 13 2024, 12:22 AM
F41668545: 2024-01-12_15-32-55.png
Jan 13 2024, 12:22 AM
F41668570: 2024-01-12_15-52-08.png
Jan 13 2024, 12:22 AM


When to clear edit recovery data

Currently, if you edit a section the edit recovery data is stored in a separate indexeddb record.

You can have multiple records associated with the same page.

For example, if you open the below users and make edits (but don't publish):

you will have three records, one for the entire page and two for the two sections.

However, as soon as you publish an edit (either for the entire page or a section) it will clear all the records associated with the page and you will lose any unsaved edits for the other sections and/or the entire page.

So, for example, if you were now to publish the edits you made to

you would lose any edits you made to

How to handle sections added or moved

Sections are identified by a number, for example: title=New_Page_123&action=edit&section=3.

section_numbers_before.png (716ร—982 px, 77 KB)

These numbers can change if sections are moved around the page or new sections are added above the existing sections. For example, if I make edits to == Section 2 == (but don't publish)

In the meantime, if someone adds a section above it like in the screenshot below

section_numbers_after.png (723ร—989 px, 81 KB)

If I return to I will be editing a different section (=== Section 1b ===) but it will restore the edit data for the previous section (== Section 2 ==).

Deleted section

If I am editing the last section on the page and someone deletes it, when I go back to edit it you will see "Cannot find section" and therefore you won't be able to recover your edit data.

section_deleted.png (421ร—991 px, 47 KB)

I would need to edit the entire page to re-add the section or undo the delete (unless you use rollback), but doing that will clear all the recovery data for the page, thus losing their unsaved edit data.

We should decide how we want to handle these cases. Perhaps this is a question for @JSengupta-WMF.

QA Results - Beta

Event Timeline

Restricted Application added a subscriber: Aklapper. ยท View Herald TranscriptAug 17 2023, 8:12 AM

Change 967756 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/core@master] Edit Recovery: discard section edit correctly

I'm not sure how we want to handle this, but it looks like there's a bug anyway: as things stand, we should be treating sections as their own thing and not deleting them when the whole page or another section is edited.

Maybe we'll change that when we answer the actual question of sections, but it seems best to at least make it consistent for now.

Change 967756 merged by jenkins-bot:

[mediawiki/core@master] Edit Recovery: discard section edit correctly

@dom_walden Now that sections and the whole page are deleted independently (per the above patch), the behaviour here might be a bit better; can you see what you think?

I'm still not sure if it makes sense to keep sections if the whole page is discarded (or vice versa), and there's still the issue of section numbers being a rather clunky way to track sections, but I'm not sure what should be done.

I have raised T352028, but I wonder if we should just move the current bug back into In Development?

Good point, thanks.

Unfortunately, it doesn't seem like there's any way at the moment to determine what section was being edited, in the postEdit hook, so we'll have to add that. It's probably still better to add it there rather than deleting the data on clicking saving because the same might not work.

T352028 has progressed and is now in QA, and the idea is that whole-page vs section editing is handled quite separately and there shouldn't be any interaction between the two (i.e. saving/cancelling the whole page doesn't delete section data, nor vice versa). Whether that's the final state of how we want things to be, but I think it's at least consistent and we can move ahead with it for now. Does that sound okay?

Yes. Let's start with this and see if we get any insights when people start using this feature.

@Samwilson Please see the results below. Firefox seems to be working fine but I had a couple of different issues as seen from Chrome and Safari.

Status: โŒ FAIL
Environment: Beta: 1.42.0-alpha (eb82de5)
OS: macOS Sonoma 14.2.1
Browser: Chrome 120, Firefox 120, Safari 17.2
Skins. Vector 2022
Device: MBA M2
Emulated Device:: n/a
Test Links:


โŒChrome- "Vanilla" was published from but "Vanilla" was not removed from the IndexDB after it was published

RegularSection 1Section 2Publish Changes Result
2024-01-12_16-12-20.png (1ร—2 px, 441 KB)
2024-01-12_16-10-46.png (1ร—2 px, 472 KB)
2024-01-12_16-12-03.png (1ร—2 px, 445 KB)
2024-01-12_16-12-40.png (1ร—3 px, 597 KB)
2024-01-12_16-12-56.png (1ร—3 px, 515 KB)

โŒSafari- "Fish" was published from but this time, everything in the IndexedDB is now deleted which includes "Dog" and "Cat"

RegularSection 1Section 2Publish Changes Result
2024-01-12_15-49-42.png (1ร—2 px, 386 KB)
2024-01-12_15-50-11.png (1ร—2 px, 404 KB)
2024-01-12_15-50-39.png (1ร—2 px, 382 KB)
2024-01-12_15-51-21.png (1ร—2 px, 418 KB)
2024-01-12_15-52-08.png (1ร—2 px, 333 KB)

โœ…Firefox- "Burger" was publish from and the other two still had the previous Edit Recovery words of "Cheese Steak" and "Pork Roll"

RegularSection 1Section 2Publish Changes Result
2024-01-12_15-32-55.png (1ร—3 px, 534 KB)
2024-01-12_15-32-26.png (1ร—3 px, 546 KB)
2024-01-12_15-33-44.png (1ร—3 px, 505 KB)
2024-01-12_16-00-32.png (1ร—3 px, 539 KB)
2024-01-12_16-01-24.png (1ร—3 px, 423 KB)

@GMikesell-WMF It looks like there might've been a few issues here:

  • We were saving the page text even if it wasn't changed; this is now fixed.
  • Clearing the page data after saving was ignoring the section number; this is also now fixed.
  • Lastly, it appears that sometimes browsers' dev tools are showing the contents of the database prior to the last updates, so it's probably best to use Special:EditRecovery or click the 'reload indexedDB' button (although perhaps you were and this is not an issue).

Sorry to have been slow in responding to your test results here. Could you have another look at this and see if things are now working correctly? Thanks!

@GMikesell-WMF mind looking at this once more? We've made a few updates and want to make sure it's working as expected

@Samwilson @JWheeler-WMF I tested it again and this time Chrome now works but Safari is still having an issue. After a publish in Safari, it was not removed from the IndexDB as seen in the video below.

Status: โŒFAIL
Environment: Beta: 1.43.0-alpha (67f80e6)
OS: macOS Sonoma 14.4.1
Browser: Chrome 123, Safari 17.4.1
Skins. Vector 2022
Device: MBA M2
Emulated Device:: n/a
Test Links:


โœ…Chrome- "Vanilla" was published from and now "Vanilla" is removed from the IndexDB after it was published

โŒSafari- "Blue" was published from but this time, everything in the IndexedDB stayed when "Blue" should have been removed since it was published.