Closed Bug 1388611 Opened 7 years ago Closed 7 years ago

Refresh loses recent sqlite changes in the WAL and fails doing a consecutive Refresh

Categories

(Firefox :: Migration, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 57
Tracking Status
firefox-esr52 --- fixed
firefox55 blocking wontfix
firefox56 + verified
firefox57 + verified

People

(Reporter: asa, Assigned: MattN)

References

Details

(Keywords: regression)

Attachments

(2 files)

Reported on Twitter https://twitter.com/dietrich/status/895124003345416192 refreshing Firefox is failing with user data lost. 

"Thanks @firefox for totally F'ing me. Suggested I restore browser for faster performance. Wipes out all bookmarks & history. Backup error."
Couldn't reproduce on Mac OS X with clean profile and a few bookmarks. IIRC we've had this type of problem mostly on Windows though. Would be great to have more info from the person.
This also failed for me yesterday morning on Windows 10.  I managed to get my profile back from CrashPlan, and hand-edited my profiles.ini file, but obviously that's not a great solution.
Is there any logging we could request from the user that might shed some light on what happened here?
Flags: needinfo?(MattN+bmo)
The Browser Console is where we would find relevant info. I think there may be two issues here:
1) Refresh not working
2) The dialog in the tweet

Blake, which of the two did you see? Can you provide Browser Console logs or STR?
Flags: needinfo?(MattN+bmo) → needinfo?(bwinton)
I saw refresh not working, not the dialog.  And I don't have any browser console logs, sadly.  STR was "update Firefox to latest nightly, when it offers to refresh your profile, click 'yes'."
Flags: needinfo?(bwinton)
* Was this a profile you hadn't used in 60 days? The old profile notification bar only shows up after 60 days. Or was it some other UI?
* How did you know what Refresh didn't work?
** Did you check data types other than history/bookmarks? See the Firefox column at https://wiki.mozilla.org/QA/Firefox_migrators#Supported_data_types
* Which OS are you on?

I wouldn't be surprised if this was related to bug 1388584 but that depends on whether it's just bookmarks+history being lost.
Flags: needinfo?(bwinton)
It was the profile I was using that morning when I clicked the "upgrade" button.

I don't know whether refresh worked or not, but after refreshing, I had none of my open windows or tabs, which was… unexpected.

I don't remember whether my add-ons came across, sorry!

Windows 10 Pro, v1703, 64-bit.

Oh, and I believe it wasn't a bar, it was a separate popup window…  But I could be misremembering.
Flags: needinfo?(bwinton)
> Status (NEW bug found in Firefox 57 with no priority)

