If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Switching to "Private Browsing" halts active add-on updater downloads

RESOLVED FIXED in Firefox 3.6a1

Status

()

Firefox
Private Browsing
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Adam Backstrom, Assigned: Ehsan)

Tracking

({verified1.9.1})

3.5 Branch
Firefox 3.6a1
verified1.9.1
Points:
---

Firefox Tracking Flags

(status1.9.1 .4-fixed)

Details

(Whiteboard: [fixed by bug 496335])

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 FirePHP/0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 FirePHP/0.3

This morning I manually ran "Find Updates" from the Add-ons dialog. While add-ons were updating, I switched to Private Browsing mode. When I went back to the Add-ons window minutes later, the download progress bar for YSlow was stationary. I would assume that the switch to Private Browsing terminated that specific HTTP connection. The download does not continue after Private Browsing is disabled.

I was able to duplicate this bug after restarting Firefox.

Reproducible: Always

Steps to Reproduce:
1. "Install Updates" through the Add-ons "Find Updates" window
2. Enable Private Browsing when an add-on is downloading
Actual Results:  
The download will terminate.

Expected Results:  
The download should continue, or possibly resume when Private Browsing is disabled.
I will try to reproduce this. Ehsan - Was wondering if addons in progress should continue when the session is resumed.
(In reply to comment #1)
> I will try to reproduce this. Ehsan - Was wondering if addons in progress
> should continue when the session is resumed.

They should if they use the download manager API.  CCing the QA address of the add-ons component to ask the add-on manager gurus to weigh in.
Component: General → Private Browsing
QA Contact: general → private.browsing
Version: unspecified → 3.5 Branch
(In reply to comment #2)
> (In reply to comment #1)
> > I will try to reproduce this. Ehsan - Was wondering if addons in progress
> > should continue when the session is resumed.
> 
> They should if they use the download manager API.  CCing the QA address of the
> add-ons component to ask the add-on manager gurus to weigh in.

Add-on installs do not use the download manager API. In essence they just use a regular HTTP channel.
(In reply to comment #3)
> Add-on installs do not use the download manager API. In essence they just use a
> regular HTTP channel.

Are these connections properly resumed after for example going offline and online again?
(Reporter)

Comment 5

8 years ago
An informal test by myself seems to say, "no." I have a download that is sitting partially downloaded ("Waiting") after disconnecting my wireless connection during add-on updating.
(In reply to comment #4)
> (In reply to comment #3)
> > Add-on installs do not use the download manager API. In essence they just use a
> > regular HTTP channel.
> 
> Are these connections properly resumed after for example going offline and
> online again?

Add-on installs should be cancelled when going offline, the user should be prompted to check that they really want to go offline when downloads are in progress (assuming offline-requested is dispatched before going offline).
(In reply to comment #6)
> Add-on installs should be cancelled when going offline, the user should be
> prompted to check that they really want to go offline when downloads are in
> progress (assuming offline-requested is dispatched before going offline).

So, the same thing should happen when switching the private browsing mode.  This is what happens in download manager as well.
Assignee: nobody → ehsan.akhgari
Severity: minor → normal
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Created attachment 398916 [details] [diff] [review]
Patch (v1)
Attachment #398916 - Flags: review?(dtownsend)
Comment on attachment 398916 [details] [diff] [review]
Patch (v1)

I'm not sure why we need to cancel downloads in progress when going into private browsing but I don't think this will fix the bug, only ask the user if it is ok to do so. We need to also work out why the download isn't getting cancelled and removed from the UI.
Attachment #398916 - Flags: review?(dtownsend) → review-
FWIW I can't reproduce the behaviour in comment 0. When I switch to private browsing add-on installs continue to download and install with no issue.
(In reply to comment #10)
> FWIW I can't reproduce the behaviour in comment 0. When I switch to private
> browsing add-on installs continue to download and install with no issue.

You're right.  The reporter has been using Fx3.5.1.  This problem is caused by the fact that private browsing mode transitions used to reset Necko.  This is no longer the case with the fix to bug 496335, which has been available on 1.9.2 and 1.9.3, and will be available in Fx3.5.4.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Depends on: 496335
Resolution: --- → WORKSFORME
status1.9.1: --- → .4-fixed
Resolution: WORKSFORME → FIXED
Whiteboard: [fixed by bug 496335]
Target Milestone: --- → Firefox 3.6a1
I tested this using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20091001 Shiretoko/3.5.4pre and the addons do continue to download while in Private Browsing mode. I think we can mark this verified 1.9.1.
Keywords: verified1.9.1
You need to log in before you can comment on or make changes to this bug.