[Reporting] set zoom to 1 for long reports

[pmuellr]

resolves #138812

Summary

Chrome has a hard limit of 16000 rows in a page screenshot. We currently set the zoom level to 2, which means any report > 8000 in height won't be rendered correctly.

As a partial fix, we'll set zoom to 1 for any report that is > 8000 height.

for more info: puppeteer/puppeteer#359

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
• Flaky Test Runner was used on any tests changed
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
• Review the backport guidelines and apply applicable backport:* labels.

Identify risks

Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.

Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.

• See some risk examples
• ...

[kibanamachine]

Cloud deployments require a Github label, please add ci:cloud-deploy or ci:cloud-redeploy and trigger the job through the checkbox again.

[pmuellr]

@darnautov this is a riff on your PR #246560

I only set the zoom to either 1 or 2 - a zoom of 2 is what we've been using for a while, and

• I'm worried some customers may notice a loss is resolution
• not sure how well scaling to non-integral values is going to work, especially with software rendering

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[pmuellr]

To test this, here's a Saved Object export for the Web Logs sample, which is ~12K in height, due to one of the graphs being resized to be VERY TALL. There's a table at the bottom, so you can tell if it rendered the whole thing. Remove the .txt from the file name to import. Add the Web Logs sample first!

Note, this dashboard likely works without this patch on Mac, but that's because it's using a GPU. The problem appears to be related to running with no gpu. To run on Mac with no gpu, you'll need to hack the code: #246560 (comment)

[Logs] Web Traffic Dashboard - Long.ndjson.txt

[pmuellr]

Closing in preference of #248566 .

That PR will handle longer reports (this one could only handle reports < 16K height), and this one has some kind of a problem with the clipping rectangle - I was seeing the "chrome" of the Dashboard app in the resulting images, when the zoom was set to 1.

[pmuellr]

Closed PR #248566 and will fix the "long report" issue with this PR.

The "tiling" approach in that PR does work, but requires a lot of memory. It may be useful in the future if we move to some kind of centralized printing service where memory isn't as much of an issue.

[pmuellr]

In the cloud deployment, I added a modified version of the Web Traffic dashboard, that is 12888 pixels high. It generates PNGs and PDFs fine for this dashboard, where a cloud deployment without these changes fails to run, or generates a garbled image.

[darnautov]

Tested, LGTM

[darnautov]

Shall we update the docs https://www.elastic.co/docs/explore-analyze/report-and-share by adding the "Certain limitations" sections similar to the CSV exports? cc @nastasha-solomon

[nastasha-solomon]

Yeah, good call. Are there width restrictions for screenshots too?

[pmuellr]

It seems like it's hard or not practival to make "wide" dashboards in Kibana, that would have problems printing like this. So I'd say we don't have to worry about width issues.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 9dbbd10
• Cloud Deployment

Metrics [docs]

✅ unchanged

History

• 💚 Build #387212 succeeded f5f0f7e
• 💛 Build #381193 was flaky 30975a6
• 💛 Build #381071 was flaky 12d67fd
• 💔 Build #380692 failed 846899a

[kibanamachine]

Starting backport for target branches: 8.19, 9.1, 9.2, 9.3

https://github.com/elastic/kibana/actions/runs/21613375117

[kibanamachine]

💔 Some backports could not be created

Status	Branch	Result
❌	8.19	Backport failed because of merge conflicts You might need to backport the following PRs to 8.19: - [EDR Workflows] Test improvement: get rid of duplicate test errors in afterAll (#251046) - [SLO] Fix SLO filter containing space and wildcard (#251033)
❌	9.1	Backport failed because of merge conflicts You might need to backport the following PRs to 9.1: - [Cases][Webhook] - Better handle 204 responses (#251090)
❌	9.2	Backport failed because of merge conflicts You might need to backport the following PRs to 9.2: - [Fleet] Use package policy input when available to retrieve agent health components (#251093) - [Cases][Webhook] - Better handle 204 responses (#251090) - [SLO] Fix SLO filter containing space and wildcard (#251033)
✅	9.3

Note: Successful backport PRs will be merged automatically after passing CI.

Manual backport

To create the backport manually run:

node scripts/backport --pr 248785

Questions ?

Please refer to the Backport tool documentation

[pmuellr]

💚 All backports created successfully

Status	Branch	Result
✅	9.2
✅	9.1
✅	8.19

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation