96731 - browser fails to download theme

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Installer, defect)

Description

[Darin Fisher]

1) start with an empty cache
2) follow the link to get new themes
3) click on one of the older themes (eg. "thinice")
4) notice that the theme is not downloaded
5) click stop on the browser window showing the themes page
6) notice that the thinice theme is now downloaded

BTW it appears that the theme is being loaded twice for some reason, but the
first load is ignored.  the second load is blocked waiting for the cache entry
which the first load opened.  i suspect that clicking the STOP button on the
browser window kills off the first load, freeing the second load to get access
to the cache.

Comment 1

[Darin Fisher]

noticing this with a trunk build from yesterday (8/22) on win32 and linux.

Comment 2

[Daniel Veditz [:dveditz]]

*you're* in networking, you tell *us* what's wrong! This has been a pretty
common problem, and is a dupe of another bug unless that one was finally closed
"works for me".

There are two ways to trigger an XPInstall. The way that works is to use a bit
of Javascript, which causes us to put up a confirmation dialog, and after the
user OKs that we then call Necko to get the passed-in URL.

The way that doesn't work is to click on a file of a given MIME type, which
apparently starts a download on its own, and then tells us so we can put up the
confirmation dialog and then try to download it ourselves.
Any pointers to documentation on content handlers would be appreciated, so we
can take advantage of the download that's already occurring, while still being
able to put up our confirmation dialog and cancel the download if necessary.

Comment 3

[Darin Fisher]

looks like the first download is not being canceled.

-> taking, as i think i can come up with a patch

Comment 4

[Darin Fisher]

Attachment: sample http log demonstrating the problem

Comment 5

[Darin Fisher]

dveditz: what is so special about the older xpi files?  why do they produce the
intermediate dialog?

Comment 6

[Darin Fisher]

nope... i really don't know enough about the way installer works to solve this
problem.  someone in docshell land may know why the first load is not getting
canceled.

Comment 7

[K'Trina Medina]

ccing adamlock (in docshell)

Adam, do you know why the first load is not getting canceled?

Comment 8

[Sean Su]

over to dprice

Comment 9

[chris hofmann]

dprice is on sabitcal. moving to next milestone. 

Comment 10

[Syd Logan]

only nsbeta1+ bugs can have milestones, resetting to ---

Comment 11

[dprice (gone)]

The test case for this is gone.  Looking for another one.

Comment 12

[dprice (gone)]

it sounds a lot like http://bugzilla.mozilla.org/show_bug.cgi?id=60910 and
http://bugzilla.mozilla.org/show_bug.cgi?id=46318  

Dan: Is it a dup?

Comment 13

[Daniel Veditz [:dveditz]]

You can get skins at
http://xulplanet.com/downloads/view.cgi?category=skins&view=all for now. If it
goes away try
http://www.deskmod.com/?show=showcat&cat_name=mozilla

It might be a dupe, but there are enough little differences between chrome
installs and XPInstall that it should be verified.

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

old XPFE installer is dead.