1740499 - [fission] Page loads flickers and shows visible redraws (due to too-early paint unsuppression?)

Status: REOPENED

(Core :: Layout, defect, P2)

Description

[zdnex]

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

Steps to reproduce:

1. open https://bugzilla.mozilla.org
2. enter bug number like 1719818 into search
3. click after load go back and try again or click on Bugzilla
4. After Firefox will reload whole page black/white/grey etc..

Actual results:

Firefox after some new version 93/94 started to refresh page a lot. version 78.15 esr does not do that.

Expected results:

Firefox should load page with minimum of refresh if it is same layout like Chrome or old version of Firefox does.

Comment 1

[zdnex]

Or another way to do that is to open another page where this happes. On this version it much more visible, than before. Also it seems that it loads faster, version 78 is really quick in transion on pages. Chrome also. Btw this is on Ubuntu 18.04 , cannot try on windows.

Comment 2

[zdnex]

Btw here on Bugzilla it happens quite a lot (on diffrent pages also).

Comment 3

[zdnex]

Ok, so I have tried to figure more about that > maybe it is related to black style; it shows this background of purple/blue which is in anonymous browsing. Sometimes it is quite a lot and long and sometimes it gets away or it is not visible. I have tried to turn off addons and they do not seems to be responsible.

Comment 4

[zdnex]

For example it seems to be happening a lot when I go from search MyDashboard > My Bugs > select bug and then to bugzilla logo.
Btw for example on this https://www.iinfo.cz/ and going back and forward it also happens quite a lot.

Comment 5

[zdnex]

Attachment: firefox94_flickers_on_some_pages.mp4

I am attaching video > it is clearly visible at 11s and then when I click on red button to load bug. As I am saying similar flickering happens on more pages, so it seems to be connected to Firefox.

Comment 6

[zdnex]

So I was testing it more and it seems than in 91 ESR this does not happen. How can I further find out what can be reason for this? I was thinking some graphic settings could be reason for this redrawing.

Comment 7

[zdnex]

Ok I have just found out that when I on some tab of same page it does not seem to happen so often. I am quite sure it is somehow connected to loaded TAB window. Could it be there is some different mechanism of change location depending on way how tab is opened?

Comment 8

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

Hi zdnex,

Thank you for providing detailed information for this bug. I did a test on my end on Ubuntu 20.04 LTS using these Firefox Release versions 92.0.1 (64-bit) and 94.0.1 (64-bit). I also tested on the latest Nightly 96.0a1 (2021-11-12) (64-bit) and Beta with no luck.

I'll add this ticket to the Widget: Gtk component in the hope someone from their team can take a look and provide feedback on your report. In the meantime, can you test this in the latest Nightly version?
Please also attach the information from your about:support page, in case there's something worth looking that may explain the cause of this.

Thanks!
Virginia

Comment 9

[zdnex]

Attachment: support_page.txt

Hello Virginia,

ok I will try it. I am attaching support page. This is profile which I downgraded from 94, it did not help. But that 91 ESR does not help with this. I will try nighly. Btw did you see these flashes/flickers in video which I meant?

Comment 10

[zdnex]

Ok so nightly with clean profile seems to work in similiar way as ESR version. on 94 when I turn on safe mode it seems to be okay. But in normal mode with addons turned on off it still flickers. I have tried to change hwcomposition/webrender and nothing.

What options are changed in safe-mode?

Comment 11

[zdnex]

Hello Virginia,

so I have found out what is problem > it is this fission project not webrender/gtk/composition these seems to be not relevant. So I was comparing diffrences between nighly/esr/ and safemode and all of them had fission.experiment.enrollmentStatus (on my was 4) and fission.autostart.session (and here true) deactivated.

When I changed fission.experiment.enrollmentStatus to 0 and restarted all started to be okay and no flickers/refresh. So I hope somebody will see this and revisit this function.

Comment 12

[zdnex]

I am not sure how to change component to fission, could you please try it? I have tried to change on clean profile fission.experiment.enrollmentStatus in nightly this value to 4 and immediately refresh were visible on most pages.

Comment 13

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

Hi zdnex,

I'll change this ticket to the "CoreDOM: Content Process" in the hope they can review your question and provide feedback.

Thanks!

Comment 14

[zdnex]

Hello,

