1720849 - Pages opened in the background tab are partially rendered

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P3)

Description

[andysem]

Attachment: Screenshot_20210716_123013.png

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

Steps to reproduce:

1. Open a web page with some links in it. Google will do.
2. On one of the links, Right Click, Open Link in New Tab. The page opens in a new tab in the background.
3. Wait a few seconds not clicking on anything.
4. Switch to the background tab.

The system is Kubuntu 21.04 x86-64. This reproduces on two machines, one using Intel iGPU and the other one - Nvidia dGPU (with binary driver 470.42.01).

Actual results:

The page opened in the background tab is sometimes not fully rendered (see the screenshot) and at times is completely blank. The amount of rendered content can be different every time. This does not happen every time, but rather often.

When the page is rendered, you can occasionally see a brief graphical glitch when you switch to the page. As if for one frame after the switch the page is not fully rendered or has some invalid content and then it gets rendered proper.

If the page is not fully rendered, you can fix this by scrolling the page up or down - the content gets fully rendered when the scrolling animation starts.

Expected results:

The page should be fully rendered every time, with no graphical glitches.

Comment 1

[andysem]

Attachment: about:support page contents

Here are about:support page, which is surprisingly empty. Firefox 90.0.

Comment 2

[Pablo]

I tried to reproduce this using ubuntu 20 64bit and firefox nightly 92.0a1 and also with firefox release 90.0.1 and i was not able to reproduce
i tested it using a google search and then right click and open in new tab. The site got rendered.

Does this issue occur in the latest nightly version of firefox?

Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/

please let us know
thanks

Comment 3

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

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

Comment 4

[andysem]

