Last Comment Bug 395917 - simulating a click on an anchor using dispatchEvent and initMouseEvent does not trigger a real click
: simulating a click on an anchor using dispatchEvent and initMouseEvent does n...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: 1.9.0 Branch
: x86 All
: -- normal with 4 votes (vote)
: mozilla6
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 331087 (view as bug list)
Depends on: 666604
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-12 09:56 PDT by Julien Blanc
Modified: 2011-08-14 06:56 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test case for bug (503 bytes, text/html)
2007-09-12 09:57 PDT, Julien Blanc
no flags Details
Test case for bug; demonstrates that handler is executed (896 bytes, text/html)
2009-11-03 13:39 PST, Andy Harrison
no flags Details

Description Julien Blanc 2007-09-12 09:56:18 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; fr; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; fr; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

Using dom events to programmatically click on an anchor (see the example), the result is not the same as if the user had clicked on the anchor. The href portion is ignored when using dom events, which is not obvious why (both opera and khtml do not behave this way).

Reproducible: Always

Steps to Reproduce:
1. create a file with the following html :
<html>
	<head><title>Simulate click/title></head>
	<body>
		<a href="test.html" id="test_link">test</a>
		<input type="button" onclick="simulateclick()" value="simulate" />
		<script type='text/javascript'>
function simulateclick()
{
	var elem = document.getElementById("test_link");
	var evt = document.createEvent("MouseEvents");
	evt.initMouseEvent("click", true, true, window, 0, 0, 0, 0, 0, false, false, false, false, 0, elem);
	elem.dispatchEvent(evt);
}
		</script>
	</body>
</html>

2. click on the simulate click button

Actual Results:  
nothing happens

Expected Results:  
the test.html page is opened (should follow the link, since the default action for clicking on a link is to follow it).
Comment 1 Julien Blanc 2007-09-12 09:57:17 PDT
Created attachment 280616 [details]
test case for bug
Comment 2 Neil Deakin 2007-09-12 13:37:29 PDT
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;
Comment 3 Julien Blanc 2007-09-12 23:14:06 PDT
I don't see the point with the security reason. There are plenty other ways to trigger a download, and you just gave one (using document.location).

Moreover, the workaround you gave is incomplete. A good workaround would be to simulate what the browser does, that is to say :
- trigger the event using dispatchEvent
- check the return value
- if okay, then, test for any tags on the href (such as target)
- test the href, it may be either an http url, but can also be a mailto: or javascript:
- act accordingly, which can be pretty complex.

I can code that in javascript (i've already done it for cases needed in my application), but that won't be cross browser, since other implementation will follow the href after the first step. And i think they're right in the way they interpret the DOM.

This definitely looks like a bug in gecko to me.
Comment 4 Olli Pettay [:smaug] 2007-09-12 23:43:40 PDT
See Bug 265176.
Comment 5 Olli Pettay [:smaug] 2007-09-12 23:48:51 PDT
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.
Comment 6 Daniel Vanesse 2008-01-18 00:23:40 PST
I have experienced the same problem both in Firefox 2.0.0.10 AND release 3 beta 2. No improvement so far ...
Comment 7 Julien Blanc 2008-08-22 01:19:40 PDT
Tested with 3.0.0.1

Still not working.
Comment 8 Daniel.S 2009-05-02 03:34:05 PDT
*** Bug 331087 has been marked as a duplicate of this bug. ***
Comment 9 Perry Smith 2009-06-28 20:23:42 PDT
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.
Comment 10 Andy Harrison 2009-11-03 13:36:31 PST
The handler for the click event is executed but the link is not followed afterward.
Comment 11 Andy Harrison 2009-11-03 13:39:22 PST
Created attachment 410029 [details]
Test case for bug; demonstrates that handler is executed
Comment 12 Perry Smith 2010-04-17 10:14:30 PDT
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...
Comment 13 Makinde Adeagbo 2010-07-22 06:03:00 PDT
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.
Comment 14 Olli Pettay [:smaug] 2010-07-22 06:07:15 PDT
Makinde, may I ask why you need to rely on this?
It is not at all clear that this is even a valid bug.
Comment 15 Olli Pettay [:smaug] 2010-07-22 06:09:00 PDT
By default an event which isn't dispatched by UA doesn't have the default
action (which is in this case 'trigger-the-link').
Comment 16 Makinde Adeagbo 2010-07-22 06:13:45 PDT
Wow, quick reply.  Thanks.  My current use case is letting the user use the left and right arrow to navigate through photos.  I'm trying to have javascript simulate a click on that link.  Simulating the click, and the ful stack associated with that, allows me to run all the logic on that link.

In general, this is something that many people have spoken about online.  See: http://stackoverflow.com/questions/809057/how-do-i-programmatically-click-on-an-element-in-firefox

My reasoning is very similar to Julien Blanc in his 2007 comment.
Comment 17 Makinde Adeagbo 2010-07-22 06:14:32 PDT
This is also frustrating since all other major browsers facilitate the functionality.
Comment 18 Olli Pettay [:smaug] 2010-07-22 06:22:21 PDT
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)
Comment 19 Andy Harrison 2010-07-22 06:26:49 PDT
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".
Comment 20 Makinde Adeagbo 2010-07-22 06:36:06 PDT
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.
Comment 21 Makinde Adeagbo 2010-07-22 06:49:09 PDT
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.
Comment 22 Neil Deakin 2010-07-22 07:27:03 PDT
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.
Comment 23 Perry Smith 2010-07-22 22:52:22 PDT
Also, FF allows a person to configure chord keys that interact with the mouse click.  e.g. on a mac if I hold down command and click I get a new tab.  If I hold down shift+command and click I get a new tab and select the tab.  Doing all this in Javascript is near impossible since that level of detail of how the user has the browser configured is not provided.
Comment 24 Igor Minar 2010-10-04 20:45:44 PDT
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.
Comment 25 Ruy Asan 2011-07-20 19:18:13 PDT
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?
Comment 26 Olli Pettay [:smaug] 2011-07-21 02:18:37 PDT
This is fixed. See bug 666604.

Note You need to log in before you can comment on or make changes to this bug.