Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#18583 closed defect (fixed)

dojox/mobile/SwapView does not animate correctly

Reported by: alancutter Owned by: Youcef Mammar
Priority: low Milestone: 1.9.8
Component: DojoX Mobile Version: 1.10.4
Keywords: Cc:
Blocked By: Blocking:

Description

Browsers affected: Chrome 42, Firefox 39 (and probably earlier).

Repro steps: http://download.dojotoolkit.org/release-1.10.0/dojo-release-1.10.0/dojox/mobile/tests/test_SwapView-demo.html Swipe the bottom section horizontally.

Seen behaviour: The panels jump forward on mouse/finger up for their exit animation.

Expected behaviour: They should slide smoothly into position. This can be observed on Firefox in: download.dojotoolkit.org/release-1.8.0/dojo-release-1.8.0/dojox/mobile/tests/test_SwapView-demo.html This is because dojox 1.8 falls back to JS if the webkit prefix is not present while dojox 1.10 has better CSS3 Animation detection.

See Chromium bug for further context: code.google.com/p/chromium/issues/detail?id=478765

""" Before this patch to Chrome (chromium.googlesource.com/chromium/blink/+/9c5f20c3f5cc16cd8070a74a9c2cedecb600cbea) animations ignored changes in @keyframes rules. After the patch animations will restart in response to dynamic updates to their @keyframes rule. Example: jsfiddle.net/swqpvwkt/

Narrowed the bug down to be the change in behaviour conflicting with this line in dojox/mobile: github.com/dojo/dojox/blob/1.8/mobile/scrollable.js#L1073 The library recycles an @keyframes rule by updating it with new keyframes and using it to start a new animation. Any existing animations get updated to reflect the new @keyframes rule instead of the animation they were started with. This explains the "collapsing" of elements to the same location on mouse up at the end of a horizontal swipe because they are playing the same @keyframes rule.

The change in behaviour for @keyframes was decided by spec committee in September 2014: lists.w3.org/Archives/Public/www-style/2014Sep/0130.html So far Chrome and Firefox have implemented the latest specification.

This issue is still present in the latest dojox 1.10 release: github.com/dojo/dojox/blob/1.10/mobile/scrollable.js#L1266 Since Firefox also supports dynamic animation updating. The latest dojox 1.10 release shows the same bug in the latest Chrome and Firefox: download.dojotoolkit.org/release-1.10.0/dojo-release-1.10.0/dojox/mobile/tests/test_SwapView-demo.html

The reason it was not failing for Firefox in dojox 1.8 is because that version was checking for webkit prefixes and falling back to JS if not present thus a different code path was being used in Firefox. In dojox 1.10 it checks for CSS3 Animation support and executes the same code for Chrome and Firefox. """

(Links obscured to avoid spam rejection.)

Change History (10)

comment:1 Changed 4 years ago by Patrick Ruzand

Owner: changed from Patrick Ruzand to Youcef Mammar
Status: newassigned

comment:2 Changed 3 years ago by dylan

Milestone: tbd1.11

Any chance we can land a fix for this for 1.11?

comment:3 Changed 3 years ago by dylan

Priority: undecidedlow

comment:4 Changed 3 years ago by dylan

Milestone: 1.111.12

Ok, after massive triage, ended up with about 80 tickets for 1.11 and 400 or so for 1.12. That's a bit unrealistic, so first I changed all 1.12 to 1.13 (with the plan to move some forward to the new 1.12. Now, I'm moving some of the 1.11 tickets that are less likely to get done this month without help to 1.11. Feel free to help out in January if you want to see this ticket land in 1.11.

comment:5 in reply to:  2 Changed 3 years ago by Youcef Mammar

Replying to dylan:

Any chance we can land a fix for this for 1.11?

Here is a fix suggestion: https://github.com/dojo/dojox/compare/master...tkrugg:swapview

It's fixing the issue, I voluntarily kept the changes minimal, but I have to be critical of the tight coupling that exists around the .mblScrollableScrollTo[012] classes. They are referenced in multiple places, across several files, as you can tell with a quick search: https://github.com/dojo/dojox/search?utf8=%E2%9C%93&q=mblScrollableScrollTo2

comment:6 Changed 3 years ago by dylan

Milestone: 1.121.11

Thanks tkrugg. Go ahead and create a pull request for that change, and we'll plan to land it for 1.11. Agreed that there's likely a better way to clean this up by reducing the tight coupling, but we can revisit that for 1.12 if there's interest.

comment:7 Changed 3 years ago by dylans <dylan@…>

Resolution: fixed
Status: assignedclosed

In 414d4e6be5fbb046fd7b12e33c64dfd2c7945af2/dojox:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:8 Changed 3 years ago by dylans <dylan@…>

In c715891c01676bd7deae89be3bf31eb8df2fabea/dojox:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:9 Changed 3 years ago by dylans <dylan@…>

In c5e5906f7b19f0e2eefad603f5098e2ef71b7ad5/dojox:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:10 Changed 3 years ago by dylan

Milestone: 1.111.9.8
Note: See TracTickets for help on using tickets.