Closed Bug 498714 Opened 15 years ago Closed 15 years ago

Do not call installTrigger on "Download Now" buttons

Categories

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

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: leszekz, Assigned: abuchanan)

References

Details

(Keywords: regression)

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
Assignee: nobody → buchanae
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
Summary: Bad button name on SeaMonkey main page → Do not call installTrigger on "Download Now" buttons
Why is a later bug (mine) marked as a duplicate of a newer bug?
Because the newer one has an assignee (along with a slightly more common use case in comment 0 ;) ). Sorry, should have mentioned that.
Depends on: 498825
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.
Severity: normal → trivial
Priority: -- → P5
Target Milestone: --- → 5.4
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)
(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.
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.
(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.
or invalid I guess.
(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 :)
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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.