207805 - Back Button -- Missing data

Status: RESOLVED DUPLICATE of bug 36843

(Bugzilla :: Bugzilla-General, defect)

Description

[mike_brown]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

I was filling in a bug report and had written a fairly large amount of
information, including some quite witty remarks (ahem)
I clicked submit and got a message saying I'd skipped the summary field and to
click BACK
I di so and found all the data had disappeared, requiring me to reenter it all
(minus the witticisms)

Reproducible: Always

Steps to Reproduce:
Fill the form without a field, sumbit, click BACK and reenter everything.
Actual Results:  
Data not retained

Expected Results:  
Data should be retained

Comment 1

[Bradley Baetz (:bbaetz)]

This is a browser bug, although I don't know of any bug in 1.3 which caused this.

Comment 2

[Dave Miller [:justdave]]

This was originally bug 163714 for Mozilla, but it was supposedly fixed 6 months
ago, and if it's been this long since it was fixed I'd suggest filing a new bug
(or moving this one to the Browser product) if you can reproduce this at will in
a current build.

The "workaround" for this for Bugzilla is bug 36843.

Comment 3

[Dave Miller [:justdave]]

*** Bug 208415 has been marked as a duplicate of this bug. ***

Comment 4

[Dave Miller [:justdave]]

*** Bug 208629 has been marked as a duplicate of this bug. ***

Comment 5

[Dave Miller [:justdave]]

Other possible (already fixed) Mozilla bugs:  bug 179020, bug 179330

If anyone knows a currently-open Mozilla bug for this, please post it here. 

Comment 6

[Steve Strassmann]

I can confirm this bug burns me all the time
in IE 6.0.26 on Windows XP, and bugzilla 2.16.2.

Comment 7

[Veda Larson Palmer]

I can confirm too that this burns me all the time on Internet Explorer 6.0.2800 
on Windows 2000 - it is definitely not a Mozilla-only problem.

I have observed that with the default cache setting in IE (Tools | Internet 
Options... | Connections | General | Temporary Internet Files | Settings... | 
Check for newer versions of stored pages | Automatically), the form values are 
kept if I hit the Back button within a few minutes of loading the form, but 
they are lost if it has been longer than that.  Of course that generally 
correlates with when I've spent more time filling out the form and looking up 
related information, which is infuriating!

Turning the cache setting to "Check for newer versions of stored pages | Never" 
causes the form values to be preserved no matter how old the page is, but that 
in turn causes a whole host of other problems with various web applications.

This is a dataloss problem and hence should be upgraded to critical with the 
dataloss keyword (as well as CONFIRMED).  If this is a bug in Internet 
Explorer, then please report it to Microsoft, or else give me evidence so that 
I can report it to them.

Thanks for your help.  Bugzilla is a great product and this pretty much the 
only thing that really, really bugs me about it (sorry, no pun intended ;).

Comment 8

[Veda Larson Palmer]

FYI, here an article from Microsoft about the behavior in IE:
http://support.microsoft.com/default.aspx?scid=kb;en-us;174550
Also, http://support.microsoft.com/default.aspx?scid=kb;en-us;199805

SYMPTOMS
If you fill out a form on a Web page, submit the form, and then click Back in 
Internet Explorer, the form may not be repopulated with the data you just 
entered.

CAUSE
The form is repopulated only if the following items are true:
- The Web page is not an HTTPS (or secure) Web page. 
- The page is cached to disk. 
- The page has not changed since you filled out the form.

STATUS
This behavior is by design.


By the way, I'd be happy if bug 36843 was implemented, but it is marked as an 
enhancement, and I still consider this to be a dataloss/critical bug.

Comment 9

[mike_brown]

(In reply to comment #8)
> FYI, here an article from Microsoft about the behavior in IE:
> http://support.microsoft.com/default.aspx?scid=kb;en-us;174550
> Also, http://support.microsoft.com/default.aspx?scid=kb;en-us;199805
> 

With respect, what's all this talk about IE?  The original post was about
Mozilla and, in particular, a problem with bugzilla forms.  If your comments
about how the web site is designed being a contributing factor are correct, then
we should focus on how the bugzilla process is to be changed to prevent the
problem -- yes??

Comment 10

[Veda Larson Palmer]

#@! - This just burned me again! (mistyped someone's email address on
the CC: list)

(In reply to comment #9)
> With respect, what's all this talk about IE?  The original post was about
> Mozilla and, in particular, a problem with bugzilla forms.  If your comments
> about how the web site is designed being a contributing factor are correct, 
then
> we should focus on how the bugzilla process is to be changed to prevent the
> problem -- yes??

I agree with you that this is about a problem with bugzilla forms, and
that we should focus on how the bugzilla process is to be changed to
prevent the problem.  I am just trying to point out that:

(1) This is not a Mozilla-specific problem.  Most of the discussion
here and in other bugs seems to imply that it is, and that fixing
Mozilla would fix this problem.  That's why I was describing the
behavior in IE, and how it is affected by the cache settings (e.g. in
the off chance that this could be fixed with HTML cache directives).
I was also trying to illustrate how I have exhausted the workarounds
that I can think of in IE.

(2) I consider this to be a critical/dataloss bug, and either it or
bug 36843 (which sounds like a great solution, but is currently
classified as a relatively low-priority enhancement) should
accordingly be upgraded to critical.

Comment 11

[Dave Miller [:justdave]]

There is nothing we can do from the client side to prevent this except to
implement bug 36843, so marking this as a dupe of that.

*** This bug has been marked as a duplicate of 36843 ***