https://bugs.webkit.org/show_bug.cgi?id=228865
Patch by Michael Catanzaro <mcatanzaro@gnome.org> on 2021-08-09
Reviewed by Yusuke Suzuki.
When investigating why WebKitGTK fails to build with LTO (link-time optimization) enabled,
one of the GCC developers noticed that we are missing __attribute__ (("used")) on several
C++ functions declared in LLIntSlowPaths.h and WasmSlowPaths.h that are called only from
asm. Without this attribute, GCC assumes the functions are unused and drops them, then
linking fails because they really are used.
* llint/LLIntSlowPaths.h:
* wasm/WasmSlowPaths.h:
Canonical link: https://commits.webkit.org/240354@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280770 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=227740
Reviewed by Žan Doberšek.
In order to share AHardwareBuffer handles via IPC we need to use the AHardwareBuffer_sendHandleToUnixSocket()
and AHardwareBuffer_recvHandleFromUnixSocket() functions. This is not currently compatible with the Attachment
API used in UnixConnection, as those functions use custom messaging into the socked fd.
This patch adds a CustomWriterType Attachment that allows custom messaging going into the socket fd.
* Platform/IPC/unix/ConnectionUnix.cpp:
Canonical link: https://commits.webkit.org/240353@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280769 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228859
rdar://81674787
Reviewed by Tim Horton.
Source/WebKit:
Addresses a couple of issues that cause the `caret-color` CSS property to not be applied when focusing editable
content on iOS. See below for more details.
Test: editing/caret/ios/caret-color-after-refocusing-input.html
* Platform/spi/ios/UIKitSPI.h:
* UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h:
* UIProcess/API/ios/WKWebViewTestingIOS.mm:
(-[WKWebView _serializedSelectionCaretBackgroundColorForTesting]):
Add support for a new test-only helper method. See Tools/ChangeLog for more information.
* UIProcess/ios/WKContentViewInteraction.h:
* UIProcess/ios/WKContentViewInteraction.mm:
(WebKit::WKSelectionDrawingInfo::WKSelectionDrawingInfo):
(WebKit::operator==):
(WebKit::operator<<):
Make a minor adjustment to ensure that changes to `caretColor` in `EditorState` are propagated to UIKit's
selection views. To achieve this, we add `caretColor` to `WKSelectionDrawingInfo`, and force the text selection
view to update the caret background color when the caret color changes (alongside other selection UI geometry
changes, which are applied underneath the call to `-selectionChanged`).
(-[WKContentView _updateChangedSelection:]):
(-[WKContentView textInteractionAssistant]):
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::getPlatformEditorState const):
Address an existing FIXME which (mostly) fixes this bug. Currently, the caret color is only computed when
`WebPage::m_focusedElement` is set. However, when resigning first responder, we clear out `WebPage`'s
`m_focusedElement`) right before updating the DOM selection, which creates a brief window during which we
compute an `EditorState` with a `caretColor` of transparent black.
To avoid this inconsistency, we instead compute the caret color from the selection container; this has the
additional benefit of allowing the caret color to change when changing selection within a single editable host
with multiple caret colors (instead of always just using the focused element's caret color).
Note that while this adjustment to `WebPage::getPlatformEditorState` is sufficient to ensure that the value of
`-[WKContentView insertionPointColor]` (which is based on `EditorState`) is always up-to-date, this doesn't
guarantee that the actual color of UIKit's caret view reflects the updated `-insertionPointColor`, which results
in situations where the caret color appears out-of-date after hiding the keyboard and refocusing an input field.
To fix this, we need the other adjustment in WKContentView (see above).
Tools:
Make it possible to test this bug by adding a UIScriptController hook to request the background color of the
current selection view's caret view, as serialized CSS text. See LayoutTests/ChangeLog for more details.
* TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::selectionCaretBackgroundColor const):
* WebKitTestRunner/ios/UIScriptControllerIOS.h:
* WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::selectionCaretBackgroundColor const):
LayoutTests:
Add a new layout test that exercises the issue, as reported in Bugzilla (the call to `-resignFirstResponder`
simulates backgrounding Safari). To achieve this, we also introduce a script controller testing helper to grab
the native background color of the `UITextSelectionView`'s caret view; see Tools/ChangeLog for more details.
* editing/caret/ios/caret-color-after-refocusing-input-expected.txt: Added.
* editing/caret/ios/caret-color-after-refocusing-input.html: Added.
* resources/ui-helper.js:
(window.UIHelper.selectionCaretBackgroundColor):
Canonical link: https://commits.webkit.org/240352@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280767 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=227366
<rdar://problem/79733280>
Reviewed by Eric Carlson.
Source/WebCore:
Querying for any state on an AVAsset before its fully loaded will cause AVFoundation to block
on networking to fulfill the request, and in the case where WebKit handles loading, will eventually
dispatch to the main thread (which is blocked) in WebCore loader code, causing a deadlock.
Always guard queries to AVAsset with checks for the loaded status of the property being queried.
To make this easier, add a new safeAVAssetTracksForVisualMedia() method, similar to the existing
safeAVAssetTracksForAudibleMedia(), which checks the "tracks" property status and returns an empty
array if the tracks are not yet loaded.
Guard a few more methods by bailing early if the AVAsset is not fully loaded.
* platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h:
* platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::tracksChanged):
(WebCore::MediaPlayerPrivateAVFoundationObjC::updateRotationSession):
(WebCore::MediaPlayerPrivateAVFoundationObjC::paintWithVideoOutput):
(WebCore::MediaPlayerPrivateAVFoundationObjC::safeAVAssetTracksForVisualMedia):
LayoutTests:
* platform/mac-wk1/TestExpectations:
Canonical link: https://commits.webkit.org/240351@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280766 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228841
rdar://79960890
Reviewed by Ryosuke Niwa.
Source/WebCore:
In the case where the document is in the process of being detached (underneath `willBeRemovedFromFrame()`), if
there is currently uncommitted marked text in the document, we will attempt to cancel the IME composition in the
process of clearing out the selection. On macOS, this calls into `Editor::cancelComposition()` which
subsequently triggers layout under various call stacks (DOM mutations, text event dispatch, and when scrolling
to reveal the selection); this triggers a security release assertion inside `Document::updateLayout()`.
To mitigate this, we avoid calling into this codepath if the Document no longer has a living render tree (i.e.,
the render tree has either been destroyed, is being destroyed, or has not been created yet).
Test: editing/inserting/remove-frame-with-marked-text.html
* editing/mac/EditorMac.mm:
(WebCore::Editor::selectionWillChange):
Source/WebKit:
Deploy a similar fix on iOS, to avoid any attempts to compute editor state due to discarding uncommitted marked
text during Document teardown. This is required in order to avoid the same security assertion when running the
new layout test on iOS.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::sendEditorStateUpdate):
Tools:
Make a small adjustment to DumpRenderTree, such that TextInputController targets the selected frame (or the main
frame, if there is no DOM selection). This behavior matches that of WebKitTestRunner, and allows layout tests
that use TextInputController to simulate setting marked text inside subframes.
* DumpRenderTree/mac/TextInputControllerMac.m:
(-[TextInputController selectedOrMainFrame]):
(-[TextInputController textInput]):
LayoutTests:
Add a layout test to exercise the crash.
* editing/inserting/remove-frame-with-marked-text-expected.txt: Added.
* editing/inserting/remove-frame-with-marked-text.html: Added.
Canonical link: https://commits.webkit.org/240347@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280762 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228876
Patch by Michael Catanzaro <mcatanzaro@gnome.org> on 2021-08-07
Reviewed by Yusuke Suzuki.
When built with LTO enabled, GCC will warn about violations of C++'s one-definition rule.
JSC currently has two violations. The first is JSC::SpeciesConstructResult, which has two
different declarations, one in ArrayPrototype.cpp and the other in
JSArrayBufferPrototype.cpp. I decided to change the version in ArrayPrototype.cpp to make
the declarations match.
The next problem is JSC::SignalContext. We have two different versions of this struct, one
in VMTraps.cpp and the other in SigillCrashAnalyzer.cpp. In this case, I decided to change
the one in VMTraps.cpp from JSC::SignalContext to JSC::VMTraps::SignalContext.
* runtime/ArrayPrototype.cpp:
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
* runtime/VMTraps.h:
Canonical link: https://commits.webkit.org/240346@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280761 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=227989
Reviewed by Yusuke Suzuki.
JSTests:
* microbenchmarks/for-in-double-array-with-own-named.js: Added.
(test):
* microbenchmarks/for-in-double-array.js: Added.
(test):
* microbenchmarks/for-in-getters.js: Added.
(test):
* microbenchmarks/for-in-int32-array-with-own-named.js: Added.
(test):
* microbenchmarks/for-in-int32-array.js: Added.
(test):
* microbenchmarks/for-in-int32-object-with-own-named-and-getters.js: Added.
(test):
* microbenchmarks/for-in-int32-object-with-own-named.js: Added.
(test):
* microbenchmarks/for-in-object-with-own-named.js: Added.
(sum):
(opaqueSet):
* microbenchmarks/for-in-string-array.js: Added.
(test):
* microbenchmarks/for-of-iterate-array-map-set.js: Added.
(sum):
(let.generator):
* stress/for-in-array-mode.js:
(test):
* stress/for-in-base-reassigned-later.js:
* stress/for-in-delete-during-iteration.js:
* stress/for-in-primitive-index-on-prototype.js: Added.
(test):
* stress/for-in-tests.js:
* stress/has-own-property-structure-for-in-loop-correctness.js:
(test5):
Source/JavaScriptCore:
This patch redesigns how we implement for-in loops. Before this patch we would emit three copies of the for-in loop body. One for the indexed properties, one for the named-own properties, and one for generic properties (anything else). This had a couple of problems. Firstly, it meant bytecode size grew exponentially to number of nested for-in loops. This in turn meant DFG/FTL compilation took much longer.
Going off our experience with fast for-of, this patch turns for-in loops specializations into
a "fused" opcode that internally switches on the enumeration mode it currently sees. For example, if we are enumerating an own-named property, the new enumerator_get_by_val bytecode will check the enumerator cell's cached structure matches the base's then load the property offset directly.
There are four new opcodes this patch adds, which replace the various operations we had for the specialized loops previously. The new opcodes are EnumeratorGetByVal, EnumeratorInByVal, EnumeratorHasOwnProperty, and EnumeratorNext. The first three correspond to GetByVal, InByVal, and HasOwnProperty respectively. The EnumeratorNext opcode has three results in bytecode, the next enumeration value's mode, the index of the property name, and the property name string itself. When enumeration is done EnumeratorNext returns JS null as the property name string. Since the DFG doesn't support tuples yet this opcode is spilt into four new nodes. The first computes the updated index and mode for the next enumeration key, which is encoded into a single JS number. Then there are two nodes that extract the mode and index. Finally, the last new node produces the property name string or null based on the extracted mode and index.
Since, in most benchmarks, any given enumeration opcode tends to profile exactly one enumeration mode. This patch focuses primarily on reimplementing all the optimizations we have for any one specific mode. This means there are still potential optimizations for the multi-mode flavors of each new opcode.
The main optimizations implemented for each new opcode are:
EnumeratorNext:
1) IndexedMode loops are loaded and checked for presence inline (DFG/FTL).
2) NamedMode is computed inline as long as the cached structure on the enumerator cell matches the base (Baseline+). This can only differ if there's a transition.
3) property names are extracted from the cached buffer inline (Baseline+).
EnumeratorGetByVal:
EnumeratorInByVal:
EnumeratorHasOwnProperty:
1) IndexedMode has all the optimizations of a normal XByVal on indexed properties (DFG/FTL).
2) NamedMode will extract the value directly from the inline/out-of-line offset if the structure matches the enumerator's (Baseline+).
There are also a few interesting changes worth mentioning here:
1) If a for-in loop would produce an empty enumerator we now always
return the VMs empty enumerator. This has two benefits, most importantly, it distingishes between an unprofiled for-in loop and empty enumeration, which prevents OSR exit loops. Also, it means that the various Enumerator opcodes no longer need to handle undefined/null when `toObject`ing the base value.
2) The enumerator now contains a bit set of all the modes it will produce. This removes a few extra branches when speculating on the modes we will see in EnumeratorNext.
3) In the DFG, enumerator GetByVal relies on compileGetByVal to set the result it also passes a prefix callback which emits code after the various cases set up their operands but before code is emitting to help satisfy the branch over register allocation validation. Also, the array mode branch in compileGetByVal passes the data format that it would prefer, which for normal GetByVal is returned. For EnumeratorGetByVal, that preference is completely ignored and it always returns DataFormatJS.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::or8):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::or8):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::rshift64):
(JSC::MacroAssemblerX86_64::or8): Deleted.
* builtins/BuiltinNames.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/LinkTimeConstant.h:
* bytecode/Opcode.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::recordHasOwnPropertyInForInLoop):
(JSC::BytecodeGenerator::emitInByVal):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitEnumeratorNext):
(JSC::BytecodeGenerator::emitEnumeratorHasOwnProperty):
(JSC::BytecodeGenerator::pushForInScope):
(JSC::BytecodeGenerator::popForInScope):
(JSC::rewriteOp):
(JSC::ForInContext::finalize):
(JSC::BytecodeGenerator::findForInContext):
(JSC::BytecodeGenerator::recordHasOwnStructurePropertyInForInLoop): Deleted.
(JSC::BytecodeGenerator::emitGetEnumerableLength): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableIndexedProperty): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableStructureProperty): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableProperty): Deleted.
(JSC::BytecodeGenerator::emitHasOwnStructureProperty): Deleted.
(JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName): Deleted.
(JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName): Deleted.
(JSC::BytecodeGenerator::emitToIndexString): Deleted.
(JSC::BytecodeGenerator::pushIndexedForInScope): Deleted.
(JSC::BytecodeGenerator::popIndexedForInScope): Deleted.
(JSC::BytecodeGenerator::pushStructureForInScope): Deleted.
(JSC::BytecodeGenerator::popStructureForInScope): Deleted.
(JSC::StructureForInContext::finalize): Deleted.
(JSC::IndexedForInContext::finalize): Deleted.
(JSC::BytecodeGenerator::findStructureForInContext): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::ForInContext::isValid const):
(JSC::ForInContext::invalidate):
(JSC::ForInContext::local const):
(JSC::ForInContext::propertyName const):
(JSC::ForInContext::propertyOffset const):
(JSC::ForInContext::enumerator const):
(JSC::ForInContext::mode const):
(JSC::ForInContext::ForInContext):
(JSC::ForInContext::bodyBytecodeStartOffset const):
(JSC::ForInContext::type const): Deleted.
(JSC::ForInContext::isIndexedForInContext const): Deleted.
(JSC::ForInContext::isStructureForInContext const): Deleted.
(JSC::ForInContext::asIndexedForInContext): Deleted.
(JSC::ForInContext::asStructureForInContext): Deleted.
(JSC::StructureForInContext::StructureForInContext): Deleted.
(JSC::StructureForInContext::index const): Deleted.
(JSC::StructureForInContext::property const): Deleted.
(JSC::StructureForInContext::enumerator const): Deleted.
(JSC::StructureForInContext::baseVariable const): Deleted.
(JSC::StructureForInContext::addGetInst): Deleted.
(JSC::StructureForInContext::addInInst): Deleted.
(JSC::StructureForInContext::addHasOwnPropertyJump): Deleted.
(JSC::IndexedForInContext::IndexedForInContext): Deleted.
(JSC::IndexedForInContext::index const): Deleted.
(JSC::IndexedForInContext::addGetInst): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::HasOwnPropertyFunctionCallDotNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::isSaneChain const):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::injectOSR):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::setJSArraySaneChainIfPossible):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasStorageChild const):
(JSC::DFG::Node::storageChildIndex):
(JSC::DFG::Node::hasArrayMode):
(JSC::DFG::Node::hasEnumeratorMetadata const):
(JSC::DFG::Node::enumeratorMetadata):
* dfg/DFGNodeType.h:
* dfg/DFGOpInfo.h:
(JSC::DFG::OpInfo::OpInfo):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::SSALoweringPhase::handleNode):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString):
(JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol):
(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdateIndexAndMode):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractIndex):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractMode):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdatePropertyName):
(JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal):
(JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty):
(JSC::DFG::SpeculativeJIT::compileEnumeratorInByVal):
(JSC::DFG::SpeculativeJIT::compileEnumeratorHasOwnProperty):
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
(JSC::DFG::SpeculativeJIT::compileGetEnumerableLength): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasEnumerableProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileToIndexString): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasEnumerableStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasOwnStructurePropertyImpl): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasOwnStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileInStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetEnumeratorPname): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetDirectPname): Deleted.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::allocate):
(JSC::DFG::JSValueOperand::regs):
(JSC::DFG::JSValueOperand::gpr):
(JSC::DFG::StorageOperand::StorageOperand):
(JSC::DFG::StorageOperand::~StorageOperand):
(JSC::DFG::StorageOperand::emplace):
(JSC::DFG::JSValueRegsTemporary::operator bool):
(JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByVal):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByVal):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByValImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAtImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* ftl/FTLOutput.h:
(JSC::FTL::Output::phi):
* generator/DSL.rb:
* interpreter/Register.h:
* interpreter/RegisterInlines.h:
(JSC::Register::operator=):
* jit/AssemblyHelpers.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_structure_propertyImpl): Deleted.
(JSC::JIT::emit_op_has_enumerable_structure_property): Deleted.
(JSC::JIT::emit_op_has_own_structure_property): Deleted.
(JSC::JIT::emit_op_in_structure_property): Deleted.
(JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emit_op_get_direct_pname): Deleted.
(JSC::JIT::emit_op_enumerator_structure_pname): Deleted.
(JSC::JIT::emit_op_enumerator_generic_pname): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_structure_propertyImpl): Deleted.
(JSC::JIT::emit_op_has_enumerable_structure_property): Deleted.
(JSC::JIT::emit_op_has_own_structure_property): Deleted.
(JSC::JIT::emit_op_in_structure_property): Deleted.
(JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emit_op_get_direct_pname): Deleted.
(JSC::JIT::emit_op_enumerator_structure_pname): Deleted.
(JSC::JIT::emit_op_enumerator_generic_pname): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::generateGetByValSlowCase):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_enumerator_next):
(JSC::JIT::emit_op_enumerator_get_by_val):
(JSC::JIT::emitSlow_op_enumerator_get_by_val):
(JSC::JIT::emit_enumerator_has_propertyImpl):
(JSC::JIT::emit_op_enumerator_in_by_val):
(JSC::JIT::emit_op_enumerator_has_own_property):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_enumerator_next):
(JSC::JIT::emit_op_enumerator_get_by_val):
(JSC::JIT::emitSlow_op_enumerator_get_by_val):
(JSC::JIT::emit_op_enumerator_in_by_val):
(JSC::JIT::emit_op_enumerator_has_own_property):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
* runtime/CommonSlowPaths.h:
* runtime/FileBasedFuzzerAgent.cpp:
(JSC::FileBasedFuzzerAgent::getPredictionInternal):
* runtime/FileBasedFuzzerAgentBase.cpp:
(JSC::FileBasedFuzzerAgentBase::opcodeAliasForLookupKey):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
(JSC::JSPropertyNameEnumerator::computeNext):
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/PredictionFileCreatingFuzzerAgent.cpp:
(JSC::PredictionFileCreatingFuzzerAgent::getPredictionInternal):
Canonical link: https://commits.webkit.org/240345@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280760 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228809
Reviewed by Fujii Hironori.
Source/WebCore:
No new tests because there is no behavior change.
* Sources.txt:
* WebCore.xcodeproj/project.pbxproj:
* accessibility/AXLogger.cpp:
* inspector/agents/page/PageConsoleAgent.cpp:
* page/Page.cpp:
* platform/LogInitialization.cpp: Copied from Source/WebCore/platform/LogInitialization.h.
(WebCore::logChannels):
(WebCore::getLogChannel):
* platform/LogInitialization.h:
* platform/Logging.cpp:
(WebCore::isLogChannelEnabled): Deleted.
(WebCore::setLogChannelToAccumulate): Deleted.
(WebCore::clearAllLogChannelsToAccumulate): Deleted.
(WebCore::initializeLogChannelsIfNecessary): Deleted.
(WebCore::getLogChannel): Deleted.
* platform/Logging.h:
* testing/js/WebCoreTestSupport.cpp:
(WebCoreTestSupport::setLogChannelToAccumulate):
(WebCoreTestSupport::clearAllLogChannelsToAccumulate):
(WebCoreTestSupport::initializeLogChannelsIfNecessary):
Source/WebKit:
* GPUProcess/GPUConnectionToWebProcess.cpp:
* GPUProcess/GPUProcess.cpp:
(WebKit::GPUProcess::initializeGPUProcess):
* Platform/LogInitialization.cpp: Copied from Source/WebKit/Shared/WebKit2Initialize.cpp.
(WebKit::logChannels):
(WebKit::getLogChannel):
* Platform/LogInitialization.h:
* Platform/Logging.cpp:
(WebKit::initializeLogChannelsIfNecessary): Deleted.
(WebKit::getLogChannel): Deleted.
* Platform/Logging.h:
* Shared/AuxiliaryProcess.cpp:
(WebKit::AuxiliaryProcess::initialize):
* Shared/WebKit2Initialize.cpp:
(WebKit::InitializeWebKit2):
* Sources.txt:
* UIProcess/WebPageProxy.cpp:
* UIProcess/WebProcessPool.cpp:
* WebKit.xcodeproj/project.pbxproj:
* WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::platformInitializeWebProcess):
Source/WebKitLegacy:
* WebKitLegacy.xcodeproj/project.pbxproj:
Source/WebKitLegacy/mac:
* Misc/WebKitLogInitialization.h: Copied from Source/WebKit/Platform/LogInitialization.h.
* Misc/WebKitLogInitialization.mm: Copied from Source/WebKitLegacy/mac/Misc/WebKitLogging.m.
(WebKit::logChannels):
(ReportDiscardedDelegateException):
* Misc/WebKitLogging.h:
* Misc/WebKitLogging.m:
(ReportDiscardedDelegateException): Deleted.
* WebCoreSupport/WebDragClient.mm:
* WebView/WebDelegateImplementationCaching.mm:
* WebView/WebView.mm:
(-[WebView _commonInitializationWithFrameName:groupName:]):
Source/WTF:
The current infrastructure (before this patch) had the following duplicated for each framework:
- A .cpp file declared the list of logging channels for that framework
- The .cpp file also had algorithms to search, modify, and initialize these logging channels
Each framework's .cpp file had duplicate algorithms. (The initialization algorithm was even
duplicated 3 times!)
Because the algorithms directly name their specific list of logging channels, a naive deduplication
would have had to add new parameters to these algorithms to pass in the appropriate framework's
list. That's fine, but this is exactly the sort of thing classes were designed for - classes are
an association of algorithms and data. The algorithms are shared but the data isn't, which really
just means we should have 3 instances of a shared class - one for the 3 sets of data.
So, this patch creates the LogChannels class which contains the deduplicated algorithms, and each
framework has a NeverDestroyed singleton instance of that class. There is a single virtual method
in the class, so the appropriate "default write" variable can be queried for each framework.
The instances cannot be declared in the Logging.h files in the frameworks, because certain WebKit2
files want to initialize all 3 instances of LogChannels, but you can't #include multiple Logging.h
files at the same time because their LOG_CHANNEL_PREFIX #defines will collide with each other.
Luckily, LogInitialization.h files exist exactly to solve this purpose, so that's where the
LogChannels instances are declared in. After this change, the Logging.h files are just for the
declarations of the logging channels themselves, and the LogInitialization.h files are for the
LogChannels instances which contain the searching/modifying/initializing algorithms on the list of
logging channels. If you just want to LOG(...) something, #include the relevant Logging.h file, and
if you want to search/modify/initialize across the entire list of channels, then #include the
relevant LogInitialization.h file.
* WTF.xcodeproj/project.pbxproj:
* wtf/CMakeLists.txt:
* wtf/LogChannels.cpp: Copied from Source/WebCore/platform/Logging.cpp.
(WTF::LogChannels::isLogChannelEnabled):
(WTF::LogChannels::setLogChannelToAccumulate):
(WTF::LogChannels::clearAllLogChannelsToAccumulate):
(WTF::LogChannels::initializeLogChannelsIfNecessary):
(WTF::LogChannels::getLogChannel):
* wtf/LogChannels.h: Copied from Source/WebCore/platform/LogInitialization.h.
Canonical link: https://commits.webkit.org/240343@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280758 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228809
Reviewed by Fujii Hironori.
Source/WebCore:
No new tests because there is no behavior change.
* Sources.txt:
* WebCore.xcodeproj/project.pbxproj:
* accessibility/AXLogger.cpp:
* inspector/agents/page/PageConsoleAgent.cpp:
* page/Page.cpp:
* platform/LogInitialization.cpp: Copied from Source/WebCore/platform/LogInitialization.h.
(WebCore::logChannels):
(WebCore::getLogChannel):
* platform/LogInitialization.h:
* platform/Logging.cpp:
(WebCore::isLogChannelEnabled): Deleted.
(WebCore::setLogChannelToAccumulate): Deleted.
(WebCore::clearAllLogChannelsToAccumulate): Deleted.
(WebCore::initializeLogChannelsIfNecessary): Deleted.
(WebCore::getLogChannel): Deleted.
* platform/Logging.h:
* testing/js/WebCoreTestSupport.cpp:
(WebCoreTestSupport::setLogChannelToAccumulate):
(WebCoreTestSupport::clearAllLogChannelsToAccumulate):
(WebCoreTestSupport::initializeLogChannelsIfNecessary):
Source/WebKit:
* GPUProcess/GPUConnectionToWebProcess.cpp:
* GPUProcess/GPUProcess.cpp:
(WebKit::GPUProcess::initializeGPUProcess):
* Platform/LogInitialization.cpp: Copied from Source/WebKit/Shared/WebKit2Initialize.cpp.
(WebKit::logChannels):
(WebKit::getLogChannel):
* Platform/LogInitialization.h:
* Platform/Logging.cpp:
(WebKit::initializeLogChannelsIfNecessary): Deleted.
(WebKit::getLogChannel): Deleted.
* Platform/Logging.h:
* Shared/AuxiliaryProcess.cpp:
(WebKit::AuxiliaryProcess::initialize):
* Shared/WebKit2Initialize.cpp:
(WebKit::InitializeWebKit2):
* Sources.txt:
* UIProcess/WebPageProxy.cpp:
* UIProcess/WebProcessPool.cpp:
* WebKit.xcodeproj/project.pbxproj:
* WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::platformInitializeWebProcess):
Source/WebKitLegacy:
* WebKitLegacy.xcodeproj/project.pbxproj:
Source/WebKitLegacy/mac:
* Misc/WebKitLogInitialization.h: Copied from Source/WebKit/Platform/LogInitialization.h.
* Misc/WebKitLogInitialization.mm: Copied from Source/WebKitLegacy/mac/Misc/WebKitLogging.m.
(WebKit::logChannels):
(ReportDiscardedDelegateException):
* Misc/WebKitLogging.h:
* Misc/WebKitLogging.m:
(ReportDiscardedDelegateException): Deleted.
* WebCoreSupport/WebDragClient.mm:
* WebView/WebDelegateImplementationCaching.mm:
* WebView/WebView.mm:
(-[WebView _commonInitializationWithFrameName:groupName:]):
Source/WTF:
The current infrastructure (before this patch) had the following duplicated for each framework:
- A .cpp file declared the list of logging channels for that framework
- The .cpp file also had algorithms to search, modify, and initialize these logging channels
Each framework's .cpp file had duplicate algorithms. (The initialization algorithm was even
duplicated 3 times!)
Because the algorithms directly name their specific list of logging channels, a naive deduplication
would have had to add new parameters to these algorithms to pass in the appropriate framework's
list. That's fine, but this is exactly the sort of thing classes were designed for - classes are
an association of algorithms and data. The algorithms are shared but the data isn't, which really
just means we should have 3 instances of a shared class - one for the 3 sets of data.
So, this patch creates the LogChannels class which contains the deduplicated algorithms, and each
framework has a NeverDestroyed singleton instance of that class. There is a single virtual method
in the class, so the appropriate "default write" variable can be queried for each framework.
The instances cannot be declared in the Logging.h files in the frameworks, because certain WebKit2
files want to initialize all 3 instances of LogChannels, but you can't #include multiple Logging.h
files at the same time because their LOG_CHANNEL_PREFIX #defines will collide with each other.
Luckily, LogInitialization.h files exist exactly to solve this purpose, so that's where the
LogChannels instances are declared in. After this change, the Logging.h files are just for the
declarations of the logging channels themselves, and the LogInitialization.h files are for the
LogChannels instances which contain the searching/modifying/initializing algorithms on the list of
logging channels. If you just want to LOG(...) something, #include the relevant Logging.h file, and
if you want to search/modify/initialize across the entire list of channels, then #include the
relevant LogInitialization.h file.
* WTF.xcodeproj/project.pbxproj:
* wtf/CMakeLists.txt:
* wtf/LogChannels.cpp: Copied from Source/WebCore/platform/Logging.cpp.
(WTF::LogChannels::isLogChannelEnabled):
(WTF::LogChannels::setLogChannelToAccumulate):
(WTF::LogChannels::clearAllLogChannelsToAccumulate):
(WTF::LogChannels::initializeLogChannelsIfNecessary):
(WTF::LogChannels::getLogChannel):
* wtf/LogChannels.h: Copied from Source/WebCore/platform/LogInitialization.h.
Canonical link: https://commits.webkit.org/240341@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280756 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228886
Reviewed by Said Abou-Hallawa.
Rename some "identifier" variables to differentiate between resource identifiers and
item buffer identifiers.
No behavior change.
* GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::RemoteRenderingBackend::createImageBuffer):
(WebKit::RemoteRenderingBackend::wakeUpAndApplyDisplayList):
(WebKit::RemoteRenderingBackend::cacheNativeImage):
(WebKit::RemoteRenderingBackend::cacheFont):
(WebKit::RemoteRenderingBackend::didCreateSharedDisplayListHandle):
Canonical link: https://commits.webkit.org/240339@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280754 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228885
<rdar://81603231>
Reviewed by Wenson Hsieh.
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000164708_00001.html triggered an issue
where RemoteRenderingBackend::finalizeRenderingUpdate() would be called when the
GPU process had just processed a "switching to next item buffer" meta command,
but had not yet received the new item buffer. This triggered the
MESSAGE_CHECK(initialHandle, "Missing initial shared display list handle");
in RemoteRenderingBackend::wakeUpAndApplyDisplayList().
Protect against this by having finalizeRenderingUpdate() check that
arguments.itemBufferIdentifier had been received, which is similar to what happens
inside the loop in wakeUpAndApplyDisplayList() already.
Not easily testable.
* GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::RemoteRenderingBackend::finalizeRenderingUpdate):
Canonical link: https://commits.webkit.org/240338@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280753 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228881
rdar://81294035
Reviewed by Andy Estes.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::navigateToPDFLinkWithSimulatedClick):
Clicking a link in PDF should absolutely be allowed to launch an external app.
Humorously, r185111 applied the correct value to PDFPlugin (macOS), but the
wrong value to WKPDFView (iOS). Bring them into alignment.
Canonical link: https://commits.webkit.org/240336@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280751 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228810
Reviewed by Saam Barati.
We should track up to 2 candidate characters without masking, so
that we can search a character without masking. To track candidates,
we introduce BoyerMooreCharacterCandidates.
We also add support for m_table because m_table can be used
for important CharacterClass like `\s`, and still that does not have
many character candidates if the mode is Char8.
To make `\s` work on Char8 case, we use Char8 / Char16 information
to filter characters that never appears in BoyreMoore search bitmap
construction.
* yarr/YarrJIT.cpp:
(JSC::Yarr::BoyerMooreInfo::BoyerMooreInfo):
(JSC::Yarr::BoyerMooreInfo::set):
(JSC::Yarr::BoyerMooreInfo::addCharacters):
(JSC::Yarr::BoyerMooreInfo::addRanges):
(JSC::Yarr::BoyerMooreInfo::create):
(JSC::Yarr::BoyerMooreInfo::createCandidateBitmap const):
* yarr/YarrJIT.h:
(JSC::Yarr::BoyerMooreCharacterCandidates::isValid const):
(JSC::Yarr::BoyerMooreCharacterCandidates::invalidate):
(JSC::Yarr::BoyerMooreCharacterCandidates::isEmpty const):
(JSC::Yarr::BoyerMooreCharacterCandidates::size const):
(JSC::Yarr::BoyerMooreCharacterCandidates::at const):
(JSC::Yarr::BoyerMooreCharacterCandidates::add):
(JSC::Yarr::BoyerMooreCharacterCandidates::merge):
(JSC::Yarr::BoyerMooreBitmap::characterCandidates const):
(JSC::Yarr::BoyerMooreBitmap::add):
(JSC::Yarr::BoyerMooreBitmap::addCharacters):
(JSC::Yarr::BoyerMooreBitmap::addRanges):
(JSC::Yarr::BoyerMooreBitmap::isMaskEffective const): Deleted.
Canonical link: https://commits.webkit.org/240330@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280744 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228853
Reviewed by Alex Christensen.
Source/WebKit:
~NetworkResourceLoader() had the assertion ensuring m_networkLoad
was empty. But, this could fail in the following scenario. If a
'keepalive' fetch request is not finished and the page is
navigated away, its NetworkResourceLoader is transferred to the
NetworkSession by NetworkConnectionToWebProcess::transferKeptAliveLoad.
And, before the request is finished, if the NetworkSession is
destroyed, the kept alive NetworkResourceLoader is destroyed.
Test: http/tests/fetch/keepalive-fetch.html
* NetworkProcess/NetworkSession.cpp:
(WebKit::NetworkSession::~NetworkSession): Abort m_keptAliveLoads.
LayoutTests:
* http/tests/fetch/keepalive-fetch-expected.txt: Added.
* http/tests/fetch/keepalive-fetch.html: Added.
Canonical link: https://commits.webkit.org/240326@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280740 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228874
Patch by Michael Catanzaro <mcatanzaro@gnome.org> on 2021-08-06
Reviewed by Geoffrey Garen.
When built with LTO enabled, GCC will warn about violations of C++'s one-definition rule.
MallocBench has two different Objects in two different files, which is illegal. We could
rename one of them, but I decided it's simplest to just put them each in anonymous
namespaces in order to restrict them to file scope.
* MallocBench/MallocBench/big.cpp:
* MallocBench/MallocBench/stress.cpp:
Canonical link: https://commits.webkit.org/240324@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280738 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228834
rdar://75390908
Reviewed by Wenson Hsieh and Tim Horton.
Reports show 3 second hangs in WebPageProxy::acceptsFirstMouse, which is
the timeout for the sync IPC sent by the method. While this method has
always sent a sync IPC, logs show the WebProcess is also blocked on sync
IPC, under WebProcess::ensureGPUProcessConnection.
If a Web<->GPU process connection has not been established,
WebProcess::ensureGPUProcessConnection sends a sync IPC from the
WebProcess to the UIProcess to establish get the connection. However, to
get the connection, the UIProcess then sends an async IPC with a reply
block to the GPUProcess (see GPUProcessProxy::getGPUProcessConnection).
The WebProcess remains blocked until the UIProcess receives the reply
from the GPUProcess, and then sends a reply to the WebProcess.
Now, if a call to acceptsFirstMouse occurs in between the time the async
UIProcess -> GPUProcess IPC is sent, and the reply is received, we will
experience deadlock. The UIProcess will be blocked waiting on the
WebProcess' reply to acceptsFirstMouse, and the reply from the GPUProcess
will not be dispatched. Since the reply from the GPUProcess will not be
dispatched until the UIProcess is unblocked, the WebProcess will be
waiting under WebProcess:ensureGPUProcessConnection, and unable to reply
to acceptsFirstMouse.
A simple fix for the described scenario would be to introduce a
replySendOptions parameter to sendWithAsyncReply, so that the UIProcess
could be re-entered to dispatch the GPUProcess reply, even when waiting
for acceptsFirstMouse. However, this will not work in cases where the
GPUProcess is being launched, due to being blocked on the reply from
xpc_connection_send_message_with_reply in ProcessLauncherMac, which is
before the IPC::Connection has been established.
Since re-entering the UIProcess is not possible in this scenario, given
the existing architecture, the next simplest solution is to re-enter
the WebProcess on acceptsFirstMouse instead. Consequently, one part of
the fix involves sending the acceptsFirstMouse IPC with
IPC::SendOption::DispatchMessageEvenWhenWaitingForUnboundedSyncReply and
tagging WebProcess::getGPUProcessConnection as unbounded sync IPC.
Then, we must also consider the fact that, in the WebProcess,
acceptsFirstMouse performs hit-testing. Hit-testing triggers layout and
could cause script to run. Script could result in a GPUProcess connection
being established, eventually leading us down the path towards the
aforementioned deadlock. To avoid deadlock in this scenario, we need to
interrupt acceptsFirstMouse if a message to get the GPUProcess connection
is received. This is achieved by using waitForAndDispatchImmediately with
the InterruptWaitingIfSyncMessageArrives option, and splitting up
acceptsFirstMouse into two separate IPCs.
* UIProcess/WebPageProxy.h:
* UIProcess/WebPageProxy.messages.in:
* UIProcess/ios/WebPageProxyIOS.mm:
Implementation not required for iOS.
* UIProcess/mac/WebPageProxyMac.mm:
(WebKit::WebPageProxy::acceptsFirstMouse):
Send an async IPC with IPC::SendOption::DispatchMessageEvenWhenWaitingForUnboundedSyncReply
so that the WebProcess can be re-entered to resolve deadlock if
necessary. Then, use waitForAndDispatchImmediately to wait for the reply
(essentially making it a sync IPC), so that the wait can be interrupted
if another sync message, such as getGPUProcessConnection, is received.
(WebKit::WebPageProxy::handleAcceptsFirstMouse):
Store the result of the reply from the WebProcess.
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/WebPage.messages.in:
Split the sync IPC into two async IPCs, in order to support the use of
waitForAndDispatchImmediately.
* WebProcess/WebPage/ios/WebPageIOS.mm:
Implementation not required for iOS.
* WebProcess/WebPage/mac/WebPageMac.mm:
(WebKit::WebPage::requestAcceptsFirstMouse):
Exit early if re-entering the WebProcess, to avoid running script on
re-entry.
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::getGPUProcessConnection):
Tag as unbounded sync IPC, so the WebProcess can be re-entered to
resolve deadlock.
Canonical link: https://commits.webkit.org/240322@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280736 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228824
<rdar://problem/81564477>
Reviewed by Eric Carlson.
Source/WebCore:
Manually tested.
* platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::sampleBufferDisplayLayerStatusDidChange):
Recreate a new layer if the previous one failed.
Source/WebKit:
Make WebKit::SampleBufferDisplayLayer listen to GPUProcess connection being closed.
When that happens, notify its client that it failed.
* WebProcess/GPU/GPUProcessConnection.cpp:
* WebProcess/GPU/GPUProcessConnection.h:
* WebProcess/GPU/media/RemoteMediaPlayerManager.cpp:
* WebProcess/GPU/webrtc/SampleBufferDisplayLayer.cpp:
(WebKit::SampleBufferDisplayLayer::create):
(WebKit::SampleBufferDisplayLayer::SampleBufferDisplayLayer):
(WebKit::SampleBufferDisplayLayer::~SampleBufferDisplayLayer):
(WebKit::SampleBufferDisplayLayer::setDidFail):
(WebKit::SampleBufferDisplayLayer::gpuProcessConnectionDidClose):
* WebProcess/GPU/webrtc/SampleBufferDisplayLayer.h:
* WebProcess/GPU/webrtc/SampleBufferDisplayLayerManager.cpp:
(WebKit::SampleBufferDisplayLayerManager::createLayer):
* WebProcess/GPU/webrtc/SampleBufferDisplayLayerManager.h:
Canonical link: https://commits.webkit.org/240318@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280731 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228803
<rdar://problem/81142982>
Reviewed by Tim Horton.
Source/WebKit:
On macOS, Safari Technology Preview or a local build WebKit/Safari will always
get the default preference values through the "Feature Flags" SPI. Unfortunately,
this approach won't work if the OS does not provide correct default preference values.
With this patch, we only get default preference values with the SPI for system
WebKit on macOS. For all other cases, we use hardcoded values. So that
WebKit will always get the correct default preference values.
This patch also fixes a few mistakes in two preferences: "webm_webaudio" and "vp8_decoder".
* FeatureFlags/WebKit-appletvos.plist:
* FeatureFlags/WebKit-ios.plist:
* FeatureFlags/WebKit-macos.plist:
* FeatureFlags/WebKit-watchos.plist:
* Shared/Cocoa/WebPreferencesDefaultValuesCocoa.mm:
(WebKit::isFeatureFlagEnabled):
* Shared/WebPreferencesDefaultValues.cpp:
(WebKit::isFeatureFlagEnabled):
(WebKit::defaultAsyncFrameAndOverflowScrollingEnabled):
(WebKit::defaultUseGPUProcessForCanvasRenderingEnabled):
(WebKit::defaultUseGPUProcessForDOMRenderingEnabled):
(WebKit::defaultUseGPUProcessForMediaEnabled):
(WebKit::defaultUseGPUProcessForWebGLEnabled):
(WebKit::defaultCaptureAudioInGPUProcessEnabled):
(WebKit::defaultCaptureVideoInGPUProcessEnabled):
(WebKit::defaultWebRTCCodecsInGPUProcess):
(WebKit::defaultIncrementalPDFEnabled):
(WebKit::defaultWebMFormatReaderEnabled):
(WebKit::defaultVP8DecoderEnabled):
(WebKit::defaultVP9DecoderEnabled):
(WebKit::defaultVP9SWDecoderEnabledOnBattery):
(WebKit::defaultWebMParserEnabled):
(WebKit::defaultWebMWebAudioEnabled):
(WebKit::defaultInAppBrowserPrivacy): Deleted.
* Shared/WebPreferencesDefaultValues.h:
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::creationParameters): Fix a typo.
Source/WebKitLegacy/mac:
On macOS, Safari Technology Preview or a local build WebKit/Safari will always
get the default preference values through the "Feature Flags" SPI. Unfortunately,
this approach won't work if the OS does not provide correct default preference values.
With this patch, we only get default preference values with the SPI for system
WebKit on macOS. For all other cases, we use hardcoded values. So that
WebKit will always get the correct default preference values.
This patch also fixes a few mistakes in two preferences: "webm_webaudio" and "vp8_decoder".
* WebView/WebPreferencesDefaultValues.h:
* WebView/WebPreferencesDefaultValues.mm:
(WebKit::isFeatureFlagEnabled):
(WebKit::defaultIncrementalPDFEnabled):
(WebKit::defaultWebXREnabled):
(WebKit::defaultWebMParserEnabled):
(WebKit::defaultWebMWebAudioEnabled):
(WebKit::defaultVP8DecoderEnabled):
(WebKit::defaultVP9DecoderEnabled):
LayoutTests:
Update a mac-bigsur specific test expectation file because the test is passing now.
* platform/mac/imported/w3c/web-platform-tests/media-source/mediasource-addsourcebuffer-expected.txt: Removed.
* platform/mac-bigsur/imported/w3c/web-platform-tests/media-source/mediasource-addsourcebuffer-expected.txt:
Canonical link: https://commits.webkit.org/240316@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280726 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228560
<rdar://problem/81336280>
Reviewed by Eric Carlson.
Source/WebCore:
A much more minimal approach to removing support for AVAssetImageGenerator.
The only time we use an AVAssetImageGenerator (as opposed to an AVPlayerItemVideoOutput)
is when the latter does not currently have an available image enqueued. Because painting
is a synchronous operation, we use a synchronous API (the generator) to create an image
for that operation. However, this can create deadlocks if (for example) the resource needs
to load data on the main thread in order to complete the painting operation.
Instead, allow the main runloop to spin while waiting (up to 1_s) for the video output
to receive a decoded frame.
Drive-by fixes:
- Don't create an AVPlayerLayer at AVPlayer-creation; this causes the AVPlayerItemVideoOutput
to never receive a decoded frambe (as the layer is not in a CALayer-heirarchy).
- preferredRenderingMode() shouldn't be "none" when the page isn't visible. We already
just mark the layer as "hidden" in that case.
- Don't tear down the AVPlayerItemVideoOutput when creating an AVPlayerLayer; it'll just
get re-created anyway.
* platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
(WebCore::MediaPlayerPrivateAVFoundation::preferredRenderingMode const):
(WebCore::MediaPlayerPrivateAVFoundation::setUpVideoRendering):
* platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h:
* platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayer):
(WebCore::MediaPlayerPrivateAVFoundationObjC::paintCurrentFrameInContext):
(WebCore::MediaPlayerPrivateAVFoundationObjC::createVideoOutput):
(WebCore::MediaPlayerPrivateAVFoundationObjC::paintWithVideoOutput):
(WebCore::MediaPlayerPrivateAVFoundationObjC::waitForVideoOutputMediaDataWillChange):
(WebCore::MediaPlayerPrivateAVFoundationObjC::outputMediaDataWillChange):
(-[WebCoreAVFPullDelegate outputMediaDataWillChange:]):
(-[WebCoreAVFPullDelegate setParent:]):
Source/WebKit:
Drive-by fix: we're passing the wrong value into acceleratedRenderingStateChanged(), and
we're not setting the correct initial value on MediaPlayerPrivateRemote creation.
* GPUProcess/media/RemoteMediaPlayerProxy.h:
* WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:
(WebKit::MediaPlayerPrivateRemote::MediaPlayerPrivateRemote):
(WebKit::MediaPlayerPrivateRemote::acceleratedRenderingStateChanged):
Canonical link: https://commits.webkit.org/240314@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280723 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228816
<rdar://81077972>
Reviewed by Eric Carlson.
Source/WebCore:
Do not create layers when not needed.
This prevents enqueuing frames in a AVSampleBufferDisplayLayer that will only buffer them, thus breaking camera capture/video decoding.
We do this by not calling ensureLayers when getting a new track. Instead we react upon player renderingCanBeAccelerated value.
It is also unnecessary and takes CPU cycles to enqueue frames when the video element is not visible.
HTMLMediaElement and RenderVideo thus pass to MediaPlayer a new flag telling whether the video element is visible in the view port.
MediaPlayerPrivateMediaStreamAVFObjC will then skip enqueueing frames if not needed.
Add getter and internals API to cover these changes.
Test: fast/mediastream/mediaPlayer-visibility.html
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::isVisibleInViewportChanged):
* platform/graphics/MediaPlayer.cpp:
(WebCore::MediaPlayer::loadWithNextMediaEngine):
(WebCore::MediaPlayer::setVisibleInViewport):
* platform/graphics/MediaPlayer.h:
* platform/graphics/MediaPlayerPrivate.h:
(WebCore::MediaPlayerPrivateInterface::setVisibleInViewport):
* platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h:
* platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::enqueueVideoSample):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::setVisible):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::setVisibleInViewport):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::checkSelectedVideoTrack):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::paintCurrentFrameInContext):
* rendering/RenderVideo.cpp:
(WebCore::RenderVideo::updatePlayer):
* testing/Internals.cpp:
(WebCore::Internals::isPlayerVisibleInViewport const):
* testing/Internals.h:
* testing/Internals.idl:
LayoutTests:
* fast/mediastream/mediaPlayer-visibility-expected.txt: Added.
* fast/mediastream/mediaPlayer-visibility.html: Added.
Canonical link: https://commits.webkit.org/240311@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280720 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228724
<rdar://problem/81435095>
Reviewed by Darin Adler.
Source/WebCore:
FormController currently tracks the insertion order of
HTMLFormElementWithState objects in the document. But we don't need
to know this list of form controls until the time we need to save
form state for the document (e.g. on pagehide). So we instead
traverse the document to find those elements at the point we need
them, rather than maintain FormController::m_formElementsWithState.
This is a small speedup (1-2%) on a few of the Speedometer subtests
that insert and remove many input elements.
A future optimization could record on the Document whether there are
any input elements that have had their value changed, since it's
probably common for pages with form controls to never be changed.
* dom/Document.cpp:
(WebCore::Document::formElementsState const): Traverse the document to
find all the HTMLFormElementWithState objects.
* dom/Element.h:
(WebCore::Element::isFormControlElementWithState const):
* html/FormController.cpp:
(WebCore::FormController::createSavedFormStateMap):
(WebCore::FormController::formElementsState const):
* html/FormController.h:
* html/HTMLFormControlElementWithState.cpp:
(WebCore::HTMLFormControlElementWithState::insertedIntoAncestor):
Track the order that HTMLFormControlElementWithState objects are
inserted into the document.
(WebCore::HTMLFormControlElementWithState::removedFromAncestor):
* html/HTMLFormControlElementWithState.h:
(WebCore::HTMLFormControlElementWithState::insertionIndex const):
(isType):
* page/Frame.h: Remove unused formElementsCharacterCount.
* page/ios/FrameIOS.mm:
Source/WebKitLegacy/mac:
formElementsCharacterCount is unused and can be removed.
* WebView/WebFrame.mm:
* WebView/WebFramePrivate.h:
Canonical link: https://commits.webkit.org/240309@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280718 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228839
Patch by Mikhail R. Gadelha <mikhail@igalia.com> on 2021-08-05
Reviewed by Yusuke Suzuki.
JSTests:
* stress/check-array-empty-32.js: Added.
(a.b.catch.print.c):
(a.b):
(a.e):
(a):
Source/JavaScriptCore:
Since empty values don't pass the cell check in 32 bits, we need to
guard the SpecEmpty check to only happen in 64 bits archs
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):
Canonical link: https://commits.webkit.org/240307@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280716 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Cameron McCormack