flypig.co.uk

After my distraction with moderation yesterday I'm back on track again today. You may recall I'd been looking at the BrowsingContext and why it isn't active by the time the first paint happens. I'd been comparing the execution path on an ESR 78 build with that on an ESR 91 build by stepping through both with the debugger. My aim was to find out where they diverged in a way that might cause the context to be active on one, but inactive on the other.

I continued today. There are two big difficulties. First of all the code changes that cause the problem are in the EmbedLite code and aren't reflected in the other windowing approaches (e.g. on Android, Gtk or Windows). There seems to be a hint of related code in a snippet of nsCocoaWindow.mm in the changeset. But to make things harder, changes have been layered on top of that changeset so that they're no longer entirely valid.

This means ESR 78 doesn't provide a good example to compare against any more. And because no relevant methods are firing in ESR 91 it's very hard to determine where any changes are actually needed in order to make the various methods that I need to fire actually, well, fire! So to speak.

Nevertheless today I persevered. There must be an answer to this after all (that's what I always tell myself: with open source code there's always an answer, even if it involves rewriting everything from scratch). Looking through the code I notice many hints, such as the code that suspends and resumes the compositor that's part of the CompositorBridge classes. But mostly nothing concrete.

But then a key realisation is that the code for setting the active state is actually in qtmozembed rather than gecko. I only realise this because the backtrace on some calls mysteriously vanishes way too quickly. That turned out to be because the qtmozembed methods weren't being picked up by the debugger.

The latest changes, then, are to call BrowsingContext::SetExplicitActive() directly in the EmbedLiteViewChild::RecvSetIsActive() method, like this:

  Unused << docShell->GetBrowsingContext()->SetExplicitActive(
      dom::ExplicitActiveStatus::Inactive);

Having decided this is what I wanted, the task is then to figure out how to get the SetExplicitActive() method into scope. Getting methods isn't always straightforward. It usually involves following a breadcrumb path of pointers, class inheritance and Mozilla's magical runtime introspection GetInterface() calls. After various failures I eventually settle on the following for getting hold of the BrowsingContext. You'll notice I'm skipping a null check that might turn out to be necessary, but I'm hoping it will be okay.

  nsCOMPtr docShell = do_GetInterface(mWebNavigation);
  if (NS_WARN_IF(!docShell)) {
    return IPC_OK();
  }

  Unused << docShell->GetBrowsingContext()->SetExplicitActive(
      dom::ExplicitActiveStatus::Inactive);

The partial build went through and I'm now transferring the massive 2.8 GiB resulting library over to my phone. It's big because it contains debug symbols, but I need those so I can put breakpoints on and step through the code.

After installing and debugging the new library, the good news is that the nsDisplayList::PaintRoot() method is now being called multiple times during the render, rather than not at all. This is excellent.

There are two pieces of bad news. The first is that the user interface has gone back to a state where it gets stuck. The second is that there's still no image being rendered to the screen.

But this feels like a step forwards. Tomorrow I'll have to figure out where the rendered material is actually ending up and why that's not the screen.

In the meantime, for all the other entries in my developer diary, check out the Gecko-dev Diary page.