flypig.co.uk

Happy weekend everyone! First a quick recap. Getting logging to work by fixing some small JavaScript errors in the front end code caused a segfault to trigger. This turned out to be due to the code that switches between light and dark themes. When the browser starts up it sets this theme, but the interface had changed to require a value to specify how much re-rendering is needed. For example, does the layout need updating, or can that be skipped? The C++ code was expecting this value, found null instead and promptly crashed.

The fix was to pass in a suitable value and handily the gecko devs already included a nice helper function for doing it all automatically. So I used that yesterday and now no crash.

So now it's back to rendering. I've been looking at the rendering for the last couple of days and it feels like I'm going round in circles a bit. Having log output without crashes is going to help. I hope.

There are a bunch of errors all related to Services.appinfo being undefined. It might make sense to fix these to get a load more modules potentially working quite easily. But for now I'm just going to take a note of it.

JavaScript error: file:///usr/lib64/mozembedlite/components/
  UserAgentOverrideHelper.js, line 110: TypeError: Services.appinfo is undefined
JavaScript error: resource://gre/modules/EnterprisePoliciesParent.jsm, line 500:
  TypeError: Services.appinfo is undefined
JavaScript error: resource://gre/modules/URLQueryStrippingListService.jsm, line
  42: TypeError: Services.appinfo is undefined
JavaScript Error: "TypeError: Services.appinfo is undefined" {file:
  "resource://gre/modules/LoginRecipes.jsm" line: 56}
JavaScript Error: "1696965251556       addons.manager  ERROR   startup failed:
  TypeError: Services.appinfo is undefined(resource://gre/modules/AddonManager.jsm:680:1) JS Stack trace: startup@AddonManager.jsm:680:1 startup@AddonManager.jsm:3511:26
  observe@addonManager.js:81:29" {file: "resource://gre/modules/Log.jsm"
  line: 723}
JavaScript error: resource://gre/modules/Region.jsm, line 119: TypeError:
  Services.appinfo is undefined

Let's focus on the SetIsActive and SuspendRendering/ResumeRendering states now.

For the first an important method is EmbedLiteViewChild::RecvSetIsActive() since this seems to propagate the active flag through to lots of different places: PresShell, nsWebBrowser, EmbedLitePuppetWidget and DocShell. My plan is to step through this method to check they're all getting set appropriately, and if not, figure out why not.

First here's the backtrace we get when we hit the breakpoint.

Thread 8 "GeckoWorkerThre" hit Breakpoint 1, mozilla::embedlite::
  EmbedLiteViewChild::RecvSetIsActive (this=0x7f885831b0,
    aIsActive=@0x7f9f4f3600: true)
    at ${PROJECT}/gecko-dev/mobile/sailfishos/embedshared/EmbedLiteViewChild.cpp:607
607     ${PROJECT}/gecko-dev/mobile/sailfishos/embedshared/EmbedLiteViewChild.cpp:
    No such file or directory.
(gdb) bt
#0  mozilla::embedlite::EmbedLiteViewChild::RecvSetIsActive (this=0x7f885831b0,
    aIsActive=@0x7f9f4f3600: true)
    at ${PROJECT}/gecko-dev/mobile/sailfishos/embedshared/EmbedLiteViewChild.cpp:607
#1  0x0000007fba3094e0 in mozilla::embedlite::PEmbedLiteViewChild::OnMessageReceived
    (this=0x7f885831b0, msg__=...) at PEmbedLiteViewChild.cpp:1218
#2  0x0000007fba2f6e84 in mozilla::embedlite::PEmbedLiteAppChild::OnMessageReceived
    (this=, msg__=...)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/ipc/ProtocolUtils.h:675
#3  0x0000007fba1e3690 in mozilla::ipc::MessageChannel::DispatchAsyncMessage
    (this=this@entry=0x7f88876968, aProxy=aProxy@entry=0x7ef4004830, aMsg=...)
