flypig.co.uk

I'm still stuck confused about why, specifically, the main DuckDuckGo search page doesn't render using ESR 91. As we saw yesterday, rotating the screen doesn't fix it. Copying the entire page and serving it from a different location works okay, which is the opposite of what I was hoping for and makes narrowing down the problem that much more difficult.

The only thing I can think to do now is crack open the debugger and see whether there's being any attempt to render anything of the site.

If the page is rendering, there's a good chance that some part of it will be an image. Consequently I've placed a breakpoint on nsImageRenderer::PrepareImage() and have set the browser running. Let's see if it hits.

$ EMBED_CONSOLE=1 gdb sailfish-browser https://duckduckgo.com/
[...]
(gdb) b nsImageRenderer::PrepareImage
Function "nsImageRenderer::PrepareImage" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (nsImageRenderer::PrepareImage) pending.
(gdb) r
Starting program: /usr/bin/sailfish-browser 
[...]

An interesting result: there are no hits on the breakpoint at all when loading the default DuckDuckGo page. But when loading the HTML-only page, the breakpoint hits immedately:

Thread 10 "GeckoWorkerThre" hit Breakpoint 1,
    mozilla::nsImageRenderer::PrepareImage (this=this@entry=0x7f9efb0848)
    at layout/painting/nsImageRenderer.cpp:66
66      bool nsImageRenderer::PrepareImage() {

In fact it hits, and continues hitting, while the page is displayed. Which is interesing: it suggests that for the JavaScript page no attempt is being made to render the page at all.

Here's the backtrace from the breakpoint hit with the HTML-only page. This could be useful, because it may allow us to place a breakpoint further up the stack to figure out at which point the render is getting blocked. That's assuming that the problem is in the render loop, which of course it may well not be.

The 69-frame backtrace is huge, so I'm just copying out the relevant parts of it below. Rendering involves recursive calls to BuildDisplayList() which seems to be one of the reasons these stacks get so large.

Thread 10 "GeckoWorkerThre" hit Breakpoint 1, mozilla::nsImageRenderer::
    PrepareImage (this=this@entry=0x7f9efa0848)
    at layout/painting/nsImageRenderer.cpp:66
66      bool nsImageRenderer::PrepareImage() {
(gdb) bt
#0  mozilla::nsImageRenderer::PrepareImage (this=this@entry=0x7f9efa0848)
    at layout/painting/nsImageRenderer.cpp:66
#1  0x0000007fbc350c5c in nsCSSRendering::PrepareImageLayer
    (aPresContext=aPresContext@entry=0x7f8111dde0,
    aForFrame=aForFrame@entry=0x7f813062c0, 
    aFlags=<optimized out>, aBorderArea=..., aBGClipRect=..., aLayer=..., 
    aOutIsTransformedFixed=aOutIsTransformedFixed@entry=0x7f9efa0847)
    at layout/painting/nsCSSRendering.cpp:2976
#2  0x0000007fbc351254 in nsDisplayBackgroundImage::GetInitData
    (aBuilder=aBuilder@entry=0x7f9efa6268, aFrame=aFrame@entry=0x7f813062c0, 
    aLayer=aLayer@entry=1, aBackgroundRect=...,
    aBackgroundStyle=aBackgroundStyle@entry=0x7f8130f608)
    at layout/painting/nsDisplayList.cpp:3416
#3  0x0000007fbc3a97a4 in nsDisplayBackgroundImage::AppendBackgroundItemsToTop
    (aBuilder=0x7f9efa6268, aFrame=0x7f813062c0, aBackgroundRect=..., 
    aList=0x7f9efa11c8, aAllowWillPaintBorderOptimization=<optimized out>,
    aComputedStyle=<optimized out>, aBackgroundOriginRect=..., 
    aSecondaryReferenceFrame=0x0, aAutoBuildingDisplayList=0x0)
    at layout/painting/nsDisplayList.cpp:3794
#4  0x0000007fbc18c3d0 in nsIFrame::DisplayBackgroundUnconditional
    (this=this@entry=0x7f813062c0, aBuilder=aBuilder@entry=0x7f9efa6268,
    aLists=..., aForceBackground=aForceBackground@entry=false)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsRect.h:40
#5  0x0000007fbc191c90 in nsIFrame::DisplayBorderBackgroundOutline
    (this=this@entry=0x7f813062c0, aBuilder=aBuilder@entry=0x7f9efa6268,
    aLists=..., aForceBackground=aForceBackground@entry=false)
    at layout/generic/nsIFrame.cpp:2590
#6  0x0000007fbc16fd10 in nsBlockFrame::BuildDisplayList
    (this=0x7f813062c0, aBuilder=0x7f9efa6268, aLists=...)
    at layout/generic/nsBlockFrame.cpp:6963
#7  0x0000007fbc1c040c in nsIFrame::BuildDisplayListForChild
    (this=this@entry=0x7f81306200, aBuilder=aBuilder@entry=0x7f9efa6268, 
    aChild=aChild@entry=0x7f813062c0, aLists=..., aFlags=..., aFlags@entry=...)
    at layout/generic/nsIFrame.cpp:4278
#8  0x0000007fbc159ccc in DisplayLine (aBuilder=aBuilder@entry=0x7f9efa6268,
    aLine=..., aLineInLine=aLineInLine@entry=false, aLists=..., 
    aFrame=aFrame@entry=0x7f81306200, aTextOverflow=aTextOverflow@entry=0x0,
    aLineNumberForTextOverflow=aLineNumberForTextOverflow@entry=0, 
    aDepth=aDepth@entry=0, aDrawnLines=@0x7f9efa14fc: 127)
    at layout/generic/nsBlockFrame.cpp:6924
#9  0x0000007fbc170220 in nsBlockFrame::BuildDisplayList (this=0x7f81306200,
    aBuilder=0x7f9efa6268, aLists=...)
    at layout/generic/nsBlockFrame.cpp:7082
