recursal/MDN huggingface dataset:
ServiceWorkerGlobalScope: registration property
===============================================

The **`registration`** read-only property of the `ServiceWorkerGlobalScope` interface returns a reference to the `ServiceWorkerRegistration` object, which represents the service worker's registration.

Value
-----

A `ServiceWorkerRegistration` object.

Specifications
--------------

| Specification |
| --- |
| Service Workers # service-worker-global-scope-registration |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Using Service Workers
* Service workers basic code example
* Using web workers
ServiceWorkerGlobalScope: push event
====================================

The **`push`** event is sent to a service worker's global scope (represented by the `ServiceWorkerGlobalScope` interface) when the service worker has received a push message.

This event is not cancelable and does not bubble.

Syntax
------

Use the event name in methods like `addEventListener()`, or set an event handler property.


```js
addEventListener("push", (event) => {});

onpush = (event) => {};
```

Event type
----------

A `PushEvent`. Inherits from `Event`.

Event

ExtendableEvent

PushEventEvent properties
----------------

*Inherits properties from its parent, `ExtendableEvent`. Additional properties:*

`PushEvent.data` Read only 

Returns a reference to a `PushMessageData` object containing data sent to the `PushSubscription`.

Example
-------

This example sets up a handler for `push` events that takes JSON data, parses it, and dispatches the message for handling based on information contained within the message.


```js
self.addEventListener(
  "push",
  (event) => {
    let message = event.data.json();

    switch (message.type) {
      case "init":
        doInit();
        break;
      case "shutdown":
        doShutdown();
        break;
    }
  },
  false,
);
```

Specifications
--------------

| Specification |
| --- |
| Push API # extensions-to-the-serviceworkerglobalscope-interface |
| Push API # dom-serviceworkerglobalscope-onpush |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Using the Push API
* `pushsubscriptionchange` event
ServiceWorkerGlobalScope: sync event
====================================

The **`sync`** event of the `ServiceWorkerGlobalScope` interface is fired when the page (or worker) that registered the event with the `SyncManager` is running and as soon as network connectivity is available.

This event is not cancelable and does not bubble.

Syntax
------

Use the event name in methods like `addEventListener()`, or set an event handler property.


```js
addEventListener("sync", (event) => {});

onsync = (event) => {};
```

Event type
----------

A `SyncEvent`. Inherits from `ExtendableEvent` and `Event`.

Event

ExtendableEvent

SyncEventEvent properties
----------------

*Inherits properties from its ancestor, `ExtendableEvent` and `Event`*.

`SyncEvent.tag` Read only 

Returns the developer-defined identifier for this `SyncEvent`.

`SyncEvent.lastChance` Read only 

Returns `true` if the user agent will not make further synchronization attempts after the current attempt.

Examples
--------

The following example shows how to respond to a sync event in the service worker.


```js
self.addEventListener("sync", (event) => {
  if (event.tag === "sync-messages") {
    event.waitUntil(sendOutboxMessages());
  }
});
```


You can also set up the event handler using the `onsync` property:


```js
self.onsync = (event) => {
  // ...
};
```

Specifications
--------------

| Specification |
| --- |
| Web Background Synchronization # dom-serviceworkerglobalscope-onsync |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Richer offline experiences with the Periodic Background Sync API
* A Periodic Background Sync demo app
ServiceWorkerGlobalScope: skipWaiting() method
==============================================

The **`ServiceWorkerGlobalScope.skipWaiting()`** method of the `ServiceWorkerGlobalScope` forces the waiting service worker to become the active service worker.

Use this method with `Clients.claim()` to ensure that updates to the underlying service worker take effect immediately for both the current client and all other active clients.

Syntax
------


```js
skipWaiting()
```

### Parameters

None.

### Return value

A `Promise` that resolves with `undefined` after trying to activate the newly installed service worker.

Examples
--------

While `self.skipWaiting()` can be called at any point during the service worker's execution, it will only have an effect if there's a newly installed service worker that might otherwise remain in the `waiting` state. Therefore, it's common to call `self.skipWaiting()` from inside of an `InstallEvent` handler.

The following example causes a newly installed service worker to progress into the `activating` state, regardless of whether there is already an active service worker.


```js
self.addEventListener("install", (event) => {
  // The promise that skipWaiting() returns can be safely ignored.
  self.skipWaiting();

  // Perform any other actions required for your
  // service worker to install, potentially inside
  // of event.waitUntil();
});
```

Specifications
--------------

| Specification |
| --- |
| Service Workers # service-worker-global-scope-skipwaiting |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Using Service Workers
* Service workers basic code example
* `Clients.claim()`
* Using web workers
ServiceWorkerGlobalScope: paymentrequest event
==============================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`paymentrequest`** event of the `ServiceWorkerGlobalScope` interface is fired on a payment app when a payment flow has been initiated on the merchant website via the `PaymentRequest.show()` method.

