1546294 - Many github pages unusable in Firefox, code disappears

Status: RESOLVED DUPLICATE of bug 1548484

(Core :: Web Painting, defect)

Description

[gserg.g]

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

Steps to reproduce:

Using Firefox 66.0.3 on Windows 10 x64, I find many Github pages unusable. When there is a lot of code on the screen at once, attempt to interact with it in any way makes it disappear for about 20 seconds. After that it appears again, but one more click and it disappears for 20 seconds more.

E.g. visit https://github.com/JanKallman/EPPlus/blob/master/EPPlus/ExcelWorksheet.cs

Scroll the page back and forth without clicking anything, observe the code is there.

Click the code. It disappears.

Wait for some time. The code appears again.

Click it again, it again disappears for 20 seconds.

Actual results:

The code disappears when interacted with. Cannot select, copy etc.

Expected results:

The code does not disappear.

Comment 1

[Virginia (please send need info request to Brindusa Tot)]

Hi gserg.g,

I was unable to reproduce the issue on Windows 10 and Mac OSX 10.13 using the following browsers:

• Nightly latest version 68.0a1
• Firefox latest Release version 66.0.3
• Firefox Beta 67.0b15

Could you please also test on the latest version of Firefox Nightly and share the results with us? You can download it from here: https://nightly.mozilla.org/

If you still have the issue please create a new profile, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Also, please test if this is reproducible in safe mode, here is a link that can help you:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

I'm going to set a component so developers can take a look at it. If this is not the right component, feel free to move it to a more appropriate one.

If there is any other info you can provide to help us figure out how we can reproduce the issue please share it with us.

Thanks for your contribution.

Comment 2

[gserg.g]

Attachment: Recorded steps to reproduce - Win10, FF66.0.3.zip

Comment 3

[gserg.g]

Attachment: Recorded steps to reproduce - Win10, FF68.0a1.zip

Comment 4

[gserg.g]

I am able to reproduce with 66.0.3 on Windows 7 and Windows 10, and with Nightly 68.0a1 on Windows 10 (did not test on Windows 7).

The difference is that on Windows 7 I don't even need to click the code for it to disappear, scrolling the page is enough. On Windows 10 scrolling does not cause a problem.

Attached is a Windows steps capture that shows the problem, for FF66 and FF Nightly.

Note there is a 15 seconds pause between the last two steps, it is the time the code was invisible. I clicked the border as soon as the code reappeared to trigger the step tool to take another screenshot.

While the code is invisible, it still logically exists, if you move the mouse over where it should be, the cursor correctly changes from the arrow to the I shape depending on whether you are on a text line or between text lines. You can even select the invisible text even though you cannot see it getting selected (I did that in the steps capture), and your selection will remain when the code finally appears 15 seconds later.

I do not see high processor usage while the code is invisible, so it does not appear to be a heavy rendering calculation that takes 15 seconds to complete.

Comment 5

[Virginia (please send need info request to Brindusa Tot)]

Hi gserg.g,

Thanks for reaching back to us with the steps to reproduce. I signed in Github and opened the test page, selected and copied text, scrolled up and down, edited the code, etc. but I couldn't replicate the behavior reported using the latest Nightly version. I'm attaching a gif with my result.

Were you able to reproduce this issue in other Github cs page? could you try reproducing it by logging in with a different user? Additionally, I would advice testing this with a new profile, and by using safe mode.

Please update this ticket with your results.

Regards,

Comment 6

[Virginia (please send need info request to Brindusa Tot)]

Attachment: screencast of bug *not* reproducing

Comment 7

[gserg.g]

I am able to reproduce this issue on any github page that contains a really big amount of code, like that one.
Pages with reasonable amount of code do not cause the problem.

It does not appear to matter whether I am signed in on github or not.

Using the safe mode does not change anything.

The Firefox Nightly installation already had a new profile, so a new profile does not fix it either.

I have just tried Nightly in Safe mode, same results.

The problem occurs regardless of whether I am at a computer directly or via remote desktop (tried several computers, Windows 7 and Windows 10).
Changing Firefox performance settings (hardware acceleration etc) does not do anything either.

I do not see this problem in Chrome and Edge on the computers on which it occurs in Firefox.

Looking at the performance tab in the developer tools, I can see that when the code disappears, there are several Paint events, and then when it reappears 15 seconds later, there is one more Paint event (obviously all that time I do not touch the page to not cause any more events). If I record performance when the code is visible on the screen (because I have not clicked it), there are no Paint events in the trace.

Comment 8

[Daniel Holbert [:dholbert]]

gserg, it sounds like maybe there's some busy work (possibly some heavy JS or DOM operations) going on in the background that are preventing us from repainting (per your observation that paints are delayed ~15 seconds)

Would you mind capturing a profile of the problem using the addon at https://profiler.firefox.com/ ? Ideally it'd be great if you could do this in your Nightly firefox version, with its ~fresh profile.

Note that the profile may capture activity in background tabs as well, so it's best (from a precision and a privacy perspective) to not have background tabs open.

Comment 9

[Daniel Holbert [:dholbert]]

Basic profiler usage, after you've installed the add-on:
a. Ctrl+Shift+1 to start profiling (watch for toolbar icon to change from gray to blue)
b. trigger the bug
c. Ctrl+Shift+2 to capture + view the profile
d. Press "publish" to upload profile data + generate a sharable https://perfht.ml/ short-URL that you can post here.

Comment 10

[gserg.g]

Trace captured on a "refreshed" Nightly on Windows 10: https://perfht.ml/2DZ4YIe

What I can immediately spot here is that in the capture all the screenshots show visible code, while actually that code was invisible for 15 seconds.

Also attaching a gif of reproducing the problem in the same Nightly FF right after capturing the trace.
Interestingly, with ScreenToGif running, it takes almost 30 seconds for the code to reappear, as opposed to the usual 15.

Comment 11

[gserg.g]

Attachment: Gif of reproducing the problem

Comment 12

[Daniel Holbert [:dholbert]]

Hmm, it sounds like this might be a painting/graphics bug then.

If you visit the special URL about:support, do you see any mention of WebRender? (e.g. Compositing: WebRender)

And, if you do see WebRender there: does the bug go away if you set the about:config preference gfx.webrender.force-disabled to true and restart Firefox Nightly?

Comment 13

[gserg.g]

Both Windows 7 / FF 66.0.5 and Windows 10 / FF 68.0a1 have this in about:support:

Compositing:
Basic

WEBRENDER:
opt-in by default: WebRender is an opt-in feature
unavailable by runtime: ANGLE is disabled

WEBRENDER_QUALIFIED:
blocked by env: No qualified hardware

Comment 14

[Daniel Holbert [:dholbert]]

Thanks, OK. So this is not a WebRender bug.

I did notice one interesting thing in your performance profile, shown in this view (if you scroll down the top area a bit):
https://perfht.ml/30bE8Wy
All three PaintWorkers for your github content-process seem to be blocked for the full 16 seconds (as shown by long red bars), though I'm not sure by what. Markus, do you know what that means, & can you glean anything from the profile here?

Also: for now, I'm reclassifying this as a "Web Painting" bug, since this seems to be about paints getting delayed/blocked rather than about layout.

Comment 15

[Daniel Holbert [:dholbert]]

[er, meant to needinfo mstange for comment 14 -- doing so now]

Comment 16

[Markus Stange [:mstange]]

(In reply to Daniel Holbert [:dholbert] from comment #14)

All three PaintWorkers for your github content-process seem to be blocked for the full 16 seconds (as shown by long red bars), though I'm not sure by what. Markus, do you know what that means, & can you glean anything from the profile here?

I've seen this happen on certain background threads. I'm pretty sure it's an artifact of the profiler's responsiveness instrumentation and doesn't indicate actual unresponsiveness on the thread. I'm hoping that bug 1482244 will help with it.
In other words: the profiler is lying, please ignore.

As for this bug, is this a dupe of bug 1548484?

Comment 17

[Daniel Holbert [:dholbert]]

Thanks, Markus.

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

As for this bug, is this a dupe of bug 1548484?

Sounds likely! gserg, would you mind seeing if the workaround from bug 1548484 comment 2 (setting layers.async-pan-zoom.enabled to false in about:config) fixes this for you?

Comment 18

[gserg.g]

(In reply to Daniel Holbert [:dholbert] from comment #17)

Sounds likely! gserg, would you mind seeing if the workaround from bug 1548484 comment 2 (setting layers.async-pan-zoom.enabled to false in about:config) fixes this for you?

Yes, it does on both machines.

Comment 20

[Daniel Holbert [:dholbert]]

Great, thanks for the info. Let's track this over in bug 1548484 then.