Created attachment 709080 [details] Screenshot 1) Open https://twitter.com/download/firefox/ in Firefox 2) Click the big yellow "Get Twitter Address Bar Search" button. Doing so opens a new tab (the URL says about:blank), and there is a doorhanger saying an addon install was blocked. Twitter should probably be linking to the addon's landing page instead of the xpi (I think that's what's happening, at least, the hover preview says it's pointing at https://addons.mozilla.org/en-US/firefox/downloads/latest/318202/addon-318202-latest.xpi?src=external-twitter). But the combination of opening a new tab and blocking the install is really confusing. Either we (?) shouldn't open the tab (so that the doorhanger is in the actual twitter.com page), or we should just completely block the install attempt without any UI. The default action is "Allow", and I'd suspect this could be abused by sketchy sites to push addon installs without it being very obvious where it's coming from. [Actually, we should probably make this dialog just be icon-only, since there's no really good reason to be encouraging such installs IMO]
Would doing this also disable drag-to-install functionality of local .xpi files onto about:blank or about:newtab?
Twitters button is basically this: <a target="_blank" href="https://addons.mozilla.org/en-US/firefox/downloads/latest/318202/addon-318202-latest.xpi?src=external-twitter"></a> target="_blank" forces us to open a new tab before even looking at what the content of the link is. Then that tab's browser attempts to load the XPI and our content handler steps in to initiate add-on installation. It gets blocked correctly because the referer (twitter.com) isn't whitelisted. Presumably the content handler is stepping in so early that tabbrowser doesn't even get told about the page's URL which is why it is showing about:blank. Twitter should just remove the link target or link to the AMO page. I'm not sure how easy it would be to fix this ourselves, a few options: Pre-loading the content would tell us that no new tab is needed. The browser.js code could detect that the add-on install is being triggered on a blank tab and close it and jump back to the opening tab (do we have that info?) instead. I seem to recall that downloads had this issue for a while too and got fixed, not sure how.
(In reply to Mardeg from comment #1) > Would doing this also disable drag-to-install functionality of local .xpi > files onto about:blank or about:newtab? We would presumably not want to break that use case.
It's a bit confusing, but that's the choice the author of the page (which no longer exists made). I don't necessarily any real problem with installing an add-on on about:blank and I feel anything that tries to prevent this will lead us into a rabbit hole of questionable value.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.