Branch: refs/heads/safari-7618.3.11.11-branch
Home: https://github.com/WebKit/WebKit
Commit: c5362127111b42249784671dbdb835edd9bc8e96
https://github.com/WebKit/WebKit/commit/c5362127111b42249784671dbdb835edd9bc8e96
Author: Mohsin Qureshi <mohs...@apple.com>
Date: 2024-07-02 (Tue, 02 Jul 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7618.3.11.11.1
Canonical link:
https://commits.webkit.org/272448.1100@safari-7618.3.11.11-branch
Commit: 830f7ba72e969a8c5f2d99464fcb3064bf9bed94
https://github.com/WebKit/WebKit/commit/830f7ba72e969a8c5f2d99464fcb3064bf9bed94
Author: Chris Dumez <cdu...@apple.com>
Date: 2024-07-02 (Tue, 02 Jul 2024)
Changed paths:
M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp
Log Message:
-----------
Cherry-pick bb685c487850. rdar://130531570
REGRESSION (iOS 17.6 beta): Hangs on realmahjongg.com and realcanasta.com
(both Safari and WKWebView)
https://bugs.webkit.org/show_bug.cgi?id=275852
rdar://130531570
Reviewed by Jer Noble.
AudioBufferSourceNode::setBufferForBindings() was running on the main
thread and
acquiring first the graphLock and then the processLock.
AudioBufferSourceNode::process()
would then run on the audio thread and acquire the processLock first and
then ref the
AudioBufferSourceNode, which would acquire the graphLock. The reversed
ordering in
which the locks are acquired would mean that we could deadlock.
* Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp:
(WebCore::AudioBufferSourceNode::setBufferForBindings):
Canonical link: https://commits.webkit.org/272448.1101@safari-7618-branch
Canonical link:
https://commits.webkit.org/272448.1101@safari-7618.3.11.11-branch
Commit: 4d7e1206db7a8c83c2ee6aa6b3742f2e696b5f0e
https://github.com/WebKit/WebKit/commit/4d7e1206db7a8c83c2ee6aa6b3742f2e696b5f0e
Author: Mohsin Qureshi <mohs...@apple.com>
Date: 2024-07-03 (Wed, 03 Jul 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7618.3.11.11.2
Canonical link:
https://commits.webkit.org/272448.1102@safari-7618.3.11.11-branch
Commit: 52d543a7d2f24b503480c2e70515216cd591a856
https://github.com/WebKit/WebKit/commit/52d543a7d2f24b503480c2e70515216cd591a856
Author: Daniel Liu <danl...@umich.edu>
Date: 2024-07-03 (Wed, 03 Jul 2024)
Changed paths:
A JSTests/wasm/stress/funcref-types.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
Cherry-pick 5b25ef6f6add. rdar://130746587
ref.as_non_null does not validate argument type
https://bugs.webkit.org/show_bug.cgi?id=276097
rdar://130746587
Reviewed by Yusuke Suzuki.
The function parser does not ensure ref.as_not_null takes in the correct
type; this may lead to issues downstream because of incorrect validation.
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
Canonical link: https://commits.webkit.org/272448.1102@safari-7618-branch
Canonical link:
https://commits.webkit.org/272448.1103@safari-7618.3.11.11-branch
Commit: cc3803a8ab5f541b0dfc9a1da0a21dfd18595fa2
https://github.com/WebKit/WebKit/commit/cc3803a8ab5f541b0dfc9a1da0a21dfd18595fa2
Author: Wenson Hsieh <wenson_hs...@apple.com>
Date: 2024-07-03 (Wed, 03 Jul 2024)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Cherry-pick bf0c0decaac7. rdar://130610141
Cherry-pick 703a5b6bfcf1. rdar://130610141
REGRESSION (iOS 17.2): Infinite recursion in
-[WKContentView(WKInteraction) inputViewForWebView]
https://bugs.webkit.org/show_bug.cgi?id=275171
rdar://127722998
Reviewed by Richard Robinson.
The changes in rdar://116751305&104994662 seem to have made it possible
for `-inputViewForWebView`
to trigger infinite recursion, due to a new `-[UITextInputAssistantItem
leadingBarButtonGroups]`
KVO listener in UIKit. Underneath this new KVO logic, UIKit calls into
some internal methods which
ultimately call back into `-[WKContentView inputViewForWebView]`. In
order of stack depth (growing
downwards), the reentrant calls to update the input accessory view look
like this:
```
-[WKContentView(WKInteraction) _updateAccessory]
-[WKContentView(WKInteraction) formAccessoryView]
-[WKFormAccessoryView _initForUniversalControlBar:] // <--- Setting up
WKFormAccessoryView
… (KVO triggered by setting leading/trailing bar button groups)
-[UISystemInputAssistantViewController
observeValueForKeyPath:ofObject:change:context:]
-[TUISystemInputAssistantView setInputAssistantItem:force:]
… (UIKit internals)
-[UIKeyboardSceneDelegate expectedInputViewSetIsCustom]
-[WKContentView(WKInteraction) inputViewForWebView]
-[WKContentView(WKInteraction) _updateAccessory]
-[WKContentView(WKInteraction) formAccessoryView]
-[WKFormAccessoryView _initForUniversalControlBar:] // <--- Setting up
WKFormAccessoryView (reentrancy!)
```
While I wasn't able to reproduce the crash at all, we can at least
harden against this scenario by
making `-_updateAccessory` robust against reentrancy. Achieve this by
adding a new ivar that's only
set during the scope of `-_updateAccessory`, and return early if it's
set.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView setUpInteraction]):
(-[WKContentView _updateAccessory]):
Canonical link: https://commits.webkit.org/279845@main
Canonical link:
https://commits.webkit.org/272448.1104@safari-7618.3.11.11-branch
Commit: c72413d8e8fa0fc53f0555d33a8f2d9629adc5cb
https://github.com/WebKit/WebKit/commit/c72413d8e8fa0fc53f0555d33a8f2d9629adc5cb
Author: Mohsin Qureshi <mohs...@apple.com>
Date: 2024-07-03 (Wed, 03 Jul 2024)
Changed paths:
A
LayoutTests/editing/pasteboard/dom-paste/dom-paste-in-child-frame-does-not-crash-expected.txt
A
LayoutTests/editing/pasteboard/dom-paste/dom-paste-in-child-frame-does-not-crash.html
M Source/WebCore/dom/DOMPasteAccess.h
M Source/WebKit/UIProcess/API/gtk/PageClientImpl.cpp
M Source/WebKit/UIProcess/API/gtk/PageClientImpl.h
M Source/WebKit/UIProcess/API/wpe/PageClientImpl.cpp
M Source/WebKit/UIProcess/API/wpe/PageClientImpl.h
M Source/WebKit/UIProcess/PageClient.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/ios/PageClientImplIOS.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/mac/PageClientImplMac.h
M Source/WebKit/UIProcess/mac/PageClientImplMac.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Source/WebKit/UIProcess/playstation/PageClientImpl.cpp
M Source/WebKit/UIProcess/playstation/PageClientImpl.h
M Source/WebKit/UIProcess/win/PageClientImpl.cpp
M Source/WebKit/UIProcess/win/PageClientImpl.h
Log Message:
-----------
Cherry-pick 5b8bfc5e1fae. rdar://130078654
Apply patch. rdar://130078654
Canonical link:
https://commits.webkit.org/272448.1105@safari-7618.3.11.11-branch
Commit: 612ec190384f1107c539014260b3127aa13b9dc8
https://github.com/WebKit/WebKit/commit/612ec190384f1107c539014260b3127aa13b9dc8
Author: Michael Saboff <msab...@apple.com>
Date: 2024-07-05 (Fri, 05 Jul 2024)
Changed paths:
A JSTests/stress/regexp-backreference-backtrack-interpreter.js
M Source/JavaScriptCore/yarr/YarrInterpreter.cpp
Log Message:
-----------
Cherry-pick 51993233d76f. rdar://115244009
Crash in JavaScriptCore: JSC::Yarr::Interpreter<unsigned
char>::matchDisjunction()
rdar://115244009
https://bugs.webkit.org/show_bug.cgi?id=276154
Reviewed by Yusuke Suzuki.
When processing back references, if the referenced capture was empty then
the back reference succeeds without comparing
the characters at the back reference atom with the captured characters.
This was handled with early exits in the
function matchBackReference(), before setting match info like the start
position, match size or match count. This
info is used when backtracking or when matching more in the case of a
non-greedy quantified back reference.
The fix is to move the setting the initial match information before we do
any checks for an empty match or a match comparing
characters. Also added code to properly handle duplicate named capture
groups in the function backtrackBackReference().
Added a new regression test.
* JSTests/stress/regexp-backreference-backtrack-interpreter.js: Added.
(arrayToString):
(objectToString):
(dumpValue):
(compareArray):
(compareGroups):
(testRegExp):
(testRegExpSyntaxError):
* Source/JavaScriptCore/yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::matchBackReference):
(JSC::Yarr::Interpreter::backtrackBackReference):
Canonical link: https://commits.webkit.org/272448.1104@safari-7618-branch
Canonical link:
https://commits.webkit.org/272448.1106@safari-7618.3.11.11-branch
Commit: ca223acdc4825442283a2c44e00a792eaacce455
https://github.com/WebKit/WebKit/commit/ca223acdc4825442283a2c44e00a792eaacce455
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2024-07-05 (Fri, 05 Jul 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7618.3.11.11.3
Canonical link:
https://commits.webkit.org/272448.1107@safari-7618.3.11.11-branch
Commit: ffd2ae22f5bc152b210657cd4d0f96cf58fed769
https://github.com/WebKit/WebKit/commit/ffd2ae22f5bc152b210657cd4d0f96cf58fed769
Author: Jean-Yves Avenard <j...@apple.com>
Date: 2024-07-05 (Fri, 05 Jul 2024)
Changed paths:
A LayoutTests/media/media-vp8-webm-seek-to-start-expected.html
A LayoutTests/media/media-vp8-webm-seek-to-start.html
A LayoutTests/platform/mac-site-isolation/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm
Log Message:
-----------
Cherry-pick d15bf6e99aee. rdar://128620836
Cherry-pick e5a7357eaea5. rdar://128620836
[WEBM] Seeking is broken
https://bugs.webkit.org/show_bug.cgi?id=276171
rdar://128620836
Reviewed by Jer Noble and Youenn Fablet.
Regression was introduced in 273109@main
We never flushed the AVSampleBufferDisplayLayer nor re-enqueued new
frames to be displayed
when seeking backward.
Added test
* LayoutTests/media/media-vp8-webm-seek-to-start-expected.html: Added.
* LayoutTests/media/media-vp8-webm-seek-to-start.html: Added.
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm:
(WebCore::MediaPlayerPrivateWebM::seekInternal):
Canonical link: https://commits.webkit.org/280648@main
Canonical link:
https://commits.webkit.org/272448.1106@safari-7618.3.11.14-branch
Canonical link:
https://commits.webkit.org/272448.1108@safari-7618.3.11.11-branch
Commit: 0e3b4cb2c69ddfee5c5dee2f79428dca35831c86
https://github.com/WebKit/WebKit/commit/0e3b4cb2c69ddfee5c5dee2f79428dca35831c86
Author: Mohsin Qureshi <mohs...@apple.com>
Date: 2024-07-05 (Fri, 05 Jul 2024)
Changed paths:
R LayoutTests/media/media-vp8-webm-seek-to-start-expected.html
R LayoutTests/media/media-vp8-webm-seek-to-start.html
R LayoutTests/platform/mac-site-isolation/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm
Log Message:
-----------
Revert d15bf6e99aee. rdar://128620836
Canonical link:
https://commits.webkit.org/272448.1109@safari-7618.3.11.11-branch
Commit: dd7c7fb719af3a3374f92fd6b828a17b018e4df2
https://github.com/WebKit/WebKit/commit/dd7c7fb719af3a3374f92fd6b828a17b018e4df2
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2024-07-09 (Tue, 09 Jul 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7618.3.11.11.4
Canonical link:
https://commits.webkit.org/272448.1110@safari-7618.3.11.11-branch
Commit: aca63e53700d7b9e3d8f1173c8bb1e2ba7e2c258
https://github.com/WebKit/WebKit/commit/aca63e53700d7b9e3d8f1173c8bb1e2ba7e2c258
Author: Dan Hecht <dan.he...@apple.com>
Date: 2024-07-09 (Tue, 09 Jul 2024)
Changed paths:
M Source/bmalloc/libpas/src/libpas/pas_bitfit_heap.c
M Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c
M Source/bmalloc/libpas/src/test/BmallocTests.cpp
Log Message:
-----------
Cherry-pick c6894f128e9b. rdar://131396046
[libpas]
pas_segregated_heap_ensure_size_directory_for_size/check_medium_directories
assert fail due to creating overlapping directories
https://bugs.webkit.org/show_bug.cgi?id=275820
rdar://129774839
Reviewed by Yusuke Suzuki.
There are some edge cases that can cause
pas_segregated_heap_ensure_size_directory_for_size()
to create a new directory that overlaps the next largest directory, i.e.
the new directory's object_size index is greater than the next largest's
min_index. One case in which this can occur is after entering mini mode,
which forces bitfit. A side effect of that is that the "ideal object size"
computation changes, which can lead to this overlap.
There are three possible solutions:
1. Extend the directory for the next largest size class (candidate) down
to the new install_index. However, after this solution can lead to
pathologically large directories if given the a particular sequence of
allocates. This is because then the candidate is extended based on the
min_index, which then could continue decreasing after each allocate.
Normally, size classes are extended based only on the candidate's
object_size, which doesn't change once the directory is created.
2. Trim the lower bound of the next biggest directory (candidate) if the
new directory would overlap the candidate min_index. This appears to be
unsafe if the candidate is bitfit given the comment in the code that does
similar trimming for result.
/* Bitfit size directories claim super high alignment, so they
should never get replaced. This is a
hard requirement, since:
- pas_bitfit_size_class is allocated as part of the
pas_segregated_size_directory.
- We cannot add duplicate bitfit_size_classes, so if we ever
tried to replace a
segregated_size_directory with another one of the same size,
and they both had bitfit_size_classes,
then we'd be in trouble. */
PAS_ASSERT(!pas_segregated_size_directory_is_bitfit(result));
3. Cap the new directory's object_size at the next largest directories
min_index. Bumping of the new directory's object_size to the ideal
object size appears to be an optimization and so it is safe to not do
this if it would create overlapping directories.
Some of the existing libpas chaos test cases do hit this case, but it
goes unnoticed because the overlapping directories are small, not medium.
The assert that made this problem apparent is only for medium directories
(to verify their index can be binary searched). While this doesn't cause
an assert with small directories, it seems that overlapping directories
should not be allowed for small directories either as it can lead to
inconsistencies. For example, if the index tables need to be
dematerialized we may index to a different set of directories then were
indexed previously.
So I've added a libpas test case that does trigger the medium director
assert without this fix.
* Source/bmalloc/libpas/src/libpas/pas_bitfit_heap.c:
(pas_bitfit_heap_select_variant):
* Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c:
(pas_segregated_heap_ensure_size_directory_for_size):
* Source/bmalloc/libpas/src/test/BmallocTests.cpp:
(std::testBmallocForceBitfitAfterAlloc):
(addBmallocTests):
Canonical link: https://commits.webkit.org/280317@main
Canonical link:
https://commits.webkit.org/272448.1111@safari-7618.3.11.11-branch
Commit: 93fe7e225330bc5e5a30bd7e6cd687654db0f6c1
https://github.com/WebKit/WebKit/commit/93fe7e225330bc5e5a30bd7e6cd687654db0f6c1
Author: Youenn Fablet <you...@apple.com>
Date: 2024-07-09 (Tue, 09 Jul 2024)
Changed paths:
M Source/WebCore/Modules/webaudio/AudioDestinationNode.cpp
M Source/WebCore/Modules/webaudio/AudioWorkletGlobalScope.cpp
M Source/WebCore/workers/WorkerThread.cpp
Log Message:
-----------
Cherry-pick f98cf4e20b37. rdar://131127484
heap-use-after-free |
WebCore::WorkerOrWorkletThread::destroyWorkerGlobalScope;
WebCore::WorkerOrWorkletThread::workerOrWorkletThread; WTF::Thread::entryPoint)
rdar://131127484
Reviewed by Ryosuke Niwa.
AudioWorkletGlobalScope is RefCounted so it is unsafe to ref/unref it from
various threads.
Before this patch, AudioDestinationNode::renderQuantum may either be called
from the audio worklet thread (expected) or the audio rendering thread at init
time (unexpected).
This is done to call AudioWorkletGlobalScope::handlePreRenderTasks, which
is a no-op if called in another thread than the worklet thread.
To fix the issue, if we are not in the context thread, we do not ref
AudioWorkletGlobalScope in AudioDestinationNode::renderQuantum.
AudioWorkletGlobalScope::handlePreRenderTasks will then no longer be called
in another thread than the worklet thread.
We update AudioWorkletGlobalScope::handlePreRenderTasks accordingly.
* Source/WebCore/Modules/webaudio/AudioDestinationNode.cpp:
(WebCore::AudioDestinationNode::renderQuantum):
* Source/WebCore/Modules/webaudio/AudioWorkletGlobalScope.cpp:
(WebCore::AudioWorkletGlobalScope::handlePreRenderTasks):
* Source/WebCore/workers/WorkerThread.cpp:
(WebCore::WorkerThread::globalScope):
Canonical link: https://commits.webkit.org/272448.1107@safari-7618-branch
Canonical link:
https://commits.webkit.org/272448.1112@safari-7618.3.11.11-branch
Commit: 7324c7e4e7a8f0fe7f9f4836afc4963ae769895b
https://github.com/WebKit/WebKit/commit/7324c7e4e7a8f0fe7f9f4836afc4963ae769895b
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2024-07-09 (Tue, 09 Jul 2024)
Changed paths:
M Source/bmalloc/libpas/src/libpas/pas_bitfit_heap.c
M Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c
M Source/bmalloc/libpas/src/test/BmallocTests.cpp
Log Message:
-----------
Revert "Cherry-pick c6894f128e9b. rdar://131396046"
This reverts commit aca63e53700d7b9e3d8f1173c8bb1e2ba7e2c258.
Canonical link:
https://commits.webkit.org/272448.1113@safari-7618.3.11.11-branch
Commit: c397fbba37b51e729d0fc81b5a08c08e6f4684d2
https://github.com/WebKit/WebKit/commit/c397fbba37b51e729d0fc81b5a08c08e6f4684d2
Author: Chris Dumez <cdu...@apple.com>
Date: 2024-07-09 (Tue, 09 Jul 2024)
Changed paths:
M Source/WebCore/platform/SharedBuffer.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/LoadAlternateHTMLString.mm
M Tools/TestWebKitAPI/cocoa/HTTPServer.h
M Tools/TestWebKitAPI/cocoa/HTTPServer.mm
Log Message:
-----------
Cherry-pick 0d4ba4017ef3. rdar://131369305
Integer truncation in FragmentedSharedBuffer::tryCreateArrayBuffer can lead
to a buffer overflow
https://bugs.webkit.org/show_bug.cgi?id=276381
rdar://131369305
Reviewed by Alex Christensen.
Make sure the size fits in an `unsigned` type before casting it.
Including an API test that Alex Christensen wrote.
* Source/WebCore/platform/SharedBuffer.cpp:
(WebCore::FragmentedSharedBuffer::tryCreateArrayBuffer const):
Canonical link: https://commits.webkit.org/272448.1109@safari-7618-branch
Canonical link:
https://commits.webkit.org/272448.1114@safari-7618.3.11.11-branch
Commit: f1cc8a36a2325c38a08dfe0abd5af9f50225cfd2
https://github.com/WebKit/WebKit/commit/f1cc8a36a2325c38a08dfe0abd5af9f50225cfd2
Author: Alex Christensen <achristen...@apple.com>
Date: 2024-07-09 (Tue, 09 Jul 2024)
Changed paths:
A LayoutTests/security/decode-buffer-size-expected.txt
A LayoutTests/security/decode-buffer-size.html
M Source/WebCore/PAL/pal/text/TextCodecLatin1.cpp
M Source/WebCore/PAL/pal/text/TextCodecUTF8.cpp
Log Message:
-----------
Cherry-pick dfa712ddc5a1. rdar://130946877
Integer truncation in TextCodecUTF8::decode leading to OOB writes
rdar://130946877
Reviewed by Darin Adler.
If the length plus the length of the previously attempted partial UTF-8
sequence
is greater than can fit into an unsigned, we will truncate the length and
write
the long length, which isn't ideal.
The Latin-1 codec appears to have a similar issue but it doesn't keep
state, so
I think it's unreachable. To make it more clear in code inspection that it
is
unreachable, I added a check to be extra safe.
* LayoutTests/security/decode-buffer-size-expected.txt: Added.
* LayoutTests/security/decode-buffer-size.html: Added.
* Source/WebCore/PAL/pal/text/TextCodecLatin1.cpp:
(PAL::TextCodecLatin1::decode):
* Source/WebCore/PAL/pal/text/TextCodecUTF8.cpp:
(PAL::TextCodecUTF8::decode):
Canonical link: https://commits.webkit.org/272448.1108@safari-7618-branch
Canonical link:
https://commits.webkit.org/272448.1115@safari-7618.3.11.11-branch
Commit: 918262e6872f93e9e8cf15aaf0aeb8a3d4ca3419
https://github.com/WebKit/WebKit/commit/918262e6872f93e9e8cf15aaf0aeb8a3d4ca3419
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2024-07-10 (Wed, 10 Jul 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7618.3.11.11.5
Canonical link:
https://commits.webkit.org/272448.1115@safari-7618.3.11.11-branch
Commit: e28a7c3599e11dd54862529c2852092dfedff12e
https://github.com/WebKit/WebKit/commit/e28a7c3599e11dd54862529c2852092dfedff12e
Author: Elika Etemad <fantasai.b...@inkedblade.net>
Date: 2024-07-10 (Wed, 10 Jul 2024)
Changed paths:
A LayoutTests/fast/overflow/flexbox-abspos-overflow-expected.html
A LayoutTests/fast/overflow/flexbox-abspos-overflow.html
A LayoutTests/fast/overflow/flexbox-multiline-overflow-expected.html
A LayoutTests/fast/overflow/flexbox-multiline-overflow.html
M
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/negative-overflow-002-expected.txt
M
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-flexbox/negative-overflow-002-expected.txt
M Source/WebCore/rendering/RenderFlexibleBox.cpp
Log Message:
-----------
Cherry-pick efacbbdcc425. rdar://131201271
Fix error in flexbox alignment overflow calculations.
https://bugs.webkit.org/show_bug.cgi?id=276382
rdar://131201271
Reviewed by Alan Baradlay.
This patch fixes the logic in contentAlignmentStartOverflow correctly
clamp overflow, by handling reversed flows properly rather than returning
an overly-large value in some cases. It also fixes the error where we only
account for the last flex line.
* LayoutTests/fast/overflow/flexbox-abspos-overflow-expected.html: Added.
* LayoutTests/fast/overflow/flexbox-abspos-overflow.html: Added.
* LayoutTests/fast/overflow/flexbox-multiline-overflow-expected.html: Added.
* LayoutTests/fast/overflow/flexbox-multiline-overflow.html: Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/negative-overflow-002-expected.txt:
Partial revert of 273737@main
*
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-flexbox/negative-overflow-002-expected.txt:
Partial revert of 273737@main
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::layoutBlock): Shift reset for
m_justifyContentStartOverflow out of the flex line loop.
(WebCore::contentAlignmentStartOverflow): Fix logic to correctly account
for reversing.
(WebCore::RenderFlexibleBox::layoutAndPlaceChildren): Update call to pass
reversing parameter.
(WebCore::RenderFlexibleBox::alignFlexLines): Update call to pass reversing
parameter, and fix multiline handling.
Canonical link: https://commits.webkit.org/280812@main
Canonical link:
https://commits.webkit.org/272448.1117@safari-7618.3.11.11-branch
Commit: 412a5f4cd06ed56b750a99ec4b5f8b032123a5db
https://github.com/WebKit/WebKit/commit/412a5f4cd06ed56b750a99ec4b5f8b032123a5db
Author: Scott Marcy <msc...@apple.com>
Date: 2024-07-10 (Wed, 10 Jul 2024)
Changed paths:
M
Source/ThirdParty/ANGLE/src/compiler/translator/tree_ops/msl/SeparateCompoundExpressions.cpp
Log Message:
-----------
Cherry-pick 5a66ef38bf19. rdar://128873925
Fix array OOB due to a bug in comma expression processing.
https://bugs.webkit.org/show_bug.cgi?id=xxxxx
rdar://128873925
Reviewed by Dan Glastonbury.
A pre-pass of the ANGLE compiler separates compound expressions into single
expressions with temporary values. (i.e. x=A+B+C can become tmp1 = b+C,
x=A+tmp1;). When creating a temporary variable, we previously would copy
the entire type. However, the type constructor also lead to copying
qualifiers, such as 'uniform' and 'interface block' markers: Qualifiers
that can belong to an original type, but shouldn't ever be applied to
temporary variables. (Fix and explanation by Kyle Piddington.)
*
Source/ThirdParty/ANGLE/src/compiler/translator/tree_ops/msl/SeparateCompoundExpressions.cpp:
(sh::Separator::pushBinding):
Canonical link: https://commits.webkit.org/272448.1110@safari-7618-branch
Canonical link:
https://commits.webkit.org/272448.1118@safari-7618.3.11.11-branch
Compare: https://github.com/WebKit/WebKit/compare/c5362127111b%5E...412a5f4cd06e
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