ok. I just want point out that after setting fission.experiment.enrollmentStatus:0 and having addons active it is running without a problem whole day. So I am quite sure it is somehow related. Not sure what this function actually does but, seems to somehow change way how rendering/cache works on actually page.

Thank you.

Comment 15

[Jens Stutte [:jstutte]]

Hi, I assume this pref triggers if fission is active. It seems you are using an addon that somehow interferes with fission. You could try to disable them one by one (or add them one by one to a fresh profile) to see if you can find a specific one. Thanks

Comment 16

[zdnex]

So I was trying more nightly and it is quite sure that fission.experiment.enrollmentStatus makes this visible. It is clean profile. Why nightly has this fission thing deactivated and on 94 it was active? Is this some staged rollout? And if yes it seems to be quite problematic.

Btw I have also tried setting in nightly with clean profile (without addons) it up via this https://wiki.mozilla.org/Project_Fission and it flickering stops when I fission.autostart: false.

Can I debug this somehow more?

Comment 17

[zdnex]

Hi Jens,

It does this without addons on nightly (completly clean profile) just fission.autostart : true and restart and it starts to flicker.

Comment 18

[zdnex]

Or clean profile from nightly is not enough?

Comment 19

[Alice0775 White]

I can reproduce the issue in Nightly96 Windows10 if Fision is enabled.

Comment 20

[Jens Stutte [:jstutte]]

Clean profile should be enough. Given that we are not able to reproduce this, I can only think of some specific interference between fission and the graphics subsystem on your hardware configuration. Jim, do you see something actionable here? Thanks

Comment 21

[zdnex]

I do not understand, I see that Alice0775 confirmed it even on windows ? That means this is something related to fission itself, no?

Comment 22

[Alice0775 White]

