Closed Bug 938324 Opened 6 years ago Closed 6 years ago

Defect - NavBar and OSK have different transition timing/aren't in sync

Categories

(Firefox for Metro Graveyard :: App Bar, defect, P2)

x86
Windows 8.1
defect

Tracking

(firefox28 verified, firefox29 verified)

RESOLVED FIXED
Firefox 29
Tracking Status
firefox28 --- verified
firefox29 --- verified

People

(Reporter: shorlander, Assigned: sfoster)

References

Details

(Whiteboard: [block28] feature=defect c=tbd u=tbd p=1 )

Attachments

(1 file, 2 obsolete files)

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?
Attachment #8346872 - Flags: feedback?(mbrubeck)
Attachment #8346872 - Flags: feedback?(jmathies)
Hey Sam, can you provide a point value.
Flags: needinfo?(sfoster)
Updated: p=1
Flags: needinfo?(sfoster)
Whiteboard: [release28] feature=defect c=tbd u=tbd p=0 → [release28] feature=defect c=tbd u=tbd p=1
Attached patch osk-transition (obsolete) — Splinter Review
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?
Attachment #8346872 - Attachment is obsolete: true
Attachment #8346872 - Flags: feedback?(mbrubeck)
Attachment #8346872 - Flags: feedback?(jmathies)
Flags: needinfo?(mmaslaney)
Blocks: metrov1it21
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
Priority: -- → P2
QA Contact: jbecerra
Whiteboard: [release28] feature=defect c=tbd u=tbd p=1 → [block28] feature=defect c=tbd u=tbd p=1
Flags: needinfo?(mmaslaney)
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.
Attachment #8346932 - Attachment is obsolete: true
Attachment #8347559 - Flags: review?(jmathies)
OS: Mac OS X → Windows 8.1
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+
On fx-team: https://hg.mozilla.org/integration/fx-team/rev/2ea6399bbea3
Whiteboard: [block28] feature=defect c=tbd u=tbd p=1 → [block28] feature=defect c=tbd u=tbd p=1 [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/2ea6399bbea3
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+
Flags: in-testsuite?
Flags: in-qa-testsuite?
Keywords: verifyme
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
Flags: in-testsuite?
Flags: in-testsuite-
Flags: in-qa-testsuite?
Flags: in-qa-testsuite-
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.