1565437 - Session restore doesn't restore issue title in Github issue form

Status: NEW

(Firefox :: Session Restore, defect, P3)

Description

[Dietrich Ayala (:dietrich)]

70.0a1 (2019-07-09) (64-bit) Mac OS X

1. Begin to create a new Github issue
2. Do not submit it
3. Restart browser

Expected: The data you'd entered so far is still there

Actual: All form data has been reset

Comment 1

[Dietrich Ayala (:dietrich)]

Looks like only the issue title was not restored - the comment part was there still.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:mikedeboer, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Dale Harvey (:daleharvey)]

Yeh this is weird, has a stable id, isnt dynamically generated, refresh reloads the title however you can see that it clears and repopulates in a way that the textarea doesnt, there is some js attached to the input but not immediately clear if thats whats breaking this.

Comment 4

[Dietrich Ayala (:dietrich)]

Maybe related, I've noticed this sequence as well:

1. submit comment on github issue
2. suspend tab
3. unsuspend tab

Expected: Page looks as if comment has been submitted (which it has)

Actual: Page looks as if comment is still being edited, and no yet been submitted

Mitigation: Reload page and it looks correct

Comment 5

[u608768]

This is happening because we skip collection for inputs with autocomplete=off: https://searchfox.org/mozilla-central/rev/4f05a46731c1f7f111ec7a41ce38a34594aa0d37/toolkit/components/sessionstore/SessionStoreUtils.cpp#761-763 (which the title input has).

This was added in bug 1280294 to avoid collecting passwords from type=password inputs which change to type=text to temporarily display the password.

Comment #0 works in Chrome though, so we should find other ways around this.

There was a suggestion in that bug to mark type=password inputs as tainted if they were ever type=password, so maybe we'll end up doing that:

(bug 1280294 comment #21)

Seems like a more robust way to fix this (without requiring sites to change
behavior, which is a losing game), would be to have a way to mark inputs as
tainted if they've ever been type=password.

EG:

0. start with <input type=text>
1. input.mozWasOnceAPassword === false
2. input.type = "password"
3. input.mozWasOnceAPassword === true
4. input.type = "color"
5. input.mozWasOnceAPassword === true

Obviously this would require a DOM change, but I should think it would be
trivial. Then session store (and form manager?) should decline to save input
that have been so tainted.