684208 - anchorElement.dispatchEvent(clickEvent) always returns false

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Vojta]

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.218 Safari/535.1

Steps to reproduce:

Here is a test case for the issue:
http://jsfiddle.net/vojtajina/S67Bp/

Note, this works fine on FF3, Chrome, Opera.



Actual results:

element.dispatchEvent(evt) returns false even if event.preventDefault() has not been called.

Comment 1

[Alice0775 White]

Regression window(cached m-c hourly),
Works:
http://hg.mozilla.org/mozilla-central/rev/5c246f2bccb1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110630 Firefox/7.0a1 ID:20110630035829
Fails:
http://hg.mozilla.org/mozilla-central/rev/7deef688bbf5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110630 Firefox/7.0a1 ID:20110630112801
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c246f2bccb1&tochange=7deef688bbf5

Suspected:
7deef688bbf5	Olli Pettay — Bug 666604 - Allow untrusted events to trigger a link, r=bz

Comment 2

[Boris Zbarsky [:bzbarsky]]

There's an event listener in this case that in fact calls preventDefault.  It's just not provided by the page.  You can trivially check it by checking the value of event.getPreventDefault() on |event| after the first dispatch: it returns true.

So I believe this bug is invalid as far as that goes....

Now one could argue that the listener in question should not prevent default, but that's outside the scope of the event system, no?

Comment 3

[Vojta]

You are right, that event.defaultPrevented is true after dispatching...
But the property is probably changed from within the dispatch, there no outside call to event.preventDefault().

Try this, before dispatching the event:
event.preventDefault = function() {
  alert('called from outside');
};

This method will not be called.

Note that it works as expected in other browsers as Chrome, FF3, Opera, so I think it's a bug.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> But the property is probably changed from within the dispatch

It's changed by an event listener.  See comment 2!

> Note that it works as expected in other browsers

There can't be any expectations about preventDefault behavior, since listeners outside your control can call it.

Comment 5

[Igor Minar]

Attachment: attaching a test case for this bug

Comment 6

[Igor Minar]

I work on a end-to-end testing framework for http://angularjs.org/ and I came across this issue.

For my testing framework to work properly, it needs to be able to tell if the default action was prevented by the application or not. This is easy on all browsers (even older FF), but not on FF6 which always returns false when I call element.dispatchEvent.

I attached a reduced test case inspired by Vojta's jsfiddle. It clearly shows that without anything in the application calling preventDefault(), FF6 always returns false for dispatchEvent calls.

Originally we created a workaround, which monkey-patched preventDefault method on the event we were about to dispatch, but even that stopped working recetly (FF6.0.2?). This is likely because when we dispatch the event into the iframe and it appears that FF will recreate the event object and the monkey-patch is not available within the app iframe.

Comment 7

[Michelle Funches - QA]

This bug has been tagged for Regression and or closure. Updating to New as this still appears in current Release and Nightly.
Verified: this still appears to be an issue
Version 	45.0.1
Build ID 	20160315153207
User Agent 	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Version 	48.0a1
Build ID 	20160404030231
expecting dispatchEvent to return true . it returned false 
expecting dispatchEvent to return false . it returned false 

While Chrome displays 
expecting dispatchEvent to return true . it returned true 
expecting dispatchEvent to return false . it returned false

Comment 8

[Michelle Funches - QA]

Last: Additonal comments have been acknowledged, however if this won't be fixed (see comment 2), please notify and i will close as invalid or won't fix.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Attachment: patch

Let's see what tryserver says about the change.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=49b090c8379fa75723ac14ce973fe3b62cf469fd

Comment 10

[Michelle Funches - QA]

Verifying:
Build in comment 9 has resolved the issue.
expecting dispatchEvent to return true . it returned true .
expecting dispatchEvent to return false . it returned false .

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Attachment: patch

The patch revealed another interesting bug, which is why
test_bug517851.html had to be modified.
If an already cancelled event was re-dispatched to an event target which didn't have any listeners, we got wrong return value from dispatchEvent.
Improved that test a bit.

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/83d398b9419a

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/83d398b9419a