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

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect)

Description

[Adam Backstrom]

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.

Comment 1

[Marcia Knous [:marcia]]

I will try to reproduce this. Ehsan - Was wondering if addons in progress should continue when the session is resumed.

Comment 2

[(no longer active)]

(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.

Comment 3

[Dave Townsend [:mossop]]

(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.

Comment 4

[(no longer active)]

(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?

Comment 5

[Adam Backstrom]

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.

Comment 6

[Dave Townsend [:mossop]]

(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).

Comment 7

[(no longer active)]

(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.

Comment 8

[(no longer active)]

Attachment: Patch (v1)

Comment 9

[Dave Townsend [:mossop]]

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.

Comment 10

[Dave Townsend [:mossop]]

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.

Comment 11

[(no longer active)]

(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.

Comment 12

[Marcia Knous [:marcia]]

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.