Looks like there might be a mixup of some internal API data being misinterpreted, presumably the JavaScript/JSON boolean false value finding its way through one too many layers:
e.g. at https://www.mediawiki.org/wiki/Talk:Development_policy
Description
Description
Related Objects
Related Objects
- Mentioned Here
- P9945 Flow talk page bug (T235134)
Event Timeline
Comment Actions
@Krinkle - false appears as a topic title when an anon user clicks in 'Start a new topic' field to create a new topic? I cannot reproduce the issue in mediawiki or testwiki.
Comment Actions
It was when opening the page and clicking on the first button. Refreshed several times and it was consistent.
But.. not anymore. Maybe 1.35-wmf.1 fixed it. Oh well. Thanks :)
Comment Actions
… and I can reproduce this consistently again today at https://www.mediawiki.org/wiki/Talk:Stable_interface_policy. Refreshed several times and
I've dumped the HTML source at P9945, in case it contains any clues that might disappear after some time.
There were no XHR requests under devtools/network.
There were no errors under devtools/console.
One thing I find particularly interesting is that when I open this in Chrome logged-out, it focusses the new topic automatically. The above screenshot is exactly how it opens initially. I haven't clicked anywhere to get there.
When logged-in in Chrome, or when logged-out in any other browser (Safari, Firefox) it loads normally, the new topic form does not open, and if I open it myself, it works fine.
 |  |
Comment Actions
I believe I found the cause in mw.flow.ui.NewTopicWidget.js
this.title = new OO.ui.TextInputWidget( { placeholder: mw.msg( 'flow-newtopic-start-placeholder' ), value: mw.storage.session.get( this.id + '/title' ) } );
mw.storage.session.get() returns string|null|false. Where if the store is accessible, strings are previously saved values, null is none. And if not accessible, it returns false.
Where null is ignored by TextInputWidget (in so far that it casts to empty string), false is not, and casts to "false".
The reason I can only produce this in my work Chrome profile where I'm not logged in (and fine in Safari/Firefox) is because in my main profile persistent storage is only granted to whitelisted websites. This means document.cookie === '' and localStorage/sessionStorage throw (which mw.storage turns into false). The bug would presumably also happen on Safari when in its private browsing mode, which behaves the same way as Chrome's "Cookies allowed by default: off" option.