2055555 - Text selection rectangle shows wrong / different part of opened PDF document

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, defect)

Description

[Tobias (:Tobbi) Markus]

Attachment: Screenshot

I'm seeing a bug with text selection in Firefox Nightly (not Release, though). I've already filed this bug on GitHub as https://github.com/mozilla/pdf.js/issues/21584

When selecting text in a PDF document, the selection box does not contain the text selected, but a different part of the PDF file that's being viewed.

Steps to reproduce:

1. Open the pdf.js example viewer at https://mozilla.github.io/pdf.js/web/viewer.html
2. Highlight / select the heading "Trace-based Just-in-Time Type Specialization for Dynamic
   Languages"

Expected results:
The highlight box / rectangle contains the text "Trace-based Just-in-Time Type Specialization for Dynamic
Languages"

Actual results:
The highlight box / rectangle contains part of the name section below the title.

Comment 1

[Marco Castelluccio [:marco]]

It would be great if you could try using mozregression to pinpoint what caused this.

Comment 2

[Alice0775 White]

regression range:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=bddf006f33a761249182e33b5cf59b24b25ef5a6&tochange=7758fcd3b738a1af186a64b2101916f11575fe30

Comment 3

[Calixte Denizet (:calixte)]

:gw can you have a look please ?

Comment 4

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

Set release status flags based on info from the regressing bug 2054854

Comment 5

[Glenn Watson [:gw]]

Attachment: Bug 2055555 - Map the backdrop readback into the parent surface's raster space

A backdrop-filter resolve target can establish a different raster root
than the parent surface it reads back from (for example when it promotes
to a root-snapping raster root inside a scrolled subtree). handle_resolve
intersected the dest and src content rects as if they shared a space,
offsetting the backdrop readback by the scroll amount. Store the
dest->src raster mapping on the ResolveOp and apply it so we read back
the region the backdrop actually covers. The mapping is the identity when
the raster roots match, so the common case is unchanged.

Comment 6

[Glenn Watson [:gw]]

Green try run: https://treeherder.mozilla.org/jobs?repo=try&revision=7095fe0ea154d484a08f85f602705266ac480d6a

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/cf9aa2b437a3
https://hg.mozilla.org/integration/autoland/rev/6d408e3625f1
Map the backdrop readback into the parent surface's raster space r=gfx-reviewers,nical

Comment 8

[amarc]

https://hg.mozilla.org/mozilla-central/rev/6d408e3625f1