Closed Bug 395917 Opened 17 years ago Closed 13 years ago

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

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Version:
1.9.0 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla6

People

(Reporter: julien.blanc, Unassigned)

References

Details

Attachments

(2 files)

test case for bug
503 bytes, text/html
Details
Test case for bug; demonstrates that handler is executed
896 bytes, text/html
Details 
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).
Attached file test case for bug — 

    
    

    
  
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
Closed: 17 years ago
Resolution: --- → INVALID

    
    

    
  
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 → ---

    
    

    
  
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 2.0.0.10 AND release 3 beta 2. No improvement so far ...

    
    

    
  
Tested with 3.0.0.1

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

    
    

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

    
  
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

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.
Status: NEW → RESOLVED
Closed: 17 years ago → 13 years ago
Depends on: 666604
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
Target Milestone: mozilla7 → mozilla6

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: