Last modified: 2013-10-24 20:01:55 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 T56335, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 54335 - VisualEditor: Surface isn't updated properly for Language annotations
VisualEditor: Surface isn't updated properly for Language annotations
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
ContentEditable (Other open bugs)
unspecified
All All
: High normal
: VE-deploy-2013-10-24
Assigned To: Roan Kattouw
:
Depends on: 54675
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-19 16:10 UTC by Moriel Schottlender
Modified: 2013-10-24 20:01 UTC (History)
6 users (show)

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


Attachments

Description Moriel Schottlender 2013-09-19 16:10:33 UTC
This is extremely weird, and is relatively new, and I am at a loss.

Steps to reproduce:
1. Put cursor on some word in the article.
2. Select "More -> Language" in the toolbar
3. Click "Change Language" button in the widget
4. Choose any other language (for example, "Hebrew")
5. Close the inspector by clicking anywhere else.
6. Notice: The word is surrounded with a language span, but it has the initial en/ltr values instead of the chosen annotation.
7. Save the article.
8. Click on "Edit Source" --> the language span contains the *correct* annotation (he/rtl)

Expansion on that:
1. Repeat the above through step 6.
2. Select a separate word and annotate it with some random link.
3. Inspect the original language span -- *now* it's updated!

One more weirdness:
1. Repeat above through step 6.
2. Put the cursor back on that annotation, and open the inspector
3. Observe: While the surface shows the span as en/ltr, the inspector widget shows the correct annotation (hebrew/rtl)

This happens in master and in the live mediawiki.org version.



I've spent a while tracking what is wrong with the annotations, and they seem to be correct in the inspector itself. In the "onClose", the annotation is the correct he/rtl one, being then sent to AnnotationInspector onClose, and then to the SurfaceFragment for execution in the fragment.annotateContent( 'set', annotation )

That annotation (the final one that's sent to the fragment) is the *correct* annotation. And yet, somewhere along the way the update stops. 

I tried stepping into the code inside ve.ce.Surface onChange and the annotation remains the correct one. It then continues to ve.dm.Surface 'change' method where the annotation is still the correct one (he/rtl) 

And yet somewhere it doesn't update the surface.

Link Inspector seems to work properly, though, and both link and language inspector rely on AnnotationInspector, which makes me think there is an issue with Language specifically, or that perhaps something has changed with the definition that needs to be updated in the Language inspector.

I'm not sure if the problem is in the Language Inspector (though that seems a bit odd, since the annotation remains correct throughout) or somewhere in the process of updating (and that seems weird too since *links* are working fine).

I'm at a loss. Help is appreciated!
Comment 1 Moriel Schottlender 2013-09-20 01:57:03 UTC
The same also happens with Link annotation on MediaWiki.org and on Master.

Since the dataModel seems to change, and the problem *seems* to be in the ce.Surface not changing, I am in dire need of help. 

Based on advice from Roan, I've repeatedly checked the transaction history, and it shows a correct transaction on both meta/language annotation and link/mwInternal and link/mwExternal as it should, based on the annotation actions.

And yet, while the datamodel seems to be updated, the ce.Surface does not.
Comment 2 James Forrester 2013-10-24 20:01:55 UTC
This was fixed in Gerrit change #90957.

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


Navigation
Links