770760 - MiddleClick on an <a Onclick="Alert(... ></a> creates true http request instead of alerting on new tab

Status: RESOLVED INCOMPLETE

(Firefox :: Untriaged, defect)

Description

[john]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

I middle-clicked on a URL whose underlying code was this:

<a onclick="alert('Attn: --text here')" href="javascript:void(0)">
<font size="3" face="Times New Roman"> --more text here-- </font>
</a>




Actual results:

[I have middle click set to push the link to a new tab]

I get a website server error:  
Error 404--Not Found
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.

From which I assume some context of the URL is sent the domain serving the original web page [in this case, FedEx.Com]


Expected results:

I suppose the alert should have shown up within the construct of the new-tab

Comment 1

[mjh563]

I can't reproduce this. When I middle click the link I get a blank tab opening that says "javascript:void(0)" in the address bar. Not a 404 page, but not an alert either.

The alert not appearing is expected behaviour though. Firefox doesn't fire an "onclick" event when you middle click a link. (It does fire it on the document object, but not on the link itself.) 

But even if the onclick handler *was* run, the alert would appear on the existing tab not the new tab, because it would happen prior to the browser navigating to the new page.

Comment 2

[mjh563]

Attachment: Reporter's testcase

Comment 3

[Loic]

john ruskin, could you test the tescase with a new Firefox profile please?
https://support.mozilla.org/en-US/kb/Managing-profiles

Comment 4

[john]

I suspect the difference is that the actual code is located on a live FedEx.Com web page, and my Fox is treating the URL as a construct which is sent back to the FedEx domain server -- ergo the 404 response from the server.  And it -only- does that with a middle click; with a normal click, the OnClick event is trapped and executed.

---

When normal-clicking, on a traditional URL or the OnClick URL, the resulting action appears on the then displayed tab.

In contrast, when I middle-click, I expect the returned result [ie, returned to me] to appear on a new tab.   For a traditional URL [ie, a server request as HTTP://etc], it works.

For the OnClick event, for some reason the normal-click returns an alert, and does not send the underlying URL to the domain server in any form.  In contrast, with a middle-click, for some reason, Fox elects to send the OnClick event back to the domain server.   

That Fox does that perplexes me.  What is it about a normal-click that Fox traps an OnClick event, and never gets around to sending a request to the page server?  What is it about a middle-click that the trapping never occurs ?

---

I don't understand the comment/concept that the middle-click fires on the document, and not the Link itself.   To me, the UI distinction, between normal-click and middle-click, is where the result lands.  

---

Does a middle-click, in Fox without addons, return content to a new-tab? (It seems so, since your test does, for you)  On my Fox, with tabMixPlus, the middle-click drives links' returned content to a new-tab.

Comment 5

[john]

(In reply to mjh563 from comment #1)
> 
> The alert not appearing is expected behaviour though. Firefox doesn't fire
> an "onclick" event when you middle click a link. (It does fire it on the
> document object, but not on the link itself.) 

On thinking this through, more, this implies to me that the bug, at least as I reported it, is confirmed, but that mjh563 sees it as expected behavior.  From a UI perspective, if the middle-click is designed to send results to a new tab, why does it have a schema which does not respond to the same object [ie, why not respond to the link...]

---

My apologies: allow me to add clarity to the original post:  Under the "Actual results", everything from there down to just before the paragraph beginning "From Which..." was the FedEx.Com server response.    The paragraph: "From which...." was my comment about the result.   Sorry.

Comment 6

[mjh563]

Please provide more detailed steps to reproduce. If it only happens on the fedex.com website (and not using the standalone HTML fragment you provided) then the steps should include that if possible. 

Alternatively, try to create and attach a minimised test case that other people can run and get the same result that you do.

Comment 7

[mjh563]

(In reply to john ruskin from comment #4)
> Does a middle-click, in Fox without addons, return content to a new-tab? (It
> seems so, since your test does, for you)  On my Fox, with tabMixPlus, the
> middle-click drives links' returned content to a new-tab.

So have you checked that the problem isn't caused by Tab Mix Plus or one of your other add-ons?

Comment 8

[john]

mjh:  thanks for reminding me to test the report with addons disabled.

In that addon disabled state, the middle-click drives the same response you report, using the live FedEx.Com webpage.

I still think that the UI should be consistent, driving the same response with the middle click towards a new tab.

And, it is very curious that the same middle click , with TabMixPlus enabled, eliminates the trap of the OnClick event 

I am tempted to suggest that the artifact in the standard Fox code, and the existence of different trapping behaviors, implicates something about the sequence of response: for creating new tab, and responding to the users URL click, that bypasses a portion of the code that responds to OnClick or other events.

In both the addon disabled and enabled states, the new tab creation apparently occurs before some trap occurs; and after the new tab is created, and a decision tree is entered to respond to the URL, there is no longer any trapping in the handling tree.

That, to my contemplation, would a logic/coding mis-sequence that would probably be recognized by someone who has tooled in coding the handling tree, and the new tab creations...

Comment 9

[Nickolay_Ponomarev]

If there's still an issue here after disabling tab mix plus, please provide clear steps to reproduce; this report is very confusing in its current state.