Typing in input fields does not visually update

RESOLVED FIXED in Firefox 47

Status

()

Core
Panning and Zooming
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: kats, Assigned: rbarker)

Tracking

({regression})

46 Branch
mozilla47
regression
Points:
---

Firefox Tracking Flags

(firefox47 fixed)

Details

Attachments

(1 attachment)

In the latest nightly I'm frequently seeing problems where I focus on an input field, start typing, and the field does not visually update to show what I have typed. I saw it just now editing the bug dependency list on a bug, and saw it this morning on some other page as well, don't remember which. Once the keyboard is dismissed the field updates to show what I typed. I'll try to find STR.
Seems to always happen after the page zooms in to the input field. Not every time that happens, but sometimes. Probably a regression from Randall's patch which landed recently - maybe some state getting out of sync somewhere.
(Assignee)

Updated

2 years ago
Assignee: nobody → rbarker
(Assignee)

Updated

2 years ago
Component: Keyboards and IME → Panning and Zooming
Product: Firefox for Android → Core
(Assignee)

Comment 2

2 years ago
Created attachment 8715020 [details] [diff] [review]
0001-Bug-1242173-Typing-in-input-fields-does-not-visually-update-r-16020214-8e6ef903.patch
(Assignee)

Updated

2 years ago
Attachment #8715020 - Flags: review?(botond)
(Assignee)

Comment 4

2 years ago
Explanation from #apz IRC:

1:43 PM <•kats> so what's happening during the animation is that we send repaint requests for every frame of animation
1:43 PM <•kats> these will have a constantly changing zoom value
1:43 PM <•kats> now let's stay we start off with everything in sync at 1.0 zoom and we're animating to a 2.0 zoom
1:43 PM <•kats> and let's say the animation has 10 steps, so the repaint requests will be at 1.1, 1.2, 1.3, ... 1.9. 2,0
1:44 PM <•kats> so the first repaint request gets sent, the metrics will have presShellResolution=1.0 and mZoom=1.1
1:44 PM <•kats> and the APZCCallbackHelper will compare the 1.0 to the 1.0 on content side, and say "yup, this is good" and call SetResolutionAndScaleTo with 1.1
1:44 PM <•kats> ok, now the second repaint request comes from APZC
1:45 PM <•kats> the second repaint request has presShellResolution = 1.0 and mZoom = 1.2
1:45 PM <•kats> this one gets rejected by APZCCallbackHelper because on the content side the presShell resolution is now 1.1
1:45 PM <•kats> and there may be a few more repaint requests following that (say the ones for 1.3 and 1.4) that similarly get rejected
1:46 PM <•kats> at some point content finishes doing its repaint, and sends a NotifyLayersUpdate to APZC, with mPresShellResolution = 1.1
1:46 PM <•kats> so now APZC has mPresShellResolution = 1.1 and (say) mZoom = 1.5
1:46 PM <•kats> so when it sends the next repaint request that's what gets sent to APZCCallbackHelper, and it takes effect because the 1.1 matches what the resolution is on the content side
1:47 PM <•kats> so now APZCCallbackHelper calls SetResolutionAndScaleTo(1.5)
1:47 PM <•kats> and APZC continues sending more repaint request at 1.6, 1.7 etc. that now get rejected
1:47 PM <•kats> ok, so now we get to the end of the animation
1:47 PM <•kats> APZC sends the final repaint request at 2.0
1:47 PM <•kats> and let's say content is still processing the 1.5 repaint request
1:47 PM <•kats> so the 2.0 one is rejected by APZCCallbackHelper
1:48 PM <•kats> so when the NotifyLayersUpdate call comes in with 1.5 as the presShellResolution, APZC was in a state where its internal presShellResolution = 1.1 and mZoom = 2.0
1:50 PM <•kats> so APZC picks up presShellResolution = 1.5 and its mZoom is still 2.0
1:50 PM <•kats> at this point it's done the animation so it's not even trying to send out more repaint requests, and so that's what we end up in as the final state
1:50 PM <•kats> what my patch does is trigger a new repaint when that 1.5 comes in to NotifyLayersUpdated
1:50 PM <•kats> and the second part of the patch allows the repaint request to get through the deduplication code, because mLastDispatchedPaintRequest still has 1.1 in the resolution field, even though mZoom is 2.0
1:51 PM <•kats> so the patch allows one extra repaint request to get through at the end of the animation, which gets to APZCCallbackHelper with presShellResolution = 1.5 and mZoom = 2.0
1:51 PM <•kats> and that will set the content-side resolution to 2.0
1:51 PM <•kats> (which will then trigger another NotifyLayersUpdated to APZC with 2.0 as the presShellResolution)
1:51 PM <•kats> and then everything settles down and everything is in sync

(edited to remove my unhelpful interjections).
Comment on attachment 8715020 [details] [diff] [review]
0001-Bug-1242173-Typing-in-input-fields-does-not-visually-update-r-16020214-8e6ef903.patch

Review of attachment 8715020 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks! The explanation in comment 4 made this easy to understand.
Attachment #8715020 - Flags: review?(botond) → review+

Comment 7

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/875b8cfc1587
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox47: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
You need to log in before you can comment on or make changes to this bug.