Represents the global scope of the worker.
Inheritance HierarchyThe WorkerGlobalScope does not inherit from any class or interface.
The WorkerGlobalScope object has these types of members:
The WorkerGlobalScope object has these events.
Returns an error if a worker throws an unhandled exception.
Returns a message from the parent thread to the worker thread, or between two MessagePort objects.
The WorkerGlobalScope object has these methods.
Registers an event handler for the specified event type.
Stops a worker when called inside worker code.
Sends an event to the current element.
Loads and executes one or more scripts into the worker specified by a URL.
Writes a profiling event.
Sends a message from the worker to the parent thread.
Removes an event handler that the addEventListener method registered.
The WorkerGlobalScope object has these properties.
Returns the windows console object to use to send messages.
Allows access to the Indexed Database API, as implemented by Internet Explorer 10.
Returns the WorkerLocation object of a worker.
Returns a WorkerNavigator object.
Contains a reference to the WorkerGlobalScope object.
The WorkerGlobalScope object is accessed by using the self or this property and is accessed only inside a worker. A worker has the following functionality within its scope:
- It can use the XMLHttpRequest method.
- It has a self property, which contains a reference to the worker object.
- It has a navigator object, which provides the appName, appVersion, onLine, userAgent, and platform properties but no others.
- The location property creates the WorkerLocation object, which contains URL information on the worker's location. This property is similar to the Window.location property, but is read-only.
- It supports the worker versions of the setTimeout, setInterval, clearTimeout, and clearInterval methods, which are similar to the methods of the same name for the Window object.
Workers do not have access to the Document Object Model (DOM), nor the window, document, and parent objects.
You can create new child workers from inside a worker. They must all run in the same host and their location depends on the parent worker of the new worker, not the original webpage. Because a new worker is likely to be in a separate process, you shouldn't create too many workers at once. Also, because messages between workers and their parents are copies and not shared, too many workers can use up resources quickly.