JDK-8157559 : Linux: Javascript Timing Events stop work on system clock changes at past
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u45,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2016-05-23
  • Updated: 2016-06-03
  • Resolved: 2016-06-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u112Fixed 9Fixed
Related Reports
Duplicate :  
JDK-8089563 - Javascript Timing Events stop work on system clock changes at past
Relates :  
JDK-8089563 - Javascript Timing Events stop work on system clock changes at past
Description
Javascript timing events(setInterval/setTimeout) stop work when system clock set a date in the past.

To reproduce:
- Open this page http://www.w3schools.com/js/tryit.asp?filename=tryjs_setinterval2 in a webview
- Change system date with a date in the past

At this point timer will stop work as each other timing events
Comments
Changeset: eddde58f57f4 Author: Ankit Srivastava <a.ankit.srivastava@oracle.com> Date: 2016-06-03 12:26 +0530 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/eddde58f57f4
03-06-2016
NOTE: you will need to wait to push the backport to 8u-dev until after JDK-8156698 (updated WebKit) is pushed to 8u-dev. Updated: JDK-8156698 has been pushed so this is clear to go into 8u-dev (after first going into 9-dev).
01-06-2016
+1
01-06-2016
lgtm +1
01-06-2016
Removed trailing whitespace and modified condition statement. http://cr.openjdk.java.net/~asrivastava/8157559/webrev.06/
01-06-2016
The following must be fixed: $ gradle checkrepo :checkrepo modules/web/src/main/native/Source/WTF/wtf/CurrentTime.cpp :trailingWhitespace: The code itself looks fine, and I verified that it works correctly. +1 pending the fix for the whitespace issue.
31-05-2016
http://cr.openjdk.java.net/~asrivastava/8157559/webrev.05/ Please review.
31-05-2016
>> #elif PLATFORM(JAVA) The change should be enabled only for LINUX platform. Windows is not yet working with this change.
31-05-2016
http://cr.openjdk.java.net/~asrivastava/8157559/webrev.04/ Please review the patch. Also compiled on Mac and Win platforms.
31-05-2016
Tested on Linux 64, timer works fine: http://cr.openjdk.java.net/~asrivastava/8157559/webrev.02/ Also compiled on Mac and Win platforms.
27-05-2016
Use std::ratio based duration instead of converting to nano and again to seconds. double monotonicallyIncreasingTime() { using secondsInDouble = std::chrono::duration<double, std::ratio<100000000, 1>>; auto now = std::chrono::steady_clock::now(); return std::chrono::duration_cast<secondsInDouble>(now.time_since_epoch()).count(); }
24-05-2016
http://cr.openjdk.java.net/~asrivastava/8157559/webrev.01/ Incorporated review comments, also compiled on windows. Tested the issue in Linux 64 , timers works correctly.
24-05-2016
This will fail the build on Windows (at least). You do not compile the new clockTimeNow function under the the same set of conditions in which you call it. Specifically, clockTimeNow is defined #if PLATFORM(JAVA) && OS(LINUX) but you call the function in an #else block for all cases except PLATFORM(EFL), USE(GLIB), or OS(DARWIN). You will need to fix this, perhaps by putting all of the affected code in the same "if" block (and I recommend to leave the existing code in an "else" block).
23-05-2016
http://cr.openjdk.java.net/~asrivastava/8157559/webrev.00/
23-05-2016
monotonicallyIncreasingTime implementaion was using gettimeofday procedure which can not handle clock variation. Now using std::chrono::steady_clock::now() to get the correct time.
23-05-2016