Don't prompt for updates when Firefox is in private browsing

RESOLVED WONTFIX

Status

()

Toolkit
Application Update
RESOLVED WONTFIX
7 years ago
8 months ago

People

(Reporter: Cww, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
Part of fixing session loss on updates (bug 685731)

To allow users to keep working and not have updates be as disruptive as they are, we shouldn't prompt for updates if the browser is in private browsing.  This means users don't lose everything they're currently on when they accept the update.

To address users who always run in private browsing and never restart Firefox (which should be a small usecase), set a max time (say, 24 hours) after which we prompt anyway, but with a warning saying that their session will be lost.
Component: Installer → Application Update
Product: Firefox → Toolkit
QA Contact: installer → application.update
As far as notifying the user that they should update, the update ui is only shown after 12 hours on releases and we will likely be changing that to 24 hours per bug 659181 which is more than adequate to solve the last part of comment #0.

I suspect the scenario where the user is shown the update ui is because we show the update ui when the user has to opt-in to the update (after a minute of idle time) which is due to incompatible add-ons or there being add-ons that will be disabled by the update.

Another option is to always prompt on restart with a warning specific to private browsing similar to the tab warning when session restore is turned off giving the user a chance to opt out of restarting. Then we wouldn't have to change or make more complicated any of the app update or other notifications. For example, this same problem exists when installing or updating an extension.

It would be helpful if the exact scenario where the user ends up with this ui displayed is confirmed.
(In reply to Robert Strong [:rstrong] (do not email) from comment #1)
> As far as notifying the user that they should update, the update ui is only
> shown after 12 hours on releases and we will likely be changing that to 24
> hours per bug 659181 which is more than adequate to solve the last part of
> comment #0.
For clarity:
As far as notifying the user that they should update
should be
As far as notifying the user that they should restart to update
(Reporter)

Comment 3

7 years ago
I'm not sure what you're asking for. As users see it, they're prompted to restart for an update in the middle of doing something in the browser, they agree and they lose their session.  I'm just hypothesizing that one cause is that they're in private browsing--and that seems like an easy thing to address.
I wanted to make sure it was for the restart case vs. any of the other cases. For the restart case the user can also restart due to installing an add-on as well so at this point I am leaning toward using a similar method as when restarting with tabs open as summarized in comment #1 which is actually easier than adding more cases to when the update prompts to restart especially across session.
Gavin, what do you think about just warning the user after they initiate a restart when in private browsing with the ability to opt-out of the restart?
(Reporter)

Comment 6

7 years ago
Hmm... good point.  I would guess that restart-for-update happens to the average user a lot more than restart-for-addon and it's all clustered so that's why we predominantly see restart-on-update.

Can you even install extensions in private browsing mode? That feels like it's leaking information somehow (although I guess I can't pinpoint why).

Also, if we do this, maybe we should also cover the case where you have Firefox set to delete history on exit with the same warning.
(In reply to Robert Strong [:rstrong] (do not email) from comment #5)
> Gavin, what do you think about just warning the user after they initiate a
> restart when in private browsing with the ability to opt-out of the restart?

Bug 679957's patch is adding that, I think.
We aren't likely to change anything for this bug. The new UI is much less intrusive and there is Bug 1365491 to make the message in this UI more concise for this case. Plus we don't prompt on release for something like 8 days now.
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.