Bugzilla

Comment 2

•

6 years ago

I saw this assertion when I open https://bugzilla.mozilla.org/attachment.cgi?id=8981269 and scroll the content.

Comment 3

•

6 years ago

Attached file A backtrace — Details

The stack is bit different from comment 0.
In this case, ActiveScrolledRoot::PickDescendant.

Comment 4

•

6 years ago

(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)
> I saw this assertion when I open
> https://bugzilla.mozilla.org/attachment.cgi?id=8981269 and scroll the
> content.

This is wrong!  The assertion happens when I open the attachment and open devtools animation inspector.

Matt Woodrow (:mattwoodrow)

Updated

•

6 years ago

Blocks: 1298218

Tyson Smith [:tsmith]

Updated

•

6 years ago

status-firefox60: --- → affected

status-firefox61: --- → affected

status-firefox62: --- → affected

Comment 5

•

6 years ago

This test constructs a frame tree that looks something like this:

Viewport <
  HTMLScroll(1)
    Canvas
      Block
        line
          Placeholder(2)
>
FixedList <
  HTMLScroll(2)
    // Content
>

Both scroll frames are active and create ASRs.

When we descend into the inner scroll frame, we set the current ASR to nullptr [1], since that's the correct ASR for the containing block. We then create a new ASR for the inner scrollframe that has no ancestor, and our two ASRs are not related (which I believe is correct). nsDisplayListBuilder::mCurrentContainerASR still points to the ASR for the outer scrollframe though, so mCurrentContainerASR/mCurrentActiveScrolledRoot are not related.

Then we instantiate an AutoContainerASRTracker, which sets mCurrentContainerASR to the value of mCurrentActiveScrolledRoot, and saves the old value of mCurrentActiveScrolledRoot into mSavedContainerASR.
Nothing changes while it's in scope, and then we assert in the destructor, since mCurrentContainerASR and mSavedContainerASR(/mCurrentActiveScrolledRoot) are not related.

Any idea what the right solution is for this Markus?


[1] https://searchfox.org/mozilla-central/source/layout/generic/nsFrame.cpp#3734

Component: Layout → Layout: Web Painting

Flags: needinfo?(mstange)

Markus Stange [:mstange]

Comment 6

•

6 years ago

(In reply to Matt Woodrow (:mattwoodrow) from comment #5)
> When we descend into the inner scroll frame, we set the current ASR to
> nullptr [1], since that's the correct ASR for the containing block. We then
> create a new ASR for the inner scrollframe that has no ancestor, and our two
> ASRs are not related (which I believe is correct).

I agree, this part seems correct.

> nsDisplayListBuilder::mCurrentContainerASR still points to the ASR for the
> outer scrollframe though,

This is the bug, I think. mCurrentContainerASR should be nullptr. 

> Any idea what the right solution is for this Markus?

Not sure, I haven't given it much thought yet.

Flags: needinfo?(mstange)

Matt Woodrow (:mattwoodrow)

Updated

•

6 years ago

Blocks: APZLayout

Updated

•

6 years ago

Blocks: 1454206

Updated

•

6 years ago

See Also: → https://webcompat.com/issues/19116

Comment 7

•

6 years ago

Markus, this assertion failure has been cropping up in various Android scrolling bugs, such as bug 1454206 and now the site in https://webcompat.com/issues/19116. Any chance of getting this fixed?

Flags: needinfo?(mstange)

Updated

•

6 years ago

Blocks: 1501342

Comment 8

•

6 years ago

(In reply to Botond Ballo [:botond] from comment #7)
> Markus, this assertion failure has been cropping up in various Android
> scrolling bugs, such as bug 1454206 and now the site in
> https://webcompat.com/issues/19116. Any chance of getting this fixed?

And now, on the comments section of the New York Times (bug 1501342).

Updated

•

6 years ago

Blocks: 1493250

Comment 9

•

6 years ago

There are actually two different assertions with this condition: one in PickAncestor(), and one in PickDescendant(). We've been using this bug for both of them, but they may in fact have different underlying causes.

Updated

•

6 years ago

Depends on: 1511419

Updated

•

6 years ago

No longer blocks: 1501342

https://searchfox.org/mozilla-central/rev/ddd065ed26206d7ded61a4e5a35abb0cd6dbd9bc/layout/painting/nsDisplayList.cpp#438
https://searchfox.org/mozilla-central/rev/ddd065ed26206d7ded61a4e5a35abb0cd6dbd9bc/layout/painting/nsDisplayList.h#1352

Comment 10

•

3 years ago

(In reply to Markus Stange [:mstange] from comment #6)

nsDisplayListBuilder::mCurrentContainerASR still points to the ASR for the
outer scrollframe though,

This is the bug, I think. mCurrentContainerASR should be nullptr.

This is because of these two lines

If we change them to both to ignore the content clip asr (and hence remove the PickDescendant call) it fixes this bug. I don't quite understand the explanatory comment but this seems like an optimization? Or maybe not.

That change only fails on reftest

https://treeherder.mozilla.org/jobs?repo=try&revision=6634b9f85547c1d1d716d15497148fa4b0b2d7ae

REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/layers/fixed-pos-scrolled-clip-opacity-layerize.html == layout/reftests/layers/fixed-pos-scrolled-clip-opacity-inside-layerize.html | failed reftest-assigned-layer: these elements are assigned to 2 different layers, instead of sharing just one layer: <div class="blueBox" reftest-assigned-layer="page-background">, <div class="absoluteCyanBox" reftest-assigned-layer="page-background">, these elements are assigned to 2 different layers, instead of sharing just one layer: <div class="blueBox" reftest-assigned-layer="page-background">, <div class="absoluteCyanBox" reftest-assigned-layer="page-background">

I'm not necessarily suggested we take that approach just recording what I learned.

BugBot [:suhaib / :marco/ :calixte]

Updated

•

3 years ago

Crash Signature: [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform] [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform_with_face]

Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)

Comment 12

•

3 years ago

The crash frequency increased at the end of February. Glenn, can you check what started this?

Crash Signature: [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform] [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform_with_face] → [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform] [@ core::option::expect_failed | webrender::spatial_tree::SpatialTree::get_relative_transform_with_face]

Flags: needinfo?(gwatson)

Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)

Comment 13

•

3 years ago

•

Edited

Do we have an approximate regression range for when this got worse? Eyeballing it seems like maybe 2021-02-23.

Comment 14

•

3 years ago

Based on the duplicate this could be from bug 1649668.

Glenn Watson [:gw]

Comment 15

•

3 years ago

I think it's unlikely it's from that - because backdrop-filter is disabled by default, and only enabled if the user explicitly opts-in via about:config, so I expect that very few users have that enabled, unless some large number of people recently enabled that pref for some reason?

I'm not sure how to find out with any confidence what it's from. Any ideas on how we would normally work out what might have caused something like that?

Unfortunately, although the eventual panic occurs in WR, it looks like this is probably from an invalid display list that Gecko is supplying, due to the assertion failure in DL building, which I don't have a good understanding of.

Flags: needinfo?(gwatson)

Updated

•

3 years ago

Comment 16

•

3 years ago

•

Edited

Testcase found while fuzzing mozilla-central rev f4ad9b76e5f8 (built with: --enable-debug --enable-fuzzing).

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch --build f4ad9b76e5f8 --debug --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.zip

Reporter

Comment 17

•

3 years ago

Attached file Detailed Crash Information — Details

Reporter

Comment 18

•

3 years ago

Attached file Testcase — Details

Reporter

Updated

•

3 years ago

Attachment #9238928 - Attachment description: Testcase for comment 8 → Testcase

Comment hidden (obsolete)

Comment on attachment 8939572 [details]
trigger.html

><html>
>  <head>
>    <style></style>
>    <script>
>      try { o1 = document.createElement('tfoot') } catch(e) { }
>      try { o2 = document.createElement('tr') } catch(e) { }
>      try { o3 = document.createElement('th') } catch(e) { }
>      try { o4 = document.createElement('d') } catch(e) { }
>      try { o5 = document.createElement('frameset') } catch(e) { }
>      try { document.documentElement.appendChild(o1) } catch(e) { }
>      try { o1.appendChild(o2) } catch(e) { }
>      try { o2.appendChild(o3) } catch(e) { }
>      try { o3.appendChild(o4) } catch(e) { }
>      try { o4.appendChild(o5) } catch(e) { }
>      try { document.styleSheets[0].insertRule("* { mask:url(), -moz-linear-gradient(8deg,blue,green), -moz-element(#a) }", 0) } catch(e) { }
>      try { document.styleSheets[0].insertRule('tfoot { overflow-y: hidden; position:fixed }', 0) } catch(e) { }
>    </script>
>  </head>
></html>

Tyson Smith [:tsmith]

Comment 20

•

3 years ago

A Pernosco session is available here: https://pernos.co/debug/2ZzYXSnoJzjd9AE0875Y3w/index.html

It was created using the test case attached in comment 18.

Darkspirit

Updated

•

3 years ago

Comment 21

•

3 years ago

(In reply to Jason Kratzer [:jkratzer] from comment #16)

Testcase found while fuzzing mozilla-central rev f4ad9b76e5f8 (built with:
--enable-debug --enable-fuzzing).

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch --build f4ad9b76e5f8 --debug --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.zip

Does this mean reproducing the crash requires more than just loading the testcase in the browser? If so, what else (in terms of interactions with the browser) does this replay script do?

Dennis Schubert [:denschub]

Reporter

Comment 22

•

3 years ago

(In reply to Botond Ballo [:botond] from comment #21)

Does this mean reproducing the crash requires more than just loading the testcase in the browser? If so, what else (in terms of interactions with the browser) does this replay script do?

No. Grizzly.replay is just used to automate launching the browser with the prefs included in testcase.zip and opening the testcase.

Karl Dubost💡 :karlcow

Updated

•

3 years ago

Webcompat Priority: --- → ?

Updated

•

2 years ago

Webcompat Priority: ? → ---

Updated

•

2 years ago

Severity: normal → S3

Markus Stange [:mstange]

Comment 23

•

1 year ago

I think we have a workaround for this these days.

Flags: needinfo?(mstange.moz)