Branch: refs/heads/webkitglib/2.40
Home: https://github.com/WebKit/WebKit
Commit: 016b79db98596c60ed96897742b3a81fa1ae81e4
https://github.com/WebKit/WebKit/commit/016b79db98596c60ed96897742b3a81fa1ae81e4
Author: Michael Catanzaro <mcatanz...@redhat.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/WebCore/platform/graphics/Font.h
M Source/WebCore/platform/graphics/FontCustomPlatformData.h
M
Source/WebCore/platform/graphics/freetype/FontCustomPlatformDataFreeType.cpp
Log Message:
-----------
Revert "[WPE][GTK] Do not deref CreationData's buffer when Cairo font is
destroyed" on 2.40 branch
This commit depends on 263084@main, which I don't want to backport to
this branch.
* Source/WebCore/platform/graphics/Font.h:
* Source/WebCore/platform/graphics/FontCustomPlatformData.h:
* Source/WebCore/platform/graphics/freetype/FontCustomPlatformDataFreeType.cpp:
(WebCore::releaseCustomFontData):
(WebCore::FontCustomPlatformData::FontCustomPlatformData):
Canonical link: https://commits.webkit.org/260527.340@webkitglib/2.40
Commit: ae40f7ee8db5e4f1a09b5b3e1b13f63caa502a92
https://github.com/WebKit/WebKit/commit/ae40f7ee8db5e4f1a09b5b3e1b13f63caa502a92
Author: Arunsundar Kannan <arunsundar_kan...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/cssom/css-stylesheet-replaceSync-null-deref-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/cssom/css-stylesheet-replaceSync-null-deref.html
M Source/WebCore/css/CSSStyleSheet.cpp
Log Message:
-----------
Cherry-pick 259548.524@safari-7615-branch (a48f8590fa3e).
https://bugs.webkit.org/show_bug.cgi?id=254727.
Null ptr deref in CSSStyleSheet::replaceSync.
https://bugs.webkit.org/show_bug.cgi?id=254727.
rdar://101629411.
Reviewed by Chris Dumez.
Added a null check in CSSStyleSheet::replaceSync to prevent a null deref.
*
LayoutTests/imported/w3c/web-platform-tests/css/cssom/css-stylesheet-replaceSync-null-deref-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/cssom/css-stylesheet-replaceSync-null-deref.html:
Added.
* Source/WebCore/css/CSSStyleSheet.cpp:
(WebCore::CSSStyleSheet::replaceSync):
Canonical link: https://commits.webkit.org/259548.524@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.341@webkitglib/2.40
Commit: ccf34efe975eae4a56b29d111989e52bf4644421
https://github.com/WebKit/WebKit/commit/ccf34efe975eae4a56b29d111989e52bf4644421
Author: JC Alvarado <jonca...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
A LayoutTests/fast/scrolling/scroll-snap-crash-expected.txt
A LayoutTests/fast/scrolling/scroll-snap-crash.html
M Source/WebCore/platform/ScrollSnapAnimatorState.cpp
Log Message:
-----------
Cherry-pick 259548.525@safari-7615-branch (3d4fc69bfad2).
https://bugs.webkit.org/show_bug.cgi?id=254383
Ignore snap offsets with an identifier of zero
https://bugs.webkit.org/show_bug.cgi?id=254383
rdar://107130316
Reviewed by Simon Fraser.
When updating snap offsets, if there is no element for a RenderBox,
then a snap offset with an identifier of 0 is created. This can lead
to issues when we add that offset identifier to a HashSet so we should
ignore them in ScrollSnapAnimatorState::currentlySnappedBoxes().
* LayoutTests/fast/animation/scroll-snap-crash-expected.txt: Added.
* LayoutTests/fast/animation/scroll-snap-crash.html: Added.
* Source/WebCore/platform/ScrollSnapAnimatorState.cpp:
(WebCore::ScrollSnapAnimatorState::currentlySnappedBoxes const):
Canonical link: https://commits.webkit.org/259548.525@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.342@webkitglib/2.40
Commit: 858ff599635f2cf5822f7768f5cccf96ad88fa93
https://github.com/WebKit/WebKit/commit/858ff599635f2cf5822f7768f5cccf96ad88fa93
Author: Antoine Quint <grao...@webkit.org>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/WebCore/animation/WebAnimation.cpp
Log Message:
-----------
Cherry-pick 259548.532@safari-7615-branch (1d6fe184ea53).
https://bugs.webkit.org/show_bug.cgi?id=254840
Potential use-after-free in WebAnimation::commitStyles
https://bugs.webkit.org/show_bug.cgi?id=254840
rdar://107444873
Reviewed by Dean Jackson and Darin Adler.
Ensure that the animation's effect and target are kept alive for the
duration of this method
since it is possible that calling updateStyleIfNeeded() could call into
JavaScript and thus
these two pointers could be changed to a null value using the Web
Animations API.
* Source/WebCore/animation/WebAnimation.cpp:
(WebCore::WebAnimation::commitStyles):
Canonical link: https://commits.webkit.org/259548.532@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.343@webkitglib/2.40
Commit: f4239204176891c5ed5128b27e43c1ee53c36429
https://github.com/WebKit/WebKit/commit/f4239204176891c5ed5128b27e43c1ee53c36429
Author: Alexey Shvayka <ashva...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
A LayoutTests/fast/forms/input-type-radio-form-gc-crash-expected.txt
A LayoutTests/fast/forms/input-type-radio-form-gc-crash.html
M Source/WebCore/html/FormAssociatedCustomElement.cpp
M Source/WebCore/html/FormAssociatedCustomElement.h
M Source/WebCore/html/ValidatedFormListedElement.cpp
M Source/WebCore/html/ValidatedFormListedElement.h
Log Message:
-----------
Cherry-pick 259548.534@safari-7615-branch (f5dc82736e2c).
https://bugs.webkit.org/show_bug.cgi?id=253860
<input type=radio> crashes in
removeInvalidElementToAncestorFromInsertionPoint() during GC
https://bugs.webkit.org/show_bug.cgi?id=253860
<rdar://105086386>
Reviewed by Ryosuke Niwa.
When a <form> gets destroyed, it calls into formWillBeDestroyed() callback
of <input type=radio>
which, when removing radio buttons themselves, calls into updateValidity()
and then into
removeInvalidElementToAncestorFromInsertionPoint() with partially-deleted
ContainerNode as an
argument, causing a crash.
This change guards removeInvalidElementToAncestorFromInsertionPoint() and
its counterpart
from being called during form destruction.
* LayoutTests/fast/forms/input-type-radio-form-gc-crash-expected.txt: Added.
* LayoutTests/fast/forms/input-type-radio-form-gc-crash.html: Added.
* Source/WebCore/html/FormAssociatedCustomElement.cpp:
(WebCore::FormAssociatedCustomElement::didChangeForm):
(WebCore::FormAssociatedCustomElement::formWillBeDestroyed): Deleted.
* Source/WebCore/html/FormAssociatedCustomElement.h:
* Source/WebCore/html/ValidatedFormListedElement.cpp:
(WebCore::ValidatedFormListedElement::updateValidity):
(WebCore::ValidatedFormListedElement::formWillBeDestroyed):
* Source/WebCore/html/ValidatedFormListedElement.h:
(WebCore::ValidatedFormListedElement::belongsToFormThatIsBeingDestroyed
const):
Canonical link: https://commits.webkit.org/259548.534@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.344@webkitglib/2.40
Commit: 296cc117281afd395de14e4b40555af34a70e5a7
https://github.com/WebKit/WebKit/commit/296cc117281afd395de14e4b40555af34a70e5a7
Author: JC Alvarado <jonca...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
A LayoutTests/fast/editing/insert-text-hit-testing-crash-expected.txt
A LayoutTests/fast/editing/insert-text-hit-testing-crash.html
M Source/WebCore/dom/Document.cpp
M Source/WebCore/rendering/HitTestRequest.h
Log Message:
-----------
Cherry-pick 259548.535@safari-7615-branch (3bc53a0a2ccf).
https://bugs.webkit.org/show_bug.cgi?id=253615
Update layout of child frames before hit testing a document if necessary
https://bugs.webkit.org/show_bug.cgi?id=253615
rdar://107375598
Reviewed by Alan Baradlay.
If hit testing can recurse into a child frame, we should make sure that
layout and style are updated for all children before proceeding with
hit testing.
* LayoutTests/fast/editing/insert-text-hit-testing-crash-expected.txt:
Added.
* LayoutTests/fast/editing/insert-text-hit-testing-crash.html: Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::hitTest):
Canonical link: https://commits.webkit.org/259548.535@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.345@webkitglib/2.40
Commit: 114314c6b2e963887cb29ddeabd65bad9936794e
https://github.com/WebKit/WebKit/commit/114314c6b2e963887cb29ddeabd65bad9936794e
Author: Arunsundar Kannan <arunsundar_kan...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
A
LayoutTests/http/tests/media/fairplay/fps-init-data-sinf-oob-crash-expected.txt
A LayoutTests/http/tests/media/fairplay/fps-init-data-sinf-oob-crash.html
M Source/WebCore/platform/graphics/iso/ISOTrackEncryptionBox.cpp
Log Message:
-----------
Cherry-pick 259548.536@safari-7615-branch (8320a5247c74).
https://bugs.webkit.org/show_bug.cgi?id=254781.
CDMPrivateFairPlayStreaming parsing of WebCore::ISOTrackEncryptionBox can
lead to a heap-buffer-overflow.
https://bugs.webkit.org/show_bug.cgi?id=254781.
rdar://103849722.
Reviewed by Jer Noble.
WebCore::ISOTrackEncryptionBox::parse() is missing basic bounds checking
before memcpy. This change add the check.
*
LayoutTests/http/tests/media/fairplay/fps-init-data-sinf-oob-crash-expected.txt:
Added.
* LayoutTests/http/tests/media/fairplay/fps-init-data-sinf-oob-crash.html:
Added.
* Source/WebCore/platform/graphics/iso/ISOTrackEncryptionBox.cpp:
(WebCore::ISOTrackEncryptionBox::parse):
Canonical link: https://commits.webkit.org/259548.536@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.346@webkitglib/2.40
Commit: f7db434186298910f194e3e296e1a671da7ca722
https://github.com/WebKit/WebKit/commit/f7db434186298910f194e3e296e1a671da7ca722
Author: Michael Saboff <msab...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
A JSTests/stress/string-replace-regexp-matchBOL-correct-advancing.js
M Source/JavaScriptCore/runtime/StringPrototype.cpp
M Source/JavaScriptCore/yarr/YarrInterpreter.cpp
Log Message:
-----------
Cherry-pick 259548.551@safari-7615-branch (e34edaa74575).
https://bugs.webkit.org/show_bug.cgi?id=254930
[JSC] RegExpGlobalData::performMatch issue leading to OOB read
https://bugs.webkit.org/show_bug.cgi?id=254930
rdar://107436732
Reviewed by Alexey Shvayka.
Fixed two issues:
1) In YarrInterpreter.cpp::matchAssertionBOL() we were advancing the string
position for non-BMP
characters. Since it is an assertion, we shouldn't advance the
character position.
Made the same fix to matchAssertionEOL().
2) In StringPrototype.cpp::replaceUsingRegExpSearch(), we need to advance
past both elements of
a non-BMP character for the case where the RegExp match is empty.
* JSTests/stress/string-replace-regexp-matchBOL-correct-advancing.js: New
test.
* Source/JavaScriptCore/runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
* Source/JavaScriptCore/yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::InputStream::readCheckedDontAdvance):
(JSC::Yarr::Interpreter::matchAssertionBOL):
(JSC::Yarr::Interpreter::matchAssertionEOL):
Canonical link: https://commits.webkit.org/259548.551@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.347@webkitglib/2.40
Commit: b44c0d582e1cf9fe70e59d8a97b10269db356ffa
https://github.com/WebKit/WebKit/commit/b44c0d582e1cf9fe70e59d8a97b10269db356ffa
Author: Chirag M Shah <chirag_m_s...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
A LayoutTests/fast/rendering/glyph-display-list-cache-crash-expected.txt
A LayoutTests/fast/rendering/glyph-display-list-cache-crash.html
M Source/WebCore/rendering/GlyphDisplayListCache.h
Log Message:
-----------
Cherry-pick 259548.555@safari-7615-branch (707d4fb8838c).
https://bugs.webkit.org/show_bug.cgi?id=254941
Fix equals() for GlyphDisplayListCacheEntryHash
https://bugs.webkit.org/show_bug.cgi?id=254941
rdar://107416408
Reviewed by Cameron McCormack.
This change fixes a heap use after free in GlyphDisplayListCache, which
happens when the destructor of GlyphDisplayListCacheEntry tries to
remove this from the HashSet<GlyphDisplayListCacheEntry*>. The change
fixes the security issue by correcting the equal() implementation, which
now only checks for pointer equality.
* LayoutTests/fast/rendering/glyph-display-list-cache-crash-expected.txt:
Added.
* LayoutTests/fast/rendering/glyph-display-list-cache-crash.html: Added.
* Source/WebCore/rendering/GlyphDisplayListCache.h:
(WebCore::GlyphDisplayListCacheEntryHash::equal):
Canonical link: https://commits.webkit.org/259548.555@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.348@webkitglib/2.40
Commit: 97f5a4a8486105695bfaf33aed9343d809530134
https://github.com/WebKit/WebKit/commit/97f5a4a8486105695bfaf33aed9343d809530134
Author: Matt Woodrow <mattwood...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/WebKit/GPUProcess/graphics/RemoteImageBuffer.h
M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp
Log Message:
-----------
Cherry-pick 259548.560@safari-7615-branch (96ee5835ab95).
https://bugs.webkit.org/show_bug.cgi?id=254367
RemoteRenderingBackend::moveToImageBuffer can be called multiple times
simultaneously.
https://bugs.webkit.org/show_bug.cgi?id=254367
<rdar://106972794>
Reviewed by Kimmo Kinnunen.
It adds locking to RemoteSerializedImageBuffer, so that only one thread can
take ownership of the image buffer backend.
* Source/WebKit/GPUProcess/graphics/RemoteImageBuffer.h:
* Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::RemoteRenderingBackend::moveToImageBuffer):
Canonical link: https://commits.webkit.org/259548.560@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.349@webkitglib/2.40
Commit: c53479b2802f785f424cc2191705b10cf55a29d5
https://github.com/WebKit/WebKit/commit/c53479b2802f785f424cc2191705b10cf55a29d5
Author: Arunsundar Kannan <arunsundar_kan...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M
Source/WebCore/platform/graphics/iso/ISOProtectionSystemSpecificHeaderBox.cpp
Log Message:
-----------
Cherry-pick 259548.574@safari-7615-branch (0c76eb21f2d8).
https://bugs.webkit.org/show_bug.cgi?id=254931.
Potential OOB Read in ISOProtectionSystemSpecificHeaderBox::parse(...).
https://bugs.webkit.org/show_bug.cgi?id=254931.
rdar://107441432.
Reviewed by Jer Noble.
There is a potential OOB access in
ISOProtectionSystemSpecificHeaderBox::parse when we do memcpy without a bounds
check. This adds a bounds check to prevent such access.
*
Source/WebCore/platform/graphics/iso/ISOProtectionSystemSpecificHeaderBox.cpp:
(WebCore::ISOProtectionSystemSpecificHeaderBox::parse):
Canonical link: https://commits.webkit.org/259548.574@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.350@webkitglib/2.40
Commit: 63375db425fe181471dcae5e2f2e3b6434aa1e43
https://github.com/WebKit/WebKit/commit/63375db425fe181471dcae5e2f2e3b6434aa1e43
Author: Sihui Liu <sihui_...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp
M Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.h
Log Message:
-----------
Cherry-pick 259548.577@safari-7615-branch (3679790c14ce). rdar://106965632
v2: CrashTracer: com.apple.WebKit.Networking at JavaScriptCore:
WTF::StringImpl::hashSlowCase const
rdar://106965632
Reviewed by Youenn Fablet and Ryosuke Niwa.
Moving a lambda might involve copying its captured variables. According to
crash trace, recordInfos
(Vector<CacheStorageRecordInformation>) captured by didReadRecordFiles is
copied when running on the WorkQueue of
CacheStorageDiskStore (com.apple.WebKit.CacheStorageCache). This is an
issue as CacheStorageRecordInformation is not
thread-safe. To avoid this, we now replace the lambda with
CompletionHandler, which has a more definitive move behavior
that does not involves copy.
* Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp:
(WebKit::CacheStorageDiskStore::readAllRecordInfosInternal):
(WebKit::CacheStorageDiskStore::readAllRecordInfos):
(WebKit::CacheStorageDiskStore::readRecordsInternal):
(WebKit::CacheStorageDiskStore::readRecords):
* Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.h:
Canonical link: https://commits.webkit.org/259548.577@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.351@webkitglib/2.40
Commit: 0f0d5a8b4e66e830eafd6a11dcf23b61fea1a0ad
https://github.com/WebKit/WebKit/commit/0f0d5a8b4e66e830eafd6a11dcf23b61fea1a0ad
Author: Mark Lam <mark....@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
Log Message:
-----------
Cherry-pick 259548.581@safari-7615-branch (1698533dc391).
https://bugs.webkit.org/show_bug.cgi?id=255030
CodeBlock::baselineAlternative() lookup only needs an if statement.
https://bugs.webkit.org/show_bug.cgi?id=255030
<rdar://problem/107657983>
Reviewed by Justin Michaud and Yusuke Suzuki.
There is only ever 1 possible alternative i.e. the baseline CodeBlock.
Since there is
none beyond that, there is no need to loop here.
* Source/JavaScriptCore/bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setAlternative):
(JSC::CodeBlock::baselineAlternative):
Canonical link: https://commits.webkit.org/259548.581@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.352@webkitglib/2.40
Commit: 59a4096eafd16a1f4ee69a3c92813e732aa1e215
https://github.com/WebKit/WebKit/commit/59a4096eafd16a1f4ee69a3c92813e732aa1e215
Author: Mark Lam <mark....@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h
Log Message:
-----------
Cherry-pick 259548.592@safari-7615-branch (61fa810ab89d).
https://bugs.webkit.org/show_bug.cgi?id=255136
untagArrayPtr() should do validation if FPAC is not available, not the
other way around.
https://bugs.webkit.org/show_bug.cgi?id=255136
rdar://107739543
Reviewed by Yusuke Suzuki and Justin Michaud.
The current code erroneously tests for the inverted condition.
* Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::untagArrayPtr):
(JSC::MacroAssemblerARM64E::untagArrayPtrLength64):
Canonical link: https://commits.webkit.org/259548.592@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.353@webkitglib/2.40
Commit: de361a84ce99e996435dfc921c39fce63c76b548
https://github.com/WebKit/WebKit/commit/de361a84ce99e996435dfc921c39fce63c76b548
Author: Justin Michaud <justin_mich...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
A JSTests/wasm/stress/block_end_aliasing.js
A JSTests/wasm/stress/block_end_aliasing.wasm
A JSTests/wasm/stress/block_end_aliasing_2.js
A JSTests/wasm/stress/block_end_aliasing_2.wasm
A JSTests/wasm/stress/block_end_aliasing_2.wat
A JSTests/wasm/stress/if-block-arguments-2.js
A JSTests/wasm/stress/if-block-arguments.js
M Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp
Log Message:
-----------
Cherry-pick 259548.624@safari-7615-branch (c9d960b1956a). rdar://106354199
OMG should pop try arguments
rdar://106354199
Reviewed by Yusuke Suzuki.
The parser and the B3 generator both maintain their own separate wasm
stacks.
When we end a block, these two stacks can get out of sync because we forgot
to pop on the b3 side. This can cause type confusion.
The real fix for this is to fix the underlying design flaw.
In the future, we should only store one copy of the stack state in the
parser,
including the wasm type, and refer exclusively to that. This is what the
new BBQ tier does.
For now, we just pop as needed.
* JSTests/wasm/stress/block_end_aliasing.js: Added.
(instantiate):
(async let):
* JSTests/wasm/stress/block_end_aliasing.wasm: Added.
* JSTests/wasm/stress/block_end_aliasing_2.js: Added.
(instantiate):
(async let):
(async let.i4.await.instantiate):
* JSTests/wasm/stress/block_end_aliasing_2.wasm: Added.
* JSTests/wasm/stress/block_end_aliasing_2.wat: Added.
* JSTests/wasm/stress/loop-end-aliasing.js: Added.
(from.string_appeared_here.import.as.assert.from.string_appeared_here.let.wat.module.import.string_appeared_here.string_appeared_here.memory.mem.1.func.export.string_appeared_here.result.i64.funcref.i64.const.14.block.param.i64.end.ref.func.0.return.async
test):
* Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::didPopValueFromStack):
(JSC::Wasm::B3IRGenerator::makePushVariable):
(JSC::Wasm::B3IRGenerator::addEndToUnreachable):
Canonical link: https://commits.webkit.org/259548.624@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.354@webkitglib/2.40
Commit: c3d8a36a63918c3e63ec015dff3bd579a4a209e6
https://github.com/WebKit/WebKit/commit/c3d8a36a63918c3e63ec015dff3bd579a4a209e6
Author: Chirag M Shah <chirag_m_s...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
A
LayoutTests/fast/rendering/render-text-control-crash-with-designmode-off-expected.txt
A
LayoutTests/fast/rendering/render-text-control-crash-with-designmode-off.html
M Source/WebCore/rendering/RenderTextControl.cpp
M Source/WebCore/rendering/RenderTextControlSingleLine.cpp
Log Message:
-----------
Cherry-pick 259548.635@safari-7615-branch (064579d997ae).
https://bugs.webkit.org/show_bug.cgi?id=255423
Fix crash when innerTextElement() can be null when designMode="off"
https://bugs.webkit.org/show_bug.cgi?id=255423
rdar://107985448
Reviewed by Antti Koivisto.
This change guards against innerTextElement() being null. The file
already checked for this in some places, but it wasn't consistent.
*
LayoutTests/fast/rendering/render-text-control-crash-with-designmode-off-expected.txt:
Added.
*
LayoutTests/fast/rendering/render-text-control-crash-with-designmode-off.html:
Added.
* Source/WebCore/rendering/RenderTextControl.cpp:
(WebCore::RenderTextControl::textBlockLogicalWidth const):
(WebCore::RenderTextControl::computeLogicalHeight const):
(WebCore::RenderTextControl::computeIntrinsicLogicalWidths const):
* Source/WebCore/rendering/RenderTextControlSingleLine.cpp:
(WebCore::RenderTextControlSingleLine::layout):
(WebCore::RenderTextControlSingleLine::preferredContentLogicalWidth const):
Canonical link: https://commits.webkit.org/259548.635@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.355@webkitglib/2.40
Commit: 1c21333f8f8871a61262d42dc1cc2a778f868af9
https://github.com/WebKit/WebKit/commit/1c21333f8f8871a61262d42dc1cc2a778f868af9
Author: Mark Lam <mark....@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/JavaScriptCore/assembler/MacroAssemblerARM64.h
M Source/JavaScriptCore/assembler/testmasm.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/WTF/wtf/PtrTag.h
Log Message:
-----------
Cherry-pick 259548.636@safari-7615-branch (a45dfa3dc3d4).
https://bugs.webkit.org/show_bug.cgi?id=255475
Ensure that tagArrayPtr's size diversifier's top 16 bits are always 0.
https://bugs.webkit.org/show_bug.cgi?id=255475
rdar://107724053
Reviewed by Justin Michaud.
On ARM64, sizes never exceed 48 bits anyway. This also ensures that the
signed values
will not conflict with the namespace of other data pointers signed with the
same PAC key.
* Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::zeroExtend48ToWord):
* Source/JavaScriptCore/assembler/testmasm.cpp:
(JSC::testZeroExtend48ToWord):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::emitNewTypedArrayWithSize):
* Source/WTF/wtf/PtrTag.h:
(WTF::tagArrayPtr):
(WTF::retagArrayPtr):
Canonical link: https://commits.webkit.org/259548.636@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.356@webkitglib/2.40
Commit: ffa1fe87b2791fd07557e3526c61e21337158550
https://github.com/WebKit/WebKit/commit/ffa1fe87b2791fd07557e3526c61e21337158550
Author: Alex Christensen <achristen...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
Log Message:
-----------
Cherry-pick 259548.637@safari-7615-branch (2aa0035b7a09). <bug>
Cherry-pick 71578313d03d. rdar://106952778
Network process should only consider web archives to have been loaded
if loaded using local scheme
https://bugs.webkit.org/show_bug.cgi?id=255459
rdar://106952778
Reviewed by John Pascoe.
Adding the scheme check matches the check in
DocumentLoader::disallowWebArchive
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::didReceiveMainResourceResponse):
Canonical link: https://commits.webkit.org/259548.637@safari-7615-branch
Canonical link: https://commits.webkit.org/260527.357@webkitglib/2.40
Compare: https://github.com/WebKit/WebKit/compare/b3a18564f431...ffa1fe87b279
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
