Page MenuHomePhabricator

Font size changes, and then the editor crashes
Open, NormalPublic1 Story Points

Description

This may be a case of "Bad things happen when VisualEditor Converter and Parsoid disagree with each other".

Initial symptom: The font size changed in part of the editing window. See a screenshot at https://upload.wikimedia.org/wikipedia/commons/e/ef/Problem_WP_Editor.jpg

Then the editor seemed to crash.

Reported in great detail at https://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&oldid=167554917#R.C3.A4tselhaftes_Verhalten_des_2017-Quelltext-Editors (complete with console output) by @XanonymusX, who can help answer questions. He usually uses SRWare Iron on Win 10 Pro, but also tested this in &safemode=1 in Chrome and Microsoft Edge.

Event Timeline

Restricted Application added a project: VisualEditor. · View Herald TranscriptJul 25 2017, 4:57 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

To give a short summary of my usual steps (described in detail in German): it always happens when I want to delete an infobox at the beginning of an article which contains a photo. The moment I try to use the file name in a normal file embedding without the infobox code, the font changes and different problems can arise (there are some variations): sometimes the editor is completely blocked, one time making it even impossible to save (after a lot of editing in the article); sometimes it is not possible to write in some paragraphs (in those moments the Chrome console always warned about "Uncaught TypeError: Cannot read property 'getStore' of null" and similar); usually if I try to copy-paste some part of the source, I will not get back the part I have previously selected (mostly the code at the beginning of the article that I had previously deleted will always reappear somewhere). Looks like some deleted parts instead of vanishing are somehow hidden under other parts of the text.

I can't reproduce this, but hopefully the error the user saw in their console will help an engineer debug:

VM292:139 Uncaught TypeError: Cannot read property 'length' of null
    at Object.ve.adjacentDomPosition (eval at <anonymous> (load.php?debug=false&lang=de&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin…:4), <anonymous>:139:324)
Deskana triaged this task as Normal priority.Jul 25 2017, 7:12 PM
Deskana moved this task from To Triage to TR1: Releases on the VisualEditor board.

Just encountered the problem again in a different setting (and with less severe consequences)!

I overwrote Template:Erledigt (similar to e.g. Template:Done) at the end of a talk page in order to continue discussion by simply selecting the line ({{Erledigt|<signature>}}) and writing my new comment. When I looked at the preview I saw that the line with the template (which was obviously not visible anymore in the editor) had not vanished, but was put at the end of my newly added text; only the first character of the line (one bracket) had been canceled when I overwrote the line, the rest had apparently become invisible and hidden under the new text (similar to what had happened in my initial problem described above). Going back to the editor without saving, I could get back the "invisible" line by randomly clicking in other paragraphs of the discussion. Afterwards I could delete it and save my comment without problems.

I assume that the specific problem is related to an incorrect conversion of Template-code in the editor. Hope that helps.

Deskana set the point value for this task to 1.Oct 11 2017, 11:33 AM
ssastry added a subscriber: ssastry.

I am not sure this is Parsoid related. So, removing the Parsoid tag. Please re-add if there is more info indicating that this requires a Parsoid fix.

I hoped that resolving T185184 would fix this as well. But I can still reproduce the invisible wikitext parts at the beginning of any article that start with a template (infoboxes, usually). Just encountered another interesting case: initially, there were two different infoboxes at the beginning of the article, which I both deleted (by selecting single parts of them and overwriting the wikitext; it was this article: https://de.wikipedia.org/wiki/Zero_Assoluto). Then I used the backwards function of the editor, which eventually only brought back the first infobox. When using the preview, though, the other infobox was still there. Trying to reproduce it later, I managed to get various combinations of chaotic template wikitext, like

{[Datei:{Infobox Band

(combining a file link and an infobox header). It works as bad as before.

Esanders updated the task description. (Show Details)Wed, Nov 6, 2:17 PM