1563178 - document splitting: odd overflow behaviour in search / URL bar

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect, P2)

Description

[Paul Stone]

Attachment: doc split search bar.webm

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

1. enable webrender and gfx.webrender.split-render-roots
2. keep typing in URL or search bar until it overflows

Actual results:

as you keep typing the text starts to move towards the end of the text field (see attached video)

Expected results:

Text field should behave normally

Comment 1

[Andrew Osmond [:aosmond] (he/him)]

Confirmed this happens on Windows nightly as well with document splitting turned on.

Comment 2

[Darkspirit]

mozregression --good 2019-05-01 --bad 2019-07-02 --pref gfx.webrender.all:true gfx.webrender.split-render-roots:true -a about:preferences#search

9:33.90 INFO: Last good revision: 6c6b0bbf5885493a0b85cedf1985d6eb3bdbfe6f
9:33.90 INFO: First bad revision: 5a18f5c929ab13bde25f7fff8ae72f87e8fa379c
9:33.90 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6c6b0bbf5885493a0b85cedf1985d6eb3bdbfe6f&tochange=5a18f5c929ab13bde25f7fff8ae72f87e8fa379c

5a18f5c929ab13bde25f7fff8ae72f87e8fa379c Doug Thayer — Bug 1549976 - Implement popover render root r=kats,Gijs

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I've been poking around at this all day. I made some progress, in that I discovered this patch seems to fix things, although I have no idea why:

diff --git a/layout/painting/nsDisplayList.cpp b/layout/painting/nsDisplayList.cpp
index acd2c0dd32cd..cd1729f51778 100644
--- a/layout/painting/nsDisplayList.cpp
+++ b/layout/painting/nsDisplayList.cpp
@@ -6999,16 +6999,17 @@ bool nsDisplayRenderRoot::UpdateScrollData(
   // establishing a render root boundary (i.e. if mRenderRoot ==
   // aBuilder.GetRenderRoot()). But we don't have aBuilder here so we can't do
   // that. Returning true unconditionally is suboptimal but still correct.
   if (aLayerData) {
     if (mBoundary) {
       // Scroll data entries that are referents should never have direct
       // descendants. Instead they will refer to a different subtree
       MOZ_ASSERT(aLayerData->GetDescendantCount() == 0);
+if (mRenderRoot != wr::RenderRoot::Popover)
       aLayerData->SetReferentRenderRoot(*mBoundary);
     }
   }
   return true;
 }
 
 bool nsDisplayRenderRoot::CreateWebRenderCommands(
     mozilla::wr::DisplayListBuilder& aBuilder,

It's weird because all this does is skip setting the referent render root on one of the scroll data entries, that links the default document's scrolldata to the popover scroll data tree. But the popover scroll data tree is empty anyway (with these STR anyway) so this should have no effect. And yet it does, somehow.

I tried doing an equivalent change on the compositor side, by adding a && mLayer->GetReferentRenderRoot()->GetChildType() != wr::RenderRoot::Popover clause to this if condition but that did not fix the problem. So it's even doubly puzzling.

I'll keep digging.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Ah, the problem is here - the render root management during the recursive tree walk is not correct. It was copy/pasted from the layers id management, but the layers id gets reset on unwinding the stack here while the render root isn't reset anywhere.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Attachment: Bug 1563178 - Properly manage the renderRoot variable during the APZ tree walk. r?botond

The APZ tree walk is recursive but the render root was not being updated when
walking up out of a subtree with a different render root. This changes the
code to use a stack and push/pop the render root for subtrees as we enter
and exit the subtrees as part of the tree walk.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dc058b3425f7
Properly manage the renderRoot variable during the APZ tree walk. r=botond

Comment 7

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/dc058b3425f7

Comment 8

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello!
Reproduced the issue with Firefox 69.0a1 (20190703162038) on Windows 10x64. The issue is verified fixed with Firefox 70.0b9 (20190923154733) on Windows 10x64, Ubuntu 18.04 and macOS 10.14.