[...]
#33 0x0000007fbc1bce14 in nsIFrame::BuildDisplayListForStackingContext
    (this=this@entry=0x7f81304940, aBuilder=<optimized out>, 
    aBuilder@entry=0x7f9efa6268, aList=aList@entry=0x7f9efa8078,
    aCreatedContainerItem=aCreatedContainerItem@entry=0x0)
    at layout/generic/nsIFrame.cpp:3416
#34 0x0000007fbc12d7ac in nsLayoutUtils::PaintFrame
    (aRenderingContext=aRenderingContext@entry=0x0,
    aFrame=aFrame@entry=0x7f81304940, aDirtyRegion=...,
    aBackstop=aBackstop@entry=4294967295,
    aBuilderMode=aBuilderMode@entry=nsDisplayListBuilderMode::Painting,
    aFlags=aFlags@entry=(nsLayoutUtils::PaintFrameFlags::WidgetLayers |
    nsLayoutUtils::PaintFrameFlags::ExistingTransaction |
    nsLayoutUtils::PaintFrameFlags::NoComposite))
    at layout/base/nsLayoutUtils.cpp:3445
#35 0x0000007fbc0b9008 in mozilla::PresShell::Paint
    (this=this@entry=0x7f811424a0, aViewToPaint=aViewToPaint@entry=0x7e780077f0,
    aDirtyRegion=..., aFlags=aFlags@entry=mozilla::PaintFlags::PaintLayers)
    at layout/base/PresShell.cpp:6400
[...]
#69 0x0000007fb78b289c in ?? () from /lib64/libc.so.6
(gdb) 

This breakpoint was set on nsImageRenderer::PrepareImage(). That hit on the HTML page but not on the JavaScript page. Let's try something further down the stack. At stack frame 34 we're inside nsLayoutUtils::PaintFrame(), so let's put a breakpoint on that and display the JavaScript version of the page to see what happens.

(gdb) delete break 1
(gdb) b nsLayoutUtils::PaintFrame
Breakpoint 2 at 0x7fbc12ce1c: file layout/base/nsLayoutUtils.cpp, line 3144.
(gdb) c
Continuing.

