Open Bug 1445644 Opened 6 years ago Updated 2 years ago

Input data is lost after session restore

Categories

(Firefox :: Session Restore, defect, P3)

defect

Tracking

()

Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- fix-optional
firefox66 --- fix-optional
firefox67 --- affected
firefox68 --- affected
firefox69 --- affected
firefox70 --- affected
firefox71 --- affected
firefox72 --- affected
firefox73 --- affected
firefox74 --- affected
firefox77 --- affected

People

(Reporter: emilghitta, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Attached image 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.
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
Thank you Alice for helping me out with the regression!
I can confirm that reverting setTimeout thing to toolkit/modules/sessionstore/FormData.jsm in m-c fixes the regression.
Blocks: 1023565
Flags: needinfo?(ttaubert)
Redirecting to Mike, who works on Session Restore these days.
Flags: needinfo?(ttaubert) → needinfo?(mdeboer)
Too late to fix in 59 but we can still take a patch for 61 and possibly 60.
Flags: needinfo?(mdeboer)
Priority: -- → P1
Priority: P1 → P3
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.
Reproduced on latest Nightly 66.0a1 (2018-12-18) (64-bit)on Mac OS 10.14
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.

Removing regression keyword since it has been wontfix since 52.

Keywords: regression

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

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

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

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

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.
  1. The value can be restored if we remove the check for "NODE_IS_EDITABLE" flag.

Hi Peter and Mike,
any suggestion or comment?

Flags: needinfo?(peterv)
Flags: needinfo?(mdeboer)

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.

Flags: needinfo?(peterv)

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.

Flags: needinfo?(mdeboer)

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

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

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

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

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 14 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dao+bmo)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: