flypig.co.uk

I'm still trying to track down the reason for the following error today:

JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 541:
    NotFoundError: WindowGlobalChild.getActor:
    No such JSWindowActor 'LoginManager'

It's being a bit elusive, because there doesn't seem to be any clear difference between the way the LoginManager is set up on ESR 78 compared to ESR 91.

So I thought I should let it settle overnight. One possibility I came up with during this pondering process was that there's an error during the initialisation of LoginManager that's resulting in it not becoming available for use later.

But a careful check of the debug output prior to the above error doesn't give any indication that anything like this is going wrong. Here's the entire output.

[defaultuser@Xperia10III gecko]$ sailfish-browser
[D] unknown:0 - Using Wayland-EGL
library "libutils.so" not found
library "libcutils.so" not found
library "libhardware.so" not found
library "android.hardware.graphics.mapper@2.0.so" not found
library "android.hardware.graphics.mapper@2.1.so" not found
library "android.hardware.graphics.mapper@3.0.so" not found
library "android.hardware.graphics.mapper@4.0.so" not found
library "libc++.so" not found
library "libhidlbase.so" not found
library "libgralloctypes.so" not found
library "android.hardware.graphics.common@1.2.so" not found
library "libion.so" not found
library "libz.so" not found
library "libhidlmemory.so" not found
library "android.hidl.memory@1.0.so" not found
library "vendor.qti.qspmhal@1.0.so" not found
greHome from GRE_HOME:/usr/bin
libxul.so is not found, in /usr/bin/libxul.so
Created LOG for EmbedLiteTrace
[D] onCompleted:105 - ViewPlaceholder requires a SilicaFlickable parent
Created LOG for EmbedLite
Created LOG for EmbedPrefs
Created LOG for EmbedLiteLayerManager
JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 541:
    NotFoundError: WindowGlobalChild.getActor:
    No such JSWindowActor 'LoginManager'
JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 541:
    NotFoundError: WindowGlobalChild.getActor:
    No such JSWindowActor 'LoginManager'
Call EmbedLiteApp::StopChildThread()

Apart from the LoginManager error the output is looking surprisingly clean now. But I do still need to figure this one out.

Another possibility that crossed my mind is that there's a problem with the way WindowGlobalChild::GetActor() is working in general. In other words, the issue isn't really with the LoginManager at all but rather with the code for accessing it.

On the face of it this seems unlikely: the error is only showing for the LoginManager and no other actors. And there are plenty of other uses. I count 167 instances, only 9 of which are for LoginManager.

$ grep -rIn ".getActor(\"" * --include="*.js*" | wc -l
167
$ grep -rIn ".getActor(\"LoginManager\")" * --include="*.js*" | wc -l
9

Nevertheless it is possible that only the LoginManager happens to be being requested. Unlikely, but possible.

To try to find out, I've added some debugging code so that something will be output whenever GetActor() is called off the WindowGlobalChild:

already_AddRefed<JSWindowActorChild> WindowGlobalChild::GetActor(
    JSContext* aCx, const nsACString& aName, ErrorResult& aRv) {

  MOZ_LOG(BrowsingContext::GetLog(), LogLevel::Debug, ("ACTOR: GetActor: ",
      PromiseFlatCString(aName)));

  return JSActorManager::GetActor(aCx, aName, aRv)
      .downcast<JSWindowActorChild>();
}

I've also added some debugging closer to the action in LoginManagerChild.jsm:

  static forWindow(window) {
    let windowGlobal = window.windowGlobalChild;
    if (windowGlobal) {
      dump("ACTOR: Getting LoginManager\n");
      return windowGlobal.getActor("LoginManager");
    }

    return null;
  }

Let's see if either of those provide any insight. Unfortunately these changes require a build, so it will take a while. During the build, I'm going to look into the third possibility I thought about: that the LoginManager isn't being registered correctly.

[...]

Before the build completes I realise that all of the action registering and unregistering actors happens in JSActorService.cpp. There's a hash table called mWindowActorDescriptors which stores all of the actors, alongside registration and removal methods. To help understand what's going on there it will be helpful to add some debug output here too, to expose any actors that are added or removed here. So I've cancelled the build while I add it in.

Here's an example:

void JSActorService::RegisterWindowActor(const nsACString& aName,
                                         const WindowActorOptions& aOptions,
                                         ErrorResult& aRv) {
  MOZ_ASSERT(NS_IsMainThread());
  MOZ_ASSERT(XRE_IsParentProcess());

  printf("ACTOR: RegisterWindowActor: %s", PromiseFlatCString(aName));
[...]

I've added similar debug output for UnregisterWindowActor(), RegisterProcessActor() and UnregisterProcessActor() as well.

Now I've set it building again. Time for a break while my laptop does all the work for me.

[...]

It turns out the break was longer than I anticipated. I thought the build might finish quickly but it's still chugging away several hours later as it heads towards bed time.

So I'll have to pick this up in the morning once it's built. I'm looking forward to finding out what's really happening with this Actor code.

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.