Download error -228 if you leave the add-on's public page before download completion

RESOLVED FIXED in mozilla1.9.2a1

Status

Core Graveyard
Installer: XPInstall Engine
P2
normal
RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: Thomas Goldstein, Assigned: mossop)

Tracking

({fixed1.9.0.9, fixed1.9.1, regression})

1.9.1 Branch
mozilla1.9.2a1
fixed1.9.0.9, fixed1.9.1, regression
Bug Flags:
blocking1.9.1 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090110 Shiretoko/3.1b3pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090110 Shiretoko/3.1b3pre (.NET CLR 3.5.30729)

For example, go to: https://addons.mozilla.org/en-US/firefox/addon/1865
Start the install, and then, while the download bar fills, go to another page (go back, or go to Google, whatever).
Result: the download will stop, and a "Download error" message box will pop up.

Reproducible: Always

Comment 1

9 years ago
because: Download error
-228

I can confirm this. Have to be quick on the trigger to click to another page if it you download fast, but it does error if I go to my homepage before getting to the end. (during download or "wait" period in the beginning) Tested in 3.1b3pre on Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All

Updated

9 years ago
Component: General → Add-ons Manager
Product: Firefox → Toolkit
QA Contact: general → add-ons.manager

Updated

9 years ago
Summary: Extension download is cut/interrupted if you leave the page → Download error -228 if you leave the add-on's public page before download completion

Comment 2

9 years ago
Not sure if this is on the add-ons manager end or the AMO end. Might also be a dupe, but I can't find one.

Comment 3

9 years ago
After a bit of testing in a new profile, I've been able to reproduce this in both 3.1b3pre and 3.2a1pre but not 3.0.5.
Seems to be something from last week November.
(In reply to comment #2)
> Not sure if this is on the add-ons manager end or the AMO end.

That sounds a lot like a client bug.
Regression range is http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-11-28+05%3A00%3A00&enddate=2008-11-28+21%3A00%3A00
There is a Bug 462739, a Bug 454546 and a Bug 463882. 
BTW, for some reason I need to delete the profile after every test.
Keywords: regression

Comment 7

9 years ago
(In reply to comment #6)
> BTW, for some reason I need to delete the profile after every test.

Odd, I had no such problem here.

Updated

9 years ago
Flags: blocking1.9.1?
Version: unspecified → 1.9.1 Branch
(In reply to comment #7)
> (In reply to comment #6)
> > BTW, for some reason I need to delete the profile after every test.
> 
> Odd, I had no such problem here.

Clicking Cancel on the dialog in a unaffected build gave a false negative in a affected build.
(Assignee)

Comment 9

9 years ago
Will backout bug 462739 to resolve this
Blocks: 462739
Component: Add-ons Manager → Installer: XPInstall Engine
Product: Toolkit → Core
QA Contact: add-ons.manager → xpi-engine
(Assignee)

Updated

9 years ago
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
(Assignee)

Updated

9 years ago
Assignee: nobody → dtownsend
(Assignee)

Comment 10

9 years ago
Actually have a potential fix for this, but still working on developing unit tests for it.
Status: NEW → ASSIGNED
(Assignee)

Comment 11

9 years ago
I don't think we need this for b3, but we'll probably want to relnote it if it isn't fixed by then.
Keywords: relnote
(Assignee)

Comment 12

9 years ago
Created attachment 359502 [details] [diff] [review]
patch rev 1

This patch works by removing the request from the page's load group once the request has begun. This is after any necessary cookies have been added to the headers so does not regress bug 462739, but means that when the page is navigated away from the load group will no longer cancel the xpi request.

Tests for this exist in the test suite in bug 474763
Attachment #359502 - Flags: superreview?(dveditz)
Attachment #359502 - Flags: review?(dveditz)
Comment on attachment 359502 [details] [diff] [review]
patch rev 1

r/sr=dveditz
Attachment #359502 - Flags: superreview?(dveditz)
Attachment #359502 - Flags: superreview+
Attachment #359502 - Flags: review?(dveditz)
Attachment #359502 - Flags: review+
(Assignee)

Comment 14

8 years ago
Landed: http://hg.mozilla.org/mozilla-central/rev/cd824b1dd0bb
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
(Assignee)

Updated

8 years ago
Flags: in-testsuite+
(Assignee)

Comment 15

8 years ago
Landed on branch: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d1d3a589d096
Keywords: relnote → fixed1.9.1
(Assignee)

Comment 16

8 years ago
Comment on attachment 359502 [details] [diff] [review]
patch rev 1

We need this on branch if we also want to fix bug 462739 there
Attachment #359502 - Flags: approval1.9.0.8?
Attachment #359502 - Flags: approval1.9.0.8? → approval1.9.0.8+
Comment on attachment 359502 [details] [diff] [review]
patch rev 1

Approved for 1.9.0.8, a=dveditz for release-drivers
(Assignee)

Comment 18

8 years ago
Landed on branch:

Checking in xpinstall/src/CertReader.cpp;
/cvsroot/mozilla/xpinstall/src/CertReader.cpp,v  <--  CertReader.cpp
new revision: 1.13; previous revision: 1.12
done
Checking in xpinstall/src/nsXPInstallManager.cpp;
/cvsroot/mozilla/xpinstall/src/nsXPInstallManager.cpp,v  <--  nsXPInstallManager.cpp
new revision: 1.167; previous revision: 1.166
done
Keywords: fixed1.9.0.8
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.1b3pre) Gecko/20090110 Shiretoko/3.1b3pre (.NET CLR 3.5.30729)
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.1b3pre) Gecko/20090110 Shiretoko/3.1b3pre (.NET CLR 3.5.30729)
> 
> For example, go to: https://addons.mozilla.org/en-US/firefox/addon/1865
> Start the install, and then, while the download bar fills, go to another page
> (go back, or go to Google, whatever).
> Result: the download will stop, and a "Download error" message box will pop up.
> 
> Reproducible: Always

I cannot confirm this bug with these repro steps in 1.9.0.7 on XP (which is not surprising based on comment 3).
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.