Last modified: 2014-06-28 23:24:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T48138, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 46138 - VisualEditor: Transaction with replaceMetadata then replace at the same offset doesn't rollback cleanly
VisualEditor: Transaction with replaceMetadata then replace at the same offse...
Status: ASSIGNED
Product: VisualEditor
Classification: Unclassified
Technical Debt (Other open bugs)
unspecified
All All
: Low enhancement
: ---
Assigned To: Editing team bugs – take if you're interested!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-14 22:35 UTC by Roan Kattouw
Modified: 2014-06-28 23:24 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Roan Kattouw 2013-03-14 22:35:48 UTC
This is kind of a ridiculous case, but it cost me an hour of debugging time, so documenting it here for posterity. It won't be a practical issue until we start composing transactions together.

Consider:

var data = ve.dm.example.withMeta,
    oldDoc = new ve.dm.Document( ve.copyArray( data ) ),
    newDoc = new ve.dm.Document( ve.copyArray( data ) ),
    tx = new ve.dm.Transaction();
tx.pushRetain( 11 );
tx.pushReplaceMetadata( [], [ { metadata element here } ] );
tx.pushReplace( [] , [ 'a', 'b', 'c' ] );
ve.dm.TransactionProcessor.commit( newDoc, tx );
ve.dm.TransactionProcessor.rollback( newDoc, tx );

After running this, you'd expect oldDoc.metadata and newDoc.metadata to be equal, but they're not:

> oldDoc.metadata[11].length;
4
> newDoc.metadata[11].length;
5

When the transaction is rolled back, the metadata element that was added was never removed. I think this is because the content insertion pushes the metadata back, and then when the rollback tries to remove the metadata again, it can't find it. When the metadata replacement and content replacement are swapped, it works fine, so that's my workaround for now.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links