This doesn't happen for security reasons, so that web sites can't trigger downloads. If you're trying to just open a url from a link, you should just use: document.location = document.getElementById("test_link").href;
See Bug 265176.
But I *might* agree that this is a bug. We handle trusted events better way now than in 1.7.x and Bug 265176 could be possibly backed out. Need to test that.
I have experienced the same problem both in Firefox 220.127.116.11 AND release 3 beta 2. No improvement so far ...
Tested with 18.104.22.168 Still not working.
If no one can give a valid reason why it is a security issue to allow a simulated click (I sure can't come up with a valid reason), then this needs to be considered a bug. Setting the location is not adequate. In particular, there are features of FF that you can not duplicate. On the Mac for example, a commant-click opens the page in a new tab; shift-command-click opens in a new tab and selects it. This is using the default set up which can be altered. Simulating all that would be absurd. I'm not familiar with other platforms but I'm sure others have similar features. Please fix this bug.
The handler for the click event is executed but the link is not followed afterward.
Can we get this fixed? Andy's test case is simple. The way I have FF configured I can hold down command+shift and hit the real link and after the dialog box is acknowledged, I get a new tab with the non-existent page. But I do not get that when the submit button is hit. At least change the status to confirmed...
Hello, I am an engineer at facebook. Going forward, we will be creating features that depend on the correct behavior of this bug (where dispatchEvent follows the link). When these features start shipping, current versions of firefox will be lacking the additional functionality.
Makinde, may I ask why you need to rely on this? It is not at all clear that this is even a valid bug.
By default an event which isn't dispatched by UA doesn't have the default action (which is in this case 'trigger-the-link').
This is also frustrating since all other major browsers facilitate the functionality.
So if you're handling keys, why don't you just do something like document.location = "new location" in your key event handler? (I assume you actually want to set the location of some iframe)
Olli - Why are you unsure whether this is a valid bug? I can't find anything in the spec that says the default action should not be triggered if preventDefault isn't called by any of the event handlers. FYI, I would like to use this functionality in one of my Greasemonkey scripts - coincidentally for the Facebook feed page to simulate a click on "Most Recent".
I do not to re-implement the browser stack for processing events. As Julien mentioned: - trigger the event using dispatchEvent - check the return value - if okay, then, test for any tags on the href (such as target) Writing that logic in my own JS is fragile and unnecessary. Perhaps it may help to get a clearer understanding of what the issue is on your side. Maybe we can also look into how the other browsers address the issue.
I do want not to re-implement the browser stack for processing events. As Julien mentioned, that would involve a series of steps: - trigger the event using dispatchEvent - check the return value - if okay, then, test for any tags on the href (such as target) Writing that logic in my own JS is fragile and unnecessary. Perhaps it may help to get a clearer understanding of what the issue is on your side. Maybe we can also look into how the other browsers address the issue.
The html5 spec says: "The above doesn't happen for arbitrary synthetic events dispatched by author script. However, the click() method can be used to make it happen programmatically." referring to the behaviour that occurs when an element is clicked/activated. What I think what we want is to have the click() method implemented.
I'm too affected by this bug. My use case is building an automated test suite that precisely simulates user clicking on a link. Chrome and Safari simulate the click event well, but FF doesn't.
I'd like to +1 that this is in fact a bug and that Bug 265176 is an invalid fix. This exception clearly breaks expected DOM behavior as discussed above. In addition, I am also at a loss to explain how setting window.location is any different from triggering a prompt-less download (for users who have prompt-less downloads enabled). The moz DOM is acting in a strange way that outright defies html5 specs (as per comment 22), that not other browser has seen fit to emulate and provides no additional security to the user. Pretty please with sugar on top, is it possible to revert this behavior?
This is fixed. See bug 666604.