[MGNLUI-377] Action bar has corrupted layout during app switch transition. Created: 07/Dec/12  Updated: 11/Feb/13  Resolved: 19/Dec/12

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Critical
Reporter: Christopher Zimmermann Assignee: Samuli Penttilä
Resolution: Fixed Votes: 0
Labels: frontend
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
duplicate
is duplicated by MGNLUI-508 Corrupted actionbar after navigation ... Closed
relation
is related to MGNLUI-352 Broken layout when switching betweeen... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

This is a followup ticket to MGNLUI-352. The layout does look good when transition is complete.
But it looks bad that the actionbar is gone during the transition and then pops into view.
It should be visible the whole time in the state that the user left it.



 Comments   
Comment by Samuli Penttilä [ 13/Dec/12 ]

Fixed by letting layouts calculate itself first and animate later. User may see randomly target app switching first and then animation take place depending how fast web browser is able to render. This is the best that can be done with small changes.

Comment by Christopher Zimmermann [ 17/Dec/12 ]

It works in my testing but we must prevent that: "User may witness switching app flicking shortly before the animation."
How about this?

  • Create a new CSS class "zoomed-out" which has scale 0 (or 0.0001) but no animation.
  • Apply it immediately before viewport.doSetVisibleApp(app).

The vaadin size calculation should work then, and it would not be possible to see the app before the deferred animation started. Then I think it would be fare to remove the "this is a hack" comment.
Or do you feel there is a more proper approach.

Comment by Samuli Penttilä [ 19/Dec/12 ]

Used that approach with small modifications. Starting from scale 0 would break size calculations but setting opacity to 0 will do the trick. By doing that the app flicking is gone and instead there is background visible what would be desired start point of animation anyway.

Generated at Mon Feb 12 08:36:17 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.