1445644 - Input data is lost after session restore

Status: NEW

(Firefox :: Session Restore, defect, P3)

Description

[Emil Ghitta, QA [:emilghitta]]

Attachment: session restore iss.gif

[Affected versions]:
Firefox 52.7.0 esr(BuildId:20180307131617).
Firefox 59.0(BuildId:20180310025718).
Firefox 60.0b3(BuildId:20180312152746).
Firefox 61.0a1(BuildId:20180313100127).

[Affected platforms]:
Windows 10 64bit.
macOS 10.13.
Ubuntu 16.04 64bit.

[Steps to reproduce]:
Can be found in Bug 1030719 

OR:
1. Launch Firefox with a clean profile.
2. Access the following website: http://www-archive.mozilla.org/editor/midasdemo/.
3. Key in something.
4. Restart Firefox 

[Expected result]:
Inputted data is not lost.

[Actual result]:
Inputted data is lost.

[Regression range]:
This seems to be a regression since this issue isn't reproducible with a Nightly build from 2014-08-08.

I will get back with a regression range asap.

[Note]:

For more information regarding this issue please observe the attached screencast.

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=315321e5b7d6&tochange=a19de49dacb8

Suspect:
 63c1d07df69b	Tim Taubert — Bug 1023565 - Remove setTimeout() when restoring contentEditable values r=smacleod
 89a109796b8e	Tim Taubert — Bug 1124147 - Get rid of browser.__SS_restore_tab r=smacleod

Comment 2

[Emil Ghitta, QA [:emilghitta]]

Thank you Alice for helping me out with the regression!

Comment 3

[Alice0775 White]

I can confirm that reverting setTimeout thing to toolkit/modules/sessionstore/FormData.jsm in m-c fixes the regression.

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

Redirecting to Mike, who works on Session Restore these days.

Comment 5

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

Too late to fix in 59 but we can still take a patch for 61 and possibly 60.

Comment 6

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

Marking fix-optional for 64. We could still take a patch for 65, and if it's verified and doesn't seem risky, could still take fixes for 64 as well.

Comment 7

[Timea Cernea [:tbabos]]

Reproduced on latest Nightly 66.0a1 (2018-12-18) (64-bit)on Mac OS 10.14

Comment 8

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

Since this is triaged and has a priority set, marking this fix-optional to remove it from regression triage. 
Happy to still take a patch in nightly.

Comment 9

[Neha Kochar [:neha]]

Removing regression keyword since it has been wontfix since 52.

Comment 10

[Rares Doghi]

This issue still occurs in Firefox Nightly 68.0a1 (2019-05-05) on Ubuntu 18.04.

Comment 11

[ovidiu boca[:Ovidiu]]

Also reproducible on Mac OS X 10.14 with the latest FF Nightly 68.0aa1(2019-05-07).

Comment 12

[Timea Cernea [:tbabos]]

Reproducible on the latest Nightly 69. Marking it as affected.

Comment 13

[Alin Ilea]

Reproducible on latest Nightly 70.0a1 (2019-08-27) using Ubuntu 18.04.

Comment 14

[Alphan Chen [:alchen]]

I've investigated this symptom.

Update the finding:

1. The related codes are rewritten into C++ in bug 1497146. However, the issue is found from firefox-esr52. So it is not a regression by this rewritting.

2. (C++) current code
   https://searchfox.org/mozilla-central/source/toolkit/components/sessionstore/SessionStoreUtils.cpp#951
   (JSM) original code
   https://searchfox.org/mozilla-central/rev/6d38cefd3d9a8ffc130fa68ff17fe3bae4e45021/toolkit/modules/sessionstore/FormData.jsm#126

Before setting the innerHTML,

• (current) we will check if the document has "NODE_IS_EDITABLE" flag or not.
• (original) we will check if the designMode of the document is "on" or not.

3. The value can be restored if we remove the check for "NODE_IS_EDITABLE" flag.

Hi Peter and Mike,
any suggestion or comment?

Comment 15

[Peter Van der Beken [:peterv]]

I guess this case was why we had the timeout that bug 1023565 ended up removing. That was done to fix browser_formdata.js intermittent failures, so someone needs to figure out what exactly is happening.

Comment 16

[Mike de Boer [:mikedeboer]]

I agree with Peter in comment 15, but I don't know if it's entirely necessary to do a deep when we already know that re-adding the setTimeout will fix the issue. We'll get an intermittent failure in return, but that's a better state than failing to restore form data. Perhaps using something like await new Prromise(resolve => Services.tm.dispatchToMainThread(() => resolve())); instead of the clock would lower the chance of re-introducing that intermittent failure, even though it would surprise me. Try will tell, I guess.

Comment 17

[Release mgmt bot [:sylvestre / :calixte / :marco for bugbug]]

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

Comment 18

[Alin Ilea]

Reproducible on the latest Nightly 73.0a1 (2019-12-10). Marking it as affected.

Comment 19

[Augusto Pace]

I've seen this behavior on Windows 10 and Firefox version 74.0a1 (2020-01-13) (64-bit).

Comment 20

[Maria Berlinger [:mberlinger]]

Reproducible on the latest Beta 77.0b2. Marking it as affected.