Timeline
Jun 3, 2020:
- 7:25 PM Changeset in webkit [262529] by
-
- 2 edits in trunk/Source/WebCore
[iOS] Validate index parameter in PlatformPasteboard
https://bugs.webkit.org/show_bug.cgi?id=212713
<rdar://problem/60068765>
Reviewed by Wenson Hsieh.
Validate index parameter in PlatformPasteboard, before calling [NSIndexSet indexSetWithIndex:].
Per documentation, index needs to be in the range [0 .. NSNotFound-1].
- platform/ios/PlatformPasteboardIOS.mm:
(WebCore::PlatformPasteboard::readBuffer const):
(WebCore::PlatformPasteboard::readString const):
(WebCore::PlatformPasteboard::readURL const):
- 6:57 PM Changeset in webkit [262528] by
-
- 17 edits1 add2 deletes in trunk
[Apple Pay] Add new values for -apple-pay-button-type
https://bugs.webkit.org/show_bug.cgi?id=212684
<rdar://problem/63908535>
Reviewed by Anders Carlsson.
Source/WebCore:
Where available, added new values for -apple-pay-button-type and introduced ApplePaySession v10.
New test: http/tests/ssl/applepay/ApplePayButton.html
- Modules/applepay/PaymentCoordinatorClient.cpp:
(WebCore::PaymentCoordinatorClient::supportsVersion):
- accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::applePayButtonDescription const):
- css/CSSPrimitiveValueMappings.h:
(WebCore::CSSPrimitiveValue::CSSPrimitiveValue):
(WebCore::CSSPrimitiveValue::operator ApplePayButtonType const):
- css/CSSValueKeywords.in:
- css/parser/CSSParserFastPaths.cpp:
(WebCore::CSSParserFastPaths::isValidKeywordPropertyAndValue):
- en.lproj/Localizable.strings:
- platform/LocalizedStrings.cpp:
(WebCore::AXApplePayReloadLabel):
(WebCore::AXApplePayAddMoneyLabel):
(WebCore::AXApplePayTopUpLabel):
(WebCore::AXApplePayOrderLabel):
(WebCore::AXApplePayRentLabel):
(WebCore::AXApplePaySupportLabel):
(WebCore::AXApplePayContributeLabel):
(WebCore::AXApplePayTipLabel):
- platform/LocalizedStrings.h:
- rendering/RenderThemeCocoa.mm:
(WebCore::toPKPaymentButtonType):
- rendering/style/RenderStyleConstants.cpp:
(WebCore::operator<<):
- rendering/style/RenderStyleConstants.h:
- rendering/style/StyleRareNonInheritedData.h:
Source/WTF:
- wtf/PlatformEnableCocoa.h:
LayoutTests:
- http/tests/ssl/applepay/ApplePayButton-expected.txt: Added.
- http/tests/ssl/applepay/ApplePayButton.html:
- http/tests/ssl/applepay/ApplePayButtonV4.html: Removed.
- platform/mac/http/tests/ssl/applepay/ApplePayButton-expected.png: Removed.
- platform/mac/http/tests/ssl/applepay/ApplePayButton-expected.txt: Removed.
- platform/mac/http/tests/ssl/applepay/ApplePayButtonV4-expected.png: Removed.
- platform/mac/http/tests/ssl/applepay/ApplePayButtonV4-expected.txt: Removed.
- 6:05 PM Changeset in webkit [262527] by
-
- 141 edits6 deletes in trunk/LayoutTests
Resync web-platform-tests/2dcontext from upstream
https://bugs.webkit.org/show_bug.cgi?id=212639
Reviewed by Youenn Fablet.
LayoutTests/imported/w3c:
Resync web-platform-tests/2dcontext from upstream d3ea88514a93b7b6968.
- resources/import-expectations.json:
- resources/resource-files.json:
- web-platform-tests/2dcontext/*: Removed.
- web-platform-tests/html/canvas/element/*: Added.
- web-platform-tests/html/canvas/resources/*: Added.
- web-platform-tests/html/canvas/tools/*: Added.
LayoutTests:
- TestExpectations:
- canvas/philip/tests/2d.drawImage.incomplete.emptysrc.html:
- canvas/philip/tests/2d.drawImage.incomplete.nosrc.html:
- canvas/philip/tests/2d.drawImage.incomplete.removedsrc.html:
- canvas/philip/tests/2d.pattern.image.incomplete.emptysrc.html:
- canvas/philip/tests/2d.pattern.image.incomplete.removedsrc.html:
- gpu-process/TestExpectations:
- platform/glib/imported/w3c/web-platform-tests/2dcontext/imagebitmap/createImageBitmap-drawImage-expected.txt: Removed.
- platform/glib/imported/w3c/web-platform-tests/2dcontext/imagebitmap/createImageBitmap-flipY-expected.txt: Removed.
- platform/glib/imported/w3c/web-platform-tests/2dcontext/imagebitmap/createImageBitmap-invalid-args-expected.txt: Removed.
- platform/glib/imported/w3c/web-platform-tests/2dcontext/imagebitmap/createImageBitmap-origin.sub-expected.txt: Removed.
- platform/glib/imported/w3c/web-platform-tests/2dcontext/imagebitmap/createImageBitmap-transfer-expected.txt: Removed.
- platform/gtk/TestExpectations:
- platform/gtk/imported/w3c/web-platform-tests/2dcontext/imagebitmap/createImageBitmap-serializable-expected.txt: Removed.
- platform/ios-simulator/TestExpectations:
- platform/ios-wk2/TestExpectations:
- platform/ios/TestExpectations:
- platform/ios/imported/w3c/web-platform-tests/2dcontext/imagebitmap/createImageBitmap-invalid-args-expected.txt: Removed.
- platform/mac/TestExpectations:
- platform/mac/imported/w3c/web-platform-tests/2dcontext/line-styles/2d.line.cap.round-expected.txt: Removed.
- platform/win/TestExpectations:
- platform/wpe/TestExpectations:
- platform/wpe/imported/w3c/web-platform-tests/2dcontext/imagebitmap/createImageBitmap-serializable-expected.txt: Removed.
- 5:25 PM Changeset in webkit [262526] by
-
- 2 edits in trunk/Source/WebKit
[watchOS] fast/events/watchos/change-focus-during-change-event.html crashes
https://bugs.webkit.org/show_bug.cgi?id=212722
<rdar://problem/60633339>
Reviewed by Andy Estes.
When HAVE(QUICKBOARD_COLLECTION_VIEWS) is enabled, the codepath that's used to simulate interacting with the
select menu view controller on watchOS will crash, since it tries to pretend that the user has selected an item
in a table view section (PUICQuickboardListSectionTextOptions) that only exists when Quickboard collection
views are disabled. Fix the crash by adjusting the testing codepath to select the item in the first section when
HAVE(QUICKBOARD_COLLECTION_VIEWS) is defined.
- UIProcess/ios/forms/WKSelectMenuListViewController.mm:
(-[WKSelectMenuListViewController selectItemAtIndex:]):
- 5:01 PM Changeset in webkit [262525] by
-
- 3 edits4 adds in trunk
Inserted text placeholder should vertically align to top and behave like block-level element when it has 0 width
https://bugs.webkit.org/show_bug.cgi?id=212716
<rdar://problem/62672479>
Reviewed by Darin Adler.
Source/WebCore:
Refine the appearance of a text placeholder based on feedback:
- If the width of the placeholder is 0 then put it on its own line. This is accomplished by making it CSS "display: block".
- Vertically align the placeholder with the top of the line.
Both of these refinements are to make the rendering more like TextKit's rendering.
Tests: editing/text-placeholder/insert-into-content-editable-non-zero-width-and-height.html
editing/text-placeholder/insert-into-content-editable-zero-width.html
- html/shadow/TextPlaceholderElement.cpp:
LayoutTests:
Add tests.
- editing/text-placeholder/insert-into-content-editable-non-zero-width-and-height-expected.html: Added.
- editing/text-placeholder/insert-into-content-editable-non-zero-width-and-height.html: Added.
- editing/text-placeholder/insert-into-content-editable-zero-width-expected.html: Added.
- editing/text-placeholder/insert-into-content-editable-zero-width.html: Added.
- 4:22 PM Changeset in webkit [262524] by
-
- 5 edits2 adds in trunk
Release Assert @ WebCore::RenderTreeBuilder::RenderTreeBuilder
https://bugs.webkit.org/show_bug.cgi?id=212714
Patch by Pinki Gyanchandani <pgyanchandani@apple.com> on 2020-06-03
Reviewed by Geoffrey Garen.
Source/WebCore:
Widget removal in the middle of building a Render Tree causes side effects, leading to Release Assert. Moved the scope for suspension of widgets
update to RenderTreeBuilder instead of having it in RenderTreeUpdater.
Also made sure that the WidgetHierarchyUpdatesSuspensionScope::moveWidgets() should handle all widgets scheduled to move, including new widgets
scheduled during moveWidgets().
Test: fast/rendering/widget-removal-in-render-tree-builder-crash.html
- rendering/RenderWidget.cpp:
(WebCore::WidgetHierarchyUpdatesSuspensionScope::moveWidgets):
- rendering/updating/RenderTreeBuilder.h:
- rendering/updating/RenderTreeUpdater.cpp:
(WebCore::RenderTreeUpdater::tearDownRenderers):
LayoutTests:
Added a regression test.
- fast/rendering/widget-removal-in-render-tree-builder-crash-expected.txt: Added.
- fast/rendering/widget-removal-in-render-tree-builder-crash.html: Added.
- 4:18 PM Changeset in webkit [262523] by
-
- 6 edits2 adds in trunk
Disable B3 hoistLoopInvariantValues by default
https://bugs.webkit.org/show_bug.cgi?id=212511
<rdar://problem/63813245>
Reviewed by Mark Lam.
JSTests:
- microbenchmarks/interpreter-wasm.js: Added.
(key.in.Module.Module.hasOwnProperty):
(quit_):
(locateFile):
(ENVIRONMENT_IS_NODE.read_):
(ENVIRONMENT_IS_NODE.readBinary):
(ENVIRONMENT_IS_NODE.quit_):
(ENVIRONMENT_IS_NODE.Module.string_appeared_here):
(else.read_):
(else.readBinary):
(else.quit_):
(else):
(else.xhr.onload):
(else.readAsync):
(else.setWindowTitle):
(key.in.moduleOverrides.moduleOverrides.hasOwnProperty):
(dynamicAlloc):
(getNativeTypeSize):
(warnOnce):
(convertJsFunctionToWasm):
(addFunctionWasm):
(removeFunctionWasm):
(setTempRet0):
(setValue):
(assert):
(getCFunc):
(toC.string_appeared_here):
(convertReturnValue):
(ccall):
(UTF8ArrayToString):
(UTF8ToString):
(stringToUTF8Array):
(stringToUTF8):
(lengthBytesUTF8):
(allocateUTF8OnStack):
(writeArrayToMemory):
(writeAsciiToMemory):
(updateGlobalBufferAndViews):
(callRuntimeCallbacks):
(preRun):
(initRuntime):
(preMain):
(exitRuntime):
(postRun):
(addOnPreRun):
(addOnPostRun):
(addRunDependency):
(removeRunDependency):
(hasPrefix):
(isDataURI):
(isFileURI):
(getBinary):
(getBinaryPromise):
(createWasm.receiveInstance):
(createWasm.receiveInstantiatedSource):
(createWasm.instantiateArrayBuffer):
(createWasm.instantiateAsync.):
(createWasm.instantiateAsync):
(createWasm):
(ATINIT.push.func):
(demangle):
(demangleAll):
(_emscripten_get_sbrk_ptr):
(_emscripten_memcpy_big):
(abortOnCannotGrowMemory):
(_emscripten_resize_heap):
(PATH.splitPath):
(PATH.normalizeArray):
(PATH.normalize):
(PATH.dirname):
(PATH.basename):
(PATH.extname):
(PATH.join):
(PATH.join2):
(SYSCALLS.printChar):
(SYSCALLS.getStr):
(SYSCALLS.get64):
(_fd_write):
(_setTempRet0):
(_wasm_call_ctors.Module.string_appeared_here):
(_main.Module.string_appeared_here):
(_malloc.Module.string_appeared_here):
(_errno_location.Module.string_appeared_here):
(_free.Module.string_appeared_here):
(stackSave.Module.string_appeared_here):
(stackAlloc.Module.string_appeared_here):
(stackRestore.Module.string_appeared_here):
(growWasmMemory.Module.string_appeared_here):
(dynCall_ii.Module.string_appeared_here):
(dynCall_iiii.Module.string_appeared_here):
(dynCall_jiji.Module.string_appeared_here):
(ExitStatus):
(dependenciesFulfilled):
(callMain):
(run.doRun):
(run):
(exit):
- microbenchmarks/interpreter-wasm.wasm: Added.
Source/JavaScriptCore:
The hoistLoopInvariantValues optimization in B3 does not calculate the cost of hoisting the candidates.
For example, in the test case provided with the bug, a switch inside a loop can lead to hoisting the body
of several switch cases which would never be executed. Other than leading to worse runtime, this also
increases the pressure in the register allocate, leading to worse compile times (~10x worse in this case).
I have added a FIXME to consider adding cost calculation and re-enabling this pass, but given that we
already have LICM in DFG, it should be ok to disable it for now.
- b3/B3Generate.cpp:
(JSC::B3::generateToAir):
- runtime/OptionsList.h:
Tools:
Enable the B3 hoistLoopInvariantValues pass in one of our existing configurations to
avoid bit rot since we'd like to re-enable it eventually.
- Scripts/run-jsc-stress-tests:
- 4:16 PM Changeset in webkit [262522] by
-
- 1 copy in tags/Safari-610.1.15.1.3
Tag Safari-610.1.15.1.3.
- 4:11 PM Changeset in webkit [262521] by
-
- 8 edits in branches/safari-610.1.15-branch/Source
Revert "Versioning."
This reverts commit r262519.
- 4:10 PM Changeset in webkit [262520] by
-
- 8 edits in branches/safari-610.1.15.1-branch/Source
Versioning.
- 4:00 PM Changeset in webkit [262519] by
-
- 8 edits in branches/safari-610.1.15-branch/Source
Versioning.
- 3:55 PM Changeset in webkit [262518] by
-
- 2 edits in trunk/LayoutTests
[ macOS wk1 debug ] svg/custom/textPath-change-id.svg is a flaky failure
https://bugs.webkit.org/show_bug.cgi?id=212721
Unreviewed test gardening.
- platform/mac-wk2/TestExpectations:
- 3:15 PM Changeset in webkit [262517] by
-
- 3 edits in trunk/Source/JavaScriptCore
Gardening: fix broken Windows debug build.
https://bugs.webkit.org/show_bug.cgi?id=212680
Not reviewed.
- dfg/DFGDoesGCCheck.cpp:
(JSC::DFG::DoesGCCheck::verifyCanGC):
- dfg/DFGDoesGCCheck.h:
- 2:34 PM Changeset in webkit [262516] by
-
- 3 edits in trunk/LayoutTests
Refactor long press test to reflect current behaviour.
https://bugs.webkit.org/show_bug.cgi?id=212709
<rdar://problem/59572126>
Reviewed by Wenson Hsieh.
Previously, if you long pressed on editable content, the selection assistant would be triggered
in the wrong mode and you could not modify or interact with the selection. With changes and
refactors that have happened in UIKit and WebKit, the selection can be interacted with
correctly inside of an editable area. We should now allow and test for this behavior.
- fast/events/touch/ios/long-press-on-editable-expected.txt:
- fast/events/touch/ios/long-press-on-editable.html:
- 2:08 PM Changeset in webkit [262515] by
-
- 4 edits in trunk
[Text manipulation] Extract the value attribute in inputs of type "text" and "search"
https://bugs.webkit.org/show_bug.cgi?id=212706
<rdar://problem/63876969>
Reviewed by Tim Horton.
Source/WebCore:
Allow text manipulation to extract text for the value of text fields that were not last modified by user input.
Aside from button types, it generally doesn't make sense to perform text manipulation over arbitrary input
element values, especially for text field types such as passwords, URLs, emails, and numbers. However, some
webpages set thevalueof inputs to implementplaceholder-like behavior in text fields, and we need to be
compatible with this.
Tests: TextManipulation.StartTextManipulationExtractsValuesFromTextInputs
TextManipulation.CompleteTextManipulationInButtonsAndTextFields
- editing/TextManipulationController.cpp:
(WebCore::shouldExtractValueForTextManipulation):
Unfortunately, we need to check the type attribute here against "text", since inputs of type "date" and "time"
fall back to text fields on macOS, and we still want to avoid extracting values for these.
(WebCore::isAttributeForTextManipulation):
Pull the
valueattribute of this out into a separate method, above.
(WebCore::TextManipulationController::observeParagraphs):
(WebCore::TextManipulationController::replace):
Treat the text field value separately from other attributes by calling
HTMLInputElement::value()upon
extraction, andHTMLInputElement::setValue()upon replacement.
Tools:
Add a new test case (similar to the existing test
StartTextManipulationExtractsValuesFromButtonInputs) to
verify that we extract text from thevalueof inputs of type "text" and "search".
- TestWebKitAPI/Tests/WebKitCocoa/TextManipulation.mm:
(TestWebKitAPI::TEST):
- 1:57 PM Changeset in webkit [262514] by
-
- 4 edits in trunk/LayoutTests
REGRESSION: (r262456): [ Mac ] media/modern-media-controls/media-controller/media-controller-inline-to-fullscreen-to-pip-to-inline.html is timing out.
https://bugs.webkit.org/show_bug.cgi?id=212694
Reviewed by Jer Noble.
Enable the mock video presentation mode of the WebKitTestRunner in the test,
and only request a video element to change its video presentation mode after
the previous change is completed.
- media/modern-media-controls/media-controller/media-controller-inline-to-fullscreen-to-pip-to-inline-expected.txt:
- media/modern-media-controls/media-controller/media-controller-inline-to-fullscreen-to-pip-to-inline.html:
- platform/mac/TestExpectations:
- 1:23 PM Changeset in webkit [262513] by
-
- 23 edits2 copies in trunk/Source/JavaScriptCore
[Re-landing] Enhance DoesGC verification to print more useful info when verification fails.
https://bugs.webkit.org/show_bug.cgi?id=212680
Reviewed by Yusuke Susuki.
When DoesGC verification fails, the first step of debugging it would be to find
out what and which DFG node resulted in the failed verification. In pre-existing
code, all we get is an assertion failure.
This patch makes it so that the verifier will dump useful info. Here's an example:
Error: DoesGC failed @ D@34 DateGetInt32OrNaN in #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
[0] frame 0x7ffee8285660 {
name:
sourceURL:
isInlinedFrame: false
callee: 0x1135f6820
returnPC: 0x50ce61248ae6
callerFrame: 0x7ffee82856f0
rawLocationBits: 5 0x5
codeBlock: 0x1135bd1d0 #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
hasCodeOrigins: true
callSiteIndex: 5 of 13
jitCode: 0x113020200 start 0x50ce61214c60 end 0x50ce61219b00
line: 1
column: 60
EntryFrame: 0x7ffee8285860
}
[1] frame 0x7ffee82856f0 {
name:
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1135f65a0
returnPC: 0x50ce61227e99
callerFrame: 0x7ffee8285770
rawLocationBits: 4 0x4
codeBlock: 0x1135bd0a0 #BU6Zcd:[0x1135bd0a0->0x1135bc260->0x1135e5180, DFGFunctionCall, 112 (DidTryToEnterInLoop)]
hasCodeOrigins: true
callSiteIndex: 4 of 12
jitCode: 0x113004000 start 0x50ce61212c60 end 0x50ce61214960
line: 26
column: 22
EntryFrame: 0x7ffee8285860
}
[2] frame 0x7ffee8285770 {
name:
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1135f64e0
returnPC: 0x108058eb1
callerFrame: 0x7ffee82857e0
rawLocationBits: 1001 0x3e9
codeBlock: 0x1135bc130 #DAS9xe:[0x1135bc130->0x1135e5100, BaselineFunctionCall, 1149]
bc#1001 of 1149
line: 417
column: 38
EntryFrame: 0x7ffee8285860
}
[3] frame 0x7ffee82857e0 {
name: global code
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1130f97b8
returnPC: 0x108039043
callerFrame: 0x0
rawLocationBits: 23 0x17
codeBlock: 0x1135bc000 <global>#CukXvt:[0x1135bc000->0x1130cd768, LLIntGlobal, 81]
bc#23 of 81
line: 425
column: 3
EntryFrame: 0x7ffee8285860
}
ASSERTION FAILED: expectDoesGC()
The error message now comes with the node index, NodeType, codeBlock which this
failure was found in, and the JS call stack that led to the failure.
Changes made:
- Introduced a DoesGCCheck value that is used to encode some of the above data.
Previously, we only recorded whether doesGC() returns true or false for the
Node. Now, we record the nodeIndex and nodeOp as well.
Note that we also set DoesGC expectations for OSR exits. So, DoesGCCheck
includes Special cases for those.
- Added store64(TrustedImm64 imm, const void* address) emitters for X86_64 and ARM64. Also added a test for this new emitter in testmasm.
- CMakeLists.txt:
- JavaScriptCore.xcodeproj/project.pbxproj:
- Sources.txt:
- assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::store64):
- assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::store64):
- assembler/testmasm.cpp:
(JSC::testStore64Imm64AddressPointer):
(JSC::run):
- dfg/DFGDoesGCCheck.cpp: Copied from Source/JavaScriptCore/dfg/DFGDoesGCCheck.cpp.
- dfg/DFGDoesGCCheck.h: Copied from Source/JavaScriptCore/dfg/DFGDoesGCCheck.h.
- dfg/DFGGraph.cpp:
- dfg/DFGOSRExit.cpp:
(JSC::DFG::operationCompileOSRExit):
(JSC::DFG::OSRExit::compileExit):
- dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
- ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::operationCompileFTLOSRExit):
- heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::tryAllocateSlow):
(JSC::CompleteSubspace::reallocatePreciseAllocationNonVirtual):
- heap/CompleteSubspaceInlines.h:
(JSC::CompleteSubspace::allocateNonVirtual):
- heap/DeferGC.h:
(JSC::DeferGC::~DeferGC):
- heap/GCDeferralContextInlines.h:
(JSC::GCDeferralContext::~GCDeferralContext):
- heap/Heap.cpp:
(JSC::Heap::collectNow):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectIfNecessaryOrDefer):
- heap/Heap.h:
(JSC::Heap::addressOfDoesGC):
(JSC::Heap::setDoesGCExpectation):
(JSC::Heap::verifyCanGC):
(JSC::Heap::expectDoesGC const): Deleted.
(JSC::Heap::setExpectDoesGC): Deleted.
(JSC::Heap::addressOfExpectDoesGC): Deleted.
- heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::stopIfNecessary):
- heap/LocalAllocatorInlines.h:
(JSC::LocalAllocator::allocate):
- heap/PreciseAllocation.cpp:
(JSC::PreciseAllocation::tryCreate):
(JSC::PreciseAllocation::createForLowerTier):
- runtime/JSString.h:
(JSC::jsSingleCharacterString):
(JSC::JSString::toAtomString const):
(JSC::JSString::toExistingAtomString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
- runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
- 1:16 PM Changeset in webkit [262512] by
-
- 2 edits in trunk/LayoutTests
REGRESSION: [macOS WK2] Layout Test fast/mediastream/device-cha nge-event-2.html is a flaky timeout
https://bugs.webkit.org/show_bug.cgi?id=188924
Unreviewed test gardening.
- platform/mac-wk2/TestExpectations:
- 12:59 PM Changeset in webkit [262511] by
-
- 24 edits11 adds in trunk
Disallow responses when a response contains invalid header values
https://bugs.webkit.org/show_bug.cgi?id=184493
Patch by Rob Buis <rbuis@igalia.com> on 2020-06-03
Reviewed by Darin Adler.
LayoutTests/imported/w3c:
Update improved test results and import fetch/h1-parsing.
- web-platform-tests/fetch/api/basic/header-value-combining.any-expected.txt:
- web-platform-tests/fetch/api/basic/header-value-combining.any.worker-expected.txt:
- web-platform-tests/fetch/api/basic/header-value-null-byte.any-expected.txt:
- web-platform-tests/fetch/api/basic/header-value-null-byte.any.worker-expected.txt:
- web-platform-tests/fetch/h1-parsing/resources-with-0x00-in-header.window-expected.txt: Added.
- web-platform-tests/fetch/h1-parsing/resources-with-0x00-in-header.window.html: Added.
- web-platform-tests/fetch/h1-parsing/resources-with-0x00-in-header.window.js: Added.
(async_test.t.t.step_timeout):
- web-platform-tests/fetch/h1-parsing/resources/README.md: Added.
- web-platform-tests/fetch/h1-parsing/resources/blue-with-0x00-in-a-header.asis: Added.
- web-platform-tests/fetch/h1-parsing/resources/document-with-0x00-in-header.py: Added.
(main):
- web-platform-tests/fetch/h1-parsing/resources/script-with-0x00-in-header.py: Added.
(main):
- web-platform-tests/fetch/h1-parsing/resources/w3c-import.log: Added.
- web-platform-tests/fetch/h1-parsing/w3c-import.log: Added.
- web-platform-tests/xhr/headers-normalize-response-expected.txt:
Source/WebCore:
From the Fetch specification [1]:
"A value is a byte sequence that matches the following conditions:
"- Contains no 0x00 (NUL) or HTTP newline bytes."
[1] https://fetch.spec.whatwg.org/#concept-header-value
Tests: imported/w3c/web-platform-tests/fetch/h1-parsing/resources-with-0x00-in-header.window.html
imported/web-platform-tests/fetch/api/basic/header-value-combining.any.html
imported/web-platform-tests/fetch/api/basic/header-value-combining.any.worker.html
imported/web-platform-tests/fetch/api/basic/header-value-null-byte.any.html
imported/web-platform-tests/fetch/api/basic/header-value-null-byte.any.worker.html
imported/web-platform-tests/xhr/headers-normalize-response.htm
- Modules/fetch/FetchHeaders.cpp:
(WebCore::canWriteHeader):
(WebCore::appendToHeaderMap):
(WebCore::FetchHeaders::filterAndFill):
- loader/DocumentThreadableLoader.cpp:
(WebCore::DocumentThreadableLoader::loadRequest):
- loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::didReceiveResponse):
- platform/network/HTTPParsers.cpp:
(WebCore::isValidHTTPHeaderValue):
- platform/network/ResourceResponseBase.cpp:
(WebCore::ResourceResponseBase::containsInvalidHTTPHeaders const):
- platform/network/ResourceResponseBase.h:
LayoutTests:
Update improved test results.
- platform/glib/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any-expected.txt:
- platform/glib/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any.worker-expected.txt:
- platform/ios-12/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any-expected.txt:
- platform/ios-12/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any.worker-expected.txt:
- platform/ios/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any-expected.txt:
- platform/ios/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any.worker-expected.txt:
- platform/mac-mojave/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any-expected.txt:
- platform/mac-mojave/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any.worker-expected.txt:
- platform/mac/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any-expected.txt:
- platform/mac/imported/w3c/web-platform-tests/fetch/api/basic/header-value-combining.any.worker-expected.txt:
- 12:55 PM Changeset in webkit [262510] by
-
- 2 edits in trunk/Source/JavaScriptCore
DFGSSAConversionPhase.cpp needs to #include OperandsInlines.h.
https://bugs.webkit.org/show_bug.cgi?id=212687
Reviewed by Keith Miller.
Without this, strange build failures can happen with unified builds.
For example, the Windows build started failing due a linkage error in this file
when the patch from https://bugs.webkit.org/show_bug.cgi?id=212680 landed.
212680 introduced a new .cpp file, and that probably bumped DFGSSAConversionPhase.cpp
into another unified unit, thereby depriving it from seeing the OperandsInlines.h
#include'd by another .cpp.
- dfg/DFGSSAConversionPhase.cpp:
- 12:47 PM Changeset in webkit [262509] by
-
- 2 edits in trunk/Tools
[iOS] TestWTF.WTF_Lock.ContendedShortSection is consistently timing out on debug simulator builds
https://bugs.webkit.org/show_bug.cgi?id=211650
Reviewed by Saam Barati.
The prior change to disable this test for Debug actually enabled it
only for Debug IOS builds of any type, simulator or real HW.
This test has intermittently failed or timed out on Debug simulator
builds for for almost a year. We want to test Release builds as well as
hardware builds. Therefore we should disable Debug simulator builds,
and test all other variants.
- TestWebKitAPI/Tests/WTF/Lock.cpp:
- 12:45 PM Changeset in webkit [262508] by
-
- 2 edits in trunk/Source/WebKit
[iOS] Hide the PiP button in fullscreen mode if PiP is disabled in preferences
https://bugs.webkit.org/show_bug.cgi?id=212699
<rdar://problem/60391437>
Reviewed by Eric Carlson.
In r260474, we hid the PiP button in fullscreen when PiP was unsupported on the
current device; we must also hide the PiP button when clients have disabled PiP
via preferences.
- UIProcess/ios/fullscreen/WKFullScreenViewController.mm:
(-[WKFullScreenViewController videoControlsManagerDidChange]):
- 12:41 PM Changeset in webkit [262507] by
-
- 20 edits1 add in trunk
dataTransfer.types is empty when handling the "dragstart" event
https://bugs.webkit.org/show_bug.cgi?id=212685
<rdar://problem/61368402>
Reviewed by Andy Estes.
Source/WebCore:
Implements several currently stubbed methods on StaticPasteboard, so that the DataTransfer provided to the page
on the "dragstart" event contains the DOM-exposed data types that will be written to the system pasteboard. This
includes "text/html", "text/plain", and "text/uri-list".
Tests: DragAndDropTests.DataTransferTypesOnDragStartForTextSelection
DragAndDropTests.DataTransferTypesOnDragStartForImage
DragAndDropTests.DataTransferTypesOnDragStartForLink
...as well as several existing tests in DragAndDropTestsIOS.mm that attempt to set pasteboard data during the
dragstart event:
DragAndDropTests.DataTransferSanitizeHTML
DragAndDropTests.DataTransferSetDataCannotWritePlatformTypes
DragAndDropTests.DataTransferSetDataInvalidURL
DragAndDropTests.DataTransferSetDataUnescapedURL
DragAndDropTests.DataTransferSetDataValidURL
- dom/DataTransfer.cpp:
(WebCore::DataTransfer::commitToPasteboard):
Only commit data to the native pasteboard if the page actually tried to write or modify the data. This allows us
to preserve existing behavior by allowing DragController to write dragged data to the pasteboard normally in the
case where the page didn't specify any custom data. In the case where the page does specify custom data, we will
write this custom data *in addition* to any default data that was written to the static pasteboard. While this
is a departure from our current behavior (which is to treat the pasteboard as a blank slate that contains only
whatever custom data was provided by the page), it matches behavior in both Chrome and Firefox, and is likely
more compatible with webpages that don't have UA-specific logic targeting WebKit.
- editing/cocoa/EditorCocoa.mm:
(WebCore::Editor::writeSelectionToPasteboard):
Avoid calling into the injected bundle (as well as writing a few particular non-web-exposed types, such as web
archive data) in the case where we're writing to a static pasteboard (there's no point in doing this for the
static pasteboard, and in the worst case, it could confuse some internal clients).
- editing/ios/EditorIOS.mm:
(WebCore::Editor::writeImageToPasteboard): Ditto.
- editing/mac/EditorMac.mm:
(WebCore::Editor::writeImageToPasteboard):
Ditto. But additionally, introduce a markup string to PasteboardImage, so that we will expose the "text/html"
type when starting a drag on an image element.
- page/DragController.cpp:
(WebCore::DragController::startDrag):
Only attempt to call into
Pasteboard::writeTrustworthyWebURLsPboardTypein the case where the pasteboard
supports this type (i.e. on macOS). This fixes an existing assertion that was hit by my new API test, which
attempts to override the contents of the pasteboard with custom data while starting a drag on a link.
- page/EventHandler.cpp:
(WebCore::EventHandler::handleDrag):
Since the StaticPasteboard contains data before the page has written anything, don't use
Pasteboard::hasData()
to determine whether there's custom data; instead, use the newhasNonDefaultData()method on
StaticPasteboard(see below).
- platform/Pasteboard.cpp:
(WebCore::Pasteboard::canWriteTrustworthyWebURLsPboardType):
On non-macOS ports, return false.
- platform/Pasteboard.h:
- platform/StaticPasteboard.cpp:
(WebCore::StaticPasteboard::hasNonDefaultData const):
Keep track of whether the page attempted to stage any custom data during "dragstart" by maintaining the set of
types written by the page, via calls towriteString()and similar. I'm using a set of types here instead of a
simpleboolflag to ensure correctness in the case where the page adds a type, and then later removes that
same custom type, such that there is no longer non-default data.
(WebCore::StaticPasteboard::writeString):
(WebCore::StaticPasteboard::writeData):
(WebCore::StaticPasteboard::writeStringInCustomData):
(WebCore::StaticPasteboard::clear):
See above.
(WebCore::StaticPasteboard::writeMarkup):
(WebCore::StaticPasteboard::writePlainText):
(WebCore::StaticPasteboard::write):
Implement these methods by writing to the
PasteboardCustomData. These methods are invoked by our own code
rather than the bindings, and should only be used to stage default data types when starting a drag.
- platform/StaticPasteboard.h:
- platform/mac/PasteboardMac.mm:
(WebCore::Pasteboard::write):
(WebCore::Pasteboard::canWriteTrustworthyWebURLsPboardType):
Tools:
Adds new API tests and test infrastructure to verify that DataTransfer types and data are accessible during
the "dragstart" event. See below for more details.
- TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
- TestWebKitAPI/Tests/WebKitCocoa/DragAndDropTests.mm:
(-[TestWKWebView selectElementWithID:]):
(-[DragAndDropSimulator dragFromElementWithID:to:]):
Add a few (very specialized) helper methods to assist with simulating drags over the various elements in the new
drag and drop test harness page below (dragstart-data.html).
(runDragStartDataTestCase):
Test the following scenarios (split between three API tests) by dumping the resulting DataTransfer types and
their data strings, and observing the results:
- Dragging a normal text selection.
- Dragging a normal text selection, and then adding a URL string.
- Dragging a normal text selection, and then adding a custom pasteboard type.
- Dragging a normal text selection, but then replacing the data with just a URL string.
- Dragging a normal text selection, but then replacing the data with just a custom data type.
- Dragging an image element.
- Dragging an image element, and then overriding the plain text data.
- Dragging a link (anchor element).
- Dragging a link, and then adding a custom type.
- TestWebKitAPI/Tests/WebKitCocoa/dragstart-data.html: Added.
Add a new test harness to help test DataTransfer types when starting a drag. This test page can also be used as
a manual test harness, by simply opening the test page, starting drags on the various elements and observing the
output in the textarea.
- TestWebKitAPI/Tests/WebKitCocoa/dump-datatransfer-types.html:
Tweak this test page to replace the DataTransfer with custom data (rather than simply append it) by calling
DataTransfer.clearData()prior to writing the custom types.
- TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm:
- TestWebKitAPI/cocoa/TestWKWebView.h:
- TestWebKitAPI/cocoa/TestWKWebView.mm:
(-[TestWKWebViewHostWindow initWithWebView:contentRect:styleMask:backing:defer:]):
Add a
__weakreference on TestWKWebViewHostWindow back to the TestWKWebView, so that we can consult
-eventTimestampwhen synthesizing mouse events on macOS during API tests.
(-[TestWKWebViewHostWindow _mouseDownAtPoint:simulatePressure:clickCount:]):
(-[TestWKWebViewHostWindow _mouseUpAtPoint:clickCount:]):
(-[TestWKWebViewHostWindow initWithWebView:frame:]):
(-[TestWKWebView _setUpTestWindow:]):
(-[TestWKWebView setEventTimestampOffset:]):
(-[TestWKWebView eventTimestamp]):
Add a mechanism to offset synthetic event timestamps by a given time interval (i.e. the event timestamp offset).
(-[TestWKWebView mouseMoveToPoint:withFlags:]):
(-[TestWKWebView _mouseEventWithType:atLocation:]):
(-[TestWKWebView typeCharacter:]):
- TestWebKitAPI/mac/DragAndDropSimulatorMac.mm:
(-[DragAndDropSimulator runFrom:to:]):
While simulating drag and drop on macOS, use
-setEventTimestampOffset:to "leap forward" in time, so that the
150 millisecond delay when dragging a text selection doesn't prevent drags from beginning.
- 12:25 PM Changeset in webkit [262506] by
-
- 3 edits in trunk/Source/WebCore
Crash with uncaught exception: * -[AVSampleBufferAudioRenderer enqueueSampleBuffer:] Sample buffer has media type 'vide' instead of 'soun'
https://bugs.webkit.org/show_bug.cgi?id=212646
<rdar://problem/63040834>
Reviewed by Eric Carlson.
Protect against the possibility of AVStreamDataParser generating non-video or -audio samples in an otherwise
video- or audio-track. Check the format description attached to the sample before appending, and ASSERT in
debug builds and ERROR_LOG in release builds, as this is an exceptional condition.
- platform/graphics/FourCC.h:
(WTF::LogArgument<WebCore::FourCC>::toString):
- platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
(WebCore::SourceBufferPrivateAVFObjC::enqueueSample):
- 12:13 PM Changeset in webkit [262505] by
-
- 6 edits in trunk/Source
Any active sqlite transactions for the ITP database should be aborted when the network process suspends.
https://bugs.webkit.org/show_bug.cgi?id=212608
<rdar://problem/60540768>
Reviewed by Chris Dumez.
Source/WebCore:
Add WEBCORE_EXPORT macro to use interrupt() function in
ResourceLoadStatisticsDatabaseStore.
- platform/sql/SQLiteDatabase.h:
Source/WebKit:
Calls to WebResourceLoadStatisticsStore::suspend() should abort any
active SQLite transactions. Unfinished transactions will hold the lock
of a database file and could cause the network process to crash when
suspending.
- NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp:
(WebKit::ResourceLoadStatisticsDatabaseStore::ResourceLoadStatisticsDatabaseStore):
(WebKit::ResourceLoadStatisticsDatabaseStore::~ResourceLoadStatisticsDatabaseStore):
Store all ResourceLoadStatisticsDatabaseStore instances in a static
HashSet so existing transactions can be aborted when the process is
preparing to suspend.
(WebKit::ResourceLoadStatisticsDatabaseStore::interrupt):
- NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.h:
- NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
(WebKit::WebResourceLoadStatisticsStore::suspend):
- 12:13 PM Changeset in webkit [262504] by
-
- 8 edits in trunk/Source
Versioning.
- 12:10 PM Changeset in webkit [262503] by
-
- 1 copy in tags/Safari-610.1.16
Tag Safari-610.1.16.
- 12:09 PM Changeset in webkit [262502] by
-
- 8 edits in branches/safari-610.1.16-branch/Source
Versioning.
- 12:08 PM Changeset in webkit [262501] by
-
- 1 copy in branches/safari-610.1.16-branch
New branch.
- 12:07 PM Changeset in webkit [262500] by
-
- 6 edits2 adds in trunk
AX: SVG text node with content is described as "empty group" even if it's not empty
https://bugs.webkit.org/show_bug.cgi?id=210315
Reviewed by Darin Adler.
Source/WebCore:
Test: accessibility/svg-text.html
SVGText elements are conveyed as AXGroups and cannot have a description
or help property, but instead the content of the element is exposed as
static text.
- accessibility/AccessibilitySVGElement.cpp:
(WebCore::AccessibilitySVGElement::accessibilityDescription const):
(WebCore::AccessibilitySVGElement::helpText const):
- accessibility/AccessibilitySVGElement.h:
LayoutTests:
- accessibility/svg-text-expected.txt: Added.
- accessibility/svg-text.html: Added.
- accessibility/w3c-svg-name-calculation.html: Expected name for an SVG
text element should be "". Its text content is exposed as a child static text accessibility object.
- platform/mac/accessibility/w3c-svg-name-calculation-expected.txt:
- 12:04 PM Changeset in webkit [262499] by
-
- 4 edits in trunk
Text manipulation sometimes fails to replace text in attributes
https://bugs.webkit.org/show_bug.cgi?id=212701
Reviewed by Wenson Hsieh.
Source/WebCore:
Concatenate replacement tokens of same identifier for attribute like we do for title and option element in
r260393.
Covered by test: TextManipulation.CompleteTextManipulationShouldReplaceTextContentWithMultipleTokens
- editing/TextManipulationController.cpp:
(WebCore::TextManipulationController::replace):
Tools:
Modify TextManipulation.CompleteTextManipulationShouldReplaceTextContentWithMultipleTokens to cover text
manipulation for attributes.
- TestWebKitAPI/Tests/WebKitCocoa/TextManipulation.mm:
(TestWebKitAPI::TEST):
- 11:48 AM Changeset in webkit [262498] by
-
- 3 edits in trunk
[ macOS ] REGRESSION(r262366): webgl/1.0.3/conformance/canvas/buffer-offscreen-test.html & webgl/2.0.0/conformance/canvas/buffer-offscreen-test.html are constant failures
https://bugs.webkit.org/show_bug.cgi?id=212594
<rdar://problem/63828783>
Reviewed by Eric Carlson.
The change in r262366 split the OpenGL work to prepare a canvas for rendering from the actual painting
(or compositing in this case). Canvas elements were being "prepared" at the end of the HTML run loop
if they'd done anything that would change pixels. The problem is that canvas elements that are not in
the document body are never composited, and thus should never be prepared, otherwise they will clear
their drawing buffer. In other words, a canvas in this state must keep the same buffer through
each rendering frame.
The solution is to check if the canvas is in the tree scope at the time we consider preparing
it for display.
- dom/Document.cpp:
(WebCore::Document::prepareCanvasesForDisplayIfNeeded):
- 11:40 AM Changeset in webkit [262497] by
-
- 3 edits in trunk
WebProcessPool::notifyPreferencesChanged() is unsafely called on a background thread
https://bugs.webkit.org/show_bug.cgi?id=212697
<rdar://problem/63876652>
Reviewed by Per Arne Vollan.
Make sure we dispatch to the main thread in [WKPreferenceObserver preferenceDidChange] before
we iterate over the process pools and call WebProcessPool::notifyPreferencesChanged() on each
one.
- UIProcess/Cocoa/PreferenceObserver.mm:
(-[WKPreferenceObserver preferenceDidChange:key:encodedValue:]):
- 11:39 AM Changeset in webkit [262496] by
-
- 2 edits in trunk/Source/WebKit
[iOS] Reduce sandbox logging by permitting necessary sysctl
https://bugs.webkit.org/show_bug.cgi?id=212710
<rdar://problem/63900239>
Reviewed by Per Arne Vollan.
Telemetry indicates that we need to access "sysctl.name2oid" in the
Network process during error handling for HTTP connections. Allow this
access and avoid generating unnecessary logging for this case.
- Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb:
- 11:07 AM Changeset in webkit [262495] by
-
- 7 edits2 adds in trunk
Storage Access API: Add setting for per-page storage access scope
https://bugs.webkit.org/show_bug.cgi?id=212682
<rdar://problem/63904824>
Reviewed by Brent Fulgham.
Source/WebCore:
This is a follow-up patch to https://bugs.webkit.org/show_bug.cgi?id=212114,
adding an off-by-default setting and a test case for per-page storage access.
Test: http/tests/storageAccess/request-and-grant-access-with-per-page-scope-access-from-another-frame.html
- dom/DocumentStorageAccess.cpp:
(WebCore::DocumentStorageAccess::requestStorageAccess):
- page/Settings.yaml:
- testing/InternalSettings.cpp:
(WebCore::InternalSettings::setStorageAccessAPIPerPageScopeEnabled):
- testing/InternalSettings.h:
- testing/InternalSettings.idl:
LayoutTests:
- http/tests/storageAccess/request-and-grant-access-with-per-page-scope-access-from-another-frame-expected.txt: Added.
- http/tests/storageAccess/request-and-grant-access-with-per-page-scope-access-from-another-frame.html: Added.
- 10:46 AM Changeset in webkit [262494] by
-
- 3 edits in trunk/Tools
[WPE] lint-test-expectations doesn't work when platform is WPE
https://bugs.webkit.org/show_bug.cgi?id=212700
Reviewed by Carlos Alberto Lopez Perez.
When passing arguments '--wpe' or '--platform=wpe*',
lint-test-expectations does nothing for WPE, despite currently
there are many lint errors in WPE's TestExpectations file.
As a side-effect of this patch, now `Tools/Scripts/webkit-path
rebaseline` lists the WPE Release and Debug bots.
- Scripts/webkitpy/port/builders.py: Add WPE to the list of
exact_matches and fuzzy_matches.
- Scripts/webkitpy/tool/commands/rebaseline_unittest.py:
- 10:32 AM Changeset in webkit [262493] by
-
- 2 edits in trunk/Tools
Allow using web processes for service workers even though they loaded about URLs (Follow-up fix)
https://bugs.webkit.org/show_bug.cgi?id=212464
Unreviewed build fix.
- TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm: didFinishNavigation is now used unconditionally.
- 10:31 AM Changeset in webkit [262492] by
-
- 12 edits in trunk/Source/JavaScriptCore
Fix non-unified --jsc-only build.
https://bugs.webkit.org/show_bug.cgi?id=212707
Reviewed by Yusuke Suzuki.
These files need JSGlobalObjectInlines.h. But rather than adding yet another
#include, we'll just remove many individual ones and just #include JSCInlines.h
instead.
- wasm/js/JSToWasmICCallee.cpp:
- wasm/js/WebAssemblyCompileErrorConstructor.cpp:
- wasm/js/WebAssemblyCompileErrorPrototype.cpp:
- wasm/js/WebAssemblyGlobalPrototype.cpp:
- wasm/js/WebAssemblyInstanceConstructor.cpp:
- wasm/js/WebAssemblyInstancePrototype.cpp:
- wasm/js/WebAssemblyLinkErrorConstructor.cpp:
- wasm/js/WebAssemblyLinkErrorPrototype.cpp:
- wasm/js/WebAssemblyModulePrototype.cpp:
- wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
- wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
- 9:59 AM Changeset in webkit [262491] by
-
- 2 edits in trunk/LayoutTests
[WPE] Gardening, lint WPE test expectations
https://bugs.webkit.org/show_bug.cgi?id=212705
Unreviewed gardening.
- platform/wpe/TestExpectations:
- 9:13 AM Changeset in webkit [262490] by
-
- 2 edits in trunk/Source/WebKit
Add more logging related to service worker fetch event handling
https://bugs.webkit.org/show_bug.cgi?id=212632
<rdar://problem/63913271>
Unreviewed.
Build fix.
- WebProcess/Storage/WebServiceWorkerFetchTaskClient.cpp:
(WebKit::WebServiceWorkerFetchTaskClient::continueDidReceiveResponse):
- 9:00 AM Changeset in webkit [262489] by
-
- 2 edits in trunk/LayoutTests
REGRESSION: (r262432): [ iOS wk2 ] imported/w3c/web-platform-tests/service-workers/service-worker/fetch-request-no-freshness-headers.https.html is flaky failing.
https://bugs.webkit.org/show_bug.cgi?id=212696
Unreviewed test gardening.
- platform/ios-wk2/TestExpectations:
- 8:44 AM Changeset in webkit [262488] by
-
- 2 edits in trunk/LayoutTests
REGRESSION: (r262456): [ Mac ] media/modern-media-controls/media-controller/media-controller-inline-to-fullscreen-to-pip-to-inline.html is timing out.
https://bugs.webkit.org/show_bug.cgi?id=212694
Unreviewed test gardening.
- platform/mac/TestExpectations:
- 8:37 AM Changeset in webkit [262487] by
-
- 7 edits in trunk/Source/WebKit
Pass WebPageProxyIdentifier to PreconnectTask
https://bugs.webkit.org/show_bug.cgi?id=212648
Patch by Alex Christensen <achristensen@webkit.org> on 2020-06-03
Reviewed by Chris Dumez.
Otherwise, AuthenticationManager::didReceiveAuthenticationChallenge sometimes returned early because there was no pageID.
Observed connecting to real websites from my home wifi. Unable to test using local servers because connecting happens too fast.
- NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::preconnectTo):
- NetworkProcess/NetworkProcess.h:
- NetworkProcess/NetworkProcess.messages.in:
- UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::preconnectTo):
- UIProcess/Network/NetworkProcessProxy.h:
- UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::preconnectTo):
- 7:29 AM Changeset in webkit [262486] by
-
- 23 edits in trunk/Source
Make generated C++ code use modern C++
https://bugs.webkit.org/show_bug.cgi?id=190714
Patch by Rob Buis <rbuis@igalia.com> on 2020-06-03
Reviewed by Jonathan Bedard.
Source/JavaScriptCore:
Update inspector protocol generator and rebaseline the tests.
- inspector/scripts/codegen/cpp_generator_templates.py:
- inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
- inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
- inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
- inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
- inspector/scripts/tests/expected/enum-values.json-result:
- inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
- inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
- inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
- inspector/scripts/tests/expected/type-declaration-array-type.json-result:
- inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
- inspector/scripts/tests/expected/type-declaration-object-type.json-result:
- inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
- yarr/generateYarrUnicodePropertyTables.py:
Source/WebCore:
Replace typedef usage by alias-declaration.
No new tests. No change in behavior.
- css/makeprop.pl:
- dom/make_names.pl:
(printHeaderHead):
(printInit):
(printTypeHelpersHeaderFile):
(printFactoryCppFile):
(printFactoryHeaderFile):
(printWrapperFactoryCppFile):
(printWrapperFactoryHeaderFile):
Source/WebKit:
Replace typedef usage by alias-declaration.
- Scripts/test-legacyMessages.h:
- Scripts/test-superclassMessages.h:
- Scripts/testMessages.h:
- Scripts/webkit/messages.py:
- 6:48 AM Changeset in webkit [262485] by
-
- 2 edits in trunk/Source/WebKit
[GTK4] WTR: Forward key events to the active popup menu
https://bugs.webkit.org/show_bug.cgi?id=212690
Reviewed by Adrian Perez de Castro.
I forgot to remove the ifdefs when added support for popup menus in r262414.
- UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseSynthesizeKeyEvent):
- 6:46 AM Changeset in webkit [262484] by
-
- 6 edits in trunk/Source/WebKit
[GTK4] Fix input methods
https://bugs.webkit.org/show_bug.cgi?id=212317
Reviewed by Adrian Perez de Castro.
Stop using GdkEvent to synthesize compositing events, add a specific NativeWebKeyboardEvent constructor for them.
- Shared/NativeWebKeyboardEvent.h:
- Shared/gtk/NativeWebKeyboardEventGtk.cpp:
(WebKit::NativeWebKeyboardEvent::NativeWebKeyboardEvent):
- UIProcess/API/gtk/WebKitInputMethodContextImplGtk.cpp:
(webkitInputMethodContextImplGtkSetClientWidget):
(webkitInputMethodContextImplGtkSetClientWindow): Deleted.
- UIProcess/API/gtk/WebKitInputMethodContextImplGtk.h:
- UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseRealize):
(webkitWebViewBaseUnrealize):
(webkitWebViewBaseKeyPressEvent):
(webkitWebViewBaseKeyReleaseEvent):
(webkitWebViewBaseFocusEnter):
(webkitWebViewBaseFocusLeave):
(webkitWebViewBaseKeyPressed):
(webkitWebViewBaseKeyReleased):
(toplevelWindowIsActiveChanged):
(webkitWebViewBaseSynthesizeCompositionKeyPress):
- 3:08 AM Changeset in webkit [262483] by
-
- 2 edits in trunk/Source/WebKit
[GTK4] Implement file chooser
https://bugs.webkit.org/show_bug.cgi?id=212322
Patch by Santosh Mahto <santosh.mahto@collabora.com> on 2020-06-03
Reviewed by Carlos Garcia Campos.
Port FileChooser to gtk4, Now FileChooser uses undeprecated api's.
Covered by existing tests.
- UIProcess/API/gtk/WebKitWebViewGtk.cpp:
(fileChooserDialogResponseCallback):
(webkitWebViewRunFileChooser):
- 2:12 AM Changeset in webkit [262482] by
-
- 3 edits in trunk/Source/WebKit
[GTK4] Implement emoji chooser
https://bugs.webkit.org/show_bug.cgi?id=212330
Reviewed by Adrian Perez de Castro.
GtkEmojiChooser is public API in GTK4, so just use that instead of our own.
- UIProcess/API/gtk/WebKitEmojiChooser.cpp:
(emojiActivated): Close the popover before emitting emoji-picked for consistency with GTK.
- UIProcess/API/gtk/WebKitWebViewBase.cpp:
(_WebKitWebViewBasePrivate::_WebKitWebViewBasePrivate):
(_WebKitWebViewBasePrivate::releaseEmojiChooserTimerFired):
(webkitWebViewBaseDispose):
(emojiChooserClosed):
(webkitWebViewBaseShowEmojiChooser):
- 12:31 AM Changeset in webkit [262481] by
-
- 4 edits in trunk
[css-grid] Dynamically setting "position: absolute" in a grid item doesn't trigger a relayout of that element
https://bugs.webkit.org/show_bug.cgi?id=191465
Reviewed by Manuel Rego Casasnovas.
Source/WebCore:
From Blink r484620 by Sergio Villar <svillar@igalia.com>
Containing block overrides not cleared for position:absolute
Whenever a position:absolute block gets a new containing block the
previously set containing block overrides are not cleared. This causes the
block not to be properly layout for its new containing block (for example
when using relative sizes).
In particular this affects grid items which always get a containing block
override size (which represent the grid areas) in case their
containing block switches from the grid container to a grid ancestor.
No new tests, as this change is covered by current web platform tests.
- rendering/RenderBlock.cpp:
(WebCore::RenderBlock::insertPositionedObject): Clear the containing block's override width and height.
LayoutTests:
Several tests pass now thanks to this change.
- TestExpectations: Removed failure expectations, since now these tests pass now.
- absolute-positioning-changing-containing-block-001.html
- grid-item-absolute-positioning-dynamic-001.html
- 12:28 AM Changeset in webkit [262480] by
-
- 5 edits in trunk/Source
Add more logging related to service worker fetch event handling
https://bugs.webkit.org/show_bug.cgi?id=212632
Reviewed by Chris Dumez.
Source/WebCore:
Add logging related to creating/canceling/deleting fetch event handler related client.
No change of behavior.
- workers/service/context/ServiceWorkerThreadProxy.cpp:
(WebCore::ServiceWorkerThreadProxy::startFetch):
(WebCore::ServiceWorkerThreadProxy::cancelFetch):
(WebCore::ServiceWorkerThreadProxy::removeFetch):
Source/WebKit:
Add logging to identify the page ID and frame ID used by a service worker.
Add logging to identify what is happening in the case of a response being buffered for navigation purposes.
- WebProcess/Storage/WebSWContextManagerConnection.cpp:
(WebKit::ServiceWorkerFrameLoaderClient::ServiceWorkerFrameLoaderClient):
(WebKit::WebSWContextManagerConnection::installServiceWorker):
(WebKit::WebSWContextManagerConnection::continueDidReceiveFetchResponse):
- WebProcess/Storage/WebServiceWorkerFetchTaskClient.cpp:
(WebKit::WebServiceWorkerFetchTaskClient::didFail):
(WebKit::WebServiceWorkerFetchTaskClient::didFinish):
(WebKit::WebServiceWorkerFetchTaskClient::continueDidReceiveResponse):
Jun 2, 2020:
- 11:53 PM Changeset in webkit [262479] by
-
- 14 edits in trunk
ASSERTION FAILED: isCell() under WebCore::JSDOMConstructor seen with webaudio/the-audio-api/the-audiocontext-interface/audiocontextoptions.html
https://bugs.webkit.org/show_bug.cgi?id=212650
Reviewed by Mark Lam.
Source/WebCore:
Some DOM constructor can return jsNull. For example, AudioContext constructor can return jsNull when it exceeds # of hardware audio contexts.
However CodeGeneratorJS assumes that DOM constructor always returns an object, or throws an exception.
This patch adds object check after DOM constructor call to handle the jsNull case while it does not change the existing semantics.
- bindings/scripts/CodeGeneratorJS.pm:
(GenerateConstructorDefinition):
LayoutTests:
- platform/ios/TestExpectations:
- platform/mac/TestExpectations:
- 11:25 PM Changeset in webkit [262478] by
-
- 23 edits2 deletes in trunk/Source/JavaScriptCore
Rolling out r262475 to unbreak Windows bot.
https://bugs.webkit.org/show_bug.cgi?id=212680
Not reviewed.
- CMakeLists.txt:
- JavaScriptCore.xcodeproj/project.pbxproj:
- Sources.txt:
- assembler/MacroAssemblerARM64.h:
- assembler/MacroAssemblerX86_64.h:
- assembler/testmasm.cpp:
(JSC::testCountTrailingZeros64WithoutNullCheck):
(JSC::run):
(JSC::testStore64Imm64AddressPointer): Deleted.
- dfg/DFGDoesGCCheck.cpp: Removed.
- dfg/DFGDoesGCCheck.h: Removed.
- dfg/DFGGraph.cpp:
- dfg/DFGOSRExit.cpp:
(JSC::DFG::operationCompileOSRExit):
(JSC::DFG::OSRExit::compileExit):
- dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
- ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::operationCompileFTLOSRExit):
- heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::tryAllocateSlow):
(JSC::CompleteSubspace::reallocatePreciseAllocationNonVirtual):
- heap/CompleteSubspaceInlines.h:
(JSC::CompleteSubspace::allocateNonVirtual):
- heap/DeferGC.h:
(JSC::DeferGC::~DeferGC):
- heap/GCDeferralContextInlines.h:
(JSC::GCDeferralContext::~GCDeferralContext):
- heap/Heap.cpp:
(JSC::Heap::collectNow):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectIfNecessaryOrDefer):
- heap/Heap.h:
(JSC::Heap::expectDoesGC const):
(JSC::Heap::setExpectDoesGC):
(JSC::Heap::addressOfExpectDoesGC):
(JSC::Heap::addressOfDoesGC): Deleted.
(JSC::Heap::setDoesGCExpectation): Deleted.
(JSC::Heap::verifyCanGC): Deleted.
- heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::stopIfNecessary):
- heap/LocalAllocatorInlines.h:
(JSC::LocalAllocator::allocate):
- heap/PreciseAllocation.cpp:
(JSC::PreciseAllocation::tryCreate):
(JSC::PreciseAllocation::createForLowerTier):
- runtime/JSString.h:
(JSC::jsSingleCharacterString):
(JSC::JSString::toAtomString const):
(JSC::JSString::toExistingAtomString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
- runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
- 10:29 PM Changeset in webkit [262477] by
-
- 4 edits in trunk
[iOS] WKProcessAssertionBackgroundTaskManager incorrectly ignores expiration notifications for daemons
https://bugs.webkit.org/show_bug.cgi?id=212619
Reviewed by Alex Christensen.
WKProcessAssertionBackgroundTaskManager was incorrectly ignoring process assertion expiration notifications
for daemons, because it was relying on visibility to make decisions. For daemons (or ViewServices), we would
not get application visibility notifications and would therefore always assume the app is visible.
As a result, _handleBackgroundTaskExpiration would think it received an outdated expiration notification for
a visible app and would simply re-take the assertion right away.
To address the issue, we now rely on a RunningBoard API that lets us know if the suspension timer has been
started or not (and how much remains on the timer). If the suspension timer is not active when get receive
the expiration notification, we know it is an outdated notification and we ignore it (release and re-take
assertion right away). This can happen if we did not have time to process the expiration notification before
suspended and thus only get it upon resuming. It can also happen if the user re-activates the app right after
the expiration notice has been sent.
- Platform/spi/ios/RunningBoardServicesSPI.h:
- UIProcess/ios/ProcessAssertionIOS.mm:
(processHasActiveRunTimeLimitation):
(-[WKProcessAssertionBackgroundTaskManager init]):
(-[WKProcessAssertionBackgroundTaskManager _updateBackgroundTask]):
(-[WKProcessAssertionBackgroundTaskManager _handleBackgroundTaskExpiration]):
(-[WKProcessAssertionBackgroundTaskManager _handleBackgroundTaskExpirationOnMainThread]):
(-[WKProcessAssertionBackgroundTaskManager _releaseBackgroundTask]):
- 9:54 PM Changeset in webkit [262476] by
-
- 4 edits2 adds in trunk
EventRegion::translate() needs to offset the wheel event regions
https://bugs.webkit.org/show_bug.cgi?id=212683
Reviewed by Zalan Bujtas.
Source/WebCore:
EventRegion::translate() failed to offset the wheel event regions, which resulted
in wrong reasons for GraphicsLayers with a non-zero offsetFromRenderer.
Test: fast/scrolling/mac/wheel-event-listener-region-layer-offset.html
- rendering/EventRegion.cpp:
(WebCore::EventRegion::translate):
LayoutTests:
- fast/scrolling/mac/wheel-event-listener-region-layer-offset-expected.txt: Added.
- fast/scrolling/mac/wheel-event-listener-region-layer-offset.html: Added.
- 9:47 PM Changeset in webkit [262475] by
-
- 23 edits2 adds in trunk/Source/JavaScriptCore
Enhance DoesGC verification to print more useful info when verification fails.
https://bugs.webkit.org/show_bug.cgi?id=212680
Reviewed by Yusuke Suzuki.
When DoesGC verification fails, the first step of debugging it would be to find
out what and which DFG node resulted in the failed verification. In pre-existing
code, all we get is an assertion failure.
This patch makes it so that the verifier will dump useful info. Here's an example:
Error: DoesGC failed @ D@34 DateGetInt32OrNaN in #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
[0] frame 0x7ffee8285660 {
name:
sourceURL:
isInlinedFrame: false
callee: 0x1135f6820
returnPC: 0x50ce61248ae6
callerFrame: 0x7ffee82856f0
rawLocationBits: 5 0x5
codeBlock: 0x1135bd1d0 #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
hasCodeOrigins: true
callSiteIndex: 5 of 13
jitCode: 0x113020200 start 0x50ce61214c60 end 0x50ce61219b00
line: 1
column: 60
EntryFrame: 0x7ffee8285860
}
[1] frame 0x7ffee82856f0 {
name:
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1135f65a0
returnPC: 0x50ce61227e99
callerFrame: 0x7ffee8285770
rawLocationBits: 4 0x4
codeBlock: 0x1135bd0a0 #BU6Zcd:[0x1135bd0a0->0x1135bc260->0x1135e5180, DFGFunctionCall, 112 (DidTryToEnterInLoop)]
hasCodeOrigins: true
callSiteIndex: 4 of 12
jitCode: 0x113004000 start 0x50ce61212c60 end 0x50ce61214960
line: 26
column: 22
EntryFrame: 0x7ffee8285860
}
[2] frame 0x7ffee8285770 {
name:
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1135f64e0
returnPC: 0x108058eb1
callerFrame: 0x7ffee82857e0
rawLocationBits: 1001 0x3e9
codeBlock: 0x1135bc130 #DAS9xe:[0x1135bc130->0x1135e5100, BaselineFunctionCall, 1149]
bc#1001 of 1149
line: 417
column: 38
EntryFrame: 0x7ffee8285860
}
[3] frame 0x7ffee82857e0 {
name: global code
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1130f97b8
returnPC: 0x108039043
callerFrame: 0x0
rawLocationBits: 23 0x17
codeBlock: 0x1135bc000 <global>#CukXvt:[0x1135bc000->0x1130cd768, LLIntGlobal, 81]
bc#23 of 81
line: 425
column: 3
EntryFrame: 0x7ffee8285860
}
ASSERTION FAILED: expectDoesGC()
The error message now comes with the node index, NodeType, codeBlock which this
failure was found in, and the JS call stack that led to the failure.
Changes made:
- Introduced a DoesGCCheck value that is used to encode some of the above data.
Previously, we only recorded whether doesGC() returns true or false for the
Node. Now, we record the nodeIndex and nodeOp as well.
Note that we also set DoesGC expectations for OSR exits. So, DoesGCCheck
includes Special cases for those.
- Added store64(TrustedImm64 imm, const void* address) emitters for X86_64 and ARM64. Also added a test for this new emitter in testmasm.
- CMakeLists.txt:
- JavaScriptCore.xcodeproj/project.pbxproj:
- Sources.txt:
- assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::store64):
- assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::store64):
- assembler/testmasm.cpp:
(JSC::testStore64Imm64AddressPointer):
(JSC::run):
- dfg/DFGDoesGCCheck.cpp: Added.
(JSC::DFG::DoesGCCheck::verifyCanGC):
- dfg/DFGDoesGCCheck.h: Added.
(JSC::DFG::DoesGCCheck::DoesGCCheck):
(JSC::DFG::DoesGCCheck::encode):
(JSC::DFG::DoesGCCheck::set):
(JSC::DFG::DoesGCCheck::expectDoesGC):
(JSC::DFG::DoesGCCheck::special):
(JSC::DFG::DoesGCCheck::nodeIndex):
(JSC::DFG::DoesGCCheck::nodeOp):
(JSC::DFG::DoesGCCheck::isSpecial):
(JSC::DFG::DoesGCCheck::specialIndex):
(JSC::DFG::DoesGCCheck::bits):
- dfg/DFGGraph.cpp:
- dfg/DFGOSRExit.cpp:
(JSC::DFG::operationCompileOSRExit):
(JSC::DFG::OSRExit::compileExit):
- dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
- ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::operationCompileFTLOSRExit):
- heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::tryAllocateSlow):
(JSC::CompleteSubspace::reallocatePreciseAllocationNonVirtual):
- heap/CompleteSubspaceInlines.h:
(JSC::CompleteSubspace::allocateNonVirtual):
- heap/DeferGC.h:
(JSC::DeferGC::~DeferGC):
- heap/GCDeferralContextInlines.h:
(JSC::GCDeferralContext::~GCDeferralContext):
- heap/Heap.cpp:
(JSC::Heap::collectNow):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectIfNecessaryOrDefer):
- heap/Heap.h:
(JSC::Heap::addressOfDoesGC):
(JSC::Heap::setDoesGCExpectation):
(JSC::Heap::verifyCanGC):
(JSC::Heap::expectDoesGC const): Deleted.
(JSC::Heap::setExpectDoesGC): Deleted.
(JSC::Heap::addressOfExpectDoesGC): Deleted.
- heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::stopIfNecessary):
- heap/LocalAllocatorInlines.h:
(JSC::LocalAllocator::allocate):
- heap/PreciseAllocation.cpp:
(JSC::PreciseAllocation::tryCreate):
(JSC::PreciseAllocation::createForLowerTier):
- runtime/JSString.h:
(JSC::jsSingleCharacterString):
(JSC::JSString::toAtomString const):
(JSC::JSString::toExistingAtomString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
- runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
- 8:59 PM Changeset in webkit [262474] by
-
- 3 edits in trunk/Source/ThirdParty/ANGLE
Change ANGLE's header postprocessing script to not rely on timestamps
https://bugs.webkit.org/show_bug.cgi?id=212623
<rdar://problem/63856997>
Reviewed by David Kilzer.
Reviewed by Kennneth Russell.
Some WebKit builds involve multiple passes, where each pass is a
superset of the previous pass. In the cases where each pass produces
the same files, it is required that files be produced in exactly the
same way in each of those passes. A build process that relies on a
file containing a timestamp trips up that prerequisite.
adjust-angle-include-paths.sh uses such a mechanism, using a timestamp
file to determine if any exported headers need to be post-processed.
Since this violates our prerequisite, we need a different approach.
Instead of using a timestamp, always perform the post-processing, but
write the output to a temporary location. Then see if it differs from
what's in the actual final destination. If the two files diff, then
copy the one from the temporary location to the final destination.
This approach does cause more work in the area of post-processing.
However, this post-processing is actually very cheap. And avoiding the
post-processing is not actually the original goal of the timestamp.
The actual goal is to avoid touching the modification dates of the
exported headers, which would then cause a lot of downstream
rebuilding. The new approach with the temporary files also achieves
that goal.
- CMakeLists.txt:
- adjust-angle-include-paths.sh:
- 8:48 PM Changeset in webkit [262473] by
-
- 2 edits in trunk/LayoutTests
[iOS] fast/events/touch/ios/content-observation/opacity-change-happens-on-touchstart-with-transition2.html is a flaky failure
https://bugs.webkit.org/show_bug.cgi?id=212660
<rdar://problem/61948534>
Reviewed by Simon Fraser.
When the device is busy and the transition gets delayed, the opacity change could miss the content observation window.
Forcing synchronous style change makes is less flaky.
- fast/events/touch/ios/content-observation/opacity-change-happens-on-touchstart-with-transition2.html:
- 8:01 PM Changeset in webkit [262472] by
-
- 2 edits in trunk/LayoutTests
Followup to r262438
Remove scrollingcoordinator/mac/latching/horizontal-overflow-back-swipe.html from TestExpectations
now that it should no longer be flaky.
- platform/mac/TestExpectations:
- 7:00 PM Changeset in webkit [262471] by
-
- 1 copy in tags/Safari-610.1.15.1.2
Tag Safari-610.1.15.1.2.
- 6:52 PM Changeset in webkit [262470] by
-
- 8 edits in branches/safari-610.1.15.1-branch/Source
Versioning.
- 6:50 PM Changeset in webkit [262469] by
-
- 4 edits in trunk/Source/WebCore
Add a helper method to populate a DataTransfer before dispatching a "dragstart" event
https://bugs.webkit.org/show_bug.cgi?id=212614
Work towards <rdar://problem/61368402>
Reviewed by Tim Horton.
Add a helper method in DragController to pre-populate the StaticPasteboard-backed DataTransfer before
dispatching the "dragstart" event. There should be no change in behavior yet, since StaticPasteboard doesn't
implement methods for writing data to the pasteboard, which this new method uses.
- page/DragController.cpp:
(WebCore::DragController::prepareForDragStart const):
(WebCore::DragController::hitTestResultForDragStart const):
(WebCore::DragController::startDrag):
- page/DragController.h:
- page/EventHandler.cpp:
(WebCore::EventHandler::dispatchDragStartEventOnSourceElement):
- 6:38 PM Changeset in webkit [262468] by
-
- 4 edits in trunk/LayoutTests
Layout test failures: media/video-create-with-user-gesture.html and media/video-restricted-no-preload-auto.html
https://bugs.webkit.org/show_bug.cgi?id=212666
Reviewed by Eric Carlson.
Set event handlers before set the video source.
- media/video-create-with-user-gesture.html:
- media/video-restricted-no-preload-auto-expected.txt:
- media/video-restricted-no-preload-auto.html:
- 6:25 PM Changeset in webkit [262467] by
-
- 4 edits in trunk/Source/JavaScriptCore
VMInspector APIs should be taking a VM* instead of a JSGlobalObject*.
https://bugs.webkit.org/show_bug.cgi?id=212676
Reviewed by Saam Barati and Robin Morisset.
This because:
- None of the functions currently taking a JSGlobalObject* actually need the globalObject. All of them need the VM.
- The role of the VMInspector is to enable inspection of the VM. By requiring that it be passed a JSGlobalObject*, we were actually preventing the VMInspector from being used in code that have a VM to inspect but don't have a JSGlobalObject to use.
The reason I'm choosing to pass VM* instead of VM& is because it makes these
functions trivial to call using lldb interactively. The VMInspector functions
are also intentionally designed so that they can be used for this purpose.
On occasion, I may have to cast literal numbers (addresses) to VM*. Technically,
I could cast a number to VM* and dereference it to get a VM& too. However, at
present, lldb is often buggy and not always reliable with casts. I would like to
lessen the chance that lldb fails on me when I'm deep in the middle of a debugging
session, and have a need to call one of these functions.
- tools/JSDollarVM.cpp:
(JSC::functionGC):
(JSC::functionEdenGC):
(JSC::functionCodeBlockForFrame):
(JSC::codeBlockFromArg):
(JSC::functionDumpCallFrame):
(JSC::functionDumpStack):
- tools/VMInspector.cpp:
(JSC::VMInspector::currentThreadOwnsJSLock):
(JSC::ensureCurrentThreadOwnsJSLock):
(JSC::VMInspector::gc):
(JSC::VMInspector::edenGC):
(JSC::VMInspector::isValidCodeBlock):
(JSC::VMInspector::codeBlockForFrame):
(JSC::VMInspector::dumpCallFrame):
(JSC::VMInspector::dumpStack):
- tools/VMInspector.h:
- 5:57 PM Changeset in webkit [262466] by
-
- 2 edits in trunk/Source/WebKit
REGRESSION[r260844]: [GTK][WPE] Inspector GResource no longer updated after WebInspectorUI file updates
https://bugs.webkit.org/show_bug.cgi?id=212583
Reviewed by Adrian Perez de Castro.
Add a cmake dependency on inspector resource stamp so the Glib
Inspector resources rebuild when the stamp is updated.
- InspectorGResources.cmake:
- 5:46 PM Changeset in webkit [262465] by
-
- 2 edits in trunk/LayoutTests
ASSERTION FAILED: isCell() under WebCore::JSDOMConstructor seen with webaudio/the-audio-api/the-audiocontext-interface/audiocontextoptions.html
https://bugs.webkit.org/show_bug.cgi?id=212650
Unreviewed test gardening.
- platform/ios/TestExpectations: Skip this test on debug since it always asserts.
- 5:38 PM Changeset in webkit [262464] by
-
- 2 edits in trunk/LayoutTests
ASSERTION FAILED: isCell() under WebCore::JSDOMConstructor seen with webaudio/the-audio-api/the-audiocontext-interface/audiocontextoptions.html
https://bugs.webkit.org/show_bug.cgi?id=212650
Unreviewed test gardening.
- platform/mac/TestExpectations: Skip this test on debug since it always asserts.
- 4:59 PM Changeset in webkit [262463] by
-
- 2 edits in trunk/Source/WebCore
AXIsolatedTree::updateNode should not call nodeForID.
https://bugs.webkit.org/show_bug.cgi?id=212662
Reviewed by Chris Fleizach.
In isolated tree mode AXIsolatedTree::nodeForID should be called only
on the secondary AX thread. So removing the need to call nodeForID in
updateNode by using AXCoreObject::childrenIDs() instead of retrieving
the isolated node to access its children IDs.
- accessibility/isolatedtree/AXIsolatedTree.cpp:
(WebCore::AXIsolatedTree::updateNode):
- 4:52 PM Changeset in webkit [262462] by
-
- 40 edits2 adds in trunk
Revert FEATURES_DEFINES related changes
https://bugs.webkit.org/show_bug.cgi?id=212664
<rdar://problem/63893033>
Reviewed by Andy Estes.
Bug 262310, Bug 262311, Bug 262318, and Bug 262331 involve changes to
FEATURE_DEFINES and how the values there relate to those found in the
Platform*.h files. Those changes break XCBuild (by removing the
.xcfilelist related to UnifiedSources and the process for generating
them), and so are being reverted.
.:
- Source/cmake/OptionsFTW.cmake:
- Source/cmake/OptionsMac.cmake:
- Source/cmake/WebKitFeatures.cmake:
Source/JavaScriptCore:
- Configurations/FeatureDefines.xcconfig:
Source/WebCore:
No new tests -- build changes.
- Configurations/FeatureDefines.xcconfig:
- Configurations/GenerateUnifiedSources.xcconfig: Added.
- DerivedSources-input.xcfilelist:
- DerivedSources-output.xcfilelist:
- DerivedSources.make:
- Modules/applepay/ApplePayError.idl:
- Modules/applepay/ApplePayPaymentAuthorizationResult.idl:
- Modules/applepay/ApplePayPaymentContact.idl:
- Modules/applepay/ApplePayPaymentMethodUpdate.idl:
- Modules/applepay/ApplePayRequestBase.idl:
- Modules/applepay/ApplePaySession.idl:
- Modules/applepay/ApplePayShippingContactUpdate.idl:
- Modules/applepay/ApplePayShippingMethodUpdate.idl:
- Modules/applepay/PaymentCoordinatorClient.cpp:
(WebCore::PaymentCoordinatorClient::supportsVersion):
- Modules/applepay/paymentrequest/ApplePayPaymentHandler.cpp:
(WebCore::ApplePayPaymentHandler::computePaymentMethodErrors const):
- Scripts/generate-unified-sources.sh:
- UnifiedSources-output.xcfilelist: Added.
- WebCore.xcodeproj/project.pbxproj:
- accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::applePayButtonDescription const):
- css/CSSPrimitiveValueMappings.h:
(WebCore::CSSPrimitiveValue::CSSPrimitiveValue):
(WebCore::CSSPrimitiveValue::operator ApplePayButtonType const):
- css/CSSValueKeywords.in:
- css/parser/CSSParserFastPaths.cpp:
(WebCore::CSSParserFastPaths::isValidKeywordPropertyAndValue):
- rendering/RenderThemeCocoa.mm:
(WebCore::toPKPaymentButtonType):
- rendering/style/RenderStyleConstants.cpp:
(WebCore::operator<<):
- rendering/style/RenderStyleConstants.h:
Source/WebCore/PAL:
- Configurations/FeatureDefines.xcconfig:
Source/WebKit:
- Configurations/FeatureDefines.xcconfig:
Source/WebKitLegacy/mac:
- Configurations/FeatureDefines.xcconfig:
Tools:
- Scripts/webkitperl/FeatureList.pm:
- Scripts/webkitpy/generate_xcfilelists_lib/generators.py:
(WebCoreGenerator):
(WebCoreGenerator._get_generate_unified_sources_script):
- TestWebKitAPI/Configurations/FeatureDefines.xcconfig:
- 4:34 PM Changeset in webkit [262461] by
-
- 20 edits in trunk/Source
Unreviewed, reverting r262424.
Caused webkitpy test failure
Reverted changeset:
"Make generated C++ code use modern C++"
https://bugs.webkit.org/show_bug.cgi?id=190714
https://trac.webkit.org/changeset/262424
- 4:18 PM Changeset in webkit [262460] by
-
- 3 edits in trunk/Source/ThirdParty/ANGLE
Revise PVRTC compressed texture validation in ANGLE backend for WebGL
https://bugs.webkit.org/show_bug.cgi?id=212612
Patch by Kenneth Russell <kbr@chromium.org> on 2020-06-02
Reviewed by Dean Jackson.
Correct the block sizes of PVRTC textures, and incorporate minimum
block sizes for width and height, as required by these formats.
- src/libANGLE/formatutils.cpp:
(gl::BuildInternalFormatInfoMap):
(gl::InternalFormat::computeCompressedImageSize const):
(gl::InternalFormat::getCompressedImageMinBlocks const):
- src/libANGLE/formatutils.h:
- 4:10 PM Changeset in webkit [262459] by
-
- 2 edits in trunk/LayoutTests
[ Mojave wk2 Debug ] fast/scrolling/mac/scrollbars/select-overlay-scrollbar-hovered.html is flaky failing and flaky timing out.
https://bugs.webkit.org/show_bug.cgi?id=212667
Unreviewed test gardening.
- platform/mac-wk2/TestExpectations:
- 4:05 PM Changeset in webkit [262458] by
-
- 2 edits in branches/safari-610.1.15-branch/Source/JavaScriptCore
Cherry-pick r262389. rdar://problem/63897040
x86.rb's LabelReference.x86LoadOperand()'s address operand should be a pointer type.
https://bugs.webkit.org/show_bug.cgi?id=212603
Reviewed by Saam Barati.
The current implementation mistakenly sets the address type to that of the value
being loaded. I encountered this issue when I was trying to do a loadb from a
global address. Because of this bug, the emitted code was trying do a load using
%al (8 byte register) as the pointer to load from. With this fix, it now loads
from %rax.
- offlineasm/x86.rb:
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262389 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 3:33 PM Changeset in webkit [262457] by
-
- 2 edits in trunk/LayoutTests
[ Mac wk1 Debug ] svg/custom/textPath-insert-path.svg is flaky failing.
https://bugs.webkit.org/show_bug.cgi?id=212665
Unreviewed test gardening.
- platform/mac-wk1/TestExpectations:
- 3:26 PM Changeset in webkit [262456] by
-
- 24 edits in trunk
Stressing webkitSetPresentationMode leads to wrong inline video dimensions
https://bugs.webkit.org/show_bug.cgi?id=202425
Reviewed by Eric Carlson.
Source/WebCore:
Make the HTMLVideoElement::setFullscreenMode() robust under stress tests
by ignoring a request when the video element is not ready yet.
Manually tested.
- dom/Element.h:
(WebCore::Element::didStopBeingFullscreenElement):
Add a callback to indicate that the element has exited fullscreen.
- dom/FullscreenManager.cpp:
(WebCore::FullscreenManager::didExitFullscreen):
Call Element::didStopBeingFullscreenElement() when the element has exited fullscreen.
- html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::enterFullscreen):
- html/HTMLMediaElement.h:
- html/HTMLVideoElement.cpp:
(WebCore::HTMLVideoElement::webkitDisplayingFullscreen):
This function will return true when a video element is in the process to exit
fullscreen/picture-in-picture until it has completed the process. Therefore, a page
can safely request the video element to enter fullscreen/picture-in-picture when
this function returns false.
(WebCore::HTMLVideoElement::setFullscreenMode):
(WebCore::HTMLVideoElement::didBecomeFullscreenElement):
(WebCore::HTMLVideoElement::didStopBeingFullscreenElement):
(WebCore::HTMLVideoElement::didEnterFullscreen): Deleted.
(WebCore::HTMLVideoElement::didExitFullscreen): Deleted.
- html/HTMLVideoElement.h:
Add a flag m_isChangingPresentationMode. webkitSetPresentationMode() will only
change the presentation mode when the flag is false.
Source/WebKit:
- WebProcess/cocoa/VideoFullscreenManager.mm:
(WebKit::VideoFullscreenManager::didEnterFullscreen):
(WebKit::VideoFullscreenManager::didCleanupFullscreen):
Source/WebKitLegacy/mac:
Move DumpRenderTree's implementation of the mock video presentation mode from WebView
to WebChromeClient and call videoElement.didStopBeingFullscreenElement() when a video
element exits fullscreen.
- WebCoreSupport/WebChromeClient.h:
- WebCoreSupport/WebChromeClient.mm:
(WebChromeClient::setMockVideoPresentationModeEnabled):
(WebChromeClient::enterVideoFullscreenForVideoElement):
(WebChromeClient::exitVideoFullscreenForVideoElement):
(WebChromeClient::exitVideoFullscreenToModeWithoutAnimation):
- WebView/WebView.mm:
(-[WebView _enterVideoFullscreenForVideoElement:mode:]):
(-[WebView _exitVideoFullscreen]):
(-[WebView _setMockVideoPresentationModeEnabled:]): Deleted.
- WebView/WebViewData.h:
- WebView/WebViewInternal.h:
Tools:
- TestWebKitAPI/Tests/WebKitCocoa/WKWebViewCloseAllMediaPresentations.mm:
(TEST):
LayoutTests:
Enable the mock video presentation mode in WebKitTestRunner and
only request a video element to enter/exit fullscreen/picture-in-picture when
the element is ready to do so (by checking the attribute webkitDisplayingFullscreen).
- media/modern-media-controls/placard-support/placard-support-pip-expected.txt:
- media/modern-media-controls/placard-support/placard-support-pip.html:
- media/presentationmodechanged-fired-once-expected.txt:
- media/presentationmodechanged-fired-once.html:
- media/video-presentation-mode-expected.txt:
- media/video-presentation-mode.html:
- 3:13 PM Changeset in webkit [262455] by
-
- 2 edits in trunk/Source/WebKit
Assert network process is not suspended when trying to merge new ITP data
https://bugs.webkit.org/show_bug.cgi?id=212663
<rdar://problem/63892899>
Reviewed by Chris Dumez.
Add a debug assert to check if statistics are being merged into the
ITP database after prepareToSuspend() has been called. If this assert
is hit, it means the ITP database thread is not being stopped when
the process is suspended.
- NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
(WebKit::WebResourceLoadStatisticsStore::resourceLoadStatisticsUpdated):
- 2:58 PM Changeset in webkit [262454] by
-
- 3 edits in branches/safari-610.1.15-branch/Source/WebCore
Cherry-pick r262428. rdar://problem/63891546
UIColor and NSColor WebCore::Color factories should return invalid colors for nil input colors
https://bugs.webkit.org/show_bug.cgi?id=212631
Reviewed by Anders Carlsson.
- platform/graphics/mac/ColorMac.mm: (WebCore::colorFromNSColor): (WebCore::semanticColorFromNSColor):
- platform/ios/ColorIOS.mm: (WebCore::colorFromUIColor): This doesn't affect any code currently in WebKit, but it is very, very surprising that these functions happily accept a null color, assert in debug, but in release do crazy things like try to paint the null color into a small bitmap to figure out what it really is.
Also, this matches the behavior of the Color constructors that take CGColorRef.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262428 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262453] by
-
- 2 edits in branches/safari-610.1.15-branch/Source/WebCore/PAL
Cherry-pick r262347. rdar://problem/63891529
REGRESSION (r262332): Windows build failure because <nw/private.h> doesn't exist
<https://bugs.webkit.org/show_bug.cgi?id=212551>
<rdar://problem/62461099>
Unreviewed Windows build fix.
- pal/spi/cf/CFNetworkSPI.h:
- Move <nw/private.h> so it is not included with PLATFORM(WIN).
- Add or clean up some macro comments.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262347 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262452] by
-
- 6 edits in branches/safari-610.1.15-branch/Source
Cherry-pick r262332. rdar://problem/63891529
[Cocoa] Improve logging quality for non-ephemeral sessions
https://bugs.webkit.org/show_bug.cgi?id=212551
<rdar://problem/62461099>
Reviewed by David Kilzer.
Source/WebCore/PAL:
Add support for the 'nw_context_privacy_level' setting.
- pal/spi/cf/CFNetworkSPI.h:
Source/WebKit:
In Bug 209522 I switched normal mode logging to use the same privacy-protecting mode we use for ephemeral sessions.
This had the unintended consequence of removing network load data used to investigate networking issues.
This patch adopts the more fine-grained logging provided by the low-level 'nw_context_privacy_level' setting.
- NetworkProcess/cocoa/NetworkSessionCocoa.mm: (WebKit::configurationForSessionID): Adopt 'nw_context_privacy_level' setting.
Source/WTF:
- wtf/PlatformHave.h: Add new feature check for CFNetwork convenience setter.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262332 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262451] by
-
- 1 edit in branches/safari-610.1.15-branch/Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm
Cherry-pick r262327. rdar://problem/63891529
Use ALLOW_DEPRECATED_DECLARATIONS_BEGIN instead (thanks to mitz)
- NetworkProcess/cocoa/NetworkSessionCocoa.mm: (WebKit::configurationForSessionID):
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262327 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262450] by
-
- 18 edits1 copy1 add in branches/safari-610.1.15-branch/Source
Cherry-pick r262434. rdar://problem/63891520
Change Gigacage::Config to use storage in WebConfig::g_config instead of its own.
https://bugs.webkit.org/show_bug.cgi?id=212585
<rdar://problem/63812487>
Reviewed by Yusuke Suzuki.
Source/bmalloc:
- Gigacage::Config now reserves and expect space to be available in an external WebConfig::g_config buffer. Gigacage does not allocate that buffer.
- Moved Gigacage::Config to GigacageConfig.h. This allows WTFConfig.h to include GigacageConfig.h instead of all of Gigacage.h.
- Moved Gigacage::Kind to GigacageKind.h. Otherwise, Gigacage::Kind would need to move to GigacageConfig.h which is a weird place to put it.
- Removed freezeGigacageConfig(), unfreezeGigacageConfig(), and permanentlyFreezeGigacageConfig().
It is no longer possible to temporarily freeze and unfreeze the Gigacage::Config
because it now share the same memory page with higher level Configs.
permanentlyFreezeGigacageConfig() is no longer needed because it is subsumed
by WTF::Config::permanentlyFreeze(), which will freeze the entire WebConfig::g_config
buffer.
One difference in behavior here is that Gigacage::Config data used to be permanently
frozen as soon as forbidDisablingPrimitiveGigacage() is called. Now, it isn't
permanently frozen until the end of the construction of the first JSC::VM instance
in the process (just like the other Config records). This still guarantees that
it is frozen before any JS script can run.
- Previously, disablePrimitiveGigacage() works by nullifying the Primitive gigacage base pointer. We can no longer do that because the base pointer will be frozen on VM instantiation. Instead, if not forbidden, we now disable the Primitive gigacage by setting a disablePrimitiveGigacageRequested bool variable that is not frozen in the Gigacage::Config.
To check if the Primitive gigacage is enabled, the LLInt, AssemblyHelpers::cageConditionally(),
and runtime functions will check the following conditions:
g_gigacageConfig.basePtr(Primitive) &&
(disablingPrimitiveGigacageIsForbidden() disableNotRequestedForPrimitiveGigacage()) The base pointer being null means the gigacage was never set up.
If disablingPrimitiveGigacageIsForbidden() is true, then we don't care
whether a disable request has been received.
Otherwise, the gigacage is only enabled if it has been set up, and a
disable request has not been received.
Note that the first 2 terms are frozen in the Gigacage::Config. Only the
last term is a runtime variable. If disabling is forbidden, then the
runtime variable never comes into play.
The FTL does not rely on a runtime check for whether the Primitive gigacage is
enabled or not. Instead, it relies on a watchpoint to handle this. So, it
just works, and there's no performance penalty with adding the 2 extra terms
to check.
Note also that the jsc shell and the WebProcess will forbid disabling of the
Primitive gigacage. This means the AssemblyHelpers::cageConditionally() will
also not generate the runtime checks for the 2 extra terms.
Only the LLInt and runtime functions will have to do work to check the 2 extra
terms. But because these are not in perf critical paths, this is ok.
Note that we're deliberately gating the disablePrimitiveGigacageRequested
variable check on disablingPrimitiveGigacageIsForbidden though, logically, the
isEnable check does not really depend on whether disabling is forbidden or not.
We do this because disablingPrimitiveGigacageIsForbidden is frozen in the Config,
and it is, therefore, a stronger guarantee of correctness whereas the variable
can be corrupted.
- Replaced isDisablingPrimitiveGigacageForbidden(), canPrimitiveGigacageBeDisabled(), and isPrimitiveGigacagePermanentlyEnabled() with disablingPrimitiveGigacageIsForbidden().
- CMakeLists.txt:
- bmalloc.xcodeproj/project.pbxproj:
- bmalloc/Gigacage.cpp: (Gigacage::ensureGigacage): (Gigacage::disablePrimitiveGigacage): (Gigacage::forbidDisablingPrimitiveGigacage): (Gigacage::bmalloc::freezeGigacageConfig): Deleted. (Gigacage::bmalloc::unfreezeGigacageConfig): Deleted. (Gigacage::bmalloc::permanentlyFreezeGigacageConfig): Deleted. (Gigacage::bmalloc::UnfreezeGigacageConfigScope::UnfreezeGigacageConfigScope): Deleted. (Gigacage::bmalloc::UnfreezeGigacageConfigScope::~UnfreezeGigacageConfigScope): Deleted. (Gigacage::isDisablingPrimitiveGigacageForbidden): Deleted.
- bmalloc/Gigacage.h: (Gigacage::disablingPrimitiveGigacageIsForbidden): (Gigacage::disableNotRequestedForPrimitiveGigacage): (Gigacage::isEnabled): (Gigacage::basePtr): (Gigacage::caged): (Gigacage::forbidDisablingPrimitiveGigacage): (): Deleted. (Gigacage::Config::basePtr const): Deleted. (Gigacage::Config::setBasePtr): Deleted. (Gigacage::isPrimitiveGigacagePermanentlyEnabled): Deleted. (Gigacage::canPrimitiveGigacageBeDisabled): Deleted.
- bmalloc/GigacageConfig.h: Added. (Gigacage::Config::basePtr const): (Gigacage::Config::setBasePtr):
- bmalloc/GigacageKind.h: Added.
- bmalloc/Heap.cpp: (bmalloc::Heap::usingGigacage):
- bmalloc/mbmalloc.cpp:
Source/JavaScriptCore:
- assembler/testmasm.cpp: (JSC::testCagePreservesPACFailureBit):
- dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
- ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged):
- jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cageConditionally):
- llint/LowLevelInterpreter64.asm:
- runtime/JSCConfig.h: (JSC::Config::isPermanentlyFrozen):
Source/WTF:
We now think of the various Config records as being allocated from parts of a
WebConfig::g_config buffer. WTF::Config will manage the mechanics of freezing
that buffer. And the JSC VM is still the determiner of if/when to freeze the
buffer, and it will do this at the end of the construction of the very first
VM instance (as before).
Gigacage::Config reserves space in WebConfig::g_config.
WTF::Config will honor that reservation and place itself after that.
JSC::Config will continue to place itself at WTF::Config::spaceForExtensions.
The upside of this approach this is that we can now share the same memory page
for all the Configs, and can freeze them in one go.
The downside is that g_gigacageConfig, g_wtfConfig, and g_jscConfig now have to
be macros. This results in some weirdness e.g. they are no longer qualified by
namespaces: referring to WTF::g_wtfConfig is now incorrect.
- wtf/Gigacage.h: (Gigacage::disablingPrimitiveGigacageIsForbidden): (Gigacage::isDisablingPrimitiveGigacageForbidden): Deleted. (Gigacage::isPrimitiveGigacagePermanentlyEnabled): Deleted. (Gigacage::canPrimitiveGigacageBeDisabled): Deleted.
- wtf/WTFConfig.cpp: (WTF::Config::permanentlyFreeze):
- wtf/WTFConfig.h: (): Deleted.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262434 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262449] by
-
- 8 edits in branches/safari-610.1.15-branch/Source/WebKit
Cherry-pick r262429. rdar://problem/63891546
macCatalyst: WKWebView's tint color is not propagated to Web Content process
https://bugs.webkit.org/show_bug.cgi?id=212630
Reviewed by Anders Carlsson.
- Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode):
- Shared/WebPageCreationParameters.h:
- UIProcess/Cocoa/PageClientImplCocoa.h:
- UIProcess/PageClient.h:
- UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters):
- WebProcess/WebPage/WebPage.cpp:
- WebProcess/WebPage/WebPage.h:
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262429 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262448] by
-
- 2 edits in branches/safari-610.1.15-branch/Source/WebKit
Cherry-pick r262427. rdar://problem/63891546
REGRESSION (r258949): Dynamic user accent color changes are not respected by WKWebView
https://bugs.webkit.org/show_bug.cgi?id=212628
<rdar://problem/63436275>
Reviewed by Per Arne Vollan.
Two issues with the "CFPrefs Direct Mode" mechanism caused dynamic changes to the
user accent color preference to not be respected anymore:
- the default change, when synchronized to the Web Content process, was written into the wrong domain, because of bug 212627.
- AppKit caches the resolved accent color; the cache is invalidated when the a CoreUI notification is posted. Since we synchronize preferences ourselves, the ordering of the default change and notification are no longer guaranteed, so AppKit sometimes reads and re-caches the old accent color.
- WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::userAccentColorPreferenceKey): (WebKit::shouldWriteToAppDomainForPreferenceKey): (WebKit::WebProcess::notifyPreferencesChanged): To fix the first problem, write the default into the standardUserDefaults. This is just a workaround, we need a more general solution to this problem for all global preferences. We know it's OK in this case, because AppKit happens to read from standardUserDefaults.
(WebKit::dispatchSimulatedNotificationsForPreferenceChange):
To fix the second problem, re-emit the notification once we have synchronized
the preference to the Web Content process.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262427 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262447] by
-
- 5 edits in branches/safari-610.1.15-branch
Cherry-pick r262398. rdar://problem/63891512
TextManipulationController should put one Node in only one paragraph
https://bugs.webkit.org/show_bug.cgi?id=212548
Reviewed by Wenson Hsieh.
Source/WebCore:
TextManipulationController mainly uses line break as delimiter to split paragraphs. In our current
implementation, if text of a Node has line break, the part before the line break is in one paragraph and the
part after the line break is in another paragraph, which means the Node is in the ranges of two paragraphs.
In this case, when TextManipulationController manipulates the first paragraph, it replaces all the Nodes in the
range of first paragraph with new Nodes. Then when it manipulates the second paragraph, if will find Node in the
range of second paragraph does not exist and fail (because the Node is removed when handling the first
paragraph.). Also, TextManipulationController currently does not preserve line breaks in text, which can be an
issue if these line breaks are visible.
This patch makes the ParagraphContentIterator iterate over Nodes instead of text, so a Node can only be in the
range of one paragraph. To do this, it makes line break and spaces around it as a special excluded token.
Here are the rules for splitting paragraphs by line break now:
- If the special token is the first token in a Node, text in Nodes before the Node will make a paragraph.
- If the special token is the last token in a Node, text in Nodes before the Node and in the Node will make a paragraph.
- If the special token in the middle of tokens in a Node, then we don't make a new paragraph until next special token meets condition 1 or 2.
This patch also fixes the issue that Nodes out of the paragraph range can be removed due to the preorder Node
traversal, by finding and adding those Nodes back.
- editing/TextManipulationController.cpp: (WebCore::ParagraphContentIterator::m_pastEndNode): (WebCore::ParagraphContentIterator::advance): (WebCore::ParagraphContentIterator::currentContent): (WebCore::ParagraphContentIterator::atEnd const): (WebCore::ParagraphContentIterator::advanceNode): (WebCore::ParagraphContentIterator::advanceIteratorNodeAndUpdateText): (WebCore::isEnclosingItemBoundaryElement): (WebCore::TextManipulationController::parse): (WebCore::TextManipulationController::observeParagraphs): (WebCore::TextManipulationController::addItem): (WebCore::TextManipulationController::getPath): (WebCore::TextManipulationController::updateInsertions): (WebCore::TextManipulationController::replace): (WebCore::ParagraphContentIterator::startPosition): Deleted. (WebCore::ParagraphContentIterator::endPosition): Deleted. (WebCore::ParagraphContentIterator::moveCurrentNodeForward): Deleted. (WebCore::containsOnlyHTMLSpaces): Deleted.
- editing/TextManipulationController.h:
Tools:
- TestWebKitAPI/Tests/WebKitCocoa/TextManipulation.mm: (TestWebKitAPI::TEST):
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262398 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262446] by
-
- 3 edits in branches/safari-610.1.15-branch/Source/WebKit
Cherry-pick r262396. rdar://problem/63891587
Remove unused WebContent process sandbox syscall
https://bugs.webkit.org/show_bug.cgi?id=212609
<rdar://problem/63764590>
Reviewed by Per Arne Vollan.
After further testing we have determined that the syscall added in
Bug 206260 is not always enabled. Check if the Sandbox recognizes
the rule before using it.
- Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:
- WebProcess/com.apple.WebProcess.sb.in:
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262396 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262445] by
-
- 7 edits in branches/safari-610.1.15-branch/Source
Cherry-pick r262356. rdar://problem/63891520
Change JSC::Config to use storage in WTF::Config instead of its own.
https://bugs.webkit.org/show_bug.cgi?id=212575
<rdar://problem/63796584>
Reviewed by Yusuke Suzuki.
Source/JavaScriptCore:
Since Configs must be rounded up to CeilingOnPageSize, this will save us some
memory since the contents of both Configs do not add up to CeilingOnPageSize.
g_jscConfig is now located at g_wtfConfig.spaceForExtensions.
- runtime/JSCConfig.cpp: (JSC::Config::disableFreezingForTesting): (JSC::Config::enableRestrictedOptions): (JSC::Config::permanentlyFreeze): Deleted.
- runtime/JSCConfig.h: (JSC::Config::permanentlyFreeze): (JSC::Config::isPermanentlyFrozen): (): Deleted.
- runtime/Options.cpp: (JSC::Options::setOptions):
- tools/JSDollarVM.cpp: (JSC::functionCallWithStackSize):
Source/WTF:
- wtf/WTFConfig.h:
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262356 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262444] by
-
- 2 edits in branches/safari-610.1.15-branch/Source/WebKitLegacy/mac
Cherry-pick r262330. rdar://problem/63891486
REGRESSION (r260306): Compatibility issue leading to crash on macOS games
<https://webkit.org/b/212546>
<rdar://problem/62624078>
Reviewed by Brent Fulgham.
- WebView/WebView.mm: (_WebSafeForwarder._target): (_WebSafeForwarder._defaultTarget):
- Change weak attribute to unsafe_unretained to fix the crash.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262330 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262443] by
-
- 2 edits in branches/safari-610.1.15-branch/Source/WebKit
Cherry-pick r262280. rdar://problem/63891526
Avoid unnecessary sync IPC messages when togging the callout bar for selections.
https://bugs.webkit.org/show_bug.cgi?id=212508
The loupe gesture only needs to be activated and evaluated if the tap is inside
an existing selectionView. We can do that test in the UIProcess without resorting to a sync IPC message.
Doing that evaluation locally will eliminate unnecessary hangs in the UIProcess.
Reviewed by Wenson Hsieh.
- UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _pointIsInsideSelectionRect:outBoundingRect:]): (-[WKContentView _shouldToggleSelectionCommandsAfterTapAt:]): (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]):
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262280 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:58 PM Changeset in webkit [262442] by
-
- 11 edits4 adds in branches/safari-610.1.15-branch
Cherry-pick r262279. rdar://problem/63891510
[Apple Pay] Buttons render with a corner radius of PKApplePayButtonDefaultCornerRadius even when explicitly specifying "border-radius: 0px"
https://bugs.webkit.org/show_bug.cgi?id=212476
<rdar://problem/63401433>
Reviewed by Antti Koivisto.
Source/WebCore:
r256648 added support for customizing the corner radius of Apple Pay buttons using the
border-radius CSS property. PassKit buttons have a default corner radius of 4, but
border-radius has an initial value of 0, so to maintain web compatibility with existing
buttons we only want to customize the corner radius when a border-radius value has been
explicitly specified (otherwise, previously rounded buttons would all become squared off due
to border-radius's initial value).
r256648 checked for a non-initial border-radius by calling RenderStyle::hasBorderRadius, but
this check does not distinguish between an initial value and an explicit declaration of
"border-radius: 0px". As a result, authors are unable to create Apple Pay buttons with
square corners.
This patch adds a flag to RenderStyle::NonInheritedFlags that tracks whether any
border-radius longhand has been explicitly set (or has explicitly inherited an explicitly set
value), and uses that flag to adjust the computed border radius for Apple Pay buttons.
The addition of RenderStyle::NonInheritedFlags::hasExplicitlySetBorderRadius did not change
the size of RenderStyle.
Tests: fast/css/appearance-apple-pay-button-border-radius.html
fast/css/getComputedStyle/computed-style-apple-pay-button.html
- css/CSSProperties.json:
- rendering/RenderThemeCocoa.mm: (WebCore::RenderThemeCocoa::adjustApplePayButtonStyle const): (WebCore::RenderThemeCocoa::paintApplePayButton): (WebCore::largestCornerRadius): Deleted.
- rendering/style/RenderStyle.cpp: (WebCore::RenderStyle::RenderStyle):
- rendering/style/RenderStyle.h: (WebCore::RenderStyle::hasExplicitlySetBorderRadius const): (WebCore::RenderStyle::setHasExplicitlySetBorderRadius): (WebCore::RenderStyle::NonInheritedFlags::operator== const): (WebCore::RenderStyle::NonInheritedFlags::copyNonInheritedFrom):
- style/StyleBuilderCustom.h: (WebCore::Style::BuilderCustom::applyInheritBorderBottomLeftRadius): (WebCore::Style::BuilderCustom::applyValueBorderBottomLeftRadius): (WebCore::Style::BuilderCustom::applyInheritBorderBottomRightRadius): (WebCore::Style::BuilderCustom::applyValueBorderBottomRightRadius): (WebCore::Style::BuilderCustom::applyInheritBorderTopLeftRadius): (WebCore::Style::BuilderCustom::applyValueBorderTopLeftRadius): (WebCore::Style::BuilderCustom::applyInheritBorderTopRightRadius): (WebCore::Style::BuilderCustom::applyValueBorderTopRightRadius):
LayoutTests:
- TestExpectations:
- fast/css/appearance-apple-pay-button-border-radius-expected.html: Added.
- fast/css/appearance-apple-pay-button-border-radius.html: Added.
- fast/css/appearance-apple-pay-button-expected.html:
- fast/css/appearance-apple-pay-button.html:
- fast/css/getComputedStyle/computed-style-apple-pay-button-expected.txt: Added.
- fast/css/getComputedStyle/computed-style-apple-pay-button.html: Added.
- platform/mac/TestExpectations:
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262279 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:57 PM Changeset in webkit [262441] by
-
- 3 edits in branches/safari-610.1.15-branch/Source/WebKit
Cherry-pick r262255. rdar://problem/63891604
Do not send a second sync request for positition information to the web process if we have not recieved information since the previous sync request.
https://bugs.webkit.org/show_bug.cgi?id=212289
<rdar://problem/58494578>
Reviewed by Tim Horton.
If we have sent a sync requests to the web process for position information, and timed out, and have not
received a message with position information in the interim, do not send another sync request. The web
process is likely still hung, and there is no reason to hang the UIProcess again if we suspect that it
is unlikely that we will receive a reply.
- UIProcess/ios/WKContentViewInteraction.h:
- UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView cleanUpInteraction]): (-[WKContentView ensurePositionInformationIsUpToDate:]): (-[WKContentView _positionInformationDidChange:]):
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262255 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:57 PM Changeset in webkit [262440] by
-
- 2 edits in branches/safari-610.1.15-branch/Source/WebCore
Cherry-pick r262208. rdar://problem/63891613
REGRESSION (r254541): Valid mime types can only be added to the HashSet of the supported types for encoding
https://bugs.webkit.org/show_bug.cgi?id=212427
Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2020-05-27
Reviewed by Darin Adler.
Add back a check for the mime type validity which was removed in r254541.
- platform/MIMETypeRegistry.cpp: (WebCore::MIMETypeRegistry::createMIMETypeRegistryThreadGlobalData):
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262208 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- 2:19 PM Changeset in webkit [262439] by
-
- 8 edits2 adds in branches/safari-609-branch
Apply patch. rdar://problem/63626670
2020-05-22 Andy Estes <aestes@apple.com>
[Apple Pay] Add new ApplePayInstallmentConfiguration members
https://bugs.webkit.org/show_bug.cgi?id=212160
<rdar://problem/60703650>
Reviewed by Alex Christensen.
Source/WebCore:
Test: http/tests/ssl/applepay/ApplePayInstallmentItems.https.html
- DerivedSources-input.xcfilelist:
- DerivedSources-output.xcfilelist:
- DerivedSources.make:
- SourcesCocoa.txt:
- WebCore.xcodeproj/project.pbxproj: Added IDLs, headers, and derived sources for ApplePayInstallment{Item,ItemType,RetailChannel}.
- Modules/applepay/ApplePayInstallmentConfiguration.idl:
- Modules/applepay/ApplePayInstallmentConfigurationWebCore.h: Added items, applicationMetadata, and retailChannel members. Added missing conditionals to merchantIdentifier and referrerIdentifier.
- Modules/applepay/ApplePayInstallmentItem.h:
- Modules/applepay/ApplePayInstallmentItem.idl:
- Modules/applepay/ApplePayInstallmentItemType.h:
- Modules/applepay/ApplePayInstallmentItemType.idl:
- Modules/applepay/ApplePayInstallmentRetailChannel.h:
- Modules/applepay/ApplePayInstallmentRetailChannel.idl: Added.
- Modules/applepay/ApplePayRequestBase.cpp: (WebCore::convertAndValidate): Changed to call PaymentInstallmentConfiguration::create, returning an exception if present.
- Modules/applepay/PaymentInstallmentConfiguration.mm: (WebCore::fromDecimalNumber): Allowed for a large maximum number of fractional digits to support formatting high-precision currency and APRs (note that this formatter is only used for test support).
(WebCore::applePayItemType):
(WebCore::platformItemType): Added to convert between PKInstallmentItemType and
ApplePayInstallmentItemType.
(WebCore::applePayRetailChannel):
(WebCore::platformRetailChannel): Added to convert between PKInstallmentRetailChannel and
ApplePayInstallmentRetailChannel.
(WebCore::makeNSArrayElement):
(WebCore::makeVectorElement): Added to convert between NSArray<PKPaymentInstallmentItem *>
and Vector<ApplePayInstallmentItem>.
(WebCore::createPlatformConfiguration): Added a parameter for passing in applicationMetadata
as an NSDictionary. Set properties on PKPaymentInstallmentConfiguration for new
ApplePayInstallmentConfiguration members.
(WebCore::PaymentInstallmentConfiguration::create): Added; converts the applicationMetadata
JSON string (if present) to an NSDictionary, returning a TypeError if the JSON string does
not deserialize to an NSDictionary (as PassKit requires).
(WebCore::PaymentInstallmentConfiguration::PaymentInstallmentConfiguration): Added a
parameter for passing in applicationMetadata as an NSDictionary. Made private.
(WebCore::PaymentInstallmentConfiguration::applePayInstallmentConfiguration const): Set
members on ApplePayInstallmentConfiguration for new PKPaymentInstallmentConfiguration
properties.
- Modules/applepay/PaymentInstallmentConfigurationWebCore.h:
LayoutTests:
- http/tests/ssl/applepay/ApplePayInstallmentItems.https-expected.txt:
- http/tests/ssl/applepay/ApplePayInstallmentItems.https.html: Added.
- platform/mac-wk2/TestExpectations: Skipped test on Mojave and Catalina.
- 1:44 PM Changeset in webkit [262438] by
-
- 2 edits in trunk/LayoutTests
[ macOS ] scrollingcoordinator/mac/latching/horizontal-overflow-back-swipe.html is flaky timing out
https://bugs.webkit.org/show_bug.cgi?id=210351
<rdar://problem/61601464>
Reviewed by Tim Horton.
Try to deflake this test. It timed out when all the wheel events were received in the UI process
before the ViewGestureController had received a response from the web process about whether the
first event had been handled. Fix by adding a rAF() wait in the middle of sending the events.
Also register the swipe callback before starting the event sending.
- scrollingcoordinator/mac/latching/horizontal-overflow-back-swipe.html:
- 1:17 PM Changeset in webkit [262437] by
-
- 7 edits in trunk/Source
Add ENABLE(WHEEL_EVENT_REGIONS), enabled on macOS which is the only platform that needs wheel event regions for scrolling thread hit-testing
https://bugs.webkit.org/show_bug.cgi?id=212620
Reviewed by Tim Horton.
Surround code related to wheel event regions with ENABLE(WHEEL_EVENT_REGIONS).
Eventually we'll use this same code for touch event regions, and when we do, we
can rejigger the #ifdefs.
Source/WebCore:
- rendering/EventRegion.cpp:
(WebCore::EventRegion::operator== const):
(WebCore::EventRegion::unite):
(WebCore::EventRegion::containsEditableElementsInRect const):
(WebCore::EventRegion::dump const):
- rendering/EventRegion.h:
- rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::paintDebugOverlays):
Source/WTF:
- wtf/PlatformEnable.h:
- wtf/PlatformEnableCocoa.h:
- 1:05 PM Changeset in webkit [262436] by
-
- 8 edits in branches/safari-610.1.15-branch/Source
Versioning.
- 1:04 PM Changeset in webkit [262435] by
-
- 4 edits in trunk/Source
REGRESSION(r261387): Introduced sandbox violations
https://bugs.webkit.org/show_bug.cgi?id=212634
Reviewed by Darin Adler.
Source/WebCore/PAL:
Declare Launch Services class.
- pal/spi/cocoa/LaunchServicesSPI.h:
Source/WebKit:
The change set r261387 introduced some new mach lookup sandbox violations, when attempting to close Launch Services connections that were not open.
Fix this by only attempting to close open connections, and do it while holding the extension to the database mapping service.
No new tests, since this patch is fixing benign sandbox violations.
- WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::platformInitializeWebProcess):
- 12:43 PM Changeset in webkit [262434] by
-
- 18 edits2 adds in trunk/Source
Change Gigacage::Config to use storage in WebConfig::g_config instead of its own.
https://bugs.webkit.org/show_bug.cgi?id=212585
<rdar://problem/63812487>
Reviewed by Yusuke Suzuki.
Source/bmalloc:
- Gigacage::Config now reserves and expect space to be available in an external WebConfig::g_config buffer. Gigacage does not allocate that buffer.
- Moved Gigacage::Config to GigacageConfig.h. This allows WTFConfig.h to include GigacageConfig.h instead of all of Gigacage.h.
- Moved Gigacage::Kind to GigacageKind.h. Otherwise, Gigacage::Kind would need to move to GigacageConfig.h which is a weird place to put it.
- Removed freezeGigacageConfig(), unfreezeGigacageConfig(), and permanentlyFreezeGigacageConfig().
It is no longer possible to temporarily freeze and unfreeze the Gigacage::Config
because it now share the same memory page with higher level Configs.
permanentlyFreezeGigacageConfig() is no longer needed because it is subsumed
by WTF::Config::permanentlyFreeze(), which will freeze the entire WebConfig::g_config
buffer.
One difference in behavior here is that Gigacage::Config data used to be permanently
frozen as soon as forbidDisablingPrimitiveGigacage() is called. Now, it isn't
permanently frozen until the end of the construction of the first JSC::VM instance
in the process (just like the other Config records). This still guarantees that
it is frozen before any JS script can run.
- Previously, disablePrimitiveGigacage() works by nullifying the Primitive gigacage base pointer. We can no longer do that because the base pointer will be frozen on VM instantiation. Instead, if not forbidden, we now disable the Primitive gigacage by setting a disablePrimitiveGigacageRequested bool variable that is not frozen in the Gigacage::Config.
To check if the Primitive gigacage is enabled, the LLInt, AssemblyHelpers::cageConditionally(),
and runtime functions will check the following conditions:
g_gigacageConfig.basePtr(Primitive) &&
(disablingPrimitiveGigacageIsForbidden() disableNotRequestedForPrimitiveGigacage()) The base pointer being null means the gigacage was never set up.
If disablingPrimitiveGigacageIsForbidden() is true, then we don't care
whether a disable request has been received.
Otherwise, the gigacage is only enabled if it has been set up, and a
disable request has not been received.
Note that the first 2 terms are frozen in the Gigacage::Config. Only the
last term is a runtime variable. If disabling is forbidden, then the
runtime variable never comes into play.
The FTL does not rely on a runtime check for whether the Primitive gigacage is
enabled or not. Instead, it relies on a watchpoint to handle this. So, it
just works, and there's no performance penalty with adding the 2 extra terms
to check.
Note also that the jsc shell and the WebProcess will forbid disabling of the
Primitive gigacage. This means the AssemblyHelpers::cageConditionally() will
also not generate the runtime checks for the 2 extra terms.
Only the LLInt and runtime functions will have to do work to check the 2 extra
terms. But because these are not in perf critical paths, this is ok.
Note that we're deliberately gating the disablePrimitiveGigacageRequested
variable check on disablingPrimitiveGigacageIsForbidden though, logically, the
isEnable check does not really depend on whether disabling is forbidden or not.
We do this because disablingPrimitiveGigacageIsForbidden is frozen in the Config,
and it is, therefore, a stronger guarantee of correctness whereas the variable
can be corrupted.
- Replaced isDisablingPrimitiveGigacageForbidden(), canPrimitiveGigacageBeDisabled(), and isPrimitiveGigacagePermanentlyEnabled() with disablingPrimitiveGigacageIsForbidden().
- CMakeLists.txt:
- bmalloc.xcodeproj/project.pbxproj:
- bmalloc/Gigacage.cpp:
(Gigacage::ensureGigacage):
(Gigacage::disablePrimitiveGigacage):
(Gigacage::forbidDisablingPrimitiveGigacage):
(Gigacage::bmalloc::freezeGigacageConfig): Deleted.
(Gigacage::bmalloc::unfreezeGigacageConfig): Deleted.
(Gigacage::bmalloc::permanentlyFreezeGigacageConfig): Deleted.
(Gigacage::bmalloc::UnfreezeGigacageConfigScope::UnfreezeGigacageConfigScope): Deleted.
(Gigacage::bmalloc::UnfreezeGigacageConfigScope::~UnfreezeGigacageConfigScope): Deleted.
(Gigacage::isDisablingPrimitiveGigacageForbidden): Deleted.
- bmalloc/Gigacage.h:
(Gigacage::disablingPrimitiveGigacageIsForbidden):
(Gigacage::disableNotRequestedForPrimitiveGigacage):
(Gigacage::isEnabled):
(Gigacage::basePtr):
(Gigacage::caged):
(Gigacage::forbidDisablingPrimitiveGigacage):
(): Deleted.
(Gigacage::Config::basePtr const): Deleted.
(Gigacage::Config::setBasePtr): Deleted.
(Gigacage::isPrimitiveGigacagePermanentlyEnabled): Deleted.
(Gigacage::canPrimitiveGigacageBeDisabled): Deleted.
- bmalloc/GigacageConfig.h: Added.
(Gigacage::Config::basePtr const):
(Gigacage::Config::setBasePtr):
- bmalloc/GigacageKind.h: Added.
- bmalloc/Heap.cpp:
(bmalloc::Heap::usingGigacage):
- bmalloc/mbmalloc.cpp:
Source/JavaScriptCore:
- assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
- dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
- ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::caged):
- jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageConditionally):
- llint/LowLevelInterpreter64.asm:
- runtime/JSCConfig.h:
(JSC::Config::isPermanentlyFrozen):
Source/WTF:
We now think of the various Config records as being allocated from parts of a
WebConfig::g_config buffer. WTF::Config will manage the mechanics of freezing
that buffer. And the JSC VM is still the determiner of if/when to freeze the
buffer, and it will do this at the end of the construction of the very first
VM instance (as before).
Gigacage::Config reserves space in WebConfig::g_config.
WTF::Config will honor that reservation and place itself after that.
JSC::Config will continue to place itself at WTF::Config::spaceForExtensions.
The upside of this approach this is that we can now share the same memory page
for all the Configs, and can freeze them in one go.
The downside is that g_gigacageConfig, g_wtfConfig, and g_jscConfig now have to
be macros. This results in some weirdness e.g. they are no longer qualified by
namespaces: referring to WTF::g_wtfConfig is now incorrect.
- wtf/Gigacage.h:
(Gigacage::disablingPrimitiveGigacageIsForbidden):
(Gigacage::isDisablingPrimitiveGigacageForbidden): Deleted.
(Gigacage::isPrimitiveGigacagePermanentlyEnabled): Deleted.
(Gigacage::canPrimitiveGigacageBeDisabled): Deleted.
- wtf/WTFConfig.cpp:
(WTF::Config::permanentlyFreeze):
- wtf/WTFConfig.h:
(): Deleted.
- 11:43 AM Changeset in webkit [262433] by
-
- 2 edits in trunk/Source/WebCore
Avoid calling axBackingObject multiple times in [WebAccessibilityObjectWrapper roleDescription].
https://bugs.webkit.org/show_bug.cgi?id=212643
Reviewed by Chris Fleizach.
No new functionality.
Avoid unnecessary overhead of calling axBackingObject multiple times in
roleDescription. axBackingObject is not just a getter but involves
checking whether isolated tree mode is enabled.
- accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper subrole]):
(-[WebAccessibilityObjectWrapper roleDescription]):
- 11:38 AM Changeset in webkit [262432] by
-
- 4 edits in trunk
Allow using web processes for service workers even though they loaded about URLs
https://bugs.webkit.org/show_bug.cgi?id=212464
Reviewed by Chris Dumez.
Source/WebKit:
Before the patch, a web process that loads about:blank will not be able to run service workers.
A web process that is running service workers and is loading an about:blank page will also kill its service workers.
To prevent this, do not take into account about:blank URLs for the computation of the registrable domain of a process.
Covered by API tests.
- UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::didStartProvisionalLoadForMainFrame):
Tools:
- TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:
- 11:19 AM Changeset in webkit [262431] by
-
- 1 edit3 adds in trunk/LayoutTests
Landing expectations for tests that were recently imported but did not have them
Unreviewed test gardening
- platform/ios/imported/w3c/web-platform-tests/dom/events/scrolling/input-text-scroll-event-when-using-arrow-keys-expected.txt: Added.
- platform/ios/imported/w3c/web-platform-tests/dom/events/scrolling/overscroll-deltas-expected.txt: Added.
- 11:10 AM Changeset in webkit [262430] by
-
- 2 edits in trunk/Source/WebCore
Pass nullptr for the 2nd argument of FileReaderLoader
https://bugs.webkit.org/show_bug.cgi?id=212642
Patch by Tetsuharu Ohzeki <Tetsuharu Ohzeki> on 2020-06-02
Reviewed by Darin Adler.
Instead of passing
0,nullptris better
becauseFileReaderLoadertakes a pointer.
- fileapi/FileReaderSync.cpp:
(WebCore::FileReaderSync::readAsArrayBuffer):
(WebCore::FileReaderSync::readAsBinaryString):
(WebCore::FileReaderSync::readAsText):
(WebCore::FileReaderSync::readAsDataURL):
- 10:14 AM Changeset in webkit [262429] by
-
- 8 edits in trunk/Source/WebKit
macCatalyst: WKWebView's tint color is not propagated to Web Content process
https://bugs.webkit.org/show_bug.cgi?id=212630
Reviewed by Anders Carlsson.
- Shared/WebPageCreationParameters.cpp:
(WebKit::WebPageCreationParameters::encode const):
(WebKit::WebPageCreationParameters::decode):
- Shared/WebPageCreationParameters.h:
- UIProcess/Cocoa/PageClientImplCocoa.h:
- UIProcess/PageClient.h:
- UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::creationParameters):
- WebProcess/WebPage/WebPage.cpp:
- WebProcess/WebPage/WebPage.h:
- 10:11 AM Changeset in webkit [262428] by
-
- 3 edits in trunk/Source/WebCore
UIColor and NSColor WebCore::Color factories should return invalid colors for nil input colors
https://bugs.webkit.org/show_bug.cgi?id=212631
Reviewed by Anders Carlsson.
- platform/graphics/mac/ColorMac.mm:
(WebCore::colorFromNSColor):
(WebCore::semanticColorFromNSColor):
- platform/ios/ColorIOS.mm:
(WebCore::colorFromUIColor):
This doesn't affect any code currently in WebKit, but it is very, very surprising
that these functions happily accept a null color, assert in debug, but in release
do crazy things like try to paint the null color into a small bitmap to figure out
what it really is.
Also, this matches the behavior of the Color constructors that take CGColorRef.
- 10:09 AM Changeset in webkit [262427] by
-
- 2 edits in trunk/Source/WebKit
REGRESSION (r258949): Dynamic user accent color changes are not respected by WKWebView
https://bugs.webkit.org/show_bug.cgi?id=212628
<rdar://problem/63436275>
Reviewed by Per Arne Vollan.
Two issues with the "CFPrefs Direct Mode" mechanism caused dynamic changes to the
user accent color preference to not be respected anymore:
- the default change, when synchronized to the Web Content process, was
written into the wrong domain, because of bug 212627.
- AppKit caches the resolved accent color; the cache is invalidated when the
a CoreUI notification is posted. Since we synchronize preferences ourselves,
the ordering of the default change and notification are no longer guaranteed,
so AppKit sometimes reads and re-caches the old accent color.
- WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::userAccentColorPreferenceKey):
(WebKit::shouldWriteToAppDomainForPreferenceKey):
(WebKit::WebProcess::notifyPreferencesChanged):
To fix the first problem, write the default into the standardUserDefaults.
This is just a workaround, we need a more general solution to this problem
for all global preferences. We know it's OK in this case, because AppKit
happens to read from standardUserDefaults.
(WebKit::dispatchSimulatedNotificationsForPreferenceChange):
To fix the second problem, re-emit the notification once we have synchronized
the preference to the Web Content process.
- 10:07 AM Changeset in webkit [262426] by
-
- 2 edits in trunk/LayoutTests
[ iOS wk2 ] animations/play-state-paused.html is flaky failing.
https://bugs.webkit.org/show_bug.cgi?id=212641
Unreviewed test gardening.
- platform/ios-wk2/TestExpectations:
- 9:55 AM Changeset in webkit [262425] by
-
- 6 edits2 adds in trunk
MultiDeleteByOffset should not always def
https://bugs.webkit.org/show_bug.cgi?id=212621
<rdar://problem/63824182>
Reviewed by Yusuke Suzuki.
JSTests:
- stress/multi-del-by-offset-doesnt-always-def-osr-entry.js: Added.
(foo):
- stress/multi-del-by-offset-doesnt-always-def.js: Added.
(foo):
(let.p.set undefined):
Source/JavaScriptCore:
Clobberize used to claim that MultiDeleteByOffset always defd a value.
That's an incorrect modeling of MultiDeleteByOffset though, since it might
have delete misses in its variant list. This would lead us to incorrectly
CSE when we shouldn't. This patch fixes this by saying MultiDeleteByOffset
only defs when all its cases write out a value (are hits).
- dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
- dfg/DFGNode.cpp:
(JSC::DFG::MultiDeleteByOffsetData::allVariantsStoreEmpty const):
- dfg/DFGNode.h:
- ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMultiDeleteByOffset):
- 9:10 AM Changeset in webkit [262424] by
-
- 20 edits in trunk/Source
Make generated C++ code use modern C++
https://bugs.webkit.org/show_bug.cgi?id=190714
Patch by Rob Buis <rbuis@igalia.com> on 2020-06-02
Reviewed by Sam Weinig.
Source/JavaScriptCore:
Update inspector protocol generator and rebaseline the tests.
- inspector/scripts/codegen/cpp_generator_templates.py:
- inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
- inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
- inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
- inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
- inspector/scripts/tests/expected/enum-values.json-result:
- inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
- inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
- inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
- inspector/scripts/tests/expected/type-declaration-array-type.json-result:
- inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
- inspector/scripts/tests/expected/type-declaration-object-type.json-result:
- inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
- yarr/generateYarrUnicodePropertyTables.py:
Source/WebCore:
Replace typedef usage by alias-declaration.
No new tests. No change in behavior.
- css/makeprop.pl:
- dom/make_names.pl:
(printHeaderHead):
(printInit):
(printTypeHelpersHeaderFile):
(printFactoryCppFile):
(printFactoryHeaderFile):
(printWrapperFactoryCppFile):
(printWrapperFactoryHeaderFile):
Source/WebKit:
Replace typedef usage by alias-declaration.
- Scripts/webkit/messages.py:
- 9:05 AM Changeset in webkit [262423] by
-
- 2 edits in trunk/LayoutTests
[ iOS debug ] REGRESSION(r262254): imported/w3c/web-platform-tests/2dcontext/fill-and-stroke-styles/canvas_colorsandstyles_createlineargradient_001.htm is a constant timeout
https://bugs.webkit.org/show_bug.cgi?id=212636
Unreviewed test gardening
- platform/ios-wk2/TestExpectations:
- 8:41 AM Changeset in webkit [262422] by
-
- 3 edits in trunk/Source/ThirdParty/libwebrtc
Unreviewed, reverting r262290.
https://bugs.webkit.org/show_bug.cgi?id=212638
it is not yet ready (Requested by youenn on #webkit).
Reverted changeset:
"Enable VTB required low latency code path"
https://bugs.webkit.org/show_bug.cgi?id=210609
https://trac.webkit.org/changeset/262290
- 8:36 AM Changeset in webkit [262421] by
-
- 3 edits in trunk/Source/WebCore
Remove unused BlobURL::getIdentifier
https://bugs.webkit.org/show_bug.cgi?id=212635
Patch by Tetsuharu Ohzeki <Tetsuharu Ohzeki> on 2020-06-02
Reviewed by Youenn Fablet.
- fileapi/BlobURL.cpp:
- fileapi/BlobURL.h:
- 8:08 AM Changeset in webkit [262420] by
-
- 2 edits in trunk/LayoutTests
Removing expectations for a test that is now passing
https://bugs.webkit.org/show_bug.cgi?id=211920
Unreviewed test gardening
- platform/ios-wk2/TestExpectations:
- 7:19 AM Changeset in webkit [262419] by
-
- 2 edits in trunk/LayoutTests
[GLIB] Update TestExpectations Sections
https://bugs.webkit.org/show_bug.cgi?id=212586
Initial conversion from the "kind of failure" to the "feature" based
approach to organizing the glib test expectations.
This is an attempt to group related expectations closer together. At
the time of this patch, some sections are only related to the top
folder at LayoutTests, like WebAnimations, but others have entries
from multiple folders, like GStreamer, WebGL. More specific features
like EncryptedMedia will likely have their own sections even though it
could be seen as a subset of GStreamer.
In doubt, there is a NEEDS TRIAGING section at the end of the file
where one can put the failure if not sure about which existing section
it should go and ask for a more detailed investigation.
Reviewed by Carlos Alberto Lopez Perez.
- platform/glib/TestExpectations:
- 7:17 AM Changeset in webkit [262418] by
-
- 2 edits in trunk/Source/WebCore
Fix broken Windows build.
https://bugs.webkit.org/show_bug.cgi?id=212633
Reviewed by Yusuke Suzuki.
- html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::needsPreparationForDisplay):
(WebCore::HTMLCanvasElement::prepareForDisplay):
- 6:49 AM Changeset in webkit [262417] by
-
- 4 edits in trunk/Tools
[buildbot] [GTK][WPE] Move JavaScript related tests to own bot
https://bugs.webkit.org/show_bug.cgi?id=212481
Reviewed by Carlos Alberto Lopez Perez.
Currently GTK and WPE tests bots run too many tests. This makes
the total running time for each build very long.
This patch moves JavaScript related tests (jscore-test and
test262-test) to a separated bot which will be triggered by the
corresponding build bot of each platform.
- BuildSlaveSupport/build.webkit.org-config/config.json:
- BuildSlaveSupport/build.webkit.org-config/factories.py:
(TestFactory.init):
(TestJSFactory):
(TestJSFactory.init):
- BuildSlaveSupport/build.webkit.org-config/steps_unittest.py:
- 6:39 AM Changeset in webkit [262416] by
-
- 2 edits in trunk/Source/WebCore
Add some logging to ServiceWorkerThread to track install/activate event handling
https://bugs.webkit.org/show_bug.cgi?id=212523
Reviewed by Chris Dumez.
Add some logging for firing install/activate events and when these events are handled.
No change of behavior.
- workers/service/context/ServiceWorkerThread.cpp:
(WebCore::ServiceWorkerThread::queueTaskToFireInstallEvent):
(WebCore::ServiceWorkerThread::queueTaskToFireActivateEvent):
- 6:06 AM Changeset in webkit [262415] by
-
- 4 edits in trunk/Source/WebKit
[GTK4] Implement data list drop down menu
https://bugs.webkit.org/show_bug.cgi?id=212333
Reviewed by Adrian Perez de Castro.
Use a GtkPopover for GTK4 instead of a GtkMenu.
- UIProcess/API/gtk/PageClientImpl.cpp:
(WebKit::PageClientImpl::createDataListSuggestionsDropdown):
- UIProcess/gtk/WebDataListSuggestionsDropdownGtk.cpp:
(WebKit::WebDataListSuggestionsDropdownGtk::WebDataListSuggestionsDropdownGtk):
(WebKit::WebDataListSuggestionsDropdownGtk::~WebDataListSuggestionsDropdownGtk):
(WebKit::WebDataListSuggestionsDropdownGtk::show):
- UIProcess/gtk/WebDataListSuggestionsDropdownGtk.h:
- 6:04 AM Changeset in webkit [262414] by
-
- 11 edits in trunk
[GTK4] Make popup menus work
https://bugs.webkit.org/show_bug.cgi?id=211178
Reviewed by Adrian Perez de Castro.
Source/WebCore:
- platform/gtk/GtkVersioning.h:
(gtk_tree_view_column_cell_get_size):
Source/WebKit:
Use a GtkPopover for GTK4 instead of a GtkMenu.
- UIProcess/API/gtk/PageClientImpl.cpp:
(WebKit::PageClientImpl::createPopupMenuProxy):
- UIProcess/API/gtk/WebKitPopupMenu.cpp:
(WebKit::WebKitPopupMenu::WebKitPopupMenu):
(WebKit::menuCloseCallback):
(WebKit::WebKitPopupMenu::showPopupMenu):
(WebKit::WebKitPopupMenu::hidePopupMenu):
(WebKit::WebKitPopupMenu::cancelTracking):
(WebKit::WebKitPopupMenu::activateItem):
- UIProcess/API/gtk/WebKitPopupMenu.h:
- UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseSizeAllocate): Iterate children and call check_resize on every native one.
- UIProcess/gtk/WebPopupMenuProxyGtk.cpp:
(WebKit::WebPopupMenuProxyGtk::treeViewButtonReleaseEventCallback):
(WebKit::WebPopupMenuProxyGtk::createPopupMenu):
(WebKit::WebPopupMenuProxyGtk::showPopupMenu):
(WebKit::WebPopupMenuProxyGtk::hidePopupMenu):
(WebKit::WebPopupMenuProxyGtk::treeViewRowActivatedCallback): Deleted.
- UIProcess/gtk/WebPopupMenuProxyGtk.h:
Tools:
- WebKitTestRunner/gtk/PlatformWebViewGtk.cpp:
(WTR::PlatformWebView::dismissAllPopupMenus):
- 5:52 AM Changeset in webkit [262413] by
-
- 6 edits in trunk/Tools
[GTK4] Make it possible to run layout tests
https://bugs.webkit.org/show_bug.cgi?id=212328
Reviewed by Carlos Alberto Lopez Perez.
Build WTR with GTK4.
- PlatformGTK.cmake:
- Scripts/webkitdirs.pm:
(builtDylibPathForName): Try with both 4 and 5 API versions.
- WebKitTestRunner/gtk/EventSenderProxyGtk.cpp:
- WebKitTestRunner/gtk/PlatformWebViewGtk.cpp:
(WTR::PlatformWebView::PlatformWebView):
(WTR::PlatformWebView::~PlatformWebView):
(WTR::PlatformWebView::setWindowIsKey):
(WTR::PlatformWebView::windowFrame):
(WTR::PlatformWebView::setWindowFrame):
(WTR::PlatformWebView::addToWindow):
(WTR::PlatformWebView::removeFromWindow):
(WTR::PlatformWebView::windowSnapshotImage):
(WTR::PlatformWebView::dismissAllPopupMenus):
- WebKitTestRunner/gtk/UIScriptControllerGtk.cpp:
(WTR::UIScriptControllerGtk::copyText):
- 4:29 AM Changeset in webkit [262412] by
-
- 2 edits in trunk/Source/JavaScriptCore
Fix assert message formatting
https://bugs.webkit.org/show_bug.cgi?id=212591
Reviewed by Adrian Perez de Castro.
Fixes warning by gcc - lineParts.size() is size_t, %zu should be used.
- runtime/FuzzerPredictions.cpp:
(JSC::FuzzerPredictions::FuzzerPredictions):
- 4:28 AM Changeset in webkit [262411] by
-
- 4 edits in trunk
[css-flexbox] ChildIntrinsicLogicalWidth should use fit-content, not max-content
https://bugs.webkit.org/show_bug.cgi?id=210465
Reviewed by Javier Fernandez.
Source/WebCore:
When computing the hypothetical cross size of each item in the flexbox algorithm
the current code was using the max-size. However the specs state clearly that we
should use fit-content instead, i.e., the shrink-to-fit size.
See https://drafts.csswg.org/css-flexbox/#algo-cross-item.
Based on Blink's crrev.com/1327746 by <cbiesinger@chromium.org>
- rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::childIntrinsicLogicalWidth const): Use the shrink-to-fit
size instead just the max-size.
LayoutTests:
- TestExpectations: Unskipped flex-wrap-002.html which is now passing.
- 4:24 AM Changeset in webkit [262410] by
-
- 5 edits in trunk/Source/WebCore
MediaPlayerPrivateMediaStreamAVFObjC should enqueue samples in a background thread
https://bugs.webkit.org/show_bug.cgi?id=212073
Reviewed by Eric Carlson.
Do not hop to the main thread when rendering video samples anymore.
Instead, we enqueue to the display layer in the background thread but still hop to the main thread for two things:
- Update of various states of the player
- keep a ref to the video sample if canvas rendering is needed.
Most display layer operations stay in the main thread (creation, flushing...).
Deletion of the display layer and access from a background are covered by a lock.
The m_canEnqueueDisplayLayer boolean ensures we do not enqueue too early when the display layer is not yet properly initialized.
LocalSampleBufferDisplayLayer needs to handle the fact that enqueueing might be done in a background thread.
Instead of introducing a lock, we introduce a work queue and we hop to this queue whenever we need to enqueue/mutate the pending samples.
Covered by existing tests and manual testing.
- platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.h:
- platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.mm:
(-[WebAVSampleBufferStatusChangeListener observeValueForKeyPath:ofObject:change:context:]):
(WebCore::LocalSampleBufferDisplayLayer::enqueueSample):
(WebCore::LocalSampleBufferDisplayLayer::enqueueSampleBuffer):
(WebCore::LocalSampleBufferDisplayLayer::requestNotificationWhenReadyForVideoData):
- platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h:
- platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm:
(WebCore::videoTransformationMatrix):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::processNewVideoSampleAvailable):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::videoSampleAvailable):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::applicationDidBecomeActive):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::flushRenderers):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::ensureLayers):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::destroyLayers):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::updateRenderingMode):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::checkSelectedVideoTrack):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::paintCurrentFrameInContext):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::setBufferingPolicy):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::rootLayerBoundsDidChange):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::videoTransformationMatrix): Deleted.
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::enqueueCorrectedVideoSample): Deleted.
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::updateDisplayLayer): Deleted.
- 4:23 AM Changeset in webkit [262409] by
-
- 6 edits in trunk
[ Mac wk2 ] http/wpt/service-workers/service-worker-spinning-fetch.https.html is flaky failing.
https://bugs.webkit.org/show_bug.cgi?id=207515
<rdar://problem/59329307>
Reviewed by Chris Dumez.
Source/WebCore:
When a service worker is terminated, we remove it from the map in SWContextManager.
Shortly after a new service worker may be added to the map.
In that case, previously, we were potentially trying to decrement the message count of the old service worker thread, which is confusing the new service worker thread.
Instead, use WeakPtr to decrement if the service worker thread is still valid.
Covered by existing tests.
- workers/service/context/ServiceWorkerThread.cpp:
(WebCore::ServiceWorkerThread::queueTaskToPostMessage):
(WebCore::ServiceWorkerThread::queueTaskToFireInstallEvent):
(WebCore::ServiceWorkerThread::queueTaskToFireActivateEvent):
(WebCore::ServiceWorkerThread::start):
- workers/service/context/ServiceWorkerThread.h:
LayoutTests:
- http/wpt/service-workers/service-worker-spinning-fetch.https.html:
In case service worker gets closed, fetch failure might be logged as console log message.
- platform/mac-wk2/TestExpectations:
- 1:56 AM WebKitEmacsTips edited by
- (diff)
- 12:44 AM Changeset in webkit [262408] by
-
- 1 edit1 add in trunk
Add .editorconfig
https://bugs.webkit.org/show_bug.cgi?id=212463
Add .editorconfig for Visual Studio.
Initally following file types are supported:
- .h/.c/.cpp
- CMakeFilelist.txt/.cmake
- .editorconfig itself
Reviewed by Fujii Hironori.
- .editorconfig: Added.