[webkit-changes] [WebKit/WebKit] 60635d: Versioning.
Chirag Shah
noreply at github.com
Fri Feb 17 07:36:42 PST 2023
Branch: refs/heads/safari-7615-branch
Home: https://github.com/WebKit/WebKit
Commit: 60635d719037e2e723734d9c86c6c91806d4a28f
https://github.com/WebKit/WebKit/commit/60635d719037e2e723734d9c86c6c91806d4a28f
Author: Alan Coon <alancoon at apple.com>
Date: 2023-01-30 (Mon, 30 Jan 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.1.19
Canonical link: https://commits.webkit.org/259548.1@safari-7615-branch
Commit: b82676592fa369882f94330e8ab345956415f771
https://github.com/WebKit/WebKit/commit/b82676592fa369882f94330e8ab345956415f771
Author: Brent Fulgham <bfulgham at apple.com>
Date: 2023-01-30 (Mon, 30 Jan 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
Log Message:
-----------
Cherry-pick c4d95cca9a1f. rdar://problem/104830750
Revert `FullScreenEnabled` feature flag from `internal` back to `embedder`
https://bugs.webkit.org/show_bug.cgi?id=251390
<rdar://104830750>
Reviewed by Tim Nguyen.
The `FullScreenEnabled` preference is not meant to be an internal debugging
toggle, so should be labeled as `embedder`.
This patch is a partial revert of 259054 at main.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Canonical link: https://commits.webkit.org/259586@main
Canonical link: https://commits.webkit.org/259548.2@safari-7615-branch
Commit: e8f7233310fd9bcb67c6fdc4387363dea01ee243
https://github.com/WebKit/WebKit/commit/e8f7233310fd9bcb67c6fdc4387363dea01ee243
Author: David Li <jingye_li at apple.com>
Date: 2023-01-30 (Mon, 30 Jan 2023)
Changed paths:
A LayoutTests/animations/animation-set-effect-expected.txt
A LayoutTests/animations/animation-set-effect.html
M Source/WebCore/animation/CSSAnimation.cpp
Log Message:
-----------
Cherry-pick 252432.1013 at safari-7614-branch (1d545c7ebfef). rdar://104831379
[Web Animations] CSSAnimation::setBindingsEffect should also add KeyFrames to overriddenProperties
rdar://102137788
Reviewed by Jonathan Bedard and Antoine Quint.
* LayoutTests/animations/animation-set-effect-expected.txt: Added.
* LayoutTests/animations/animation-set-effect.html: Added.
* Source/WebCore/animation/CSSAnimation.cpp:
(WebCore::CSSAnimation::setBindingsEffect):
Canonical link: https://commits.webkit.org/252432.1013@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.3@safari-7615-branch
Commit: 9fa8efe1b2e2564a89db574400a0c9c25beb0a73
https://github.com/WebKit/WebKit/commit/9fa8efe1b2e2564a89db574400a0c9c25beb0a73
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
M LayoutTests/platform/ios/TestExpectations
M Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp
Log Message:
-----------
Cherry-pick 4590ce7d98b4. rdar://problem/104498135
REGRESSION (256863 at main): [ iOS ] imported/w3c/web-platform-tests/webstorage/storage_local_window_open.window.html is a consistent timeout
https://bugs.webkit.org/show_bug.cgi?id=250922
rdar://104498135
Reviewed by Chris Dumez.
Currently quota check of LocalStorage is performed in both web process (StorageAreaMap) and network process
(SQLiteStorageArea). Web process only sends a setting item request to network process when the local quota check passes.
The issue they calculate usage differently: web process calculates usage based on size of string (WebCore::StorageMap)
and network process uses database file size. Also network process stores upconverted characters in database
(SQLiteStorageArea stores value as blob and SQLiteStatement::bindBlob upconverts characters). The result is web process
may send more requests to network process than it is supposed to.
For example, in the failing test, web process can send about 5000 setItem requests to network process, and network
process will start return error after finishing about 2500 requests. Since 256863 at main, network process will include all
stored items in the request reply when a request fails, so that web process can sync its local cache and two processes
have a consistent view of data. The reason the test starts to fail is reading all items takes time, and there are too
many failed requests.
To fix this issue, this patch increases database size limit to 10MB (double of quota), which should make quota check
results in different processes to be more closer.
* LayoutTests/platform/ios/TestExpectations:
* Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp:
(WebKit::SQLiteStorageArea::prepareDatabase):
Canonical link: https://commits.webkit.org/259571@main
Canonical link: https://commits.webkit.org/259548.5@safari-7615-branch
Commit: a70b0bbd3039ee0cc265602b006c770afb40f22f
https://github.com/WebKit/WebKit/commit/a70b0bbd3039ee0cc265602b006c770afb40f22f
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
M Source/WebCore/platform/mac/DataDetectorHighlight.mm
Log Message:
-----------
Cherry-pick 312ff43f570c. rdar://problem/104723803
Fix a rare crash under data detector highlight painting logic
https://bugs.webkit.org/show_bug.cgi?id=251384
rdar://104723803
Reviewed by Megan Gardner.
Add a null check for the `DDHighlightRef` before attempting to ask for `DDHighlightGetBoundingRect`.
It's not clear how to trigger this crash, so this patch only makes this painting codepath robust
against `m_highlight` being `nil`.
* Source/WebCore/platform/mac/DataDetectorHighlight.mm:
(WebCore::DataDetectorHighlight::paintContents):
Canonical link: https://commits.webkit.org/259599@main
Canonical link: https://commits.webkit.org/259548.6@safari-7615-branch
Commit: 1b17df7c206361fffed2586dc250a1f091af5498
https://github.com/WebKit/WebKit/commit/1b17df7c206361fffed2586dc250a1f091af5498
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
A LayoutTests/streams/blob-and-then-expected.txt
A LayoutTests/streams/blob-and-then.html
M Source/WebCore/Modules/fetch/FetchBodyConsumer.cpp
M Source/WebCore/Modules/streams/ReadableStreamSink.cpp
Log Message:
-----------
Cherry-pick 252432.1018 at safari-7614-branch (792c09f18dc7). rdar://103649054
Use-after-free in FetchBodyConsumer::resolve
https://bugs.webkit.org/show_bug.cgi?id=249996
rdar://103649054
Reviewed by Jonathan Bedard and Alex Christensen.
Make sure in FetchBodyConsumer that refed promise/source remain protected.
We also revert part of an unnecessary and wrong change from https://trac.webkit.org/changeset/227760.
This makes sure ReadableStreamToSharedBufferSink callback remains valid until completely executed in close case, as was the case in error case.
We use std::exchange instead of move as it is more semantically correct.
Covered by added test.
* LayoutTests/streams/blob-and-then-expected.txt: Added.
* LayoutTests/streams/blob-and-then.html: Added.
* Source/WebCore/Modules/fetch/FetchBodyConsumer.cpp:
(WebCore::FetchBodyConsumer::resolveWithFormData):
(WebCore::FetchBodyConsumer::consumeFormDataAsStream):
(WebCore::FetchBodyConsumer::resolve):
* Source/WebCore/Modules/streams/ReadableStreamSink.cpp:
(WebCore::ReadableStreamToSharedBufferSink::close):
(WebCore::ReadableStreamToSharedBufferSink::error):
Canonical link: https://commits.webkit.org/252432.1018@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.6@safari-7615-branch
Commit: 83422ec49be9a26a887566eb35a449917592fa11
https://github.com/WebKit/WebKit/commit/83422ec49be9a26a887566eb35a449917592fa11
Author: David Li <jingye_li at apple.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
A LayoutTests/editing/async-clipboard/clipboard-clear-expected.txt
A LayoutTests/editing/async-clipboard/clipboard-clear.html
M Source/WebCore/Modules/async-clipboard/ClipboardItemBindingsDataSource.cpp
M Source/WebCore/Modules/async-clipboard/ClipboardItemBindingsDataSource.h
Log Message:
-----------
Cherry-pick 252432.1019 at safari-7614-branch (1988807a5229). rdar://103307563
[Clipboard] Explicitly call completion on clearing ClipboardItemTypeLoader
rdar://103307563
Reviewed by Jonathan Bedard and Wenson Hsieh.
In m_itemTypeLoaders.clear(), ClipboardItemBindingsDataSource::invokeCompletionHandler() is called after all m_itemTypeLoaders released
and traverses the itemTypeLoaders after itemTypeLoaders is clear but before the size is updated, causing nullptr accessment.
So we should explicitly call completion before itemTypeLoader is released.
* LayoutTests/editing/async-clipboard/clipboard-clear-expected.txt: Added.
* LayoutTests/editing/async-clipboard/clipboard-clear.html: Added.
* Source/WebCore/Modules/async-clipboard/ClipboardItemBindingsDataSource.cpp:
(WebCore::ClipboardItemBindingsDataSource::clearItemTypeLoaders):
(WebCore::ClipboardItemBindingsDataSource::collectDataForWriting):
(WebCore::ClipboardItemBindingsDataSource::ClipboardItemTypeLoader::~ClipboardItemTypeLoader):
* Source/WebCore/Modules/async-clipboard/ClipboardItemBindingsDataSource.h:
Canonical link: https://commits.webkit.org/252432.1019@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.7@safari-7615-branch
Commit: 5a0f792b008f1f20f03f3020ab94cc18e04e28f4
https://github.com/WebKit/WebKit/commit/5a0f792b008f1f20f03f3020ab94cc18e04e28f4
Author: JC Alvarado <joncarlo at apple.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
A LayoutTests/fast/backgrounds/background-color-lch-crash-expected.txt
A LayoutTests/fast/backgrounds/background-color-lch-crash.html
M Source/WebCore/platform/graphics/ColorBlending.cpp
Log Message:
-----------
Check color opacity after lossy conversion when blending
https://bugs.webkit.org/show_bug.cgi?id=251158
rdar://104553839
Reviewed by Dean Jackson.
We check opacity to determine if we should forgo blending,
however after performing a lossy conversion we can end
up with alpha values that result in a division by zero.
Add an additional check after conversion to prevent this
case.
* LayoutTests/fast/backgrounds/background-color-lch-crash-expected.txt: Added.
* LayoutTests/fast/backgrounds/background-color-lch-crash.html: Added.
* Source/WebCore/platform/graphics/ColorBlending.cpp:
(WebCore::blendSourceOver):
Canonical link: https://commits.webkit.org/259548.8@safari-7615-branch
Commit: 2ca6487cbce8949e446d98c3070fe8f2379a7d60
https://github.com/WebKit/WebKit/commit/2ca6487cbce8949e446d98c3070fe8f2379a7d60
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
A LayoutTests/fast/css/content/quote-display-contents-crash-expected.txt
A LayoutTests/fast/css/content/quote-display-contents-crash.html
M Source/WebCore/dom/Element.cpp
Log Message:
-----------
Cherry-pick 256843.5 at webkit-2022.12-embargoed (312254f5776d). rdar://102807985
Check displayContentsChanged in destroyRenderTreeIfNeeded
https://bugs.webkit.org/show_bug.cgi?id=248776
rdar://102807985>
Reviewed by Antti Koivisto.
Check displayContentsChanged in destroyRenderTreeIfNeeded since
display: contents may be removed due to focus removal while
removing subtrees but we still need to clean up pseudo elements.
* LayoutTests/fast/css/content/quote-display-contents-crash-expected.txt: Added.
* LayoutTests/fast/css/content/quote-display-contents-crash.html: Added.
* Source/WebCore/dom/ContainerNode.cpp:
(WebCore::destroyRenderTreeIfNeeded):
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::resolveComputedStyle):
Canonical link: https://commits.webkit.org/256843.5@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/259548.9@safari-7615-branch
Commit: d0b789c9fd718e237060c07e85bb8864ee98f97c
https://github.com/WebKit/WebKit/commit/d0b789c9fd718e237060c07e85bb8864ee98f97c
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKitLegacy/mac/WebView/WebJSPDFDoc.mm
Log Message:
-----------
Cherry-pick 252432.1017 at safari-7614-branch (94d37ad7d541). rdar://102740487
WebKit`WebKit::PDFPlugin::jsPDFDocPrint - type confusion
https://bugs.webkit.org/show_bug.cgi?id=249169
rdar://102740487
Reviewed by Tim Horton, Yusuke Suzuki and Jonathan Bedard.
When JavaScript is embedded inside a PDF and it invokes the `print()` function,
the `thisObject` parameter in `PDFPlugin::jsPDFDocPrint` is not guaranteed
to be the proper type. Currently, we errenously assume it always is the proper
type, and cast it to `PDFPlugin *`, which results in an object with garbage values.
This PR protects against this by first checking if the `thisObject` is the correct
JavaScript object type, before trying to cast it.
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::jsPDFDocClass):
(WebKit::PDFPlugin::jsPDFDocPrint):
(WebKit::PDFPlugin::makeJSPDFDoc):
Canonical link: https://commits.webkit.org/252432.1017@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.10@safari-7615-branch
Commit: d98b4a43ecd47e273238216eafa2c5254580acf2
https://github.com/WebKit/WebKit/commit/d98b4a43ecd47e273238216eafa2c5254580acf2
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
M Source/WebKit/GPUProcess/mac/com.apple.WebKit.GPUProcess.sb.in
Log Message:
-----------
Cherry-pick c070affcd03f. rdar://problem/104604967
[macOS] Modify Audio related sandbox rule
https://bugs.webkit.org/show_bug.cgi?id=251163
rdar://104604967
Reviewed by Brent Fulgham.
Modify Audio related sandbox rule in the GPU process on macOS to allow reading subpaths of Audio directory.
* Source/WebKit/GPUProcess/mac/com.apple.WebKit.GPUProcess.sb.in:
Canonical link: https://commits.webkit.org/259643@main
Canonical link: https://commits.webkit.org/259548.12@safari-7615-branch
Commit: 099b24dd9eb3f1a2fb67968629db80e6484ab41d
https://github.com/WebKit/WebKit/commit/099b24dd9eb3f1a2fb67968629db80e6484ab41d
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 252432.1023 at safari-7614-branch (55c2b9caae92). rdar://101222657
[CoreIPC] Integer overflow in UIProcess from scaling/zoom factors
https://bugs.webkit.org/show_bug.cgi?id=250408
rdar://101222657
Reviewed by Wenson Hsieh and Jonathan Bedard.
Adds bounds checking via `MESSAGE_CHECK` to the page/plugin scale/zoom `factorDidChange`
methods in `WebPageProxy` to ensure that overflow will not occur in the web process.
The bounds were chosen to be `(0, 100]` because a factor of `<= 0.0` does not make sense,
and `100.0` ia a reasonable upper bound.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::pageScaleFactorDidChange):
(WebKit::WebPageProxy::pluginScaleFactorDidChange):
(WebKit::WebPageProxy::pluginZoomFactorDidChange):
Canonical link: https://commits.webkit.org/252432.1023@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.12@safari-7615-branch
Commit: f322e936fb840d8242edb89a6bbef6fa0509c44c
https://github.com/WebKit/WebKit/commit/f322e936fb840d8242edb89a6bbef6fa0509c44c
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
M Source/WebCore/Modules/contact-picker/ContactsManager.cpp
M Source/WebCore/Modules/contact-picker/ContactsManager.h
Log Message:
-----------
Cherry-pick 252432.1024 at safari-7614-branch (2ea437d75522). rdar://101241436
Use-after-free in ContactsManager::select
https://bugs.webkit.org/show_bug.cgi?id=250351
rdar://101241436
Reviewed by Wenson Hsieh and Jonathan Bedard.
`ContactsManager` can be destroyed prior to receiving the user's selection, which
is performed asynchronously. Deploy `WeakPtr` to avoid a use-after-free in this
scenario.
A test was unable to be added, as the failure scenario involves opening a new
Window, using the new Window object's `navigator.contacts`, and performing user
interaction. Creating a new Window results in the creation of a new web view,
however all of our existing UIScriptController hooks only apply to the original
(main) web view. Consequently, it is not possible to use our testing
infrastructure to dismiss the contact picker and trigger the callback in the
failure scenario.
* Source/WebCore/Modules/contact-picker/ContactsManager.cpp:
(WebCore::ContactsManager::select):
* Source/WebCore/Modules/contact-picker/ContactsManager.h:
Canonical link: https://commits.webkit.org/252432.1024@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.13@safari-7615-branch
Commit: 7b91f2d38778624f81cd47f7932754a72bfef77c
https://github.com/WebKit/WebKit/commit/7b91f2d38778624f81cd47f7932754a72bfef77c
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
A LayoutTests/editing/editability/design-mode-does-not-inherit-across-frames-expected.txt
A LayoutTests/editing/editability/design-mode-does-not-inherit-across-frames.html
M LayoutTests/fast/dom/HTMLElement/iscontenteditable-designmodeon-allinherit-subframe-expected.txt
M LayoutTests/fast/dom/HTMLElement/iscontenteditable-designmodeon-allinherit-subframe.html
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
Log Message:
-----------
Cherry-pick 252432.1026 at safari-7614-branch (2a8469e53b2f). rdar://102868995
Remove inheritance of designMode attribute
https://bugs.webkit.org/show_bug.cgi?id=248615
rdar://102868995
Reviewed by Wenson Hsieh and Jonathan Bedard.
Stop making design mode inherit across frame boundaries.
This will prevent a form element from being injected into a victim page via drag & drop
and the new behavior matches that of Firefox and Chrome.
* LayoutTests/editing/editability/design-mode-does-not-inherit-across-frames-expected.txt: Added.
* LayoutTests/editing/editability/design-mode-does-not-inherit-across-frames.html: Added.
* LayoutTests/fast/dom/HTMLElement/iscontenteditable-designmodeon-allinherit-subframe-expected.txt:
* LayoutTests/fast/dom/HTMLElement/iscontenteditable-designmodeon-allinherit-subframe.html:
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setDesignMode):
(WebCore::Document::inDesignMode const): Deleted.
* Source/WebCore/dom/Document.h:
(WebCore::Document::inDesignMode const):
Canonical link: https://commits.webkit.org/252432.1026@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.14@safari-7615-branch
Commit: b971159cda2eab32b8eed71a935eee6bf1f80b40
https://github.com/WebKit/WebKit/commit/b971159cda2eab32b8eed71a935eee6bf1f80b40
Author: Yijia Huang <yijia_huang at apple.com>
Date: 2023-01-31 (Tue, 31 Jan 2023)
Changed paths:
A JSTests/wasm/stress/wasm-tuple-return.js
M Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
Log Message:
-----------
Cherry-pick 252432.1029 at safari-7614-branch (9dda7bfe768d). rdar://103551585
LLInt WASM argument locals must be read before return values are written
https://bugs.webkit.org/show_bug.cgi?id=250482
rdar://103551585
Reviewed by Justin Michaud.
Given the wasm code which exports a wasm function `intFuncRef2` as a js function.
```
(func (export "intFuncRef2") (param $p0 f32) (param $p1 funcref) (result i32 funcref)
(i32.const 42)
(local.get $p1)
(return)
)
```
The corresponding dumped bytecodes show
```
[ 0] enter
[ 1] mov dst:loc2, src:42(const0)
[ 4] mov dst:loc3, src:loc2 // loc2 contains the funcref but now replaced with 42
[ 7] ret // return [loc2, loc3]
```
which is wrong. Instead we should do
```
[ 0] enter
[ 1] mov dst:loc18, src:42(const0)
[ 4] mov dst:loc19, src:loc2
[ 7] mov dst:loc2, src:loc18
[ 10] mov dst:loc3, src:loc19
[ 13] ret
```
Note that loc2 is both parameter and return lot.
Locals usually need to be materialized on wasm stack when they are about to be or could
be clobbered, usually before a control entry, a branch, or redefinition. Previously,
Return writes only one value to the result slot that clobber one argument slot which
is fine. Since now wasm function can return tuple that might bring us to the situation
as shown in above example. We should materialize expression stack when return more than
one values.
* JSTests/wasm/stress/tuple-return.js: Added.
(async test):
* Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addReturn):
Canonical link: https://commits.webkit.org/252432.1029@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.15@safari-7615-branch
Commit: eed6a380fbda18a4a104de9c5a960e7a48b7ced6
https://github.com/WebKit/WebKit/commit/eed6a380fbda18a4a104de9c5a960e7a48b7ced6
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.1.20
Canonical link: https://commits.webkit.org/259548.17@safari-7615-branch
Commit: 614ea47ae108a8f1ccc192f486ab6308f5894812
https://github.com/WebKit/WebKit/commit/614ea47ae108a8f1ccc192f486ab6308f5894812
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
M Source/WebCore/bindings/js/JSErrorHandler.cpp
M Source/WebCore/bindings/js/JSEventListener.cpp
M Source/WebCore/bindings/js/JSEventListener.h
M Source/WebCore/bindings/js/JSLazyEventListener.cpp
M Source/WebCore/bindings/js/WebCoreJSClientData.cpp
M Source/WebCore/bindings/js/WebCoreJSClientData.h
M Source/WebCore/dom/EventTarget.cpp
M Source/WebCore/inspector/CommandLineAPIHost.cpp
M Source/WebCore/inspector/WebInjectedScriptHost.cpp
M Source/WebCore/inspector/agents/InspectorDOMAgent.cpp
Log Message:
-----------
Cherry-pick 433db4f29219. rdar://problem/100763856
Heap use-after-free in DOMWrapperWorld::~DOMWrapperWorld
https://bugs.webkit.org/show_bug.cgi?id=246022
rdar://100763856
Reviewed by Jonathan Bedard and Ryosuke Niwa.
Right before a worker terminates, it destroys its WorkerOrWorkletScriptController,
which destroys the JS VM. Certain objects like DOMWrapperWorld cannot outlive
the VM since they keep a `VM&' as data member. However, DOMWrapperWorld is
refcounted and JSEventListeners hold a strong ref to their DOMWrapperWorld. If
JSEventListeners outlive the VM, then it would lead to a use-after free in the
DOMWrapperWorld destructor when destroying those JSEventListeners later on.
We have previously made several attempts to try and unregister all event
listeners before destroying the VM. However, those attempts were either
incomplete or led to other crashes. I am therefore trying a different approach
this time.
JSEventListeners now register themselves as client of the JSVMClientData (which
is owned by the VM) and the client gets a `willDestroyVM()` call before the
VM gets destroyed. This allows JSEventListeners to clear out their data members
which rely on the VM (DOMWrapperWorld and JSC::Weak data members).
* Source/WebCore/bindings/js/JSErrorHandler.cpp:
(WebCore::JSErrorHandler::handleEvent):
* Source/WebCore/bindings/js/JSEventListener.cpp:
(WebCore::JSEventListener::JSEventListener):
(WebCore::JSEventListener::handleEvent):
(WebCore::JSEventListener::functionName const):
(WebCore::JSEventListener::willDestroyVM):
* Source/WebCore/bindings/js/JSEventListener.h:
(WebCore::JSEventListener::isolatedWorld const):
(WebCore::JSEventListener::ensureJSFunction const):
* Source/WebCore/bindings/js/JSLazyEventListener.cpp:
(WebCore::JSLazyEventListener::initializeJSFunction const):
* Source/WebCore/bindings/js/WebCoreJSClientData.cpp:
(WebCore::JSVMClientData::~JSVMClientData):
* Source/WebCore/bindings/js/WebCoreJSClientData.h:
(WebCore::JSVMClientData::addClient):
* Source/WebCore/dom/EventTarget.cpp:
(WebCore::EventTarget::attributeEventListener):
* Source/WebCore/inspector/CommandLineAPIHost.cpp:
(WebCore::CommandLineAPIHost::getEventListeners):
* Source/WebCore/inspector/WebInjectedScriptHost.cpp:
(WebCore::objectForEventTargetListeners):
* Source/WebCore/inspector/agents/InspectorDOMAgent.cpp:
(WebCore::InspectorDOMAgent::buildObjectForEventListener):
Canonical link: https://commits.webkit.org/252432.1030@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.18@safari-7615-branch
Commit: 1f4d2fc64a6d3745bdd038c7fb0ed1abdc5d2b39
https://github.com/WebKit/WebKit/commit/1f4d2fc64a6d3745bdd038c7fb0ed1abdc5d2b39
Author: David Degazio <d_degazio at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
A JSTests/stress/cell-speculated-array-indexof.js
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
Log Message:
-----------
Cherry-pick 252432.1031 at safari-7614-branch (9f7e401c42a8). rdar://103852510
Fix use-after-free in DFGFixupPhase for array indexOf
https://bugs.webkit.org/show_bug.cgi?id=250429
rdar://103852510
Reviewed by Jonathan Bedard and Michael Saboff.
During DFG fixup, array indexOf nodes are folded to -1 when the search element is speculated
to be a different type than the array element (for instance, JSCell instead of Int32). When
this happens, a speculation check is inserted, which can cause the DFG graph's varArgChildren
array to reallocate. This invalidates the searchElement Edge reference, which we use
immediately after the check insertion in the fixup phase. This patch fixes this potential
use-after-free by grabbing the searchElement's associated node before inserting any checks,
giving us a persistent pointer to a DFG node rather than a reference into a vector.
* JSTests/stress/cell-speculated-array-indexof.js: Added.
* Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupArrayIndexOf):
Canonical link: https://commits.webkit.org/252432.1031@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.18@safari-7615-branch
Commit: b84b9ab9932b1056e77395a7e8ff91cee42fbec1
https://github.com/WebKit/WebKit/commit/b84b9ab9932b1056e77395a7e8ff91cee42fbec1
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
M Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp
Log Message:
-----------
Cherry-pick 252432.1033 at safari-7614-branch (02e324c57689). <rdar://102373218>
Possible type confusion bug in RemoteScrollingCoordinatorTransaction::decode
https://bugs.webkit.org/show_bug.cgi?id=250742
<rdar://102373218>
Reviewed by Jonathan Bedard and Ryosuke Niwa.
RemoteScrollingCoordinatorTransaction::decode() fails to check whether the nodeID returned by
`m_scrollingStateTree->insertNode()` is a new one, different from the `nodeID` argument. If so, it
could indicate that the node type of `m_scrollingStateTree->stateNodeForID()` does not match
`nodeType`, leading to type confusion.
In the UI process, `m_scrollingStateTree->insertNode()` should never return a different nodeID; this
only happens when the given nodeType does not match the type of the existing node, which only
happens in the WebProcess. So if `insertNode()` returns a different nodeID, or when the returned
node doesn't have the expected type, we can consider it an IPC decoding error.
* Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
(WebKit::RemoteScrollingCoordinatorTransaction::decode):
Canonical link: https://commits.webkit.org/252432.1033@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.19@safari-7615-branch
Commit: cdc9b351b5da54a789f846e5996252817e2bee99
https://github.com/WebKit/WebKit/commit/cdc9b351b5da54a789f846e5996252817e2bee99
Author: Ryan Reno <rreno at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub-expected.txt
A LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub.html
M Source/WebCore/page/csp/ContentSecurityPolicySource.cpp
Log Message:
-----------
Cherry-pick 252432.1034 at safari-7614-branch (3ee4a8321986). rdar://104335301
CSP bypass due to incorrect handling of wildcard character in host expression
https://bugs.webkit.org/show_bug.cgi?id=250709
rdar://104335301
Reviewed by Brent Fulgham and Jonathan Bedard.
We were treating something like "https://*/foo" as being a scheme-only source (so checking only against
'https'). That is fixed by not only checking for the host-part being an empty string but also whether or not
the host wildcard flag had been set by the CSP parser. Additionally, we were checking a given URL's host
against the wildcard assuming a format like "*.com" instead of the possibility of the catch-all "*" wildcard.
This change fixes our handling of the wildcard "*" in a directive's source list by correctly identifying when a
source is scheme-only and by correctly taking into account the entire host-part wildcard grammar when checking
a given host against a wildcard pattern.
* LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub.html: Added.
* Source/WebCore/page/csp/ContentSecurityPolicySource.cpp:
(WebCore::ContentSecurityPolicySource::hostMatches const):
(WebCore::ContentSecurityPolicySource::isSchemeOnly const):
Canonical link: https://commits.webkit.org/252432.1034@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.20@safari-7615-branch
Commit: 0ddfa735c301195973e3002aef53f891e67b870c
https://github.com/WebKit/WebKit/commit/0ddfa735c301195973e3002aef53f891e67b870c
Author: Michael Saboff <msaboff at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
A JSTests/stress/regexp-testinline-stacklimits.js
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/runtime/RegExp.h
M Source/JavaScriptCore/yarr/YarrJIT.cpp
Log Message:
-----------
Cherry-pick 252432.1036 at safari-7614-branch (c553da3adc35). rdar://104072550
[JSC] RegExp.test inline is missing some stack overflow checks
https://bugs.webkit.org/show_bug.cgi?id=250873
rdar://104072550
Reviewed by Yusuke Suzuki.
The RegExp.test inline code is missing two stack overflow checks.
1) When compiling the pattern string to a YarrPattern, we checked for stack overflow,
but didn't do anything with the failure.
2) When allocating the stack space needed to execute the JIT code for the expression
we need to first check that we have enough stack.
This change adds checks for both cases using the JSRegExpResult::JITCodeFailure return value when we
would have overflowed the stack. The results checking code after the inline code sees that error
value, it will now call out to the appropriate C++ helper function to perform the match.
Those functions are capable of throwing Out of Stack exceptions.
* JSTests/stress/regexp-testinline-stacklimits.js: Added new test.
(baz):
(bar):
(foo):
(true.string_appeared_here.repeat):
(true.catch):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileRegExpTestInline):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* Source/JavaScriptCore/runtime/RegExp.h:
* Source/JavaScriptCore/yarr/YarrJIT.cpp:
(JSC::Yarr::jitCompileInlinedTest):
Canonical link: https://commits.webkit.org/252432.1036@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.21@safari-7615-branch
Commit: 433aae06c3e18d614bb94f59c1e9f2a652d02386
https://github.com/WebKit/WebKit/commit/433aae06c3e18d614bb94f59c1e9f2a652d02386
Author: Gerald Squelart <g_squelart at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
M Source/WebCore/platform/graphics/IntRect.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Validate IPC-decoded IntRect's
rdar://101324985
Reviewed by Dean Jackson.
* Source/WebCore/platform/graphics/IntRect.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Canonical link: https://commits.webkit.org/259548.22@safari-7615-branch
Commit: c36c1e18ef5dd43fe0272e9cb6674f64ee69c980
https://github.com/WebKit/WebKit/commit/c36c1e18ef5dd43fe0272e9cb6674f64ee69c980
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm
Log Message:
-----------
Cherry-pick 252432.1040 at safari-7614-branch (5f64e30a652b). <rdar://102603221>
[CoreIPC] Type confusion bugs in RemoteScrollingCoordinatorProxyIOS::establishLayerTreeScrollingRelations
https://bugs.webkit.org/show_bug.cgi?id=250812
<rdar://102603221>
Reviewed by Jonathan Bedard and Ryosuke Niwa.
Add MESSAGE_CHECKing for two node types in code that runs in response to an IPC message.
Add an early return checking the root node type in code that runs from user events.
* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
(WebKit::RemoteScrollingCoordinatorProxy::establishLayerTreeScrollingRelations):
(WebKit::RemoteScrollingCoordinatorProxy::nearestActiveContentInsetAdjustedSnapOffset const):
Canonical link: https://commits.webkit.org/252432.1040@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.23@safari-7615-branch
Commit: fe42cdb53f0fc9924206cb88650ecdfbf22ad98c
https://github.com/WebKit/WebKit/commit/fe42cdb53f0fc9924206cb88650ecdfbf22ad98c
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
A LayoutTests/fast/table/table-cell-crash-when-detached-state-2-expected.txt
A LayoutTests/fast/table/table-cell-crash-when-detached-state-2.html
M Source/WebCore/rendering/RenderLayerModelObject.cpp
Log Message:
-----------
Cherry-pick 256843.4 at webkit-2022.12-embargoed (6234ec9c65b9). rdar://102808328
Do not issue repaints when in detached state
https://bugs.webkit.org/show_bug.cgi?id=248773
rdar://102808328
Reviewed by Antti Koivisto.
Do not issue repaints when the RenderObject is in detached state while removing render subtrees.
* LayoutTests/fast/table/table-cell-crash-when-detached-state-2-expected.txt: Added.
* LayoutTests/fast/table/table-cell-crash-when-detached-state-2.html: Added.
* Source/WebCore/rendering/RenderLayerModelObject.cpp:
(WebCore::RenderTableCell::willBeRemovedFromTree const):
Canonical link: https://commits.webkit.org/256843.4@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/259548.24@safari-7615-branch
Commit: 1a20160f826c5b348a2c38128cdaa79bb9b867e2
https://github.com/WebKit/WebKit/commit/1a20160f826c5b348a2c38128cdaa79bb9b867e2
Author: Justin Michaud <justin_michaud at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
A JSTests/wasm/stress/many-locals-small-wasm-stack.js
A JSTests/wasm/stress/many-locals-small-wasm-stack.wasm
A JSTests/wasm/stress/many-locals-small-wasm-stack.wat
M Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
Log Message:
-----------
Locals should update max stack size
rdar://104692168
Reviewed by Yusuke Suzuki.
We can forget to update the max stack size, causing an OOB stack read in
OSR entry. This only happens if you create a bunch of locals and never
push anything to the stack, so it should be very rare and difficult to
abuse.
* JSTests/wasm/stress/many-locals-small-wasm-stack.js: Added.
(async let):
* JSTests/wasm/stress/many-locals-small-wasm-stack.wasm: Added.
* JSTests/wasm/stress/many-locals-small-wasm-stack.wat: Added.
* Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addLocal):
Canonical link: https://commits.webkit.org/259548.25@safari-7615-branch
Commit: 53ca7314c84e57851428d264ebdb2bbc72482f97
https://github.com/WebKit/WebKit/commit/53ca7314c84e57851428d264ebdb2bbc72482f97
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
A LayoutTests/fast/dom/set-outer-text-on-moved-element-expected.html
A LayoutTests/fast/dom/set-outer-text-on-moved-element.html
M Source/WebCore/rendering/updating/RenderTreeUpdater.cpp
Log Message:
-----------
Cherry-pick 256843.6 at webkit-2022.12-embargoed (c4c0ef6360b2). rdar://102808104
Verify that style update roots are for correct document
https://bugs.webkit.org/show_bug.cgi?id=248775
rdar://102808104
Reviewed by Antti Koivisto.
Verify that style update roots are for the correct document since
we may be dealing with a pending update on an element/text node that
moved to another document.
* LayoutTests/fast/dom/set-outer-text-on-moved-element-expected.html: Added.
* LayoutTests/fast/dom/set-outer-text-on-moved-element.html: Added.
* Source/WebCore/rendering/updating/RenderTreeUpdater.cpp:
(WebCore::RenderTreeUpdater::commit):
Canonical link: https://commits.webkit.org/256843.6@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/259548.26@safari-7615-branch
Commit: 97035e0981452a6db759e30f25a2492aa14a28bb
https://github.com/WebKit/WebKit/commit/97035e0981452a6db759e30f25a2492aa14a28bb
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
M Source/WebKit/UIProcess/WebProcessProxy.cpp
Log Message:
-----------
Use-after-free under WebProcessProxy::logDiagnosticMessageForResourceLimitTermination()
https://bugs.webkit.org/show_bug.cgi?id=251454
rdar://104818871
Reviewed by David Kilzer and Ryosuke Niwa.
The code was storing a reference to a temporary.
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::logDiagnosticMessageForResourceLimitTermination):
Canonical link: https://commits.webkit.org/259548.27@safari-7615-branch
Commit: edbb5f8954848a8030de37c1b85a6175bc19e7d9
https://github.com/WebKit/WebKit/commit/edbb5f8954848a8030de37c1b85a6175bc19e7d9
Author: Patrick Angle <pangle at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
A LayoutTests/inspector/console/console-recursive-logging-expected.txt
A LayoutTests/inspector/console/console-recursive-logging.html
M Source/JavaScriptCore/inspector/agents/InspectorConsoleAgent.cpp
M Source/JavaScriptCore/inspector/agents/InspectorConsoleAgent.h
Log Message:
-----------
Cherry-pick 252432.1043 at safari-7614-branch (6633438abd8b). rdar://104083913
Web Inspector: Console messages that log a value that recursively logs crashes
https://bugs.webkit.org/show_bug.cgi?id=251018
rdar://104083913
Reviewed by Jonathan Bedard and Michael Saboff.
Web Inspector normally generates a preview for objects logged in the console when Web Inspector is open. However, it is
possible for authored pages to cause logging to occur when we attempt to generate the preview, as we must invoke getters
to get the values to display. In order to not recursively log messages to the console this patch turns off generating
previews for console messages that are logged while in middle of logging another console message. The user can still
generate a preview later in Web Inspector by using the disclosure triangle next to the message, which will then cause
the getter to be invoked, but the same protection will kick in to prevent recursive logging via generating previews
for objects.
* LayoutTests/inspector/console/console-recursive-logging-expected.txt: Added.
* LayoutTests/inspector/console/console-recursive-logging.html: Added.
* Source/JavaScriptCore/inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::addConsoleMessage):
* Source/JavaScriptCore/inspector/agents/InspectorConsoleAgent.h:
Canonical link: https://commits.webkit.org/252432.1043@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.28@safari-7615-branch
Commit: ce8f16b1a26ec1da841191802a02bf2c28eeb9c5
https://github.com/WebKit/WebKit/commit/ce8f16b1a26ec1da841191802a02bf2c28eeb9c5
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
Log Message:
-----------
[CoreIPC] division by zero in _restoreScrollAndZoomStateForTransaction
https://bugs.webkit.org/show_bug.cgi?id=251095
rdar://101521038
Reviewed by Wenson Hsieh and Jonathan Bedard.
In `_restorePageStateToUnobscuredCenter`, a division-by-zero can occur if `_scaleToRestore == 0.0`.
This PR adds a `MESSAGE_CHECK` to the IPC methods which set this variable to ensure that only
positive scale values may be set.
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::restorePageState):
(WebKit::WebPageProxy::restorePageCenterAndScale):
Canonical link: https://commits.webkit.org/259548.29@safari-7615-branch
Commit: 49109db4ab87a715f7a8987c7ee380e63060298b
https://github.com/WebKit/WebKit/commit/49109db4ab87a715f7a8987c7ee380e63060298b
Author: Ryan Reno <rreno at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
M Source/JavaScriptCore/runtime/Error.cpp
M Source/JavaScriptCore/runtime/StackFrame.cpp
M Source/JavaScriptCore/runtime/StackFrame.h
M Source/WTF/wtf/URL.cpp
M Source/WTF/wtf/URL.h
M Source/WebInspectorUI/UserInterface/Base/URLUtilities.js
M Source/WebInspectorUI/UserInterface/Models/DebuggerData.js
M Tools/TestWebKitAPI/Tests/WTF/URL.cpp
Log Message:
-----------
Error object stacktraces may leak sensitive data in URL query parameters
https://bugs.webkit.org/show_bug.cgi?id=250760
rdar://104376838
Reviewed by Patrick Angle.
If a remote script is delivered after a redirect sensitive data may be present
in the post-redirect URL. If the script later throws an error the error event
object will have that post-redirect URL in its stacktrace and sourceURL properties.
* Source/JavaScriptCore/runtime/Error.cpp:
(JSC::getLineColumnAndSource):
* Source/JavaScriptCore/runtime/StackFrame.cpp:
(JSC::StackFrame::sourceURLStripped const):
This is a new function which uses the URL class to strip
potentially sensitive information from the URL of the script
which contains the code for the current stack frame.
(JSC::StackFrame::toString const):
* Source/JavaScriptCore/runtime/StackFrame.h:
* Source/WTF/wtf/URL.cpp:
(WTF::URL::strippedForUseAsReport const):
This is a function similar to strippedForUseAsReferrer except we also remove
query parameters from the URL while strippedForUseAsReferrer only strips
user information and fragment.
* Source/WTF/wtf/URL.h:
* Source/WebInspectorUI/UserInterface/Base/URLUtilities.js:
Adds a utility function similar to WTF::URL::strippedForUseAsReport.
* Source/WebInspectorUI/UserInterface/Models/DebuggerData.js:
(WI.DebuggerData.prototype.scriptsForURL):
(WI.DebuggerData.prototype.addScript):
The Web Inspector debugger maps URLs it knows about to URLs reported
by the stack frames in an error object's stack trace. This allows one
to jump to offending source lines in the web inspector. In order to
correctly map the stripped URL reported in a stack trace we need to key
the map on the stripped URL as well.
* Tools/TestWebKitAPI/Tests/WTF/URL.cpp:
(TestWebKitAPI::TEST_F):
Adds a unit test for URL::strippedForUseAsReport
Canonical link: https://commits.webkit.org/259548.30@safari-7615-branch
Commit: 647c9c9c6261e42478215ec0095b0c6112c2f067
https://github.com/WebKit/WebKit/commit/647c9c9c6261e42478215ec0095b0c6112c2f067
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
A LayoutTests/fast/css-grid-layout/grid-stylechange-crash-expected.txt
A LayoutTests/fast/css-grid-layout/grid-stylechange-crash.html
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderGrid.h
Log Message:
-----------
Cherry-pick 252432.1044 at safari-7614-branch (22cbd76bcc96). rdar://104559684
Invalidate grid placement when style changes to subgrid
rdar://104559684
Reviewed by Jonathan Bedard and Matt Woodrow.
Before this change, we didn't invalidate parent and child placement
info, leading to a OOB read into the parent tracks information when
copying that to the child. This change fixes that.
* LayoutTests/fast/css-grid-layout/grid-stylechange-crash-expected.txt: Added.
* LayoutTests/fast/css-grid-layout/grid-stylechange-crash.html: Added.
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::styleDidChange):
(WebCore::RenderGrid::subgridDidChange const):
(WebCore::RenderGrid::dirtyGrid):
* Source/WebCore/rendering/RenderGrid.h:
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::copyUsedTrackSizesForSubgrid):
Canonical link: https://commits.webkit.org/252432.1044@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.31@safari-7615-branch
Commit: 484046c586bf34636072d726e6c0e859206314cd
https://github.com/WebKit/WebKit/commit/484046c586bf34636072d726e6c0e859206314cd
Author: Mark Lam <mark.lam at apple.com>
Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths:
M Source/JavaScriptCore/API/JSCallbackConstructor.h
M Source/JavaScriptCore/API/JSCallbackFunction.h
M Source/JavaScriptCore/API/JSClassRef.h
M Source/JavaScriptCore/API/JSWeakObjectMapRefInternal.h
M Source/JavaScriptCore/API/ObjCCallbackFunction.h
M Source/JavaScriptCore/runtime/ClassInfo.h
M Source/JavaScriptCore/runtime/Lookup.h
Log Message:
-----------
Cherry-pick 252432.1045 at safari-7614-branch (77446d5c727e). rdar://102768157
[Re-land] Add additional PAC diversity for function pointers in JSC API data structures as we do for vtbls.
https://bugs.webkit.org/show_bug.cgi?id=248702
<rdar://problem/102768157>
Reviewed by Yusuke Suzuki.
* Source/JavaScriptCore/API/JSCallbackConstructor.h:
* Source/JavaScriptCore/API/JSCallbackFunction.h:
* Source/JavaScriptCore/API/JSClassRef.h:
* Source/JavaScriptCore/API/JSWeakObjectMapRefInternal.h:
* Source/JavaScriptCore/API/ObjCCallbackFunction.h:
* Source/JavaScriptCore/runtime/ClassInfo.h:
* Source/JavaScriptCore/runtime/Lookup.h:
Canonical link: https://commits.webkit.org/252432.1045@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.32@safari-7615-branch
Commit: 76066c1ef2229e33f385b3e03cbca8b5af154442
https://github.com/WebKit/WebKit/commit/76066c1ef2229e33f385b3e03cbca8b5af154442
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitbugspy/setup.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/github.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/issue.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/bugzilla.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/data.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py
Log Message:
-----------
Cherry-pick 259639 at main (28af6286be2f). rdar://104838949
[webkitbugspy] Access keywords from Radars and bugzillas
https://bugs.webkit.org/show_bug.cgi?id=251398
rdar://104838949
Reviewed by Aakash Jain.
* Tools/Scripts/libraries/webkitbugspy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py:
(Tracker.populate): Populate keywords.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/github.py:
(Tracker.populate): Note that keywords are unsupported.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/issue.py:
(Issue.__init__): Add keywords.
(Issue.keywords): Ditto.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/bugzilla.py:
(Bugzilla._issue): Create an issue without any keywords.
(Bugzilla._create): Return keywords.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/data.py:
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py:
(RadarModel.Keyword): Added.
(RadarModel.keywords): Ditto.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py:
(Tracker.populate): Populate keywords associated with radar.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py:
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py:
Canonical link: https://commits.webkit.org/259639@main
Canonical link: https://commits.webkit.org/259548.33@safari-7615-branch
Commit: fae4d5c750e89a5aa5c8756befcbae3c1a711605
https://github.com/WebKit/WebKit/commit/fae4d5c750e89a5aa5c8756befcbae3c1a711605
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/mocks/remote/bitbucket.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/mocks/remote/git_hub.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/pull_request.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/bitbucket.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/git_hub.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py
Log Message:
-----------
Cherry-pick 259691 at main (632106470537). rdar://104889825
[webkitscmpy] Expose hash of HEAD commit
https://bugs.webkit.org/show_bug.cgi?id=251464
rdar://104889825
Reviewed by Aakash Jain.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/mocks/remote/bitbucket.py:
(BitBucket.request): Return hash of PR head.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/mocks/remote/git_hub.py:
(GitHub.graphql): Pass hash of PR head.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/pull_request.py:
(PullRequest.__init__): Receive hash of PR head.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/bitbucket.py:
(BitBucket.PRGenerator.PullRequest): Pass hash of PR head.
(BitBucket.PRGenerator.create): Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/git_hub.py:
(GitHub.PRGenerator.PullRequest): Pass hash of PR head.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py:
Canonical link: https://commits.webkit.org/259691@main
Canonical link: https://commits.webkit.org/259548.34@safari-7615-branch
Commit: a01ddeab3a6d0612371c95e45ee6fe275ddb7cd4
https://github.com/WebKit/WebKit/commit/a01ddeab3a6d0612371c95e45ee6fe275ddb7cd4
Author: Alex Christensen <achristensen at apple.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M Source/WebKit/Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm
M Source/WebKit/UIProcess/Launcher/cocoa/ProcessLauncherCocoa.mm
Log Message:
-----------
Cherry-pick 06c8c34deeb9. rdar://problem/104569995
Enable framework version mismatch check on Catalyst builds
https://bugs.webkit.org/show_bug.cgi?id=251569
rdar://104569995
Reviewed by Chris Dumez.
We see some crashes sometimes which indicate that auxiliary processes are decoding incompatible messages.
Do the version check like we do on macOS to make it more clear what is going on.
* Source/WebKit/Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:
(WebKit::XPCServiceMain):
* Source/WebKit/UIProcess/Launcher/cocoa/ProcessLauncherCocoa.mm:
(WebKit::ProcessLauncher::launchProcess):
Canonical link: https://commits.webkit.org/259756@main
Canonical link: https://commits.webkit.org/259548.36@safari-7615-branch
Commit: e397aab78e7328d62117af9e25be9f100d33c15b
https://github.com/WebKit/WebKit/commit/e397aab78e7328d62117af9e25be9f100d33c15b
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M Source/WebCore/platform/mediastream/MediaConstraints.h
Log Message:
-----------
Cherry-pick 252432.1035 at safari-7614-branch (b9851bb36465). rdar://103012405
IPC hardening for MediaConstraint subclasses
https://bugs.webkit.org/show_bug.cgi?id=250722
rdar://103012405
Reviewed by Jonathan Bedard and David Kilzer.
Make sure we validate the constraint type whenever we IPC-deserialize a
MediaConstraint subclass.
* Source/WebCore/platform/mediastream/MediaConstraints.h:
(WebCore::NumericConstraint::decode):
(WebCore::StringConstraint::decode):
Canonical link: https://commits.webkit.org/252432.1035@safari-7614-branch
Canonical link: https://commits.webkit.org/259548.36@safari-7615-branch
Commit: a96eb9fd341713aeb3bb7729ec6ec1a3658ff56c
https://github.com/WebKit/WebKit/commit/a96eb9fd341713aeb3bb7729ec6ec1a3658ff56c
Author: Robert Jenner <jenner at apple.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M LayoutTests/svg/compositing/outermost-svg-with-border-padding.html
Log Message:
-----------
Cherry-pick 259646 at main (ee8e4757570e). https://bugs.webkit.org/show_bug.cgi?id=248018
REGRESSION(256180 at main): Enabling accelerated drawing caused some ImageOnly Failures (248018)
https://bugs.webkit.org/show_bug.cgi?id=248018
Unreviewed test gardening.
Follow-up fix to svg/compositing/outermost-svg-with-border-padding.html.
* LayoutTests/svg/compositing/outermost-svg-with-border-padding.html:
Canonical link: https://commits.webkit.org/259646@main
Canonical link: https://commits.webkit.org/259548.37@safari-7615-branch
Commit: 2a2126344ab5bb7b23e572c18f048236a36ffa03
https://github.com/WebKit/WebKit/commit/2a2126344ab5bb7b23e572c18f048236a36ffa03
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M LayoutTests/fast/repaint/rtl-content-selection-hairline-gap-expected.txt
M LayoutTests/fast/repaint/rtl-content-selection-hairline-gap.html
Log Message:
-----------
Cherry-pick 259692 at main (c743104c1d86). <rdar://problem/104881737>
[iOS / macOS] fast/repaint/rtl-content-selection-hairline-gap.html is a flaky failure
https://bugs.webkit.org/show_bug.cgi?id=251452
<rdar://problem/104881737>
Unreviewed.
Do not rely on repaint order.
* LayoutTests/fast/repaint/rtl-content-selection-hairline-gap-expected.txt:
* LayoutTests/fast/repaint/rtl-content-selection-hairline-gap.html:
Canonical link: https://commits.webkit.org/259692@main
Canonical link: https://commits.webkit.org/259548.38@safari-7615-branch
Commit: c68b7da0d9b419e335b4cb6e6ee53c20948f7a9b
https://github.com/WebKit/WebKit/commit/c68b7da0d9b419e335b4cb6e6ee53c20948f7a9b
Author: Ryan Reno <rreno at apple.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M Source/JavaScriptCore/API/JSScript.mm
M Source/JavaScriptCore/API/JSScriptRef.cpp
M Source/JavaScriptCore/inspector/ScriptCallFrame.cpp
M Source/JavaScriptCore/inspector/ScriptCallFrame.h
M Source/JavaScriptCore/inspector/ScriptCallStackFactory.cpp
M Source/JavaScriptCore/interpreter/StackVisitor.cpp
M Source/JavaScriptCore/interpreter/StackVisitor.h
M Source/JavaScriptCore/parser/SourceProvider.cpp
M Source/JavaScriptCore/parser/SourceProvider.h
M Source/JavaScriptCore/runtime/CachedTypes.cpp
M Source/JavaScriptCore/runtime/ScriptExecutable.h
M Source/WebCore/bindings/js/CachedScriptSourceProvider.h
M Source/WebCore/bindings/js/ScriptBufferSourceProvider.h
M Source/WebCore/bindings/js/ScriptModuleLoader.cpp
M Source/WebCore/bindings/js/ScriptSourceCode.h
M Source/WebCore/page/csp/ContentSecurityPolicy.cpp
M Source/WebCore/workers/WorkerGlobalScope.cpp
M Source/WebCore/workers/WorkerThread.cpp
Log Message:
-----------
Cross-Site Information Leak: CSP violation reports may contain a post-redirect URL
https://bugs.webkit.org/show_bug.cgi?id=251282
rdar://104753003
Reviewed by Yusuke Suzuki.
The source-file field of a CSP violation report may contain a URL which has sensitive data in the
query string if it was the result of a redirect. The CSP spec in non-normative terms suggests
that in the case of a redirect (such as a login flow which appends a login token) we should report
violations in the resulting resource with the pre-redirect URL to avoid cross-site information leaks
via the CSP reporting API.
Source/JavaScriptCore:
Plubming code to make pre-redirect URLs available in ScriptCallStacks.
When a ScriptCallStack is created by the StackVisitor the ScriptCallFrame
objects will be populated with the pre-redirect URL by consulting the SourceProvider. WebCore
will conditionally set the preRedirectURL member if the resource was obtained via a redirected
response.
* Source/JavaScriptCore/API/JSScript.mm:
(-[JSScript sourceCode]):
* Source/JavaScriptCore/API/JSScriptRef.cpp:
* Source/JavaScriptCore/inspector/ScriptCallFrame.cpp:
(Inspector::ScriptCallFrame::ScriptCallFrame):
(Inspector::ScriptCallFrame::isEqual const):
* Source/JavaScriptCore/inspector/ScriptCallFrame.h:
* Source/JavaScriptCore/inspector/ScriptCallStackFactory.cpp:
(Inspector::CreateScriptCallStackFunctor::operator() const):
* Source/JavaScriptCore/interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::preRedirectURL const):
* Source/JavaScriptCore/interpreter/StackVisitor.h:
* Source/JavaScriptCore/parser/SourceProvider.cpp:
(JSC::SourceProvider::SourceProvider):
(JSC::BaseWebAssemblySourceProvider::BaseWebAssemblySourceProvider):
* Source/JavaScriptCore/parser/SourceProvider.h:
(JSC::SourceProvider::preRedirectURL const):
(JSC::StringSourceProvider::StringSourceProvider):
* Source/JavaScriptCore/runtime/CachedTypes.cpp:
(JSC::CachedSourceProviderShape::encode):
* Source/JavaScriptCore/runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::preRedirectURL const):
Source/WebCore:
This updates the constructors for ScriptSourceCode objects to pass
null strings for the preRedirectURL parameter. In the cases where we can detect
whether a redirect happened or not we pass the pre-redirect URL to the SourceProvider.
* Source/WebCore/bindings/js/CachedScriptSourceProvider.h:
(WebCore::CachedScriptSourceProvider::CachedScriptSourceProvider):
* Source/WebCore/bindings/js/ScriptBufferSourceProvider.h:
* Source/WebCore/bindings/js/ScriptModuleLoader.cpp:
(WebCore::ScriptModuleLoader::notifyFinished):
* Source/WebCore/bindings/js/ScriptSourceCode.h:
(WebCore::ScriptSourceCode::ScriptSourceCode):
* Source/WebCore/workers/WorkerGlobalScope.cpp:
(WebCore::WorkerGlobalScope::importScripts):
* Source/WebCore/workers/WorkerThread.cpp:
(WebCore::WorkerThread::evaluateScriptIfNecessary):
* Source/WebCore/page/csp/ContentSecurityPolicy.cpp:
(WebCore::ContentSecurityPolicy::reportViolation const):
To populate the source-file field of a CSP report we consult the
JavaScript call stack. The source URL of the frame may be the
result of a redirect in which case we should use the pre-redirect
URL in the report to avoid leaking potentially sensitive data in the post-redirect URL.
Canonical link: https://commits.webkit.org/259548.39@safari-7615-branch
Commit: bf2c7c5b03b0a75ec4605cf02f4a66bb1b9b875d
https://github.com/WebKit/WebKit/commit/bf2c7c5b03b0a75ec4605cf02f4a66bb1b9b875d
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
A LayoutTests/mathml/mathmltoken-layout-crash-expected.txt
A LayoutTests/mathml/mathmltoken-layout-crash.html
M Source/WebCore/rendering/mathml/RenderMathMLToken.cpp
Log Message:
-----------
Fix layout for positioned children for RenderMathMLToken
rdar://104598552
Reviewed by Alan Baradlay.
Before this change, the layout method in RenderMathMLToken (<ms>) never
added positioned elements to the map for their container, which meant if
the positioned children are dirty, their layout will never be triggered.
This change fixes that by looking at direct children of
RenderMathMLToken and adding them to their container's positioned
elements map, so that their layout happens as expected.
* LayoutTests/mathml/mathmltoken-layout-crash-expected.txt: Added.
* LayoutTests/mathml/mathmltoken-layout-crash.html: Added.
* Source/WebCore/rendering/mathml/RenderMathMLToken.cpp:
(WebCore::RenderMathMLToken::layoutBlock):
Canonical link: https://commits.webkit.org/259548.40@safari-7615-branch
Commit: 569f8b660570678ccd46c80839b02feaf67a6c8a
https://github.com/WebKit/WebKit/commit/569f8b660570678ccd46c80839b02feaf67a6c8a
Author: Russell Epstein <repstein at apple.com>
Date: 2023-02-03 (Fri, 03 Feb 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.1.21
Canonical link: https://commits.webkit.org/259548.42@safari-7615-branch
Commit: dc83dd4a50e135567c3ddcb422a58df738c3c9e9
https://github.com/WebKit/WebKit/commit/dc83dd4a50e135567c3ddcb422a58df738c3c9e9
Author: Commit Queue <commit-queue at webkit.org>
Date: 2023-02-03 (Fri, 03 Feb 2023)
Changed paths:
M Source/WebKit/SourcesCocoa.txt
R Source/WebKit/UIProcess/API/Cocoa/WKApplicationManifest.h
R Source/WebKit/UIProcess/API/Cocoa/WKApplicationManifest.mm
R Source/WebKit/UIProcess/API/Cocoa/WKApplicationManifestInternal.h
R Source/WebKit/UIProcess/API/Cocoa/WKApplicationManifestPrivate.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/_WKInspector.mm
M Source/WebKit/UIProcess/API/Cocoa/_WKInspectorInternal.h
M Source/WebKit/UIProcess/API/ios/WKWebViewTestingIOS.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ApplicationManifest.mm
Log Message:
-----------
Cherry-pick fa74f2720e54. rdar://problem/104923240
Unreviewed, reverting r259523 at main.
https://bugs.webkit.org/show_bug.cgi?id=251525
No longer needed.
Reverted changeset:
"Add WKApplicationManifest API"
https://bugs.webkit.org/show_bug.cgi?id=251298
https://commits.webkit.org/259523@main
Canonical link: https://commits.webkit.org/259699@main
Canonical link: https://commits.webkit.org/259548.43@safari-7615-branch
Commit: 4143d9cc48ce20995597cd36e524def4023fdb83
https://github.com/WebKit/WebKit/commit/4143d9cc48ce20995597cd36e524def4023fdb83
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-03 (Fri, 03 Feb 2023)
Changed paths:
M metadata/contributors.json
Log Message:
-----------
Cherry-pick 259798 at main (2064be239b76).
Fix Dawn Flores's email list
Unreviewed infrastructure fix.
* metadata/contributors.json: De-duplicate email entry for Dawn Flores.
Canonical link: https://commits.webkit.org/259798@main
Canonical link: https://commits.webkit.org/259548.43@safari-7615-branch
Commit: 90861f261d6c3df22854d66996871683f466e18e
https://github.com/WebKit/WebKit/commit/90861f261d6c3df22854d66996871683f466e18e
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-03 (Fri, 03 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/contributor.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/contributor_unittest.py
Log Message:
-----------
Cherry-pick 259831 at main (4d725fd53b44). rdar://105011200
[webkitscmpy] Handle dual-email commit messages
https://bugs.webkit.org/show_bug.cgi?id=251698
rdar://105011200
Reviewed by Aakash Jain.
Contributors should only have a single email when committing, but git-webkti
tooling should handle situations where that is not the case.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/contributor.py:
(Contributor.from_scm_log): Add regex supporting multiple emails in a commit message.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/contributor_unittest.py:
(TestContributor.test_double_git_log):
Canonical link: https://commits.webkit.org/259831@main
Canonical link: https://commits.webkit.org/259548.44@safari-7615-branch
Commit: 9930b53ebce12cd824e82e06715514d29446e369
https://github.com/WebKit/WebKit/commit/9930b53ebce12cd824e82e06715514d29446e369
Author: Michael Saboff <msaboff at apple.com>
Date: 2023-02-06 (Mon, 06 Feb 2023)
Changed paths:
M Source/JavaScriptCore/yarr/YarrJIT.cpp
Log Message:
-----------
[JSC] RegExp.test inline is missing another stack overflow checks
https://bugs.webkit.org/show_bug.cgi?id=251741
rdar://104072550
Reviewed by Mark Lam.
Converted the ASSERT(!m_failureReason) into a check that when true will bail out of the inline code
and call out to the C++ operation. This check handles any errors while compiling the RegExp pattern
into YarrJIT IR during the processing of opCompileBody().
I also audited all of the other possible error cases that the YarrJIT might produce and they are already
handled by this and the prior change.
The current test already covers this case.
* Source/JavaScriptCore/yarr/YarrJIT.cpp:
Canonical link: https://commits.webkit.org/259548.45@safari-7615-branch
Commit: a00a15e7abe0140bd98cda6485e52d03b2bdf79e
https://github.com/WebKit/WebKit/commit/a00a15e7abe0140bd98cda6485e52d03b2bdf79e
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-02-06 (Mon, 06 Feb 2023)
Changed paths:
M Source/WTF/wtf/PlatformUse.h
M Source/WebCore/page/MemoryRelease.cpp
M Source/WebCore/platform/audio/HRTFElevation.cpp
M Source/WebCore/platform/audio/HRTFElevation.h
Log Message:
-----------
Fix various issues with HRTFElevation's getConcatenatedImpulseResponsesForSubject()
https://bugs.webkit.org/show_bug.cgi?id=251643
rdar://104980786
Reviewed by Eric Carlson.
Fix various issues with HRTFElevation's getConcatenatedImpulseResponsesForSubject():
- Add a lock to synchronize access to the global HashMap of AudioBus objects
since this may get called from different threads.
- Make sure we call isolatedCopy() on the String key before adding it to the HashMap
for thread safety.
- Make sure we clear this global HashMap on critical memory pressure to free up
memory.
- Use smart pointers instead of raw pointers.
- Modernize the code a bit.
* Source/WTF/wtf/PlatformUse.h:
* Source/WebCore/page/MemoryRelease.cpp:
(WebCore::releaseCriticalMemory):
* Source/WebCore/platform/audio/HRTFElevation.cpp:
(WebCore::WTF_REQUIRES_LOCK):
(WebCore::getConcatenatedImpulseResponsesForSubject):
(WebCore::HRTFElevation::clearCache):
(WebCore::HRTFElevation::calculateKernelsForAzimuthElevation):
* Source/WebCore/platform/audio/HRTFElevation.h:
Canonical link: https://commits.webkit.org/259548.46@safari-7615-branch
Commit: 0f2c12121b0a488f5ce52b5d2da8d01508cec3d8
https://github.com/WebKit/WebKit/commit/0f2c12121b0a488f5ce52b5d2da8d01508cec3d8
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-02-06 (Mon, 06 Feb 2023)
Changed paths:
A JSTests/stress/arguments-elimination-should-happen-only-when-stack-slot-is-available-at-replacement-site.js
M Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp
Log Message:
-----------
[JSC] FTL arguments elimination should ensure that replacement sites can access to original stack slots
https://bugs.webkit.org/show_bug.cgi?id=251640
rdar://99273500
Reviewed by Mark Lam.
FTL arguments elimination does analysis and attempts to eliminate arguments allocation if it is not escaped.
We emit stack access at `arguments[0]` site for example, and remove `arguments` allocations.
But important thing is that stack slots used for the `arguments` need to be available at `arguments[0]` access site.
Since we are using stack slots for different purpose when inlining different functions, it is possible that the given
stack slot is no longer available when using `arguments[0]`. For example,
function a() { return arguments; }
function b() { do-something }
var arg = a()
b();
arg[0]; // If both "a" and "b" are inlined, stack slots used for inlined "a" can be used for the other purpose for "b"
// As a result, it is possible that the slot is not available at `arg[0]` access point.
We were doing stack slot interference analysis to avoid the above problem[1]. However, it was not complete solution since it is only
checking block-local status. So if we have branch between a() and arg[0], this analysis didn't work. Attached test
"arguments-elimination-should-happen-only-when-stack-slot-is-available-at-replacement-site.js" is literally doing this.
function empty() {}
function bar2(...a0) {
return a0;
}
function foo() {
let xs = bar2(undefined);
'' == 1 && 0;
return empty(...xs, undefined);
}
Between bar2 and `...xs` site, we have branch due to &&. And at "...xs" site, the stack slot were no longer available.
In this patch, we replace our existing interference analysis with the revised fix. We use OSR availability which can describe the
state of each stack slot. For all arguments, initially, it is flushed state with a node. Then, when slot gets unavailable or overridden,
we can see the availability change, which no longer points at the same node.
We first do this OSR availability analysis and capture availability map of each candidates. And then, we analyze whether replacement sites
are still seeing the same availability for arguments. And if it becomes different, we remove the candidate from optimization target. This change
simplifies our analysis significantly, and make it procedure global (previous one was block local).
[1]: https://commits.webkit.org/212536@main
* JSTests/stress/arguments-elimination-should-happen-only-when-stack-slot-is-available-at-replacement-site.js: Added.
(empty):
(bar2):
(foo):
(main):
* Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp:
Canonical link: https://commits.webkit.org/259548.47@safari-7615-branch
Commit: c7b07170d9d3cbd340ed682a622bf3279ee2d9ca
https://github.com/WebKit/WebKit/commit/c7b07170d9d3cbd340ed682a622bf3279ee2d9ca
Author: Russell Epstein <repstein at apple.com>
Date: 2023-02-06 (Mon, 06 Feb 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.1.22
Canonical link: https://commits.webkit.org/259548.49@safari-7615-branch
Commit: 7f9ebadce2fc535ac4a350ecab8b135a013e99c2
https://github.com/WebKit/WebKit/commit/7f9ebadce2fc535ac4a350ecab8b135a013e99c2
Author: Patrick Angle <pangle at apple.com>
Date: 2023-02-06 (Mon, 06 Feb 2023)
Changed paths:
M Source/JavaScriptCore/API/JSContext.h
M Source/JavaScriptCore/API/JSContext.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
Log Message:
-----------
Cherry-pick c0769577c02d. rdar://problem/105012093
Web Inspector: `inspectable` API doesn't have a correct Objective-C getter
https://bugs.webkit.org/show_bug.cgi?id=251702
rdar://105012093
Reviewed by Tim Horton.
Boolean getters should have an `is` prefix. Currently `inspectable` is not adhering to this rule. The current getter
also doesn't match the approved API design. This API has not yet shipped, and there is no internal usage of
`[webView inspectable]`, so this change will not break existing clients. `webView.inspectable` remains correct and
unchanged.
* Source/JavaScriptCore/API/JSContext.h:
* Source/JavaScriptCore/API/JSContext.mm:
(-[JSContext isInspectable]):
(-[JSContext inspectable]): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView isInspectable]):
(-[WKWebView inspectable]): Deleted.
Canonical link: https://commits.webkit.org/259840@main
Canonical link: https://commits.webkit.org/259548.50@safari-7615-branch
Commit: de821d716c1ae7e7678bddbd7e61cc3271885ff4
https://github.com/WebKit/WebKit/commit/de821d716c1ae7e7678bddbd7e61cc3271885ff4
Author: Karl Rackler <rackler at apple.com>
Date: 2023-02-06 (Mon, 06 Feb 2023)
Changed paths:
M Tools/Scripts/webkitpy/layout_tests/run_webkit_tests_integrationtest.py
M Tools/Scripts/webkitpy/port/ios_simulator.py
M Tools/Scripts/webkitpy/xcode/simulated_device_unittest.py
Log Message:
-----------
Cherry-pick 259682 at main (92607080b412). rdar://104886115
Change the default iPadOS simulator to one with a larger screen size
https://bugs.webkit.org/show_bug.cgi?id=251458
rdar://104886115
Reviewed by Jonathan Bedard and Ryan Haddad.
* Tools/Scripts/webkitpy/layout_tests/run_webkit_tests_integrationtest.py:
(RunTest.test_device_type_test_division):
(RunTest.test_device_type_specific_listing):
(RunTest.test_ipad_test_division):
(RunTest.test_ipad_listing):
* Tools/Scripts/webkitpy/port/ios_simulator.py:
(IOSSimulatorPort):
(IPadSimulatorPort):
* Tools/Scripts/webkitpy/xcode/simulated_device_unittest.py:
Canonical link: https://commits.webkit.org/259682@main
Canonical link: https://commits.webkit.org/259548.50@safari-7615-branch
Commit: 44f75343da9e63ec797b17d3875b5bbc7aeec3d2
https://github.com/WebKit/WebKit/commit/44f75343da9e63ec797b17d3875b5bbc7aeec3d2
Author: Antti Koivisto <antti at apple.com>
Date: 2023-02-06 (Mon, 06 Feb 2023)
Changed paths:
A LayoutTests/fast/css/display-contents-slot-to-none-expected.txt
A LayoutTests/fast/css/display-contents-slot-to-none.html
M Source/WebCore/style/StyleTreeResolver.cpp
Log Message:
-----------
[be894cadcf68a52a] (REGRESSION 256601 at main) ASAN_SEGV | WebCore::RenderObject::pushOntoGeometryMap; WebCore::RenderInline::pushMappingToContainer;
https://bugs.webkit.org/show_bug.cgi?id=251788
rdar://104793275
Reviewed by Alan Baradlay.
* LayoutTests/fast/css/display-contents-slot-to-none-expected.txt: Added.
* LayoutTests/fast/css/display-contents-slot-to-none.html: Added.
* Source/WebCore/style/StyleTreeResolver.cpp:
(WebCore::Style::affectsRenderedSubtree):
We may have had display:contents before and a rendered subtree may still be affected.
Canonical link: https://commits.webkit.org/259548.51@safari-7615-branch
Commit: 0dc9ae08a78792a5b21f6c4d403d3b3980c978a0
https://github.com/WebKit/WebKit/commit/0dc9ae08a78792a5b21f6c4d403d3b3980c978a0
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-02-06 (Mon, 06 Feb 2023)
Changed paths:
M Tools/DumpRenderTree/mac/Configurations/DumpRenderTree.xcconfig
M Tools/DumpRenderTree/mac/Info.plist
M Tools/Scripts/webkitpy/port/mac.py
Log Message:
-----------
Cherry-pick 259687 at main (165e0db5c729). rdar://104838472
Clear DumpRenderTree and WebKitTestRunner defaults before running tests
https://bugs.webkit.org/show_bug.cgi?id=251397
rdar://104838472
Reviewed by Jonathan Bedard.
Historically DumpRenderTree had no bundleID specified, so would save NSUserDefaults using
"DumpRenderTree". WebKitTestRunner, on the other hand, was correctly set up to use
"com.apple.WebKit.WebKitTestRunner". This patch gives DumpRenderTree a bundleID with
a "com.apple.WebKit" prefix.
These bundleIDs matter because webkitpy uses them to clear NSUserDefaults before test runs;
this worked fine for DumpRenderTree, but failed for WebKitTestRunner because the bundleID
was incorrect. Fix that in mac.py, and use the new bundleID com.apple.WebKit.DumpRenderTree too.
Generally failing to clear NSUserDefaults before testing isn't an issue, but defaults like WebCoreLogging
can get saved into NSUserDefaults if you run WebKitTestRunner directly with logging arguments, so clearing
before running tests is useful in that scenario.
* Tools/DumpRenderTree/mac/Configurations/DumpRenderTree.xcconfig:
* Tools/DumpRenderTree/mac/Info.plist:
* Tools/Scripts/webkitpy/port/mac.py:
(MacPort.reset_preferences):
Canonical link: https://commits.webkit.org/259687@main
Canonical link: https://commits.webkit.org/259548.52@safari-7615-branch
Commit: 31cb0f30efa1a5189ed1707168c1ca059253aaa7
https://github.com/WebKit/WebKit/commit/31cb0f30efa1a5189ed1707168c1ca059253aaa7
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-06 (Mon, 06 Feb 2023)
Changed paths:
M Tools/Scripts/webkitpy/xcode/device_type.py
M Tools/Scripts/webkitpy/xcode/device_type_unittest.py
M Tools/Scripts/webkitpy/xcode/simulated_device.py
Log Message:
-----------
Cherry-pick 259848 at main (1b334608e224). rdar://105021853
[run-webkit-tests] Handle diverse WatchOS device types
https://bugs.webkit.org/show_bug.cgi?id=251723
rdar://105021853
Reviewed by Ryan Haddad.
* Tools/Scripts/webkitpy/xcode/device_type.py:
(DeviceType.standardize_hardware_type): Refactor to allow invocation without a class instance,
add a check for WatchOS variants.
(DeviceType.standardized_hardware_type): Invoke refactored function
* Tools/Scripts/webkitpy/xcode/device_type_unittest.py:
(DeviceTypeTest.test_watch_standardization):
* Tools/Scripts/webkitpy/xcode/simulated_device.py:
(SimulatedDeviceManager._get_device_identifier_for_type): Invoke DeviceType.standardize_hardware_type
instead of re-implimenting the function.
Canonical link: https://commits.webkit.org/259848@main
Canonical link: https://commits.webkit.org/259548.53@safari-7615-branch
Commit: 14fd368d745a760882fb8018cc7b6b9bfeefa4e5
https://github.com/WebKit/WebKit/commit/14fd368d745a760882fb8018cc7b6b9bfeefa4e5
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-02-07 (Tue, 07 Feb 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.1.23
Canonical link: https://commits.webkit.org/259456.146@safari-7615-branch
Commit: f967244a7ce1b4eaf96b9df5e1bf5fc8f03053d1
https://github.com/WebKit/WebKit/commit/f967244a7ce1b4eaf96b9df5e1bf5fc8f03053d1
Author: Russell Epstein <repstein at apple.com>
Date: 2023-02-07 (Tue, 07 Feb 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Revert "Versioning."
This reverts commit 14fd368d745a760882fb8018cc7b6b9bfeefa4e5.
Canonical link: https://commits.webkit.org/259548.55@safari-7615-branch
Commit: b82c6f9328d1f30074b4f211b722248babb7f121
https://github.com/WebKit/WebKit/commit/b82c6f9328d1f30074b4f211b722248babb7f121
Author: Timothy Hatcher <timothy at apple.com>
Date: 2023-02-07 (Tue, 07 Feb 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm
Log Message:
-----------
Cherry-pick d8706351a89a. rdar://problem/103793194
Cross-Origin-Resource-Policy blocks fetch from extensions.
https://webkit.org/b/251858
rdar://103793194
Reviewed by Chris Dumez.
SecurityPolicy was blocking the fetch load due to the Cross-Origin-Resource-Policy check
in the NetworkProcess. In the WebProcess, SecurityPolicy checks were succeeding due to the
existing call to SecurityPolicy::allowAccessTo() when parsing the corsDisablingPatterns.
This step was missing in the NetworkProcess. Now both processes have the same checks.
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::setCORSDisablingPatterns): Add the pattern to SecurityPolicy to
match WebPage.cpp's parseAndAllowAccessToCORSDisablingPatterns().
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm:
(TEST(URLSchemeHandler, DisableCORSAndCORP)): Added.
Canonical link: https://commits.webkit.org/259976@main
Canonical link: https://commits.webkit.org/259548.56@safari-7615-branch
Commit: dea00c925126ff818ed076d7b0519dd04788cdd8
https://github.com/WebKit/WebKit/commit/dea00c925126ff818ed076d7b0519dd04788cdd8
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-02-07 (Tue, 07 Feb 2023)
Changed paths:
M Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm
Log Message:
-----------
Cherry-pick e0e146fe111c. rdar://problem/104881175
AX: Retain AXTextMarkerRefs and AXTextMarkerRangeRefs passed from the AX thread to the main thread.
https://bugs.webkit.org/show_bug.cgi?id=251451
<rdar://problem/104881175>
Reviewed by Chris Fleizach.
* Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper doAXAttributedStringForTextMarkerRange:spellCheck:]):
(-[WebAccessibilityObjectWrapper _accessibilitySetValue:forAttribute:]):
(-[WebAccessibilityObjectWrapper _indexForTextMarker:]):
(-[WebAccessibilityObjectWrapper textMarkerRangeAtTextMarker:forUnit:]):
(-[WebAccessibilityObjectWrapper lineTextMarkerRangeForTextMarker:forUnit:]):
(-[WebAccessibilityObjectWrapper textMarkerForTextMarker:atUnit:]):
(-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]):
Canonical link: https://commits.webkit.org/259918@main
Canonical link: https://commits.webkit.org/259548.57@safari-7615-branch
Commit: 7aa88db0d137d23f74bd8ea41444510af298dffd
https://github.com/WebKit/WebKit/commit/7aa88db0d137d23f74bd8ea41444510af298dffd
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-02-07 (Tue, 07 Feb 2023)
Changed paths:
M Source/WebCore/accessibility/AXObjectCache.cpp
M Source/WebCore/accessibility/AXObjectCache.h
Log Message:
-----------
Cherry-pick c11d33bb0bb2. rdar://problem/104956200
AX: Object IDs should not be generated with AXTreeStore::generateNewID().
https://bugs.webkit.org/show_bug.cgi?id=251577
<rdar://problem/104956200>
Reviewed by Chris Fleizach.
In the patch for
https://bugs.webkit.org/show_bug.cgi?id=249480
<rdar://problem/103449294>
I erroneously switched the generation of object IDS in the AXObjectCache to use AXTreeStore::generateNewID. This is wrong because generateNewID checks the presence of the ID against the IDs of AX trees and not against object IDs. This patch rectifies this by bringing back AXObjectCache::generateNewObjectID (new name).
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::generateNewObjectID const):
(WebCore::AXObjectCache::getAXID):
* Source/WebCore/accessibility/AXObjectCache.h:
(WebCore::AXObjectCache::objectForID const): No need to pass AXID by reference since it just wraps an unsgined.
Canonical link: https://commits.webkit.org/259922@main
Canonical link: https://commits.webkit.org/259548.58@safari-7615-branch
Commit: 502dc324e696f2e239cd77d41cfde36a7ae29b3d
https://github.com/WebKit/WebKit/commit/502dc324e696f2e239cd77d41cfde36a7ae29b3d
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-02-07 (Tue, 07 Feb 2023)
Changed paths:
A LayoutTests/fast/multicol/nested-columns-out-of-flow-crash-expected.txt
A LayoutTests/fast/multicol/nested-columns-out-of-flow-crash.html
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
Log Message:
-----------
Cherry-pick 256843.7 at webkit-2022.12-embargoed (3b92d70ba3ea). rdar://98438399
Do not skip fragmented flow thread descendents
https://bugs.webkit.org/show_bug.cgi?id=245374
rdar://98438399
Reviewed by Alan Baradlay.
Do not skip fragmented flow thread descendents in initializeFragmentedFlowStateOnInsertion
since its children may have a different state based on the inserted fragmented
flow thread. When a fragmented flow thread is removed there is no effect on the inner
fragmented flow threads so that behaviour is unchenged.
* LayoutTests/fast/multicol/nested-columns-out-of-flow-crash-expected.txt: Added.
* LayoutTests/fast/multicol/nested-columns-out-of-flow-crash.html: Added.
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::setFragmentedFlowStateIncludingDescendants):
(WebCore::RenderObject::initializeFragmentedFlowStateOnInsertion):
* Source/WebCore/rendering/RenderObject.h:
Canonical link: https://commits.webkit.org/256843.7@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/259548.59@safari-7615-branch
Commit: f246e1b5513c23aa8a5a94d0dd690fc15952ee12
https://github.com/WebKit/WebKit/commit/f246e1b5513c23aa8a5a94d0dd690fc15952ee12
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-02-07 (Tue, 07 Feb 2023)
Changed paths:
A LayoutTests/fast/layers/normal-flow-dialog-remove-layer-crash-expected.html
A LayoutTests/fast/layers/normal-flow-dialog-remove-layer-crash.html
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Cherry-pick 256843.8 at webkit-2022.12-embargoed (fe2f16c1dabe). rdar://104134023
Recalculate normal flow value in RenderLayer::establishesTopLayerDidChange
https://bugs.webkit.org/show_bug.cgi?id=251013
Reviewed by Tim Nguyen.
In RenderLayer::rebuildZOrderLists the RenderView layer makes sure the layers for dialogs/top-level elements are appended after
everything else in the positive z-order list. When removing the dialog layer, dirtyPaintOrderListsOnChildChange will be called
and since it is not a normal only flow everything will be handled correctly through dirtyStackingContextZOrderLists.
In the test case the behaviour is the same until dirtyPaintOrderListsOnChildChange is called on the dialog layer removal. Now that
layer to be removed *is* a normal only flow (the element is no longer positioned and has non visible overflow, see
RenderLayer::shouldBeNormalFlowOnly). This means the positive z-order list is unchanged and the deleted layer still part of it.
When the test cleanup code does a final repaint, the RenderView positive z-order list is processed as normal and when trying to
access the deleted layer the UAF happens.
To fix this, make sure the normal flow value is correct when adding the layer in RenderLayer::establishesTopLayerDidChange.
* LayoutTests/fast/layers/normal-flow-dialog-remove-layer-crash-expected.html: Added.
* LayoutTests/fast/layers/normal-flow-dialog-remove-layer-crash.html: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::establishesTopLayerDidChange):
Canonical link: https://commits.webkit.org/256843.8@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/259548.60@safari-7615-branch
Commit: 71ee942bab06e035857ef087c3bd04f686b9421d
https://github.com/WebKit/WebKit/commit/71ee942bab06e035857ef087c3bd04f686b9421d
Author: Claudio Saavedra <csaavedra at igalia.com>
Date: 2023-02-07 (Tue, 07 Feb 2023)
Changed paths:
A LayoutTests/fast/css/content/content-on-focus-change-expected.txt
A LayoutTests/fast/css/content/content-on-focus-change.html
Log Message:
-----------
Cherry-pick 256843.9 at webkit-2022.12-embargoed (4c3dcd480f7e). rdar://104256993
Test display contents change on focus change
https://bugs.webkit.org/show_bug.cgi?id=251014
Reviewed by Tim Nguyen.
* LayoutTests/fast/css/content/content-on-focus-change-expected.txt: Added.
* LayoutTests/fast/css/content/content-on-focus-change.html: Added.
Canonical link: https://commits.webkit.org/256843.9@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/259548.61@safari-7615-branch
Commit: 4c231dda4da0411138110adc4a05450c108752ff
https://github.com/WebKit/WebKit/commit/4c231dda4da0411138110adc4a05450c108752ff
Author: J Pascoe <j_pascoe at apple.com>
Date: 2023-02-08 (Wed, 08 Feb 2023)
Changed paths:
M Source/WebCore/Modules/webauthn/AuthenticatorCoordinator.cpp
M Source/WebCore/Modules/webauthn/AuthenticatorCoordinatorClient.h
M Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp
M Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.h
M Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.messages.in
M Source/WebKit/WebProcess/WebAuthentication/WebAuthenticatorCoordinator.cpp
M Source/WebKit/WebProcess/WebAuthentication/WebAuthenticatorCoordinator.h
Log Message:
-----------
Cherry-pick ba76ae810b9d. rdar://problem/99535627
[WebAuthn] Conditional passkey request presents conditional control even after AbortController.abort()
https://bugs.webkit.org/show_bug.cgi?id=250589
rdar://99535627
Reviewed by Brent Fulgham.
Currently conditional mediation requests do not get cancelled whenever the abort controller for its
request is called. This patch changes that by calling cancel on the daemon whenever the abort controller
is called.
* Source/WebCore/Modules/webauthn/AuthenticatorCoordinator.cpp:
(WebCore::AuthenticatorCoordinator::discoverFromExternalSource):
* Source/WebCore/Modules/webauthn/AuthenticatorCoordinatorClient.h:
* Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp:
(WebKit::WebAuthenticatorCoordinatorProxy::cancel):
* Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.h:
* Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.messages.in:
* Source/WebKit/WebProcess/WebAuthentication/WebAuthenticatorCoordinator.cpp:
(WebKit::WebAuthenticatorCoordinator::cancel):
* Source/WebKit/WebProcess/WebAuthentication/WebAuthenticatorCoordinator.h:
Canonical link: https://commits.webkit.org/259754@main
Canonical link: https://commits.webkit.org/259548.62@safari-7615-branch
Commit: 1b2eb138ef9254764761bf374a9ff717071e61dd
https://github.com/WebKit/WebKit/commit/1b2eb138ef9254764761bf374a9ff717071e61dd
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-02-08 (Wed, 08 Feb 2023)
Changed paths:
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
Log Message:
-----------
[JSC] ToThis object folding should check if AbstractValue is always an object
https://bugs.webkit.org/show_bug.cgi?id=251944
rdar://105175786
Reviewed by Geoffrey Garen and Mark Lam.
ToThis can become Identity for strict mode if it is just primitive values or its object does not have toThis function overriding.
This is correct, but folding ToThis to Undefined etc. (not Identity) needs to check that an input only contains objects.
This patch adds appropriate checks to prevent from converting ToThis(GlobalObject | Int32) to Undefined for example.
* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::isToThisAnIdentity):
Canonical link: https://commits.webkit.org/259548.63@safari-7615-branch
Commit: 073b621aaa39b9423c320372a9939fbed8bb3253
https://github.com/WebKit/WebKit/commit/073b621aaa39b9423c320372a9939fbed8bb3253
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-08 (Wed, 08 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/local/git.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/bitbucket.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/git_hub.py
Log Message:
-----------
Cherry-pick 259959 at main (06835af6148a). rdar://105106632
[webkitscmpy] Speed up files_changed
https://bugs.webkit.org/show_bug.cgi?id=251826
rdar://105106632
Reviewed by Aakash Jain.
Only invoke a repository's 'find' function if the provided
argument is not a hash.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/local/git.py:
(Git.files_changed):
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/bitbucket.py:
(BitBucket.files_changed):
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/git_hub.py:
(GitHub.files_changed):
Canonical link: https://commits.webkit.org/259959@main
Canonical link: https://commits.webkit.org/259548.64@safari-7615-branch
Commit: 01d5044dbe0d289a3a81271a7052fd7a12d88c8f
https://github.com/WebKit/WebKit/commit/01d5044dbe0d289a3a81271a7052fd7a12d88c8f
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-09 (Thu, 09 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitcorepy/setup.py
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py
A Tools/Scripts/libraries/webkitcorepy/webkitcorepy/filtered_call.py
A Tools/Scripts/libraries/webkitcorepy/webkitcorepy/tests/filtered_call_unittest.py
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/__init__.py
Log Message:
-----------
Cherry-pick 259979 at main (3ac8172d4ae6). rdar://105138155
[webkitcorepy] Add filtered_call
https://bugs.webkit.org/show_bug.cgi?id=251872
rdar://105138155
Reviewed by Aakash Jain.
* Tools/Scripts/libraries/webkitcorepy/setup.py: Add inspect2 dependency.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/filtered_call.py: Added.
(filtered_call): Invoke the provided function with the provided arguments, if that function supports
those arguments.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/tests/filtered_call_unittest.py: Added.
(FilteredCallTestCase.function):
(FilteredCallTestCase.test_passthrough):
(FilteredCallTestCase.test_filtered):
* Tools/Scripts/libraries/webkitscmpy/setup.py: Remove inspect2 dependency.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/__init__.py: Use filtered_call
instead of implementing that functionality ourselves.
Canonical link: https://commits.webkit.org/259979@main
Canonical link: https://commits.webkit.org/259548.65@safari-7615-branch
Commit: 6ae1e0a7658a5dadda89bf9f756fd065bfa18ae1
https://github.com/WebKit/WebKit/commit/6ae1e0a7658a5dadda89bf9f756fd065bfa18ae1
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-09 (Thu, 09 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitbugspy/setup.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/github.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/github_unittest.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tracker.py
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/branch.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/branch_unittest.py
Log Message:
-----------
Cherry-pick 260012 at main (69c4012c1ffe). rdar://105153144
[git-webkit] Allow Trackers to hide bug titles
https://bugs.webkit.org/show_bug.cgi?id=251894
rdar://105153144
Reviewed by Aakash Jain.
* Tools/Scripts/libraries/webkitbugspy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py:
(Tracker.Encoder.default):
(Tracker.__init__): Add hide_title member,.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/github.py:
(Tracker.Encoder.default):
(Tracker.__init__): Add hide_title member.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py:
(Tracker.Encoder.default):
(Tracker.__init__): Add hide_title member, True by default.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py:
(TestBugzilla.test_encoding):
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/github_unittest.py:
(TestGitHub.test_encoding):
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py:
(TestRadar.test_encoding):
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tracker.py:
(Tracker.from_json): Decode
(Tracker.__init__): Add hide_title member, False by default.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/branch.py:
(Branch.main): If a Tracker is hiding it's titles, don't encode the title in the branch name.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/branch_unittest.py:
(TestBranch.test_prompt_url):
Canonical link: https://commits.webkit.org/260012@main
Canonical link: https://commits.webkit.org/259548.66@safari-7615-branch
Commit: a3b2b56b98e09a382ee62256952c23b0700ea7b3
https://github.com/WebKit/WebKit/commit/a3b2b56b98e09a382ee62256952c23b0700ea7b3
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-09 (Thu, 09 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pickable.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pickable_unittest.py
Log Message:
-----------
Cherry-pick 260014 at main (314c5c8a883d). rdar://104100860
[git-webkit] Allow multiple refs in pickable
https://bugs.webkit.org/show_bug.cgi?id=250428
rdar://104100860
Reviewed by Aakash Jain.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pickable.py:
(Pickable.parser): Support multiple arguments.
(Pickable.main): Support multiple refs, de-duplicate any pickable commits in
both refs.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pickable_unittest.py:
(TestPickable.test_double): Added.
Canonical link: https://commits.webkit.org/260014@main
Canonical link: https://commits.webkit.org/259548.67@safari-7615-branch
Commit: 549f7c73115eab8546ec1a8a1239f883fd2d0634
https://github.com/WebKit/WebKit/commit/549f7c73115eab8546ec1a8a1239f883fd2d0634
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-09 (Thu, 09 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitbugspy/setup.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/github.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/issue.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/github_unittest.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py
M metadata/trackers.json
Log Message:
-----------
Cherry-pick 260029 at main (1e4df5db1f28). rdar://105180880
[git-webkit] Consider bug classification
https://bugs.webkit.org/show_bug.cgi?id=251933
rdar://105180880
Reviewed by Dewei Zhu.
* Tools/Scripts/libraries/webkitbugspy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py:
(Tracker.populate): Set classification to empty.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/github.py:
(Tracker.populate): Set classification to empty.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/issue.py:
(Issue.__init__): Add classification member.
(Issue.classification): Populate and return classification member.
(Issue.redacted): Include classification in redaction check.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py:
(RadarModel.__init__): Add classification member.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py:
(Tracker.populate): Populate classification from radar.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py:
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/github_unittest.py:
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py:
* metadata/trackers.json:
Canonical link: https://commits.webkit.org/260029@main
Canonical link: https://commits.webkit.org/259548.68@safari-7615-branch
Commit: 4306f12b8a715ee6957ab5a8da914728937e8a56
https://github.com/WebKit/WebKit/commit/4306f12b8a715ee6957ab5a8da914728937e8a56
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-09 (Thu, 09 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/mocks/local/git.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/__init__.py
A Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/publish.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py
A Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/publish_unittest.py
M metadata/git_config_extension
Log Message:
-----------
Cherry-pick 260044 at main (88545c7a8742). <rdar://97397960>
[git-webkit] Add Publish Command
https://bugs.webkit.org/show_bug.cgi?id=249586
<rdar://97397960>
Reviewed by Elliott Williams.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/mocks/local/git.py: Add 'git branch -a --merged'
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/__init__.py:
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/publish.py: Added.
(Publish):
(Publish.parser): User provides command a list of refs to publish.
(Publish.branches_on): List all branches that are on the history of a specified ref.
(Publish.tags_on): List all tags that are on the history of a specified ref.
(Publish.parental_intersection): Find the intersection point of the provided commit and the parent
branch of that commit. Note that the provided commit might be on the parent branch, in which case
this function returns nothing.
(Publish._push_branch_ref): Push a branch ref onto the provided mapping. This function takes into
consideration any existing branch ref of the same name, taking the more up to date of the two.
(Publish.main): Given the refs provided by the user, find all refs on that history and push those refs
to the "next" source remote.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py:
(PullRequest.create_pull_request): Prefer the most secret remote.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/publish_unittest.py: Added.
(TestPublish): Added tests.
* metadata/git_config_extension: Sort source remotes.
Canonical link: https://commits.webkit.org/260044@main
Canonical link: https://commits.webkit.org/259548.69@safari-7615-branch
Commit: 4f0cd71e42b817acf2c4a492719cd5a358a2b478
https://github.com/WebKit/WebKit/commit/4f0cd71e42b817acf2c4a492719cd5a358a2b478
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2023-02-09 (Thu, 09 Feb 2023)
Changed paths:
M Source/WebCore/Modules/webxr/WebXRRigidTransform.cpp
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
M Source/WebCore/platform/graphics/transforms/RotateTransformOperation.cpp
M Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp
M Source/WebCore/platform/graphics/transforms/TransformationMatrix.h
Log Message:
-----------
Fix use of uninitialized memory in TransformationMatrix decompose()
https://bugs.webkit.org/show_bug.cgi?id=247835
<rdar://102263762>
Reviewed by Dean Jackson.
Fixes decompose4 to check for a failing return value from inverse, and early returns, rather
than continuing with the output matrix uninitialized.
Also adds WARN_UNUSED_RETURN to decompose2/4 to ensure that all callers handle this case.
* Source/WebCore/Modules/webxr/WebXRRigidTransform.cpp:
(WebCore::m_rawTransform):
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::computeTransformedExtentViaTransformList const):
(WebCore::KeyframeEffect::computeTransformedExtentViaMatrix const):
* Source/WebCore/platform/graphics/transforms/RotateTransformOperation.cpp:
(WebCore::RotateTransformOperation::blend):
* Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp:
(WebCore::decompose4):
* Source/WebCore/platform/graphics/transforms/TransformationMatrix.h:
Canonical link: https://commits.webkit.org/259548.70@safari-7615-branch
Commit: d0ad85a37b8df44f574b01afa7d83b29b486b7c1
https://github.com/WebKit/WebKit/commit/d0ad85a37b8df44f574b01afa7d83b29b486b7c1
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-09 (Thu, 09 Feb 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/animation/custom-property-animation-list-type-mismatch-expected.txt
A LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/animation/custom-property-animation-list-type-mismatch.html
M Source/WebCore/animation/CSSPropertyAnimation.cpp
Log Message:
-----------
Cherry-pick 259557 at main (30df2fedb438). rdar://104814851
[web-animations] animating two custom property list values with mismatching types should use a discrete animation
https://bugs.webkit.org/show_bug.cgi?id=251351
rdar://104814851
Reviewed by Antti Koivisto.
It is possible for a custom property to animate between two lists of mismatching types, for instance if it's
defined as `<number>+ | <transform-list>`. In that case, we must use discrete blending.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/animation/custom-property-animation-list-type-mismatch-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/animation/custom-property-animation-list-type-mismatch.html: Added.
* Source/WebCore/animation/CSSPropertyAnimation.cpp:
(WebCore::blendSyntaxValueLists):
Canonical link: https://commits.webkit.org/259557@main
Canonical link: https://commits.webkit.org/259548.71@safari-7615-branch
Commit: 355b307a1241480c67ad77778831673e1ebe8392
https://github.com/WebKit/WebKit/commit/355b307a1241480c67ad77778831673e1ebe8392
Author: Nikolaos Mouchtaris <nmouchtaris at apple.com>
Date: 2023-02-09 (Thu, 09 Feb 2023)
Changed paths:
A LayoutTests/css3/scroll-snap/scroll-snap-remove-snap-area-expected.txt
A LayoutTests/css3/scroll-snap/scroll-snap-remove-snap-area.html
M Source/WebCore/platform/ScrollSnapAnimatorState.cpp
M Source/WebCore/platform/ScrollSnapAnimatorState.h
Log Message:
-----------
Cherry-pick 259696 at main (279d12080527). rdar://104816359
[css-scroll-snap] Have ScrollSnapAnimatorState calculate the HashSet of currently snapped boxes immediately
https://bugs.webkit.org/show_bug.cgi?id=251449
rdar://104816359
Reviewed by Simon Fraser.
The added test css3/scroll-snap/scroll-snap-remove-snap-area.html exposes a bug where removing a snap
area while we are currently snapped to multiple boxes will cause the state in the offsets stored in
m_currentlySnappedBoxesX and m_currentlySnappedBoxesY to become out of sync with the state
in m_snapOffsetsInfo. To resolve this, run currentlySnappedBoxes immediately and store its
result, rather than running it when we are no no longer snapped to multiple boxes, where the
state in m_currentlySnappedBoxesX and m_currentlySnappedBoxesY could be stale.
* Source/WebCore/platform/ScrollSnapAnimatorState.cpp:
(WebCore::ScrollSnapAnimatorState::currentlySnappedBoxes const):
(WebCore::ScrollSnapAnimatorState::chooseBoxToResnapTo const):
(WebCore::ScrollSnapAnimatorState::resnapAfterLayout):
(WebCore::isSnappedToMultipleBoxes): Deleted.
* Source/WebCore/platform/ScrollSnapAnimatorState.h:
Canonical link: https://commits.webkit.org/259696@main
Canonical link: https://commits.webkit.org/259548.72@safari-7615-branch
Commit: de0018029cb779afa5f239007d90b4ef969a8c35
https://github.com/WebKit/WebKit/commit/de0018029cb779afa5f239007d90b4ef969a8c35
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-02-09 (Thu, 09 Feb 2023)
Changed paths:
A JSTests/wasm/stress/init-expr-ref-null-function-index-space-for-validation.js
A JSTests/wasm/stress/resources/init-expr-ref-null-function-index-space-for-validation.wasm
M Source/JavaScriptCore/wasm/WasmSectionParser.cpp
Log Message:
-----------
Cherry-pick 259715 at main (ffba415d759f). rdar://104911237
[JSC] ref.func in init-expr should be validated with function-index-space
https://bugs.webkit.org/show_bug.cgi?id=251542
rdar://104911237
Reviewed by Mark Lam.
Use functionIndexSpaceSize for validation for ref.func in init-expr, since ref.func takes functionIndexSpace.
Note that functionIndexSpaceSize is always larger than functionIndex's size. We were wrongly rejecting valid
ref.func via validation.
* JSTests/wasm/stress/init-expr-ref-null-function-index-space-for-validation.js: Added.
(shouldBe):
(async let):
* JSTests/wasm/stress/resources/init-expr-ref-null-function-index-space-for-validation.wasm: Added.
* Source/JavaScriptCore/wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseInitExpr):
Canonical link: https://commits.webkit.org/259715@main
Canonical link: https://commits.webkit.org/259548.73@safari-7615-branch
Commit: 25cddfa8233595e8b0a670ca7b69d13ce60e4747
https://github.com/WebKit/WebKit/commit/25cddfa8233595e8b0a670ca7b69d13ce60e4747
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/mathml/mathml-mover-layout-crash-expected.txt
A LayoutTests/mathml/mathml-mover-layout-crash.html
M LayoutTests/platform/glib/imported/w3c/web-platform-tests/mathml/relations/html5-tree/dynamic-childlist-002-expected.txt
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp
Log Message:
-----------
Fix layout for positioned children for RenderMathMLUnderOver
rdar://105071050
Reviewed by Alan Baradlay.
Before this change, the layout method in RenderMathMLUnderOver (<mover>) never
added positioned elements to the map for their container, which meant if
the positioned children are dirty, their layout will never be triggered.
This change fixes that by looking at direct children of
RenderMathMLUnderOver and adding them to their container's positioned
elements map, so that their layout happens as expected.
* LayoutTests/mathml/mathml-mover-layout-crash-expected.txt: Added.
* LayoutTests/mathml/mathml-mover-layout-crash.html: Added.
* Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:
(WebCore::RenderMathMLUnderOver::layoutBlock):
* LayoutTests/platform/glib/imported/w3c/web-platform-tests/mathml/relations/html5-tree/dynamic-childlist-002-expected.txt:
* LayoutTests/platform/mac-wk2/TestExpectations:
Canonical link: https://commits.webkit.org/259548.74@safari-7615-branch
Commit: 22b0e73428bb4dbe8f4cb4fbc1b45e1016433178
https://github.com/WebKit/WebKit/commit/22b0e73428bb4dbe8f4cb4fbc1b45e1016433178
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/page/scrolling/ScrollingTree.cpp
M Source/WebCore/page/scrolling/ScrollingTree.h
M Source/WebCore/page/scrolling/ScrollingTreeFixedNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeFixedNode.h
M Source/WebCore/page/scrolling/ScrollingTreeFrameHostingNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeFrameHostingNode.h
M Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.h
M Source/WebCore/page/scrolling/ScrollingTreeNode.h
M Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.h
M Source/WebCore/page/scrolling/ScrollingTreePositionedNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreePositionedNode.h
M Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.h
M Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeStickyNode.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeFixedNodeCocoa.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeFixedNodeCocoa.mm
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeOverflowScrollProxyNodeCocoa.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeOverflowScrollProxyNodeCocoa.mm
M Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNodeCocoa.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNodeCocoa.mm
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.mm
M Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h
M Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm
M Source/WebCore/page/scrolling/mac/ScrollingTreeOverflowScrollingNodeMac.h
M Source/WebCore/page/scrolling/mac/ScrollingTreeOverflowScrollingNodeMac.mm
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeFixedNodeNicosia.cpp
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeFixedNodeNicosia.h
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeFrameScrollingNodeNicosia.cpp
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeFrameScrollingNodeNicosia.h
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeOverflowScrollProxyNodeNicosia.cpp
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeOverflowScrollProxyNodeNicosia.h
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeOverflowScrollingNodeNicosia.cpp
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeOverflowScrollingNodeNicosia.h
M Source/WebCore/page/scrolling/nicosia/ScrollingTreePositionedNodeNicosia.cpp
M Source/WebCore/page/scrolling/nicosia/ScrollingTreePositionedNodeNicosia.h
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeStickyNodeNicosia.cpp
M Source/WebCore/page/scrolling/nicosia/ScrollingTreeStickyNodeNicosia.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeFrameScrollingNodeRemoteIOS.h
M Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeFrameScrollingNodeRemoteIOS.mm
M Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.h
M Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.mm
M Source/WebKit/UIProcess/RemoteLayerTree/mac/ScrollingTreeFrameScrollingNodeRemoteMac.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/mac/ScrollingTreeFrameScrollingNodeRemoteMac.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/ScrollingTreeOverflowScrollingNodeRemoteMac.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/mac/ScrollingTreeOverflowScrollingNodeRemoteMac.h
Log Message:
-----------
[CoreIPC] Type confusion bug in ScrollingTree::updateTreeFromStateNodeRecursive
https://bugs.webkit.org/show_bug.cgi?id=251969
rdar://102603165
Reviewed by Ryosuke Niwa.
Make sure we type-check before all the downcast<> calls in code under scrolling tree commits.
If a type-check fails, MESSAGE_CHECK in RemoteScrollingCoordinatorProxy::commitScrollingTree().
commitStateBeforeChildren() and commitStateAfterChildren() on all the scrolling tree node classes
now return bool, indicating success or failure.
* Source/WebCore/page/scrolling/ScrollingTree.cpp:
(WebCore::ScrollingTree::commitTreeState):
(WebCore::ScrollingTree::updateTreeFromStateNodeRecursive):
* Source/WebCore/page/scrolling/ScrollingTree.h:
* Source/WebCore/page/scrolling/ScrollingTreeFixedNode.cpp:
(WebCore::ScrollingTreeFixedNode::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/ScrollingTreeFixedNode.h:
* Source/WebCore/page/scrolling/ScrollingTreeFrameHostingNode.cpp:
(WebCore::ScrollingTreeFrameHostingNode::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/ScrollingTreeFrameHostingNode.h:
* Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.cpp:
(WebCore::ScrollingTreeFrameScrollingNode::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/ScrollingTreeFrameScrollingNode.h:
* Source/WebCore/page/scrolling/ScrollingTreeNode.h:
(WebCore::ScrollingTreeNode::commitStateAfterChildren):
* Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.cpp:
(WebCore::ScrollingTreeOverflowScrollProxyNode::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/ScrollingTreeOverflowScrollProxyNode.h:
* Source/WebCore/page/scrolling/ScrollingTreePositionedNode.cpp:
(WebCore::ScrollingTreePositionedNode::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/ScrollingTreePositionedNode.h:
* Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.cpp:
(WebCore::ScrollingTreeScrollingNode::commitStateBeforeChildren):
(WebCore::ScrollingTreeScrollingNode::commitStateAfterChildren):
* Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.h:
* Source/WebCore/page/scrolling/ScrollingTreeStickyNode.cpp:
(WebCore::ScrollingTreeStickyNode::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/ScrollingTreeStickyNode.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeFixedNodeCocoa.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeFixedNodeCocoa.mm:
(WebCore::ScrollingTreeFixedNodeCocoa::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeOverflowScrollProxyNodeCocoa.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeOverflowScrollProxyNodeCocoa.mm:
(WebCore::ScrollingTreeOverflowScrollProxyNodeCocoa::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNodeCocoa.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNodeCocoa.mm:
(WebCore::ScrollingTreePositionedNodeCocoa::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.mm:
(WebCore::ScrollingTreeStickyNodeCocoa::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h:
* Source/WebCore/page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm:
(WebCore::ScrollingTreeFrameScrollingNodeMac::commitStateBeforeChildren):
(WebCore::ScrollingTreeFrameScrollingNodeMac::commitStateAfterChildren):
* Source/WebCore/page/scrolling/mac/ScrollingTreeOverflowScrollingNodeMac.h:
* Source/WebCore/page/scrolling/mac/ScrollingTreeOverflowScrollingNodeMac.mm:
(WebCore::ScrollingTreeOverflowScrollingNodeMac::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeFixedNodeNicosia.cpp:
(WebCore::ScrollingTreeFixedNodeNicosia::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeFixedNodeNicosia.h:
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeFrameScrollingNodeNicosia.cpp:
(WebCore::ScrollingTreeFrameScrollingNodeNicosia::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeFrameScrollingNodeNicosia.h:
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeOverflowScrollProxyNodeNicosia.cpp:
(WebCore::ScrollingTreeOverflowScrollProxyNodeNicosia::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeOverflowScrollProxyNodeNicosia.h:
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeOverflowScrollingNodeNicosia.cpp:
(WebCore::ScrollingTreeOverflowScrollingNodeNicosia::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeOverflowScrollingNodeNicosia.h:
* Source/WebCore/page/scrolling/nicosia/ScrollingTreePositionedNodeNicosia.cpp:
(WebCore::ScrollingTreePositionedNodeNicosia::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/nicosia/ScrollingTreePositionedNodeNicosia.h:
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeStickyNodeNicosia.cpp:
(WebCore::ScrollingTreeStickyNodeNicosia::commitStateBeforeChildren):
* Source/WebCore/page/scrolling/nicosia/ScrollingTreeStickyNodeNicosia.h:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp:
(WebKit::RemoteScrollingCoordinatorProxy::commitScrollingTreeState):
* Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeFrameScrollingNodeRemoteIOS.h:
* Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeFrameScrollingNodeRemoteIOS.mm:
(WebKit::ScrollingTreeFrameScrollingNodeRemoteIOS::commitStateBeforeChildren):
(WebKit::ScrollingTreeFrameScrollingNodeRemoteIOS::commitStateAfterChildren):
* Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.h:
* Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.mm:
(WebKit::ScrollingTreeOverflowScrollingNodeIOS::commitStateBeforeChildren):
(WebKit::ScrollingTreeOverflowScrollingNodeIOS::commitStateAfterChildren):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/ScrollingTreeFrameScrollingNodeRemoteMac.cpp:
(WebKit::ScrollingTreeFrameScrollingNodeRemoteMac::commitStateBeforeChildren):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/ScrollingTreeFrameScrollingNodeRemoteMac.h:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/ScrollingTreeOverflowScrollingNodeRemoteMac.cpp:
(WebKit::ScrollingTreeOverflowScrollingNodeRemoteMac::commitStateBeforeChildren):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/ScrollingTreeOverflowScrollingNodeRemoteMac.h:
Canonical link: https://commits.webkit.org/259548.75@safari-7615-branch
Commit: d89aa236414e79a601e75bcbbfc6bec82dbedb02
https://github.com/WebKit/WebKit/commit/d89aa236414e79a601e75bcbbfc6bec82dbedb02
Author: Justin Michaud <justin at justinmichaud.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A JSTests/wasm/stress/simd-import-global-2.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/wasm/WasmGlobal.h
M Source/JavaScriptCore/wasm/js/JSWebAssemblyArray.h
M Source/JavaScriptCore/wasm/js/JSWebAssemblyGlobal.cpp
M Source/JavaScriptCore/wasm/js/JSWebAssemblyHelpers.h
M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp
M Source/JavaScriptCore/wasm/js/WebAssemblyGlobalConstructor.cpp
M Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp
Log Message:
-----------
Cherry-pick 259791 at main (18a076e402b4). rdar://104745582
Importing an exported v128 global should be possible
https://bugs.webkit.org/show_bug.cgi?id=251551
rdar://104745582
Reviewed by Mark Lam.
We missed a case here, let's just fix it.
* JSTests/wasm/stress/simd-import-global-2.js: Added.
(from.string_appeared_here.import.as.assert.from.string_appeared_here.async test):
* Source/JavaScriptCore/wasm/WasmGlobal.h:
* Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::initializeImports):
Canonical link: https://commits.webkit.org/259791@main
Canonical link: https://commits.webkit.org/259548.76@safari-7615-branch
Commit: d832dc8e0b666dba8abca591c9defcbb74448f94
https://github.com/WebKit/WebKit/commit/d832dc8e0b666dba8abca591c9defcbb74448f94
Author: Patrick Angle <pangle at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/UIProcess/Automation/mac/WebAutomationSessionMac.mm
Log Message:
-----------
Cherry-pick 260110 at main (364e72b3d3f5). rdar://105218538
WebDriver: Regression(STP 163) Many keyboard-related WPT tests fail/error
https://bugs.webkit.org/show_bug.cgi?id=251957
rdar://105218538
Reviewed by Ryosuke Niwa and Chris Dumez.
Correct local variables to be initialized to nil since not all paths may do so.
* Source/WebKit/UIProcess/Automation/mac/WebAutomationSessionMac.mm:
(WebKit::WebAutomationSession::platformSimulateKeyboardInteraction):
Canonical link: https://commits.webkit.org/260110@main
Canonical link: https://commits.webkit.org/259548.77@safari-7615-branch
Commit: a4202f6cb63a6b4675a7ae6d54aba422c33625a5
https://github.com/WebKit/WebKit/commit/a4202f6cb63a6b4675a7ae6d54aba422c33625a5
Author: Russell Epstein <repstein at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance.html
M Source/WebCore/style/StyleBuilderCustom.h
Log Message:
-----------
Cherry-pick 06e3540a49d. rdar://problem/104998661
[css-properties-values-api] non-inherited custom property fails to inherit from parent when "inherit" is set
https://bugs.webkit.org/show_bug.cgi?id=251590
Reviewed by Antti Koivisto.
We would only look at the map of inherited custom properties when applying the "inherit" value
for a custom property. However, a non-inherited value should also use its parent's value in that
case.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance.html:
* Source/WebCore/style/StyleBuilderCustom.h:
(WebCore::Style::BuilderCustom::applyInheritCustomProperty):
Canonical link: https://commits.webkit.org/259809@main
Canonical link: https://commits.webkit.org/259548.78@safari-7615-branch
Commit: 3d5c2f229370db717290f2fc8b1b3d5ba35a4cb2
https://github.com/WebKit/WebKit/commit/3d5c2f229370db717290f2fc8b1b3d5ba35a4cb2
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A JSTests/wasm/stress/only-referenced.js
A JSTests/wasm/stress/resources/only-referenced.wasm
M Source/JavaScriptCore/wasm/WasmBBQPlan.cpp
M Source/JavaScriptCore/wasm/WasmLLIntPlan.cpp
M Source/JavaScriptCore/wasm/WasmModuleInformation.h
M Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp
Log Message:
-----------
Cherry-pick 259702 at main (63e3817996f2). rdar://104912723
[JSC] Referenced function is functionIndexSpace
https://bugs.webkit.org/show_bug.cgi?id=251522
rdar://104912723
Reviewed by Tadeu Zagallo.
Wasm Referenced functions are managed via functionIndexSpace, but we are querying to it via functionIndex, which is wrong.
This patch fixes it.
* JSTests/wasm/stress/only-referenced.js: Added.
(async let):
* JSTests/wasm/stress/resources/only-referenced.wasm: Added.
* Source/JavaScriptCore/wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::compileFunction):
* Source/JavaScriptCore/wasm/WasmLLIntPlan.cpp:
(JSC::Wasm::LLIntPlan::didCompleteCompilation):
* Source/JavaScriptCore/wasm/WasmModuleInformation.h:
(JSC::Wasm::ModuleInformation::hasReferencedFunction const):
(JSC::Wasm::ModuleInformation::addReferencedFunction const):
(JSC::Wasm::ModuleInformation::callCanClobberInstance const):
(JSC::Wasm::ModuleInformation::addClobberingTailCall):
* Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::initializeExports):
Canonical link: https://commits.webkit.org/259702@main
Canonical link: https://commits.webkit.org/259548.79@safari-7615-branch
Commit: fe14d02703d243cbc9ea863ed3cbc7ca18a56fef
https://github.com/WebKit/WebKit/commit/fe14d02703d243cbc9ea863ed3cbc7ca18a56fef
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/Platform/IPC/cocoa/ConnectionCocoa.mm
M Tools/TestWebKitAPI/Tests/IPC/ConnectionTests.cpp
Log Message:
-----------
Cherry-pick e11ee9df88e6. rdar://problem/104576815
[ iOS Debug ] fast/loader/crash-replacing-location-before-load.html is a flaky crash
https://bugs.webkit.org/show_bug.cgi?id=251047
rdar://104576815
Reviewed by Matt Woodrow.
New connections for, say remote rendering backend, are sent through
WP -> GPUP main connection.
The new connection might be closed before the receiver receives it.
In this case, on Cocoa, the underlying connection Mach send right is
read from the kernel as MACH_PORT_DEAD during Mach message receipt.
Consider sequence:
... Runloop processing
A
Decode a message
B
Create connection from the port inside the message
C
... Runloop processing
For IPC::Connection programming model, there is no difference
whether the sender closes the port at A, B or C. Make A behave
identical to already working B and C, e.g. deliver normal "connection
did close" signal.
Treat PORT_DEAD as a valid IPC::Connection client send right.
Construct the receive port as usual, but do not send the server
send right anywhere, as it cannot be sent to DEAD port. When the server
send right is destroyed, the receive port is notified that the sender
went away. This is obtains the common codepath for connection operation
for dead names.
* Source/WebKit/Platform/IPC/cocoa/ConnectionCocoa.mm:
(IPC::Connection::platformInvalidate):
(IPC::Connection::cancelSendSource):
(IPC::Connection::platformInitialize):
(IPC::Connection::platformOpen):
(IPC::Connection::sendOutgoingMessage):
(IPC::Connection::initializeSendSource):
* Tools/TestWebKitAPI/Tests/IPC/ConnectionTests.cpp:
(TestWebKitAPI::MockTestMessageWithConnection::name):
(TestWebKitAPI::MockTestMessageWithConnection::arguments):
(TestWebKitAPI::MockTestMessageWithConnection::MockTestMessageWithConnection):
(TestWebKitAPI::TEST_P):
Canonical link: https://commits.webkit.org/259582@main
Canonical link: https://commits.webkit.org/259548.80@safari-7615-branch
Commit: 73e157607b8a9fbaec0856bd5db6a4623768b018
https://github.com/WebKit/WebKit/commit/73e157607b8a9fbaec0856bd5db6a4623768b018
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/platform/animation/TimingFunction.h
Log Message:
-----------
Cherry-pick 8f690bd4d728. rdar://problem/104822225
imported/w3c/web-platform-tests/css/css-transitions/parsing/transition-timing-function-computed.html crashes (libc++ assertions)
https://bugs.webkit.org/show_bug.cgi?id=251352
Reviewed by Antti Koivisto and Chris Dumez.
We have a `m_stepPosition == otherSteps.m_stepPosition` check in TimingFunction::operator==(const TimingFunction&) which would
catch the case where both m_stepPosition and otherSteps.m_stepPosition, which are std::optional<>, would not hold a value.
However, we would hit a recently-enabled libc++ assertion (see bug 245692) because of the check
`*m_stepPosition == StepPosition::End && !otherSteps.m_stepPosition`. Indeed, it is possible for otherSteps.m_stepPosition to
hold a value while m_stepPosition does not.
We simply reverse the two clauses such that we test `!otherSteps.m_stepPosition` first since we already know from earlier
that `otherSteps.m_stepPosition` and `m_stepPosition` cannot both not hold a value.
* Source/WebCore/platform/animation/TimingFunction.h:
Canonical link: https://commits.webkit.org/259559@main
Canonical link: https://commits.webkit.org/259548.81@safari-7615-branch
Commit: 01bbe60340bcc77ae3d9abfa812cd3cd2729cce0
https://github.com/WebKit/WebKit/commit/01bbe60340bcc77ae3d9abfa812cd3cd2729cce0
Author: Ben Nham <nham at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/Modules/push-api/PushDatabase.cpp
Log Message:
-----------
Cherry-pick b97e13eff45f. rdar://problem/104806715
Exclude PushDatabase from backup
https://bugs.webkit.org/show_bug.cgi?id=251343
rdar://104806715
Reviewed by Youenn Fablet.
We should avoid backing up the web push database since it contains state like endpoints and keys
that shouldn't be shared across devices.
We do this at migration time to avoid calling setExcludedFromBackup on every DB open operation.
* Source/WebCore/Modules/push-api/PushDatabase.cpp:
(WebCore::openAndMigrateDatabaseImpl):
Canonical link: https://commits.webkit.org/259563@main
Canonical link: https://commits.webkit.org/259548.82@safari-7615-branch
Commit: 25836573b8c16c8dad31fc5bf72bcfb2b9e08f21
https://github.com/WebKit/WebKit/commit/25836573b8c16c8dad31fc5bf72bcfb2b9e08f21
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/JavaScriptCore/wasm/WasmBBQPlan.cpp
M Source/JavaScriptCore/wasm/WasmOMGPlan.cpp
Log Message:
-----------
Cherry-pick 93f3d4272ced. rdar://problem/104795248
[JSC] Fix recursive call's wasm repatch
https://bugs.webkit.org/show_bug.cgi?id=251333
rdar://104795248
Reviewed by Tadeu Zagallo.
We had a long-standing bug that we failed to repatch the recursive self-calls.
This is because,
1. We first repatch our calls of BBQ / OMG callee. This will get entrypoint from CalleeGroup. But for the self call, this will get old one.
So, we repatch with that.
2. Old Plan::.updateCallsitesToCallUs iterated all callees. But at that time, this newly created callee is not registered yet, so this does
not update the (1)'s callsites.
3. Now, registers this new callee. So (1)'s callsites still point to the old callee's code for recursive calls.
But fortunately, we now factor out these iteration code etc. to CallsiteCollection. And we can easily register (1)'s callee to the repatch
target by just calling addCallsites before calling updateCallsitesToCallUs. This patch just does it.
* Source/JavaScriptCore/wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::work):
* Source/JavaScriptCore/wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
Canonical link: https://commits.webkit.org/259568@main
Canonical link: https://commits.webkit.org/259548.83@safari-7615-branch
Commit: a22ed374bc31d41389610030c4ccfbddc6a7eb5c
https://github.com/WebKit/WebKit/commit/a22ed374bc31d41389610030c4ccfbddc6a7eb5c
Author: Przemyslaw Gorszkowski <pgorszkowski at igalia.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp
Log Message:
-----------
Cherry-pick b69cf1887dfb. rdar://problem/103416260
Remove item from cache of SQLiteStorageArea
https://bugs.webkit.org/show_bug.cgi?id=250559
Reviewed by Sihui Liu.
When Storage.removeItem method from Storage API is called,
the cached value in SQLiteStorageArea should be also removed.
It prevents increase the memory usage by network process.
* Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp:
(WebKit::SQLiteStorageArea::removeItem):
Canonical link: https://commits.webkit.org/259570@main
Canonical link: https://commits.webkit.org/259548.84@safari-7615-branch
Commit: 5c6d3164370bd83fbab7adc904b8e0097bc0b332
https://github.com/WebKit/WebKit/commit/5c6d3164370bd83fbab7adc904b8e0097bc0b332
Author: Darin Adler <darin at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/inspector/InspectorCanvas.cpp
M Source/WebCore/inspector/InspectorCanvas.h
M Source/WebCore/inspector/InspectorShaderProgram.cpp
M Source/WebCore/inspector/InspectorShaderProgram.h
M Source/WebCore/inspector/agents/InspectorCanvasAgent.cpp
M Source/WebKit/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h
Log Message:
-----------
Cherry-pick 37f282e65d2e. rdar://problem/104809022
Unnecessarily using std::variant and std::monostate when we could just use nullptr instead
https://bugs.webkit.org/show_bug.cgi?id=251346
rdar://problem/104809022
Reviewed by Patrick Angle.
Using std::variant, std::reference_wrapper, and std::monostate is like a pointer, but less
efficient. Using std::optional and std::reference_wrapper is the same. Found places in our
code where we did that and removed them. Also updated one place that used std::reference_wrapper
where a reference would work just as well.
* Source/WebCore/inspector/InspectorCanvas.cpp:
(WebCore::InspectorCanvas::canvasContext const): Moved to the header since it's now trivial.
(WebCore::InspectorCanvas::canvasElement const): Removed the switchOn since m_context is now
a reference rather than a variant.
(WebCore::InspectorCanvas::scriptExecutionContext const): Ditto.
(WebCore::InspectorCanvas::resolveContext const): Ditto.
(WebCore::InspectorCanvas::clientNodes const): Ditto.
(WebCore::InspectorCanvas::canvasChanged): Ditto.
(WebCore::InspectorCanvas::resetRecordingData): Ditto.
(WebCore::InspectorCanvas::recordAction): Ditto.
(WebCore::InspectorCanvas::buildObjectForCanvas): Ditto.
(WebCore::InspectorCanvas::releaseObjectForRecording): Ditto.
(WebCore::InspectorCanvas::buildInitialState): Ditto.
* Source/WebCore/inspector/InspectorCanvas.h: Removed some unneded includes. Use
CanvasRenderingContext& for m_context.
* Source/WebCore/inspector/InspectorShaderProgram.cpp: Removed redundant checks of
(WebCore::InspectorShaderProgram::program const): Moved to the header since it's now
trivial.
(WebCore::InspectorShaderProgram::requestShaderSource): Removed the switchOn since m_program
is now a reference rather than a variant. Also changed to use early return, WebKit style.
(WebCore::InspectorShaderProgram::updateShader): Ditto.
(WebCore::InspectorShaderProgram::buildObjectForShaderProgram): Removed the code that looked
at m_program entirely, since it did't do anything.
* Source/WebCore/inspector/InspectorShaderProgram.h: Removed redundant checks of
m_program.
* Source/WebCore/inspector/agents/InspectorCanvasAgent.cpp:
(WebCore::InspectorCanvasAgent::startRecording): Updated since InspectorCanvas::canvasContext
now returns a reference.
(WebCore::InspectorCanvasAgent::stopRecording): Ditto.
(WebCore::InspectorCanvasAgent::recordAction): Ditto.
(WebCore::InspectorCanvasAgent::reset): Ditto.
(WebCore::InspectorCanvasAgent::unbindCanvas): Ditto.
(WebCore::InspectorCanvasAgent::findInspectorCanvas): Ditto.
(WebCore::InspectorCanvasAgent::findInspectorProgram): Updated since
InspectorShaderProgram::program now returns a reference.
* Source/WebKit/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm:
(WebKit::WebsiteDataStore::managedDomainsIfInitialized): Return a pointer.
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:
(WebKit::WebsiteDataStore::forwardManagedDomainsToITPIfInitialized): Updated since
managedDomainsIfInitialized now returns a pointer.
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h: Updated.
Canonical link: https://commits.webkit.org/259572@main
Canonical link: https://commits.webkit.org/259548.85@safari-7615-branch
Commit: 8ee3962b5b97ace7b10b77e426b853ae7495eb15
https://github.com/WebKit/WebKit/commit/8ee3962b5b97ace7b10b77e426b853ae7495eb15
Author: Patrick Angle <pangle at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/UIProcess/Automation/ios/WebAutomationSessionIOS.mm
M Source/WebKit/UIProcess/_WKTouchEventGenerator.h
M Source/WebKit/UIProcess/_WKTouchEventGenerator.mm
Log Message:
-----------
Cherry-pick a670e7900b4a. rdar://problem/102439701
WebDriver: [iPadOS] Synthetic tap events are not dispatched to the window
https://bugs.webkit.org/show_bug.cgi?id=251299
rdar://102439701
Reviewed by BJ Burg.
On iPadOS, the UIApplication.sharedApplication.keyWindow does not take Scenes into account, and can therefore result in
unexpected behavior when used to determine the frontmost window, namely that the returned window may not even be visible
on screen, but instead might be the "key" window from another Scene that the application has. This causes us to be
unable to get the `contextId` of the correct window, which means touch events were not being dispatched to the window
under automation. Instead of relying on the window under automation being implicitly the key window, clients should
instead provide the window in which they expect an event to take place so that _WKTouchEventGenerator can use that
window's `contextId` for created events, ensuring they are dispatched to the correct window.
iOS was unaffected because Safari does not spawn multiple scenes on that platform, which means the key window was
already accurate for that platform.
* Source/WebKit/UIProcess/Automation/ios/WebAutomationSessionIOS.mm:
- Provide the window that is the target for the touch events.
(WebKit::WebAutomationSession::platformSimulateTouchInteraction):
* Source/WebKit/UIProcess/_WKTouchEventGenerator.h:
* Source/WebKit/UIProcess/_WKTouchEventGenerator.mm:
(-[_WKTouchEventGenerator _sendHIDEvent:window:]):
(-[_WKTouchEventGenerator _sendMarkerHIDEventInWindow:completionBlock:]):
- Get the `contextId` from the provided window, instead of always using the `keyWindow`.
(-[_WKTouchEventGenerator _updateTouchPoints:count:window:]):
(-[_WKTouchEventGenerator touchDownAtPoints:touchCount:window:]):
(-[_WKTouchEventGenerator touchDown:touchCount:window:]):
(-[_WKTouchEventGenerator liftUpAtPoints:touchCount:window:]):
(-[_WKTouchEventGenerator liftUp:touchCount:window:]):
(-[_WKTouchEventGenerator moveToPoints:touchCount:duration:window:]):
(-[_WKTouchEventGenerator touchDown:window:completionBlock:]):
(-[_WKTouchEventGenerator liftUp:window:completionBlock:]):
(-[_WKTouchEventGenerator moveToPoint:duration:window:completionBlock:]):
- Plumb the window through.
(-[_WKTouchEventGenerator touchDown:]): Deleted.
(-[_WKTouchEventGenerator liftUp:]): Deleted.
- Remove unused methods.
Canonical link: https://commits.webkit.org/259576@main
Canonical link: https://commits.webkit.org/259548.86@safari-7615-branch
Commit: cd8feca07bf24e28da4cc0c673db6794cb5f3b19
https://github.com/WebKit/WebKit/commit/cd8feca07bf24e28da4cc0c673db6794cb5f3b19
Author: Alexey Shvayka <ashvayka at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/html/HTMLFieldSetElement.cpp
Log Message:
-----------
Cherry-pick f4d8caebb352. rdar://problem/104762152
REGRESSION(259372 at main): ASSERTION FAILED: !m_disabledFieldsetElementsCount on fast/forms/fieldset/fieldset-elements.html
https://bugs.webkit.org/show_bug.cgi?id=251296
Reviewed by Ryosuke Niwa.
With this change, addDisabledFieldsetElement() / removeDisabledFieldsetElement() are called
only when "disabled" attribute is added or removed, ignoring cases when its value is changed,
fixing Document::m_disabledFieldsetElementsCount to be always correct.
* Source/WebCore/html/HTMLFieldSetElement.cpp:
(WebCore::HTMLFieldSetElement::parseAttribute):
Canonical link: https://commits.webkit.org/259580@main
Canonical link: https://commits.webkit.org/259548.87@safari-7615-branch
Commit: e6b3e520f96cd7237919d015dc6a61d1af844c99
https://github.com/WebKit/WebKit/commit/e6b3e520f96cd7237919d015dc6a61d1af844c99
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/platform/graphics/Icon.h
M Source/WebCore/platform/graphics/cocoa/IconCocoa.mm
M Source/WebCore/platform/graphics/mac/IconMac.mm
M Source/WebCore/rendering/RenderThemeMac.mm
M Source/WebKit/Shared/Cocoa/WebIconUtilities.h
M Source/WebKit/Shared/Cocoa/WebIconUtilities.mm
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClientCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKitLegacy/mac/WebCoreSupport/WebOpenPanelResultListener.mm
Log Message:
-----------
Cherry-pick bf1b77633553. rdar://problem/103533427
REGRESSION (255355 at main): HTML Notes: Attachment thumbnails are low resolution
https://bugs.webkit.org/show_bug.cgi?id=251293
rdar://103533427
Reviewed by Wenson Hsieh.
In the process of supporting thumbnails for <input type=file> on macOS,
255355 at main refactored `Icon` logic to share code between Cocoa platforms.
Prior to 255355 at main, `Icon` was backed by `NSImage` on macOS, and `CGImageRef`
on other platforms. Following the change, `Icon` was backed by `CGImageRef` on
all platforms. To make this possible, `NSImage`s were converted to `CGImageRef`s
using `-[NSImage CGImageForProposedRect:context:hints]`, using a `nil` proposed
rect. This approach is problematic, as `NSImage`s are resolution-independent,
whereas `CGImageRef`s are not.
The `NSWorkspace` method used to get attachment thumbnails returns an `NSImage`
with multiple `NSImageRep`s. Before 255355 at main, WebKit would draw the `NSImage`
into a 400x400 bitmap. Now, the `NSImage` is first converted into a `CGImageRef`,
defaulting to the smallest supported representation of 32x32. That image is then
drawn into a 400x400 bitmap, resulting in low resolution.
To fix, store images in `Icon` as `NSImage`/`UIImage` and only resolve them to
`CGImageRef` when it is time to paint them. An alternate solution would be to
pass in the proposed size through multiple layers, so that
`-[NSImage CGImageForProposedRect:context:hints]` could be called with the
correct rect following the retrieval of the image from `NSWorkspace`.
However, the approach in this patch was chosen since it reduces the amount of
plumbing required, avoids conversion to `UIImage` in multiple locations in
existing iOS code, and gives clients of `Icon` more control over how they want
to present the image.
Additionally, this change removes deprecated "flippedness" logic for images.
Attachment thumbnails unnecessarily modify the "flippedness" of the image in
the UIProcess, only to undo the effect in the WebProcess. <input type=file>
thumbnails already do the right thing. It does not make sense to reintroduce the
concept of "flippedness" to `Icon` (as was the case before 255355 at main), since
it would break <input type=file> thumbnails and directory attachment thumbnails
(which have their own flipping logic, separate from files). Instead, the code
is refactored to ignore the concept of "flippedness" entirely, which AppKit
deprecated for images in macOS 10.6.
* Source/WebCore/platform/graphics/Icon.h:
(WebCore::Icon::image const):
* Source/WebCore/platform/graphics/cocoa/IconCocoa.mm:
(WebCore::Icon::Icon):
(WebCore::Icon::create):
(WebCore::Icon::paint):
(WebCore::Icon::createIconForImage): Deleted.
* Source/WebCore/platform/graphics/mac/IconMac.mm:
(WebCore::Icon::createIconForFiles):
(WebCore::Icon::createIconForFileExtension):
(WebCore::Icon::createIconForUTI):
* Source/WebCore/rendering/RenderThemeMac.mm:
(WebCore::RenderThemeMac::iconForAttachment):
Flipping the icon is no longer necessary, as the icon is drawn to a bitmap
context with a top-left origin in the UIProcess, and using a top-left origin in
the WebProcess.
(WebCore::paintAttachmentIcon):
Use the default origin, as attachment icons are no longer being flipped.
* Source/WebKit/Shared/Cocoa/WebIconUtilities.h:
* Source/WebKit/Shared/Cocoa/WebIconUtilities.mm:
(WebKit::thumbnailSizedImageForImage):
(WebKit::fallbackIconForFile):
(WebKit::iconForImageFile):
(WebKit::iconForVideoFile):
(WebKit::iconForFiles):
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::convertPlatformImageToBitmap):
Use a simpler, equivalent AppKit method to share more code between Cocoa ports.
(WebKit::WebPageProxy::updateIconForDirectory):
Flipping the icon is no longer necessary, as the icon is drawn to a bitmap
context with a top-left origin in the UIProcess, and using a top-left origin in
the WebProcess.
* Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm:
(-[_WKImageFileUploadItem displayImage]):
(-[_WKVideoFileUploadItem displayImage]):
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClientCocoa.mm:
(WebKit::WebChromeClient::createIconForFiles):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didChooseFilesForOpenPanelWithDisplayStringAndIcon):
* Source/WebKitLegacy/mac/WebCoreSupport/WebOpenPanelResultListener.mm:
(-[WebOpenPanelResultListener chooseFilenames:displayString:iconImage:]):
Canonical link: https://commits.webkit.org/259598@main
Canonical link: https://commits.webkit.org/259548.88@safari-7615-branch
Commit: e4710bdf75dc597081724d8fa8f2a07b73f43d16
https://github.com/WebKit/WebKit/commit/e4710bdf75dc597081724d8fa8f2a07b73f43d16
Author: Patrick Angle <pangle at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebInspectorUI/UserInterface/Base/Setting.js
M Source/WebInspectorUI/UserInterface/Controllers/CodeMirrorTokenTrackingController.js
M Source/WebInspectorUI/UserInterface/Views/CodeMirrorEditor.js
M Source/WebInspectorUI/UserInterface/Views/SettingsTabContentView.js
Log Message:
-----------
Cherry-pick b79f1636634f. rdar://problem/104840214
Web Inspector: Add experimental feature to enable aggressive limits on the length of lines we let CodeMirror process/format
https://bugs.webkit.org/show_bug.cgi?id=251401
rdar://104840214
Reviewed by Devin Rousso and Justin Michaud.
In select cases, we are finding that Web Inspector is effectively unusable on some sites with many source files with
very longs lines of source code. The highlighting of very longs lines of code accounts for upwards of 30 seconds of
delay for very long lines of code. While we investigate further improvements we can make to solve this problem, we
are adding an experimental setting that enforces very low line limits for highlight, as well as for determining the
hovered token. These two changes will unblock developers encountering this issue when they enable the added experimental
setting.
* Source/WebInspectorUI/UserInterface/Base/Setting.js:
* Source/WebInspectorUI/UserInterface/Controllers/CodeMirrorTokenTrackingController.js:
(WI.CodeMirrorTokenTrackingController.prototype._updateHoveredTokenInfo):
* Source/WebInspectorUI/UserInterface/Views/SettingsTabContentView.js:
(WI.SettingsTabContentView.prototype._createExperimentalSettingsView):
* Source/WebInspectorUI/UserInterface/Views/TextEditor.js:
(WI.TextEditor):
Canonical link: https://commits.webkit.org/259603@main
Canonical link: https://commits.webkit.org/259548.89@safari-7615-branch
Commit: fb6878f6b10d235a8fbe6ade8754de22cde6cd04
https://github.com/WebKit/WebKit/commit/fb6878f6b10d235a8fbe6ade8754de22cde6cd04
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/http/tests/media/autoplay-if-audio-is-playing-expected.txt
M LayoutTests/http/tests/media/autoplay-if-audio-is-playing.html
M LayoutTests/media/media-fullscreen-inline-expected.txt
M LayoutTests/media/media-fullscreen.js
M LayoutTests/media/playlist-inherits-user-gesture.html
M LayoutTests/media/restricted-audio-playback-with-multiple-settimeouts.html
M LayoutTests/platform/glib/media/media-fullscreen-inline-expected.txt
M LayoutTests/platform/glib/media/media-fullscreen-not-in-document-expected.txt
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/FullscreenManager.cpp
M Source/WebCore/html/HTMLMediaElement.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsitePolicies.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/autoplaying-multiple-media-elements.html
Log Message:
-----------
Cherry-pick 98a09842676c. rdar://problem/103800206
Use transient activation for media playback
https://bugs.webkit.org/show_bug.cgi?id=251372
rdar://103800206
Reviewed by Jer Noble.
Allow media to play when there is an active transient activation. Require and consume
a transient activation when video fullscreen requires a user gesture.
* LayoutTests/http/tests/media/autoplay-if-audio-is-playing-expected.txt:
* LayoutTests/http/tests/media/autoplay-if-audio-is-playing.html: Update test and
results as the second video is now able to play because the first was started with
a user gesture.
* LayoutTests/media/media-fullscreen-inline-expected.txt:
* LayoutTests/media/media-fullscreen.js:
(canplaythrough): Remove now invalid portion of the test.
* LayoutTests/platform/glib/media/media-fullscreen-inline-expected.txt:
* LayoutTests/platform/glib/media/media-fullscreen-not-in-document-expected.txt:
* LayoutTests/media/playlist-inherits-user-gesture.html:
* LayoutTests/media/restricted-audio-playback-with-multiple-settimeouts.html: Decrease
transient activation time so these old tests work.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsitePolicies.mm: Update test to account for
and test playing because of transient activation.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/autoplaying-multiple-media-elements.html
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::processingUserGestureForMedia const): Return true when there is an
active transient activation.
* Source/WebCore/dom/FullscreenManager.cpp:
(WebCore::FullscreenManager::requestFullscreenForElement): Drive-by logging cleanup. Log
all errors.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::enterFullscreen): Require and consume a transient activation
if a user gesture is required to enter fullscreen.
Canonical link: https://commits.webkit.org/259626@main
Canonical link: https://commits.webkit.org/259548.90@safari-7615-branch
Commit: 0423541065ec4aceb90656e5560afb29a921e461
https://github.com/WebKit/WebKit/commit/0423541065ec4aceb90656e5560afb29a921e461
Author: Mark Lam <mark.lam at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/JavaScriptCore/llint/LowLevelInterpreter.asm
M Source/JavaScriptCore/llint/LowLevelInterpreter64.asm
M Source/JavaScriptCore/llint/WebAssembly.asm
Log Message:
-----------
Cherry-pick 95dcffb800f8. rdar://problem/104854843
Remove unnecessary add when loading a JSCConfig field.
https://bugs.webkit.org/show_bug.cgi?id=251421
rdar://104854843
Reviewed by Tadeu Zagallo.
Currently, to load a JSCConfig field, our LLInt asm does something like this:
```
leap JSCConfig + constexpr JSC::offsetOfJSCConfigGateMap + (constexpr Gate::%opcodeName%) * PtrSize, ws1
jmp [ws1], NativeToJITGatePtrTag # JSEntrySlowPathPtrTag
```
... and generates this:
```
#if OS(DARWIN)
".loc 1 1\n" "Ljsc_llint_loh_adrp_1508: \n" // LowLevelInterpreter.asm:1
"adrp x10, " LOCAL_REFERENCE(g_config) "@GOTPAGE \n"
"Ljsc_llint_loh_ldr_1508: \n"
"ldr x10, [x10, " LOCAL_REFERENCE(g_config) "@GOTPAGEOFF] \n"
#elif OS(LINUX)
...
#endif
".loc 1 1\n" "add x10, x10, #3592 \n" // <---- this add can be applied as an offset to the ldr below.
".loc 6 1034\n" "movz x13, #57366 \n" // WebAssembly.asm:1034
"ldr x17, [x10] \n"
"brab x17, x13 \n"
```
This patch re-arranges the LLInt assembly to look like this instead:
```
leap _g_config, ws1
jmp JSCConfigGateMapOffset + (constexpr Gate::%opcodeName%) * PtrSize[ws1], NativeToJITGatePtrTag # JSEntrySlowPathPtrTag
```
... resulting in the removal of the unnecessary add instruction:
```
#if OS(DARWIN)
".loc 1 1\n" "Ljsc_llint_loh_adrp_1508: \n" // LowLevelInterpreter.asm:1
"adrp x10, " LOCAL_REFERENCE(g_config) "@GOTPAGE \n"
"Ljsc_llint_loh_ldr_1508: \n"
"ldr x10, [x10, " LOCAL_REFERENCE(g_config) "@GOTPAGEOFF] \n"
#elif OS(LINUX)
...
#endif
".loc 6 1034\n" "movz x13, #57366 \n" // WebAssembly.asm:1034
"ldr x17, [x10, #3592] \n"
"brab x17, x13 \n"
```
* Source/JavaScriptCore/llint/LowLevelInterpreter.asm:
* Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:
* Source/JavaScriptCore/llint/WebAssembly.asm:
Canonical link: https://commits.webkit.org/259629@main
Canonical link: https://commits.webkit.org/259548.91@safari-7615-branch
Commit: ff27770256c6220a138c39a10b2f11f6a88fc1c7
https://github.com/WebKit/WebKit/commit/ff27770256c6220a138c39a10b2f11f6a88fc1c7
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/animation/KeyframeEffect.cpp
Log Message:
-----------
Cherry-pick 9de2e80cf70b. rdar://problem/104869270
[web-animations] use the keyframe's StyleProperties to determine whether a property is set to "inherit" in a keyframe
https://bugs.webkit.org/show_bug.cgi?id=251432
Reviewed by Antti Koivisto.
Until now we would determine whether a property is set to "inherit" in a keyframe by doing a string
comparison when the Web Animations API is used to set keyframes. However, the StyleRuleKeyframe
created for the keyframe has StyleProperties where the value is parsed, it seems safer to check
the CSSValue rather than do a string comparison here.
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::processKeyframes):
(WebCore::KeyframeEffect::updateBlendingKeyframes):
Canonical link: https://commits.webkit.org/259630@main
Canonical link: https://commits.webkit.org/259548.92@safari-7615-branch
Commit: d3e63a829558048ea7e539b131269410c0152e5a
https://github.com/WebKit/WebKit/commit/d3e63a829558048ea7e539b131269410c0152e5a
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/line-height-expected.txt
A LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/line-height.html
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/style/StyleResolver.cpp
M Source/WebCore/style/StyleResolver.h
Log Message:
-----------
Cherry-pick 9f095ff23eaa. rdar://problem/104869399
[css-animations] a @keyframes rule using an "inherit" value does not update the resolved value when the parent style changes
https://bugs.webkit.org/show_bug.cgi?id=251433
Reviewed by Antti Koivisto.
In the case where a @keyframes rule has one of its properties set to "inherit", we need to update
the computed keyframes in case an ancestor changes in a way that the inherited value changes.
We already have a mechanism to deal with a similar scenario when the keyframes are provided using
the Web Animations API where the m_inheritedProperties instance variable keeps track of all CSS
properties set to "inherit" in keyframes.
We now pass m_inheritedProperties to Style::Resolver::keyframeStylesForAnimation() to populate it
when a CSS Animation's keyframes are computed.
* LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/line-height-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/line-height.html: Added.
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::computeCSSAnimationBlendingKeyframes):
* Source/WebCore/style/StyleResolver.cpp:
(WebCore::Style::Resolver::keyframeStylesForAnimation):
* Source/WebCore/style/StyleResolver.h:
Canonical link: https://commits.webkit.org/259631@main
Canonical link: https://commits.webkit.org/259548.93@safari-7615-branch
Commit: 722c923d62a50277ba7f7e4729b06905250aaa82
https://github.com/WebKit/WebKit/commit/722c923d62a50277ba7f7e4729b06905250aaa82
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/storage/filesystemaccess/resources/sync-access-handle-storage-limit.js
A LayoutTests/storage/filesystemaccess/sync-access-handle-storage-limit-worker-expected.txt
A LayoutTests/storage/filesystemaccess/sync-access-handle-storage-limit-worker.html
M Source/WebCore/Modules/filesystemaccess/FileSystemFileHandle.cpp
M Source/WebCore/Modules/filesystemaccess/FileSystemFileHandle.h
M Source/WebCore/Modules/filesystemaccess/FileSystemStorageConnection.h
M Source/WebCore/Modules/filesystemaccess/FileSystemSyncAccessHandle.cpp
M Source/WebCore/Modules/filesystemaccess/FileSystemSyncAccessHandle.h
M Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.cpp
M Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.h
M Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.cpp
M Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.h
M Source/WebKit/NetworkProcess/storage/FileSystemStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/FileSystemStorageManager.h
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.messages.in
M Source/WebKit/NetworkProcess/storage/OriginStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/OriginStorageManager.h
M Source/WebKit/Scripts/webkit/messages.py
A Source/WebKit/Shared/FileSystemSyncAccessHandleInfo.h
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.h
Log Message:
-----------
Cherry-pick 2706810bb38f. rdar://problem/93588782
FileSystemSyncAccessHandle::write should perform quota check
https://bugs.webkit.org/show_bug.cgi?id=250400
rdar://93588782
Reviewed by Youenn Fablet.
Implement basic quota check for FileSystemSyncAccessHandle. The general ideas are:
1. Each FileSystemSyncAccessHandle has a capacity intialized to current file size.
2. For write operation on FileSystemSyncAccessHandle, if the new size after write exceeds current capacity, it needs to
send a request to increase capacity.
3. The capacity of FileSystemSyncAccessHandle will be viewed as occupied (even if the real file size is smaller) in
origin quota computation.
4. FileSystem data shares origin quota with IndexedDB and CacheStorage.
* LayoutTests/storage/filesystemaccess/resources/sync-access-handle-storage-limit.js: Added.
(async test):
* LayoutTests/storage/filesystemaccess/sync-access-handle-storage-limit-worker-expected.txt: Added.
* LayoutTests/storage/filesystemaccess/sync-access-handle-storage-limit-worker.html: Added.
* Source/WebCore/Modules/filesystemaccess/FileSystemFileHandle.cpp:
(WebCore::FileSystemFileHandle::createSyncAccessHandle):
(WebCore::FileSystemFileHandle::requestNewCapacityForSyncAccessHandle):
* Source/WebCore/Modules/filesystemaccess/FileSystemFileHandle.h:
* Source/WebCore/Modules/filesystemaccess/FileSystemStorageConnection.h:
(WebCore::FileSystemStorageConnection::SyncAccessHandleInfo::isolatedCopy):
* Source/WebCore/Modules/filesystemaccess/FileSystemSyncAccessHandle.cpp:
(WebCore::FileSystemSyncAccessHandle::create):
(WebCore::FileSystemSyncAccessHandle::FileSystemSyncAccessHandle):
(WebCore::FileSystemSyncAccessHandle::write):
(WebCore::FileSystemSyncAccessHandle::requestSpaceForWrite):
* Source/WebCore/Modules/filesystemaccess/FileSystemSyncAccessHandle.h:
* Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.cpp:
(WebCore::WorkerFileSystemStorageConnection::didCreateSyncAccessHandle):
(WebCore::WorkerFileSystemStorageConnection::requestNewCapacityForSyncAccessHandle):
* Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.h:
* Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.cpp:
(WebKit::FileSystemStorageHandle::close):
(WebKit::FileSystemStorageHandle::createSyncAccessHandle):
(WebKit::FileSystemStorageHandle::closeSyncAccessHandle):
(WebKit::FileSystemStorageHandle::activeSyncAccessHandle):
(WebKit::FileSystemStorageHandle::isActiveSyncAccessHandle):
(WebKit::FileSystemStorageHandle::allocatedUnusedCapacity):
(WebKit::FileSystemStorageHandle::requestNewCapacityForSyncAccessHandle):
* Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.h:
(WebKit::FileSystemStorageHandle::activeSyncAccessHandle const): Deleted.
* Source/WebKit/NetworkProcess/storage/FileSystemStorageManager.cpp:
(WebKit::FileSystemStorageManager::FileSystemStorageManager):
(WebKit::FileSystemStorageManager::allocatedUnusedCapacity const):
(WebKit::FileSystemStorageManager::requestSpace):
* Source/WebKit/NetworkProcess/storage/FileSystemStorageManager.h:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::createSyncAccessHandle):
(WebKit::NetworkStorageManager::requestNewCapacityForSyncAccessHandle):
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.messages.in:
* Source/WebKit/NetworkProcess/storage/OriginStorageManager.cpp:
(WebKit::OriginStorageManager::StorageBucket::existingFileSystemStorageManager):
(WebKit::OriginStorageManager::StorageBucket::fileSystemStorageManager):
(WebKit::OriginStorageManager::createQuotaManager):
(WebKit::OriginStorageManager::quotaManager):
(WebKit::OriginStorageManager::fileSystemStorageManager):
(WebKit::OriginStorageManager::existingFileSystemStorageManager):
(WebKit::createQuotaManager): Deleted.
* Source/WebKit/NetworkProcess/storage/OriginStorageManager.h:
* Source/WebKit/Scripts/webkit/messages.py:
(types_that_cannot_be_forward_declared):
* Source/WebKit/Shared/FileSystemSyncAccessHandleInfo.h: Copied from Source/WebCore/Modules/filesystemaccess/FileSystemFileHandle.h.
(WebKit::FileSystemSyncAccessHandleInfo::encode const):
(WebKit::FileSystemSyncAccessHandleInfo::decode):
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.cpp:
(WebKit::WebFileSystemStorageConnection::createSyncAccessHandle):
(WebKit::WebFileSystemStorageConnection::requestNewCapacityForSyncAccessHandle):
* Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.h:
Canonical link: https://commits.webkit.org/259635@main
Canonical link: https://commits.webkit.org/259548.94@safari-7615-branch
Commit: 17ce8712cfc2746f69bd87e6935fd5276b3c47b0
https://github.com/WebKit/WebKit/commit/17ce8712cfc2746f69bd87e6935fd5276b3c47b0
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/column-rule-color-001-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/column-width-001-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/baselineShift-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/clip-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/columnCount-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/columnGap-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/offsetRotate-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/opacity-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/perspective-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/rowGap-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/shapeOutside-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/to-color-change-expected.txt
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/animation/KeyframeEffectStack.cpp
Log Message:
-----------
Cherry-pick 25ead8e66edd. rdar://problem/102694235
[web-animations] keyframes should be recomputed when a parent element changes value for a non-inherited property set to "inherit"
https://bugs.webkit.org/show_bug.cgi?id=248152
Reviewed by Antti Koivisto.
In the case where a non-inherited property is set to "inherit" on a keyframe, we now update keyframes
each time animations are updated in case the parent style changed value. While this is not optimal, this
is bound to be a pretty rare scenario which we can improve on later if we deem it necessary.
* LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/column-rule-color-001-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/column-width-001-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/baselineShift-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/clip-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/columnCount-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/columnGap-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/offsetRotate-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/opacity-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/perspective-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/rowGap-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/shapeOutside-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/to-color-change-expected.txt:
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::setBlendingKeyframes):
(WebCore::KeyframeEffect::setAnimatedPropertiesInStyle):
(WebCore::KeyframeEffect::computeHasExplicitlyInheritedKeyframeProperty):
* Source/WebCore/animation/KeyframeEffect.h:
(WebCore::KeyframeEffect::hasExplicitlyInheritedKeyframeProperty const):
* Source/WebCore/animation/KeyframeEffectStack.cpp:
(WebCore::KeyframeEffectStack::applyKeyframeEffects):
Canonical link: https://commits.webkit.org/259645@main
Canonical link: https://commits.webkit.org/259548.95@safari-7615-branch
Commit: 8072b747326b51f15399acf9d9074c379ef0bb27
https://github.com/WebKit/WebKit/commit/8072b747326b51f15399acf9d9074c379ef0bb27
Author: Patrick Angle <pangle at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js
Log Message:
-----------
Cherry-pick f8d110a5fec4. rdar://problem/104891316
Web Inspector: Add missing localizable strings after 259603 at main
https://bugs.webkit.org/show_bug.cgi?id=251468
rdar://104891316
Unreviewed localization fix.
* Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js:
Canonical link: https://commits.webkit.org/259650@main
Canonical link: https://commits.webkit.org/259548.96@safari-7615-branch
Commit: 050fa076906ffaf9e3cdcd9e0a6ad86c8f7d89cf
https://github.com/WebKit/WebKit/commit/050fa076906ffaf9e3cdcd9e0a6ad86c8f7d89cf
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb.in
Log Message:
-----------
Cherry-pick 9bde2121e40c. rdar://problem/102969507
REGRESSION(249742 at main): [iOS] createSyncAccessHandle throws error 'UnknownError: Invalid platform file handle'
https://bugs.webkit.org/show_bug.cgi?id=251460
rdar://102969507
Reviewed by Brent Fulgham.
* Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb.in:
Canonical link: https://commits.webkit.org/259656@main
Canonical link: https://commits.webkit.org/259548.97@safari-7615-branch
Commit: c120b0de1edce55652323b817a9fc55e34ce85b9
https://github.com/WebKit/WebKit/commit/c120b0de1edce55652323b817a9fc55e34ce85b9
Author: Michael Saboff <msaboff at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M JSTests/stress/regexp-lookbehind.js
M Source/JavaScriptCore/yarr/YarrPattern.cpp
M Source/JavaScriptCore/yarr/YarrPattern.h
Log Message:
-----------
Cherry-pick 561d0e5534c8. rdar://problem/104652578
[JSC] UAF Yarr::YarrPatternConstructor::atomParenthesesEnd; Yarr::Parser::parseTokens; JSC::Yarr::parse
https://bugs.webkit.org/show_bug.cgi?id=251435
rdar://104652578
Reviewed by Mark Lam and Tadeu Zagallo.
When parsing a backreference for a lookbehind, it will likely appear lexically before the capture it references.
In that case, we create a forward reference term and see if we can convert it to a backreference at the end of the
lookbehind if a corresponding capture was found. The prior code did this by saving a pointer to all such forward
references. That pointer is a pointer into the storage for a Vector, which can be reallocated as it grows.
The fix here is to save a pointer to the alternative that contains the term and the index of the term in the alternative.
PatternAlternatives are kept alive during parsing, so it is safe to use them.
* JSTests/stress/regexp-lookbehind.js: Added new test cases.
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::UnresolvedForwardReference::UnresolvedForwardReference):
(JSC::Yarr::YarrPatternConstructor::UnresolvedForwardReference::term):
(JSC::Yarr::YarrPatternConstructor::atomParenthesesEnd):
(JSC::Yarr::YarrPatternConstructor::atomBackReference):
* Source/JavaScriptCore/yarr/YarrPattern.h:
(JSC::Yarr::PatternAlternative::lastTermIndex):
(JSC::Yarr::PatternAlternative::lastTerm):
Canonical link: https://commits.webkit.org/259657@main
Canonical link: https://commits.webkit.org/259548.98@safari-7615-branch
Commit: 091cd7eff0db7db988cc578b7eb79953234a4033
https://github.com/WebKit/WebKit/commit/091cd7eff0db7db988cc578b7eb79953234a4033
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/PAL/pal/spi/cocoa/NSFileManagerSPI.h
M Source/WebCore/en.lproj/Localizable.strings
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivateForTesting.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewTesting.mm
M Source/WebKit/UIProcess/ios/WKGeolocationProviderIOS.mm
R Source/WebKit/UIProcess/ios/WKGeolocationProviderIOSObjCSecurityOrigin.mm
A Source/WebKit/UIProcess/ios/WKWebGeolocationPolicyDecider.h
A Source/WebKit/UIProcess/ios/WKWebGeolocationPolicyDeciderIOS.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/Geolocation.mm
Log Message:
-----------
Cherry-pick bbb71e0a3531. rdar://problem/102728659
[WK2] Stop relying on WebKitLegacy code to do geolocation permission prompting
https://bugs.webkit.org/show_bug.cgi?id=251368
rdar://102728659
Reviewed by Geoffrey Garen.
Stop relying on WebKitLegacy code to do geolocation permission prompting in
WebKit2. We now have a WKWebGeolocationPolicyDecider class that lives in
the WebKit2 project.
Also enhance the prompting dialog to be closer to the one MobileSafari uses
(see screenshots on radar).
The logic for remembering the geolocation permission is identical to the
one WebKitLegacy is using, except that we only use the host as key instead
of the full security origin. Note that the prompt only shows the host, like
it does in MobileSafari.
* Source/WebCore/en.lproj/Localizable.strings:
* Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js:
* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/UIProcess/ios/WKGeolocationProviderIOS.mm:
(-[WKGeolocationProviderIOS geolocationAuthorizationGranted]):
(-[WKWebAllowDenyPolicyListener deny]):
(-[WKWebAllowDenyPolicyListener denyOnlyThisRequest]): Deleted.
(-[WKWebAllowDenyPolicyListener shouldClearCache]): Deleted.
* Source/WebKit/UIProcess/ios/WKGeolocationProviderIOSObjCSecurityOrigin.mm: Removed.
* Source/WebKit/UIProcess/ios/WKWebGeolocationPolicyDecider.h: Added.
* Source/WebKit/UIProcess/ios/WKWebGeolocationPolicyDeciderIOS.mm: Added.
(clearGeolocationCache):
(appHasPreciseLocationPermission):
(appDisplayName):
(getToken):
(PermissionRequest::create):
(+[WKWebGeolocationPolicyDecider sharedPolicyDecider]):
(-[WKWebGeolocationPolicyDecider init]):
(-[WKWebGeolocationPolicyDecider dealloc]):
(-[WKWebGeolocationPolicyDecider decidePolicyForGeolocationRequestFromOrigin:requestingURL:view:listener:]):
(-[WKWebGeolocationPolicyDecider _executeNextChallenge]):
(-[WKWebGeolocationPolicyDecider _finishActiveChallenge:]):
(-[WKWebGeolocationPolicyDecider clearCache]):
(-[WKWebGeolocationPolicyDecider _siteFileInContainerDirectory:creatingIntermediateDirectoriesIfNecessary:]):
(-[WKWebGeolocationPolicyDecider _siteFile]):
(createChallengeDictionary):
(-[WKWebGeolocationPolicyDecider _loadWithCompletionHandler:]):
(-[WKWebGeolocationPolicyDecider _save]):
(-[WKWebGeolocationPolicyDecider _getChallengeCountFromHistoryForToken:requestingURL:]):
(-[WKWebGeolocationPolicyDecider _addChallengeCount:forToken:requestingURL:]):
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/259658@main
Canonical link: https://commits.webkit.org/259548.99@safari-7615-branch
Commit: babec2748c3c49178832ba0ece8a24945ceba0f9
https://github.com/WebKit/WebKit/commit/babec2748c3c49178832ba0ece8a24945ceba0f9
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/http/wpt/cache-storage/cache-quota-add.any-expected.txt
M LayoutTests/http/wpt/cache-storage/cache-quota-add.any.js
M Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp
Log Message:
-----------
Cherry-pick 2a9280974163. rdar://problem/104852161
CacheStorageCache should update size file when all records are removed
https://bugs.webkit.org/show_bug.cgi?id=251418
rdar://104852161
Reviewed by Youenn Fablet.
CacheStorageCache currently updates size file when records are added and removed, but not when all records are removed
(cleared).
* LayoutTests/http/wpt/cache-storage/cache-quota-add.any-expected.txt:
* LayoutTests/http/wpt/cache-storage/cache-quota-add.any.js:
(promise_test.async test):
* Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp:
(WebKit::CacheStorageCache::removeAllRecords):
Canonical link: https://commits.webkit.org/259660@main
Canonical link: https://commits.webkit.org/259548.100@safari-7615-branch
Commit: f8093eadfb38efd4c1aa8744ea0b6e7d8d0904e5
https://github.com/WebKit/WebKit/commit/f8093eadfb38efd4c1aa8744ea0b6e7d8d0904e5
Author: Sammy Gill <sammy.gill at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/images/abs-pos-transferred-max-width-from-percentage-max-height-in-auto-height-containing-block-expected.html
A LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/images/abs-pos-transferred-max-width-from-percentage-max-height-in-auto-height-containing-block.html
M Source/WebCore/rendering/RenderBox.cpp
Log Message:
-----------
Cherry-pick 93e6542aebf9. rdar://problem/103481329
(REGRESSION(257434 at main): https://readwise.io/read image squished
https://bugs.webkit.org/show_bug.cgi?id=251419
rdar://103481329
Reviewed by Alan Baradlay.
When viewing the website on iOS the image of the phone renders
incorrectly as the width that is computed is too large. The image has
max-height: 100%, so this constraint should also provide the transferred
max-width for the image. We should be able to compute this value since
the image is absolutely positioned.
The previous version (before the regression) of this code computed the
"constrained width" by calling computeReplacedLogicalHeight and then
using the intrinsic ratio to compute the final width. computeReplacedLogicalHeight
eventually called into computeReplacedLogicalHeightUsing to compute the
min/max heights. This ended up computing the correct value for the min/max
heights when the image was absolutely positioned and had a percentage
height in an auto-height containing block.
The new version of the code, which used the logic for the css
aspect-ratio property, did not handle this case correctly and returned
an incorrect value for max-height. To resolve this issue, we can check
to see if the object is a RenderReplaced object by the time we get
to RenderBox::computeLogicalHeightUsing and then call into
computeReplacedLogicalHeightUsing to get the correct value.
* LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/images/abs-pos-transferred-max-width-from-percentage-max-height-in-auto-height-containing-block-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/images/abs-pos-transferred-max-width-from-percentage-max-height-in-auto-height-containing-block.html: Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::computeLogicalHeightUsing const):
Canonical link: https://commits.webkit.org/259663@main
Canonical link: https://commits.webkit.org/259548.101@safari-7615-branch
Commit: 6cdaafc115629def465bf89d38500d1123a0fa62
https://github.com/WebKit/WebKit/commit/6cdaafc115629def465bf89d38500d1123a0fa62
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp
Log Message:
-----------
Cherry-pick c6d75c202f1a. rdar://problem/104797919
[IFC] InlineFormattingGeometry::staticPositionForOutOfFlowBlockLevelBox should be able to handle empty content
https://bugs.webkit.org/show_bug.cgi?id=251477
<rdar://104797919>
Reviewed by Antti Koivisto.
This is the block level box variant of webkit.org/b/248158 (<- inline level box).
While line-clamp does not produce empty IFCs anymore (changed at webkit.org/b/250270), accessing line[0] unconditionally may not be such a great idea.
* Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp:
(WebCore::Layout::InlineFormattingGeometry::staticPositionForOutOfFlowBlockLevelBox const):
Canonical link: https://commits.webkit.org/259684@main
Canonical link: https://commits.webkit.org/259548.102@safari-7615-branch
Commit: 56e8cc4a66c3ba0951f103d6745941d6b19705ac
https://github.com/WebKit/WebKit/commit/56e8cc4a66c3ba0951f103d6745941d6b19705ac
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/svg/foreignObject/foreign-object-without-svgroot-crash-expected.txt
A LayoutTests/svg/foreignObject/foreign-object-without-svgroot-crash.html
M Source/WebCore/svg/SVGForeignObjectElement.cpp
Log Message:
-----------
Cherry-pick e80607696660. rdar://problem/102916021
Don't create renderer for foreignElement when it has no parent
https://bugs.webkit.org/show_bug.cgi?id=241778
rdar://102916021
Reviewed by Nikolas Zimmermann.
If the body is replaced by foreignElement, it results in a DOM which
doesn't have anything to render or layout, but it crashes WebKit because
we trip over an assert because isPaintOffsetCacheEnabled is not disabled
(which happens only when there is a SVGRoot). This change makes it so
that we don't generate the useless renderer in the first place, which is
what happens with other SVGElements.
* LayoutTests/svg/foreignObject/foreign-object-without-svgroot-crash-expected.txt: Added.
* LayoutTests/svg/foreignObject/foreign-object-without-svgroot-crash.html: Added.
* Source/WebCore/svg/SVGForeignObjectElement.cpp:
(WebCore::SVGForeignObjectElement::rendererIsNeeded):
Canonical link: https://commits.webkit.org/259685@main
Canonical link: https://commits.webkit.org/259548.103@safari-7615-branch
Commit: 5cc8e153e8fbf4de5b9f801d868995b3096ad1a8
https://github.com/WebKit/WebKit/commit/5cc8e153e8fbf4de5b9f801d868995b3096ad1a8
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp
Log Message:
-----------
Cherry-pick 167dfa751c25. rdar://problem/104892197
Ensure CacheStorageDiskStore make isolated copy of arguments when passing them between WorkQueues
https://bugs.webkit.org/show_bug.cgi?id=251471
rdar://104892197
Reviewed by Per Arne Vollan.
* Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp:
(WebKit::CacheStorageDiskStore::deleteRecords):
(WebKit::CacheStorageDiskStore::writeRecords):
Canonical link: https://commits.webkit.org/259700@main
Canonical link: https://commits.webkit.org/259548.104@safari-7615-branch
Commit: 90f509675c69f7589fb9a2878d314a47fd0dfed4
https://github.com/WebKit/WebKit/commit/90f509675c69f7589fb9a2878d314a47fd0dfed4
Author: Antti Koivisto <antti at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/typedom-expected.txt
M Source/WebCore/css/typedom/ComputedStylePropertyMapReadOnly.cpp
Log Message:
-----------
Cherry-pick 414ff0019118. rdar://problem/104916732
[@property] Ensure style is up to date in ComputedStylePropertyMapReadOnly::entries
https://bugs.webkit.org/show_bug.cgi?id=251517
rdar://104916732
Reviewed by Alan Baradlay.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/typedom-expected.txt:
* Source/WebCore/css/typedom/ComputedStylePropertyMapReadOnly.cpp:
(WebCore::ComputedStylePropertyMapReadOnly::size const):
(WebCore::ComputedStylePropertyMapReadOnly::entries const):
Ensure style is up to date for custom properties so that we get the correct count.
Canonical link: https://commits.webkit.org/259703@main
Canonical link: https://commits.webkit.org/259548.105@safari-7615-branch
Commit: 6fb2766cfe3ebb93ee00959dda1a4b4e084c57d3
https://github.com/WebKit/WebKit/commit/6fb2766cfe3ebb93ee00959dda1a4b4e084c57d3
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/rendering/RenderObject.cpp
Log Message:
-----------
Cherry-pick 37ea7633b1ef. rdar://problem/104814038
Fix infinite recursion in propagateRepaintToParentWithOutlineAutoIfNeeded
https://bugs.webkit.org/show_bug.cgi?id=251409
rdar://104814038
Reviewed by Alan Baradlay.
Now that we map the removed element to the placeholder, we need to use
the original renderer for comparison otherwise we would cause infinite
recursion.
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::propagateRepaintToParentWithOutlineAutoIfNeeded const):
Canonical link: https://commits.webkit.org/259725@main
Canonical link: https://commits.webkit.org/259548.106@safari-7615-branch
Commit: 5e598a0ece97b0177d2e70714b6c18604229a585
https://github.com/WebKit/WebKit/commit/5e598a0ece97b0177d2e70714b6c18604229a585
Author: Sammy Gill <sammy.gill at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-collapsed-margins-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-collapsed-margins.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-self-collapsing-item-has-larger-block-end-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-self-collapsing-item-has-larger-block-end.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-self-collapsing-item-has-larger-block-start-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-self-collapsing-item-has-larger-block-start.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-collapsed-margins-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-collapsed-margins.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-self-collapsing-item-has-larger-block-end-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-self-collapsing-item-has-larger-block-end.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-self-collapsing-item-larger-block-start-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-self-collapsing-item-larger-block-start.html
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Cherry-pick 82ef68207e2f. rdar://problem/103640784
Trim collapsed margins at block-start and block-end when specified by margin-trim
https://bugs.webkit.org/show_bug.cgi?id=249781
rdar://103640784
Reviewed by Alan Baradlay.
When collapsed margins at propagated to the block-start or block-end of
a block container and the appropriate margin-trim values are specified,
those margins should also be trimmed.
This can be done by keeping track of whether we are at the block start
or block end of the box as specified by the MarginInfo structure. If
we are currently at the block start of the container, then we should
trim the before margin of the child. If the child is self collapsing,
we should also trim its after margin.
By the time we are in setCollapsedBottomMargin, we are at the block
end of the block container. That means we should be able to trim the
values inside of MarginInfo if margin-trim: block/block-end is
specified.
Here is an example to demonstrate this logic:
container {
display: block;
margin-trim: block;
margin-block-start: 10px;
}
item {
display: block;
margin-block-start: 40px;
width: 50px;
height: 50px;
background-color: green;
}
.collapsed {
margin-block-start: 0px;
height: 0px;
}
<item style="margin-block-start: 0px;"></item>
<container>
<item class="collapsed"></item>
<item></item>
</container>
- The container will begin layout of its block children and will iterate
over them. Each iteration will take in and update a MarginInfo structure
that is used to handle any sort of collapsing. Initially this structure
will just hold the margin information for the container itself.
- RenderBlockFlow::layoutBlockChild will call RenderBlockFlow::collapseMargins
with the child as an argument, and that method will call
RenderBlockFlow::collapseMarginsWithChildInfo to perform the actual
collapsing.
- Since we are at the before side of the block, which is a part of the
MarginInfo state, and block-start trimming is specified, we will then
trim the block-start margin of the child. We will also trim the block-end
margin of the child since it is self-collapsing.
- Once we are done with this item and we are back in RenderBlockFlow::layoutBlockChild
we will check to see if we need to update the MarginInfo state that keeps
track of us being at the before side of the block container. Since
1.) We were at the before side of the block container
2.) The child we just laid out is self collapsing
We will not update our MarginInfo state and we will continue to be at the
before side of the block. This means that this trimming logic will continue
on with the next item in the container. If the first item was not
self collapsing, however, then we would update our MarginInfo state so
that we are no longer at the before side and we would not trim the
block-start margins of the future children.
- After we layout and trim the margins of the second item,
RenderBlockFlow::layoutBlockChildren will call handleAfterSideOfBlock
with the MarginInfo structure that has been modified this whole time.
This should contain any margins that have collapsed through to the
after side of the block.
- Once in RenderBlockFlow::setCollapsedBottomMargin, we will check to
see if block-end margin trimming has been specified. If it has, then
we will use 0 (trimmed) for the margin from MarginInfo that is supposed
to collapse with the container's margin.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-collapsed-margins-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-collapsed-margins.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-self-collapsing-item-has-larger-block-end-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-self-collapsing-item-has-larger-block-end.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-self-collapsing-item-has-larger-block-start-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-end-self-collapsing-item-has-larger-block-start.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-collapsed-margins-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-collapsed-margins.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-self-collapsing-item-has-larger-block-end-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-self-collapsing-item-has-larger-block-end.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-self-collapsing-item-larger-block-start-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/block-container-block-start-self-collapsing-item-larger-block-start.html: Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::collapseMarginsWithChildInfo):
(WebCore::RenderBlockFlow::setCollapsedBottomMargin):
Canonical link: https://commits.webkit.org/259734@main
Canonical link: https://commits.webkit.org/259548.107@safari-7615-branch
Commit: 1f8ddc45ca6597c681c55c8967d9d3c8252ee3ea
https://github.com/WebKit/WebKit/commit/1f8ddc45ca6597c681c55c8967d9d3c8252ee3ea
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-animations/CSSAnimation-getKeyframes-crash.html
M Source/WebCore/animation/KeyframeEffect.cpp
Log Message:
-----------
Cherry-pick 0f60938da30b. rdar://problem/104947371
[web-animations] ASSERT(node.isConnected()) reached in Style::Scope::forNode() in css/css-animations/CSSAnimation-getKeyframes-crash.html
https://bugs.webkit.org/show_bug.cgi?id=251516
Reviewed by Antti Koivisto.
We should check that the effect's target is non-null and connected before calling Style::Scope::forOrdinal()
with that target as the first parameter. This caused a crash in a newly-imported WPT test.
* LayoutTests/imported/w3c/web-platform-tests/css/css-animations/CSSAnimation-getKeyframes-crash.html: Added.
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::getKeyframes):
Canonical link: https://commits.webkit.org/259735@main
Canonical link: https://commits.webkit.org/259548.108@safari-7615-branch
Commit: bbd9fed38e84c8e3bbf9ee6f3048f92d6b2a932c
https://github.com/WebKit/WebKit/commit/bbd9fed38e84c8e3bbf9ee6f3048f92d6b2a932c
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/column-rule-color-001-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/to-color-change-expected.txt
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/animation/KeyframeEffectStack.cpp
M Source/WebCore/style/StyleResolver.cpp
M Source/WebCore/style/StyleResolver.h
Log Message:
-----------
Cherry-pick cf865e9c2ded. rdar://problem/104947407
[web-animations] keyframes should be recomputed when the "currentcolor" value is used
https://bugs.webkit.org/show_bug.cgi?id=251491
Reviewed by Antti Koivisto.
Keyframes can set any number of color-related properties to use `currentcolor`. We need
to recompute keyframes if the value to which `currentcolor` would resolve changes during
an animation.
To that end, we keep track of properties set to `currentcolor` on keyframes, and recompute
the keyframes if we find that `RenderStyle::color()` has changed during style resolution.
In the case where one of those properties is the `color` property, the relevant value is
not the style's value, but the parent style's value. In this case, which is bound to be
rather rare, we elect to always recompute keyframes.
* LayoutTests/imported/w3c/web-platform-tests/css/css-animations/responsive/column-rule-color-001-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/to-color-change-expected.txt:
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::updateBlendingKeyframes):
(WebCore::KeyframeEffect::computeCSSAnimationBlendingKeyframes):
(WebCore::KeyframeEffect::hasPropertySetToCurrentColor const):
(WebCore::KeyframeEffect::hasColorSetToCurrentColor const):
* Source/WebCore/animation/KeyframeEffect.h:
* Source/WebCore/animation/KeyframeEffectStack.cpp:
(WebCore::KeyframeEffectStack::applyKeyframeEffects):
* Source/WebCore/style/StyleResolver.cpp:
(WebCore::Style::Resolver::keyframeStylesForAnimation):
* Source/WebCore/style/StyleResolver.h:
Canonical link: https://commits.webkit.org/259736@main
Canonical link: https://commits.webkit.org/259548.109@safari-7615-branch
Commit: 302e12805393b8652eb1978fccb8767c7f40f2bb
https://github.com/WebKit/WebKit/commit/302e12805393b8652eb1978fccb8767c7f40f2bb
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/baselineShift-expected.txt
M Source/WebCore/css/CSSProperties.json
M Source/WebCore/style/StyleBuilderCustom.h
Log Message:
-----------
Cherry-pick a83d5abf9aef. rdar://problem/104947491
imported/w3c/web-platform-tests/web-animations/responsive/baselineShift.html is a failure
https://bugs.webkit.org/show_bug.cgi?id=251490
Reviewed by Antti Koivisto.
The baseline-shift CSS property is represented by two different bits on RenderStyle. In the case of
"inherit" we would only forward one of the bits from the parent style. We now add a custom "inherit"
function to the style builder to correctly forward both bits from the parent style.
This fixes the remaining tests in the web-animations/responsive/baselineShift.html WPT which uses
"baseline-shift: inherit" in a @keyframes rule.
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/baselineShift-expected.txt:
* Source/WebCore/css/CSSProperties.json:
* Source/WebCore/style/StyleBuilderCustom.h:
(WebCore::Style::BuilderCustom::applyInheritBaselineShift):
Canonical link: https://commits.webkit.org/259738@main
Canonical link: https://commits.webkit.org/259548.110@safari-7615-branch
Commit: 7c86d699c6c50e3e6d5dab535b0de19cd3860ee1
https://github.com/WebKit/WebKit/commit/7c86d699c6c50e3e6d5dab535b0de19cd3860ee1
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-animations/KeyframeEffect-getKeyframes.tentative.html
M Source/WebCore/rendering/style/KeyframeList.cpp
Log Message:
-----------
Cherry-pick 52923169468b. rdar://problem/104947614
[css-animations] composite operation of implicit keyframes for CSS Animations should be "replace"
https://bugs.webkit.org/show_bug.cgi?id=251499
Reviewed by Antti Koivisto.
The CSS Animations spec indicates in its "Keyframes" section [0] that the default composite is
"replace". As such, when generating an implicit keyframe for an effect tied to a CSS Animation,
we should set the composite value to "replace".
This issue was caught by a new version of css/css-animations/KeyframeEffect-getKeyframes.tentative.html
which was not yet in our repository, so we update it with the most recent changes.
We make an additional change in the final subtest of this WPT to correctly have "replace" as
the composite value for the implicit keyframes. I suspect this change was not made when Google
last changed that test [1] because Chrome fails to generate the right implicit keyframes in this case.
[0] https://drafts.csswg.org/css-animations-2/#keyframes
[1] https://github.com/web-platform-tests/wpt/commit/1a5c61d2ca9d0f2c2801adf2b433c7931512152f
* LayoutTests/imported/w3c/web-platform-tests/css/css-animations/KeyframeEffect-getKeyframes.tentative.html:
* Source/WebCore/rendering/style/KeyframeList.cpp:
(WebCore::KeyframeList::fillImplicitKeyframes):
Canonical link: https://commits.webkit.org/259739@main
Canonical link: https://commits.webkit.org/259548.111@safari-7615-branch
Commit: ea7479f358d26856ecbffab57c655ed6b249bda2
https://github.com/WebKit/WebKit/commit/ea7479f358d26856ecbffab57c655ed6b249bda2
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/fontWeight-expected.txt
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/animation/KeyframeEffectStack.cpp
M Source/WebCore/style/StyleResolver.cpp
M Source/WebCore/style/StyleResolver.h
Log Message:
-----------
Cherry-pick 91d257012a74. rdar://problem/104948885
[web-animations] keyframes should be recomputed when "bolder" or "lighter" is used on a "font-weight" property
https://bugs.webkit.org/show_bug.cgi?id=251493
Reviewed by Antti Koivisto.
Keyframes can set the "font-weight" property to "bolder" or "lighter". When such values are used, we
recompute keyframes if the inherited "font-weight" value changes while an animation is active.
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/fontWeight-expected.txt:
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::updateBlendingKeyframes):
(WebCore::KeyframeEffect::computeCSSAnimationBlendingKeyframes):
* Source/WebCore/animation/KeyframeEffect.h:
(WebCore::KeyframeEffect::hasRelativeFontWeight const):
* Source/WebCore/animation/KeyframeEffectStack.cpp:
(WebCore::KeyframeEffectStack::applyKeyframeEffects):
* Source/WebCore/style/StyleResolver.cpp:
(WebCore::Style::Resolver::keyframeStylesForAnimation):
* Source/WebCore/style/StyleResolver.h:
Canonical link: https://commits.webkit.org/259740@main
Canonical link: https://commits.webkit.org/259548.112@safari-7615-branch
Commit: dd9e8f6dd6a2a06e294c3bf03a14006e967bf601
https://github.com/WebKit/WebKit/commit/dd9e8f6dd6a2a06e294c3bf03a14006e967bf601
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
Log Message:
-----------
Cherry-pick 905fdd75fe5d. rdar://problem/104305743
texSubImage2D crashed on iOS16 + WebGL2 + large WASM memory
https://bugs.webkit.org/show_bug.cgi?id=250558
rdar://104305743
Reviewed by Matt Woodrow.
Adjust the input size from the ArrayBufferView byteLength
to the actual image data size texSubImage2D would use.
Fixes crashes where IPC would copy the whole ArrayBufferView into
encoding buffer, causing the WP process size increase.
* Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:
(WebCore::WebGLRenderingContextBase::validateTexFuncData):
Canonical link: https://commits.webkit.org/259742@main
Canonical link: https://commits.webkit.org/259548.113@safari-7615-branch
Commit: 5286a842722831d7bb68a5e615c7928ee29786da
https://github.com/WebKit/WebKit/commit/5286a842722831d7bb68a5e615c7928ee29786da
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/http/tests/webrtc/muted-video-mediastream-invisible-autoplay-expected.txt
A LayoutTests/http/tests/webrtc/muted-video-mediastream-invisible-autoplay.html
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Cherry-pick 44f6600b0181. rdar://problem/101682623
InvisibleAutoplay interruption should be lifted when unmuting a video element that was muted then made invisible
https://bugs.webkit.org/show_bug.cgi?id=251488
rdar://101682623
Reviewed by Eric Carlson.
A muted media element will be suspended for InvisibleAutoplay if it ever made hidden.
While playback will resume if the media element is made visible, it should also resum if the media element stays hidden but is unmuted.
To do this, we call scheduleUpdateShouldAutoplay whenever the media element muted state changes.
This also has the effect that a hidden media element that gets muted will also be paused, until it either gets unmuted or made visible again.
Covered by LayoutTests/http/tests/webrtc/muted-video-mediastream-invisible-autoplay.html.
* LayoutTests/http/tests/webrtc/muted-video-mediastream-invisible-autoplay-expected.txt: Added.
* LayoutTests/http/tests/webrtc/muted-video-mediastream-invisible-autoplay.html: Added.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::setMuted):
Canonical link: https://commits.webkit.org/259744@main
Canonical link: https://commits.webkit.org/259548.114@safari-7615-branch
Commit: b62716368a9b3d6d2bcbcfc34e367c2524bed80d
https://github.com/WebKit/WebKit/commit/b62716368a9b3d6d2bcbcfc34e367c2524bed80d
Author: Brent Fulgham <bfulgham at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WTF/Scripts/GeneratePreferences.rb
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebCore/Scripts/GenerateSettings.rb
M Source/WebKit/UIProcess/API/APIFeatureStatus.h
M Source/WebKit/UIProcess/API/Cocoa/_WKFeature.mm
M Source/WebKitLegacy/mac/WebView/WebFeature.h
Log Message:
-----------
Cherry-pick c4c0ad0db413. rdar://problem/104929045
Use 'mature' instead of 'shipping' to represent stable features
https://bugs.webkit.org/show_bug.cgi?id=251545
<rdar://problem/104929045>
Reviewed by Chris Dumez and Elliott Williams.
Replace 'shipping' with 'mature' in various feature-flag places.
* Source/WTF/Scripts/GeneratePreferences.rb:
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebCore/Scripts/GenerateSettings.rb:
* Source/WebKit/UIProcess/API/APIFeatureStatus.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKFeature.mm:
(-[_WKFeature status]):
* Source/WebKitLegacy/mac/WebView/WebFeature.h:
Canonical link: https://commits.webkit.org/259755@main
Canonical link: https://commits.webkit.org/259548.115@safari-7615-branch
Commit: 459f5629cb783d8ab8bbde94d28eb04f40835faf
https://github.com/WebKit/WebKit/commit/459f5629cb783d8ab8bbde94d28eb04f40835faf
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/animation/custom-property-animation-color-comma-list-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/animation/custom-property-animation-color-space-list-expected.txt
M Source/WebCore/animation/CSSPropertyAnimation.cpp
Log Message:
-----------
Cherry-pick d96394a8f343. rdar://problem/104967426
[web-animations] animation of color list custom properties with iterationComposite is incorrect
https://bugs.webkit.org/show_bug.cgi?id=251574
Reviewed by Antti Koivisto.
Certain types require interpolation for each iteration when `iterationComposite` is used. While we
had logic in place for this in CSSPropertyAnimation::propertyRequiresBlendingForAccumulativeIteration()
for `SyntaxValue` custom properties, we did not for `SyntaxValueList`. We factor the code that determined
whether interpolation was required for the `SyntaxValue` case in a new static method which we now also
call for each value in a `SyntaxValueList`.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/animation/custom-property-animation-color-comma-list-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/animation/custom-property-animation-color-space-list-expected.txt:
* Source/WebCore/animation/CSSPropertyAnimation.cpp:
(WebCore::syntaxValuesRequireBlendingForAccumulativeIteration):
(WebCore::CSSPropertyAnimation::propertyRequiresBlendingForAccumulativeIteration):
Canonical link: https://commits.webkit.org/259761@main
Canonical link: https://commits.webkit.org/259548.116@safari-7615-branch
Commit: 9f72040287e125651b0d927d2718eba6caaad03b
https://github.com/WebKit/WebKit/commit/9f72040287e125651b0d927d2718eba6caaad03b
Author: Ben Nham <nham at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/webpushd/PushService.mm
Log Message:
-----------
Cherry-pick df642c8ddfa4. rdar://problem/104946575
Change sensitivity level of webpushd diagnostic logs
https://bugs.webkit.org/show_bug.cgi?id=251602
rdar://104946575
Reviewed by Brady Eidson.
Make scope and topic logging of Web Push subscriptions sensitive by default, which affects how they
are logged on internal builds. This has no effect on customer builds, since both private and
sensitive log strings are redacted on such builds.
* Source/WebKit/webpushd/PushService.mm:
(WebPushD::PushServiceRequestImpl::fulfill):
(WebPushD::PushServiceRequestImpl::reject):
(WebPushD::SubscribeRequest::startImpl):
(WebPushD::UnsubscribeRequest::startInternal):
(WebPushD::PushService::incrementSilentPushCount):
(WebPushD::PushService::removeRecordsForSubscriptionSetAndOrigin):
(WebPushD::PushService::removeRecordsImpl):
(WebPushD::PushService::didReceivePushMessage):
Canonical link: https://commits.webkit.org/259764@main
Canonical link: https://commits.webkit.org/259548.117@safari-7615-branch
Commit: c7d297dff8058084760106c275914f46d77def99
https://github.com/WebKit/WebKit/commit/c7d297dff8058084760106c275914f46d77def99
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp
M Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp
Log Message:
-----------
Cherry-pick e10384deeabd. rdar://problem/104531316
Fix use-after-move in CacheStorageCache::putRecordsInStore
https://bugs.webkit.org/show_bug.cgi?id=251467
rdar://104531316
Reviewed by Youenn Fablet.
CacheStorageCache::putRecordsInStore should not use WTFMove on members of existingRecord because existingRecord will
be accessed later (existingRecord points to an object in m_records). This patch also ensures CacheStorageCache is
unregistered from CacheStorageRegistry when it is removed, so CacheStorageRegistry could remove the entry from m_caches.
* Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp:
(WebKit::CacheStorageCache::putRecordsInStore):
* Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp:
(WebKit::CacheStorageManager::removeUnusedCache):
Canonical link: https://commits.webkit.org/259766@main
Canonical link: https://commits.webkit.org/259548.118@safari-7615-branch
Commit: 4b99d31670871db00baa1d247b6d897c8b1e7ee1
https://github.com/WebKit/WebKit/commit/4b99d31670871db00baa1d247b6d897c8b1e7ee1
Author: Cameron McCormack <heycam at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp
Log Message:
-----------
Cherry-pick cb846ec74099. rdar://problem/104619725
iOS-only revert of bug 249561 for causing memory regression
https://bugs.webkit.org/show_bug.cgi?id=251559
rdar://104619725
Reviewed by Brent Fulgham.
Unclear why, but for now let's leave the change on macOS and revert elsewhere.
* Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:
(WebCore::FontCache::platformReleaseNoncriticalMemory):
Canonical link: https://commits.webkit.org/259769@main
Canonical link: https://commits.webkit.org/259548.119@safari-7615-branch
Commit: a8626ec283f027c6f0b5f3c1a04cea2f70304265
https://github.com/WebKit/WebKit/commit/a8626ec283f027c6f0b5f3c1a04cea2f70304265
Author: Cameron McCormack <heycam at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/svg/SVGElement.cpp
M Source/WebCore/svg/SVGElement.h
M Source/WebCore/svg/SVGElementRareData.h
M Source/WebCore/svg/SVGTests.cpp
M Source/WebCore/svg/SVGTests.h
M Source/WebCore/svg/properties/SVGPropertyAccessorImpl.h
M Source/WebCore/svg/properties/SVGPropertyOwnerRegistry.h
Log Message:
-----------
Cherry-pick a0e6d8e81896. rdar://problem/104849618
Move SVG conditional processing attributes to SVGElementRareData
https://bugs.webkit.org/show_bug.cgi?id=251413
rdar://problem/104849618
Reviewed by Sam Weinig and Said Abou-Hallawa.
The SVG conditional processing attributes (requiredFeatures, requiredExtensions,
and systemLanguage) are rarely used. Currently nearly every SVG element creates
SVGStringList objects for these three attributes in WebCore::SVGTests, at a cost
of 48 bytes each SVGStringList plus the three pointers. We can move these to
SVGElementRareData to save 72 bytes per SVG element in this common case, which
for SVG documents with a large number of graphical elements can add up.
The existing SVG property registration mechanism expects members
corresponding to the attribute to exist on the owner element object. We adds a
new SVGConditionalProcessingAttributeAccessor for these three
attributes, which looks them up on the element's SVGElementRareData.
* Source/WebCore/svg/SVGAnimationElement.cpp:
(WebCore::SVGAnimationElement::SVGAnimationElement):
* Source/WebCore/svg/SVGCursorElement.cpp:
(WebCore::SVGCursorElement::SVGCursorElement):
* Source/WebCore/svg/SVGElement.cpp:
(WebCore::SVGElement::conditionalProcessingAttributes):
(WebCore::SVGElement::conditionalProcessingAttributesIfExists const):
* Source/WebCore/svg/SVGElement.h:
* Source/WebCore/svg/SVGElementRareData.h:
(WebCore::SVGElementRareData::conditionalProcessingAttributesIfExists const):
(WebCore::SVGElementRareData::conditionalProcessingAttributes):
* Source/WebCore/svg/SVGGraphicsElement.cpp:
(WebCore::SVGGraphicsElement::SVGGraphicsElement):
* Source/WebCore/svg/SVGMaskElement.cpp:
(WebCore::SVGMaskElement::SVGMaskElement):
* Source/WebCore/svg/SVGPatternElement.cpp:
(WebCore::SVGPatternElement::SVGPatternElement):
* Source/WebCore/svg/SVGTests.cpp:
(WebCore::SVGConditionalProcessingAttributes::SVGConditionalProcessingAttributes):
(WebCore::SVGTests::SVGTests):
(WebCore::SVGTests::isValid const):
(WebCore::SVGTests::parseAttribute):
(WebCore::SVGTests::conditionalProcessingAttributes):
(WebCore::SVGTests::conditionalProcessingAttributesIfExists const):
* Source/WebCore/svg/SVGTests.h:
(WebCore::SVGConditionalProcessingAttributes::requiredFeatures):
(WebCore::SVGConditionalProcessingAttributes::requiredExtensions):
(WebCore::SVGConditionalProcessingAttributes::systemLanguage):
(WebCore::SVGTests::requiredFeatures):
(WebCore::SVGTests::requiredExtensions):
(WebCore::SVGTests::systemLanguage):
* Source/WebCore/svg/properties/SVGPropertyAccessorImpl.h:
(WebCore::SVGConditionalProcessingAttributeAccessor<OwnerType>::singleton):
* Source/WebCore/svg/properties/SVGPropertyOwnerRegistry.h:
(WebCore::SVGPropertyOwnerRegistry::registerConditionalProcessingAttributeProperty):
Canonical link: https://commits.webkit.org/259772@main
Canonical link: https://commits.webkit.org/259548.120@safari-7615-branch
Commit: 23dfafccde00df898925f8eb383c4048a4778af4
https://github.com/WebKit/WebKit/commit/23dfafccde00df898925f8eb383c4048a4778af4
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
R LayoutTests/http/tests/security/contentSecurityPolicy/resources/track.vtt.py
M LayoutTests/http/tests/security/contentSecurityPolicy/track-redirect-allowed.html
M LayoutTests/http/tests/security/contentSecurityPolicy/track-redirect-allowed2.html
M LayoutTests/http/tests/security/contentSecurityPolicy/track-redirect-blocked-expected.txt
M LayoutTests/http/tests/security/contentSecurityPolicy/track-redirect-blocked.html
M LayoutTests/http/tests/security/text-track-crossorigin-expected.txt
M LayoutTests/http/tests/security/text-track-crossorigin.html
M LayoutTests/imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/track/track-element/cloneNode-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/track/track-element/track-data-url-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/service-workers/service-worker/webvtt-cross-origin.https-expected.txt
M Source/WebCore/loader/TextTrackLoader.cpp
Log Message:
-----------
Cherry-pick cc2a0b3996b2. rdar://problem/104493270
REGRESSION(249934 at main): Captions fail to load on ESPN.com
https://bugs.webkit.org/show_bug.cgi?id=251539
rdar://104493270
Reviewed by Eric Carlson and Youenn Fablet.
Revert 249934 at main
Canonical link: https://commits.webkit.org/259781@main
Canonical link: https://commits.webkit.org/259548.121@safari-7615-branch
Commit: d2a28969b776c07033d0ae17d956d39a41d4f41a
https://github.com/WebKit/WebKit/commit/d2a28969b776c07033d0ae17d956d39a41d4f41a
Author: Brent Fulgham <bfulgham at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
Log Message:
-----------
Cherry-pick fc1e58ebbeac. rdar://problem/104979142
Disable CSS Nesting by default
https://bugs.webkit.org/show_bug.cgi?id=251636
<rdar://problem/104979142>
Reviewed by Tim Nguyen.
Turn Nesting off for customer builds, but retain for prerelease
builds.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Canonical link: https://commits.webkit.org/259787@main
Canonical link: https://commits.webkit.org/259548.122@safari-7615-branch
Commit: 6d7488822cc4f8303c21320a6632c067afd12f86
https://github.com/WebKit/WebKit/commit/6d7488822cc4f8303c21320a6632c067afd12f86
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M JSTests/wasm/stress/tail-call-should-not-clobber-caller-origin.js
M JSTests/wasm/v8/indirect-call-non-zero-table.js
M Source/JavaScriptCore/runtime/OptionsList.h
Log Message:
-----------
Cherry-pick 3eb123c1f36f. rdar://problem/104987053
[JSC] Disable wasm tail-call because of several necessary things
https://bugs.webkit.org/show_bug.cgi?id=251656
rdar://104987053
Reviewed by Mark Lam.
This change disables wasm tail-calls since we still need several things to make it work correctly.
1. All wasm function calls need to adjust stack-pointer after the call. This is necessary thing for the support of tail-call,
but currently it is not done yet. Since tail-call can adjust the stack-pointer of the caller, the stack-pointer value can become
different after the tail-call happens from the caller's view. Since B3 etc. are freely accessing to stack slots via stack-pointer,
and since stack-pointer needs to be the same during the procedure, the adjustment is required to make things work.
In JS world, we are doing this adjustment: BaselineJIT's resetSP for example. Previously, since wasm does not have tail-calls,
wasm call is not doing this adjustment. Now, we should do that.
2. We should not change offset of StackSlots. This is not a supported operation by B3 / Air.
For now, we disable wasm tail-call.
* Source/JavaScriptCore/runtime/OptionsList.h:
Canonical link: https://commits.webkit.org/259801@main
Canonical link: https://commits.webkit.org/259548.123@safari-7615-branch
Commit: 36c3b023dd016e4890e542db6181758d874cab47
https://github.com/WebKit/WebKit/commit/36c3b023dd016e4890e542db6181758d874cab47
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation.html
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/css/CSSCustomPropertyValue.cpp
M Source/WebCore/css/CSSCustomPropertyValue.h
M Source/WebCore/style/StyleResolver.cpp
M Source/WebCore/style/StyleResolver.h
Log Message:
-----------
Cherry-pick b1a5811b3017. rdar://problem/104997994
[web-animations] keyframes should be recomputed when the "currentcolor" value is used on a custom property
https://bugs.webkit.org/show_bug.cgi?id=251591
Reviewed by Antti Koivisto.
We keep a set of CSS properties set to "currentcolor" in a KeyframeEffect but until now only considered
"standard" CSS properties. We now also consider custom properties by changing the set's type from
HashSet<CSSPropertyID> to HashSet<AnimatableProperty>.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation.html:
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::updateBlendingKeyframes):
* Source/WebCore/animation/KeyframeEffect.h:
* Source/WebCore/css/CSSCustomPropertyValue.cpp:
(WebCore::CSSCustomPropertyValue::isCurrentColor const):
* Source/WebCore/css/CSSCustomPropertyValue.h:
* Source/WebCore/style/StyleResolver.cpp:
(WebCore::Style::Resolver::keyframeStylesForAnimation):
* Source/WebCore/style/StyleResolver.h:
Canonical link: https://commits.webkit.org/259808@main
Canonical link: https://commits.webkit.org/259548.124@safari-7615-branch
Commit: 254a133cd4aa05f18c53ee265dd4bc9c73778fd0
https://github.com/WebKit/WebKit/commit/254a133cd4aa05f18c53ee265dd4bc9c73778fd0
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation.html
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/css/CSSCustomPropertyValue.h
M Source/WebCore/style/StyleResolver.cpp
M Source/WebCore/style/StyleResolver.h
Log Message:
-----------
Cherry-pick a2b572c83047. rdar://problem/105003138
[web-animations] keyframes should be recomputed when a parent element changes value for a custom property set to "inherit"
https://bugs.webkit.org/show_bug.cgi?id=251596
Reviewed by Antti Koivisto.
We keep a set of CSS properties set to "inherit" in a KeyframeEffect but until now only considered
"standard" CSS properties. We now also consider custom properties by changing the set's type from
HashSet<CSSPropertyID> to HashSet<AnimatableProperty>.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation.html:
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::updateBlendingKeyframes):
* Source/WebCore/animation/KeyframeEffect.h:
(WebCore::KeyframeEffect::inheritedProperties const):
* Source/WebCore/css/CSSCustomPropertyValue.h:
* Source/WebCore/style/StyleResolver.cpp:
(WebCore::Style::Resolver::keyframeStylesForAnimation):
* Source/WebCore/style/StyleResolver.h:
Canonical link: https://commits.webkit.org/259812@main
Canonical link: https://commits.webkit.org/259548.125@safari-7615-branch
Commit: 74bbefb2944458a8e1588e2bf937aa67d295905d
https://github.com/WebKit/WebKit/commit/74bbefb2944458a8e1588e2bf937aa67d295905d
Author: Nikolaos Mouchtaris <nmouchtaris at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/platform/ios/TestExpectations
M Source/WTF/wtf/PlatformHave.h
M Source/WebCore/platform/graphics/cg/UTIRegistry.cpp
Log Message:
-----------
Cherry-pick ca9f53c112bc. rdar://problem/102490238
AVIF images do not render in iOS Simulator
https://bugs.webkit.org/show_bug.cgi?id=247831
rdar://102534920
Reviewed by Said Abou-Hallawa.
In iOS simulator we are not decoding AVIF images because in
defaultSupportedImageTypes we are filtering the image types
based on CGImageSourceCopyTypeIdentifiers. Currently this
function is not returning public.avif so we do not decode the
image. To workaround this, we add the avif related types after
filtering the image types. I filed rdar://104940377 to get
CGImageSourceCopyTypeIdentifiers returning public.avif in
the iOS simulator.
* Source/WebCore/platform/graphics/cg/UTIRegistry.cpp:
(WebCore::defaultSupportedImageTypes):
Canonical link: https://commits.webkit.org/259819@main
Canonical link: https://commits.webkit.org/259548.126@safari-7615-branch
Commit: b530c67be3d3d040ef8b8658b6343663de71bc5b
https://github.com/WebKit/WebKit/commit/b530c67be3d3d040ef8b8658b6343663de71bc5b
Author: Ben Nham <nham at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WTF/wtf/Assertions.h
M Source/WebCore/workers/service/server/SWServer.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm
M Source/WebKit/UIProcess/Notifications/WebNotificationManagerProxy.cpp
Log Message:
-----------
Cherry-pick f83957784da9. rdar://problem/104977357
Change sensitivity level of webpushd diagnostic logs (take 2)
https://bugs.webkit.org/show_bug.cgi?id=251631
rdar://104977357
Reviewed by Brady Eidson.
Fix some additional places where we log the scope of a push subscription with a private instead of
sensitive log level. We already did some of this in 259764 at main but missed a few callsites that used
a different log level macro.
* Source/WTF/wtf/Assertions.h:
* Source/WebCore/workers/service/server/SWServer.cpp:
(WebCore::SWServer::processPushMessage):
(WebCore::SWServer::processNotificationEvent):
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::processPushMessage):
* Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm:
(-[WKWebsiteDataStore _processPushMessage:completionHandler:]):
(-[WKWebsiteDataStore _processPersistentNotificationClick:completionHandler:]):
(-[WKWebsiteDataStore _processPersistentNotificationClose:completionHandler:]):
* Source/WebKit/UIProcess/Notifications/WebNotificationManagerProxy.cpp:
(WebKit::WebNotificationManagerProxy::providerDidUpdateNotificationPolicy):
Canonical link: https://commits.webkit.org/259827@main
Canonical link: https://commits.webkit.org/259548.127@safari-7615-branch
Commit: 78090ccd1b25763284832db0b854b4440d9e537e
https://github.com/WebKit/WebKit/commit/78090ccd1b25763284832db0b854b4440d9e537e
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/svg/painting/parsing/stroke-dasharray-computed-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/strokeDasharray-expected.txt
M LayoutTests/svg/css/scientific-numbers-expected.txt
M LayoutTests/svg/css/scientific-numbers.html
M Source/WebCore/style/StyleBuilderConverter.h
M Source/WebCore/style/StyleBuilderCustom.h
M Source/WebCore/svg/SVGLengthValue.cpp
M Source/WebCore/svg/SVGLengthValue.h
Log Message:
-----------
Cherry-pick af0cc1eb786a. rdar://problem/105018931
SVGLengthValue::fromCSSPrimitiveValue() doesn't have enough context to resolve font-relative units
https://bugs.webkit.org/show_bug.cgi?id=204826
Reviewed by Antti Koivisto.
Pass a CSSToLengthConversionData argument to SVGLengthValue::fromCSSPrimitiveValue() such that we
may call computeLength() on the provided primitive value to resolve font-relative units.
This also changes the behavior of baseline-shift which now accounts for ex units, so
adjusting the relevant test to include a font to have reliable measurements across platforms
and a new expected value.
* LayoutTests/imported/w3c/web-platform-tests/svg/painting/parsing/stroke-dasharray-computed-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/responsive/strokeDasharray-expected.txt:
* LayoutTests/svg/css/scientific-numbers-expected.txt:
* LayoutTests/svg/css/scientific-numbers.html:
* Source/WebCore/style/StyleBuilderConverter.h:
(WebCore::Style::BuilderConverter::convertSVGLengthValue):
* Source/WebCore/style/StyleBuilderCustom.h:
(WebCore::Style::BuilderCustom::applyValueBaselineShift):
* Source/WebCore/svg/SVGLengthValue.cpp:
(WebCore::SVGLengthValue::fromCSSPrimitiveValue):
* Source/WebCore/svg/SVGLengthValue.h:
Canonical link: https://commits.webkit.org/259836@main
Canonical link: https://commits.webkit.org/259548.128@safari-7615-branch
Commit: 574ce8b32634d6e69290728ec40ee566149b76a2
https://github.com/WebKit/WebKit/commit/574ce8b32634d6e69290728ec40ee566149b76a2
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
Log Message:
-----------
Cherry-pick 78b297d677ce. rdar://problem/105019096
[web-animations] KeyframeEffect::setBlendingKeyframes() should take in an rvalue reference
https://bugs.webkit.org/show_bug.cgi?id=251717
Reviewed by Simon Fraser.
This method's purpose is to provide a KeyframeList that KeyframeEffect will take
ownership of, so it should be an rvalue reference.
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::copyPropertiesFromSource):
(WebCore::KeyframeEffect::updateBlendingKeyframes):
(WebCore::KeyframeEffect::setBlendingKeyframes):
(WebCore::KeyframeEffect::computeCSSAnimationBlendingKeyframes):
(WebCore::KeyframeEffect::computeCSSTransitionBlendingKeyframes):
* Source/WebCore/animation/KeyframeEffect.h:
Canonical link: https://commits.webkit.org/259837@main
Canonical link: https://commits.webkit.org/259548.129@safari-7615-branch
Commit: 7b27ad44f5b3f24ce9301887c6700cf212632d05
https://github.com/WebKit/WebKit/commit/7b27ad44f5b3f24ce9301887c6700cf212632d05
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/animation/CSSPropertyAnimation.cpp
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/animation/KeyframeEffectStack.cpp
M Source/WebCore/css/CSSKeyframeRule.cpp
M Source/WebCore/css/CSSKeyframeRule.h
M Source/WebCore/rendering/style/KeyframeList.cpp
M Source/WebCore/rendering/style/KeyframeList.h
M Source/WebCore/style/StyleResolver.cpp
M Source/WebCore/style/StyleResolver.h
Log Message:
-----------
Cherry-pick 7a34ce6d9914. rdar://problem/105019146
[web-animations] clean up the keyframe recomputation code on style change
https://bugs.webkit.org/show_bug.cgi?id=251674
Reviewed by Antti Koivisto.
We landed a fair few changes recently to recompute keyframes when style changes while animations are
active. The ever-increasing list of parameters passed to Style::Resolver::keyframeStylesForAnimation()
as well as the ever-growing list of change checks made in KeyframeEffectStack::applyKeyframeEffects()
could do with some cleaning up.
We add a new KeyframeList::updatePropertiesMetadata() method which takes in a StyleProperties
and gathers information on the rule's StyleProperties relevant to keyframe recomputation: whether
"inherit" or "currentcolor" values are set, whether CSS variable values are used, whether a relative
font-weight value is set. This replaces duplicated logic found in Style::Resolver (in the CSS Animations
case) and KeyframeEffect (in the JS-originated case) when computing keyframes.
This method is called in Style::Resolver::keyframeStylesForAnimation() and KeyframeEffect::updateBlendingKeyframes().
This allows us to remove the matching information previously stored on KeyframeEffect.
We move all the logic from KeyframeEffectStack::applyKeyframeEffects() related to checking
whether some properties change to a new KeyframeEffect::recomputeKeyframesIfNecessary() which
will query the KeyframeList.
The code is now clearer and any future change to recompute keyframes will no longer require code
duplication.
Doing this refactor also uncovered a small error in the animation wrapper for text-indent which would
not check for the RenderStyle::textIndentLine() and RenderStyle::textIndentType() bits to determine
whether two text-indent were equal. This was likely due to change in the order of functions we use to check
whether a recomputation is required in the new KeyframeEffect::recomputeKeyframesIfNecessary().
* Source/WebCore/animation/CSSPropertyAnimation.cpp:
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::updateBlendingKeyframes):
(WebCore::KeyframeEffect::computeCSSAnimationBlendingKeyframes):
(WebCore::KeyframeEffect::recomputeKeyframesIfNecessary):
(WebCore::KeyframeEffect::animatesDirectionAwareProperty const): Deleted.
(WebCore::KeyframeEffect::propertyAffectingKeyframeResolutionDidChange): Deleted.
(WebCore::KeyframeEffect::hasPropertySetToCurrentColor const): Deleted.
(WebCore::KeyframeEffect::hasColorSetToCurrentColor const): Deleted.
* Source/WebCore/animation/KeyframeEffect.h:
(WebCore::KeyframeEffect::inheritedProperties const): Deleted.
(WebCore::KeyframeEffect::containsCSSVariableReferences const): Deleted.
(WebCore::KeyframeEffect::hasExplicitlyInheritedKeyframeProperty const): Deleted.
(WebCore::KeyframeEffect::hasRelativeFontWeight const): Deleted.
* Source/WebCore/animation/KeyframeEffectStack.cpp:
(WebCore::KeyframeEffectStack::applyKeyframeEffects):
* Source/WebCore/css/CSSKeyframeRule.cpp:
(WebCore::StyleRuleKeyframe::containsCSSVariableReferences const): Deleted.
* Source/WebCore/css/CSSKeyframeRule.h:
* Source/WebCore/rendering/style/KeyframeList.cpp:
(WebCore::KeyframeList::clear):
(WebCore::KeyframeList::usesRelativeFontWeight const):
(WebCore::KeyframeList::hasCSSVariableReferences const):
(WebCore::KeyframeList::hasColorSetToCurrentColor const):
(WebCore::KeyframeList::hasPropertySetToCurrentColor const):
(WebCore::KeyframeList::propertiesSetToInherit const):
(WebCore::KeyframeList::updatePropertiesMetadata):
* Source/WebCore/rendering/style/KeyframeList.h:
* Source/WebCore/style/StyleResolver.cpp:
(WebCore::Style::Resolver::keyframeStylesForAnimation):
* Source/WebCore/style/StyleResolver.h:
Canonical link: https://commits.webkit.org/259838@main
Canonical link: https://commits.webkit.org/259548.130@safari-7615-branch
Commit: aecd66f21c955e8d9739884a077137b09f7dd65b
https://github.com/WebKit/WebKit/commit/aecd66f21c955e8d9739884a077137b09f7dd65b
Author: Yijia Huang <yijia_huang at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A JSTests/stress/try-catch-backwards-propagation.js
M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
M Source/JavaScriptCore/dfg/DFGGraph.cpp
M Source/JavaScriptCore/dfg/DFGGraph.h
M Source/JavaScriptCore/dfg/DFGLiveCatchVariablePreservationPhase.cpp
M Source/JavaScriptCore/dfg/DFGPlan.cpp
Log Message:
-----------
Cherry-pick 5e1033a7cd03. rdar://problem/92654142
Fix variable liveness for try catch in DFG
https://bugs.webkit.org/show_bug.cgi?id=239758
rdar://92654142
Reviewed by Yusuke Suzuki.
There is no successor and predecessor relationship between try and catch
block in DFG, in other words node flags cannot be passed from catch block
to its `predecessors`. If a variable defined outside the try catch block
but only be used in the catch block, then our compiler would mis-analyze
the liveness of the varible w.r.t the catch block. Therefore,
`LiveCatchVariablePreservationPhase` should be to performed before backwards propagation.
* JSTests/stress/try-catch-backwards-propagation.js: Added.
(throwFunction):
(foo1):
(foo2):
(foo3):
(foo4):
(foo5):
(foo6):
(foo7):
(foo8):
(foo9):
(foo10):
(foo11):
(foo12):
(opt):
* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parse):
* Source/JavaScriptCore/dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::LiveCatchVariablePreservationPhase::LiveCatchVariablePreservationPhase):
(JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
(JSC::DFG::performLiveCatchVariablePreservationPhase):
* Source/JavaScriptCore/dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
Canonical link: https://commits.webkit.org/259839@main
Canonical link: https://commits.webkit.org/259548.131@safari-7615-branch
Commit: bfe24ab1eab6e557c89d0dddf59bcc7cdbae689e
https://github.com/WebKit/WebKit/commit/bfe24ab1eab6e557c89d0dddf59bcc7cdbae689e
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/fast/inline/text_overflow_ellipsis_simple-expected.html
A LayoutTests/fast/inline/text_overflow_ellipsis_simple.html
M Source/WebCore/layout/formattingContexts/inline/InlineFormattingContext.cpp
M Source/WebCore/layout/formattingContexts/inline/InlineFormattingContext.h
M Source/WebCore/layout/formattingContexts/inline/InlineLine.cpp
M Source/WebCore/layout/formattingContexts/inline/InlineLine.h
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.h
M Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayBox.h
M Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.cpp
M Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.h
M Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLine.h
M Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp
M Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.h
Log Message:
-----------
Cherry-pick ff75ee6b051e. rdar://problem/105029885
[RTL/bidi/vertical] Incorrect content truncation when "text-overflow" is "ellipsis"
https://bugs.webkit.org/show_bug.cgi?id=251608
Reviewed by Antti Koivisto.
In this patch inline content truncation (overflow: hidden + text-overflow: ellipsis) is moved from logical to visual space.
It ensures that the truncation happens _after_ bidi reordering and also _after_ applying writing-mode.
Now instead of running truncation as part of the trailing content handling in LineBuilder::close right after we figured the breaking position for
the inline content, we do it after constructing the display boxes (and the associated display line).
1. Remove truncation code from Line::Run and all the related code all the way to display line construction.
2. Introduce truncateOverflowingDisplayBoxes. It applies truncation on display box in visual order (the truncation logic is actually moved from Line::Run, nothing really new here).
* LayoutTests/fast/inline/text_overflow_ellipsis_simple-expected.html: Added.
* LayoutTests/fast/inline/text_overflow_ellipsis_simple.html: Added.
* Source/WebCore/layout/formattingContexts/inline/InlineFormattingContext.cpp:
(WebCore::Layout::lineEndingEllipsisPolicy):
(WebCore::Layout::InlineFormattingContext::lineLayout):
(WebCore::Layout::InlineFormattingContext::createDisplayContentForLine):
* Source/WebCore/layout/formattingContexts/inline/InlineFormattingContext.h:
* Source/WebCore/layout/formattingContexts/inline/InlineLine.cpp:
(WebCore::Layout::Line::initialize):
(WebCore::Layout::Line::Run::detachTrailingWhitespace):
(WebCore::Layout::Line::truncate): Deleted.
(WebCore::Layout::Line::Run::truncate): Deleted.
* Source/WebCore/layout/formattingContexts/inline/InlineLine.h:
(WebCore::Layout::Line::isContentTruncated const): Deleted.
(WebCore::Layout::Line::Run::isTruncated const): Deleted.
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp:
(WebCore::Layout::LineBuilder::layoutInlineContent):
(WebCore::Layout::LineBuilder::computedIntrinsicWidth):
(WebCore::Layout::LineBuilder::close):
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.h:
* Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayBox.h:
(WebCore::InlineDisplay::Box::Text::setPartiallyVisibleContentLength):
(WebCore::InlineDisplay::Box::Box):
(WebCore::InlineDisplay::Box::setLeft):
(WebCore::InlineDisplay::Box::setIsFullyTruncated):
(WebCore::InlineDisplay::Box::Text::Text):
* Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.cpp:
(WebCore::Layout::InlineDisplayContentBuilder::appendTextDisplayBox):
(WebCore::Layout::InlineDisplayContentBuilder::appendAtomicInlineLevelDisplayBox):
(WebCore::Layout::InlineDisplayContentBuilder::appendInlineBoxDisplayBox):
(WebCore::Layout::InlineDisplayContentBuilder::appendSpanningInlineBoxDisplayBox):
* Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.h:
(WebCore::Layout::InlineDisplayContentBuilder::rootStyle const):
* Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLine.h:
(WebCore::InlineDisplay::Line::setEllipsisVisualRect):
(WebCore::InlineDisplay::Line::Line):
* Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp:
(WebCore::Layout::flipLogicalLineRectToVisualForWritingMode):
(WebCore::Layout::InlineDisplayLineBuilder::build const):
(WebCore::Layout::truncateOverflowingDisplayBoxes):
(WebCore::Layout::InlineDisplayLineBuilder::trailingEllipsisVisualRect):
(WebCore::Layout::InlineDisplayLineBuilder::trailingEllipsisRect const): Deleted.
(WebCore::Layout::InlineDisplayLineBuilder::flipLogicalLineRectToVisualForWritingMode const): Deleted.
* Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.h:
Canonical link: https://commits.webkit.org/259850@main
Canonical link: https://commits.webkit.org/259548.132@safari-7615-branch
Commit: d1ce86643246c01e93cc8147aa687210d3cdc5b0
https://github.com/WebKit/WebKit/commit/d1ce86643246c01e93cc8147aa687210d3cdc5b0
Author: Cameron McCormack <heycam at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/css/StyleRule.cpp
M Source/WebCore/css/StyleRule.h
Log Message:
-----------
Cherry-pick aea4f3f29a7c. rdar://problem/105046580
Shrink StyleRule by reducing padding and moving CSS Nesting fields to a rare data object
https://bugs.webkit.org/show_bug.cgi?id=251744
rdar://105046580
Reviewed by Simon Fraser.
This reduces StyleRule from 64 to 40 bytes.
* Source/WebCore/css/StyleRule.cpp:
(WebCore::StyleRuleRareData::createIfNeeded):
(WebCore::StyleRule::StyleRule):
(WebCore::StyleRule::rareData const):
(WebCore::StyleRule::setNestedRules):
(WebCore::StyleRule::setResolvedSelectorList const):
(WebCore::emptyRuleVector):
(WebCore::StyleRule::nestedRules const):
* Source/WebCore/css/StyleRule.h:
(WebCore::StyleRuleRareData::createIfNeeded):
Canonical link: https://commits.webkit.org/259875@main
Canonical link: https://commits.webkit.org/259548.133@safari-7615-branch
Commit: 96344ac7fb6f4df3807c0cdcc0c6af16aa20ab72
https://github.com/WebKit/WebKit/commit/96344ac7fb6f4df3807c0cdcc0c6af16aa20ab72
Author: Antti Koivisto <antti at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/layout/integration/LayoutIntegrationBoxTree.cpp
Log Message:
-----------
Cherry-pick 470080c7ba5f. rdar://problem/105025598
LayoutIntegration::BoxTree::m_renderers wastes 16KB of vector capacity
https://bugs.webkit.org/show_bug.cgi?id=251726
rdar://105025598
Reviewed by Simon Fraser.
* Source/WebCore/layout/integration/LayoutIntegrationBoxTree.cpp:
(WebCore::LayoutIntegration::BoxTree::buildTreeForInlineContent):
(WebCore::LayoutIntegration::BoxTree::buildTreeForFlexContent):
shrinkToFit() the vector
Canonical link: https://commits.webkit.org/259895@main
Canonical link: https://commits.webkit.org/259548.134@safari-7615-branch
Commit: a4b0a9202145a93737024a38094bef4a9e7257d9
https://github.com/WebKit/WebKit/commit/a4b0a9202145a93737024a38094bef4a9e7257d9
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/layout/floats/FloatingState.cpp
M Source/WebCore/layout/floats/FloatingState.h
M Source/WebCore/layout/formattingContexts/block/BlockFormattingState.cpp
M Source/WebCore/layout/formattingContexts/block/BlockFormattingState.h
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp
Log Message:
-----------
Cherry-pick f2ad1fd561f5. rdar://problem/105025457
FloatingState::m_floats wastes 30KB of vector capacity
https://bugs.webkit.org/show_bug.cgi?id=251725
<rdar://problem/105025457>
Reviewed by Antti Koivisto.
Introduce shrinkToFit to BlockFormattingState (which we already have on InlineFormattingState).
* Source/WebCore/layout/floats/FloatingState.cpp:
(WebCore::Layout::FloatingState::shrinkToFit):
* Source/WebCore/layout/floats/FloatingState.h:
* Source/WebCore/layout/formattingContexts/block/BlockFormattingState.cpp:
(WebCore::Layout::BlockFormattingState::shrinkToFit):
* Source/WebCore/layout/formattingContexts/block/BlockFormattingState.h:
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp:
(WebCore::LayoutIntegration::LineLayout::constructContent):
Canonical link: https://commits.webkit.org/259909@main
Canonical link: https://commits.webkit.org/259548.135@safari-7615-branch
Commit: 15a5c5f4055c8a82b5b0db3f0dfa5041500dd30a
https://github.com/WebKit/WebKit/commit/15a5c5f4055c8a82b5b0db3f0dfa5041500dd30a
Author: Cameron McCormack <heycam at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/fast/css/lang-matching-document-invalidation-expected.txt
A LayoutTests/fast/css/lang-matching-document-invalidation.html
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Element.h
M Source/WebCore/dom/ElementData.cpp
M Source/WebCore/dom/ElementData.h
M Source/WebCore/dom/EventTarget.h
Log Message:
-----------
Cherry-pick 8858f1de792a. rdar://problem/104987630
Avoid storing effective language on ElementRareData when it matches the effective document element language
https://bugs.webkit.org/show_bug.cgi?id=251657
<rdar://problem/104987630>
Reviewed by Ryosuke Niwa.
When an element's lang attribute is set, we set the effective language on
the ElementRareData of all elements in the subtree. We have an existing
optimization that avoids this if we're setting it on the document
element. There are some pages, like Wikipedia, that set an explicit
lang on some other element in the body of the page, but which matches
the document element's lang.
We can avoid the memory overhead of allocating ElementRareData to store
the effective language in this case by using a flag on the element. On
large Wikipedia pages this can save several MB.
If the document element language changes later, we must update the
effective lang state on subtrees that are using this flag. A WeakHashSet
is added to Document to track elements that have an explicit lang
attribute that matches the effective document element language.
Three flags on EventTarget are introduced:
- HasLangAttr and HasXMLLangAttr: records that the element has the
corresponding lang attribute. This allows us to avoid searching
for an attribute when updating the effective lang state.
- EffectiveLangKnownToMatchDocument: records that the element has an
effective lang that matches the effective document element language,
whether it's due to an explicit lang attribute or inherited from an
ancestor. This flag is used in place of
ElementRareData::m_effectiveLang.
The EffectiveLangKnownToMatchDocument flag is used in place of the "null
effective language means we've inherited the effective document
language" state so that disconnected subtrees can also make use of this
optimization. Otherwise, for a case like this:
let e = document.createElement("div");
e.lang = "en"; // matching document
e.append(document.createElement("div"));
the child element would not know whether to return nullptr or "en" from
Element::effectiveLang() without looking up the tree to see if there is
an ancestor with a langauge attribute.
The EffectiveLangKnownToMatchDocument flag is not
EffectiveLangMatchesDocument, since we don't set it if the document
element language changes and an existing element starts matching it.
Rather than track all elements with lang attributes to handle such
cases, we leave the effective lang stored on the ElementRareData.
* LayoutTests/fast/css/lang-matching-document-invalidation-expected.txt: Added.
* LayoutTests/fast/css/lang-matching-document-invalidation.html: Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setDocumentElementLanguage):
(WebCore::Document::addElementWithLangAttrMatchingDocument):
(WebCore::Document::removeElementWithLangAttrMatchingDocument):
* Source/WebCore/dom/Document.h:
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::~Element):
(WebCore::Element::attributeChanged):
(WebCore::Element::setEffectiveLangInSubtree):
(WebCore::Element::didMoveToNewDocument):
(WebCore::Element::setEffectiveLangFromParent):
(WebCore::Element::setEffectiveLang):
(WebCore::Element::insertedIntoAncestor):
(WebCore::Element::hasEffectiveLangState const):
(WebCore::Element::removedFromAncestor):
(WebCore::Element::effectiveLang const):
(WebCore::Element::langFromAttribute const):
(WebCore::Element::langAttrMatchesDocument const):
(WebCore::Element::setLangAttrMatchesDocument):
(WebCore::Element::effectiveLangMatchesDocument const):
(WebCore::Element::setEffectiveLangMatchesDocument):
* Source/WebCore/dom/Element.h:
* Source/WebCore/dom/EventTarget.h:
Canonical link: https://commits.webkit.org/259931@main
Canonical link: https://commits.webkit.org/259548.136@safari-7615-branch
Commit: d8def5f012b2e5c5eb61db9e237ecc5b8dbd378e
https://github.com/WebKit/WebKit/commit/d8def5f012b2e5c5eb61db9e237ecc5b8dbd378e
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/storage/filesystemaccess/resources/sync-access-handle-storage-limit.js
M LayoutTests/storage/filesystemaccess/sync-access-handle-storage-limit-worker-expected.txt
M LayoutTests/storage/filesystemaccess/sync-access-handle-storage-limit-worker.html
M Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.cpp
M Tools/WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl
M Tools/WebKitTestRunner/InjectedBundle/TestRunner.cpp
M Tools/WebKitTestRunner/InjectedBundle/TestRunner.h
M Tools/WebKitTestRunner/TestController.cpp
M Tools/WebKitTestRunner/TestController.h
M Tools/WebKitTestRunner/TestInvocation.cpp
M Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm
M Tools/WebKitTestRunner/cocoa/TestWebsiteDataStoreDelegate.h
M Tools/WebKitTestRunner/cocoa/TestWebsiteDataStoreDelegate.mm
Log Message:
-----------
Cherry-pick 459a045d57da. rdar://problem/104980443
Preallocate quota for FileSystemSyncAccessHandle
https://bugs.webkit.org/show_bug.cgi?id=251642
rdar://104980443
Reviewed by Youenn Fablet.
QuotaManager is in network process, and FileSystemSyncAcessHandle performs file operation in web process, so web process
needs to message network process when it needs to use more space. However, FileSystemSyncAccessHandle::write is sync and
supposed to be performant, which means we should unblock them if possible. This patch makes QuotaManager allocate more
capacity to FileSystemSyncAccessHandle than it requests, so that FileSystemSyncAccessHandle would not need to send a
message on each write).
The current allocation policy for requested capacity x is:
1. If x <= 1MB, new capacity is 1MB.
2. If 1MB < x < 256MB, new capacity is 2^(log2(x) + 1).
3. If x >= 256MB, new capacity is (x / 128MB + 1) * 128MB.
With this change, FileSystemSyncAcessHandle tests will start to fail if we disallow quota to increase (e.g. disallow it
to check if quota error can be thrown), because TestRunner sets origin quota to be 40KB by default, and each
FileSystemSyncAcessHandle requests at least 1MB. To fix this, this patch adds a new setQuota() function on TestRunner to
allow configuring quota for each test.
* LayoutTests/storage/filesystemaccess/resources/sync-access-handle-storage-limit.js:
* LayoutTests/storage/filesystemaccess/sync-access-handle-storage-limit-worker-expected.txt:
* LayoutTests/storage/filesystemaccess/sync-access-handle-storage-limit-worker.html:
* Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.cpp:
(WebKit::FileSystemStorageHandle::requestNewCapacityForSyncAccessHandle):
* Tools/WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
* Tools/WebKitTestRunner/InjectedBundle/TestRunner.cpp:
(WTR::TestRunner::setQuota):
* Tools/WebKitTestRunner/InjectedBundle/TestRunner.h:
* Tools/WebKitTestRunner/TestController.cpp:
(WTR::TestController::resetStateToConsistentValues):
(WTR::TestController::setQuota):
* Tools/WebKitTestRunner/TestController.h:
* Tools/WebKitTestRunner/TestInvocation.cpp:
(WTR::TestInvocation::didReceiveSynchronousMessageFromInjectedBundle):
* Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:
(WTR::TestController::cocoaResetStateToConsistentValues):
(WTR::TestController::setQuota):
* Tools/WebKitTestRunner/cocoa/TestWebsiteDataStoreDelegate.h:
* Tools/WebKitTestRunner/cocoa/TestWebsiteDataStoreDelegate.mm:
(-[TestWebsiteDataStoreDelegate init]):
(-[TestWebsiteDataStoreDelegate requestStorageSpace:frameOrigin:quota:currentSize:spaceRequired:decisionHandler:]):
(-[TestWebsiteDataStoreDelegate setQuota:]):
Canonical link: https://commits.webkit.org/259946@main
Canonical link: https://commits.webkit.org/259548.137@safari-7615-branch
Commit: 0d49704e79e408d1352292c1a0813e4c8db02d64
https://github.com/WebKit/WebKit/commit/0d49704e79e408d1352292c1a0813e4c8db02d64
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/Scripts/process-entitlements.sh
Log Message:
-----------
Cherry-pick faa11d115c78. rdar://problem/105100208
REGRESSION (Safari 16.1): mediaSession API not showing artwork: part 2
https://bugs.webkit.org/show_bug.cgi?id=251836
rdar://105100208
Reviewed by Youenn Fablet.
In https://bugs.webkit.org/show_bug.cgi?id=247043 an entitlements was added
in order to satisfy extra security requirements allowing to send compressed
images to MediaRemote.
Unfortunately, the entitlements was only added for macOS. We add it for iOS too.
* Source/WebKit/Scripts/process-entitlements.sh:
Canonical link: https://commits.webkit.org/259952@main
Canonical link: https://commits.webkit.org/259548.138@safari-7615-branch
Commit: 0417b7149c200d0ec3d1c913019cd1250e68f9ba
https://github.com/WebKit/WebKit/commit/0417b7149c200d0ec3d1c913019cd1250e68f9ba
Author: Antti Koivisto <antti at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/http/tests/css/link-with-non-matching-media-slow-load-expected.html
A LayoutTests/http/tests/css/link-with-non-matching-media-slow-load.html
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
Log Message:
-----------
Cherry-pick 9e31d4e46121. rdar://problem/102178226
<link> elements with media queries that do not affect the current page can be delayed
https://bugs.webkit.org/show_bug.cgi?id=39455
rdar://102178226
Reviewed by Alan Baradlay.
We correctly deprioritize stylesheets with non-matching media attribute and don't make them
rendering blocking. However they may still delay the visually non-empty milestone. This delay
only comes into play if there is not enough visual content to trigger the milestone otherwise.
This may end up delaying rendering until the non-matching stylesheets are fully loaded on simple
pages.
* LayoutTests/http/tests/css/link-with-non-matching-media-slow-load-expected.html: Added.
* LayoutTests/http/tests/css/link-with-non-matching-media-slow-load.html: Added.
* Source/WebCore/page/FrameView.cpp:
(WebCore::FrameView::checkAndDispatchDidReachVisuallyNonEmptyState):
Ignore "very low" priority resources when determining if everything important is loaded.
* Source/WebCore/testing/Internals.cpp:
(WebCore::Internals::isVisuallyNonEmpty const):
* Source/WebCore/testing/Internals.h:
* Source/WebCore/testing/Internals.idl:
Testing support.
Canonical link: https://commits.webkit.org/259963@main
Canonical link: https://commits.webkit.org/259548.139@safari-7615-branch
Commit: 1d40b038805bd2af4f89fd3794f511940502fff6
https://github.com/WebKit/WebKit/commit/1d40b038805bd2af4f89fd3794f511940502fff6
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/http/wpt/resource-timing/crossorigin-servertiming-expected.txt
A LayoutTests/http/wpt/resource-timing/crossorigin-servertiming.html
A LayoutTests/http/wpt/resource-timing/resources/server-timing.py
M Source/WebCore/loader/ResourceTiming.cpp
M Source/WebCore/loader/ResourceTiming.h
M Source/WebCore/loader/ResourceTimingInformation.cpp
Log Message:
-----------
Cherry-pick b67af69609f3. rdar://problem/104427347
Server-Timing data can be read cross-origin
https://bugs.webkit.org/show_bug.cgi?id=250837
rdar://problem/104427347
Reviewed by Alex Christensen.
For document (iframe, object, embed) loads, the origin of the load is the origin of the URL.
This is same origin by nature.
But the origin we will expose the timing info is the origin of the initiator.
Make sure to recompute the same origin request flag in that case.
* LayoutTests/http/wpt/resource-timing/crossorigin-servertiming-expected.txt: Added.
* LayoutTests/http/wpt/resource-timing/crossorigin-servertiming.html: Added.
* LayoutTests/http/wpt/resource-timing/server-timing.py: Added.
(main):
* Source/WebCore/loader/ResourceTiming.cpp:
(WebCore::ResourceTiming::updateExposure):
* Source/WebCore/loader/ResourceTiming.h:
* Source/WebCore/loader/ResourceTimingInformation.cpp:
(WebCore::ResourceTimingInformation::addResourceTiming):
Canonical link: https://commits.webkit.org/260006@main
Canonical link: https://commits.webkit.org/259548.140@safari-7615-branch
Commit: 962093e8357f1c483345fad2b99ae7376bda6f9c
https://github.com/WebKit/WebKit/commit/962093e8357f1c483345fad2b99ae7376bda6f9c
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/fast/block/height-percentage-descendants-with-absolute-pos-containingblock-expected.txt
M LayoutTests/fast/repaint/box-shadow-top-left-repaint-expected.txt
M LayoutTests/fast/repaint/focus-ring-repaint-expected.txt
M LayoutTests/fast/repaint/leftover-after-shrinking-content-expected.txt
M LayoutTests/fast/repaint/overlapping-lines-with-ink-overflow-expected.txt
M LayoutTests/fast/repaint/simple-line-layout-shrinking-content-expected.txt
A LayoutTests/fast/repaint/text-content-shrinks-repaint-expected.txt
A LayoutTests/fast/repaint/text-content-shrinks-repaint.html
M LayoutTests/fast/repaint/vertical-text-repaint-expected.txt
M LayoutTests/platform/ios-wk2/fast/block/height-percentage-descendants-with-absolute-pos-containingblock-expected.txt
M LayoutTests/platform/mac-wk1/fast/repaint/leftover-after-shrinking-content-expected.txt
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Cherry-pick f5f87a80a556. rdar://problem/104966985
REGRESSION (258819 at main): Wolfram Alpha dropdown box has repaint artifacts
https://bugs.webkit.org/show_bug.cgi?id=251816
<rdar://104966985>
Reviewed by Antti Koivisto.
Due to eager display content invalidation, repaints issued after calling RenderBlockFlow::invalidateLineLayoutPath produce empty rects.
Normally this invalidation call is followed by a layout which will eventually issue another repaint. This second repaint, with no partial layout support in IFC (and most content are now covered by IFC)
we will most likely be a full, though redundant repaint.
(note that this newly introduced repaint may be overly inflated when tall container has constantly changing short inline content)
* LayoutTests/fast/repaint/text-content-shrinks-repaint-expected.txt: Added.
* LayoutTests/fast/repaint/text-content-shrinks-repaint.html: Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::invalidateLineLayoutPath):
Canonical link: https://commits.webkit.org/260008@main
Canonical link: https://commits.webkit.org/259548.141@safari-7615-branch
Commit: 9c1db48a6f8fddee51a170b80b8fecc1ad98de13
https://github.com/WebKit/WebKit/commit/9c1db48a6f8fddee51a170b80b8fecc1ad98de13
Author: Commit Queue <commit-queue at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
R LayoutTests/fast/css/lang-matching-document-invalidation-expected.txt
R LayoutTests/fast/css/lang-matching-document-invalidation.html
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Element.h
M Source/WebCore/dom/ElementData.cpp
M Source/WebCore/dom/ElementData.h
M Source/WebCore/dom/EventTarget.h
Log Message:
-----------
Cherry-pick 5b3f738b710a. rdar://problem/105177446
Unreviewed, reverting r259931 at main.
https://bugs.webkit.org/show_bug.cgi?id=251932
Caused tests to assert in language attribute handling code
Reverted changeset:
"Avoid storing effective language on ElementRareData when it matches the effective document element language"
https://bugs.webkit.org/show_bug.cgi?id=251657
https://commits.webkit.org/259931@main
Canonical link: https://commits.webkit.org/260019@main
Canonical link: https://commits.webkit.org/259548.142@safari-7615-branch
Commit: 4d8071645a67f94a4ff2c6f3050f6fbfed5c3b96
https://github.com/WebKit/WebKit/commit/4d8071645a67f94a4ff2c6f3050f6fbfed5c3b96
Author: Antti Koivisto <antti at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/style/StyleScopeRuleSets.cpp
Log Message:
-----------
Cherry-pick 381f8ae629b0. rdar://problem/105011534
Style::RuleFeatureSet wastes vector capacity
https://bugs.webkit.org/show_bug.cgi?id=251701
rdar://105011534
Reviewed by Simon Fraser.
* Source/WebCore/style/StyleScopeRuleSets.cpp:
(WebCore::Style::ensureInvalidationRuleSets):
Shrink-to-fit the RuleSets (which also handles the RuleFeatureSets).
Canonical link: https://commits.webkit.org/260021@main
Canonical link: https://commits.webkit.org/259548.143@safari-7615-branch
Commit: 0a81af59b25b8d60873ff2d5cdb79ecfc33ebd9f
https://github.com/WebKit/WebKit/commit/0a81af59b25b8d60873ff2d5cdb79ecfc33ebd9f
Author: Tim Nguyen <ntim at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/fullscreen/fullscreen-iframe-navigation-expected.html
A LayoutTests/fullscreen/fullscreen-iframe-navigation.html
A LayoutTests/fullscreen/resources/fullscreen-iframe-navigation-target.html
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/dom/FullscreenManager.cpp
M Source/WebCore/dom/FullscreenManager.h
Log Message:
-----------
Cherry-pick 9215d7d582cb. rdar://problem/104393093
Navigation within iframe doesn't exit fullscreen for parent iframe element
https://bugs.webkit.org/show_bug.cgi?id=251896
rdar://104393093
Reviewed by Chris Dumez.
This was because the exiting document was already detached from the Frame object, causing it to fail to find the top document.
To fix this, we store the top document when initializing FullscreenManager.
* LayoutTests/fullscreen/fullscreen-iframe-navigation-expected.html: Added.
* LayoutTests/fullscreen/fullscreen-iframe-navigation.html: Added.
* LayoutTests/fullscreen/resources/fullscreen-iframe-navigation-target.html: Added.
* LayoutTests/platform/mac-wk1/TestExpectations:
* Source/WebCore/dom/FullscreenManager.cpp:
(WebCore::FullscreenManager::cancelFullscreen):
(WebCore::documentsToUnfullscreen):
(WebCore::FullscreenManager::exitFullscreen):
(WebCore::FullscreenManager::finishExitFullscreen):
(WebCore::FullscreenManager::didExitFullscreen):
* Source/WebCore/dom/FullscreenManager.h:
Canonical link: https://commits.webkit.org/260024@main
Canonical link: https://commits.webkit.org/259548.144@safari-7615-branch
Commit: db195a0fa3f7504f46bc0cfd296c2e6a100f977d
https://github.com/WebKit/WebKit/commit/db195a0fa3f7504f46bc0cfd296c2e6a100f977d
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/accumulation-per-property-002-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/addition-per-property-002-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/interpolation-per-property-002-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/property-list.js
M LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/property-types.js
M LayoutTests/platform/mac-wk1/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/accumulation-per-property-002-expected.txt
M LayoutTests/platform/mac-wk1/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/addition-per-property-002-expected.txt
M LayoutTests/platform/mac-wk1/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/interpolation-per-property-002-expected.txt
M Source/WebCore/animation/CSSPropertyAnimation.cpp
Log Message:
-----------
Cherry-pick 221eb1d58b67. rdar://problem/104346766
[web-animations] line-height should not transition from default value to a number
https://bugs.webkit.org/show_bug.cgi?id=251911
rdar://104346766
Reviewed by Antti Koivisto.
By default, properties represented by a Length in RenderStyle use discrete interpolation when
their LengthType differs. In the case of line-height, BuilderConverter::convertLineHeight() yields:
- LengthType::Percent for the "normal" CSS value (with -100 as the float value),
- LengthType::Percent for <number> CSS values,
- LengthType::Fixed for <length-percentage> values.
This means that animating between "normal" and <number> would use an interpolation because we would
see two LengthType::Percent values.
To deal with this, we now have a dedicated animation wrapper for "line-height" which detects "normal"
values and returns false if either the from or to value can be mapped back to "normal".
* LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/accumulation-per-property-002-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/addition-per-property-002-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/interpolation-per-property-002-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/property-list.js:
* LayoutTests/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/property-types.js:
(const.discreteType.testInterpolation):
(const.discreteType.testAdditionOrAccumulation):
* LayoutTests/platform/mac-wk1/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/accumulation-per-property-002-expected.txt:
* LayoutTests/platform/mac-wk1/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/addition-per-property-002-expected.txt:
* LayoutTests/platform/mac-wk1/imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/interpolation-per-property-002-expected.txt:
* Source/WebCore/animation/CSSPropertyAnimation.cpp:
(WebCore::CSSPropertyAnimationWrapperMap::CSSPropertyAnimationWrapperMap):
Canonical link: https://commits.webkit.org/260028@main
Canonical link: https://commits.webkit.org/259548.145@safari-7615-branch
Commit: 79797a9fbf8d2fa7347003818bd0c6e35694da63
https://github.com/WebKit/WebKit/commit/79797a9fbf8d2fa7347003818bd0c6e35694da63
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A JSTests/stress/string-to-well-formed-number.js
M Source/JavaScriptCore/runtime/StringPrototype.cpp
Log Message:
-----------
Cherry-pick aa30fafbe181. rdar://problem/105104668
[JSC] String#toWellFormed should return stringified value
https://bugs.webkit.org/show_bug.cgi?id=251757
rdar://problem/105104668
Reviewed by Justin Michaud and Mark Lam.
We should return stringified value instead of original thisValue for the fast path.
* JSTests/stress/string-to-well-formed-number.js: Added.
(shouldBe):
* Source/JavaScriptCore/runtime/StringPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
Canonical link: https://commits.webkit.org/260043@main
Canonical link: https://commits.webkit.org/259548.146@safari-7615-branch
Commit: 9ff606033b841541f8c22d8f12fb7b34b53d2a01
https://github.com/WebKit/WebKit/commit/9ff606033b841541f8c22d8f12fb7b34b53d2a01
Author: Cameron McCormack <heycam at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
A LayoutTests/fast/css/lang-matching-document-invalidation-expected.txt
A LayoutTests/fast/css/lang-matching-document-invalidation.html
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Element.h
M Source/WebCore/dom/ElementData.cpp
M Source/WebCore/dom/ElementData.h
M Source/WebCore/dom/EventTarget.h
Log Message:
-----------
Cherry-pick f31c6cd34376. rdar://problem/104987630
Avoid storing effective language on ElementRareData when it matches the effective document element language
https://bugs.webkit.org/show_bug.cgi?id=251657
<rdar://problem/104987630>
Reviewed by Ryosuke Niwa.
When an element's lang attribute is set, we set the effective language on
the ElementRareData of all elements in the subtree. We have an existing
optimization that avoids this if we're setting it on the document
element. There are some pages, like Wikipedia, that set an explicit
lang on some other element in the body of the page, but which matches
the document element's lang.
We can avoid the memory overhead of allocating ElementRareData to store
the effective language in this case by using a flag on the element. On
large Wikipedia pages this can save several MB.
If the document element language changes later, we must update the
effective lang state on subtrees that are using this flag. A WeakHashSet
is added to Document to track elements that have an explicit lang
attribute that matches the effective document element language.
Three flags on EventTarget are introduced:
- HasLangAttr and HasXMLLangAttr: records that the element has the
corresponding lang attribute. This allows us to avoid searching
for an attribute when updating the effective lang state.
- EffectiveLangKnownToMatchDocument: records that the element has an
effective lang that matches the effective document element language,
whether it's due to an explicit lang attribute or inherited from an
ancestor. This flag is used in place of
ElementRareData::m_effectiveLang.
The EffectiveLangKnownToMatchDocument flag is used in place of the "null
effective language means we've inherited the effective document
language" state so that disconnected subtrees can also make use of this
optimization. Otherwise, for a case like this:
let e = document.createElement("div");
e.lang = "en"; // matching document
e.append(document.createElement("div"));
the child element would not know whether to return nullptr or "en" from
Element::effectiveLang() without looking up the tree to see if there is
an ancestor with a langauge attribute.
The EffectiveLangKnownToMatchDocument flag is not
EffectiveLangMatchesDocument, since we don't set it if the document
element language changes and an existing element starts matching it.
Rather than track all elements with lang attributes to handle such
cases, we leave the effective lang stored on the ElementRareData.
* LayoutTests/fast/css/lang-matching-document-invalidation-expected.txt: Added.
* LayoutTests/fast/css/lang-matching-document-invalidation.html: Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setDocumentElementLanguage):
(WebCore::Document::addElementWithLangAttrMatchingDocument):
(WebCore::Document::removeElementWithLangAttrMatchingDocument):
* Source/WebCore/dom/Document.h:
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::~Element):
(WebCore::Element::attributeChanged):
(WebCore::Element::setEffectiveLangInSubtree):
(WebCore::Element::didMoveToNewDocument):
(WebCore::Element::setEffectiveLangFromParent):
(WebCore::Element::setEffectiveLang):
(WebCore::Element::insertedIntoAncestor):
(WebCore::Element::hasEffectiveLangState const):
(WebCore::Element::removedFromAncestor):
(WebCore::Element::effectiveLang const):
(WebCore::Element::langFromAttribute const):
(WebCore::Element::langAttrMatchesDocument const):
(WebCore::Element::setLangAttrMatchesDocument):
(WebCore::Element::effectiveLangMatchesDocument const):
(WebCore::Element::setEffectiveLangMatchesDocument):
* Source/WebCore/dom/Element.h:
* Source/WebCore/dom/EventTarget.h:
Canonical link: https://commits.webkit.org/260047@main
Canonical link: https://commits.webkit.org/259548.147@safari-7615-branch
Commit: 9049b2cd9e89d5e78499c943cd1892524c89ac7f
https://github.com/WebKit/WebKit/commit/9049b2cd9e89d5e78499c943cd1892524c89ac7f
Author: Timothy Hatcher <timothy at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm
Log Message:
-----------
Cherry-pick 1adec3c9e021. rdar://problem/105181176
REGRESSION (259976 at main): [iOS / macOS] TestWebKitAPI.URLSchemeHandler.DisableCORS is consistently failing
https://webkit.org/b/251935
rdar://105181176
Reviewed by Sihui Liu.
Remove the dynamic version of _corsDisablingPatterns on WKWebView, since it was was never adopted in Safari
and is not working correctly since SecurityPolicy never removes UserContentURLPatterns from the allowlist.
We are tracking updating this mechanism for extensions in rdar://102912898.
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _corsDisablingPatterns]): Deleted.
(-[WKWebView _setCORSDisablingPatterns:]): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm:
Remove test for setting _corsDisablingPatterns on WKWebView.
Canonical link: https://commits.webkit.org/260048@main
Canonical link: https://commits.webkit.org/259548.148@safari-7615-branch
Commit: fab603242a7d5e7eb11756fb22b802a22a593198
https://github.com/WebKit/WebKit/commit/fab603242a7d5e7eb11756fb22b802a22a593198
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/web-animations/interfaces/Animatable/animate-no-browsing-context-expected.txt
M Source/WebCore/animation/AnimationEffect.h
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/animation/WebAnimation.cpp
Log Message:
-----------
Cherry-pick 87f47a6461e3. rdar://problem/41000163
[web-animations] web-animations/interfaces/Animatable/animate-no-browsing-context.html is a unique failure
https://bugs.webkit.org/show_bug.cgi?id=186494
rdar://problem/41000163
Reviewed by Dean Jackson.
The Web Animations spec defines several factors for an animation to be considered "ready" [0], one being
that the "user agent has completed any setup required to begin the playback of the animation's associated
effect including rendering the first frame of any keyframe effect".
While it does not specifically calls out the lack of a browsing context for the associated effect's target's
document, there certainly won't be any frames rendered in that specific case. So we do not run pending tasks,
the condition for the "ready" promise to resolve, if the associated effect is associated with a document
lacking a browsing context.
I filed a spec issue [1] to clarify this in the spec, but I believe the spirit of the spec already goes in
the direction of this test.
[0] https://drafts.csswg.org/web-animations-1/#ready
[1] https://github.com/w3c/csswg-drafts/issues/8439
* LayoutTests/imported/w3c/web-platform-tests/web-animations/interfaces/Animatable/animate-no-browsing-context-expected.txt:
* Source/WebCore/animation/AnimationEffect.h:
(WebCore::AnimationEffect::preventsAnimationReadiness const):
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::preventsAnimationReadiness const):
* Source/WebCore/animation/KeyframeEffect.h:
* Source/WebCore/animation/WebAnimation.cpp:
(WebCore::WebAnimation::tick):
Canonical link: https://commits.webkit.org/260101@main
Canonical link: https://commits.webkit.org/259548.149@safari-7615-branch
Commit: c18f572b7fdd6c98f11e74733a0d6e7cf2921d8d
https://github.com/WebKit/WebKit/commit/c18f572b7fdd6c98f11e74733a0d6e7cf2921d8d
Author: David Kilzer <ddkilzer at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M Source/WebCore/platform/graphics/DecomposedGlyphs.h
M Source/WebCore/platform/graphics/ImageSource.cpp
M Source/WebCore/platform/graphics/ImageSource.h
M Source/WebCore/platform/graphics/NativeImage.h
M Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.h
M Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm
M Source/WebCore/platform/network/cocoa/RangeResponseGenerator.h
M Source/WebCore/platform/network/cocoa/RangeResponseGenerator.mm
M Source/WebCore/storage/StorageQuotaManager.h
M Source/WebKit/WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp
M Source/WebKit/WebProcess/GPU/graphics/RemoteResourceCacheProxy.h
Log Message:
-----------
Cherry-pick 8f33f11f2a7f. rdar://problem/104436726
Use WTF::ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr<> more in WebCore
https://bugs.webkit.org/show_bug.cgi?id=250929
<rdar://problem/104436726>
Reviewed by Chris Dumez.
Classes that inherit from both WTF::ThreadSafeRefCounted<> and
WTF::CanMakeWeakPtr<> should use
WTF::ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr<> instead.
Most of the changes below are:
- to replace WeakPtr<> with ThreadSafeWeakPtr<> in instance
variables and data structures,
- to change raw pointers returned from WeakPtr<>.get() to
RefPtr<> types, and
- to use a local RefPtr<> to an object instead of checking the
pointer value in the ThreadSafeWeakPtr<> object directly.
Since a lock is taken each time the value stored in the
ThreadSafeWeakPtr<> is returned, there is an effort to minimize
the number of times that happens within a given method by
creating a local RefPtr<> variable on the stack.
* Source/WebCore/platform/graphics/DecomposedGlyphs.h:
* Source/WebCore/platform/graphics/ImageSource.cpp:
(WebCore::ImageSource::ensureDecoderAvailable):
* Source/WebCore/platform/graphics/ImageSource.h:
* Source/WebCore/platform/graphics/NativeImage.h:
* Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.h:
* Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm:
(-[WebAVPlayerViewControllerDelegate fullscreenInterface]):
(-[WebAVPlayerViewControllerDelegate setFullscreenInterface:]):
(-[WebAVPlayerViewControllerDelegate playerViewControllerWillStartPictureInPicture:]):
(-[WebAVPlayerViewControllerDelegate playerViewControllerDidStartPictureInPicture:]):
(-[WebAVPlayerViewControllerDelegate playerViewController:failedToStartPictureInPictureWithError:]):
(-[WebAVPlayerViewControllerDelegate playerViewControllerWillStopPictureInPicture:]):
(-[WebAVPlayerViewControllerDelegate playerViewControllerDidStopPictureInPicture:]):
(-[WebAVPlayerViewControllerDelegate playerViewController:shouldExitFullScreenWithReason:]):
(-[WebAVPlayerViewControllerDelegate playerViewController:restoreUserInterfaceForPictureInPictureStopWithCompletionHandler:]):
(-[WebAVPlayerViewControllerDelegate pictureInPictureControllerWillStartPictureInPicture:]):
(-[WebAVPlayerViewControllerDelegate pictureInPictureControllerDidStartPictureInPicture:]):
(-[WebAVPlayerViewControllerDelegate pictureInPictureController:failedToStartPictureInPictureWithError:]):
(-[WebAVPlayerViewControllerDelegate pictureInPictureControllerWillStopPictureInPicture:]):
(-[WebAVPlayerViewControllerDelegate pictureInPictureControllerDidStopPictureInPicture:]):
(-[WebAVPlayerViewControllerDelegate pictureInPictureController:restoreUserInterfaceForPictureInPictureStopWithCompletionHandler:]):
(-[WebAVPlayerViewController initWithFullscreenInterface:]):
(-[WebAVPlayerViewController enterFullScreenAnimated:completionHandler:]):
- On watchOS, if _fullscreenInterface is nullptr, attempt to
call completionHandler if set. Previously this would crash.
(-[WebAVPlayerViewController MY_NO_RETURN]):
* Source/WebCore/platform/network/cocoa/RangeResponseGenerator.h:
* Source/WebCore/platform/network/cocoa/RangeResponseGenerator.mm:
(WebCore::RangeResponseGenerator::giveResponseToTaskIfBytesInRangeReceived):
* Source/WebCore/storage/StorageQuotaManager.h:
* Source/WebKit/WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp:
(WebKit::RemoteResourceCacheProxy::clearNativeImageMap):
(WebKit::RemoteResourceCacheProxy::clearDecomposedGlyphsMap):
* Source/WebKit/WebProcess/GPU/graphics/RemoteResourceCacheProxy.h:
Canonical link: https://commits.webkit.org/260107@main
Canonical link: https://commits.webkit.org/259548.150@safari-7615-branch
Commit: 53a37723620d9f391085a2c657f55a052e72d8ec
https://github.com/WebKit/WebKit/commit/53a37723620d9f391085a2c657f55a052e72d8ec
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-02-10 (Fri, 10 Feb 2023)
Changed paths:
M LayoutTests/TestExpectations
M Source/JavaScriptCore/runtime/OptionsList.h
Log Message:
-----------
Cherry-pick 5eb788706c89. rdar://problem/104964116
[JSC] Disable import-assertion since TC39 decides bringing it back to stage-2
https://bugs.webkit.org/show_bug.cgi?id=251600
rdar://104964116
Reviewed by Michael Saboff.
We found that the current syntax & semantics do not work with CSS / JSON module integration in HTML side,
and it requires drastic changes in import-assertion in both syntax and semantics levels, which means that
the current proposal becomes obsolete / not-shippable state. TC39 discussed about this and decided to
bring import-assertion down to stage-2 from stage-3 to announce that this is not shippable state right now.
This patch disables import-assertion by flipping a runtime flag.
* Source/JavaScriptCore/runtime/OptionsList.h:
Canonical link: https://commits.webkit.org/259795@main
Canonical link: https://commits.webkit.org/259548.151@safari-7615-branch
Commit: 3188daa6f9d083aa88760c7e721bba654f898593
https://github.com/WebKit/WebKit/commit/3188daa6f9d083aa88760c7e721bba654f898593
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2023-02-11 (Sat, 11 Feb 2023)
Changed paths:
A LayoutTests/fast/frames/nested-iframes-expected.html
A LayoutTests/fast/frames/nested-iframes.html
A LayoutTests/fast/frames/resources/nesting0.html
A LayoutTests/fast/frames/resources/nesting1.html
A LayoutTests/fast/frames/resources/nesting2.html
R LayoutTests/http/tests/security/embedded-self-reference-after-url-modified-expected.txt
R LayoutTests/http/tests/security/embedded-self-reference-after-url-modified.html
M Source/WebCore/html/HTMLFrameOwnerElement.cpp
Log Message:
-----------
REGRESSION(252432.937 at safari-7614-branch) Some nested iframes aren't getting rendered
https://bugs.webkit.org/show_bug.cgi?id=252087
rdar://104961943
Reviewed by Alan Baradlay.
This is a revert of 252432.937 at safari-7614-branch.
* LayoutTests/http/tests/security/embedded-self-reference-after-url-modified-expected.txt: Removed.
* LayoutTests/http/tests/security/embedded-self-reference-after-url-modified.html: Removed.
* Source/WebCore/html/HTMLFrameOwnerElement.cpp:
(WebCore::HTMLFrameOwnerElement::isProhibitedSelfReference const):
Canonical link: https://commits.webkit.org/259548.152@safari-7615-branch
Commit: c49d1e6e50a48dde8a1af3e527f406a7869f9714
https://github.com/WebKit/WebKit/commit/c49d1e6e50a48dde8a1af3e527f406a7869f9714
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-02-13 (Mon, 13 Feb 2023)
Changed paths:
A LayoutTests/fast/css/style-update-timer-crash-expected.txt
A LayoutTests/fast/css/style-update-timer-crash.html
M Source/WebCore/style/StyleScope.cpp
Log Message:
-----------
Hold reference to shadowRoot and document when timer is triggered
https://bugs.webkit.org/show_bug.cgi?id=252091
rdar://105115603
Reviewed by Ryosuke Niwa.
This change fixes the issue where a Style::Scope can get deallocated
when the timer is fired, leading to a use-after-free. The fix holds onto
the shadowRoot and document in question, both of which own the
Style::Scope object.
* LayoutTests/fast/css/style-update-timer-crash-expected.txt: Added.
* LayoutTests/fast/css/style-update-timer-crash.html: Added.
* Source/WebCore/style/StyleScope.cpp:
(WebCore::Style::Scope::pendingUpdateTimerFired):
Canonical link: https://commits.webkit.org/259548.153@safari-7615-branch
Commit: 7628b9317aff3f3f4754628154e17de7ea424a56
https://github.com/WebKit/WebKit/commit/7628b9317aff3f3f4754628154e17de7ea424a56
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-02-13 (Mon, 13 Feb 2023)
Changed paths:
M LayoutTests/platform/ios/fast/css/text-overflow-input-expected.txt
M LayoutTests/platform/ios/fast/forms/input-text-scroll-left-on-blur-expected.txt
M LayoutTests/platform/mac/fast/css/text-overflow-input-expected.txt
M LayoutTests/platform/mac/fast/forms/input-text-scroll-left-on-blur-expected.txt
M LayoutTests/platform/mac/fast/forms/search-rtl-expected.txt
M Source/WebCore/layout/formattingContexts/inline/InlineRect.h
M Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp
M Source/WebCore/layout/integration/inline/LayoutIntegrationInlineContentBuilder.cpp
Log Message:
-----------
Cherry-pick 1e816c148346. rdar://problem/104927367
[IFC] InlineDisplayLineBuilder::collectEnclosingLineGeometry should include root inline box in scrollable overflow
https://bugs.webkit.org/show_bug.cgi?id=251414
Reviewed by Antti Koivisto.
Display::Line should include all scrollable overflow that we can compute excluding the "padding end" hack in LegacyLineLayout::addOverflowFromInlineChildren.
* Source/WebCore/layout/integration/inline/LayoutIntegrationInlineContentBuilder.cpp:
(WebCore::LayoutIntegration::lineOverflowLogicalWidth): LegacyLineLayout::addOverflowFromInlineChildren ignores RTL content, so should IFC.
(WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLines const):
Canonical link: https://commits.webkit.org/259708@main
Canonical link: https://commits.webkit.org/259456.246@safari-7615-branch
Commit: fdef8c9b7af70b19c847b134aa19fbe8df65a78d
https://github.com/WebKit/WebKit/commit/fdef8c9b7af70b19c847b134aa19fbe8df65a78d
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-02-13 (Mon, 13 Feb 2023)
Changed paths:
A LayoutTests/fast/inline/scrollable-overflow-pre-wrap-hanging-whitespace-expected.html
A LayoutTests/fast/inline/scrollable-overflow-pre-wrap-hanging-whitespace.html
M Source/WebCore/layout/formattingContexts/inline/InlineLineBoxBuilder.cpp
M Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp
M Source/WebCore/layout/integration/inline/LayoutIntegrationInlineContentBuilder.cpp
Log Message:
-----------
Cherry-pick f500d3412d93. rdar://problem/104781435
Incorrect text caret placement when RTL text starts with whitespace
https://bugs.webkit.org/show_bug.cgi?id=251313
<rdar://problem/104781435>
Reviewed by Antti Koivisto.
See the comment in LineBoxBuilder::build.
* LayoutTests/fast/inline/scrollable-overflow-pre-wrap-hanging-whitespace-expected.html: Added.
* LayoutTests/fast/inline/scrollable-overflow-pre-wrap-hanging-whitespace.html: Added.
* Source/WebCore/layout/formattingContexts/inline/InlineLineBoxBuilder.cpp:
(WebCore::Layout::LineBoxBuilder::build):
Canonical link: https://commits.webkit.org/259868@main
Canonical link: https://commits.webkit.org/259456.247@safari-7615-branch
Commit: bde4f7b90117fffbfdda5150fd2d529455be693d
https://github.com/WebKit/WebKit/commit/bde4f7b90117fffbfdda5150fd2d529455be693d
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-13 (Mon, 13 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/style/CustomPropertyRegistry.cpp
M Source/WebCore/style/CustomPropertyRegistry.h
Log Message:
-----------
Cherry-pick 70fad0325901. rdar://problem/104947453
[web-animations] keyframes should be recomputed if a custom property registration changes
https://bugs.webkit.org/show_bug.cgi?id=251509
Reviewed by Antti Koivisto.
If the registration of a custom property is changed, we must recompute keyframes of any effects
with keyframes targeting that custom property. To that end, we add a new method on KeyframeEffect
that the CustomPropertyRegistry can call into to notify the change of a custom property's
registration.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt:
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::customPropertyRegistrationDidChange):
* Source/WebCore/animation/KeyframeEffect.h:
* Source/WebCore/style/CustomPropertyRegistry.cpp:
(WebCore::Style::CustomPropertyRegistry::registerFromAPI):
(WebCore::Style::CustomPropertyRegistry::registerFromStylesheet):
(WebCore::Style::CustomPropertyRegistry::notifyAnimationsOfCustomPropertyRegistration):
* Source/WebCore/style/CustomPropertyRegistry.h:
Canonical link: https://commits.webkit.org/259737@main
Canonical link: https://commits.webkit.org/259456.248@safari-7615-branch
Commit: 4b621e3e1109f68249aa6ec7bfdcb14719e937c0
https://github.com/WebKit/WebKit/commit/4b621e3e1109f68249aa6ec7bfdcb14719e937c0
Author: Russell Epstein <repstein at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance.html
M Source/WebCore/style/StyleBuilderCustom.h
Log Message:
-----------
Revert "Cherry-pick 06e3540a49d. rdar://problem/104998661"
This reverts commit a4202f6cb63a6b4675a7ae6d54aba422c33625a5.
Canonical link: https://commits.webkit.org/259548.158@safari-7615-branch
Commit: ceb664523cb16e9e6e163aea17144058e1e406be
https://github.com/WebKit/WebKit/commit/ceb664523cb16e9e6e163aea17144058e1e406be
Author: Antti Koivisto <antti at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/typedom-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/cssom/cssstyledeclaration-registered-custom-properties-expected.txt
M Source/WebCore/animation/CSSPropertyAnimation.cpp
M Source/WebCore/css/CSSVariableReferenceValue.cpp
M Source/WebCore/css/ComputedStyleExtractor.cpp
M Source/WebCore/css/typedom/ComputedStylePropertyMapReadOnly.cpp
M Source/WebCore/rendering/style/RenderStyle.cpp
M Source/WebCore/rendering/style/RenderStyle.h
M Source/WebCore/rendering/style/StyleCustomPropertyData.h
M Source/WebCore/style/CustomPropertyRegistry.cpp
M Source/WebCore/style/CustomPropertyRegistry.h
M Source/WebCore/style/StyleBuilderCustom.h
M Source/WebCore/style/StyleResolver.cpp
M Source/WebCore/style/StyleTreeResolver.cpp
Log Message:
-----------
Cherry-pick ffe6d89e6fa5. rdar://problem/104953759
[@property] Set registered initial values to RenderStyle
https://bugs.webkit.org/show_bug.cgi?id=251575
rdar://104953759
Reviewed by Antoine Quint.
Remove the need to provide the registry to RenderStyle::customPropertyValue().
This is done by maintaining a prototype style in CustomPropertyRegistry that is cloned
to make the initial styles in the style resolver.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/at-property-animation-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/typedom-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/cssom/cssstyledeclaration-registered-custom-properties-expected.txt:
This also fixes some bugs.
* Source/WebCore/animation/CSSPropertyAnimation.cpp:
(WebCore::blendCustomProperty):
(WebCore::CSSPropertyAnimation::propertyRequiresBlendingForAccumulativeIteration):
(WebCore::CSSPropertyAnimation::propertiesEqual):
(WebCore::CSSPropertyAnimation::canPropertyBeInterpolated):
* Source/WebCore/css/CSSVariableReferenceValue.cpp:
(WebCore::CSSVariableReferenceValue::resolveVariableReference const):
* Source/WebCore/css/ComputedStyleExtractor.cpp:
(WebCore::ComputedStyleExtractor::customPropertyValue):
* Source/WebCore/css/typedom/ComputedStylePropertyMapReadOnly.cpp:
(WebCore::ComputedStylePropertyMapReadOnly::entries const):
* Source/WebCore/rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::createPtrWithRegisteredInitialValues):
(WebCore::RenderStyle::inheritIgnoringCustomPropertiesFrom):
(WebCore::changedCustomPaintWatchedProperty):
(WebCore::RenderStyle::deduplicateCustomProperties):
Also dedupe non-inherited properties.
(WebCore::RenderStyle::setCustomPropertyValue):
Make this a single function.
(WebCore::RenderStyle::customPropertyValue const):
(WebCore::RenderStyle::deduplicateInheritedCustomProperties): Deleted.
(WebCore::RenderStyle::setInheritedCustomPropertyValue): Deleted.
(WebCore::RenderStyle::setNonInheritedCustomPropertyValue): Deleted.
(WebCore::RenderStyle::customPropertyValueWithoutResolvingInitial const): Deleted.
* Source/WebCore/rendering/style/RenderStyle.h:
* Source/WebCore/rendering/style/StyleCustomPropertyData.h:
(WebCore::StyleCustomPropertyData::setCustomPropertyValue):
* Source/WebCore/style/CustomPropertyRegistry.cpp:
(WebCore::Style::CustomPropertyRegistry::CustomPropertyRegistry):
(WebCore::Style::CustomPropertyRegistry::registerFromAPI):
(WebCore::Style::CustomPropertyRegistry::registerFromStylesheet):
(WebCore::Style::CustomPropertyRegistry::clearRegisteredFromStylesheets):
(WebCore::Style::CustomPropertyRegistry::initialValuePrototypeStyle const):
Maintain the initial value prototype style.
(WebCore::Style::CustomPropertyRegistry::invalidate):
* Source/WebCore/style/CustomPropertyRegistry.h:
* Source/WebCore/style/StyleBuilderCustom.h:
(WebCore::Style::BuilderCustom::applyInitialCustomProperty):
(WebCore::Style::BuilderCustom::applyInheritCustomProperty):
(WebCore::Style::BuilderCustom::applyValueCustomProperty):
* Source/WebCore/style/StyleResolver.cpp:
(WebCore::Style::Resolver::styleForElement):
Clone the initial style from the prototype.
(WebCore::Style::Resolver::styleForPseudoElement):
(WebCore::Style::Resolver::defaultStyleForElement):
* Source/WebCore/style/StyleTreeResolver.cpp:
(WebCore::Style::TreeResolver::createAnimatedElementUpdate):
Canonical link: https://commits.webkit.org/259807@main
Canonical link: https://commits.webkit.org/259548.159@safari-7615-branch
Commit: b9c4842ff24e6f522bbdae1d61f52d5a253c3189
https://github.com/WebKit/WebKit/commit/b9c4842ff24e6f522bbdae1d61f52d5a253c3189
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance.html
M Source/WebCore/style/StyleBuilderCustom.h
Log Message:
-----------
Cherry-pick 06e3540a49d0. rdar://problem/104998661
[css-properties-values-api] non-inherited custom property fails to inherit from parent when "inherit" is set
https://bugs.webkit.org/show_bug.cgi?id=251590
Reviewed by Antti Koivisto.
We would only look at the map of inherited custom properties when applying the "inherit" value
for a custom property. However, a non-inherited value should also use its parent's value in that
case.
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-properties-values-api/registered-properties-inheritance.html:
* Source/WebCore/style/StyleBuilderCustom.h:
(WebCore::Style::BuilderCustom::applyInheritCustomProperty):
Canonical link: https://commits.webkit.org/259809@main
Canonical link: https://commits.webkit.org/259548.160@safari-7615-branch
Commit: 0e6d03d7a3eb7f07f392ab3cb3c018dc7b3614ed
https://github.com/WebKit/WebKit/commit/0e6d03d7a3eb7f07f392ab3cb3c018dc7b3614ed
Author: Antti Koivisto <antti at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WebCore/animation/CSSPropertyAnimation.cpp
M Source/WebCore/css/CSSCustomPropertyValue.cpp
M Source/WebCore/css/CSSCustomPropertyValue.h
Log Message:
-----------
Cherry-pick b63783f81878. rdar://problem/104997649
[@property] Cache tokens in CSSCustomPropertyValue
https://bugs.webkit.org/show_bug.cgi?id=251672
rdar://104997649
Reviewed by Antoine Quint.
We currently generate tokens on every access by tokenizing a (cached) string.
* Source/WebCore/animation/CSSPropertyAnimation.cpp:
(WebCore::blendedCSSCustomPropertyValue):
* Source/WebCore/css/CSSCustomPropertyValue.cpp:
(WebCore::CSSCustomPropertyValue::customCSSText const):
(WebCore::CSSCustomPropertyValue::tokens const):
Add a token cache for registered custom properties.
Also avoid copying by returning a reference.
* Source/WebCore/css/CSSCustomPropertyValue.h:
Also remove an unneeded copy constructor.
Canonical link: https://commits.webkit.org/259813@main
Canonical link: https://commits.webkit.org/259548.161@safari-7615-branch
Commit: 31be8653cfd15372a0e5acdd7d137f067ec74a08
https://github.com/WebKit/WebKit/commit/31be8653cfd15372a0e5acdd7d137f067ec74a08
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WebCore/platform/cocoa/ParentalControlsContentFilter.mm
Log Message:
-----------
Cherry-pick b5a5e0bd3bb7. rdar://problem/105184733
Optionally soft-link WebContentAnalysis.framework and WebFilterEvaluator
https://bugs.webkit.org/show_bug.cgi?id=251947
Reviewed by Aditya Keerthi.
Don't `RELEASE_ASSERT` in the case where `WebContentAnalysis.framework` is missing.
* Source/WebCore/platform/cocoa/ParentalControlsContentFilter.mm:
Canonical link: https://commits.webkit.org/260045@main
Canonical link: https://commits.webkit.org/259548.162@safari-7615-branch
Commit: 884ef80e537ae34d200e5188080ae61a61847805
https://github.com/WebKit/WebKit/commit/884ef80e537ae34d200e5188080ae61a61847805
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
A JSTests/wasm/stress/js-to-wasm-i64-register.js
A JSTests/wasm/stress/js-to-wasm-i64-stack.js
A JSTests/wasm/stress/js-to-wasm-many-double-from-js.js
A JSTests/wasm/stress/js-to-wasm-many-i64.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGOperations.cpp
M Source/JavaScriptCore/dfg/DFGOperations.h
M Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/jit/AssemblyHelpers.h
M Source/JavaScriptCore/runtime/JSBigInt.h
M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp
Log Message:
-----------
Cherry-pick da3929b44d5a. rdar://problem/104794806
[JSC] Add I64 support for Wasm IC and FTL Wasm fast call
https://bugs.webkit.org/show_bug.cgi?id=251332
rdar://104794806
Reviewed by Tadeu Zagallo.
This patch adds I64 support for Wasm IC and FTL Wasm fast call. This makes it possible to accept all major wasm types in IC and Wasm fast calls,
so we can reasonably assume that we will always go to this IC or fast call when the callsite is performance enough.
What we need is extracting I64 from HeapBigInt. This patch adds AssemblyHelpers::toBigInt64, which takes JSBigInt and extract I64 for wasm.
Microbenchmark showed 10x improvement (following script's iteration count is modified to make the core part running longer for measurement).
DYLD_FRAMEWORK_PATH=$VM $VM/jsc -m js-to-wasm-many-i64.js 0.62s user 0.05s system 102% cpu 0.653 total
DYLD_FRAMEWORK_PATH=$VM $VM/jsc -m js-to-wasm-many-i64.js 5.11s user 0.09s system 83% cpu 6.184 total
* JSTests/wasm/stress/js-to-wasm-many-double-from-js.js: Added.
(async test):
* JSTests/wasm/stress/js-to-wasm-many-i64.js: Added.
(async test):
* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* Source/JavaScriptCore/dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* Source/JavaScriptCore/dfg/DFGOperations.h:
* Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* Source/JavaScriptCore/jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::toBigInt64):
* Source/JavaScriptCore/runtime/JSBigInt.h:
* Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
Canonical link: https://commits.webkit.org/259584@main
Canonical link: https://commits.webkit.org/259548.163@safari-7615-branch
Commit: dd0672a5fb6b678cd4d62599e5bfb9ca9c931a75
https://github.com/WebKit/WebKit/commit/dd0672a5fb6b678cd4d62599e5bfb9ca9c931a75
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M LayoutTests/platform/ios/TestExpectations
Log Message:
-----------
Cherry-pick 259600 at main (2556c14bd4fe). rdar://104844002
[WebGPU] Lots of iOS debug asserts in http/tests/webgpu
https://bugs.webkit.org/show_bug.cgi?id=251405
rdar://104844002
Unreviewed.
I thought iOS fell back to platform/mac/TestExpectations, but apparently it doesn't.
* LayoutTests/platform/ios/TestExpectations:
Canonical link: https://commits.webkit.org/259600@main
Canonical link: https://commits.webkit.org/259548.163@safari-7615-branch
Commit: 3cc30ef58a324c612fd88aa665d5446d43e1c25c
https://github.com/WebKit/WebKit/commit/3cc30ef58a324c612fd88aa665d5446d43e1c25c
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py
Log Message:
-----------
Cherry-pick 260117 at main (d1b770d8e28b). rdar://105197556
[git-webkit] Consider redaction of all issues in PR
https://bugs.webkit.org/show_bug.cgi?id=251960
rdar://105197556
Reviewed by Elliott Williams.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py:
(PullRequest.create_pull_request): Check the redaction status of every commit on
the pull-request branch.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py:
(TestDoPullRequest.test_github_branch_secondary_redacted):
Canonical link: https://commits.webkit.org/260117@main
Canonical link: https://commits.webkit.org/259548.164@safari-7615-branch
Commit: 3eb4ecdc5918a16544570b796288d08cad4f72bd
https://github.com/WebKit/WebKit/commit/3eb4ecdc5918a16544570b796288d08cad4f72bd
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/cacert.pem
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
Log Message:
-----------
Cherry-pick 260271 at main (1ba0b182925a). rdar://105459368
[webkitscmpy] Include certificate root for Apple infrastructure
https://bugs.webkit.org/show_bug.cgi?id=252257
rdar://105459368
Reviewed by Ryan Haddad.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/cacert.pem: Add 'AAA Certificate Services O'.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
Canonical link: https://commits.webkit.org/260271@main
Canonical link: https://commits.webkit.org/259548.165@safari-7615-branch
Commit: 6fc0a52315fa4fa7809e3bf71eccbfa2a5ead3e7
https://github.com/WebKit/WebKit/commit/6fc0a52315fa4fa7809e3bf71eccbfa2a5ead3e7
Author: Ryan Haddad <ryanhaddad at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/ios/fast/css-generated-content/initial-letter-basic-expected.txt
M LayoutTests/platform/ios/fast/css-generated-content/initial-letter-border-padding-expected.txt
M LayoutTests/platform/ios/fast/css-generated-content/initial-letter-clearance-expected.txt
M LayoutTests/platform/ios/fast/css-generated-content/initial-letter-descender-expected.txt
M LayoutTests/platform/ios/fast/css-generated-content/initial-letter-raised-expected.txt
M LayoutTests/platform/ios/fast/css-generated-content/initial-letter-sunken-expected.txt
Log Message:
-----------
Cherry-pick 259640 at main (28c0165eebae). rdar://104836521
REGRESSION (259540 at main): [ iOS ] 6 x fast/css-generated-content/ tests are constant text failures.
https://bugs.webkit.org/show_bug.cgi?id=251394
rdar://104836521
Unreviewed test gardening.
Rebaseline for test failures.
* LayoutTests/platform/ios/fast/css-generated-content/initial-letter-basic-expected.txt:
* LayoutTests/platform/ios/fast/css-generated-content/initial-letter-border-padding-expected.txt:
* LayoutTests/platform/ios/fast/css-generated-content/initial-letter-clearance-expected.txt:
* LayoutTests/platform/ios/fast/css-generated-content/initial-letter-descender-expected.txt:
* LayoutTests/platform/ios/fast/css-generated-content/initial-letter-raised-expected.txt:
* LayoutTests/platform/ios/fast/css-generated-content/initial-letter-sunken-actual.txt: Added.
Canonical link: https://commits.webkit.org/259640@main
Canonical link: https://commits.webkit.org/259548.166@safari-7615-branch
Commit: 3fde2f202963ba97ebac67e1d8cbf2ea8d661bfa
https://github.com/WebKit/WebKit/commit/3fde2f202963ba97ebac67e1d8cbf2ea8d661bfa
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm
Log Message:
-----------
Cherry-pick dd929cd085dc. rdar://problem/100155151
Find on page intermittently fails to show results in PDFs in Safari
https://bugs.webkit.org/show_bug.cgi?id=251311
rdar://100155151
Reviewed by Aditya Keerthi.
When viewing a PDF in Safari, Find in Page fails after the following sequence
of events:
1. Open a PDF in Safari
2. Activate Find in Page and search for a string
3. Refresh the page
4. Activate Find in Page again
After the last step, Find In Page will continue to return zero results regardless
of the search string.
This is because the `WKPDFView` instance is used as the `UIFindSession`'s "searchable object"
to process the search. When the page is refreshed, a new `WKPDFView` instance is created, but
not a new `UIFindSession`, and so the session has lost its searchable object.
This PR fixes this by setting the session's searchable object to the new `WKPDFView` in the
`_didCommitLoadForMainFrame` method, which is called after the new `WKPDFView` has been created.
This ensures that the session's searchable object is up to date.
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _didCommitLoadForMainFrame]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:
(swizzledPerformTextSearchWithQueryString):
(TEST):
Canonical link: https://commits.webkit.org/259655@main
Canonical link: https://commits.webkit.org/259548.168@safari-7615-branch
Commit: 9e4a0471766a3e411e32cbaa2f61fd5d20e4349b
https://github.com/WebKit/WebKit/commit/9e4a0471766a3e411e32cbaa2f61fd5d20e4349b
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M LayoutTests/platform/ios-wk2/TestExpectations
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WTF/wtf/PlatformEnableCocoa.h
Log Message:
-----------
Cherry-pick b8652a99205d. rdar://problem/103571674
Disable WebGL in worker threads.
https://bugs.webkit.org/show_bug.cgi?id=251341
<rdar://103571674>
Reviewed by Brent Fulgham.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* LayoutTests/platform/ios-wk2/TestExpectations:
Canonical link: https://commits.webkit.org/259711@main
Canonical link: https://commits.webkit.org/259548.169@safari-7615-branch
Commit: 5d957e3234378ec1df22bdb4e7b34f32d837755f
https://github.com/WebKit/WebKit/commit/5d957e3234378ec1df22bdb4e7b34f32d837755f
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WebCore/layout/integration/inline/InlineIteratorTextBox.cpp
Log Message:
-----------
Cherry-pick 7289c5d771f2. rdar://problem/101874893
REGRESSION(241899 at main): Find on Page fails to highlight SVG text content
https://bugs.webkit.org/show_bug.cgi?id=251438
Reviewed by Antti Koivisto.
Let's restore before-241899 at main state, where we called SVGInlineTextBox::localSelectionRect on SVG text content.
* Source/WebCore/layout/integration/inline/InlineIteratorTextBox.cpp:
(WebCore::InlineIterator::TextBox::selectionRect const):
Canonical link: https://commits.webkit.org/259753@main
Canonical link: https://commits.webkit.org/259548.170@safari-7615-branch
Commit: 7d8e265b41d872d5ffdbbf7eccd00e251e214129
https://github.com/WebKit/WebKit/commit/7d8e265b41d872d5ffdbbf7eccd00e251e214129
Author: Said Abou-Hallawa <said at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M LayoutTests/fast/canvas/canvas-scale-strokePath-shadow-expected.txt
M LayoutTests/fast/canvas/canvas-scale-strokePath-shadow.html
R LayoutTests/platform/ios/fast/canvas/canvas-scale-strokePath-shadow-expected.txt
R LayoutTests/platform/mac/fast/canvas/canvas-scale-strokePath-shadow-expected.txt
R LayoutTests/platform/win/fast/canvas/canvas-scale-strokePath-shadow-expected.txt
Log Message:
-----------
Cherry-pick d538ed723a99. rdar://problem/104761905
Relax the checks of the alpha channel of the blurred stroke in fast/canvas/canvas-scale-strokePath-shadow.html
https://bugs.webkit.org/show_bug.cgi?id=251558
rdar://104761905
Reviewed by Dean Jackson.
Relax the check for the alpha channel of the blurred stroke in this test to avoid
rebase-line the expectation in the future. And git rid of the platform expectation.
Ensure the alpha channel of the blurred stroke is between 75 and 225 instead of
175 and 225.
* LayoutTests/fast/canvas/canvas-scale-strokePath-shadow-expected.txt:
* LayoutTests/fast/canvas/canvas-scale-strokePath-shadow.html:
* LayoutTests/platform/ios/fast/canvas/canvas-scale-strokePath-shadow-expected.txt: Removed.
* LayoutTests/platform/mac/fast/canvas/canvas-scale-strokePath-shadow-expected.txt: Removed.
* LayoutTests/platform/win/fast/canvas/canvas-scale-strokePath-shadow-expected.txt: Removed.
Canonical link: https://commits.webkit.org/259765@main
Canonical link: https://commits.webkit.org/259548.171@safari-7615-branch
Commit: 8a47c27ffb5e0bd7e6088e8e765494ab2e87b6e5
https://github.com/WebKit/WebKit/commit/8a47c27ffb5e0bd7e6088e8e765494ab2e87b6e5
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp
Log Message:
-----------
Cherry-pick ed56087035ea. rdar://problem/102302792
REGRESSION (iOS 16): sina.cn: Find on Page highlights obscure the text behind them
https://bugs.webkit.org/show_bug.cgi?id=251707
rdar://102302792
Reviewed by Wenson Hsieh.
sina.cn contains elements with "-webkit-user-select: none". Prior to iOS 16,
any text found within these elements would count towards the number of results,
but would not be highlighted.
Find-in-page logic was refactored in iOS 16 to support UIKit's new Find & Replace
API. As part of these changes, find-in-page began storing/restoring ranges, rather
than simply updating selection. Consequently, the `TextIndicator` used to draw
highlights is created from a `SimpleRange`, rather than the current selection.
The previously used constructor would early return if the selection was empty
(as is the case when attempting to select a "-webkit-user-select: none" element),
resulting the the pre-iOS 16 behavior described above.
`TextIndicator` does not know how to take snapshots of "-webkit-user-select: none"
content. Consequently, the highlight is painted without any text, leading to
found text getting obscured.
For now, restore the pre-iOS 16 behavior, and do not draw highlights if the
selection is empty. In the longer term, `TextIndicator` should be taught to
draw this content (tracked in webkit.org/b/251709). Note that following this
change, there is still a net progression over pre-iOS 16 behavior, where
WebKit will indicate found results with "-webkit-user-select: none" by drawing
"holes".
* Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp:
(WebKit::WebFoundTextRangeController::drawRect):
Additionally, move the use of `GraphicsContext` closer to the painting logic to
avoid running unnecessary code.
Canonical link: https://commits.webkit.org/259857@main
Canonical link: https://commits.webkit.org/259548.172@safari-7615-branch
Commit: f44e26acd224261b5239ac634249c53de937b707
https://github.com/WebKit/WebKit/commit/f44e26acd224261b5239ac634249c53de937b707
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorkerServerConnection.cpp
Log Message:
-----------
Cherry-pick c7229df52bd1. rdar://problem/105018668
Add allowsFirstPartyForCookies in WebSharedWorkerServerConnection::requestSharedWorker
https://bugs.webkit.org/show_bug.cgi?id=251720
rdar://105018668
Reviewed by Alex Christensen.
We need to add allowsFirstPartyForCookies when requesting shared worker
so that a compromised web process doesn't access cookies its not
supposed to.
* Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorkerServerConnection.cpp:
(WebKit::WebSharedWorkerServerConnection::requestSharedWorker):
Canonical link: https://commits.webkit.org/259859@main
Canonical link: https://commits.webkit.org/259548.173@safari-7615-branch
Commit: 87bdc17fcbf8e010b901f6e1365c71d5619b0d3d
https://github.com/WebKit/WebKit/commit/87bdc17fcbf8e010b901f6e1365c71d5619b0d3d
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WebCore/platform/graphics/displaylists/DisplayListItemBuffer.h
Log Message:
-----------
Cherry-pick b7a8c3d2ff89. rdar://problem/105011333
DisplayList::ItemBuffer wastes a lot of vector capacity
https://bugs.webkit.org/show_bug.cgi?id=251700
<rdar://problem/105011333>
Reviewed by Wenson Hsieh.
The Vector<ItemBufferHandle, 2> ItemBuffer::m_readOnlyBuffers gets allocated for every GlyphDisplayListCache
entry, but is never used there. It's also very rarely used with GPU process rendering (I never saw use of
m_readOnlyBuffers running MotionMark), so give it default capacity 0, and capacity 2 when it does get allocated.
* Source/WebCore/platform/graphics/displaylists/DisplayListItemBuffer.h:
Canonical link: https://commits.webkit.org/259861@main
Canonical link: https://commits.webkit.org/259548.174@safari-7615-branch
Commit: c83439da5138b14037a754636aabe01341d8deba
https://github.com/WebKit/WebKit/commit/c83439da5138b14037a754636aabe01341d8deba
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WebCore/layout/formattingContexts/inline/InlineRect.h
M Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp
Log Message:
-----------
Cherry-pick cc1ff21b89a3. rdar://problem/105047621
[IFC] Use computed LineBox geometry in InlineDisplayLineBuilder::build
https://bugs.webkit.org/show_bug.cgi?id=251342
Reviewed by Antti Koivisto.
We already compute these (logical top/left/width) values for LineBox. Let's not compute them again.
This is also in preparation for fixing webkit.org/b/251313.
* Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp:
(WebCore::Layout::InlineDisplayLineBuilder::build const):
Canonical link: https://commits.webkit.org/259863@main
Canonical link: https://commits.webkit.org/259548.175@safari-7615-branch
Commit: 79752b904edd0b49912b347fb2e4661f156e8783
https://github.com/WebKit/WebKit/commit/79752b904edd0b49912b347fb2e4661f156e8783
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
A LayoutTests/platform/glib/webgl/webgl-ext-norm16-texture-texsubimage-nocrash-expected.txt
A LayoutTests/platform/mac-bigsur-wk2/webgl/webgl-ext-norm16-texture-texsubimage-nocrash-expected.txt
A LayoutTests/webgl/webgl-ext-norm16-texture-texsubimage-nocrash-expected.txt
A LayoutTests/webgl/webgl-ext-norm16-texture-texsubimage-nocrash.html
M Source/ThirdParty/ANGLE/src/libANGLE/ErrorStrings.h
M Source/ThirdParty/ANGLE/src/libANGLE/formatutils.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/validationES.cpp
Log Message:
-----------
Cherry-pick b34b56522035. rdar://problem/104340031
EXT_norm16_texture fails with texSubImage and signed types
https://bugs.webkit.org/show_bug.cgi?id=252039
rdar://104340031
Reviewed by Dean Jackson.
The supported texture format tables would have entries for
a signed or unsigned internal format and matching type.
The texSubImage variants do not communicate the sized internal format,
rather unsized format type. Data parameters are validated based on
format, not internal format. For these, the signed variants were
missing.
Add texture format table entries for signed types that match the format
parameters.
Add a precautionary validation case so that future such bugs would not
pass the control flow forward, into the copying phase.
* LayoutTests/webgl/webgl-ext-norm16-texture-texsubimage3d-nocrash.html: Added.
* Source/ThirdParty/ANGLE/src/libANGLE/ErrorStrings.h:
* Source/ThirdParty/ANGLE/src/libANGLE/formatutils.cpp:
(gl::BuildInternalFormatInfoMap):
* Source/ThirdParty/ANGLE/src/libANGLE/validationES.cpp:
(gl::ValidImageDataSize):
Canonical link: https://commits.webkit.org/260114@main
Canonical link: https://commits.webkit.org/259548.176@safari-7615-branch
Commit: a91d61e8bfa1f2b46c01332f8e1769267b1da7ba
https://github.com/WebKit/WebKit/commit/a91d61e8bfa1f2b46c01332f8e1769267b1da7ba
Author: Brent Fulgham <bfulgham at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
Log Message:
-----------
Cherry-pick 24427685c584. rdar://problem/104759290
Numerous "Stable" feature flags appear miscategorized, should be "Mature"
https://bugs.webkit.org/show_bug.cgi?id=252071
<rdar://104759290>
Reviewed by Patrick Angle.
Numerous "Stable" feature flags appear miscategorized, and should instead
be "Mature".
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Canonical link: https://commits.webkit.org/260129@main
Canonical link: https://commits.webkit.org/259548.177@safari-7615-branch
Commit: df089965a1d414507007b78f6af4ebc4cda4e188
https://github.com/WebKit/WebKit/commit/df089965a1d414507007b78f6af4ebc4cda4e188
Author: David Kilzer <ddkilzer at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Configurations/WebKitTargetConditionals.xcconfig
Log Message:
-----------
Cherry-pick adf544afeb9f. rdar://problem/105284669
Fix mistakes in WebKitTargetConditionals.xcconfig
https://bugs.webkit.org/show_bug.cgi?id=252064
<rdar://105284669>
Reviewed by Elliott Williams.
This change correctly defines these macros to "_SINCE_" strings
as the prior, buggy definitions were circular and resulted in
no value being set.
* Configurations/WebKitTargetConditionals.xcconfig:
(WK_IOS_17_):
(WK_TVOS_16_):
(WK_TVOS_17_):
Canonical link: https://commits.webkit.org/260134@main
Canonical link: https://commits.webkit.org/259548.178@safari-7615-branch
Commit: 6e25bbc66ae06e85161274e9de875de44d64fdea
https://github.com/WebKit/WebKit/commit/6e25bbc66ae06e85161274e9de875de44d64fdea
Author: Alexey Shvayka <ashvayka at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
A JSTests/stress/spread-arguments-null-proto-no-crash.js
M Source/JavaScriptCore/runtime/ClonedArguments.cpp
Log Message:
-----------
Cherry-pick 146475121307. rdar://problem/105295643
ClonedArguments::isIteratorProtocolFastAndNonObservable() should check didTransition() earlier
https://bugs.webkit.org/show_bug.cgi?id=252083
<rdar://105295643>
Reviewed by Yusuke Suzuki.
This change hoists didTransition() check to prevent nullptr deref crash when calling needsSlowPutIndexing().
* JSTests/stress/spread-arguments-null-proto-no-crash.js: Added.
* Source/JavaScriptCore/runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::isIteratorProtocolFastAndNonObservable):
Canonical link: https://commits.webkit.org/260145@main
Canonical link: https://commits.webkit.org/259548.179@safari-7615-branch
Commit: 96a67d4a37e9445925a272e0db3cb383500ea631
https://github.com/WebKit/WebKit/commit/96a67d4a37e9445925a272e0db3cb383500ea631
Author: Karl Rackler <rackler at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
Log Message:
-----------
Cherry-pick beb0550b9dde. rdar://problem/104759290
Revert [260129 at main] Numerous "Stable" feature flags appear miscategorized, should be "Mature"
https://bugs.webkit.org/show_bug.cgi?id=252071
<rdar://104759290>
Unreviewed revert
This reverts because it broke 67+ tests.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Canonical link: https://commits.webkit.org/260164@main
Canonical link: https://commits.webkit.org/259548.180@safari-7615-branch
Commit: b36aff9a8ddac0ed70c82f65acdab4fb7a6b56ba
https://github.com/WebKit/WebKit/commit/b36aff9a8ddac0ed70c82f65acdab4fb7a6b56ba
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: 2023-02-14 (Tue, 14 Feb 2023)
Changed paths:
M Source/WebCore/platform/graphics/cocoa/GraphicsContextGLCocoa.mm
Log Message:
-----------
Cherry-pick ab998e353f10. rdar://problem/105174119
ANGLE Metal program memory cache is unbounded
https://bugs.webkit.org/show_bug.cgi?id=251915
rdar://105174119
Reviewed by Matt Woodrow.
Disable the memory cache for now, it may consume too much memory
on pages that compile many programs. It does not benefit normal
WebGL apps, as those should not recompile the same program over and
over again.
* Source/WebCore/platform/graphics/cocoa/GraphicsContextGLCocoa.mm:
(WebCore::initializeEGLDisplay):
Canonical link: https://commits.webkit.org/260235@main
Canonical link: https://commits.webkit.org/259548.181@safari-7615-branch
Commit: cd2c5ede52cedb703ffbf9b681d22b2b4204c040
https://github.com/WebKit/WebKit/commit/cd2c5ede52cedb703ffbf9b681d22b2b4204c040
Author: Gavin Phillips <gavin.p at apple.com>
Date: 2023-02-15 (Wed, 15 Feb 2023)
Changed paths:
A Source/WebKit/NetworkProcess/mac/SecItemShim.cpp
A Source/WebKit/NetworkProcess/mac/SecItemShim.h
R Source/WebKit/Shared/mac/SecItemShim.cpp
R Source/WebKit/Shared/mac/SecItemShim.h
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick 259835 at main (71cadaca836c). rdar://105002389
Move SecItemShim to the Network Process subdirectory
https://bugs.webkit.org/show_bug.cgi?id=251678
rdar://105002389
Reviewed by Alex Christensen.
The SecItemShim is only required in the Network Process, so move the
code out of shared and into the Network Process specific directory.
* Source/WebKit/Shared/mac/SecItemShim.cpp: Removed.
* Source/WebKit/Shared/mac/SecItemShim.h: Removed.
* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::connectionWillOpen):
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/259835@main
Canonical link: https://commits.webkit.org/259548.181@safari-7615-branch
Commit: 0a169be47de4cb8c77827aa75276e29a710fe408
https://github.com/WebKit/WebKit/commit/0a169be47de4cb8c77827aa75276e29a710fe408
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-02-15 (Wed, 15 Feb 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm
Log Message:
-----------
REGRESSION (259548.23 at safari-7615-branch): Invalid MESSAGE_CHECK when sending Yahoo email
https://bugs.webkit.org/show_bug.cgi?id=252293
<rdar://105471203>
Reviewed by Alex Christensen.
When sending an email from mail.yahoo.com on iPhone, if sending while the keyboard is visible, the UI process
receives a ScrollingTree where overflow scrolling proxy nodes have a reference to an overflow scrolling node
that no longer exists. Guard against this by null-checking the result of calls to scrollingTree()->nodeForID()
in a couple of places, before checking their types.
rdar://105481381 tracks a better long-term fix.
* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
(WebKit::RemoteScrollingCoordinatorProxyIOS::establishLayerTreeScrollingRelations):
Canonical link: https://commits.webkit.org/259548.182@safari-7615-branch
Commit: 71834ce0e87bdd6fa9bfcd923a5ec4f7d1989781
https://github.com/WebKit/WebKit/commit/71834ce0e87bdd6fa9bfcd923a5ec4f7d1989781
Author: Claudio Saavedra <csaavedra at igalia.com>
Date: 2023-02-15 (Wed, 15 Feb 2023)
Changed paths:
A LayoutTests/fast/dom/element-clearing-display-contents-on-node-removal-expected.txt
A LayoutTests/fast/dom/element-clearing-display-contents-on-node-removal.html
Log Message:
-----------
Cherry-pick 256843.10 at webkit-2022.12-embargoed (b7f9b7f4679b). rdar://102808942
Add test for element's display contents change on sibling removal
https://bugs.webkit.org/show_bug.cgi?id=248772
Reviewed by Tim Nguyen.
This was already fixed with #248776, but add the test for completeness.
* LayoutTests/fast/dom/element-clearing-display-contents-on-node-removal-expected.txt: Added.
* LayoutTests/fast/dom/element-clearing-display-contents-on-node-removal.html: Added.
Canonical link: https://commits.webkit.org/256843.10@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/259548.183@safari-7615-branch
Commit: 01ceccf02b5f3011b49c5f08d10ca3851ccde4fd
https://github.com/WebKit/WebKit/commit/01ceccf02b5f3011b49c5f08d10ca3851ccde4fd
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-02-15 (Wed, 15 Feb 2023)
Changed paths:
A LayoutTests/fast/frames/disconnected-frame-set-to-eager-crash-expected.txt
A LayoutTests/fast/frames/disconnected-frame-set-to-eager-crash.html
Log Message:
-----------
Cherry-pick 256843.11 at webkit-2022.12-embargoed (7d616c4d06eb). rdar://98898374
Add crash test for disconnected frame switching to eager
https://bugs.webkit.org/show_bug.cgi?id=245377
Reviewed by Ryosuke Niwa.
Add crash test for disconnected frame switching to eager.
* LayoutTests/fast/frames/disconnected-frame-set-to-eager-crash-expected.txt: Added.
* LayoutTests/fast/frames/disconnected-frame-set-to-eager-crash.html: Added.
Canonical link: https://commits.webkit.org/256843.11@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/259548.184@safari-7615-branch
Commit: 41af95f8b4e79530811897ff9acbe06756ebc159
https://github.com/WebKit/WebKit/commit/41af95f8b4e79530811897ff9acbe06756ebc159
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-02-15 (Wed, 15 Feb 2023)
Changed paths:
M Source/WebCore/loader/SubresourceLoader.cpp
Log Message:
-----------
Clear the resource counter when releasingResources
https://bugs.webkit.org/show_bug.cgi?id=252200
rdar://104908871
Reviewed by Chris Dumez.
SubResourceLoader will clear the m_resource after releasing it, but the
resource counter still holds a raw pointer to it. This causes a UAF
issue. This fix clears the resource counter so that we don't end up
using it after releasing the resource.
* Source/WebCore/loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::releaseResources):
Canonical link: https://commits.webkit.org/259548.185@safari-7615-branch
Commit: 1aa5ac3e3745f20045d7c831c138b0a6a8d9933a
https://github.com/WebKit/WebKit/commit/1aa5ac3e3745f20045d7c831c138b0a6a8d9933a
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-02-15 (Wed, 15 Feb 2023)
Changed paths:
M Source/WebCore/loader/SubresourceLoader.cpp
M Source/WebCore/loader/SubresourceLoader.h
M Source/WebCore/loader/cache/CachedResource.h
M Source/WebCore/loader/cache/CachedResourceLoader.h
Log Message:
-----------
Use WeakPtr to track resources in SubresourceLoader
https://bugs.webkit.org/show_bug.cgi?id=252200
rdar://104908871
Reviewed by Chris Dumez.
CachedResource can get deallocated when the SubresourceLoader releases
its resources, in which case we'd be accessing a dangling pointer. This
change adopts WeakPtr for CachedResource so that we don't have a UAF.
* Source/WebCore/loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::didFinishLoading):
(WebCore::SubresourceLoader::didFail):
* Source/WebCore/loader/SubresourceLoader.h:
* Source/WebCore/loader/cache/CachedResource.h:
* Source/WebCore/loader/cache/CachedResourceLoader.h:
Canonical link: https://commits.webkit.org/259548.186@safari-7615-branch
Compare: https://github.com/WebKit/WebKit/compare/60635d719037%5E...1aa5ac3e3745
More information about the webkit-changes
mailing list