List items
Items from the current list are shown below.
Blog
14 Feb 2024 : Day 156 #
It is the morning, time to take a look into why EmbedLiteGlobalHelper.js isn't being initialised on ESR 91. We saw yesterday that this was why the Window Actors weren't being registered. If we want them registered we're going to have to get EmbedLiteGlobalHelper.js back up and running.
Now I think about it, it's not that EmbedLiteGlobalHelper.js isn't being loaded. We know it's being loaded because we see this line in the debug output when running ESR 91:
Presumably there was some error resulting from the call to ActorManagerParent.flush(), but November was a long time ago now (way back on Day 88 in fact). According to the diary entry then, the change was to remove the following error:
The results here are interesting. This has clearly brought the ActorManagerParent back to life. But there is still this error about flush() not being a function. And when comparing the code in ActorManagerParent.jsm between ESR 78 and ESR 91 it is true that this flush() method has been removed.
That leaves us with an interesting quandary. In ESR 78 the flush() function was being used to trigger initialisation of the module. Now we need something else to do the same.
Thankfully there is a really simple solution. We can just instantiate an ActorManagerParent object without calling any functions on it.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Now I think about it, it's not that EmbedLiteGlobalHelper.js isn't being loaded. We know it's being loaded because we see this line in the debug output when running ESR 91:
$ EMBED_CONSOLE=1 sailfish-browser [...] JSComp: EmbedLiteGlobalHelper.js loaded [...]That line is being directly output from the EmbedLiteGlobalHelper.js file itself:
function EmbedLiteGlobalHelper() { L10nRegistry.registerSources([new FileSource( "0-mozembedlite", ["en-US", "fi", "ru"], "chrome://browser/content/localization/ {locale}/")]) Logger.debug("JSComp: EmbedLiteGlobalHelper.js loaded"); }But! There is a line missing from here that's in the ESR 78 code:
function EmbedLiteGlobalHelper() { ActorManagerParent.flush(); L10nRegistry.registerSource(new FileSource( "0-mozembedlite", ["en-US", "fi", "ru"], "chrome://browser/content/localization/ {locale}/")) Logger.debug("JSComp: EmbedLiteGlobalHelper.js loaded"); }Could it be that the call to ActorManagerParent.flush() is what kicks the ActorManagerParent into life? Presumably there's a reason it was removed. It was most likely me that removed it, but I don't recall. But we should be able to find out.
$ git log -S "ActorManagerParent" -1 -- jscomps/EmbedLiteGlobalHelper.js commit 0bf2601425ec1d8d639255d6a7c32231e7e38eae Author: David Llewellyn-Jones <david.llewellyn-jones@jolla.com> Date: Thu Nov 23 21:55:13 2023 +0000 Remove EmbedLiteGlobalHelper.js errors Makes three changes to address errors that were coming from EmbedLiteGlobalHelper.js: 1. Use ComponentUtils.generateNSGetFactory() instead of XPCOMUtils.generateNSGetFactory(). 2. Remove call to ActorManagerParent.flush(). See Bug 1649843. 3. Use L10nRegistry.registerSources() instead of L10nRegistry.registerSource(). See Bug 1648631. See the following related upstream changes: https://phabricator.services.mozilla.com/D95206 https://phabricator.services.mozilla.com/D81243That "Bug 1648631" that's being referred to there is described as "Remove legacy JS actors infrastructure and migrate remaining actors to JSWindowActors".
Presumably there was some error resulting from the call to ActorManagerParent.flush(), but November was a long time ago now (way back on Day 88 in fact). According to the diary entry then, the change was to remove the following error:
JavaScript error: file:///usr/lib64/mozembedlite/components/ EmbedLiteGlobalHelper.js, line 32: TypeError: ActorManagerParent.flush is not a function JavaScript error: file:///usr/lib64/mozembedlite/components/ EmbedLiteGlobalHelper.js, line 34: TypeError: L10nRegistry.registerSource is not a functionWith all of the other changes we've been making, restoring the removed code to see what happens doesn't sound like the worst idea right now. Let's try it.
$ sailfish-browser [D] unknown:0 - Using Wayland-EGL [...] Created LOG for EmbedLite ACTOR: addJSProcessActors ACTOR: RegisterProcessActor: ACTOR: RegisterProcessActor: ACTOR: RegisterProcessActor: ACTOR: addJSWindowActors ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: AJavaScript error: file:///usr/lib64/mozembedlite/components/ EmbedLiteGlobalHelper.js, line 31: TypeError: ActorManagerParent.flush is not a function CTOR: RegisterWindowActor: ACTOR: RegisterWindowActor: Created LOG for EmbedPrefs Created LOG for EmbedLiteLayerManager ACTOR: Getting LoginManager ACTOR: Getting LoginManager ACTOR: Getting LoginManager ACTOR: Getting LoginManager Call EmbedLiteApp::StopChildThread()It turns out the code I added to output the name of the actors is broken: the log output is being generated, but without the name of the actor concerned. But I don't fancy doing a complete rebuild to fix that so we'll just have to do without for now.
The results here are interesting. This has clearly brought the ActorManagerParent back to life. But there is still this error about flush() not being a function. And when comparing the code in ActorManagerParent.jsm between ESR 78 and ESR 91 it is true that this flush() method has been removed.
That leaves us with an interesting quandary. In ESR 78 the flush() function was being used to trigger initialisation of the module. Now we need something else to do the same.
Thankfully there is a really simple solution. We can just instantiate an ActorManagerParent object without calling any functions on it.
function EmbedLiteGlobalHelper() { // Touch ActorManagerParent so that it gets initialised var actor = new ActorManagerParent(); L10nRegistry.registerSources([new FileSource( "0-mozembedlite", ["en-US", "fi", "ru"], "chrome://browser/content/localization/ {locale}/")]) Logger.debug("JSComp: EmbedLiteGlobalHelper.js loaded"); }Now we get a nice clean startup without any errors:
$ sailfish-browser [D] unknown:0 - Using Wayland-EGL [...] Created LOG for EmbedLiteTrace [D] onCompleted:105 - ViewPlaceholder requires a SilicaFlickable parent Created LOG for EmbedLite ACTOR: addJSProcessActors ACTOR: RegisterProcessActor: ACTOR: RegisterProcessActor: ACTOR: RegisterProcessActor: ACTOR: addJSWindowActors ACTOR: RegisterWindowActor: [...] ACTOR: RegisterWindowActor: Created LOG for EmbedPrefs Created LOG for EmbedLiteLayerManager ACTOR: Getting LoginManager ACTOR: Getting LoginManager ACTOR: Getting LoginManager ACTOR: Getting LoginManager Call EmbedLiteApp::StopChildThread()Excellent! The final step then is to remove all of the debugging code I added and see where that leaves us. With any luck, this will resolve the session history issues and allow us to head back in to checking DuckDuckGo once again.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Comments
Uncover Disqus comments