Closed Bug 1604504 Opened 4 years ago Closed 4 years ago

Part of the image remains blocked while scrolling when the browser is set to 100% after it was zoomed out

Categories

(Core :: Web Painting, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1611660
Tracking Status
firefox-esr68 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix

People

(Reporter: obotisan, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Affected versions

  • Firefox 72.0b7
  • Firefox 73.0a1

Affected platforms

  • Windows 10 x64
  • macOS 10.15
  • Ubuntu 18.04 x64

Steps to reproduce

  1. Go to https://bug1209970.bmoattachments.org/attachment.cgi?id=8667908
  2. Zoom out by using CTRL + scroll.
  3. Click on the zoom level from URL bar in order to get back to 100%.
  4. Then scroll the page down.

Expected result

  • The red circle stays inside the target.

Actual result

  • The red circle remains blocked on the page and only the target moves.

Regression range

  • First bad: 2019-03-26
  • Last good: 2019-03-25
  • I was not able to find a pushlog. Mozregression just send me errors while trying to do that.

Additional notes

  • Please look at the attached video.

I re-ran mozregression and was able to narrow it down to the following push:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=365ff23dd4c93ef26743e3fa339b5fac3bf15b66&tochange=2bf6bddf9a8a5c52222273ee787bfca7e6c97394

which contains bug 1535507.

Miko, do you know what might be happening here?

Flags: needinfo?(mikokm)
Regressed by: 1535507
Has Regression Range: --- → yes

Anyways, moving to Web Painting based on the regression range.

Component: Panning and Zooming → Web Painting

Hi Jessie, is there anyone with cycles to look into this regression?

We will try and take a look ASAP, I am not sure we will get it fixed by 74 yet.

Flags: needinfo?(jbonisteel)

This was regressed by ActiveLayerTracker expiry -part of bug 1535507. Matt had a theory that this might be caused by AGRs changing due to scrolling activity, in which case we would need to rebuild the display items (the patch changed this behavior).

Flags: needinfo?(mikokm)

Pernosco recording: https://pernos.co/debug/rOWs69XQQFM2feTdHnPBkQ/index.html#f{m[AgKl,AA_,t[Qg,DzlG_,f{e[AgKj,IT4_,s{af0La80AA,bAYE,oB+ehag,uB+b+ZA___

We keep scrolling the root scroller to 0,0 because the APZ layout viewport seems off. GetScrollPosition has the right position. I don't know how the layout viewport value in the scroll request is computed though.

Miko and I have been discussing this. We have a theory, that this is the same issue as bug 1611660, and should be fixed by it.

(In reply to Botond Ballo [:botond] [spotty responses until Feb 19] from comment #7)

Miko and I have been discussing this. We have a theory, that this is the same issue as bug 1611660, and should be fixed by it.

I can confirm that applying the patch for bug 1611660 fixes this on my MBP.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: