event listeners not triggered in web extensions with custom EventTarget
Categories
(WebExtensions :: General, defect)
Tracking
(firefox125 affected, firefox126 affected, firefox127 affected)
People
(Reporter: info, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0
Steps to reproduce:
PreReq.:
- all platforms
- Firefox (latest, occurs since many versions ago)
- WebExtension V2 / V3 (both version affected)
I have several content scripts in a WebExtension, all organized in classes. Assume I have two classes connected by the event executed
.
FooBar.js
class FooBar extends EventTarget
{
execute()
{
this.dispatchEvent(
new Event( 'executed' )
);
}
}
BarFoo.js
class BarFoo
{
#message = 'fooBar executed';
execute()
{
const fooBar = new FooBar();
fooBar.addEventListener( 'executed', this.#fooBar_executed );
fooBar.execute();
}
#fooBar_executed = ( event ) =>
{
console.log( this.#message );
}
}
main.js
( new BarFoo() )
.execute();
manifest.json
{
...,
"manifest_version": 2,
"content_scripts": [
{
"matches": [
"https://example.com/*"
],
"js": [
"FooBar.js",
"BarFoo.js",
"main.js"
]
}
}
}
Actual results:
The event will be dispatched with no exception nor error. The event listener won't be triggered.
Expected results:
The event listener must be triggered.
Comment 1•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Events' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Updated•2 months ago
|
Comment 2•1 month ago
|
||
Hello,
I tried reproducing the issue on the latest Nightly (127.0a1/20240506214401) under Windows 10 x64 using the attached extension, however I’m not sure of the results I’ve observed.
I’ve loaded the extension via about:debugging and accessed https://example.com/. I’ve then checked the browser console, the web console and the extension console and I’m not seeing any of the messages logged there as they, I assume, are supposed to be logged according to the BarFoo.js
file contents.
Is this the issue you are reporting? i.e. the messages should have been logged once the event listener was triggered, but since the event listener does not trigger, those messages are not logged to console?
Yes, you obversed the results correctly.
You can replace the console logging with anything innocuous. Like manipulating the DOM or anything else one can expect a web extension is able to do. And it won't work then. I've tried a lot of scenarios - none of them worked.
This bug remains since a lot of versions before the latest (as of today). But I didn't report it here because I thought I did something in accordance with any unknown web extension guideline. But a user in StockOverflow confirmed my example code working in Chrome but not in FireFox.
Ref.:
(In reply to info from comment #3)
[...] But I didn't report it here because I thought I did something wrong in accordance with any unknown web extension guideline. [...]
Comment 5•1 month ago
|
||
Thank you for the confirmation of the observed results.
Considering the above, I reproduced the issue on the latest Nightly (127.0a1/20240507214419), Beta (126.0/20240506203248) and Release (125.0.3/20240425211020) under Windows 10 x64 and Ubuntu 22.04 LTS.
Comment 6•1 month ago
|
||
The severity field is not set for this bug.
:willdurand, could you have a look please?
For more information, please visit BugBot documentation.
Comment 7•29 days ago
|
||
The example breaks in Manifest Version 2 and Manifest Version 3 for different reasons.
In both cases the difference is due to Xrays in Firefox.
First, Manifest Version 3: an error is thrown, fooBar.execute is not a function
. This is because new FooBar()
returns an EventTarget
instance due to bug 1820521. if you call FooBar.prototype.execute.call(fooBar)
, then I see fooBar executed
as expected.
In Manifest Version 2, fooBar
is an instance of FooBar
because EventTarget
belongs to the sandbox (explained at https://bugzilla.mozilla.org/show_bug.cgi?id=1896267#c5). However, nothing is logged for some reason. This was already filed before at bug 1473306.
Description
•