Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 154060 Pepper Flash not setting local timezone in new Date object
Starred by 29 users Reported by dangwyn...@gmail.com, Oct 4 2012 Back to list
Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Oct 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug



Sign in to add a comment
Steps to reproduce the problem:
We have had customers reporting that since the release of Pepper Flash 11.3.31.331 they have seen timers on our site periodically jump forwards by 1 hour. We have a sports betting site and on busy days we can display over 100 sporting events at once, each one of those events has its own game timer. We have observed that when a large number of Date objects are created at the same time Pepper Flash sometimes sets the time zone in a new Date object to +0000 instead of the users local time zone (+0100 for our UK users). Once the time zone is incorrect it stays like that for 10 second then reverts back to the correct local time zone.

I’ve put together a demo to show this happening, here are the steps to reproduce:
•	Open up six new Chrome browser instances with Pepper Flash enabled
•	Go to this address in each browser instance: http://81.94.219.38/ChromeDateTest
•	Leave these instances running for 10-20 minutes and you’ll start seeing log entries showing the time zone changing

You can see the source for the demo swf here: http://81.94.219.38/ChromeDateTest/ChromeDateTest.txt

What is the expected behavior?
Creating a new Date object should always set the time zone to the clients local time zone.

What went wrong?
Pepper Flash Player intermittently sets the time zone in a Date object to +0000

Did this work before? Yes 25/09/12

Chrome version: 22.0.1229.79
OS Version: 5.1 (Windows XP)

UserAgent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
 
pepper-flash-date.jpg
317 KB View Download
Cc: brettw@chromium.org
Labels: Feature-Flash
Status: Untriaged
Labels: Feature-Plugins-Pepper
Hi, please note that this is currently affecting an commercial website that as just over 4 million customers. We currently have a workaround for this, but with so many customers there are scenarios where the workaround is still not addressing the root cause. The website relies upon very accurate and timely information being displayed on screen in real time. This bug is causing us to mislead our customers with regards the information that is presented to them.
Comment 4 Deleted
Comment 5 by rtche...@gmail.com, Oct 10 2012
I am experiencing this issue as well on Windows 7 w/ Chrome 22.0.1229.92 and Flash version 11.4.31.110.  I have seen dates/times change by 1 hour as well.  The timezone bounces between -0400 and -0500.  Could this be related to daylight savings time?
Hi, we are publishing a commercial FLEX calendar component (KCCalendar) and more and more customers report us weird issues with events “jumping” from 1 hour, day shifts (occurs on dates after the DST change date: 28/10) and other chaotic displays…
We have hundreds of customers, meaning thousands of users. This bug is really critical.

Hi.I.was...@gmail.com, you say having a workaround, can you please share it? I think it will be useful for other users running into this issue. Thanks in advance!

I put a sample application at http://www.flex-component.com/demo/chrome_issue_154060/

The application display 3 events respectively on 1/11/12, 2/11/12 and 3/11/12 (european format), starting at 12:00 and ending at 14:00. It logs every (last 200) generated date timezoneOffset property in the bottom text area.
To reproduce the issue you have to navigate to the 29/10 - 04/11 week and start moving the mouse over cells and items. If it doesn't work you can switch to month view and come back to week view and move the mouse on each view.

In France we start with -120 timezoneOffset but after a while it becomes -60 and if you go back in time it could be -120 again. You may also see events hours changing from 12-14 to 11-13.

Hope it will help for your tests and fix.

We tried two workarounds, first we tried getting the timezone offset from a javascript Date object using ExternalInterface. We could then compare the javascript offset with the flash offset and adjust the time in the flash Date object if the timezones where not the same. This did reduce the amount of occurrences of the issue but we found the javascript Date object to be unresponsive to timezone changes on your local machine. 

Our second solution which we are currently using is to create a Date object at the start of the application and store it's offset in a variable. Each time we create a new date object we check the offset against the stored offset and adjust the time if the offset has changed.

