Page MenuHomePhabricator

Special:MovePage interface loses what it had in the new title field if you go to a new page and then come back to it
Closed, ResolvedPublic

Description

Sorry if the title is unclear. Basically when you are moving pages as an admin often you will be moving to a target title that already exists. When you do this, the move interface page will reload with a helpful note saying "The destination page "[X]" already exists. Do you want to delete it to make way for the move? (Check the edit history.)" In the new interface if you go to check the edit history and then go back to the move interface page the new title field becomes blank (the reason field and which boxes you've ticked stay as they are though). Considering this did not happen with the old interface and that other fields are able to retain the information that's been entered, I assume this is a problem with the new OOUI move interface and not on my end.

Event Timeline

Jenks24 raised the priority of this task from to Needs Triage.
Jenks24 updated the task description. (Show Details)
Jenks24 added subscribers: Jenks24, matmarex.

Might be related to the recent update to it where it was converted to use the OO-UI interface.

We replace the new title field with a JavaScript-enhanced one (that checks whether the title you're trying to input is valid) and I guess that confuses at least some browsers. Which one are you using?

I'll experiment with it.

I'm using Firefox 41.0 on Mac OSX Yosemite. Thanks for the quick response.

It seems my initial guess was wrong, I tried changing the code to avoid that and it did not help.

Then I realized that we use the autocomplete=off attribute on the text field (to disable browser's autocompletion, because we have our own), and that has the additional effect of preventing "form caching" when you navigate to other pages and hit "Back".

Further digging showed that actually both of these things are problematic, and uncovered a separate bug that also blocks fixing this.

Thanks for filing this bug, I think this work will really make the OOjs UI library more robust and I probably wouldn't have worked on it otherwise.

Change 243080 had a related patch set uploaded (by Bartosz Dziewoński):
mw.widgets.ComplexTitleInputWidget: Implement gatherPreInfuseState/restorePreInfuseState

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

Change 243081 had a related patch set uploaded (by Bartosz Dziewoński):
TextInputWidget: Remove 'autocomplete' attribute on page navigation

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

Change 243082 had a related patch set uploaded (by Bartosz Dziewoński):
Preserve DOM node of InputWidget's $input when infusing

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

matmarex triaged this task as Medium priority.Oct 3 2015, 5:06 PM

Change 243081 merged by jenkins-bot:
TextInputWidget: Remove 'autocomplete' attribute on page navigation

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

Change 244047 had a related patch set uploaded (by Cscott):
WIP: Preserve DOM node of InputWidget's $input when infusing.

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

Change 243082 merged by jenkins-bot:
Allow widgets to reuse parts of the DOM when infusing, use it for InputWidget's $input

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

Change 243080 merged by jenkins-bot:
mw.widgets.ComplexTitleInputWidget: Add infusion helpers

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

This issue has been fixed and the fix should be deployed to Wikimedia wikis next week (10-12 November) with MediaWiki 1.27.0-wmf.6, as per https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap. You can test it now at http://en.wikipedia.beta.wmflabs.org/.

Change 244047 abandoned by Bartosz Dziewoński:
WIP: Preserve DOM node of InputWidget's $input when infusing.

Reason:
Folded into https://gerrit.wikimedia.org/r/#/c/243082/ , thanks!

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