anchorElement.dispatchEvent(clickEvent) always returns false

RESOLVED FIXED in Firefox 48

Status

()

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

People

(Reporter: Vojta, Assigned: smaug)

Tracking

({regression})

6 Branch
mozilla48
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(firefox48 fixed)

Details

Attachments

(3 attachments)

(Reporter)

Description

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

Updated

6 years ago
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → events

Comment 1

6 years ago
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
Blocks: 666604
Keywords: regression
(Assignee)

Updated

6 years ago
Summary: element.eventDispatch() always returns false → element.eventDispatch(clickEvent) always returns false
(Assignee)

Updated

6 years ago
Summary: element.eventDispatch(clickEvent) always returns false → anchorElement.eventDispatch(clickEvent) always returns false
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?
(Reporter)

Comment 3

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

6 years ago
Created attachment 561194 [details]
attaching a test case for this bug

Comment 6

6 years ago
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Flags: needinfo?(bugs)

Updated

2 years ago
Summary: anchorElement.eventDispatch(clickEvent) always returns false → anchorElement.dispatchEvent(clickEvent) always returns false
(Assignee)

Updated

2 years ago
Assignee: nobody → bugs
Flags: needinfo?(bugs)
(Assignee)

Comment 9

2 years ago
Created attachment 8738266 [details] [diff] [review]
patch

Let's see what tryserver says about the change.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=49b090c8379fa75723ac14ce973fe3b62cf469fd
Flags: needinfo?(bugs)
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 .
(Assignee)

Comment 11

2 years ago
Created attachment 8738528 [details] [diff] [review]
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.
Flags: needinfo?(bugs)
Attachment #8738528 - Flags: review?(masayuki)
Attachment #8738528 - Flags: review?(masayuki) → review+
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1257043

Comment 13

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

Comment 14

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/83d398b9419a
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox48: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.