(In reply to Pablo from comment #2)

I tried to reproduce this using ubuntu 20 64bit and firefox nightly 92.0a1 and also with firefox release 90.0.1 and i was not able to reproduce
i tested it using a google search and then right click and open in new tab. The site got rendered.

Does this issue occur in the latest nightly version of firefox?

Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/

please let us know
thanks

I tried to reproduce it for a few minutes and couldn't. Though the nightly build created a new profile with no extensions, and the issue did not reproduce reliably on the release build, so my testing is inconclusive.

Comment 5

[andysem]

Attachment: about:support page contents

Here is about:support page contents from my other system. It has actual data in it this time.

Comment 6

[Lee Salzman [:lsalzman]]

Robert, does this look anything like the invalidation issues we were having on Linux recently?

Comment 7

[Robert Mader [:rmader]]

(In reply to Lee Salzman [:lsalzman] from comment #6)

Robert, does this look anything like the invalidation issues we were having on Linux recently?

Don't recall any more what you are referring to - maybe bug 1712665? In any case it can't have anything to do with EGL or partial damage, according to the supplied about:support. The only thing I can spot here is that we are dealing with a multi-monitor setup.

andysem:

• is that correct (multi-monitor, we can't detect this properly on X11 with compositing window manager as the system only reports one monitor with the combined size)?
• does the issue also happen with only one monitor?
• does force-disabling WR work around the issue? (Enable gfx.webrender.software in about:config to force SW-WR)

Comment 8

[Lee Salzman [:lsalzman]]

Hmm, I wonder if maybe this is related to bug 1721098. Nightly (and now beta) has the fix for bug 1721098 in it already, so should be easy to check. Andy, can you see if the latest nightly or beta fixes the issue for you?

Comment 9

[andysem]

(In reply to Robert Mader [:rmader] from comment #7)

(In reply to Lee Salzman [:lsalzman] from comment #6)

Robert, does this look anything like the invalidation issues we were having on Linux recently?

Don't recall any more what you are referring to - maybe bug 1712665? In any case it can't have anything to do with EGL or partial damage, according to the supplied about:support. The only thing I can spot here is that we are dealing with a multi-monitor setup.

andysem:

• is that correct (multi-monitor, we can't detect this properly on X11 with compositing window manager as the system only reports one monitor with the combined size)?

One of my systems has two displays. The primary one is 3840x2160, the secondary is 1920x1080. Firefox is running maximized on the primary display. I almost never run Firefox on the second display, so I haven't seen this issue there. This system is running the Nvidia GPU.

The other system is a laptop, with only one display - 1920x1080. The issue reproduced on that display. This system is using Intel GPU.

BTW, xrandr does detect two separate displays.

• does the issue also happen with only one monitor?

I haven't seen it, though I didn't try much, as described above.

• does force-disabling WR work around the issue? (Enable gfx.webrender.software in about:config to force SW-WR)

I haven't tried, but I will. Though, as I said, I can't reliably reproduce. It happens maybe once a week or two.

(In reply to Lee Salzman [:lsalzman] from comment #8)

Hmm, I wonder if maybe this is related to bug 1721098. Nightly (and now beta) has the fix for bug 1721098 in it already, so should be easy to check. Andy, can you see if the latest nightly or beta fixes the issue for you?

As I noted a week ago, I couldn't reproduce it with the nightly build at that time. I was trying to reproduce for about half an hour that time.

Comment 10

[andysem]

I think, I've just reproduced this with gfx.webrender.software == true. I've opened a link in a new background tab, and when I switched to it after a while it was blank. When I tried to scroll up/down with the mouse wheel, the content appeared with a delay of one or two seconds. This delay is where it's different from the hardware renderer - before I changed gfx.webrender.software to true scrolling would cause the content appear immediately, or at least with much less of a delay.

Comment 11

[Darkspirit]

(In reply to andysem from comment #0)

The page opened in the background tab is sometimes not fully rendered (see the screenshot) and at times is completely blank.

bug 1732743 has been fixed by bug 1722487 ("Avoid some work for font list updates"). This could be the same.
Firefox 93 will be released on 2021-10-05. Hopefully it fixes this bug.

Comment 12

[andysem]

I have just reproduced this in Firefox 93.0, the bug is not fixed.

Comment 13

[andysem]

For reference, it often reproduces on this bug tracker. Right-click on various comment links (the ones that have #cN at the end of the URL), click "Open Link in New Tab". Do this for several such links. Then start switching to the tabs you opened. Chances are high that some of them won't be fully rendered.

Comment 14

[Alice0775 White]

(In reply to andysem from comment #13)

For reference, it often reproduces on this bug tracker. Right-click on various comment links (the ones that have #cN at the end of the URL), click "Open Link in New Tab". Do this for several such links. Then start switching to the tabs you opened. Chances are high that some of them won't be fully rendered.

I can reproduce the issue with str comment#13 in Firefox93.0 Windows10.
And It seems to be fixed in Firefox94beta.

It happens intermittently. So I can't be 100% sure.
Fixed range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9454a21f0863be403ec585d4b0bc176656f170ed&tochange=f52e47992f26b86ea97ae16ff4908438f245dbc8

Comment 15

[andysem]

(In reply to Alice0775 White from comment #14)

(In reply to andysem from comment #13)

For reference, it often reproduces on this bug tracker. Right-click on various comment links (the ones that have #cN at the end of the URL), click "Open Link in New Tab". Do this for several such links. Then start switching to the tabs you opened. Chances are high that some of them won't be fully rendered.

I can reproduce the issue with str comment#13 in Firefox93.0 Windows10.
And It seems to be fixed in Firefox94beta.

It happens intermittently. So I can't be 100% sure.
Fixed range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9454a21f0863be403ec585d4b0bc176656f170ed&tochange=f52e47992f26b86ea97ae16ff4908438f245dbc8

This still reproduces in Firefox 96.0 for me, so the issue is not fixed.

Comment 16

[Darkspirit]

bug 1747857 was fixed in 97.

Comment 17

[andysem]

This is not related to the partial present/buffer age issue. Partial present is disabled on my system.

Comment 18

[andysem]

Still reproduces in 98.0.2.

I can add that it looks like the browser selects incorrect "viewing position" in the page (viewport), typically below the part associated with the anchor in the link. That is, if the browser renders the region of the page that is around the anchor, the viewport is typically located below it, where the content isn't rendered or partially rendered. This is evidenced by the fact that when I scroll the wheel, the page content is rendered and it is usually much lower than the anchor. To go back to the anchor you need to click on the URL bar and press Enter.

Comment 19

[Timothy Nikkel (:tnikkel)]

Bug 1742241 sounds very similar to this bug and was fixed in Firefox 99, which was released this week. Could you try Firefox 99 and report back if it is fixed or not?

Comment 20

[andysem]

(In reply to Timothy Nikkel (:tnikkel) from comment #19)

Bug 1742241 sounds very similar to this bug and was fixed in Firefox 99, which was released this week. Could you try Firefox 99 and report back if it is fixed or not?

That bug says it should be fixed in Firefox 98. This problem reproduces in 98.0.2.

Comment 21

[Timothy Nikkel (:tnikkel)]

You're right, my mistake, I forgot we uplifted that bug to 98.

I landed a couple other fixes that only made it into 99 and not 98 and they fix similar cases (bug 1756762, bug 1753881). Could you please test Firefox 99?

Comment 22

[andysem]

After some preliminary testing, the problem does not reproduce in 99.0. Thanks.

Comment 23

[Timothy Nikkel (:tnikkel)]

Thanks for testing. If you see the problem again or something similar please re-open or file a new bug.