Closed Bug 1915230 Opened 1 month ago Closed 28 days ago

Sidebar animations need to take content zoom level into account

Categories

(Firefox :: Sidebar, defect, P1)

defect

Tracking

()

RESOLVED FIXED
132 Branch
Tracking Status
firefox132 --- fixed

People

(Reporter: mconley, Assigned: emilio)

References

Details

(Whiteboard: [fidefe-sidebar])

Attachments

(3 files, 1 obsolete file)

STR:

In a recent Nightly (with the animations from bug 1898251 available), with sidebar and vertical tabs enabled:

  1. Visit any site, and set the zoom level to > 100%.
  2. Open the sidebar to initiate the animation

ER:

The sidebar animation to translate a capture of the content area horizontally, and cover the entire content area while doing so.

AR:

The captured screenshot seems to be hardcoded to 100% scale, and so its size doesn't fully cover the content area when zoomed at > 100%. When the content area zoomed < 100%, the screenshot is still captured at 100% scale, so the overlap is correct (but the scaling between capture and content area is not).

Whiteboard: [fidefe-sidebar]

Is there a clear and straightforward fix for this?

We ran into this many, many times and ways in Screenshots. If the user has zoomed in/out of the page, window.devicePixelRatio is the multiplier you need to get the correct screenshot and seamless transition. Both the canvas size and drawSnapshot call need the devicePixelRatio from the child/content process. For the canvas, I believe width and height both need to be multiplied by the devicePixelRatio, and for the drawSnapshot call, devicePixelRatio (or scaling factor) is the 2nd argument you pass in.

This will necessitate a new child actor to send a message with the devicePixelRatio to the parent, as I don't think we have this information already in the parent process where SidebarController runs.

You have the browsingContext.fullZoom value and the parent window's devicePixelRatio, fwiw... Which doesn't account for the app unit scale, but should be ~identical / very close.

That said, a transform animation seems like it'd be a better approach?

This looks simpler, a lot smoother on my machine, and shouldn't cause
content resizes.

Maybe eventually we can use view transitions for this, seems like the
perfect use-case.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

While the intention behind this is appreciated Emilio, it does look like it completely rewrites kcochranes animation work, and it might have implications for her work in bug 1908989 which is in review. It'd be preferrable if there could be an agreement with the original patch author/sidebar team before a major refactor or change in approach, especially now while we're in a critical phase for remaining work for the release experiment.

Sure, the reason I sent comment 5 was to try out making it a transform animation (as per comment 4 and discussions on matrix with Sam and Markus). If you want to keep the current approach or rework it, that's fine for me! I wrote it just to confirm that using transform would work. That said, the result is a lot better on the machines I've tried (and it's also a lot less code).

Attachment #9422126 - Attachment description: Bug 1915230 - Make sidebar animation use width + scale. r=#sidebar-reviewers!,mconley!,dao! → Bug 1915230 - Make sidebar animation use transforms. r=#sidebar-reviewers!,mconley!,dao!
Severity: -- → S3
Priority: -- → P1
See Also: → 1916599
Attachment #9423277 - Attachment description: WIP: Bug 1915230 - WIP - Use a translate transform only. → Bug 1915230 - Use a translate transform only. r=#sidebar-reviewers!,mstange

Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).

Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
non-remote frames.

This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.

I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.

See Also: → 1917458

Comment on attachment 9423381 [details]
Bug 1915230 - Only send resizes for remote browsers once per frame. r=mstange,#layout

Revision D221405 was moved to bug 1917458. Setting attachment 9423381 [details] to obsolete.

Attachment #9423381 - Attachment is obsolete: true

And tweak the default duration as per UX feedback.

Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/aaaae84198ae Make sidebar animation use transforms. r=mconley,dao,sidebar-reviewers,desktop-theme-reviewers,kcochrane https://hg.mozilla.org/integration/autoland/rev/749011ce7a8a Use a translate transform only. r=sidebar-reviewers,desktop-theme-reviewers,kcochrane,dao https://hg.mozilla.org/integration/autoland/rev/05fe9b71651f Make animation and duration configurable. r=sidebar-reviewers,kcochrane
Pushed by smolnar@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/85a061e28d5d Make sidebar animation use transforms. r=#sidebar-reviewers!,mconley!,dao! https://hg.mozilla.org/integration/autoland/rev/3c348ff27dc1 Use a translate transform only. r=#sidebar-reviewers!,mstange https://hg.mozilla.org/integration/autoland/rev/80939eef1317 Make animation and duration configurable. r=#sidebar-reviewers CLOSED TREE
Status: ASSIGNED → RESOLVED
Closed: 28 days ago
Resolution: --- → FIXED
Target Milestone: --- → 132 Branch
Flags: needinfo?(emilio)
Regressions: 1918765
Blocks: 1917801
Regressions: 1919041
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: