If a page is tall (greater than 16,384 pixels or so), the text near the bottom of the page is truncated and not rendered correctly on a full page screenshot. Other elements such as images are rendered correctly.

I will attach a testcase and sample image.

Sample screenshot (look near the bottom to see the vertically truncated text).

Hey Matt, do you know why this might be happening? We're passing a truncated rect into the captureTab (https://searchfox.org/mozilla-central/rev/9c91451cc2392d942a42493fc895f5aeeddde45d/browser/extensions/screenshots/background/takeshot.js#26-27,36-42,59), but it looks like it's cropping the text element within it.

If this doesn't seem like a screenshots issue, we can move it out of this component

Mark, could you please attach your about:support information. I cannot reproduce this on my computer.

This is slightly redacted about:support content from a new Firefox 91.0.2 profile on a Windows 10 computer (I replaced the user name within file system paths with --redacted--). I did not make any changes to preferences except to disable DoH when prompted. I can reproduce this problem in Windows 10 and macOS 11.5.x, on several different computers.

Hmm, that's strange I am unable to reproduce, then.

Are you able to use mozregression to determine whether this is a regression or not?

(In reply to Jamie Nicol [:jnicol] PTO until 2021-09-20 from comment #5)

Are you able to use mozregression to determine whether this is a regression or not?

Maybe, or I could at least do some manual testing with older builds to narrow things down... except I don't know if or when this bug was not present. Any suggestions for how old of a build I should start with? I do not know when the screenshot code last had major changes applied to it, and the same for the rendering code or any other module that might be to blame.

Mark, do you still see this if you change layers.async-pan-zoom.enabled = false in about:config and restart?

(In reply to Mark Smith [:mcs] from comment #6)

(In reply to Jamie Nicol [:jnicol] PTO until 2021-09-20 from comment #5)

Are you able to use mozregression to determine whether this is a regression or not?

Maybe, or I could at least do some manual testing with older builds to narrow things down... except I don't know if or when this bug was not present. Any suggestions for how old of a build I should start with? I do not know when the screenshot code last had major changes applied to it, and the same for the rendering code or any other module that might be to blame.

If I'm unsure about when a bug was regressed (or if it may not be a regression at all) I like to pick a date several years ago - since the number of steps is logarithmic it doesn't take too much longer! If it doesn't reproduce on the first date I pick, I try an earlier one. If firefox won't run or immediately crashes then I give up and treat it as always being broken

(In reply to Kestrel from comment #7)

Mark, do you still see this if you change layers.async-pan-zoom.enabled = false in about:config and restart?

Yes, I still see it.

Here are the results from mozregression (done on a Windows 10 64-bit system):

Last available build that does not exhibit the bug:
app_name: firefox
build_date: 2018-10-30
build_file: C:\Users\mcs.mozilla\mozregression\persist\2018-10-30--mozilla-central--firefox-65.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2018/10/2018-10-30-22-40-27-mozilla-central/firefox-65.0a1.en-US.win64.zip
changeset: be32f4014f92d0ab717621997e0d36c9bc1c479b
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=be32f4014f92d0ab717621997e0d36c9bc1c479b&tochange=7e4afca2ca929a07128419874845a94c2ff9aa3d
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

First build that does have the bug:
app_name: firefox
build_date: 2018-10-31
build_file: C:\Users\mcs.mozilla\mozregression\persist\2018-10-31--mozilla-central--firefox-65.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2018/10/2018-10-31-22-35-03-mozilla-central/firefox-65.0a1.en-US.win64.zip
changeset: 7e4afca2ca929a07128419874845a94c2ff9aa3d
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3dc7cdbb2b5fe3cbbe34b19fc32b3562b6ff6ff9&tochange=7e4afca2ca929a07128419874845a94c2ff9aa3d
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

I think that means the culprit is in this range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=be32f4014f92d0ab717621997e0d36c9bc1c479b&tochange=7e4afca2ca929a07128419874845a94c2ff9aa3d

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bhood, since the bug doesn't have a severity set, could you please set the severity or close the bug?

For more information, please visit auto_nag documentation.

This is a limit that has become imposed historically due to some of the back-end software we are using (i.e., Skia). This has propagated throughout our system as a result.

There is a tracking bug for re-evaluating this in our pipeline: https://bugzilla.mozilla.org/show_bug.cgi?id=1702494