flypig.co.uk

For the last twenty hours or so my development phone has been loyally running ESR 91 in the debugger. That's because I've been searching for a suitable breakpoint to distinguish a working render of DuckDuckGo from a failing render of DuckDuckGo.

The time spent in between has been fruitful, but before I get on to that I want to first thank simonschmeisser for the useful comment on the Sailfish Forum about remote debugging. Simon highlights the fact that Firefox can be remote debugged by a second copy of Firefox. Here's how Simon explains it:
 
This approach isn't something I've tried before and it's true that it may need some code changes, but they may not be significant changes. I've not had a chance to try this, but plan to give it a go some time over the next week if I have time. Thanks Simon for the really nice suggestion!

Going back to the curent situation, the local gdb debugger is still running so I'd better spend a little time today making use of it. Recall that yesterday we found that on ESR 91 a breakpoint on nsDisplayBackgroundImage::AppendBackgroundItemsToTop was triggered, whereas a breakpoint on nsDisplayBackgroundImage::GetInitData() wasn't.

These two are potentially significant because the latter can be found one above the former in the stack when we visit the HTML version of DuckDuckGo. Consequently, it could be that something is happening in this method to prevent the site from rendering.

This feels like a long shot, especially because the stack for the HTML version of the page is hardly likely to be equivalent to the stack for the JavaScript version of the page. Nevetheless, we can pin this down a bit more using an ESR 78 version of the browser. If we run this on the JavaScript version of the page, we might find there's some useful comparison to be made.

I've placed breakpoints on nsDisplayBackgroundImage::GetInitData() for both versions of the browser and have run them simultaneously. On ESR 91 I get a blank page, nothing rendered, and the breackpoint remains untriggered. In contrast to this on ESR 78 the breakpoint hits with the following backtrace:

Thread 8 "GeckoWorkerThre" hit Breakpoint 1,
    nsDisplayBackgroundImage::GetInitData (aBuilder=aBuilder@entry=0x7fa6e2e630,
    aFrame=aFrame@entry=0x7f88744060, aLayer=aLayer@entry=0,
    aBackgroundRect=..., aBackgroundStyle=aBackgroundStyle@entry=0x7f89d21578)
    at layout/painting/nsDisplayList.cpp:3233
3233                                          ComputedStyle* aBackgroundStyle) {
(gdb) bt
#0  nsDisplayBackgroundImage::GetInitData (aBuilder=aBuilder@entry=0x7fa6e2e630,
    aFrame=aFrame@entry=0x7f88744060, aLayer=aLayer@entry=0, 
    aBackgroundRect=..., aBackgroundStyle=aBackgroundStyle@entry=0x7f89d21578)
    at layout/painting/nsDisplayList.cpp:3233
#1  0x0000007fbc1fab50 in nsDisplayBackgroundImage::AppendBackgroundItemsToTop
    (aBuilder=aBuilder@entry=0x7fa6e2e630, aFrame=aFrame@entry=0x7f88744060, 
    aBackgroundRect=..., aList=<optimized out>, 
    aAllowWillPaintBorderOptimization=aAllowWillPaintBorderOptimization@entry=true, 
    aComputedStyle=aComputedStyle@entry=0x0, aBackgroundOriginRect=..., 
    aSecondaryReferenceFrame=aSecondaryReferenceFrame@entry=0x0, 
    aAutoBuildingDisplayList=<optimized out>, aAutoBuildingDisplayList@entry=0x0)
    at layout/painting/nsDisplayList.cpp:3605
#2  0x0000007fbbffea94 in nsFrame::DisplayBackgroundUnconditional
    (this=this@entry=0x7f88744060, aBuilder=aBuilder@entry=0x7fa6e2e630, aLists=..., 
    aForceBackground=aForceBackground@entry=false)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsRect.h:42
[...]
#74 0x0000007fb735e89c in ?? () from /lib64/libc.so.6
(gdb) 

This is interesting because the second frame in the stack is for nsDisplayBackgroundImage::AppendBackgroundItemsToTop(). That matches what we were expecting before, and there's a good chance that DuckDuckGo will be serving the same data to ESR 78 as to the ESR 91 version of the renderer.

This strengthens my suspicion that there's something to be found inside AppendBackgroundItemsToTop(). Let's take a look at it.

So now I'm stepping through the code side-by-side using two phones; ESR 78 on the phone on the left and ESR 91 on the phone on the right. On my laptop display I have Qt Creator open with the ESR 78 copy of nsDisplayList.cpp on the left and the ESR 91 copy of the file on the right.

As I step through on both phones I'm comparing the source code line-by-line. They're not identical but close enough that I can keep track of them line-by-line and keep them broadly synchronised.

Eventually we hit this bit of code that's part of ESR 78, which is where the method returns:

  if (!bg) {
    aList->AppendToTop(&bgItemList);
    return false;
  }

The ESR 91 version of this code looks like this:

  if (!bg || !drawBackgroundImage) {
    if (!bgItemList.IsEmpty()) {
      aList->AppendToTop(&bgItemList);
      return AppendedBackgroundType::Background;
    }

    return AppendedBackgroundType::None;
  }

That's similar but not quite the same and in particular, bgItemList.mLength is zero meaning that !bgItemList.IsEmpty() is false.

(gdb) p bgItemList.mLength
$6 = 0

Both methods return at this point, but on ESR 78 aList->AppendToTop() has been called whereas on ESR 91 it's been skipped. There are multiple reasons why this might be and it's hard to imagine this is the reason rendering is failing on ESR 91, but it's a possibility that I need to investigate further.

But also in both cases the method is returning before the call to GetInitData() and what I'm really after is a case where it's called on ESR 78 but not on ESR 91. To examine that I'm going to have to step through the method a few more times, maybe place a breakpoint closer to the call. And for that, unfortunately, I've run out of time for today; it'll have to be something I explore tomorrow.

So I guess the phones will have to be left stuck on a breakpoint overnight yet again.

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