Syntax
------

Use the event name in methods like `addEventListener()`, or set an event handler property.


```js
addEventListener("paymentrequest", (event) => {});

onpaymentrequest = (event) => {};
```

Event type
----------

A `PaymentRequestEvent`. Inherits from `ExtendableEvent`.

Event

ExtendableEvent

PaymentRequestEventExamples
--------

When the `PaymentRequest.show()` method is invoked, a `paymentrequest` event is fired on the service worker of the payment app. This event is listened for inside the payment app's service worker to begin the next stage of the payment process.


```js
let payment_request_event;
let resolver;
let client;

// `self` is the global object in service worker
self.addEventListener("paymentrequest", async (e) => {
  if (payment_request_event) {
    // If there's an ongoing payment transaction, reject it.
    resolver.reject();
  }
  // Preserve the event for future use
  payment_request_event = e;

  // ...
});
```


When a `paymentrequest` event is received, the payment app can open a payment handler window by calling `PaymentRequestEvent.openWindow()`. The payment handler window will present the customers with a payment app interface where they can authenticate, choose shipping address and options, and authorize the payment.

When the payment has been handled, `PaymentRequestEvent.respondWith()` is used to pass the payment result back to the merchant website.

See Receive a payment request event from the merchant for more details of this stage.

Specifications
--------------

| Specification |
| --- |
| Payment Handler API # the-paymentrequestevent |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Payment Handler API
* Web-based payment apps overview
* Setting up a payment method
* Life of a payment transaction
* Using the Payment Request API
* Payment processing concepts
ServiceWorkerGlobalScope: backgroundfetchabort event
====================================================

Limited availability
--------------------

This feature is not Baseline because it does not work in some of the most widely-used browsers.

* Learn more
* See full compatibility
* Report feedback
**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`backgroundfetchabort`** event of the `ServiceWorkerGlobalScope` interface is fired when the user or the app itself cancels a background fetch operation.

This event is not cancelable and does not bubble.

Syntax
------

Use the event name in methods like `addEventListener()`, or set an event handler property.


```js
addEventListener("backgroundfetchabort", (event) => {});

onbackgroundfetchabort = (event) => {};
```

Event type
----------

A `BackgroundFetchEvent`.

Event

ExtendableEvent

BackgroundFetchEventEvent properties
----------------

*Inherits properties from its parent, `ExtendableEvent`.*

`BackgroundFetchEvent.registration`

Returns the `BackgroundFetchRegistration` for the aborted fetch.

Description
-----------

In the background fetch API, the browser shows a UI element to the user to indicate the progress of the operation. This element also enables the user to cancel the fetch. The app itself can also cancel the fetch by calling `BackgroundFetchRegistration.abort()`.

If the fetch is canceled, the browser aborts the fetch, starts the service worker, if necessary, and fires the `backgroundfetchabort` event in the service worker's global scope.

In the handler for this event, the service worker can clean up any related data for the operation. It can also retrieve and store any successful responses (for example, using the `Cache` API). To access the response data, the service worker uses the event's `registration` property.

Examples
--------

### Cleaning up

This event handler might perform any cleanup of data associated with the aborted fetch.


```js
addEventListener("backgroundfetchabort", (event) => {
  // clean up any related data
});
```

Specifications
--------------

| Specification |
| --- |
| Background Fetch # dom-serviceworkerglobalscope-onbackgroundfetchabort |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Background Fetch API
GPUDevice: limits property
==========================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The **`limits`** read-only property of the
 `GPUDevice` interface returns a `GPUSupportedLimits` object that describes the limits supported by the device. All limit values will be included, and the limits requested during the creation of the device (i.e. when `GPUAdapter.requestDevice()` is called) will be reflected in those values.

**Note:** Not all limits will be reported as expected, even if they are supported by the underlying hardware. See `GPUAdapter.limits` for more details.

Value
-----

A `GPUSupportedLimits` object instance.

Examples
--------

In the following code we query the `GPUAdapter.limits` value of `maxBindGroups` to see if it is equal to or greater than 6. Our theoretical example app ideally needs 6 bind groups, so if the returned value is >= 6, we add a maximum limit of 6 to the `requiredLimits` object.

We then check that the expected limit has been set on the resulting device by logging its value to the console.


