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)
addons.mozilla.org Graveyard
Public Pages
Tracking
(Not tracked)
RESOLVED
WONTFIX
5.4
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
Updated•15 years ago
|
Assignee: nobody → buchanae
Comment 1•15 years ago
|
||
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
Updated•15 years ago
|
Summary: Bad button name on SeaMonkey main page → Do not call installTrigger on "Download Now" buttons
Comment 3•15 years ago
|
||
Why is a later bug (mine) marked as a duplicate of a newer bug?
Comment 4•15 years ago
|
||
s/later/earlier
Comment 5•15 years ago
|
||
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•15 years ago
|
||
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
Assignee | ||
Comment 7•15 years ago
|
||
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•15 years ago
|
||
(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•15 years ago
|
||
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•15 years ago
|
||
(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•15 years ago
|
||
or invalid I guess.
Comment 12•15 years ago
|
||
(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 :)
Assignee | ||
Comment 13•15 years ago
|
||
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
Updated•8 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•