Bug 22328 - Worker object should implement WindowTimers interface as per HTML5 spec
Summary: Worker object should implement WindowTimers interface as per HTML5 spec
Status: RESOLVED DUPLICATE of bug 22718
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2008-11-17 21:43 PST by Dmitry Titov
Modified: 2008-12-08 00:49 PST (History)
1 user (show)

See Also:

Initial Refactoring of code (49.45 KB, patch)
2008-11-20 01:31 PST, Dmitry Titov
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Titov 2008-11-17 21:43:20 PST
Workers should get setTimeout/clearTimeout/setInterval/clearInterval implemented on them. working on a patch.
Comment 1 Dmitry Titov 2008-11-20 01:31:32 PST
Created attachment 25304 [details]
Initial Refactoring of code
Comment 2 Dmitry Titov 2008-11-20 01:34:07 PST
Refactored timeout code (set/clearTimeout,set/clearInterval) in preparation for implementing them on Workers.
Most of implementation moved from JSDOMWindowBase to ScriptExecutionContext, including the storage for timers.
Timers are now instances of new class DOMTimer. 
ScriptExecutionContext has a virtual method 'executeTimoutCallback' which is called when a timer fires. Subclasses of SEC (Document and WorkerContext) implement this differently. For now, only Document has implementation - depending on whether a callback is a JS function or a string of JS code, it either delegates back to JSDOMGlobalObject that captured the function and arguments, or asks FrameLoader to execute the script.
ScheduledAction is now just a collection of data for timer callback.

Comment 3 Alexey Proskuryakov 2008-11-20 03:34:39 PST
Comment on attachment 25304 [details]
Initial Refactoring of code

Aside from code style issues, I have two comments. First, DOMTimer inherits from TimerBase, which is not thread safe, and doesn't work in non-main threads anyway (on Mac OS X, it uses CFRunLoopTimerCreate on main run loop). Second, clearAllTimeouts and related functions need to be modified to take advantage of DOMTimer being an ActiveDOMObject. Pausing and resuming timers will probably require support for pausing/resuming active DOM objects, which is needed anyway.

You may want to discuss this with someone who actually knows how timers used to work though!
Comment 4 Dmitry Titov 2008-12-08 00:49:27 PST

*** This bug has been marked as a duplicate of 22718 ***