226483 - FB resets contents of TEXTAREA when the page finishes loading

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Jeremy Hetzler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

As a page is loading, FB allows you to start typing into a textarea as soon as
it appears. Then, when the page finishes loading, the textarea is reset to its
default contents, irreversibly destroying your changes.

This is a common occurrence over a dialup connection. I ran into it when
replying on a forum. If the page contains images, or is particularly long, or
there are other applications competing for bandwidth, it can take 15-20 seconds
to finish loading the page. By that time, I'm halfway through writing my reply.
Then it is summarily deleted, causing anger and frustration.

Reproducible: Always

Steps to Reproduce:
1. Start loading a long page with a textarea
2. Start typing in the textarea as the page is loading


Actual Results:  
3. When the page finishes loading, observe as fb obliterates your changes

Expected Results:  
Once I start typing in a textarea, fb should not mess with it. If it must reflow
the page, fine, but keep my textarea changes.

If this is impossible, disallowing typing into a textarea until the page is
finished loading would at least prevent data loss.

Comment 1

[Jesse Ruderman]

I can't reproduce this bug in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.6b) Gecko/20031116 Firebird/0.7+.

I tried with the following HTML in http://www.squarefree.com/htmledit/:

<textarea>Foo</textarea>
<img alt="Slow-loading image"
src="http://software.hixie.ch/utilities/cgi/test-tools/delayed-file?pause=2&mime=image/gif&text="
>

What pages do you see this bug on?

Comment 2

[Robert Mohr]

Reporter, can you give a URL for a testcase?  It could very well be that the
website uses JS to clear said textarea using onLoad().

Comment 3

[Jeremy Hetzler]

Attachment: Sample reply page. This page does not trigger the bug.

Thanks for the quick replies.

I see the bug on forums.somethingawful.com reply pages. The humor site
SomethingAwful has a web-based forum using JelSoft's vBulletin.

Attached please find a small sample SomethingAwful reply page. This particular
page does not trigger the bug, but it does show what the site's html looks
like. A quick grep did not reveal an onLoad routine, but there is some js in
there.

I am still trying to get the bug to trigger reliably. It appears more often on
longer, more complicated pages. (When replying to long threads, the forum
software includes the last few 40 or so replies in the reply page.)

On long pages, fb often "reflows" the page just as it finishes loading (I see
this on many sites). The partially-rendered page disappears, the window goes
blank, and then you are taken to the top of the page and it is displayed fully.
(Is "reflow" the right word?) Textarea contents are reset as part of this
process; this is the bug I am trying to describe.

I will continue trying to reproduce the bug.

Comment 4

[Jeremy Hetzler]

Attachment: Ctrl-shift-R on this page triggers the bug

THE GOOD NEWS
The attached page triggers the bug when I load it remotely. I have to use
ctrl-shift-r; ctrl-r does not always work.

The page load takes about 15 seconds total on my 56k connection. The textarea
is first rendered at about the four second mark, at which point it accepts
text. The reflow and textarea reset occurs at the very end.

I noticed something else during testing. The status bar reads "Waiting for
..."/"Transferring data from ..." for most of the load. Then, just before the
reflow, it reads "Stopped" for a moment. Then it reflows, and then it flashes
quickly through another couple of "Waiting"s and "Transferring"s before
printing "Done".

The url for the problem page (source attached) is
http://forums.somethingawful.com/newreply.php?s=&action=newreply&threadid=713003
. The url for the thread is
http://forums.somethingawful.com/showthread.php?s=&threadid=713003 .

THE BAD NEWS
It will be difficult for others to test, because posting on this forum requires
an account, which costs money. Loading the page locally does not ever cause the
bug (that is, there is no reflow).

I hope that this is still helpful.

Comment 5

[Jeremy Hetzler]

MORE GOOD NEWS

Loading the attachment from my last post
("http://bugzilla.mozilla.org/attachment.cgi?id=136152&action=view") does
trigger the bug reliably for me. Hopefully this will make it easier for others
to reproduce.

Comment 6

[Bob Firth]

> The attached page triggers the bug when I load it remotely. I have to use
> ctrl-shift-r; ctrl-r does not always work.

isn't ctrl-shift-R supposed to clear form fields? That is the behavious I expect
at least. That doesn't say anything about this bug, just that I don't think it
should be tested using ctrl-shift-R.

Do I understand this bug correctly? I think that what gets cleared is text
entered between displaying the textarea and when the page finishes loading and
is reflowed. If so, my internet is too fast for me to test this (usually a good
thing...)

This should be tested in mozilla too, I'd be surprised if this was a firebird
only issue. If the same problem occurs in mozilla then the product should be set
to Browser.

Comment 7

[Jeremy Hetzler]

> isn't ctrl-shift-R supposed to clear form fields? That is the behavious I expect
> at least. That doesn't say anything about this bug, just that I don't think it
> should be tested using ctrl-shift-R.

Ctrl-shift-R is listed as "Reload (override cache)" on this page:
http://www.texturizer.net/firebird/keyboard.html . I expect any reload to reset
form fields. However, note that the behavior is "start loading -> render empty
textarea -> begin typing -> textarea is reset". In other words, the problem is
not that the reload clears pre-existing text but that it deletes text entered
after the textarea has been rendered.

Also, the behavior reliably occurs on original page loads (as opposed to
reloads); that was where I originally observed it. Ctrl-shift-R is just a
convenient way to trigger it.

> Do I understand this bug correctly? I think that what gets cleared is text
> entered between displaying the textarea and when the page finishes loading and
> is reflowed.

That's exactly right.

> If so, my internet is too fast for me to test this (usually a good thing...)

Probably this is true for most users, and especially most developers, which is
why it hasn't been noticed before.

Comment 8

[Jeremy Hetzler]

I installed Mozilla-1.5, but was not able to get this behavior to trigger. So, I
created a new Firebird profile and tested that. Unfortunately, I can't get the
fresh profile to show the behavior either.

So, I guess until I can nail down the critical difference between my profile and
the new one, this bug isn't going anywhere. Thanks to everybody who made
suggestions and comments so far.

Comment 9

[Bob Firth]

Hi Jeremy,

it's quite common that a corrupt profile will mess up mozilla, in fact, if you
look at the instructions for reporting bugs at
http://texturizer.net/firebird/bugs.html you will see that a clean installation
with a fresh profile is the first step before reporting bugs. If you can find
out the difference it might help with this bug (e.g. if you have set a
preference that somehow messes up the page loading). This bug should probably be
resolved WORKSFORME, but you're welcome to keep it open as long as you are still
looking into it. :0)

bob