1698353 - [fission] Some content gets clipped when navigating in an iframe, with e.g. Yahoo Mail and w3.org, with fission enabled

Status: RESOLVED FIXED

(Core :: Layout: Scrolling and Overflow, defect, P1)

Description

[kernp25]

Attachment: 7udh6AB0TF.mp4

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

Steps to reproduce:

1. Install https://addons.mozilla.org/firefox/addon/yahoo-mail-notifier-we/
2. Go to options page and check "Show mail preview window"
3. Click on the mail icon in the toolbar menu

Actual results:

See attached video.

Expected results:

Should load normal.

Comment 1

[kernp25]

I have the latest nightly version (88.0a1 (2021-03-14) (64-Bit)).

Comment 2

[kernp25]

You get the same bug when loading: data:text/html,<iframe src="https://www.w3.org/" style="width:800px">

Comment 3

[kernp25]

Note: I'm using width:800px and not width:500px

Comment 4

[kernp25]

I found a way to temporary fix this bug. Move the mouse cursor over the scrollbar so the rest of the page will be painted/visible.

It maybe has something to do with the scrollbar?

Comment 5

[kernp25]

Attachment: J3CCosLchE.mp4

Comment 6

[kernp25]

Attachment: H4rZs7kQAV.mp4

Tested with layout.scrollbar.side 3

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Thanks for reporting this. I don't seem to be able to reproduce, can you attach your about:support to the bug?

Or, can you maybe run mozregression to see what caused this? Looking at it it seems more likely to be a graphics / APZ issue.

Comment 8

[kernp25]

Attachment: 0XzdmR6YKG.mp4

Comment 9

[kernp25]

Can you look at the video?

Note: fission.autostart true

Comment 10

[Emilio Cobos Álvarez [:emilio]]

I did see the video, but I still can't reproduce, so the about:support information could be useful to determine what might be different. Does it work if you turn off fission? What is your WebRender status?

Comment 11

[kernp25]

Attachment: { "application": { "name": "Firefox", "osVersion": "Windows_NT 10.0 19041", "version": "88.0a1", "buildID": "20210314094531", "distributionID": "", "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 F

Comment 12

[kernp25]

Yes, with fission turned off everything works as expected.

Comment 13

[kernp25]

It does not matter, if i set gfx.webrender.all to true or not. The bug still occurs.

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to kernp25 from comment #2)

You get the same bug when loading: data:text/html,<iframe src="https://www.w3.org/" style="width:800px">

Could you clarify what the steps-to-reproduce are with this URL? (Do you see graphical issues right away when you load it, or do you have to interact with the frame somehow?)

This one's nicer than Yahoo as a testcase here (if it reproduces as reliably), since it doesn't require any account/login.

Comment 15

[Daniel Holbert [:dholbert]]

Oh, I missed the video in comment 8. It looks like the STR for w3.org are to click the "participate" / "membership" / etc. tabs. [Probably just any sort of navigation at all.]

I am able to reproduce temporarily with that example, using latest Nightly with fission on my mac laptop, with my regular web-browsing profile. In my case, the issue seems to correct itself after a few seconds.

Comment 16

[Daniel Holbert [:dholbert]]

I can reproduce in a fresh profile, too (with fission enabled).

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=42791e22621d1dab5fff576448eccb45f6b3ca6a&tochange=175a61c35c21f15581df58371c45221f31f36aed

--> regression from bug 1687928

tnikkel, would you mind taking a look?

Comment 17

[Timothy Nikkel (:tnikkel)]

Thanks for the regression range and testcase, I can reproduce. Glad I landed that changeset which was not supposed to change anything separately!

Comment 18

[Timothy Nikkel (:tnikkel)]

Weird, our displayport base rect (as set in DecideScrollableLayer) starts too small and then grows over several steps (in appunits): 11520, 23040, 38400, 47100. APZ callback helper sets an almost final value of 46200 in the middle of that sequence, but DecideScrollableLayer squashes it.

Comment 19

[Timothy Nikkel (:tnikkel)]

Ah, because we call RestrictToRootDisplayPort, which tries to restrict to itself (because the code assumes that something that is a root scroll frame but that isn't in a root content doc and isn't a root chrome doc is necessarily not the root scroll frame of a process, which fails with fission) which doesn't make sense and it gets confused.

Comment 20

[Neha Kochar [:neha]]

Timothy, is this reproducible without Fission but with WR enabled?

Comment 21

[Neha Kochar [:neha]]

If this does not fail without Fission (with any WR setting) and only fails when Fission is enabled, then this will most definitely be a Fission Beta blocker (M7)

Comment 22

[Timothy Nikkel (:tnikkel)]

This bug only happens with fission. I should be able to get a patch up today, and hopefully with a test too.

Comment 23

[Chris Peterson [:cpeterson]]

Assigning to tnikkel since he's already fixing this bug. This regression is a high priority for Fission.

Comment 24

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 1698353. Don't try to restrict the display port base rect of a scroll frame with the display port of the same scroll frame because that doesn't make sense. r?botond

Comment 25

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 1698353. Add test. r?botond

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/929c04cc6396
Don't try to restrict the display port base rect of a scroll frame with the display port of the same scroll frame because that doesn't make sense. r=botond

Comment 27

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/929c04cc6396

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e036257362d2
Add test. r=botond

Comment 29

[Sandor Molnar[:smolnar]]

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