[..]
#29 0x0000007fb79cf89c in ?? () from /lib64/libc.so.6
(gdb) 

The app is paused at the point the breakpoint hit. Now it's time to step through the code.

(gdb) n
Missing separate debuginfo for /usr/lib64/libnssckbi.so
Try: zypper install -C "debuginfo(build-id)=c2e22ddaa9e2d7802fd7ff14979ba02fb6508bcd"
Missing separate debuginfo for /usr/lib64/libtasn1.so.6
Try: zypper install -C "debuginfo(build-id)=95f83c2cec19f8b9030e796b6c25c31a10c185e8"
[LWP 7851 exited]
310     ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:
        No such file or directory.
(gdb) n
867     ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsCOMPtr.h:
        No such file or directory.
(gdb) n
313     ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:
        No such file or directory.
(gdb) n
609       RefPtr presShell = mHelper->GetTopLevelPresShell();
(gdb) n
610       if (aIsActive) {
(gdb) p aIsActive
$1 = (const bool &) @0x7f9f4df600: true
(gdb) n
616           mWebBrowser->FocusActivate(nsFocusManager::GenerateFocusActionId());
(gdb) n
617           LOGT("Activate browser");
(gdb) n
624       EmbedLitePuppetWidget *widget = GetPuppetWidget();
(gdb) n
625       if (widget) {
(gdb) p widget
$2 = (mozilla::embedlite::EmbedLitePuppetWidget *) 0x7f88587490
(gdb) n
626         widget->SetActive(aIsActive);
(gdb) n
630       nsCOMPtr docShell = do_GetInterface(mWebNavigation);
(gdb) n
867     ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsCOMPtr.h:
        No such file or directory.
(gdb) p docShell
$3 = { = {mRawPtr = 0x7f887b3b18}, }
(gdb) n
635       mWidget->Show(aIsActive);
(gdb) n
313     ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:
        No such file or directory.
(gdb) n
638       if (aIsActive) {
(gdb) n
639         RecvScheduleUpdate();
(gdb) n
641       return IPC_OK();
(gdb) n
630       nsCOMPtr docShell = do_GetInterface(mWebNavigation);
(gdb) n
609       RefPtr presShell = mHelper->GetTopLevelPresShell();
(gdb) c
Continuing.

This is quite hard to follow without actually having stepped through it, so let me highlight a few parts. First it's worth noting that this all looks pretty sensible. The widget is set to something valid aIsActive is set to true.

To try to progress further I've also put breakpoints on a few more things to see if there's any noticeable difference between ESR 78 and ESR 91.

What I find is that on ESR 78 the CompositorOGL::BeginFrame() is called (unsurprisingly, every time a frame is rendered). But on ESR 91 it's not being called at all. I think it's worth finding out why.

Here's the backtrace for it on ESR 78:

(gdb) bt
#0  mozilla::layers::CompositorOGL::BeginFrame (this=0x7ed0003450,
    aInvalidRegion=..., aClipRect=..., aRenderBounds=..., aOpaqueRegion=...)
    at gfx/
    layers/opengl/CompositorOGL.cpp:967
#1  0x0000007ff2999070 in mozilla::layers::CompositorOGL::BeginFrameForWindow
    (this=, aInvalidRegion=..., aClipRect=..., 
    aRenderBounds=..., aOpaqueRegion=...) at /usr/src/debug/
    xulrunner-qt5-78.15.1+git33.2-1.21.1.jolla.aarch64/gfx/layers/opengl/
    CompositorOGL.cpp:793
#2  0x0000007ff2a5fcc8 in mozilla::layers::LayerManagerComposite::Render
    (this=this@entry=0x7ed021df20, aInvalidRegion=..., aOpaqueRegion=...)
    at 
    obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:313
#3  0x0000007ff2a602c4 in mozilla::layers::LayerManagerComposite::UpdateAndRender
    (this=this@entry=0x7ed021df20)
    at gfx/
    layers/composite/LayerManagerComposite.cpp:647
#4  0x0000007ff2a60514 in mozilla::layers::LayerManagerComposite::EndTransaction
    (aFlags=mozilla::layers::LayerManager::END_DEFAULT, aTimeStamp=..., 
    this=0x7ed021df20) at /usr/src/debug/
    xulrunner-qt5-78.15.1+git33.2-1.21.1.jolla.aarch64/gfx/layers/composite/
    LayerManagerComposite.cpp:566
#5  mozilla::layers::LayerManagerComposite::EndTransaction (this=0x7ed021df20,
    aTimeStamp=..., aFlags=mozilla::layers::LayerManager::END_DEFAULT)
    at gfx/
    layers/composite/LayerManagerComposite.cpp:536
#6  0x0000007ff2a87f9c in mozilla::layers::CompositorBridgeParent::
    CompositeToTarget (this=0x7fb89bdf20, aId=..., aTarget=0x0,
    aRect=)
    at 
    obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:313
#7  0x0000007ff4d8288c in mozilla::embedlite::EmbedLiteCompositorBridgeParent::
    CompositeToDefaultTarget (this=0x7fb89bdf20, aId=...)
    at mobile/
    sailfishos/embedthread/EmbedLiteCompositorBridgeParent.cpp:159
#8  0x0000007ff2a67988 in mozilla::layers::CompositorVsyncScheduler::Composite
    (this=0x7fb8cd6390, aId=..., aVsyncTimestamp=...)
    at gfx/
    layers/ipc/CompositorVsyncScheduler.cpp:249
#9  0x0000007ff2a65ff0 in mozilla::detail::RunnableMethodArguments, mozilla::TimeStamp>::
    applyImpl, mozilla::TimeStamp), StoreCopyPassByConstLRef >, StoreCopyPassByConstLRef, 0ul, 1ul> (args=..., m=, o=)
    at 
    obj-build-mer-qt-xr/dist/include/nsThreadUtils.h:925
[...]
#22 0x0000007fef65b89c in ?? () from /lib64/libc.so.6
(gdb) 

What we know is that on ESR 91, something in this backtrace is skipping over something. A few more breakpoints and it becomes clear that CompositorBridgeParent::CompositeToTarget() is being entered. So why isn't it calling LayerManagerComposite::EndTransaction?

Here's a potentially interesting aside. I'm using gdb for debugging. By default it's configured to break on signals. If you leave a connection unattended for too long it will get closed at by the other and and the operating system will send a SIGPIPE (broken pipe) signal to the process that opened the connection.

When you're debugging it's common to leave the process in a suspended state, blocked from executing by the debugger. If you do this for too long the SIGPIPE signal will be sent for every open connection (which for a browser can be quite a few). Each one halts execution. It's a pain because you have to tell the debugger to continue after every one and it completely breaks the debugging flow.

Anyway, the solution is to run the following command in gdb:

handle SIGPIPE nostop

This tells the debugger not to halt the process if it receives the SIGPIPE signal. It's a simple step, but saves a lot of hassle.

Now back to the issue at hand. Stepping through the code it looks like the problem is that mLayerManager has its mRoot value unset. As a consequence CanComposite() is returning false:

bool CompositorBridgeParent::CanComposite() {
  return mLayerManager && mLayerManager->GetRoot() && !mPaused;
}

Here's the result of stepping through:

Thread 34 "Compositor" hit Breakpoint 6, mozilla::layers::
    CompositorBridgeParent::CompositeToTarget (this=0x7f888b4b10, aId=...,
    aTarget=0x0, aRect=0x0)
    at gfx/
    layers/ipc/CompositorBridgeParent.cpp:936
