1030719 - Input data are lost in the session restore twice

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect)

Description

[Alice0775 White]

Steps To Reproduce:
1. Open http://www-archive.mozilla.org/editor/midasdemo/
2. Key in something

3. Exit browser
4. Start Browser and restore previous session
   ---- data is restored as expected

5. Exit browser
6. Start Browser and restore previous session
   ---- data is lost, this is bug

Actual Results:
Input data are lost in the session restore twice

Expected Results:
Input data should not be lost in the session restore twice
Firefox26 works well.
Firefox27-Noghtly33.a01 is broken

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

Attachment: 0001-Bug-1030719-Properly-restore-form-data-for-contented.patch

Oops. Didn't work properly before either but it should be fine now.

Comment 2

[Steven MacLeod [:smacleod]]

Comment on attachment 8446534 [details] [diff] [review]
0001-Bug-1030719-Properly-restore-form-data-for-contented.patch

Review of attachment 8446534 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/integration/fx-team/rev/1d77b632bcd2

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/1d77b632bcd2

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8446534 [details] [diff] [review]
0001-Bug-1030719-Properly-restore-form-data-for-contented.patch

Approval Request Comment
[Feature/regressing bug #]: Bug 947212
[User impact if declined]: Form data for contenteditables will be lost after two Firefox restarts if the user doesn't modify the form data in between.
[Describe test coverage new/current, TBPL]: Covered by an automated test.
[Risks and why]: The fix itself is one-line change with some clean up and very safe. I don't consider this a bug that many users hit but for the sake of correctness it would be great to have this uplifted as the risk is very low.
[String/UUID change made/needed]: None.

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8446534 [details] [diff] [review]
0001-Bug-1030719-Properly-restore-form-data-for-contented.patch

Since it is not a critical issue, we have it for a while and beta 5 has been released, I will only accept it in aurora. It will wait for 32.

Comment 7

[Tim Taubert [:ttaubert] (inactive)]

Fair enough. Thanks!

https://hg.mozilla.org/releases/mozilla-aurora/rev/b435946629a0

Comment 8

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8446534 [details] [diff] [review]
0001-Bug-1030719-Properly-restore-form-data-for-contented.patch

I'm sure Sylvestre meant to + the Aurora nom. Cleaning that up now.

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

Oops, that's how I read it too. Sorry for being hasty.

Comment 10

[Paul Silaghi, QA [:pauly]]

Verified fixed FF 33.0a1 2014-07-21, Win 7 x64

Comment 11

[Teodora Vermesan (:TeoVermesan)]

Reproduced the issue on 2014-06-18 Nightly build, verified as fixed on Firefox 32 Beta 5 
(buildID: 20140807212602) under Windows 7 64bit, Mac OS X 10.9 and Ubuntu 64bit.

Comment 12

[Emil Ghitta, QA [:emilghitta]]

Hi Tim,

It seems that this issue is reproducible again (by following the steps in Comment 0) on Firefox 61.0a1 (BuildId:20180313100127) using Windows 10 64bit, macOS 10.13 and Ubuntu 16.04 64bit.

Should we file a new bug for this?

Thanks!

Comment 13

[Tim Taubert [:ttaubert] (inactive)]

Hey Emil,

(In reply to Emil Ghitta, QA [:emilghitta] from comment #12)
> It seems that this issue is reproducible again (by following the steps in
> Comment 0) on Firefox 61.0a1 (BuildId:20180313100127) using Windows 10
> 64bit, macOS 10.13 and Ubuntu 16.04 64bit.

We added tests for this issue, so I'd be a little surprised to see it resurface. But nothing's impossible of course ;)

> Should we file a new bug for this?

Yes, please. Thanks!