https://bugzilla.wikimedia.org/show_bug.cgi?id=46138
Web browser: ---
Bug ID: 46138
Summary: VisualEditor: Transaction with replaceMetadata then
replace at the same offset doesn't rollback cleanly
Product: VisualEditor
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Technical Debt
Assignee: esand...@wikimedia.org
Reporter: roan.katt...@gmail.com
CC: jforres...@wikimedia.org, krinklem...@gmail.com,
tpars...@wikimedia.org
Classification: Unclassified
Mobile Platform: ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