936                                                    const gfx::IntRect* aRect) {
(gdb) n
937       AUTO_PROFILER_TRACING_MARKER("Paint", "Composite", GRAPHICS);
(gdb) n
938       AUTO_PROFILER_LABEL("CompositorBridgeParent::CompositeToTarget", GRAPHICS);
(gdb) n
939       PerfStats::AutoMetricRecording autoRecording;
(gdb) n
943       TimeStamp start = TimeStamp::Now();
(gdb) n
945       if (!CanComposite()) {
(gdb) p CanComposite()
$4 = false
(gdb) p mLayerManager
$5 = {mRawPtr = 0x7eb8113150}
(gdb) p mLayerManager.mRawPtr->mRoot
$6 = {mRawPtr = 0x0}
(gdb) p mPaused
$7 = false
(gdb) 

Compare this with stepping through the ESR 78 code:

Thread 39 "Compositor" hit Breakpoint 4, mozilla::layers::
    CompositorBridgeParent::CompositeToTarget (this=0x7fb89bdf20, aId=...,
    aTarget=0x0, aRect=0x0)
    at gfx/
    layers/ipc/CompositorBridgeParent.cpp:932
932                                                    const gfx::IntRect* aRect) {
(gdb) n
933       AUTO_PROFILER_TRACING_MARKER("Paint", "Composite", GRAPHICS);
(gdb) n
934       AUTO_PROFILER_LABEL("CompositorBridgeParent::CompositeToTarget", GRAPHICS);
(gdb) n
935       PerfStats::AutoMetricRecording autoRecording;
(gdb) n
939       TimeStamp start = TimeStamp::Now();
(gdb) n
941       if (!CanComposite()) {
(gdb) p CanComposite()
Cannot evaluate function -- may be inlined
(gdb) p mLayerManager
$1 = {mRawPtr = 0x7ed021df20}
(gdb) p mLayerManager.mRawPtr->mRoot
$2 = {mRawPtr = 0x7ed027e880}
(gdb) p mPaused
$3 = false

We can see the crucial difference here, which is that mRoot is set. It's also worth exploring the mLayerManager a bit to see what its polymorphism hierarchy looks like. Knowing these details helps understand what methods, potentially overridden, are likely to be called and which source files are relevant. It also highlights how powerful gdb is.

(gdb) explore mLayerManager
The value of 'mLayerManager' is a struct/class of type 'RefPtr' with the following fields:

  mRawPtr = 

Enter the field number of choice: 0
'mLayerManager.mRawPtr' is a pointer to a value of type
    'mozilla::layers::HostLayerManager'
Continue exploring it as a pointer to a single value [y/n]: y

      The value of '*(mLayerManager.mRawPtr)' is a struct/class of type
      'mozilla::layers::HostLayerManager' with the following fields:

  mozilla::layers::LayerManager = 
    mDebugOverlayWantsNextFrame = false .. (Value of type 'bool')
   mImageCompositeNotifications = '>
                  mWarningLevel = 0 .. (Value of type 'float')
                      mWarnTime = 
                   mDiagnostics =  >'>
            mCompositorBridgeID = 
                 mLastPaintTime = 
               mRenderStartTime = 
           mCompositionRecorder =  >'>
               mCompositionTime = 
            mCompositeUntilTime = 

Enter the field number of choice: 0
The value of '(*(mLayerManager.mRawPtr)).mozilla::layers::LayerManager' is a
  struct/class of type 'mozilla::layers::LayerManager' with the following fields:

  mozilla::layers::FrameRecorder = 
                         mRefCnt = 
                           mRoot = '>
                       mUserData = 
                      mDestroyed = false .. (Value of type 'bool')
        mSnapEffectiveTransforms = true .. (Value of type 'bool')
                  mRegionToClear = 
                             mId = 
                  mInTransaction = false .. (Value of type 'bool')
                    mContainsSVG = false .. (Value of type 'bool')
             mAnimationReadyTime = 
              mPaintedPixelCount = 
                        mPayload = '>
           mPendingScrollUpdates = 

I've now put a breakpoint on LayerManagerComposite::SetRoot() in the ESR 78 code to find out where it gets called from, in the hope of finding out why it's not (presumably) getting called on ESR 91.

And the answer is: it isn't getting called!

But there are six other classes which have a SetRoot() method. Maybe it's being set by one of these instead?

(gdb) b SetRoot
Breakpoint 7 at 0x7ff29af3e0: SetRoot. (6 locations)
(gdb) info b
Num     Type           Disp Enb Address            What
7       breakpoint     keep y            
7.1                         y     0x0000007ff29af3e0 in WebRenderLayerManager::
                                  SetRoot(mozilla::layers::Layer*) 
                                                   at WebRenderLayerManager.cpp:682
7.2                         y     0x0000007ff2a0f5f0 in BasicLayerManager::
                                  SetRoot(mozilla::layers::Layer*) 
                                                   at RefPtr.h:187
7.3                         y     0x0000007ff2a22928 in ClientLayerManager::
                                  SetRoot(mozilla::layers::Layer*) 
                                                   at ClientLayerManager.cpp:153
7.4                         y     0x0000007ff2a22980 in ClientLayerManager::
                                  SetRoot(mozilla::layers::Layer*) 
                                                   at RefPtr.h:313
7.5                         y     0x0000007ff2a4dca0 in LayerManagerComposite::
                                  SetRoot(mozilla::layers::Layer*) 
                                                   at RefPtr.h:187
7.6                         y     0x0000007ff2a94928 in ShadowLayerForwarder::
                                  SetRoot(mozilla::layers::ShadowableLayer*) 
                                                   at ShadowLayers.cpp:297
(gdb) 

A little incongruously the ESR 91 build only has five such methods.

(gdb) break SetRoot
Breakpoint 9 at 0x7fba7d5400: SetRoot. (5 locations)
(gdb) info break
Num     Type           Disp Enb Address            What
9       breakpoint     keep y            
9.1                         y     0x0000007fba7d5400 in WebRenderLayerManager::
                                  SetRoot(mozilla::layers::Layer*) 
                                                   at WebRenderLayerManager.cpp:748
9.2                         y     0x0000007fba8698ac in BasicLayerManager::
                                  SetRoot(mozilla::layers::Layer*) 
                                                   at RefPtr.h:187
9.3                         y     0x0000007fba8799f0 in ClientLayerManager::
                                  SetRoot(mozilla::layers::Layer*) 
                                                   at RefPtr.h:514
9.4                         y     0x0000007fba88c4e0 in LayerManagerComposite::
                                  SetRoot(mozilla::layers::Layer*) 
                                                   at RefPtr.h:187
9.5                         y     0x0000007fba8da6d8 in ShadowLayerForwarder::
                                  SetRoot(mozilla::layers::ShadowableLayer*) 
                                                   at ShadowLayers.cpp:301
(gdb) 

On ESR 78 it's the ClientLayerManager version which is being called:

Thread 10 "GeckoWorkerThre" hit Breakpoint 7, ClientLayerManager::SetRoot
    (this=0x7fb8cdc820, aLayer=0x7fb8722560)
    at gfx/layers/client/ClientLayerManager.cpp:153
153     void ClientLayerManager::SetRoot(Layer* aLayer) {
(gdb) bt
#0  mozilla::layers::ClientLayerManager::SetRoot (this=0x7fb8cdc820,
    aLayer=0x7fb8722560)
    at gfx/layers/client/ClientLayerManager.cpp:153
#1  0x0000007ff423c36c in mozilla::PresShell::Paint (this=this@entry=0x7fb864a0f0,
    aViewToPaint=aViewToPaint@entry=0x7fb8cef9b0, aDirtyRegion=..., 
    aFlags=aFlags@entry=mozilla::PaintFlags::PaintLayers)
    at layout/base/PresShell.cpp:6282
#2  0x0000007ff40b30ac in nsViewManager::ProcessPendingUpdatesPaint
    (this=this@entry=0x7fb8cef930, aWidget=aWidget@entry=0x7fb8cefa30)
    at obj-build-mer-qt-xr/dist/include/nsTArray.h:554
#3  0x0000007ff40b33c0 in nsViewManager::ProcessPendingUpdatesForView
    (this=this@entry=0x7fb8cef930, aView=, 
    aFlushDirtyRegion=aFlushDirtyRegion@entry=true) at view/nsViewManager.cpp:395
#4  0x0000007ff40b3b50 in nsViewManager::ProcessPendingUpdates (this=0x7fb8cef930)
    at view/nsViewManager.cpp:1018
#5  nsViewManager::ProcessPendingUpdates (this=)
    at view/nsViewManager.cpp:1004
#6  0x0000007ff40b3c0c in nsViewManager::WillPaintWindow
    (this=this@entry=0x7fb8cef930, aWidget=0x7fb8cefa30)
    at view/nsViewManager.cpp:664
#7  0x0000007ff40b3c88 in nsView::WillPaintWindow
    (this=, aWidget=)
    at view/nsView.cpp:1048
#8  0x0000007ff4d98344 in mozilla::embedlite::PuppetWidgetBase::Invalidate
    (aRect=..., this=0x7fb8cefa30)
    at mobile/sailfishos/embedshared/PuppetWidgetBase.cpp:268
#9  mozilla::embedlite::PuppetWidgetBase::Invalidate (this=0x7fb8cefa30, aRect=...)
    at mobile/sailfishos/embedshared/PuppetWidgetBase.cpp:253
#10 0x0000007ff4d91768 in mozilla::embedlite::EmbedLitePuppetWidget::Show
    (this=0x7fb8cefa30, aState=)
    at mobile/sailfishos/embedshared/EmbedLitePuppetWidget.cpp:97
#11 0x0000007ff42923e8 in nsDocumentViewer::Show (this=0x7fb8ce70b0)
    at layout/base/nsDocumentViewer.cpp:2132
#12 0x0000007ff4a9cf64 in nsDocShell::SetVisibility (this=,
    aVisibility=)
    at docshell/base/nsDocShell.cpp:4742
#13 0x0000007ff4bfc78c in nsWebBrowser::SetVisibility (this=0x7fb8b1e190,
    aVisibility=true)
    at obj-build-mer-qt-xr/dist/include/nsCOMPtr.h:857
