compose-window-init event only fired some times
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
People
(Reporter: axel.grude, Unassigned)
Details
|
Reporter | |
Comment 1•7 years ago
•
|
||
My Add-on (SmartTemplate4) relies on the compose-window-init event which should be fired here:
however the event only seems to fire randomly / sometimes; this makes my Add-on not work most of the time. I am not sure what might lead to the event not being fired but I have seen that the line for dispatchEvent was called without hitting a breakpoint on the Event constructor.
I am currently debating whether writing a wrapper function for ** ComposeStartup()** may be a viable solution. SmartTemplate⁴ is only useful if it can react to the NotifyComposeBodyReady event, which is currently hinging on another function (SmartTemplate4.initListener) based on compose-window-init.
|
|
Reporter | |
Comment 2•7 years ago
•
|
||
I made a workaround that currently functions well on Thunderbird 68b01
However in Thunderbird Daily 69 the window onload event will fire before my overlayed JavaScript files get a chance to execute.
from the manifest:
overlay chrome://messenger/content/messengercompose/messengercompose.xul chrome://smarttemplate4/content/messengercomposeOverlay.xul
from the overlay xul file:
<script type="application/javascript" src="chrome://smarttemplate4/content/smartTemplate-main.js"/>
<script type="application/javascript" src="chrome://smarttemplate4/content/smartTemplate-compose.js"/>
<script type="application/javascript" src="chrome://smarttemplate4/content/smartTemplate-overlay.js"/>
<script type="application/javascript" src="chrome://smarttemplate4/content/smartTemplate-util.js"/>
<script type="application/javascript" src="chrome://smarttemplate4/content/smartTemplate-composer.js"/>
...
smartTemplate-composer.js contains the following function:
window.setTimeout (function()
{
const util = SmartTemplate4.Util,
logDebugOptional = util.logDebugOptional.bind(util),
isDebugComposer = SmartTemplate4.Preferences.isDebugOption('composer');
let txt = "unknown";
try { txt = window.document.firstElementChild.getAttribute('windowtype'); }
catch(ex) {;}
logDebugOptional('composer', "Adding compose-window-init event listener for msgcomposeWindow...");
let composer = document.getElementById("msgcomposeWindow");
composer.addEventListener("compose-window-init", SmartTemplate4.initListener, false);
SmartTemplate4.init();
// debugger;
util.logDebug("Calling SmartTemplate4.composer.load from window: " + txt);
// safety for when the compose-window-init event does not fire (Tb 67+)
if (typeof ComposeStartup == 'function') {
// if (util.versionGreaterOrEqual(util.AppverFull, "61"))
if (!SmartTemplate4.ComposeStartup) {
if (isDebugComposer) debugger;
SmartTemplate4.ComposeStartup = ComposeStartup;
ComposeStartup = function() {
logDebugOptional('composer','Calling ComposeStartup Wrapper');
SmartTemplate4.ComposeStartup();
logDebugOptional('composer','Calling initListener');
SmartTemplate4.initListener(true);
}
}
}
SmartTemplate4.composer.load();
},10
);
... by the time the line:
composer.addEventListener("compose-window-init", SmartTemplate4.initListener, false);
is executed, ComposeStartup() has already been executed and the "compose-window-init" event dispatched. I wonder if there is any way to make sure the onload is not executed until all overlays are loaded. If not, I will have to think of other ways (lower level window management) to check whether the composer window has been loaded.
|
||
Comment 3•7 years ago
|
||
So basically you have a XUL add-on that uses TB's overlay loader. And now there is a timing issue between that stuff being loaded onto the compose window, right. Sounds like playing with fire.
Geoff, can you comment, please.
|
|
Reporter | |
Comment 4•7 years ago
•
|
||
I guess. but the question is, is there a reasonable / more reliable way to consume the ready events from Thunderbird's child windows? I am happy to rewrite my code if you can show me a way - obviously my assumption that the script
MsgComposeCommands.js (which is loaded from xul)
and my own scripts (which are part of an overlayed xul) should both be executed when the document is ready (after all XUL has loaded) - something that worked up to thunderbird 68. If there is new rules, how else would I listen to these events? Is there a way to load my scripts earlier?
|
||
Comment 5•7 years ago
|
||
Theoretically, scripts on windows loaded after TB start-up should run before the load event. Practically, I'm not certain that is always the case. I just made a minimal extension listening for load and compose-window-init events and it worked fine.
The setTimeout(… , 10) in your code could be a factor although it doesn't seem like it should be. I can't see why you have it there but I guess there's a reason.
You could check document.readyState == "complete" which would mean the events you're listening for have already fired.
|
|
Reporter | |
Comment 6•7 years ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #5)
The
setTimeout(… , 10)in your code could be a factor although it doesn't seem like it should be. I can't see why you have it there but I guess there's a reason.
I tried the suggestion of calling the function directly, like so:
(function()
{
...
SmartTemplate4.composer.load()
...
}) ();
but then I am getting an error on the load line:
({load:(function st4_composerLoad() {
..
})}) is not a function
see https://pastebin.com/dPK8gzRH
not sure what I am doing wrong..
|
|
||
Comment 7•7 years ago
|
||
Add a semicolon on line 56.
|
|
Reporter | |
Comment 8•7 years ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #7)
Add a semicolon on line 56.
thanks - that actually helped; it even made the code more resilient (working every time) in Tb68 beta2. what did the JS interpreter think beforehand? did it think the function in parens was an argument to the previous object?
|
|
||
Comment 9•7 years ago
|
||
Yes, I'd think so.
|
||
Updated•3 years ago
|
Description
•