Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 1a85d4fc2323736582b5a1b6b27d7e315d3233dc
https://github.com/WebKit/WebKit/commit/1a85d4fc2323736582b5a1b6b27d7e315d3233dc
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-17 (Wed, 17 Dec 2025)
Changed paths:
A JSTests/wasm/stress/catch-pinned-registers.js
M Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
Log Message:
-----------
[JSC] Wasm OMG Catch entry should setup pinned registers at prologue
https://bugs.webkit.org/show_bug.cgi?id=301324
rdar://161754890
Reviewed by Dan Hecht.
When wasm memory is shared or signaling, wasm memory base address never
changes. So when we may execute a code which can clobber instance,
instead of loading it from a instance, we get B3 Value representing it.
However, normal code in the root block touches this value, thus which
can be used before we set up these values from catch entry.
Catch prologue will be executed for each entry case, and it will be
executed before any of OMG code. Thus we should set up all necessary
registers inside this prologue. This patch fills pinned registers when
necessary inside catch prologue thunk.
Test: JSTests/wasm/stress/catch-pinned-registers.js
* JSTests/wasm/stress/catch-pinned-registers.js: Added.
(instantiate):
(async let):
* Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h:
(JSC::Wasm::buildEntryBufferForCatch):
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp:
(JSC::Wasm::OMGIRGenerator::emitCatchImpl):
(JSC::Wasm::OMGIRGenerator::emitCatchTableImpl):
Originally-landed-as: 301765.98@safari-7623-branch (d8b7d2999677).
rdar://166338852
Canonical link: https://commits.webkit.org/304612@main
Commit: 50b0e0bcc62b24506996736cda133753c5101a34
https://github.com/WebKit/WebKit/commit/50b0e0bcc62b24506996736cda133753c5101a34
Author: Matthew Finkel <[email protected]>
Date: 2025-12-17 (Wed, 17 Dec 2025)
Changed paths:
M Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKit/GetUserMedia.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/NotificationAPI.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/example.webarchive
Log Message:
-----------
[webarchive] Isolate web archive permissions
https://bugs.webkit.org/show_bug.cgi?id=295941
rdar://149069663
Reviewed by Eric Carlson.
Currently, a web archive inherits any cached permission that was previously
granted to the web archive's origin (as specified by the archive's main
resource). This means a malicious web archive can covertly gain access to some
sensitive web APIs and physical resources without prompting the user for
access. This is an opportunistic attack, and relies on the user previously
granting permission.
This patch adjusts the logic for user media and geolocation such that we always
prompt when the page loaded a web archive. All other web API permissions are
either not cached or they are not currently supported in web archives.
This patch does not directly address any phishing/spoofing/impersonation
threats that are possible with prompts initiated by a web archive, and the
associated permission prompts may still rely on the page's origin.
* Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
(WebKit::UserMediaPermissionRequestManagerProxy::denyRequest):
(WebKit::UserMediaPermissionRequestManagerProxy::grantRequest):
(WebKit::UserMediaPermissionRequestManagerProxy::hasGrantedRequest const):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::shouldAlwaysPromptForPermission const):
New helper function that ensures we carefully consider how existing and new
permissions should be handled in a web archive
(WebKit::WebPageProxy::queryPermission):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKit/GetUserMedia.mm:
(TestWebKitAPI::(GetUserMedia, OriginAndWebArchivePermission)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/NotificationAPI.mm:
(TestWebKitAPI::TEST(Notification, WebArchiveNotificationNotSupported)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm:
((WebKit, GeolocationPermissionInIFrameExampleWebArchive)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/example.webarchive: Added.
Originally-landed-as: 301765.154@safari-7623-branch (9ec1b822d817).
rdar://166337769
Canonical link: https://commits.webkit.org/304613@main
Commit: 3cccf4011f4e795c5db45a6549dc80b37ef670bc
https://github.com/WebKit/WebKit/commit/3cccf4011f4e795c5db45a6549dc80b37ef670bc
Author: Brady Eidson <[email protected]>
Date: 2025-12-17 (Wed, 17 Dec 2025)
Changed paths:
A
LayoutTests/http/tests/notifications/request-in-cross-origin-frame-expected.txt
A LayoutTests/http/tests/notifications/request-in-cross-origin-frame.html
A
LayoutTests/http/tests/notifications/resources/request-in-cross-origin-subframe.html
M Source/WebCore/Modules/notifications/Notification.cpp
Log Message:
-----------
Cross-origin iframe can trigger native Notification permission prompt
rdar://163197557
Reviewed by Ben Nham.
The spec is currently silent on this, but the other browsers don't allow
cross-origin iframes
to request notification permission.
So we'll now do the same.
Test: http/tests/notifications/request-in-cross-origin-frame.html
*
LayoutTests/http/tests/notifications/request-in-cross-origin-frame-expected.txt:
Added.
* LayoutTests/http/tests/notifications/request-in-cross-origin-frame.html:
Added.
*
LayoutTests/http/tests/notifications/resources/request-in-cross-origin-subframe.html:
Added.
* Source/WebCore/Modules/notifications/Notification.cpp:
(WebCore::Notification::requestPermission):
Originally-landed-as: 301765.166@safari-7623-branch (b47fc7e04bef).
rdar://166337737
Canonical link: https://commits.webkit.org/304614@main
Commit: 4d476621f46b203e81c0166645f72e4a56c5c6b9
https://github.com/WebKit/WebKit/commit/4d476621f46b203e81c0166645f72e4a56c5c6b9
Author: Rob Buis <[email protected]>
Date: 2025-12-17 (Wed, 17 Dec 2025)
Changed paths:
A LayoutTests/fast/editing/recursive-unapply-edit-command-crash-expected.txt
A LayoutTests/fast/editing/recursive-unapply-edit-command-crash.html
M Source/WebCore/editing/Editor.cpp
Log Message:
-----------
[WebKit][Main+SU?] [3cff0e3a4d6faa36] ASAN_SEGV |
WebCore::Page::respondToUnappliedWritingToolsEditing;
WebCore::Editor::unappliedEditing; WebCore::EditCommandComposition::unapply
https://bugs.webkit.org/show_bug.cgi?id=300375
rdar://162025465
Reviewed by Ryosuke Niwa.
Make sure page is non null before calling
respondToUnappliedWritingToolsEditing. This is closely related to
284805@main, so base the test case on recursive-reapply-edit-command-crash.html.
Test: fast/editing/recursive-unapply-edit-command-crash.html
* LayoutTests/fast/editing/recursive-unapply-edit-command-crash-expected.txt:
Added.
* LayoutTests/fast/editing/recursive-unapply-edit-command-crash.html: Added.
* Source/WebCore/editing/Editor.cpp:
(WebCore::Editor::unappliedEditing):
Originally-landed-as: [email protected] (e7840d7d1a5e).
rdar://166337431
Canonical link: https://commits.webkit.org/304615@main
Commit: 683c4e9a970eca02f16b784827ec2e179decf092
https://github.com/WebKit/WebKit/commit/683c4e9a970eca02f16b784827ec2e179decf092
Author: Tyler Wilcock <[email protected]>
Date: 2025-12-17 (Wed, 17 Dec 2025)
Changed paths:
A LayoutTests/accessibility/mac/find-sentence-boundary-crash-expected.txt
A LayoutTests/accessibility/mac/find-sentence-boundary-crash.html
M Source/WTF/wtf/text/TextBreakIterator.cpp
M Source/WTF/wtf/text/TextBreakIterator.h
M Source/WebCore/accessibility/AXTextMarker.cpp
Log Message:
-----------
AXTextMarker's use of sentenceBreakIterator off the main-thread is not
threadsafe and can cause crashes
https://bugs.webkit.org/show_bug.cgi?id=301649
rdar://162811597
Reviewed by Joshua Hoffman.
If the main-thread is using sentenceBreakIterator (which uses a static
UBreakIterator*), and the accessibility thread
also simulataneously tries to use it via previousSentenceStartFromOffset or
nextSentenceEndFromOffset, a crash can
happen because UBreakIterators are not threadsafe.
Fix this by introducing a new WTF::NonSharedSentenceBreakIterator, and use that
in AXTextMarker instead.
Test: accessibility/mac/find-sentence-boundary-crash.html
* LayoutTests/accessibility/mac/find-sentence-boundary-crash-expected.txt:
Added.
* LayoutTests/accessibility/mac/find-sentence-boundary-crash.html: Added.
* Source/WTF/wtf/text/TextBreakIterator.cpp:
(WTF::getNonSharedSentenceBreakIterator):
(WTF::cacheNonSharedSentenceBreakIterator):
(WTF::NonSharedSentenceBreakIterator::NonSharedSentenceBreakIterator):
(WTF::NonSharedSentenceBreakIterator::~NonSharedSentenceBreakIterator):
* Source/WTF/wtf/text/TextBreakIterator.h:
(WTF::NonSharedSentenceBreakIterator::operator UBreakIterator* const):
* Source/WebCore/accessibility/AXTextMarker.cpp:
(WebCore::previousSentenceStartFromOffset):
(WebCore::nextSentenceEndFromOffset):
Originally-landed-as: 301765.196@safari-7623-branch (ee21633d1dd7).
rdar://166337163
Canonical link: https://commits.webkit.org/304616@main
Compare: https://github.com/WebKit/WebKit/compare/93ddb5c2ffab...683c4e9a970e
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
