Last modified: 2014-10-16 00:11:31 UTC
Go to https://zh.m.wikipedia.org/wiki/宋任窮 and you will have #undefined appended to URL once page loads. Reproduced in desktop Chrome and FF. Probably has something to do with redirect handling.
Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/7kDNfITT
Change 164772 had a related patch set uploaded by Florianschmidtwelzow: Don't add #undefined as redirectHash https://gerrit.wikimedia.org/r/164772
Change 164772 merged by jenkins-bot: Don't add #undefined as redirectHash https://gerrit.wikimedia.org/r/164772
Change 166716 had a related patch set uploaded by Krinkle: Don't add #undefined as redirectHash https://gerrit.wikimedia.org/r/166716
*** Bug 72071 has been marked as a duplicate of this bug. ***
Please backport fixes for regressions like these. This has been in production for over a week! (In reply to Krinkle from comment #0) > https://en.m.wikipedia.org/wiki/Black_Peter > https://en.m.wikipedia.org/wiki/Black_Peter#undefined > > https://en.m.wikipedia.org/wiki/1550–1600_in_fashion > https://en.m.wikipedia.org/wiki/1550%E2%80%931600_in_fashion#undefined > > Also found loads of them on social media and other usages.
Mmm.. What is your criteria for backporting regressions Krinkle? We only lightning deploy when we have a serious problem - e.g. hitting servers, functionality broken. This is a hash... why would we backport this. Also note this didn't even work prior to the regression so it's not like we've taken away functionality on mobile.
Change 166716 merged by jenkins-bot: Don't add #undefined as redirectHash https://gerrit.wikimedia.org/r/166716
(In reply to Jon from comment #7) > Mmm.. What is your criteria for backporting regressions Krinkle? > We only lightning deploy when we have a serious problem - e.g. hitting > servers, functionality broken. > > This is a hash... why would we backport this. > My criteria for backporting is a superset of "it's a regression". Within regressions, none. Always. Why not? As for this particular bug: It affects the end user. It impacts urls people share. It looks unprofessional on us.
Krinkle I would suggest a productive way of taking this forward would be to start a wiki page highlighting what kinds of changes deserve lightning deploys. This wasn't a regression as this never used to work in mobile, it just happened the fix to make it work wasn't complete enough. I still think it wasn't worth a lightning deploy in this case. It looks unprofessional yes but in my opinion that just encourages us to write better code to avoid this sort of thing. Really we want daily deploys here :)
(In reply to Jon from comment #10) > Krinkle I would suggest a productive way of taking this forward would be to > start a wiki page highlighting what kinds of changes deserve lightning > deploys. > > This wasn't a regression as this never used to work in mobile, it just > happened the fix to make it work wasn't complete enough. > You're missing the point. The regression is that virtually every url people opened on mobile for the past 1-2 weeks resulted in an immediate javascript location.hash assignment to "undefined". Thus resulting in the bug as described, including urls as shared by browser and OS plugins, as well as plain select/copy/paste through all kinds of media.
Krinkle I understand you. I just don't agree with you that it warrants a lightning deploy. The URL still points to the same resource they wanted to share. We will just have to agree to disagree here.
