Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#17775 closed defect (fixed)

SpinWheelSlot doesn't spin when setting a value that is 2 "steps" distance from initial value

Reported by: Virgil Ciobanu Owned by: Adrian Vasiliu
Priority: undecided Milestone: 1.9.4
Component: DojoX Mobile Version: 1.9.3
Keywords: Cc:
Blocked By: Blocking:

Description

When setting a value (using slot.set("value", value) ) that is 2 "steps" distance from initial value the SpinWheelSlot? doesn't spin. I get no error.

I created a test file to demonstrate the problem.

Attachments (1)

test_SpinWheelSlot-not-spin-2-up.html (4.5 KB) - added by Virgil Ciobanu 6 years ago.

Download all attachments as: .zip

Change History (9)

Changed 6 years ago by Virgil Ciobanu

comment:1 Changed 6 years ago by Virgil Ciobanu

I was able to reproduce the same problem using the dojox/mobile/tests/test_DatePicker2.html file.

If I change the line 38 from datePicker1.set("value", "2020-01-01"); to datePicker1.set("value", "2020-01-03");

the "day" slot will not spin, it remains the initial value which in this case was the current day (05 of March).

comment:2 Changed 6 years ago by Adrian Vasiliu

Owner: set to Adrian Vasiliu
Status: newassigned

comment:3 Changed 6 years ago by Adrian Vasiliu

I reproduce with Safari on iOS 6 and 7, and on Nexus 5 Android 4.4, but not on any desktop browser I tried (Chrome 33, FF 27, IE10, and even Safari 5.1.7, all on Win7).

This bug appears to be due to a race condition: at startup, the spinners of the DatePicker? initialize themselves at the current date; later in the execution flow, the app sets a different date, but in some cases the initialization to the current date, which has some asynchronous steps, is executed after the initialization to the custom date thus reverts the shown value to the initial one...

More precisely, I think this is due to the fact that dojox/mobile/SpinWheelSlot tries to execute the initial spin without any animation, and goes through dojox/mobile/scrollable.slideTo() with the 'duration' argument set at 0, however this method in some cases uses setTimeout() thus delaying the execution to the next frame.

I tested successfully the following easy workaround: encapsulate your code to set the date in a setTimeout():

setTimeout(function() {
  ... here the code to set the custom date ...
});

I will probably submit a change in SpinWheelSlot? to avoid the need of this workaround.

comment:4 Changed 6 years ago by Virgil Ciobanu

Thank you very much Adrian for addressing this and for the solution.

My former testing was on Chrome 32 on Ubuntu Desktop 13.10.

I tested again today with Chrome 33 and FF 28 and I cannot reproduce anymore with today's date.

If I set the computer date back to 04 March then I'm able to reproduce the bug but in Chrome only (tested also with Chromium 32 and FF 28).

I also tested that using setTimeout(...) does solve it.

comment:5 Changed 6 years ago by Adrian Vasiliu

Two pull requests for two interconnected issues:

These PRs make it work without the workaround in my testing on a bunch of different browsers. @virgil, if you can give it a try on your side, it would be helpful (double-checking is always helpful :-) ).

Last edited 6 years ago by Patrick Ruzand (previous) (diff)

comment:6 Changed 6 years ago by Adrian Vasiliu <vasiliu@…>

Resolution: fixed
Status: assignedclosed

In df3bb97818ccee3534e1e184b9fc20d7312b22fc/dojox:

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

comment:7 Changed 6 years ago by Adrian Vasiliu <vasiliu@…>

In 866eab946b3b59b0014967153bc0f18dd60e06ec/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 6 years ago by Adrian Vasiliu

Milestone: tbd1.9.4
Note: See TracTickets for help on using tickets.