The default bug view has changed. See this FAQ.

simulating a click on an anchor using dispatchEvent and initMouseEvent does not trigger a real click

RESOLVED FIXED in mozilla6

Status

()

Core
DOM: Events
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: Julien Blanc, Unassigned)

Tracking

1.9.0 Branch
mozilla6
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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).
(Reporter)

Comment 1

10 years ago
Created attachment 280616 [details]
test case for bug

Comment 2

10 years ago
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;
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

10 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 4

10 years ago
See Bug 265176.

Comment 5

10 years ago
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

9 years ago
I have experienced the same problem both in Firefox 2.0.0.10 AND release 3 beta 2. No improvement so far ...
(Reporter)

Comment 7

9 years ago
Tested with 3.0.0.1

Still not working.
OS: Windows Server 2003 → All
Version: unspecified → 1.9.0 Branch

Updated

8 years ago
Duplicate of this bug: 331087

Comment 9

8 years ago
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

8 years ago
The handler for the click event is executed but the link is not followed afterward.

Comment 11

8 years ago
Created attachment 410029 [details]
Test case for bug; demonstrates that handler is executed

Comment 12

7 years ago
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...

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: simulating a click on an anchor using dispatchEvent does not trigger a real click → simulating a click on an anchor using dispatchEvent and initMouseEvent does not trigger a real click

Comment 13

7 years ago
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').

Comment 16

7 years ago
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

7 years ago
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)

Comment 19

7 years ago
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

7 years ago
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

7 years ago
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

7 years ago
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

7 years ago
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

7 years ago
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

6 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago6 years ago
Depends on: 666604
Resolution: --- → FIXED

Updated

6 years ago
Target Milestone: --- → mozilla7

Updated

6 years ago
Target Milestone: mozilla7 → mozilla6
You need to log in before you can comment on or make changes to this bug.