Closed Bug 147322 Opened 22 years ago Closed 3 years ago

Text entered into a Form Text area is lost.

Categories

(Core :: Layout: Form Controls, defect, P5)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.3beta

People

(Reporter: andyhurst_uk, Assigned: john)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: dataloss, testcase) 

If I am entering text into a text area on a Form and I click the 'Back' or
'Forward' button or load another page and then return to the original page with
the Text area, the text I had inserted has disappeared. I tried this with
hotmail and yahoo mail.

Thanks
Andrew
Form Controls (or History ?)
Assignee: Matti → rods
Component: Browser-General → HTML Form Controls
QA Contact: imajes-qa → tpreston
Andrew, what build are you using?  Does it happen on this bug page?

Most often when this happens the site in question is doing it on purpose...
WFM Linux Rc3 -- this page: comment area

Hi, thanks for prompt feedback. I'm using Mozilla RC3 and I've just run my tests
again in Netscape 6 and the problem does not occur. I'm not using a tabbed
window either. The 'Additional Comments' box in which I'm typing now does not
show the same problem. This is strange is it not? Looking at the page source
from Yahoo mail (another one of my test pages that fails), the text area is
definitely in a form.
Here is the textaera declaration from the page source from hotmail: \<td
colspan=2 align="center"\>
\<textarea name="body" rows=15 cols=70 wrap="soft" style="width:600px"
tabindex="7" title="Type Message Text"\>
\</textarea\>
\</td\> (I've escaped the tags manually). And for Yahoo mail: \<textarea
name="Body" rows=15 cols=55 wrap=virtual\>\</textarea\>

Hope this helps. I've just tried a form on the BBC news website in the 'Talking
point' section. The problem does not occur here either. Also, I cleared my
history and cache.
Regards, Andrew
What does page info say about those hotmail/yahoo pages being cached or not?  I 
suspect those sites mark the pages no-cache or no-store or something and I 
recall that screwing with our form state restoration.
Thats right, the failing pages show (not cached) in page info. However, this
page I'm currently entering this comment into shows the same, yet it doesn't
have the problem.
jkeiser, if autocomplete is turned off by the page using whatever magic 
invocation does it, do we still do history form state restoration? 
I can now see that this is a sinister result of the assertions in bug 139568,
and the problem is that the nsContentList for the form controls is not yet
updated by the time we get in here.  It can be fixed with a
FlushPendingNotifications, but no one wants to see that happen--up up and away,
pageload times!
Assignee: rods → jkeiser
Status: UNCONFIRMED → NEW
Depends on: 139568
Ever confirmed: true
Status: NEW → ASSIGNED
I see this bug with build 2002083108 on Windows 98SE. It makes refining Bugzilla
queries a real pain. Marking dataloss, and nominating for catfood and Mozilla 1.2.
Keywords: dataloss, mozilla1.2, nsCatFood
Setting OS to All because it occurs on Windows and Linux.
OS: Linux → All
Blocks: 1.2a
is this the same as bug 163714? We really need these both fixed for 1.2alpha.
John, what do you think?
John, you mentioned on IRC that this might be fixed. Can you take another look
and help us get this off of our list with a WFM or a patch? Time is short on
1.2a and if this really is a problem we shouldn't ship it.
The Real Fix for this is going to be a long haul.  I will look and see if there
is a quick and dirty hack I can put in.
OK, this is moving to 1.2beta.
No longer blocks: 1.2a
Blocks: 140697
Priority: -- → P1
Target Milestone: --- → mozilla1.3beta
Reproduced using 1/03/03 branch build on Win XP
Keywords: testcase
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
*** Bug 190392 has been marked as a duplicate of this bug. ***
*** Bug 172713 has been marked as a duplicate of this bug. ***
Blocks: 252729
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
QA Contact: tpreston → layout.form-controls
Decreasing the priority as no update for the last 2 years on this bug.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage 
about the priority meaning.
Priority: P1 → P5
Pretty sure this got fixed for most simple cases when we changed state key generation a few years back, but whether it's fixed for hotmail in particular, hard to tell.  Someone with a hotmail account would need to test.

(In reply to Boris Zbarsky [:bzbarsky] from comment #20)

whether it's fixed for hotmail in
particular, hard to tell. Someone with a hotmail account would need to test.

I'll bet Hotmail and Yahoo Mail have been rewritten several times since this was filed, and I would bet they do server-side saving of draft messages these days, so the actual sites' behavior is probably irrelevant to the original report.

comment 4 has the actual content from the original affected versions of the sites, which seem to just be basic <textarea> fields. I just wrote a local testcase with a <textarea>, and I tried entering some content and then navigating, and then navigating back. The content I'd entered was successfully preserved through this.

So, I think we can call this WORKSFORME.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME

I still see this behavior on a daily basis using Firefox 84.0.2 on Windows 10. It's not limited to hotmail and yahoo. It's pretty much any form on any site.

Thanks Jerry -- cold you post steps to reproduce the issue that you're seeing?

(e.g. can you reproduce it here at Bugzilla, to have an easy testcase that we all have access to? If so, how? In my experience, this generally works properly, so I'm curious where it's still broken.)

Simple example: if I visit https://paste.mozilla.org/ , type in some text, and then click the "About" link at the top-right (to navigate away), and then press my browser's back-button, then the text is faithfully restored.

Flags: needinfo?(mozilla)

(In reply to Daniel Holbert [:dholbert] from comment #23)

Simple example: if I visit https://paste.mozilla.org/ , type in some text, and then click the "About" link at the top-right (to navigate away), and then press my browser's back-button, then the text is faithfully restored.

You're very unlikely to experience on a simple form like that. Every time I experience it involves longer forms with multiple fields, like filling out shipping and billing info for a purchase. Going back will have some of the form fields blank. It's difficult to test without spamming somebody's site. I will try to replicate it on bugzilla.

Flags: needinfo?(mozilla)

Thanks! Would you mind filing a new bug for your issue, when you do come up with steps to reproduce? (and please CC and/or "needinfo" me on the bug report, when you do; and feel free to mention the bug number here)

That'll make for an easier-to-follow bug. The original issue here, with <textarea> and other form fields just 100% losing their contents whenever the browser navigates, was a real problem that was fixed at some point in the past (in the time since this was filed for mozilla-suite 1.3beta where this bug was filed 19 years ago). :) Any remaining issues in this neighborhood are likely to be something more specific/nuanced that would merit a dedicated bug-report.

(In reply to Jerry Baker from comment #24)

I will try to replicate it on bugzilla.

(Also, worth noting: Bugzilla might be a bad place to try to replicate it, if you're suspecting there's a general issue here with form fields. Bugzilla seems to have added its own draft-comment-saving feature which is completely separate from Firefox's own basic form-field-preservation functionality. Plus, bugzilla.mozilla.org admins don't love people using Bugzilla for testing except when absolutely necessary. So: you might just make a note of what precisely happened, the next time you encounter this in the wild, and then see if there's a way you can validate your steps at that point?)

You need to log in before you can comment on or make changes to this bug.