The second solution works well for us because we are using the Date object for countdown timers which don't need to be timezone aware, I'm not sure if this solution could be applied to your calendar application as I assume you'd want your application to be timezone aware.
Thanks a lot for your comments! As in our component, dates are almost everywhere (and as Date is final and can't be overriden) it will require to completely rework the component and you're right concerning the timezone awareness, hard to know the side-effects of such kind a solution in our case...
Is there any update on this? We've received issue reports from users of 2 different Flex applications that both suffer from this issue.

Since this really is a major issue, we're advising users to NOT use Chrome for now. I know this sounds drastic, but most of our users are not computer savvy enough to install the Adobe Flash Player and to disable the Pepper version.

Please consider this a high priority issue.
Labels: -Area-UI -Pri-2 -OS-Windows Area-Internals Pri-1 OS-All
Owner: viettrungluu@chromium.org
Status: Assigned
Status: Started
I'm pretty sure it's a regression due to http://src.chromium.org/viewvc/chrome?view=rev&revision=155374 (I blame the reviewer of the change).
Project Member Comment 13 by bugdroid1@chromium.org, Oct 18 2012
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=162605

------------------------------------------------------------------------
r162605 | viettrungluu@chromium.org | 2012-10-18T01:45:58.797599Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/proxy/ppb_flash_proxy.cc?r1=162605&r2=162604&pathrev=162605

Make PPB_Flash_Proxy::GetLocalTimeZoneOffset()'s cache aware of the input time.

BUG= http://crbug.com/154060  (maybe also  http://crbug.com/146918 )


Review URL: https://chromiumcodereview.appspot.com/11211003
------------------------------------------------------------------------
If the performance issue described in ticket 145854 is only the case on WinXP, can't the caching take place then only in that specific case?
Cc: kareng@google.com
Labels: Mstone-23 Merge-Requested
Status: Fixed
@kareng@: This bug is pretty serious, and the fix should pretty safe. Hold the merge request till it's been on Canary though.
Cc: josewong...@gmail.com nhu...@adobe.com anthony....@adobe.com viettrungluu@chromium.org jeffreyc@chromium.org jsc...@chromium.org
 Issue 146918  has been merged into this issue.
Comment 17 by kareng@google.com, Oct 18 2012
ok let me know when it's on canary and we'll merge it.
Comment 18 by kareng@google.com, Oct 22 2012
Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved Merge-Merged
Project Member Comment 20 by bugdroid1@chromium.org, Oct 22 2012
Labels: merge-merged-1271
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=163440

------------------------------------------------------------------------
r163440 | viettrungluu@chromium.org | 2012-10-22T23:38:46.862217Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1271/src/ppapi/proxy/ppb_flash_proxy.cc?r1=163440&r2=163439&pathrev=163440

Merge 162605 to 1271 (M23) - Make PPB_Flash_Proxy::GetLocalTimeZoneOffset()'s cache aware of the input time.

BUG= http://crbug.com/154060  (maybe also  http://crbug.com/146918 )


Review URL: https://chromiumcodereview.appspot.com/11211003

TBR=viettrungluu@chromium.org
Review URL: https://codereview.chromium.org/11230046
------------------------------------------------------------------------
 Issue 146918  has been merged into this issue.
 Issue 146918  has been merged into this issue.
Project Member Comment 23 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Feature-Flash -Feature-Plugins-Pepper -Mstone-23 Cr-Content-Plugins-Flash Cr-Internals M-23 Cr-Content-Plugins-Pepper
Project Member Comment 24 by bugdroid1@chromium.org, Apr 5 2013
Labels: Cr-Blink
Project Member Comment 25 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content-Plugins-Flash Cr-Internals-Plugins-Flash
Project Member Comment 26 by bugdroid1@chromium.org, Apr 6 2013
Labels: Cr-Internals-Plugins
Project Member Comment 27 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content-Plugins-Pepper Cr-Internals-Plugins-Pepper
Comment 28 by laforge@google.com, Jul 24 2013
Cc: -jeffreyc@chromium.org
Sign in to add a comment