1729937 - Not render a page properly of Wikipedia

Status: VERIFIED FIXED

(Core :: Web Painting, defect)

Description

[Walter Labonte]

Attachment: screenshot1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

1. Go to https://ja.wikipedia.org/wiki/GEM_(%E3%82%A2%E3%82%A4%E3%83%89%E3%83%AB%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97)
2. Scroll down to '在籍タイムライン' section of the middle of the page.
3. Scroll to right.
4. Boom, black out the area.

<Environment>
Firefox 93.0b2
Windows 10 19043
Geforce GTX 670

Actual results:

black out the area of timeline.

Expected results:

render properly.

Comment 1

[Walter Labonte]

Attachment: screenshot2.png

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Darkspirit]

Thanks for the report!

Comment 4

[Darkspirit]

Attachment: 2021-09-09_18-21-32.mp4

I can reproduce this even on Linux (Debian Testing, Intel Iris Graphics 6100 (BDW GT3), EGL/Xwayland, Macbook Pro).

Comment 5

[Darkspirit]

Tested on Linux:
mozregression --good 90 --bad 2021-09-08 --pref gfx.webrender.all:true -a 'https://ja.wikipedia.org/wiki/GEM_(%E3%82%A2%E3%82%A4%E3%83%89%E3%83%AB%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97)'

13:42.97 INFO: Last good revision: 9118d660cfcb990a0b9723aefbb237ed489318b0
13:42.97 INFO: First bad revision: 93f8701fc36dd009c38448b90896eb819ae4b69c
13:42.97 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9118d660cfcb990a0b9723aefbb237ed489318b0&tochange=93f8701fc36dd009c38448b90896eb819ae4b69c

93f8701fc36dd009c38448b90896eb819ae4b69c Matt Woodrow — Bug 1728709 - Add nsDisplayItem::GetPaintRect that computes a value using the current clip extents. r=jrmuizel

Comment 6

[Matt Woodrow (:mattwoodrow)]

It looks like GenerateFallbackData (which we're using to paint nsDisplayImage fallback, since it's an image map) overrides the building rect of items to be the bounds, and trusts that the recorded rendering commands don't have any reference to the building rect.

It does however create the recording draw target using the building rect size, though this usually isn't used for anything.

The regressing change here restricted drawing (within nsDisplayImage::Paint) to the results of GetClipRect(aBuilder, aCtx), which includes the DT bounds.

When we scroll the fallback blob, we detect that no invalidation is needed, and just update the bounds/building rect on the WebRenderFallbackData object.

That no longer works, since trying to replay the commands recorded with the old building rect against a bitmap DT with the new one results in emtpy areas.

Jeff, I think we could make the dtBounds contain the full bounds of the item and fix this, does that make sense?

For some reason I can't reproduce this in a local build, but I can in Nightly.

Comment 7

[Matt Woodrow (:mattwoodrow)]

That is already the case, I misread the code.

The bug is in ::GetPaintRect.

Comment 8

[Matt Woodrow (:mattwoodrow)]

Attachment: Bug 1729937 - Don't include the display item clip in the paint rect. r?jrmuizel

For non-WR painting from nsDisplayList::Paint, the display item clip will already be applied to the context, so will still be included in the result via the clip extents.
WebRender fallback painting intentionally doesn't use the clip (since the clip can include the displayport size), to avoid needing to invalidate for display port changes..

Comment 10

[Pascal Chevrel:pascalc]

There is an accepted patch that may be a good candidate for uplifting, can we land it and uplift to beta if it makes sense? Thanks

Comment 11

[Pascal Chevrel:pascalc]

Jeff, can you land this patch and request uplift to beta if it makes sense? Thanks

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f52e47992f26
Don't include the display item clip in the paint rect. r=jrmuizel

Comment 13

[Narcis Beleuzu [:NarcisB]]

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

Comment 14

[Pascal Chevrel:pascalc]

There was no uplift request and we build our last beta today. I am marking this as wontfix for 93. If this is an important fix needed for this release (that bug has no priority and severity set), please reach out to me thanks.

Comment 15

[Darkspirit]

wtf? (=Why has this been ignored for a week?)

Comment 16

[Darkspirit]

(Pascal Chevrel:pascalc from comment #14)

There was no uplift request and we build our last beta today. I am marking this as wontfix for 93. If this is an important fix needed for this release (that bug has no priority and severity set), please reach out to me thanks.

Can this also be uplifted into 93 rc? Or is keeping the bug safer than the patch?

Comment 17

[Matt Woodrow (:mattwoodrow)]

(In reply to Darkspirit from comment #16)

(Pascal Chevrel:pascalc from comment #14)

There was no uplift request and we build our last beta today. I am marking this as wontfix for 93. If this is an important fix needed for this release (that bug has no priority and severity set), please reach out to me thanks.

Can this also be uplifted into 93 rc? Or is keeping the bug safer than the patch?

We generally avoid uplifting into RC, except for super critical fixes.

Comment 20

[Ciprian Georgiu, Desktop QA]

Reproduced this issue on Win 10, Beta 93.0b2 with the steps from comment 0.

The issue is verified as fixed on Win 10 x64, Beta 94.0b4.