976385 - An event should be fired when textarea contents is kept on reload

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[André Hänsel]

Attachment: ff_test.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36

Steps to reproduce:

1. Open the attached file. (Or any page with a textarea and some event handler attached to it.)
2. Enter something in the textarea. "You entered n characters" will be updated.
3. Reload the page.


Actual results:

The textarea keeps its content. This is expected (see https://bugzilla.mozilla.org/show_bug.cgi?id=46845#c186).
However, it shows "You entered 0 characters" and I don't know of any way to make it work, no events seem to be fired on the textarea when the page reloads and its content is "filled in" again.


Expected results:

An event, be it onchange or some special event, should be fired so the appropriate scripts can run again.

Comment 1

[Manish Goregaokar [:manishearth]]

This is probably the responsibility of the developer -- to check whether or not a form has been pre-filled. 


But having such an event makes sense. Though I suspect that just checking the .value attribute on page load would work too, since the only time a textarea is filled on page load (without it being pre-filled by the HTML) is when the browser puts it there.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Interesting idea. Perhaps we could fire input + change events in case form restoration brings back
the old value. 

Masayuki, what do you think?

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Um, it might break some web pages. E.g., if an <input> element has JS implemented autocomplete and it suggests something from input event handler, non-focused <input> element may show the suggestions.

So, I think that firing input event on non-focused element is a bit risky.

Additionally, some web pages might use key events for detecting the timing of text change. Of course it's wrong approach. However, actually, I've seen such web sites. This means that we fix this bug only some web sites with firing specific events.

Comment 4

[(no longer active)]

(In reply to comment #3)
> Um, it might break some web pages. E.g., if an <input> element has JS
> implemented autocomplete and it suggests something from input event handler,
> non-focused <input> element may show the suggestions.
> 
> So, I think that firing input event on non-focused element is a bit risky.

Yeah agreed, this is super common in fact.

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.