274399 - form content is lost when going back with history.back()

Status: RESOLVED INCOMPLETE

(Core :: Layout: Form Controls, defect)

Description

[Hadrien Nilsson]

- Go to the specifed url.
- Change the default values, input some text, check the box... then submit the
form. 
- In the new page displayed you will find a link which calls history.back().
Click on it.
- You are now again on the page with the form. All content was lost.

Do the same procedure again, but this time, use the « back » button of your
browser (either Seamonkey or Firefox). This time the form content is kept.

IE and Opera work consistently when using history.back() or when hitting the
back button : they both keep the form content.

Comment 1

[Hadrien Nilsson]

Oops, the new bugzilla does not catch my user agent string. It's the latest
nightly build, here your are :

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041212

Comment 2

[Ray Papworth]

Does what Hadrien says with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041229
Firefox/1.0+

After playing with it a few times there are several "Select an item" entries in
the drop-down from the back button, each with different content, but only one
entry in the history list which goes back to the empty form.

Possible that it is a deliberate feature?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> - You are now again on the page with the form.

Actually, no, I am not.  I'm still on the page with the link, in a current trunk
build...

The reason, of course, is that the page starts the back(), then tries to load
'#', which cancels the back() altogether.  Try returning false from the onclick
handler?

Comment 4

[Hadrien Nilsson]

When returning false in the onclick handler, the form content is kept.

> I'm still on the page with the link, in a current trunk build...

This sounds more logical than going back and getting an empty form as seen in
preivous builds. I like this behaviour.

I would set this bug to FIXED, unless a behaviour copy of IE or Opera is wanted.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm... we could try to do IE's or Opera's behavior, but it'd be nontrivial.  The
basic problem is that by the time the scroll to '#' (off an event) is being
processed, we have started the load from history and our URI is no longer the
URI of the page that the anchor was on (so we end up not just scrolling, but
actually reloading the form result page).

Even doing the history back off an event wouldn't help, since that event would
be posted first....

So then the question is how important compat in this case is.

Comment 6

[Bob Clary [:bc] (inactive)]

MSIE appears to special case the "#" URI. It ignores the return value of the
onclick handler in that case defaulting to false. If you change the URI to
http://www.mozilla.org/, then MSIE on window.history.back() will visit
www.mozilla.org if a) return true, or b) no return and if return false will
return to the form with fields populated.

Opera 8 appears to be consistent: it always ignores the href regardless of the
return value.

I don't have any data on how common this behavior is but considering MSIE does
this on purpose it _might_ be fairly common.

Comment 7

[Boris Zbarsky [:bzbarsky]]

What about '#foo' instead of '#' in MSIE?

Comment 8

[Bob Clary [:bc] (inactive)]

same as #

Comment 9

[Boris Zbarsky [:bzbarsky]]

So most likely all that happens in IE is that scrolling to anchors is sync,
while history.back() is async, as is loading of new pages...

In Mozilla, it's the opposite.  In Opera, I don't know.

Given the variety of behavior here, and the fact that I've never seen a bug on
this before, I'd suggest wontfix or worksforme or whatever is appropriate in
this situation.

Comment 10

[jag (Peter Annema)]

I copied the testcase and added return false to the onclick, and don't see the original complaint. Both with bfcache turned on and off, when clicking the "Go back" link the form's values are still there. This is with build 2005110908 on Windows.

Comment 11

[Magnus Melin [:mkmelin]]

I can reproduce this on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b2) Gecko/20060905 BonEcho/2.0b2 ID:2006090504 when bfcache is turned off.

Not a problem with bfcache enabled though.

Comment 12

[Jesse Ruderman]

Dup of bug 348857?

Comment 13

[Daniel Ovsiannikov]

Am I the only one who noticed this regression after moving from 2.0 to 3.0?

Comment 14

[Boris Zbarsky [:bzbarsky]]

> Am I the only one who noticed this regression after moving from 2.0 to 3.0?

This bug was filed before 1.5 was released.  So whatever you're seeing that's changed from 2.0 to 3.0 is a different bug.

Comment 15

[Mats Palmgren (inactive)]

The test at the URL works for me in Firefox 38.0.1 on Linux64.

Can anyone else reproduce the problem in a recent version?

Comment 16

[Phoenix]

Resolved per whiteboard