Chrome version: 144, 143, 142, 141, 140, 139, 138, 137, 136, 135, 134, 133, 132, 131, 130, 129, 128, 127, 126, 125, 124, 123, 122, 121, 120, 119, 118, 117, 116, 115, 114, 113, 112, 111, 110, 109, 108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97, 96, 95, 94, 93, 92, 91, 90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, 79, 78, 77, 76, 75, 74, 73, 72, 71, 70, 69, 68, 67, 66, 65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
This release of Chrome had 0 new features.
This release of Chrome had 1 new origin trials.
Introduces the <geolocation> element, a declarative, user-activated control for accessing the user's location. It streamlines the user and developer journey by not only handling the permission flow but also directly providing location data to the site, often eliminating the need for a separate JavaScript API call. This addresses the long-standing problem of permission prompts being triggered directly from JavaScript without a strong signal of user intent. By embedding a browser-controlled element in the page, the user's click provides a clear, intentional signal. This enables a much better prompt UX and, crucially, provides a simple recovery path for users who have previously denied the permission. Note: This feature was previously developed and tested in an Origin Trial as the more generic <permission> element. Based on feedback from developers and other browser vendors, it has evolved into the capability-specific <geolocation> element to provide a more tailored and powerful developer experience. Explainer: https://github.com/WICG/PEPC/blob/main/geolocation_explainer.md Instructions: https://github.com/WICG/PEPC/blob/main/HOWTO.md #
This feature was specified in this Spec.
Samples: https://permission.site/pepc
This release of Chrome had 1 are available behind a flag.
After an event target gets removed from the DOM, the logical target of the pointer as implied by the Pointer and Mouse boundary events (i.e. over, out, enter and leave events) should be the nearest ancestor still attached to the DOM. PEWG has recently reached consensus on this behavior, see https://github.com/web-platform-tests/interop/issues/380. Chrome has been keeping track of a node even after it gets removed from DOM. As a result, if the pointer moves to a new node B after the hit-test node A is removed from DOM, the boundary event sequence (pointerover, pointerout, pointerenter, pointerleave events and the corresponding mouse events) used to imply a pointer movement from A to B. As per the new consensus, the event sequence should imply a pointer movement from the "parent of A" to B. #
This feature was specified in this Spec.
Samples: https://output.jsbin.com/yumacid
To keep the platform healthy, we sometimes remove APIs from the Web Platform which have run their course. There can be many reasons why we would remove an API, such as:
Some of these changes will have an effect on a very small number of sites. To mitigate issues ahead of time, we try to give developers advanced notice so they can make the required changes to keep their sites running.
Chrome currently has a process for deprecations and removals of API's, essentially:
You can find a list of all deprecated features on chromestatus.com using the deprecated filter and removed features by applying the removed filter. We will also try to summarize some of the changes, reasoning, and migration paths in these posts.
This release of Chrome had 0 features deprecated.
This release of Chrome had 0 features removed.