498714 - Do not call installTrigger on "Download Now" buttons

Status: RESOLVED WONTFIX

(addons.mozilla.org Graveyard :: Public Pages, defect, P5)

Description

[Leszek Zyczkowski]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Build Identifier: 

On the SeaMonkey main page are displayed buttons for install add-on. Title this buttons is "Download Now", should be "Add to SeaMonkey" because after click these buttons, starts install process.

Reproducible: Always

Comment 1

[Fred Wenzel [:wenzel]]

I think this is a regression: While the text is right (it *should* be called Download Now), if you are not using SeaMonkey the InstallTrigger code is not supposed to fire. Instead, it should download the xpi file.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

Why is a later bug (mine) marked as a duplicate of a newer bug?

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

s/later/earlier

Comment 5

[Fred Wenzel [:wenzel]]

Because the newer one has an assignee (along with a slightly more common use case in comment 0 ;) ). Sorry, should have mentioned that.

Comment 6

[Wil Clouser [:clouserw]]

The bug is browsing seamonkey pages with firefox shouldn't install.  In other words, unless you are browsing with the application that matches the pages (firefox browser on /firefox/) you shouldn't ever get installTrigger().

Alex:  what's the status of this?  Moving to 5.4 so I remember to talk to alex on IRC.

Comment 7

[Alex Buchanan [:abuchanan]]

The problem comes from the downloads controller, starting at line 108, where we have some logic for setting headers for non-browser apps.  Specifically, Content-disposition: attachment

Still working on a patch.  I'm not sure yet how to get the user agent from the server-side download controller.

For an example, check out these links and their HTTP headers

* Firefox XPI
https://addons.mozilla.org/en-US/firefox/downloads/latest/1320/addon-1320-latest.xpi

* Seamonkey XPI 
https://addons.mozilla.org/en-US/seamonkey/downloads/latest/722/addon-722-latest.xpi

* Thunderbird XPI
https://addons.mozilla.org/en-US/thunderbird/downloads/latest/1865/addon-1865-latest.xpi

* Sunbird
https://addons.mozilla.org/en-US/sunbird/downloads/latest/1117/addon-1117-latest.xpi

The Firefox and Seamonkey links act the same for me, they call InstallTrigger and I get the install dialog pop-up

The Thunderbird and Sunbird links act like a file download (and have Content-Disposition headers)

Comment 8

[Wil Clouser [:clouserw]]

(In reply to comment #7)
> The problem comes from the downloads controller, starting at line 108, where we
> have some logic for setting headers for non-browser apps.  Specifically,
> Content-disposition: attachment
> 
> Still working on a patch.  I'm not sure yet how to get the user agent from the
> server-side download controller.
> 
> For an example, check out these links and their HTTP headers
> 
> * Firefox XPI
> https://addons.mozilla.org/en-US/firefox/downloads/latest/1320/addon-1320-latest.xpi
> 
> * Seamonkey XPI 
> https://addons.mozilla.org/en-US/seamonkey/downloads/latest/722/addon-722-latest.xpi
> 
> * Thunderbird XPI
> https://addons.mozilla.org/en-US/thunderbird/downloads/latest/1865/addon-1865-latest.xpi
> 
> * Sunbird
> https://addons.mozilla.org/en-US/sunbird/downloads/latest/1117/addon-1117-latest.xpi
> 
> The Firefox and Seamonkey links act the same for me, they call InstallTrigger
> and I get the install dialog pop-up
> 
> The Thunderbird and Sunbird links act like a file download (and have
> Content-Disposition headers)

You won't be able to look at the user agent on the server side.  You're saying that looking at a /firefox/ URL with seamonkey isn't actually firing installTrigger(), it's just seamonkey prompting to install because of the header?  If that's the case that's a different bug and, potentially, a wontfix due to our caching.

Comment 9

[Fred Wenzel [:wenzel]]

I guess we could set a GET variable in the download URL, forcing download-only on the install button's link target but removing that variable with JS when firing the install trigger.

In other words, all downloads would default to content-disposition attachment, unless the install button JS code says otherwise.

Comment 10

[Wil Clouser [:clouserw]]

(In reply to comment #9)
> I guess we could set a GET variable in the download URL, forcing download-only
> on the install button's link target but removing that variable with JS when
> firing the install trigger.
> 
> In other words, all downloads would default to content-disposition attachment,
> unless the install button JS code says otherwise.

That's a pretty big change.  It sounds reasonable, but could change expected behavior when I, for example, send you a link to an XPI.  I think that's out of scope for this bug.

Alex:  If you're saying installTrigger() isn't actually called on the Download Now buttons this can be WONTFIX'd.

Comment 11

[Wil Clouser [:clouserw]]

or invalid I guess.

Comment 12

[Fred Wenzel [:wenzel]]

(In reply to comment #10)
> That's a pretty big change.  It sounds reasonable, but could change expected
> behavior when I, for example, send you a link to an XPI.  I think that's out of
> scope for this bug.

I understand and concur :)

Comment 13

[Alex Buchanan [:abuchanan]]

Agreed.

To be clear, I'm saying InstallTrigger() is *not* called by the button JS, rather by Mozilla apps when they see "Content-Type:  application/x-xpinstall"

"Content-disposition: attachment" happens to override that, and force a download.  We use that for apps without a browser or URL bar, like Tbird.

All that happens completely on the server-side, where UA detection is not possible (per our infrastructure).

I think an optional _GET param could work, but yeah, it probably creates more edge cases than it fixes anyway.