#14 0x0000007ff4d92958 in mozilla::embedlite::EmbedLiteViewChild::RecvSetIsActive
    (this=0x7fb8cde9d0, aIsActive=@0x7fde8d68f0: true)
    at obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:313
[...]
#38 0x0000007fef65b89c in ?? () from /lib64/libc.so.6
(gdb) 

It gets in some other places too, including the ShadowLayerForwarder version. On ESR 91 none of them get called, so maybe we're getting closer.

In this callstack it looks like PresShell::Paint() is being called in ESR 91 but nsLayoutUtils::PaintFrame() is not, so that's worth investigating.

And here we have something substantial. In ESR 91 mIsActive is set to false. As a result the Paint() method is being exited almost immediately because of this:

  if (!mIsActive) {
    return;
  }

I've set a breakpoint on PresShell::SetIsActive() and on ESR 91 get a backtrace like this:

(gdb) bt
#0  mozilla::PresShell::SetIsActive (this=this@entry=0x7f889b4c30, aIsActive=false)
    at layout/base/PresShell.cpp:10865
#1  0x0000007fbc2236e8 in mozilla::PresShell::ActivenessMaybeChanged
    (this=this@entry=0x7f889b4c30)
    at layout/base/PresShell.cpp:10794
#2  0x0000007fbc247dbc in mozilla::PresShell::Init (this=this@entry=0x7f889b4c30, aPresContext=aPresContext@entry=0x7f885e0f10,
    aViewManager=aViewManager@entry=0x7f885e1a60) at layout/base/PresShell.cpp:1035