```js
async function init() {
  if (!navigator.gpu) {
    throw Error("WebGPU not supported.");
  }

  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) {
    throw Error("Couldn't request WebGPU adapter.");
  }

  const requiredLimits = {};

  // App ideally needs 6 bind groups, so we'll try to request what the app needs
  if (adapter.limits.maxBindGroups >= 6) {
    requiredLimits.maxBindGroups = 6;
  }

  const device = await adapter.requestDevice({
    requiredLimits,
  });

  console.log(device.limits.maxBindGroups);

  // ...
}
```

Specifications
--------------

| Specification |
| --- |
| WebGPU # dom-gpudevice-limits |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* The WebGPU API
GPUDevice: createQuerySet() method
==================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The **`createQuerySet()`** method of the
 `GPUDevice` interface creates a `GPUQuerySet` that can be used to record the results of queries on passes, such as occlusion or timestamp queries.

Syntax
------


```js
createQuerySet(descriptor)
```

### Parameters

`descriptor`

An object containing the following properties:

`count`

A number specifying the number of queries to be managed by the resulting `GPUQuerySet`.

`label` Optional

A string providing a label that can be used to identify the object, for example in `GPUError` messages or console warnings.

`type`

An enumerated value specifying the type of queries to be managed by the resulting `GPUQuerySet`. Possible values are:

`"occlusion"`

Occlusion queries are available on render passes to query the number of fragment samples that pass all the per-fragment tests for a set of drawing commands (including scissor, sample mask, alpha to coverage, stencil, and depth tests). To run an occlusion query, an appropriate `GPUQuerySet` must be provided as the value of the `occlusionQuerySet` descriptor property when invoking `GPUCommandEncoder.beginRenderPass()` to run a render pass.

`"timestamp"`

Timestamp queries allow applications to write timestamps to a `GPUQuerySet`. To run a timestamp query, appropriate `GPUQuerySet`s must be provided inside the value of the `timestampWrites` descriptor property when invoking `GPUCommandEncoder.beginRenderPass()` to run a render pass, or `GPUCommandEncoder.beginComputePass()` to run a compute pass. Alternatively, you can run a single timestamp query at any time by invoking `GPUCommandEncoder.writeTimeStamp()` with an appropriate `GPUQuerySet` as a parameter.

To use timestamp queries, the `timestamp-query` feature must be enabled in the `GPUDevice`.


### Return value

A `GPUQuerySet` object instance.

### Validation

The following criteria must be met when calling **`createQuerySet()`**, otherwise a `GPUValidationError` is generated and an invalid `GPUQuerySet` object is returned:

* `count` is less than or equal to 4096.
Examples
--------

The following snippet creates a `GPUQuerySet` that holds 32 occlusion query results:


```js
const querySet = device.createQuerySet({
  type: "occlusion",
  count: 32,
});
```

Specifications
--------------

| Specification |
| --- |
| WebGPU # dom-gpudevice-createqueryset |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* The WebGPU API
GPUDevice: popErrorScope() method
=================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The **`popErrorScope()`** method of the
 `GPUDevice` interface pops an existing GPU error scope from the error scope stack (originally pushed using `GPUDevice.pushErrorScope()`) and returns a `Promise` that resolves to an object describing the first error captured in the scope, or `null` if no error occurred.

Syntax
------


```js
popErrorScope()
```

### Parameters

None.

### Return value

a `Promise` that resolves to an object describing the first error captured in the scope. This can be of type:

* `GPUInternalError`
* `GPUOutOfMemoryError`
* `GPUValidationError`

If no error occurred, it resolves to `null`.

Examples
--------

The following example uses an error scope to capture a suspected validation error, logging it to the console.


```js
device.pushErrorScope("validation");

let sampler = device.createSampler({
  maxAnisotropy: 0, // Invalid, maxAnisotropy must be at least 1.
});

device.popErrorScope().then((error) => {
  if (error) {
    sampler = null;
    console.error(`An error occurred while creating sampler: ${error.message}`);
  }
});
```


See WebGPU Error Handling best practices for a lot more examples and information.

Specifications
--------------

| Specification |
| --- |
| WebGPU # dom-gpudevice-poperrorscope |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* The WebGPU API
GPUDevice: features property
============================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The **`features`** read-only property of the
 `GPUDevice` interface returns a `GPUSupportedFeatures` object that describes additional functionality supported by the device. Only features requested during the creation of the device (i.e. when `GPUAdapter.requestDevice()` is called) are included.

**Note:** Not all features will be available to WebGPU in all browsers that support it, even if the features are supported by the underlying hardware. See `GPUAdapter.features` for more details.

Value
-----

A `GPUSupportedFeatures` object instance. This is a setlike object.

Examples
--------

In the following code we check whether a `GPUAdapter` has the `texture-compression-astc` feature available. If so, we push it into the array of `requiredFeatures`, and request a device with that feature requirement using `GPUAdapter.requestDevice()`.

