Page MenuHomePhabricator

[Regression wmf.11] Source and VE edit tabs have the word <undefined> appearing next to them for some users on enwiki (very old cached HTML/JS?)
Closed, ResolvedPublic8 Story Points

Description


The edit tabs now have the word <undefined> (including the chevrons) next to them. see image.
This appeared when logged-in on Chrome, but NOT on Safari (logged in, or logged out).

Event Timeline

Wittylama updated the task description. (Show Details)
Wittylama raised the priority of this task from to Needs Triage.
Wittylama added a project: VisualEditor.
Wittylama added a subscriber: Wittylama.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 29 2016, 8:32 PM

does it still show up if you try the page with uselang=qqx and then go back to normal?

That indeed fixed it. Don't know how or why...

Thanks to @Ijon for explaining to me that the instruction meant that needed to add "uselang=qqx" to the end of a wikipedia URL, and also to add a "?" before it.

Jdforrester-WMF renamed this task from Source and VE edit tabs have the word <undefined> appearing next to them to Source and VE edit tabs have the word <undefined> appearing next to them for some users on enwiki (very old cached HTML/JS?).
Jdforrester-WMF triaged this task as High priority.
Jdforrester-WMF set Security to None.
Jdforrester-WMF edited a custom field.
PamD added a comment.Jan 30 2016, 12:07 AM

An effect of this bug is that the tab bar jumps around distractingly if the window is below a certain width.

If I have the window set to a width of about 80% of my laptop screen or less (which I usually do as I find it easier to read and enables access to some of the desktop icons and gadgets such as clock and calendar), then the "Read", "Edit <Undefined>" and "Edit source <undefined>" tabs move constantly from side to side in a desperate attempt to display greater width than there is room for. The remaining tabs and the search box jump up and down, and the whole effect is very distracting.

I'm using Firefox and WIndows Vista.

I think there's some RL caching weirdness going on here. It's likely all related to https://gerrit.wikimedia.org/r/#/c/258357/6/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.init.js - somehow clients are getting the new TabMessages data (which lacks the appendix keys used in the first section) but old ve.init.mw.DesktopArticleTarget.init.js (which wrongly relies on them existing)?

As the cluster's been re-re-rolled back to wmf.10 this probably has gone away at least for the next day or so, but it's likely to be worse when we re-re-re-deploy it.

Change 267551 had a related patch set uploaded (by Alex Monk):
Re-add null appendix tab messages to extension.json

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

Krenair claimed this task.Jan 31 2016, 6:27 PM

Change 267552 had a related patch set uploaded (by Alex Monk):
Re-add null appendix tab messages to extension.json

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

Change 267551 merged by jenkins-bot:
Re-add null appendix tab messages to extension.json

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

Change 267552 merged by jenkins-bot:
Re-add null appendix tab messages to extension.json

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

Elitre added a subscriber: Elitre.Feb 1 2016, 12:20 PM
Jdforrester-WMF renamed this task from Source and VE edit tabs have the word <undefined> appearing next to them for some users on enwiki (very old cached HTML/JS?) to [Regression wmf.11] Source and VE edit tabs have the word <undefined> appearing next to them for some users on enwiki (very old cached HTML/JS?).Feb 1 2016, 3:52 PM
Jdforrester-WMF changed the task status from Open to Stalled.
Jdforrester-WMF removed a project: Patch-For-Review.

This is not fixed, but it should not appear in production when it rolls out in the next few hours/days. Leaving as 'stalled' for us to re-visit in a few weeks' time when the train isn't such a mess.

Krinkle removed a subscriber: Krinkle.Feb 2 2016, 2:51 AM
Krenair added a subscriber: Krinkle.Feb 9 2016, 5:05 PM

Krinkle, what do you think about the RL caching aspect of this?

Based on chatting with Krinkle on IRC, we should be able to revert the patch and deploy, and then touch ve.init.mw.DesktopArticleTarget.init.js and sync that.

Change 269457 had a related patch set uploaded (by Alex Monk):
Revert "Re-add null appendix tab messages to extension.json"

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

Change 269457 merged by jenkins-bot:
Revert "Re-add null appendix tab messages to extension.json"

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

Change 271172 had a related patch set uploaded (by Alex Monk):
Revert "Re-add null appendix tab messages to extension.json"

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

Change 271173 had a related patch set uploaded (by Alex Monk):
Revert "Re-add null appendix tab messages to extension.json"

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

Change 271172 merged by jenkins-bot:
Revert "Re-add null appendix tab messages to extension.json"

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

Change 271173 merged by jenkins-bot:
Revert "Re-add null appendix tab messages to extension.json"

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

Mentioned in SAL [2016-02-17T01:36:11Z] <krenair@tin> Synchronized php-1.27.0-wmf.13/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.init.js: touch - https://phabricator.wikimedia.org/T125249#2012068 (duration: 01m 31s)

Krenair closed this task as Resolved.Feb 17 2016, 1:56 AM

I believe everything is done here, hopefully. Please reopen it if you see more issues with <undefined> showing up like this. Theoretically it shouldn't happen, but then it shouldn't've happened before, so...