(In reply to Alice0775 White from comment #19)

I can reproduce the issue in Nightly96 Windows10 if Fission is enabled.

Screen-cast: https://youtu.be/XPfmWm-c28s
Elapsed time
0:00-0:24 : Fission is enabled, Content area flickers
0:24-0:53 : Fission is disabled, no flicker

Comment 23

[Jens Stutte [:jstutte]]

(In reply to zdnex from comment #21)

I do not understand, I see that Alice0775 confirmed it even on windows ? That means this is something related to fission itself, no?

Fission is a deep architectural change regarding process starts and switches that can have impact on sub-systems. But it can obviously also be just a delay caused by Fission itself.

Virginia, did you try to reproduce on Windows? For me it does not reproduce here.
Alice, can you provide more details on the machine you run on?

:jesup, do you have hints for what they could look out to help diagnose this better?

Comment 24

[Alice0775 White]

Attachment: about:support

エディション Windows 10 Home
バージョン 21H1
インストール日 ‎2021/‎05/‎19
OS ビルド 19043.1348
エクスペリエンス Windows Feature Experience Pack 120.2212.3920.0

Comment 25

[Alice0775 White]

Attachment: DxDiag.txt

Comment 26

[zdnex]

Ok, so I tried to test it on another ubuntu and fission actually really makes this visible. Weird thing is that color of these flickers seems to be different could some one say from what they could originate? I guess strace is not good for this debugging. I have also tried to run it with developer tools active and I do not see any difference.

Comment 27

[Chris Peterson [:cpeterson]]

This bug is probably related to Fission's "grey flash" bug 1723495. However, that bug is only known to affect non-bfcache cross-origin navigations and this bug's demo video shows the problem happening when navigating between Bugzilla pages, which are all same-origin navigations.

@ Alice and zdnex, when you reproduce the flash, if you navigate back, does the previous page load instantly? If so, then it is probably in Firefox's "bfcache". Knowing whether the previous page is in the bfcache would help us isolate which code might be causing this bug.

@ Emilio, do you have any suggestions for how to diagnose this bug? Are our paint suppression heuristics allowing the new page to paint "too soon"?

Comment 28

[Emilio Cobos Álvarez (:emilio)]

I suspect this might be caused by bug 1731132 instead... I can only reproduce this very sporadically, is there any chance we could get a narrower regression range with fission enabled? So something like mozregression --good 92 --pref fission.autostart:true -a https://bugzilla.mozilla.org?

Does a build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=07076d5246dcd43457213aa474a2d6d933360813 still show the issue?

Comment 29

[Alice0775 White]

(In reply to Chris Peterson [:cpeterson] from comment #27)

@ Alice and zdnex, when you reproduce the flash, if you navigate back, does the previous page load instantly? If so, then it is probably in Firefox's "bfcache". Knowing whether the previous page is in the bfcache would help us isolate which code might be causing this bug.

No flash occurs when back/forward navigation.

Comment 30

[Alice0775 White]

Regression window. the bug first appears:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ab936b7f0c9f9e0b27e42e3f7909131bface08b9&tochange=7d32671931b7c2f5cb24b0f4d62bb6884e484175

Once the bug is fixed:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dd2ba7765dcb51dfd213aa734a88f21fe4ec74ea&tochange=3def4d84b1f40d244cffc31005ed67966963041b

Regressed Again:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4d3c7ac994c796987a46604d84b4323ab1193c1a&tochange=f3361711e566a33e9011d6bd00148727afee7a19

Comment 31

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

Attachment: about_support.txt

Hi, I tested this by enabling the fission preferences "fission.autostart" and "gfx.webrender.all" prefs to "true" on Nightly 96.0a1 (2021-11-24) (64-bit) using Windows 10 and I was only able to reproduce it two times right after enabling fission preferences. I tried a couple of pages and it was somewhat hard to reproduce after those two times.
I'm attaching my about:suport file for reference. Hope this helps!

Comment 32

[Emilio Cobos Álvarez (:emilio)]

Olli, it seems the fast paint unsuppression code might be too fast :)

Comment 33

[Olli Pettay [:smaug][[e-mail]]]

ok, that is very much possible. Nothing guaranteed even before my changes that flashing wouldn't happen. Depends on what is on the page.
I'll try to figure out something here

Comment 34

[zdnex]

Well but it happens on a lot of pages when that is active, so I guess there has to be some connection to fission no? Btw I have just tried activating fission on diffrent computer with AMD ryzen and vega graphics on ubuntu 20.04 and there flickering is also.

Comment 37

[Ghot]

I can reproduce this 100% of the time, starting with FF 94.0 and with fission.autostart set to true.
Still present in FF 95.0

https://bugzilla.mozilla.org/show_bug.cgi?id=1744894#c6

I run NO extensions or add-ons
Fission seems to be a great idea, but not if it's going to cause issues like these.

Comment 38

[zdnex]

So it seems that this is much more present than I initially thought. Btw saw this now on windows also. I guess this needs some fix. Is there some way how can we debug this further?

Comment 39

[Emilio Cobos Álvarez (:emilio)]

We know what causes it, the tricky thing is what to do instead...

Comment 40

[Katelyn Gadd (:kael)]

Would it be a meaningful and useful workaround to only do the fast paint if no extensions are injecting content into the page? Then performance sensitive ones like uBlock could opt out of that since they couldn't cause this kind of flicker. Many users likely have no extensions that inject content, so they get the benefit of fast paint.

Comment 41

[zdnex]

In several cases where I have tried it extensions did not play any role as there were empty profiles and it flickering was still there.

Comment 42

[Olli Pettay [:smaug][[e-mail]]]

Does anyone have a page where this happens particularly often? (I've never seen this with bugzilla myself)

Comment 43

[Timothy Nikkel (:tnikkel)]

In bug 1744894 I was able to reproduce well enough to regression range using https://www.elevenforum.com/, clicking between Forums and Whats New

Comment 44

[zdnex]

So is here something more to change or is there at least plan to deactivate fission in current state? I have tried it on another computer and there it happens much more.

Comment 45

[Olli Pettay [:smaug][[e-mail]]]

This is in my todo list. This is tricky to fix, since it is all about timing and the relevant web sites are designed.
The flash can happen also without Fission.

Comment 46

[Olli Pettay [:smaug][[e-mail]]]

But I think I have an idea to try. Hopefully it won't regress page load performance.

Comment 47

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1740499, don't unsuppress so aggressively

Comment 48

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8739b71b8bd9
don't unsuppress so aggressively r=emilio

Comment 49

[Olli Pettay [:smaug][[e-mail]]]

Note, it is not very unlikely that the patch affects performance numbers, especially vismet.

Comment 50

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/8739b71b8bd9

Comment 51

[Alex Finder]

== Change summary for alert #32976 (as of Wed, 19 Jan 2022 00:12:18 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
17%	tabpaint	linux1804-64-shippable-qr	e10s fission stylo webrender	50.36 -> 41.55
13%	tsvg_static	macosx1015-64-shippable-qr	e10s stylo webrender-sw	43.57 -> 38.02
11%	tsvg_static	macosx1015-64-shippable-qr	e10s fission stylo webrender-sw	43.70 -> 38.76
10%	tsvg_static	macosx1015-64-shippable-qr	e10s fission stylo webrender	41.48 -> 37.53
8%	tabpaint	windows10-64-shippable-qr	e10s fission stylo webrender	54.20 -> 49.62

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=32976

Comment 52

[Noemi Erli[:noemi_erli]]

Backed out changeset 8739b71b8bd9 (Bug 1740499) as requested by smaug

https://hg.mozilla.org/integration/autoland/rev/bb3853ed6dfce3f1f4c226b6c6ea26b5af6eb17f

Comment 53

[Norisz Fay [:noriszfay]]

Backout has been merged to central

Comment 54

[Alexandru Ionescu (needinfo me) [:alexandrui]]

(In reply to Noemi Erli[:noemi_erli] from comment #52)

Backed out changeset 8739b71b8bd9 (Bug 1740499) as requested by smaug

https://hg.mozilla.org/integration/autoland/rev/bb3853ed6dfce3f1f4c226b6c6ea26b5af6eb17f

== Change summary for alert #33026 (as of Sat, 22 Jan 2022 17:30:06 GMT) ==

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)
10%	imgur fnbpaint	macosx1015-64-shippable-qr	cold fission webrender	182.11 -> 200.04

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
5%	google-search loadtime	linux1804-64-shippable-qr	cold fission webrender	1,289.70 -> 1,220.96

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=33026

Comment 55

[Daniel Holbert [:dholbert]]

Capturing the current state of this bug, as part of a pass over our S2 bugs:

• The fix here landed, but was backed out for having caused bug 1750951 (a perf regression).
• bug 1750732 (which this bug depends on) is filed on avoiding that perf-regression, so that this can re-land.
• So, I think next-action here is for bug 1750732 to be fixed.

Comment 56

[Olli Pettay [:smaug][[e-mail]]]

Yes. And it is on my todo list, but I've been fixing other higher priority Fission regressions.

Comment 57

[Alexandru Ionescu (needinfo me) [:alexandrui]]

(In reply to Noemi Erli[:noemi_erli] from comment #52)

Backed out changeset 8739b71b8bd9 (Bug 1740499) as requested by smaug

https://hg.mozilla.org/integration/autoland/rev/bb3853ed6dfce3f1f4c226b6c6ea26b5af6eb17f

== Change summary for alert #33053 (as of Tue, 25 Jan 2022 07:37:38 GMT) ==

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)
21%	tabpaint	windows10-64-shippable-qr	e10s fission stylo webrender	46.52 -> 56.43
16%	tabpaint	windows10-64-shippable-qr	e10s fission stylo webrender	48.24 -> 55.84
11%	tabpaint	windows10-64-shippable-qr	e10s fission stylo webrender-sw	49.85 -> 55.22

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
7%	pdfpaint	windows10-64-shippable-qr	e10s fission stylo webrender	622.00 -> 581.38

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=33053

Comment 59

[Pascal Chevrel:pascalc]

Smaug, is there progress here? Is it still a P2/S2? Thanks

Comment 60

[Donal Meehan [:dmeehan]]

Has there been any updates in the past month - is the priority/severity correct, re: comment 59

Comment 61

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

The bug assignee didn't login in Bugzilla in the last months and this bug has priority 'P2'/severity 'S2'.
:dholbert, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 62

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:dholbert, since the bug has high priority, high severity and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 63

[Marco Castelluccio [:marco]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Comment 64

[Ghot]

I don't understand all the codes and abbreviations in this thread, but the problem still exists.

Comment 65

[Daniel Holbert [:dholbert]]

Adjusting severity to s3; still would be great to get this fixed, but doesn't feel S2-level at this point.

(smaug, feel free to revert if you disagree.)

Comment 66

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

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:smaug, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 67

[Daniel Holbert [:dholbert]]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #66)

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.

(see comment 65)

Comment 68

[Jens Stutte [:jstutte]]

Let's keep S3 as :dholbert suggested in comment 65.