Page MenuHomePhabricator

[Regression pre-wmf.8] VE crashes while opening Gallery and some other dialogs
Closed, ResolvedPublic1 Estimated Story Points

Description

Gallery, Comment, Hieroglyphs, Musical notation, Chemical Formula, Math, Map, Code block, Graph these dialogs are not opening.

Media and Citation dialog are uneffected.

There is an error in the console:

Uncaught TypeError: Cannot read property 'val' of undefined (`this.$input`)
 at VeUiWhitespacePreservingTextInputWidget (OO.ui.InputWidget) .setValue
 at new VeUiWhitespacePreservingTextInputWidget
 at VeUiMWGalleryDialog.initialize

Uncaught TypeError: Cannot read property 'setWhitespace' of null (`this.input`)
 at VeUiMWGalleryDialog.<anonymous>

Event Timeline

Ryasmeen renamed this task from [Regression pre-wmf.8] Gallery and some other dialogs are not opening in VE to [Regression pre-wmf.8] VE crashes while opening Gallery and some other dialogs .Jun 29 2017, 9:56 PM
Ryasmeen updated the task description. (Show Details)
DLynch subscribed.

Seems to be fallout from 1eb25592c removing multiline support from TextInputWidget. Only landed in OOui in 0.22.2, so it's only been visible in VE since 52e9cc34 on the 29th.

Also, I don't think that's quite the standard meaning of "deprecating change", insofar as it outright broke the functionality...

Change 363034 had a related patch set uploaded (by DLynch; owner: DLynch):
[VisualEditor/VisualEditor@master] ui.WhitespacePreservingTextInputWidget: inherit from MultilineTextInputWidget

https://gerrit.wikimedia.org/r/363034

Deskana moved this task from To Triage to TR0: Interrupt on the VisualEditor board.

Change 363034 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] ui.WhitespacePreservingTextInputWidget: inherit from MultilineTextInputWidget

https://gerrit.wikimedia.org/r/363034

Change 363036 had a related patch set uploaded (by Jforrester; owner: DLynch):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (65ea4cf36)

https://gerrit.wikimedia.org/r/363036

Change 363036 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (65ea4cf36)

https://gerrit.wikimedia.org/r/363036

To elaborate, I think the reason the deprecation didn't work is that it relied on returning a new OO.ui.MultilineTextInputWidget from TextInputWidget's constructor, and our WhitespacePreservingTextInputWidget emphatically didn't expect this (technically valid but unusual) possibility. As such, the widget we created effectively never had the parent constructor run on it, and all the expected properties were therefore missing.

Hmm, I suppose we never tested this magical deprecation with custom subclasses.

I think by now this is spilled milk. But we should keep this in mind for the future and do any other deprecations the boring way (by just keeping all the old code in place, unchanged).

Change 363095 had a related patch set uploaded (by DLynch; owner: DLynch):
[mediawiki/extensions/VisualEditor@master] Custom TextInputWidgets: clean up unneeded multiline config

https://gerrit.wikimedia.org/r/363095

Change 363095 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] TextInputWidgets: update for deprecated multiline behavior

https://gerrit.wikimedia.org/r/363095

Hmm, I suppose we never tested this magical deprecation with custom subclasses.

I think by now this is spilled milk. But we should keep this in mind for the future and do any other deprecations the boring way (by just keeping all the old code in place, unchanged).

Just wondering (I don't have the time now to look that strange stuff up in the specification): What would happen if instead of return new TheNewConstructor() you'd use this = new TheNewConstructor()? Does this even work, and will it make inheritance work as expected?

Answering my own question: No, this is not possible, this is read-only. So I don't think the magic way would have worked even with more magic. One of the problems is the fact, that the prototype chain is just wrong, which would require the constructor to change the prototype of the object it is currently creating, which would be a huge mess.
I think a good basic rule for the future is: "Never return anything from a constructor, it will break inheritance."

@Schnark: I actually did a little bit of looking into changing the prototype on the returned object, and I sadly realized it's impossible in IE10, which has neither Object.setPrototypeOf nor __proto__. If not for that it'd be workable, albeit horrific. (Though admittedly I didn't confirm that it wouldn't do something weird mid-constructor.)