Last modified: 2013-02-16 00:44:33 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 T44222, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 42222 - VisualEditor: Two replacements within the same transaction and the same paragraph cause change markers to be off
VisualEditor: Two replacements within the same transaction and the same parag...
Status: RESOLVED INVALID
Product: VisualEditor
Classification: Unclassified
Data Model (Other open bugs)
unspecified
All All
: Lowest major
: ---
Assigned To: Ed Sanders
:
Depends on: 45061
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-17 06:42 UTC by Roan Kattouw
Modified: 2013-02-16 00:44 UTC (History)
5 users (show)

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


Attachments

Description Roan Kattouw 2012-11-17 06:42:02 UTC
Test case:

+                       'removing then inserting a character': {
+                               'calls': [
+                                       ['pushRetain', 41],
+                                       ['pushReplace', ['i'], []],
+                                       ['pushReplace', [], ['j']]
+                               ],
+                               'expected': function ( data ) {
+                                       data[41] = 'j';
+                                       ve.setProp( data[37], 'internal', 'changed', 'content', 2 );
+                               }
                        }

This sets the second change marker on data[36]. This happens because the start offsets handled in TransactionProcessor.replace are translated using this.adjustment , but that glosses over the fact that not all adjustments captured in this.adjustment actually apply if the offset is before the cursor. Instead, we need some sort of offset translation. I tried using ve.dm.Transaction.translateOffset() but that doesn't seem to work out of the box very well.

I guess theoretically this might also be an issue with other uses of .start attributes in the replacement processor, but it hasn't led to issues so far.

Low prio because we currently don't generate transactions that trigger this case.
Comment 1 Ed Sanders 2013-02-16 00:44:33 UTC
With bug 45061 all change marker code has been removed.

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


Navigation
Links