We then log all items in the `GPUDevice.features` set to the console. This set should only contain a single item — `texture-compression-astc` — as that was the only feature requested when the device was created.


```js
async function init() {
  if (!navigator.gpu) {
    throw Error("WebGPU not supported.");
  }

  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) {
    throw Error("Couldn't request WebGPU adapter.");
  }

  const requiredFeatures = [];

  if (adapter.features.has("texture-compression-astc")) {
    requiredFeatures.push("texture-compression-astc");
  }

  const device = await adapter.requestDevice({
    requiredFeatures,
  });

  device.features.forEach((value) => {
    console.log(value);
  });

  // ...
}
```

Specifications
--------------

| Specification |
| --- |
| WebGPU # dom-gpudevice-features |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* The WebGPU API
GPUDevice: lost property
========================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The **`lost`** read-only property of the
 `GPUDevice` interface contains a `Promise` that remains pending throughout the device's lifetime and resolves with a `GPUDeviceLostInfo` object when the device is lost.

`GPUAdapter.requestDevice()` will never return `null`, and it will reject only if the request is invalid, i.e. it exceeds the capabilities of the `GPUAdapter`. If a valid device request can't be fulfilled for some reason however it may resolve to a device that has already been lost. Additionally, devices can be lost at any time after creation for a variety of reasons (such as browser resource management or driver updates), so it's a good idea to always handle lost devices gracefully.

Many causes for lost devices are transient, so you should try getting a new device once a previous one has been lost unless the loss was caused by the application intentionally destroying the device (i.e. with `GPUDevice.destroy()`). Note that any WebGPU resources created with a previous device (buffers, textures, etc.) will need to be re-created with the new one.

**Note:** Also bear in mind that a `GPUAdapter` may become unavailable, e.g. if the physical GPU is unplugged from the system or disabled to save power. From then on, the adapter can no longer return valid devices, and will always return already-lost devices.

Value
-----

A promise that resolves with a `GPUDeviceLostInfo` object when the device is lost.

Examples
--------


```js
async function init() {
  if (!navigator.gpu) {
    throw Error("WebGPU not supported.");
  }

  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) {
    throw Error("Couldn't request WebGPU adapter.");
  }

  // Create a GPUDevice
  let device = await adapter.requestDevice(descriptor);

  // Use lost to handle lost devices
  device.lost.then((info) => {
    console.error(`WebGPU device was lost: ${info.message}`);
    device = null;

    if (info.reason !== "destroyed") {
      init();
    }
  });

  // ...
}
```

Specifications
--------------

| Specification |
| --- |
| WebGPU # dom-gpudevice-lost |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* The WebGPU API
GPUDevice: queue property
=========================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The **`queue`** read-only property of the
 `GPUDevice` interface returns the primary `GPUQueue` for the device.

Value
-----

A `GPUQueue` object instance.

Examples
--------

Basic `GPUQueue` access:


```js
async function init() {
  if (!navigator.gpu) {
    throw Error("WebGPU not supported.");
  }

  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) {
    throw Error("Couldn't request WebGPU adapter.");
  }

  // Create a GPUDevice
  const device = await adapter.requestDevice();

  // ...

  // Common queue use — end current frame by passing array of
  // command buffers to queue for execution
  device.queue.submit([commandEncoder.finish()]);

  // ...
}
```


**Note:** For more queue examples, see the `GPUQueue` reference pages.

Specifications
--------------

| Specification |
| --- |
| WebGPU # dom-gpudevice-queue |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* The WebGPU API
GPUDevice: uncapturederror event
================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`uncapturederror`** event of the `GPUDevice` interface is fired when an error is thrown that has not been observed by a GPU error scope, to provide a way to report unexpected errors.

Known error cases should be handled using `pushErrorScope()` and `popErrorScope()`.

Syntax
------

Use the event name in methods like `addEventListener()`, or set an event handler property.


```js
addEventListener("uncapturederror", (event) => {});

onuncapturederror = (event) => {};
```

Event type
----------

An `GPUUncapturedErrorEvent`. Inherits from `Event`.

Event

GPUUncapturedErrorEventExamples
--------

You could use something like the following as a global mechanism to pick up any errors that aren't handled by error scopes and capture them.


```js
device.addEventListener("uncapturederror", (event) => {
  // Re-surface the error.
  console.error("A WebGPU error was not captured:", event.error);

  reportErrorToServer({
    type: event.error.constructor.name,
    message: event.error.message,
  });
});
```


See WebGPU Error Handling best practices for more examples and information.

Specifications
--------------

| Specification |
| --- |
| WebGPU # dom-gpudevice-onuncapturederror |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* The WebGPU API