Closed Bug 938324 Opened 6 years ago Closed 6 years ago
Defect - Nav
Bar and OSK have different transition timing/aren't in sync
When focusing the location field the OSK and the NavBar slide up. The NavBar lags a little behind the OSK. I can't tell if they are actually animating at a different rate or if the timing-function is just different. The result is that the UI feels more sluggish and jarring.
Summary: NavBar and OSK have different transition timing/aren't in sync → Defect - NavBar and OSK have different transition timing/aren't in sync
Whiteboard: [triage] feature=defect c=tbd u=tbd p=0
Whiteboard: [triage] feature=defect c=tbd u=tbd p=0 → [release28] feature=defect c=tbd u=tbd p=0
Any changes here will need to not regress bug 877361, which was where we decided on the current behavior. It looks like MS' animations use multiples of 120ms. I can match the OSK sliding in with: transition: bottom 480ms cubic-bezier(0.1, 0.9, 0.2, 1) 0; .. but notes in 877361 indicate we specifically do *not* want to do that. Are these concerns still valid? I see some jank with the findbar - possibly unrelated. Otherwise, by my testing this appears to work well. I'll attach my WIP patch.
Assignee: nobody → sfoster
As best as I can tell, 480ms and the existing cubic-bezier function are what the OSK uses to slide in. Previously we determined we didn't want to match exactly to avoid measurment/positioning race conditions I guess. I could add 120ms delay so the velocity is matched but our stuff comes in a tad later?
Hey Sam, can you provide a point value.
Whiteboard: [release28] feature=defect c=tbd u=tbd p=0 → [release28] feature=defect c=tbd u=tbd p=1
Much peering at the screen later, I can confirm that a lock-step match with the system animation is a vain hope; sometimes its perfect, then it lags or jumps ahead. Given that, I've gone ahead with the 120ms delay that I hope looks deliberate, like a staggered build-in. The easing was in fact off, this patch has new cubic-bezier values. Try build at: https://tbpl.mozilla.org/?tree=Try&rev=086e55ecbc8d, when its done can you take it for a whirl mmaslaney?
6 years ago
This patch does 2 things: 1) More closely match the animation easing and duration used by the OSK 2) Introduce a delay (90ms) to get a build-in effect as our appbar slides up just after the keyboard slides in. I talked with mmaslaney a bit about this. Its still not ideal and the change is subtle but I think slightly improved.
Comment on attachment 8347559 [details] [diff] [review] Improve synchronization of system on-screen keyboard animation with appbar positioning animation I like it, it's quicker while still managing to avoid the situation where the nav bar gets ahead of the keyboard.
Attachment #8347559 - Flags: review?(jmathies) → review+
Whiteboard: [block28] feature=defect c=tbd u=tbd p=1 → [block28] feature=defect c=tbd u=tbd p=1 [fixed-in-fx-team]
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [block28] feature=defect c=tbd u=tbd p=1 [fixed-in-fx-team] → [block28] feature=defect c=tbd u=tbd p=1
Target Milestone: --- → Firefox 29
Comment on attachment 8347559 [details] [diff] [review] Improve synchronization of system on-screen keyboard animation with appbar positioning animation [Approval Request Comment] Bug caused by (feature/regressing bug #): Mismatch between system animations and metrofx animations User impact if declined: When the on-screen keyboard is shown, the metro browser UI response appears sluggish Testing completed (on m-c, etc.): tested good on m-c Risk to taking this patch (and alternatives if risky): low risk, only Metro code is affected String or IDL/UUID changes made by this patch: none
Attachment #8347559 - Flags: approval-mozilla-aurora?
Attachment #8347559 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Went through the following defect for iteration #21 without any issues. Used the following builds: - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-01-15-00-40-03-mozilla-aurora/ - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-01-15-03-02-29-mozilla-central/ Before testing the issue, I reproduced the original problem and noticed that the Navigation App Bar falls behind the OSK while sliding back to the top making it appear janky. Used the following build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/12/2013-12-08-03-22-01-mozilla-central/ - Ensured that the animation looks smooth when sliding in the OSK from the Navigation App Bar - Ensured that the OSK doesn't get ahead of the Navigation App Bar as stated in comment #7 (sometimes it does happen though) - Ensured the animation/transition was the same under the about:start and other webpages (consistent experience throughout the browser) - Ensured that both the OSK and Navigation animations when dismissing the OSK are smooth and consistent through the browser - Went through all of the above test cases in several different filled views (1/2, 1/3, 2/3 etc..) Quick Note: There's still times were the Navigation App Bar falls behind the OSK but its definitely a bit better than it was before. As mentioned in comment #6, this isn't the ideal fix and is really subtle but definitely an improvement. Marking both release channels are verified.
Setting in-testsuite- and in-qa-testsuite- since we don't support Metro anymore
You need to log in before you can comment on or make changes to this bug.