If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Content-dispatched events do not visit chrome across domains

VERIFIED INVALID

Status

()

Core
DOM: Core & HTML
VERIFIED INVALID
12 years ago
9 years ago

People

(Reporter: WeirdAl, Unassigned)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
I was under the impression that I could dispatch an event at a content element, and chrome event listeners would be able to pick up on it.  I remember this working a long time ago, and apparently so do others (reference the URL field).  Sadly, I've not been able to reproduce this more recently.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051216 SeaMonkey/1.0b

Testcase coming up in two parts.
(Reporter)

Comment 1

12 years ago
Created attachment 207102 [details]
Testcase, part one of two (content panel)
(Reporter)

Comment 2

12 years ago
Created attachment 207103 [details]
Testcase, part two of two (chrome window)
You have to register your chrome listeners to listen to untrusted events.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

12 years ago
Hm.  This bug is invalid as originally filed; when both attachments are hosted by Bugzilla, the testcase passes.

Steps to reproduce:

(1) Save attachment 207103 [details] to a chrome URL within your file system (chrome://global/content/tests/test01.xul will do).
(2) Enable dump statements in the browser.
(3) (application) -chrome chrome://global/content/tests/test01.xul
(4) Click on the foo button and observe dump output.
(5) Quit the browser.
(6) (application) -chrome https://bugzilla.mozilla.org/attachment.cgi?id=207103
(7) Click on the foo button and observe dump output.
(8) Quit the browser.

Expected results at step 4:
foo caught by chrome at [object ChromeWindow @ 0x1cc96b0 (native @ 0x1cc48e0)] (phase 1)
foo caught by chrome at [object XULDocument @ 0x2c1b568 (native @ 0x1d76160)] (phase 1)
foo caught by content (phase 1)
foo caught by content (phase 3)
foo caught by chrome at [object XULDocument @ 0x2c1b568 (native @ 0x1d76160)] (phase 3)
foo caught by chrome at [object ChromeWindow @ 0x1cc96b0 (native @ 0x1cc48e0)] (phase 3)
dispatchCustomFoo

Actual results at step 4:
foo caught by content (phase 1)
foo caught by content (phase 3)
dispatchCustomFoo

Expected results at step 8, and actual results at step 8, match expected results at step 4.  So that part isn't a bug.

Source code for the attachments (to assure you I'm not doing anything evil in chrome)
https://bugzilla.mozilla.org/attachment.cgi?id=207102&content_type=text/plain
https://bugzilla.mozilla.org/attachment.cgi?id=207103&content_type=text/plain
Severity: major → normal
Summary: Content-dispatched events no longer visit chrome → Content-dispatched events do not visit chrome across domains

Comment 5

12 years ago
As bz said, you need to use the 4th parameter of the addEventListener in chrome to
listen untrusted events.
http://lxr.mozilla.org/seamonkey/source/dom/public/idl/events/nsIDOMNSEventTarget.idl#67
Severity: normal → major
(Reporter)

Comment 6

12 years ago
target.addEventListener("foo", dumpEvent, (phase), true).  Thanks, Boris.
Severity: major → normal
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.