User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36

Steps to reproduce:

Hardware:

• i7-6700k (4/8 cores with Intel HD Graphics 530)
• 32GB DDR4 RAM
• Linux 5.9.11-arch2-1
• Xorg / GNOME 3.38
• Mesa 20.2.3-1
• Firefox Nigthly 85.0a1 (2020-11-28) (64-bit) with no extensions

layers.acceleration.force-enabled: true

Tested with both WebRender enabled and disabled.

Reproduction:

• Go to https://elixir.bootlin.com/linux/v5.8.11/source/kernel/sched/fair.c
• Scroll to mid page and select some code (and keep is selected)
• Scroll up quickly by dragging the scroll-bar upwards

Actual results:

The page takes a while to actually show the page (~2 seconds).

Expected results:

Without text selection, the page renders promptly so should it with text selection.

Setting a component for this enhancement in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Can you use gecko profiler (https://profiler.firefox.com/) to find the weak spot?
Thanks.

I can reproduce the issue on Nightly85.0a1 Windows10 if some code is selected.

Without text selection: https://share.firefox.dev/2Ig4uCO

With text selection: https://share.firefox.dev/36Ld5H1

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ab8293506be28247f76acb9e9da78a20e6ffad0f&tochange=399464979f2159ebd9108da3a28a09540948a021

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a3b77a006a201a4ee0fed2ca28556179d33ab5f0&tochange=b5f6cc47313dfd024408e6c8f74555410638e3cb

I can still reproduce this. Ping?

Ping. I can still reproduce this issue with the latest nightly.

This patch does not fix the root cause of the issue, which is described in bug 1503581.
What this patch does fix, is that we now reuse the results of the expensive computation at least until the text frame is reflowed, or if the selection changes.

Hi,
As per comment 4 I will update "has regression range" field accordingly.
Best,
Clara

Backed out for causing multiple failures.

Backout link: https://hg.mozilla.org/integration/autoland/rev/f40f0ac8c4e83eef889430799aa8f699f6c0dfed

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Copt%2Cmochitests%2Ctest-linux1804-64-qr%2Fopt-mochitest-plain-e10s%2C1&revision=01519685a650c76edc0922bf1f4a8b9a61ea0798&selectedTaskRun=KItZKhfpQtqa-sQuoIVy_w.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=334191340&repo=autoland&lineNumber=11212
https://treeherder.mozilla.org/logviewer?job_id=334190337&repo=autoland&lineNumber=22557
https://treeherder.mozilla.org/logviewer?job_id=334188611&repo=autoland&lineNumber=38148

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

I was able to reproduce this issue on Firefox 85.0a1 (2020-11-28) on macOS 10.15.7.

Tried verifying it on Firefox 89.0b9 and Firefox 90.0a1 but it seems to be still reproducing (see attachment). Is there something that can be done?

(In reply to Catalin Sasca, QA [:csasca] from comment #14)

I was able to reproduce this issue on Firefox 85.0a1 (2020-11-28) on macOS 10.15.7.

Tried verifying it on Firefox 89.0b9 and Firefox 90.0a1 but it seems to be still reproducing (see attachment). Is there something that can be done?

I think what you are observing is correct. As mentioned in the comment 8, this patch only mitigates the problem. The root cause of this issue is tracked in bug 1503581.

Do you see any improvement with newer Firefox? The content should reappear much quicker now after scrolling.

On this page, we call the slow nsTextFrame::IsFrameSelected() function almost ten thousands times per page scrolled (and multiple times per frame). Based on casual testing, this patch caches around 90-95% of those calls.

Yes, the performance is a bit better (~1 second) to display the text. Reverified on Firefox 89.0b10 and 90.0a1 (2021-05-09) under macOS 10.15.7, Ubuntu 20.04 and Windows 10.