_Is_ that 57 at <https://twitter.com/dpnation/status/895110349497741313>?
Probably 54 or 55
During triage, it was asked that we try to reproduce this scenario. Andrei can your team help?
Flags: needinfo?(andrei.vaida)
See Also: → 1391008
Not much actionable info here, not going to happen for 55.
Investigated this issue on 57.0a1 (2017-08-24), 56.0b5 build1 (20170821193225) and  55.0.3 build1 (20170821144629) using Windows 10 x64, Ubuntu 16.04 x64 and Mac OS X 10.11.6, trying different refreshing scenarios, but just one of them was partially successful - I managed to break the refresh process and get a "clone" profile that has lost the user bookmarks and history, following these steps: 
1. Launch Firefox with a dirty profile (e.g. https://goo.gl/x7xXgS) (Or use a clean profile and then import the bookmarks and history from another browser) 
2. Go to about:support, click the "Restart with Add-ons Disabled..." button (from the Try Safe Mode section) and then choose the "Start in Safe Mode" option from the displayed dialog
 - inspect the bookmarks and the history after the browser restarts
3. Return to about:support and click the "Refresh Firefox..." button 
 - inspect the refreshing process
 - inspect the bookmarks and the history after the browser restarts

After the step 2, the browser is restarted and the bookmarks and the history are successfully restored. But after the step 3, the Import wizard is not displayed and the browser is not restarted. Reopening Firefox, a clone profile can be noticed in the profile manager (see https://goo.gl/Ez1Uv8). This has the bookmarks and the history lost. The initial profile is kept intact. 
I didn't manage to trigger the "Unable to process the backup file" error.
Flags: needinfo?(andrei.vaida)
We have a STR, updating the flag
Do we have any telemetry on this "Unable to process the backup file" error, or related data migration/refresh failures?  Is there something we can do to fix/mitigate those issues on release?
Flags: needinfo?(jaws)
Flags: needinfo?(dolske)
Flags: needinfo?(MattN+bmo)
This issue is the main blocker for our enabling updates fully on 55.
We don't have telemetry for the "Unable to process the backup file" error. It just means the bookmarks backup was somehow corrupt or unreadable. We need some samples of those backups to be able to tell something more precise. Also, we keep 15 of them, did all of them result corrupt? In the past this kind of problem indicated a completely broken but asymptomatic db.

I was also thinking of a possible theory about a more general problem, but should be verified. Firefox reset profile feature copies over sqlite files, but it doesn't copy their journals (.wal). If a new version does a schema migration, most of the migration data could be stored in the journal. If in the same session as the schema migration we copy the db without the journal, we may be creating an incoherency. Ideally nothing bad should happen since the whole transaction (including the schema version set) should be lost, but it may be safer to copy over the journals as well.

Thus, something to test is taking a Firefox 54 db, update to Firefox 55 and then immediately do a profile reset. Does this break things?
(In reply to Iulia Cristescu, QA [:JuliaC] from comment #12)
Thank Iulia,

> Investigated this issue on 57.0a1 (2017-08-24), 56.0b5 build1
> (20170821193225) and  55.0.3 build1 (20170821144629) using Windows 10 x64,
> Ubuntu 16.04 x64 and Mac OS X 10.11.6, trying different refreshing
> scenarios, but just one of them was partially successful - I managed to
> break the refresh process and get a "clone" profile that has lost the user
> bookmarks and history, following these steps: 

Are these steps 100% reproducible for you? I don't understand what you mean by "partially successful".

> 1. Launch Firefox with a dirty profile (e.g. https://goo.gl/x7xXgS) (Or use
> a clean profile and then import the bookmarks and history from another
> browser) 
> 2. Go to about:support, click the "Restart with Add-ons Disabled..." button
> (from the Try Safe Mode section) and then choose the "Start in Safe Mode"
> option from the displayed dialog
>  - inspect the bookmarks and the history after the browser restarts
> 3. Return to about:support and click the "Refresh Firefox..." button 
>  - inspect the refreshing process
>  - inspect the bookmarks and the history after the browser restarts
> 
> After the step 2, the browser is restarted and the bookmarks and the history
> are successfully restored.

Well they aren't really restored since safe mode just launches Firefox without extensions. Is the important part of the STR that you have to choose to Refresh from within Safe Mode?

> But after the step 3, the Import wizard is not
> displayed and the browser is not restarted.

Oh, so the Firefox window never opens? I was going to ask for Browser Console output but I guess you can't get that. Is firefox.exe still running? If not, was there a crash report in about:crashes? Can you run these STR with a debug build launched from the command line and attach the terminal/console output here.

> Reopening Firefox, a clone
> profile can be noticed in the profile manager (see https://goo.gl/Ez1Uv8).
> This has the bookmarks and the history lost. The initial profile is kept
> intact. 

And which one is the default after step 3 if the profile from step 1 is the default?

> I didn't manage to trigger the "Unable to process the backup file" error.

I think you need to open the Places Manager window via Show All Bookmarks or such to see that maybe.
Flags: needinfo?(iulia.cristescu)
(In reply to Julien Cristau [:jcristau] from comment #14)
> Do we have any telemetry on this "Unable to process the backup file" error,
> or related data migration/refresh failures?

We have telemetry on migrators including the Firefox migrator that Refresh uses but we don't yet have a dashboard, alert or query on migration errors. See https://sql.telemetry.mozilla.org/dashboard/fx_migration and probes with the FX_MIGRATION_ prefix. Bug 1214154 is the bug with context on the error rate queries that would be useful here.

>  Is there something we can do to fix/mitigate those issues on release?

We could stop offering Firefox Refresh via a hotfix add-on and SUMO until we figure out the cause.
Flags: needinfo?(jaws)
Flags: needinfo?(dolske)
Flags: needinfo?(MattN+bmo)
I was not able to reproduce any problem with the STR in comment 12. (OSX, current release Firefox) So I think we're still missing some key factor in reproducing... Blake, you mentioned having backups. Perhaps you could try temporarily restoring your old profile data (and old Firefox release), and try seeing if it happens again? [At which point we'll want to pester you more to see what the specific failure is.]


(In reply to Marco Bonardo [::mak] from comment #16)
> We don't have telemetry for the "Unable to process the backup file" error.
> It just means the bookmarks backup was somehow corrupt or unreadable.

We should split this off into a separate bug, and keep this one focused on the Refresh failing.

Refresh failing is a serious issue, and ideally shouldn't require any user interaction to get back to a good state. The "Unable to process backup file" appears to only result when a manual attempt to restore a backup bookmark file fails. 

But what you describe with WAL files does sound plausible as a factor here. (Although given the specific changes in FF54/55, are we sure this would result in all bookmarks+history disappearing?) A little odd that would result in Blake losing his sessionrestore data too, although maybe something fails catastrophically and borks the entire migration/startup process...
Flags: needinfo?(bwinton)
Sadly, I don't have backups of the old profile data anymore, and it hasn't happened since.  :(
Flags: needinfo?(bwinton)
(In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking you) from comment #17)
> (In reply to Iulia Cristescu, QA [:JuliaC] from comment #12)
> Thank Iulia,
> 
> > Investigated this issue on 57.0a1 (2017-08-24), 56.0b5 build1
> > (20170821193225) and  55.0.3 build1 (20170821144629) using Windows 10 x64,
> > Ubuntu 16.04 x64 and Mac OS X 10.11.6, trying different refreshing
> > scenarios, but just one of them was partially successful - I managed to
> > break the refresh process and get a "clone" profile that has lost the user
> > bookmarks and history, following these steps: 
> 
> Are these steps 100% reproducible for you? I don't understand what you mean
> by "partially successful".

Yes, the steps are 100% reproducible for the mentioned builds. I mentioned above that I just managed to get a clone profile with lost bookmarks and history, but no "Unable to process the backup file" error. 

> 
> > 1. Launch Firefox with a dirty profile (e.g. https://goo.gl/x7xXgS) (Or use
> > a clean profile and then import the bookmarks and history from another
> > browser) 
> > 2. Go to about:support, click the "Restart with Add-ons Disabled..." button
> > (from the Try Safe Mode section) and then choose the "Start in Safe Mode"
> > option from the displayed dialog
> >  - inspect the bookmarks and the history after the browser restarts
> > 3. Return to about:support and click the "Refresh Firefox..." button 
> >  - inspect the refreshing process
> >  - inspect the bookmarks and the history after the browser restarts
> > 
> > After the step 2, the browser is restarted and the bookmarks and the history
> > are successfully restored.
> 
> Well they aren't really restored since safe mode just launches Firefox
> without extensions. Is the important part of the STR that you have to choose
> to Refresh from within Safe Mode?
> 

The bookmarks and the history are kept in Safe Mode, only the add-ons are disabled. Skipping the step 2 won't trigger anymore the clone profile creation and the bookmarks/history loss, so yes, this step is important. 

> > But after the step 3, the Import wizard is not
> > displayed and the browser is not restarted.
> 
> Oh, so the Firefox window never opens? I was going to ask for Browser
> Console output but I guess you can't get that. Is firefox.exe still running?
> If not, was there a crash report in about:crashes? Can you run these STR
> with a debug build launched from the command line and attach the
> terminal/console output here.
> 

Firefox never opens (the process disappears untill a manual restart). No crash reports generated after the clone profile creation. Reproduced the same scenario on Windows 10 x64, using the 55.0.3 (20170821144629) debug build. Here is the console output https://goo.gl/R4PH8j. 

> > Reopening Firefox, a clone
> > profile can be noticed in the profile manager (see https://goo.gl/Ez1Uv8).
> > This has the bookmarks and the history lost. The initial profile is kept
> > intact. 
> 
> And which one is the default after step 3 if the profile from step 1 is the
> default?
> 

I don't understand what are you meaning by "default"? The clone profile created after step 3 has the same name like the default one (created in step 1), but with a string of numbers added at the end (e.g. from my example, the "571" profile is the default one, created in step 1 and the "571-(string of numbers)" is the clone profile, created after step 3). 

> > I didn't manage to trigger the "Unable to process the backup file" error.
> 
> I think you need to open the Places Manager window via Show All Bookmarks or
> such to see that maybe.

Also opened the Library (via Show all bookmarks/Show all history command), but the error is not triggered.
Flags: needinfo?(iulia.cristescu)
(In reply to Iulia Cristescu, QA [:JuliaC] from comment #21)
> (In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking
> you) from comment #17)
> > (In reply to Iulia Cristescu, QA [:JuliaC] from comment #12)
> > Oh, so the Firefox window never opens? I was going to ask for Browser
> > Console output but I guess you can't get that. Is firefox.exe still running?
> > If not, was there a crash report in about:crashes? Can you run these STR
> > with a debug build launched from the command line and attach the
> > terminal/console output here.
> > 
> 
> Firefox never opens (the process disappears untill a manual restart). No
> crash reports generated after the clone profile creation. Reproduced the
> same scenario on Windows 10 x64, using the 55.0.3 (20170821144629) debug
> build. Here is the console output https://goo.gl/R4PH8j. 

I'm annotating this log file at https://docs.google.com/document/d/1FoBvv-9-ErmPLVpFoX1IDfv7v6WAaZipGWQLNE7XLa4/edit
Depends on: 1395333
Unfortunately I can't reproduce this on macOS 10.12.6 with the STR and dirty profile from comment 12.

(In reply to Iulia Cristescu, QA [:JuliaC] from comment #12)
> But after the step 3, the Import wizard is not displayed and the browser is not restarted.

Did you also not see the import wizard for the log[1] you attached on Windows 10? According to the logs the migration wizard dialog, then the reset cleanup dialog, then the browser window with about:welcomeback were all opened in that log as one would expect.

[1] https://docs.google.com/document/d/1FoBvv-9-ErmPLVpFoX1IDfv7v6WAaZipGWQLNE7XLa4/edit
Flags: needinfo?(iulia.cristescu)
Just an idea but bug 883627 landed in 54 and may be related.
Ok, after many trials, MattN and I are able to reproduce _almost_ the same problem.

Minimal STR:

1) firefox -P, create a new profile, launch Firefox with it.
2) about:support, Refresh Firefox
3) about:support, Refresh Firefox (again)

Entering Safe Mode is not needed. But the trick seems to be refreshing the same profile _twice_. Step 2 completes normally, but after Step 3 the browser appears to not reopen.

After this happens, you'll see a "profilename-#####-#####" entry in the profile manager in addition to the expected "profilename" entry. Looking at the directory for that profile, it's almost completely empty. [There's a compatibility.ini, crashes/, minidumps, and times.json]. So something has gone terribly wrong, the browser managed to start up and create a new profile, but seems to have given up immediately thereafter, before even trying to migrate anything.

However, what Matt and I are reproducing is a somewhat different problem than has been reported so far in this bug, because it's actually harmless and not something normal users would notice. When this happens, the old profile is still around and is still marked as the default profile. So despite the refresh failing, if you launch Firefox manually you'll be back in your normal Firefox profile, with all your data.

We're debugging this further, in hopes it sheds some light on the more serious problem/symptoms this bug is about.

But at the very least, this means we have a very unfortunate bug that causes a profile Refresh to only work once. :(
(In reply to Justin Dolske [:Dolske] from comment #25)

> But at the very least, this means we have a very unfortunate bug that causes
> a profile Refresh to only work once. :(

...not as serious as it sounds, as it turns out the Refresh failure only happens if you trigger the refresh again without restarting Firefox. So for most normal users this isn't going to be noticed, and isn't permafail.

I was also able to reproduce losing _recent_ bookmarks/history, which is most likely the WAL issue Marco described. Eg:

1) Bookmark foo.com
2) Quit Firefox
3) Bookmark bar.com
4) Refresh Firefox
5) In refreshed profile, foo.com is bookmarked but not bar.com.
Hey JuliaC, I have some more questions for now as you may be coming online in a bit:

A) Since what Dolske and I can reproduce may be a bit different than what you see and I haven't found the root cause yet due to complications debugging the new process after the restart, can you bisect to find approximately when this problem started? To start maybe trying different major revisions and see how far back the problem goes. You can bisect with normal non-debug builds.
 
B) Could you also include a screencast of your STR?

C) Could you share the profiles.ini file and new profile folder from immediately after step 3 (before re-launching Firefox)?

D) Could you provide a copy of the profile that you can repro with if it's different than the dirtyprofile.rar?

E) I may have already asked this but if you have saved passwords are they retained after the refresh? I'm wanting to understand if it's just bookmarks+history that are lost or all profile data.

Thanks a lot,
Matthew
The immediate cause of the 2nd reset failing is this line:

http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/toolkit/xre/nsAppRunner.cpp#4418

It's not finding the profile name specified by gResetOldProfileName. In my session, it was "test-####", when it should just be "test". Matt's going to poke a bit more tonight, but current best guess is that something is awry with the values being passed around in environment variables. (The "test-####" appears to be the legitimate name of the temporary profile from the first reset, but it gets renamed during the reset to the original name of the profile, "test").

When this fails, we immediately bail out from XRE_mainStartup(), and so the browser quits before it's really done much of anything.

Still not sure why QA's STR are not working for us, and the overall problem Matt and I are reproducing is a bit different. Would like to better understand that. The answers to comment 27 will help with that.
(In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking you) from comment #27)

> C) Could you share the profiles.ini file and new profile folder from
> immediately after step 3 (before re-launching Firefox)?

Just to expand on this, we want to see what data (if any) is being migrated to the new profile. If you're seeing mostly the same issue as us (as described in comment 28), the result is effectively a brand new profile with nothing at all migrated. But if you're seeing data partially migrated, that's going to be different, and examining the details of what data did get migrated may help pinpoint where the migration is failing.
(In reply to Matthew N. [:MattN] from comment #30)
> Created attachment 8903043 [details]
> Bug 1388611 - Update mProfileName after a profile reset to handle multiple
> consecutive resets.
> 
> Ensure `SaveWordToEnvIfUnset("XRE_PROFILE_NAME", mProfileName);` saves the
> updated profile name after reset takes the old profiles name.
> 
> Review commit: https://reviewboard.mozilla.org/r/174824/diff/#index_header
> See other reviews: https://reviewboard.mozilla.org/r/174824/

This is a fix for the problem Dolske and I are seeing but isn't necessarily what is affecting others in the wild since it seems like it's only fixing an edge case of two consecutive Resets.
Assignee: nobody → MattN+bmo
Status: NEW → ASSIGNED
(In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking you) from comment #31)
> This is a fix for the problem Dolske and I are seeing but isn't necessarily
> what is affecting others in the wild since it seems like it's only fixing an
> edge case of two consecutive Resets.

And it would be a follow-up to bug 1122124.
Blocks: 1122124
Hi again JuliaC, I did a try push of debug builds including the patch for the issue Dolske and I saw, plus a bunch of debug logging. It would be great if you could try to repro the issue with these debug builds and if you can repro, please include the terminal/console logs to help narrow down the cause. Thanks https://treeherder.mozilla.org/#/jobs?repo=try&revision=9f10d0493cd96fdc4cad90b4515119a130dabfd3
https://treeherder.mozilla.org/#/jobs?repo=try&revision=634114cf26628a453ebe72d9701bc8b3a8060019 has a new try push which includes the .sqlite-wal fix. JuliaC, you can use this build instead to see if it fixes the problems.
(In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking you) from comment #34)
> Hi again JuliaC, I did a try push of debug builds including the patch for
> the issue Dolske and I saw, plus a bunch of debug logging. It would be great
> if you could try to repro the issue with these debug builds and if you can
> repro, please include the terminal/console logs to help narrow down the
> cause. Thanks
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=9f10d0493cd96fdc4cad90b4515119a130dabfd3

Hello, Matthew! I will investigate again this issue in order to clarify comment 27 and comment 34.  Also, regarding the log I provided in comment 21, I forgot to mention that, this time (as you also noticed) the problem triggered after a second refresh (safe mode -> refresh -> refresh). Sorry, my mistake. 
Keep my ni until I will provide all the requested answers.
Comment on attachment 8903054 [details]
Bug 1388611 - Preserve .sqlite-wal files with a Firefox Reset.

https://reviewboard.mozilla.org/r/174828/#review179914

LGTM, thanks!
I can confirm signos.sqlite and formhistory.sqlite *for now* are using a DELETE journal, that means in most cases there's no journal file, since it's deleted after every transaction.
Attachment #8903054 - Flags: review?(mak77) → review+
(In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking you) from comment #36)
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=634114cf26628a453ebe72d9701bc8b3a8060019 has a new
> try push which includes the .sqlite-wal fix. JuliaC, you can use this build
> instead to see if it fixes the problems.

The builds provided in comment 36 seems to be busted. What builds should I use in order to verify the fix?
(In reply to Iulia Cristescu, QA [:JuliaC] from comment #39)
> The builds provided in comment 36 seems to be busted. What builds should I
> use in order to verify the fix?

The win2012 tc(B) builds are ok and the ones to use.
Win8 and winxp are failing on Try from some time (ERROR: Cannot find ccache), they should just not appear. Looks like it happens when specifying win32,win64 in the try syntax, those are old buildbot that should not run. See bug 1384706.
See Also: → 1395564
(In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking you) from comment #36)
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=634114cf26628a453ebe72d9701bc8b3a8060019 has a new
> try push which includes the .sqlite-wal fix. JuliaC, you can use this build
> instead to see if it fixes the problems.

Hello again, Matthew! It seems that this indeed fixes the problems. Tried different scenarios of (multiple) refresh (and/or safe mode restart), no clone profiles are created, the history, bookmarks and saved logins are kept and no related errors are kept.
Flags: needinfo?(iulia.cristescu)
Comment on attachment 8903043 [details]
Bug 1388611 - Update mProfileName after a profile reset to handle multiple consecutive resets.

https://reviewboard.mozilla.org/r/174824/#review180074
Attachment #8903043 - Flags: review?(dolske) → review+
(In reply to Iulia Cristescu, QA [:JuliaC] from comment #42)

> Tried to manually narrow down when this problem started and I can conclude
> that the first problematic build is 53.0a1 (2016-12-18) (when after the
> second refresh, a new profile named "default-#" is created, but it doesn't
> replace the previous created one). 
>
> Also reproduced the issue on 55.0.3 build2 (20170821144629) and gathered the
> information you previously requested [...]

Thanks for doing this.

It looks like you manually selected the broken profile ("alfa-####" in the Profile Manager) -- was this also what you were doing in earlier STR for this bug? I ask because the symptoms shown in your screencast match what MattN and I are seeing (c.f. comment 25), in that the old profile ("alfa") still exists and is still marked as the default (confirmed with your profiles.ini). So this bug as experienced by most end-users would be that the Refresh would simply fail to do anything, and upon manually relaunching the browser the user would be back in their normal un-refreshed profile, with no dataloss. There's an empty profile sitting around, but it wouldn't be noticed unless they launch the profile manager to look.


(In reply to Iulia Cristescu, QA [:JuliaC] from comment #41)

> Hello again, Matthew! It seems that this indeed fixes the problems. Tried
> different scenarios of (multiple) refresh (and/or safe mode restart), no
> clone profiles are created, the history, bookmarks and saved logins are kept
> and no related errors are kept.

Just to double-check, the original STR you have in comment 12 (just one refresh, right after Safe Mode) is no longer reproachable with the MattN's fix? I'm still a little confused why we haven't been able to reproduce with your original STR, but if this fix takes care of it, it seems likely it was the same problem.
Flags: needinfo?(iulia.cristescu)
Pushed by mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/2d2bb8bc3b2d
Update mProfileName after a profile reset to handle multiple consecutive resets. r=Dolske
https://hg.mozilla.org/integration/autoland/rev/25801e787df4
Preserve .sqlite-wal files with a Firefox Reset. r=mak
Comment on attachment 8903043 [details]
Bug 1388611 - Update mProfileName after a profile reset to handle multiple consecutive resets.

Approval Request Comment
[Feature/Bug causing the regression]: bug 1122124
[User impact if declined]: A Firefox Refresh in the same session after a previous Firefox Refresh will fail (Firefox won't reopen but manually re-opening Firefox will use the existing default profile with existing data).
[Is this code covered by automated tests?]: There is marionette test for Firefox Refresh but it didn't seem worthwhile to add a test case to confirm the edge case of two consecutive Refreshes.
[Has the fix been verified in Nightly?]: Not yet but already verified by QE in comment 41.
[Needs manual test from QE? If yes, steps to reproduce]: Already done in comment 41. 
[List of other uplifts needed for the feature/fix]: This is independent from the other commit in this bug but for tracking purposes it's probably easier to uplift both.
[Is the change risky?]: No
[Why is the change risky/not risky?]: obvious and trivial one-line change to update the cached profile name after Refresh renames it.
[String changes made/needed]: None
Attachment #8903043 - Flags: approval-mozilla-beta?
Summary: Refresh loses profile contents and fails with the error unable to process the backup file → Refresh loses recent sqlite changes in the WAL and fails doing a consecutive Refresh
(In reply to Justin Dolske [:Dolske] from comment #45)
> (In reply to Iulia Cristescu, QA [:JuliaC] from comment #42)
> 
> > Tried to manually narrow down when this problem started and I can conclude
> > that the first problematic build is 53.0a1 (2016-12-18) (when after the
> > second refresh, a new profile named "default-#" is created, but it doesn't
> > replace the previous created one). 
> >
> > Also reproduced the issue on 55.0.3 build2 (20170821144629) and gathered the
> > information you previously requested [...]
> 
> Thanks for doing this.
> 
> It looks like you manually selected the broken profile ("alfa-####" in the
> Profile Manager) -- was this also what you were doing in earlier STR for
> this bug? I ask because the symptoms shown in your screencast match what
> MattN and I are seeing (c.f. comment 25), in that the old profile ("alfa")
> still exists and is still marked as the default (confirmed with your
> profiles.ini). So this bug as experienced by most end-users would be that
> the Refresh would simply fail to do anything, and upon manually relaunching
> the browser the user would be back in their normal un-refreshed profile,
> with no dataloss. There's an empty profile sitting around, but it wouldn't
> be noticed unless they launch the profile manager to look.
> 
> Yes, indeed, I manually selected the broken (clone) profile, as the browser didn't automatically restarted after the second refresh. This step was also part of the earlier steps.

> (In reply to Iulia Cristescu, QA [:JuliaC] from comment #41)
> 
> > Hello again, Matthew! It seems that this indeed fixes the problems. Tried
> > different scenarios of (multiple) refresh (and/or safe mode restart), no
> > clone profiles are created, the history, bookmarks and saved logins are kept
> > and no related errors are kept.
> 
> Just to double-check, the original STR you have in comment 12 (just one
> refresh, right after Safe Mode) is no longer reproachable with the MattN's
> fix? I'm still a little confused why we haven't been able to reproduce with
> your original STR, but if this fix takes care of it, it seems likely it was
> the same problem.

Yes, indeed, neither the steps from comment 12 are no longer reproachable with MattN's fix. I am also confused as I didn't manage to reproduce anymore the problem using the initial steps (those with safe mode -> refresh).
Flags: needinfo?(iulia.cristescu)
Summary: Refresh loses recent sqlite changes in the WAL and fails doing a consecutive Refresh → Refresh loses profile contents and fails with the error unable to process the backup file
Comment on attachment 8903043 [details]
Bug 1388611 - Update mProfileName after a profile reset to handle multiple consecutive resets.

Let's take it to the next beta. Thanks!
Attachment #8903043 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Summary: Refresh loses profile contents and fails with the error unable to process the backup file → Refresh loses recent sqlite changes in the WAL and fails doing a consecutive Refresh
Sorry for the summary change from the comment 48 - it was due to a bugzilla conflict.
Comment on attachment 8903054 [details]
Bug 1388611 - Preserve .sqlite-wal files with a Firefox Reset.

Approval Request Comment
[Feature/Bug causing the regression]: Firefox Refresh doesn't preserve the sqlite WAL file for databases which use it. This has been an issue since Firefox Refresh was created and/or WAL files started to be used by us.
[User impact if declined]: Recent changes before a Refresh may be lost upon a Refresh
[Is this code covered by automated tests?]: There is a marionette test but it doesn't test WAL scenarios
[Has the fix been verified in Nightly?]: Not yet
[Needs manual test from QE? If yes, steps to reproduce]:  Done in comment 41
[List of other uplifts needed for the feature/fix]: This is independent from the other commit in this bug but for tracking purposes it's probably easier to uplift both.
[Is the change risky?]: Not really
[Why is the change risky/not risky?]: The change will only affect users who do a Firefox Refresh and from my reading of the SQLite documentation, the correct behaviour is to keep preserve the WAL files. There is a chance that preserving the WAL files will make a Refresh less effective or cause other brokenness though. 
[String changes made/needed]: None
Attachment #8903054 - Flags: approval-mozilla-beta?
After more investigation we're no longer blocking 55 updates on this issue.
Comment on attachment 8903054 [details]
Bug 1388611 - Preserve .sqlite-wal files with a Firefox Reset.

Seems worth taking on ESR52 as well since it'd be a trivial backport for an ugly dataloss situation. Note that the first patch only applies to 53+, so this request is for only the FirefoxProfileMigrator.js change.
Attachment #8903054 - Flags: approval-mozilla-esr52?
Comment on attachment 8903054 [details]
Bug 1388611 - Preserve .sqlite-wal files with a Firefox Reset.

Beta56+.
Attachment #8903054 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
Apart from the fact it was found while investigating this, there's no relation between an eventual dataloss and bug 1395333, thus removing the dependency.
No longer depends on: 1395333
Comment on attachment 8903054 [details]
Bug 1388611 - Preserve .sqlite-wal files with a Firefox Reset.

reliability fix for profile reset, esr52.4+
Attachment #8903054 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+
I can confirm that the initial issue is not reproducible anymore on 56.0b11 build1 (20170911193316), using Windows 10 x64, Ubuntu 16.04 x64 and macOS 10.12.6. Also based on the results from comment 41, I will mark this build as verified fixed.
Also confirm the fix on the latest Nightly build 57.0a1 (2017-09-13), using the above mentioned platforms. Leaving the qe-verify+ flag for the upcoming esr verification.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.