1642603 - Screen jumping while typing in an input field inside a css transformed element with perspective

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[georgekuttya]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36

Steps to reproduce:

Please see the following codepen https://codepen.io/qburst-george/pen/XWXrQLJ, please scroll down and type something in the input field

Actual results:

The page went to top and resulted in a jumping effect

Expected results:

Should not scroll to top

Comment 1

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

Thanks for the details. I was able to reproduce on (OS), on the following versions, on win 10 pro, macOs 10.14 and ubuntu 18.04

I've tried Release 77.0 (64-bit),
Beta 78.0b5 (64-bit) (64-bit) and
Firefox Nightly 79.0a1 (2020-06-11) (64-bit)

This won't occur in chrome.

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I think that's the code that tries to scroll something into view getting confused.

Comment 3

[Alice0775 White]

Regression window:https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=55a4c8d1591a4131ff318de7e887c37e5c0a1ef9&tochange=b38e8adb53185e985e3006c96a357abeef380a67

:mstange,
Your bunch of patch seems to cause the issue. Can you please look into this?

Comment 4

[Markus Stange [:mstange]]

Interesting!

Comment 5

[Markus Stange [:mstange]]

Aha! Well-hidden inside PresShell::ScrollFrameRectIntoView there's a comment that says "This function needs to work even if rect has a width or height of 0."

This patch made it so that for empty rects, the rect's position is considered meaningless. That's not what this caller expects.

Comment 6

[Markus Stange [:mstange]]

Attachment: Bug 1642603 - Make TransformAndClipBounds stop discarding the corner positions of empty rectangles. r=kip

Comment 7

[Markus Stange [:mstange]]

The rectangle in this case is the text insertion rectangle for the caret in the textbox, which has a width of zero.

Comment 8

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=60577987ab4bb65dc6aca594ed560c9ef4a1831a

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/239dea266763
Make TransformAndClipBounds stop discarding the corner positions of empty rectangles. r=kip

Comment 10

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/239dea266763

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Is this something we should consider uplifting to ESR78?

Comment 13

[Markus Stange [:mstange]]

Yes, definitely.

Comment 14

[Markus Stange [:mstange]]

Comment on attachment 9156463 [details]
Bug 1642603 - Make TransformAndClipBounds stop discarding the corner positions of empty rectangles. r=kip

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Annoying regression compared to the previous ESR
• User impact if declined: Things can scroll to unexpected places when a text field is focused.
• Fix Landed on Version: 79
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Has tests and has baked on Nightly
• String or UUID changes made by this patch: none

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9156463 [details]
Bug 1642603 - Make TransformAndClipBounds stop discarding the corner positions of empty rectangles. r=kip

Sounds like a pretty noticeable issue for users updating to the new ESR release. Approved for 78.1esr.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/203c34bc2d28

Comment 17

[Oana Botisan, Desktop QA]

I managed to reproduce this issue using an older version of Nightly from 2020-06-02 on Windows 10x64.
I verified the fix on Windows 10x64, Ubuntu 18.04x64 and macOS 10.12 using Firefox 78.1 esr, Firefox 79.0 and Firefox 80.0a1. The issue is not reproducing anymore.