Last modified: 2012-04-19 21:22:14 UTC
(From [[WP:VPT]]) [Firefox browser 3.6.x under various operating systems, Monobook skin.] While editing, I am accustomed to being able to go to a new browser destination in the open tab, then use the back button to return to the open edit window to resume my work. I am accustomed to doing the same thing when I encounter an edit conflict or error message after pushing "Save Page" (that is, I return to the previous page in the history to retrieve my work). With the advent of 1.18, this behavior has changed, After seeing the edit conflict message or a message prompting me to add an edit summary, if I step back into the history using the back button, the edit window reverts to its condition before I started my edit. I have not tested every possible variation of this situation, but I have replicated it with the edit conflict error and with he "no summary" message, and I think I've seen it in other situations. It's annoying, as I have become very accustomed to the old behavior!
https://en.wikipedia.org/w/index.php?diff=&oldid=454283976 Sounds very similar: Argh! For years, I would edit a page, click "Preview", and click a link in the text I just typed to make sure it didn't go to a disambig page or the wrong page; or would research a little more on the topic of the link; then I would click my browser's "Back" button until I was back on the editing page. This all worked until today! My editing changes are lost when I get back to the editing page, as though I had *just* clicked the "edit" link in the section header and had not done any typing yet. What changed? and Thanks, I was about to report this same issue! The crazy thing is, it's intermittent. I just edited '''Parentheses pipe shortcut doesn't work in <nowiki><ref></nowiki>''' above, and went to Show preview and back many times and never lost anything, but in editing other articles, I've found myself in Comet Tuttle's situation several times in the past day or two.
This sounds like standard Firefox behavior when confronted with changing a form element's sub-elements. Firefox (most versions I've tried, possibly not the newer ones though) remembers form content with linear navigation based on form element position, and if a javascript action comes in and changes the form elements, these can get screwed up. A simple test is to disable javascript briefly and try it. If this fixes it then it is most likely something adding elements to the edit form above the textarea. Try it logged out with JS on. If this fixes it, try disabling userscripts and gadgets and any enhanced editing options, and switching skins. Report what works and what doesn't. This information should help script maintainers debug the situation.
Looks like the {{cite}} button on the old toolbar might be to blame.
tagging bugs for Marcus to look at
Can confirm that this happens on en.wikipedia.org for me with new toolbar disabled, and doesn't happen there for me with new toolbar enabled. The old-style cite toolbar that's custom on en.wikipedia.org does indeed appear to add a whole bunch of form elements, which are initially hidden. Navigating away and back also re-hides all those form elements, indicating that it's not actually preserving the page state, but is simply saving form field contents and re-applying them after reloading the original state of the page... If it's restoring the form field contents early, that'll kill ya.
I can reproduce this problem locally only with the legacyRefToolBar js in use.
I think i now fixed legacyreftoolbar.
(In reply to comment #7) > I think i now fixed legacyreftoolbar. Brion, can you reproduce this still?
