john ruskin, could you test the tescase with a new Firefox profile please? https://support.mozilla.org/en-US/kb/Managing-profiles
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.
(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.
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.
(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?
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...
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.