Thread 10 "GeckoWorkerThre" hit Breakpoint 2, nsLayoutUtils::PaintFrame
    (aRenderingContext=aRenderingContext@entry=0x0,
    aFrame=aFrame@entry=0x7f809f3c00, 
    aDirtyRegion=..., aBackstop=aBackstop@entry=4294967295,
    aBuilderMode=aBuilderMode@entry=nsDisplayListBuilderMode::Painting, 
    aFlags=aFlags@entry=(nsLayoutUtils::PaintFrameFlags::WidgetLayers |
    nsLayoutUtils::PaintFrameFlags::ExistingTransaction |
    nsLayoutUtils::PaintFrameFlags::NoComposite))
    at layout/base/nsLayoutUtils.cpp:3144
3144                                       PaintFrameFlags aFlags) {
(gdb) bt
#0  nsLayoutUtils::PaintFrame (aRenderingContext=aRenderingContext@entry=0x0,
    aFrame=aFrame@entry=0x7f809f3c00, aDirtyRegion=..., 
    aBackstop=aBackstop@entry=4294967295,
    aBuilderMode=aBuilderMode@entry=nsDisplayListBuilderMode::Painting, 
    aFlags=aFlags@entry=(nsLayoutUtils::PaintFrameFlags::WidgetLayers |
    nsLayoutUtils::PaintFrameFlags::ExistingTransaction |
    nsLayoutUtils::PaintFrameFlags::NoComposite))
    at layout/base/nsLayoutUtils.cpp:3144
#1  0x0000007fbc0b9008 in mozilla::PresShell::Paint
    (this=this@entry=0x7f80456d90, aViewToPaint=aViewToPaint@entry=0x7f80b73520,
    aDirtyRegion=..., aFlags=aFlags@entry=mozilla::PaintFlags::PaintLayers)
    at layout/base/PresShell.cpp:6400
#2  0x0000007fbbef0ec8 in nsViewManager::ProcessPendingUpdatesPaint
    (this=this@entry=0x7f80b79520, aWidget=aWidget@entry=0x7f806e6f60)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/gfx/RectAbsolute.h:43
[...]
#30 0x0000007fb78b289c in ?? () from /lib64/libc.so.6
(gdb) 

And we get a hit. That means that somewhere between the call to nsLayoutUtils::PaintFrame() and nsImageRenderer::PrepareImage something is changing.

I won't bore you with all of the steps, but I've followed the path up through the stack, setting breakpoints on each method call, and have found that the following breakpoint does hit for the standard rendering of the DuckDuckGo site:

Thread 10 "GeckoWorkerThre" hit Breakpoint 6,
    nsDisplayBackgroundImage::AppendBackgroundItemsToTop (aBuilder=0x7f9efa6378,
    aFrame=0x7f81599428, aBackgroundRect=..., aList=0x7f9efa3f08,
    aAllowWillPaintBorderOptimization=true, aComputedStyle=0x0,
    aBackgroundOriginRect=..., aSecondaryReferenceFrame=0x0,
    aAutoBuildingDisplayList=0x0)
    at layout/painting/nsDisplayList.cpp:3632
3632            aAutoBuildingDisplayList) {
(gdb) 

However, moving one up from the stack we find nsDisplayBackgroundImage::GetInitData() and this method doesn't trigger when we placed a breakpoint on it:

(gdb) delete break 6
(gdb) break nsDisplayBackgroundImage::GetInitData
Breakpoint 7 at 0x7fbc3511d4: file layout/painting/nsDisplayList.cpp, line 3409.
(gdb) c
Continuing.

So that's between stack frame two and three of our original backtrace. This might suggest — although I'm not on firm ground here by any means — that the problem is potentially happening inside the call to AppendBackgroundItemsToTop(). On the other hand, that might just be a consequence of the two versions of the site having different structures. I'm going to step through the method to try to find out.

But unfortunately not today: it's late and this needs a bit more time, so I'll pick it up in the morning. This is actually quite a good place to pause, having a very clear direction to explore and pick up on tomorrow.

Let's see what tomorrow brings.

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