Closed Bug 1612529 Opened 4 years ago Closed 4 years ago

Document replace does not update textarea

Categories

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

72 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla74
Tracking Status
firefox74 --- verified

People

(Reporter: aruseni.magiku, Assigned: bzbarsky)

References

(Regression)

Details

(Keywords: parity-chrome, regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

  1. Open this page

    <!DOCTYPE html>
    <html>
    <head>
    <meta charset="utf-8">
    <title></title>
    </head>
    <body>
    <textarea>123</textarea>
    </body>
    </html>

  2. Change text in the textarea

  3. Run this code

    var doc = document.open('text/html'); doc.write('<!DOCTYPE html>\n<html>\n<head>\n<meta charset="utf-8">\n<title></title>\n</head>\n<body>\n<textarea>123</textarea>\n</body>\n</html>'); doc.close();

  4. Change text in the textarea again

  5. Run this code again

Actual results:

First replace of document: the textarea updates.

Second replace of document: the textarea remains unchanged.

Expected results:

When document is replaced, the textarea updates.

I can reproduce the issue on Nightly74.0a1 Windows10, but not on Chrome80 dev.

Component: Untriaged → DOM: Core & HTML
Keywords: parity-chrome
Product: Firefox → Core

As far as I've tested, no input event is fired at running the script that means that setUserInput is not used. So, it's restored without autocomplete etc. I guess cache does it?

Component: DOM: Core & HTML → Networking: Cache
Has Regression Range: --- → yes
Has STR: --- → yes
Regressed by: 1489308
Keywords: regression

State restoration is purely in the DOM not in cache.

We used to create a new SHEntry on document.open, so the new load did not have a layout history state. Now we don't do that, but should probably just clear the state out explicitly on document.open.

Assignee: nobody → bzbarsky
Status: UNCONFIRMED → NEW
Component: Networking: Cache → DOM: Core & HTML
Ever confirmed: true

Otherwise we're using state from the pre-open document for whatever content is
being written, which is not likely to be right.

Pushed by bzbarsky@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ec4e3e080c1c
document.open should clear form state from the SHEntry. r=smaug
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/21636 for changes under testing/web-platform/tests
Upstream PR was closed without merging
Pushed by bzbarsky@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3e3e0930d279
document.open should clear form state from the SHEntry. r=smaug
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
Upstream PR merged by moz-wptsync-bot
Flags: qe-verify+

Reproduced the initial issue on Nightly 74.0a1 (20200109094415).
Verified as fixed on Windows 10 x64, Ubuntu 18.04 and Mac OS X 10.15 using Firefox 74 beta 2 and the latest Nightly 75.0a1.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: