382028 - Status bar lies about link effect, even when Javascript is not allowed to modify the status bar

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

This occurred with a recent trunk SeaMonkey build on WinXP.

I originally filed this as a "Core" bug, but I learned that shift-click
is supposed to do something else on FireFox, so this is a SeaMonkey bug,
not a Core bug.

On page https://addons.mozilla.org/en-US/firefox/addon/4828 there is 
a link that looks like a big download button.  It is a link to 
https://addons.mozilla.org/en-US/firefox/downloads/file/15187/verisign_ev_green_bar_extension-1.0.1.2734-fx.xpi
I don't want to install it.  I want to download it to a disk file.

As with any link, In SeaMOnkey, if I hold down the shift key while clicking 
on it, the downloaded http response should not be interpreted normally, 
but should instead be written to a file.  I should get a file-save-as 
dialog asking me where to store the file.  But that's not what happens.  

The download triggers some installer logic (I think) and I get a dialog 
asking me if I want to install the file.  

Again: I don't want to install it.  I want to save it to disk.  
Apparently I cannot do that with SeaMonkey. :(

reproducible 100%

Steps to reproduce:
1: visit https://addons.mozilla.org/en-US/firefox/addon/4828
2: shift-click on the big download button

Expected behavior:   file-Save-As dialog appears, letting me save the file.
Actual behavior:     Software installation approval dialog appears.

Seems like the inability to save a download as a file is a loss of a MAJOR
function.  If you agree, please set the severity to major.

I have subsequently learned that the URL for the .xpi file given above 
(the second URL given above) does not directly download the xpi file, 
but instead returns something else that controls/redirects the download 
to come from 
http://releases.mozilla.org/pub/mozilla.org/addons/4828/verisign_ev_green_bar_extension-1.0.1.2734-fx.xpi

So, perhaps the right behavior of shift-click on that button would have been
to have saved to disk whatever it was that was returned from the link to 
which that button went, even though it was not the file I expected.  
But either way, I believe it should have saved something to disk, and 
should NOT have brought up an installer dialog.

Comment 1

[WADA:World Anti-bad-Duping Agency]

(Source of the link)
> <a href="/en-US/...(snip).../verisign_ev_green_bar_extension-1.0.1.2734-fx.xpi"
> id="installTrigger15187" (snip)
> onclick="return install(event,document.getElementById('installTrigger15187').getAttribute('addonName'), 
> document.getElementById('installTrigger15187').getAttribute('addonIcon'),
> document.getElementById('installTrigger15187').getAttribute('addonHash'));">

Nelson Bolyard, do you mean "onClick shouldn't be scheduled when Shift+Click"?
Shift+Click behavior of Seamonkey is different from one of Firefox(with no extension)?

I think, if you want that the "Install Now" button works as you want, you need to ask addons.mozilla.org not to use onClick, or disable JavaScript.
Usual/normal way in this case: Save thru context menu.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Well, hmmm.  I have javascript restricted so that it cannot alter the 
content of the task bar.  In fact, the only thing I let it to is change
images.  

When I put my mouse cursor on the button, the status bar shows me a URL.  
Therefore, I expect that when I click on that button, I will go to the 
URL shown in the status bar.  

I have JS's ability to modify the status bar disabled precisely so that
JS cannot lie to me about what the button is going to do when I press it.
That change disabled a certain form of spoofing attack some time back.

But apparently JS can lie to me anyway, by letting me see the URL in the
href, but not actually going there when I click.  :(  

It appears that, presently, I am mistaken to think that by disabling JS's
ability to alter the status bar content, I can believe the status bar's
content to tell me the truth about the link action.  

Is that a recent regression? or has it never been safe to do that?  

I think that, if clicking on the link is not going to go straight to the
href URL, but instead is going to do some JavaScript, then the href's URL
should not be shown in the status bar, to inform the user that something 
inobvious will happen when clicking that link.

Comment 3

[Arun Prasannan (polar)]

Works for me as expected in trunk (Linux).

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Fully reproducible on Windows.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Note, the page has changed a little now. 
The button now reads "Add to Firefox", and the link is to a newer version 
of the file,
https://addons.mozilla.org/en-US/firefox/downloads/file/19452/verisign_ev_green_bar_extension-1.0.1.2898-fx.xpi

But the problem is the same.  Shift-click brings up an XPI install window
rather than a file save as dialog.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I'm changing the subject of this bug to align with the discussion in 
comment 1 and comment 2.  

The real issue is that, even when Javascript has been disabled for all 
purposes other than changing images, and specifically when it has been 
disabled for modifying the status bar contents, the status bar contents
for a link STILL do not accurately indicate the URL to which the link 
will go.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

To state it another way, the browser behavior where it displays a URL in the
status bar on mouse over a link should NOT work when there is a Javascript
onclick script for that link that will go somewhere other than than URL.

The appearance of a URL in the status bar should be a reliable indicator that
clicking the link will take the user to that URL - WHEN the ability of 
Javascript to modify the status area has been disabled.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

MAYBE disabling Javascript's ability to modify the browser window status area
should also disable Javascript onclick, and maybe onmouseover too.

Comment 9

[Andrew Schultz]

It seems reasonable that we should force saving the link with shift-click... but the page has a link and we're properly showing the link's href in the statusbar.  You can (currently) still download the file by right-clicking and choosing to save the link target.

onclick handlers can (in other situations) have more benign behavior -- check something in the page before loading the next or other links might simply be there for the onclick handler (with href="#").  I don't think we want to break those uses for just for this case.  I don't even see fixing this as necessarily a win.  I think disabling changing the status bar is probably a setting that many people have and yet I'm certain that the majority of them would not want the behavior you're advocating (they'd want to be able to use AMO normally).  You're basically advocating that no javascript handlers for any link should work (i.e. break the web) when a pref (that we expose in the UI) is set.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

> the page has a link and we're properly showing the link's href in the
> statusbar.

The page has a link that it never goes to.  The appearance of the URL for
that link is deceitful.  Clicking on it does not to go to that URL.
Shift-Clicking on it does not download that URL.

I object to the deceit.  This sort of deceit is how phishers trick users
into doing things they had no intention of doing.  

If clicking on the link is not going to take me to that URL, or if shift-click
is not going to download that URL, then that URL should not be shown.  
Showing it is deceiving the user.

The whole point of disabling javascript's changes to the status bar is to
disable a scripter's chance of deceiving the user.  There must be a way to
stop the deceit.

Comment 11

[Andrew Schultz]

> The page has a link that it never goes to.  The appearance of the URL for
> that link is deceitful.  Clicking on it does not to go to that URL.

Well, there's deceit, and then there's malice.  There's really very little malice that could happen here that couldn't be done more simply.  As far as deceit goes, we could show nothing in the status bar, but I don't know how helpful it would be.  As I said, in many cases, the href /does/ get loaded after the onclick handler fires.  Or we could put the onlick handler in the status bar... "doGoodThings()"

I mean, servers can redirect anyone anywhere they want.  Should we put the final URL that will get loaded in the status bar?  The status bar is just saying "the page says you're going to go here if you click".  We really have no more information than that.

> Shift-Clicking on it does not download that URL.

... and as I said we should fix that part.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

> The status bar is just saying "the page says you're going to go here if 
> you click".

But that's not what the page says.  What the page "says" includes an 
onClick handler.  An onClick handler means "the href is irrelevant.  
When you click, you're going to do something else entirely. It may 
COINCIDENTALLY be that the onClick will go to the same place as the 
href, but there are absolutely no assurances of that."  

I want the browser to give me a indicator that I can trust.  I don't trust
the page author but I DO trust the browser (or rather, I want to trust the
browser, but this bug points out that I dare not).  

The page author can attempt to deceive me about the meaning of the act of 
clicking on a link in (at least) 3 ways:
a) an onmouseover action that displays a phony URL in the status bar,
a URL other than the href URL, but I can disable that.
b) on onClick action that goes to a different URL than the href.  
The browser offers me no protection from that.
c) both onmouseover and onclick.  

I really want the status bar to be an indicator of what will happen.  
Perhaps if there is an onclick action, the status bar should display 
the onclick action.  Yes, even if it's "doGoodThings()" that's enough 
warning to me.  It tells me that I must do a lot more work to find out 
what's really going to happen.  But that's infinitely better than 
deceiving me into believing it's going to go to a URL that it isn't 
going to visit.