Bail out from AsyncPanZoomController::ZoomToRect if the target zoom scale is same as the current scale in the case of zoom-to-focused-input
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox135 | --- | fixed |
People
(Reporter: hiro, Assigned: hiro)
References
(Regressed 1 open bug)
Details
Attachments
(4 files)
In AsyncPanZoomController::ZoomToRect, we do try centralizing the given rect. But in the case of zoom-to-focused-input and if the final zoom scale will be unchanged, it's inconsistent with what we do in nsDOMWIndowUtils::ZoomToFocusedInput which is called before the ZoomToRect.
In ZoomToFocusedInput we do call ScrollContentIntoView with WhereToScroll::Nearest, WhenToScroll::IfNotVisible, it's not supposed to centralize the element.
| Assignee | ||
Comment 1•1 year ago
|
||
It turned out that just skipping the centralizing is NOT sufficient to fix bug 1929516. ZoomToRect still tried to move the scroll offset.
After some more thought, given that ZoomToFocusedInput is supposed to scroll the given element to a proper position, if the final zoom scale will not be changed, we don't need do anything in ZoomToRect.
| Assignee | ||
Comment 2•1 year ago
|
||
Things are not so straight-forward as usual. :/
For example, the fix for bug 1660932, which tried to scroll to the caret position, relies on the fact that ZoomToRect scrolls to the given position. The fix doesn't work if the given focused element is inside an iframe regardless of whether it's in out-of-process or not, I think. I think we should fix bug 1927600 first.
Another issue I notice is that with interactive-widget=resizes-visual or overlays-content, I guess ZoomToRect does ensure the given focused element into the visual viewport (or the visible area on overlays-content mode), without ZoomToRect the element will stay out of view.
| Assignee | ||
Comment 3•1 year ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)
Another issue I notice is that with
interactive-widget=resizes-visualoroverlays-content, I guessZoomToRectdoes ensure the given focused element into the visual viewport (or the visible area on overlays-content mode), withoutZoomToRectthe element will stay out of view.
I confirmed this latter case doesn't matter at all. Phew. :)
| Assignee | ||
Comment 4•1 year ago
|
||
With setting these prefs, even on desktops zoomToFocusedInput zooms in to the
focued element, it would be easier to debug the tests on desktop.
| Assignee | ||
Comment 5•1 year ago
|
||
With the minimized duraion, each test finishes quickly.
Without await promiseApzFlushedRepaints
helper_zoomToFocusedInput_zoom_in_position_fixed.html failed.
| Assignee | ||
Comment 6•1 year ago
|
||
In the next change, we stop zooming in to the focused element if we've already
zoomed in the contents. Thus we will never get TransformEnd notification. There
were two different type of use cases of TransformEnd.
a) No zoom happens, no scrolling happens
b) No zoom happens, but scrolling happens
For 1) awaiting TransformEnd is replaced by awaiting a scrollend event.
For 2) awaiting TransformEnd is replaced by awaiting a
promiseApzFlushedRepaints() call.
| Assignee | ||
Comment 7•1 year ago
|
||
And skip creating a ZoomAnimation for zoom-to-focused-input if the final zoom
scale would be same as the current zoom scale.
A caveat here is that the scrollIntoView operation respects scroll-behavior
property, whereas our ZoomAnimation is always smooth, so that this change will
introduce a UX change in some cases.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
https://hg.mozilla.org/mozilla-central/rev/0396fbf37102
https://hg.mozilla.org/mozilla-central/rev/457119ca702a
https://hg.mozilla.org/mozilla-central/rev/ced0a0b2a075
https://hg.mozilla.org/mozilla-central/rev/673e6bdd2393
https://hg.mozilla.org/mozilla-central/rev/dbf0cf3a740b
Description
•