#3  0x0000007fbab910ac in mozilla::dom::Document::CreatePresShell
    (this=0x7f885dcec0, aContext=0x7f885e0f10, aViewManager=0x7f885e1a60)
    at dom/base/Document.cpp:6637
#4  0x0000007fbc27b7d4 in nsDocumentViewer::InitPresentationStuff
    (this=this@entry=0x7f885d9c60, aDoInitialReflow=aDoInitialReflow@entry=false)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:289
#5  0x0000007fbc27d4d8 in nsDocumentViewer::InitInternal (this=0x7f885d9c60,
    aParentWidget=, aState=aState@entry=0x0, aActor=0x0,
    aBounds=..., aDoCreation=aDoCreation@entry=true,
    aNeedMakeCX=aNeedMakeCX@entry=true,
    aForceSetNewDocument=aForceSetNewDocument@entry=true)
    at layout/base/nsDocumentViewer.cpp:913
#6  0x0000007fbc27d6a4 in nsDocumentViewer::Init (this=,
    aParentWidget=, aBounds=..., aActor=)
    at layout/base/nsDocumentViewer.cpp:682
#7  0x0000007fbc969a1c in nsDocShell::SetupNewViewer
    (this=this@entry=0x7f88915160, aNewViewer=aNewViewer@entry=0x7f885d9c60,
    aWindowActor=aWindowActor@entry=0x0)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsCOMPtr.h:859
#8  0x0000007fbc96e740 in nsDocShell::Embed (this=this@entry=0x7f88915160,
    aContentViewer=0x7f885d9c60, aWindowActor=aWindowActor@entry=0x0,
    aIsTransientAboutBlank=aIsTransientAboutBlank@entry=true,
    aPersist=aPersist@entry=false)
    at docshell/base/nsDocShell.cpp:5552
#9  0x0000007fbc96ebb4 in nsDocShell::CreateAboutBlankContentViewer
    (this=this@entry=0x7f88915160, aPrincipal=aPrincipal@entry=0x0,
    aPartitionedPrincipal=aPartitionedPrincipal@entry=0x0, aCSP=,
    aBaseURI=0x0, aCOEP=..., aTryToSaveOldPresentation=,
    aTryToSaveOldPresentation@entry=true, aCheckPermitUnload=
    aCheckPermitUnload@entry=true, aActor=, aActor@entry=0x0)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsCOMPtr.h:859
#10 0x0000007fbc96f020 in nsDocShell::EnsureContentViewer
    (this=this@entry=0x7f88915160)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/MaybeStorageBase.h:79
#11 0x0000007fbc96f9f0 in nsDocShell::GetDocument (this=0x7f88915160) at
    docshell/base/nsDocShell.cpp:3053
#12 0x0000007fbaad8780 in nsPIDOMWindowOuter::MaybeCreateDoc (this=)
    at dom/base/nsGlobalWindowOuter.cpp:7678
#13 0x0000007fbaad8aa4 in non-virtual thunk to nsGlobalWindowOuter::WrapObject
    (JSContext*, JS::Handle) ()
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/js/HeapAPI.h:727
#14 0x0000007fba57190c in XPCConvert::NativeInterface2JSObject
    (cx=cx@entry=0x7f88233350, d=d@entry=..., aHelper=..., iid=iid@entry=0x7f9f4eb410,
    allowNativeWrapper=allowNativeWrapper@entry=true, pErr=pErr@entry=0x0)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/js/RootingAPI.h:593
#15 0x0000007fba572a44 in XPCConvert::NativeData2JS (cx=cx@entry=0x7f88233350,
    d=d@entry=..., s=s@entry=0x7f9f4eb588, type=...,
    iid=iid@entry=0x7f9f4eb410, arrlen=, pErr=pErr@entry=0x0)
    at js/xpconnect/src/XPCConvert.cpp:355
#16 0x0000007fba591ac0 in nsXPCWrappedJS::CallMethod (this=,
    methodIndex=, info=0x7fbe37e340 , 
    nativeParams=0x7f9f4eb588) at ${PROJECT}/obj-build-mer-qt-xr/dist/include/
    js/RootingAPI.h:1320
#17 0x0000007fb9e2b140 in PrepareAndDispatch (self=0x7f8849f8e0,
    methodIndex=, args=, gprData=0x7f9f4eb640, 
    fprData=0x7f9f4eb600) at xpcom/reflect/xptcall/md/unix/xptcstubs_aarch64.cpp:190
#18 0x0000007fb9e2a110 in SharedStub () at xpcom/reflect/xptcall/md/unix/
    xptcstubs_asm_aarch64.S:47
#19 0x0000007fb9dab038 in nsObserverList::NotifyObservers (this=,
    aSubject=aSubject@entry=0x7f8854c650,
    aTopic=aTopic@entry=0x7fbe2cea78 "embedliteviewcreated",
    someData=someData@entry=0x0)
    at xpcom/ds/nsTArray.h:413
#20 0x0000007fb9db6718 in nsObserverService::NotifyObservers (this=0x7f88046b10,
    aSubject=0x7f8854c650, aTopic=0x7fbe2cea78 "embedliteviewcreated",
    aSomeData=0x0) at xpcom/ds/nsObserverService.cpp:291
#21 0x0000007fbcc916f8 in mozilla::embedlite::EmbedLiteViewChild::
    InitGeckoWindow (this=0x7f885d7b40, parentId=,
    parentBrowsingContext=, isPrivateWindow=,
    isDesktopMode=false)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsCOMPtr.h:859
[...]
#47 0x0000007fb79cf89c in ?? () from /lib64/libc.so.6
(gdb)

In contrast, on ESR 78 we have the following:

Thread 10 "GeckoWorkerThre" hit Breakpoint 1, mozilla::PresShell::SetIsActive
    (this=this@entry=0x7fb864a250, aIsActive=aIsActive@entry=true)
    at layout/base/PresShell.cpp:10724
10724   nsresult PresShell::SetIsActive(bool aIsActive) {
(gdb) bt
#0  mozilla::PresShell::SetIsActive (this=this@entry=0x7fb864a250,
    aIsActive=aIsActive@entry=true)
    at layout/base/PresShell.cpp:10724
#1  0x0000007ff4acae90 in nsDocShell::SetIsActive (this=0x7fb8cea3e0,
    aIsActive=true)
    at docshell/base/nsDocShell.cpp:4607
#2  0x0000007ff4d9291c in mozilla::embedlite::EmbedLiteViewChild::
    RecvSetIsActive (this=0x7fb8cdf500, aIsActive=@0x7fde8d68f0: true)
    at mobile/sailfishos/embedshared/EmbedLiteViewChild.cpp:623
#3  0x0000007ff23d3a00 in mozilla::embedlite::PEmbedLiteViewChild::
    OnMessageReceived (this=0x7fb8cdf500, msg__=...) at
    PEmbedLiteViewChild.cpp:1158
#4  0x0000007ff23c12f0 in mozilla::embedlite::PEmbedLiteAppChild::
    OnMessageReceived (this=, msg__=...)
    at obj-build-mer-qt-xr/dist/include/mozilla/ipc/ProtocolUtils.h:866
[...]
#26 0x0000007fef65b89c in ?? () from /lib64/libc.so.6
(gdb) 

I wonder why EmbedLiteViewChild::RecvSetIsActive() isn't being called on ESR 91? Well, it turns out it is, and with the value true, but it's not sticking! I wonder why not.

This is all very messy, and needs a clear head. But it's now late here and my head is anything but clear. So time to leave this until tomorrow.

As always, if you'd like to read more about all this gecko stuff, do take a look at my full Gecko Dev Diary.