2021-03-30 Alan Coon Cherry-pick r275214. rdar://problem/76022033 [LFC][Integration] Elements that overflow inline-blocks are not hit tested correctly https://bugs.webkit.org/show_bug.cgi?id=223932 rdar://75888718 Reviewed by Zalan Bujtas. Source/WebCore: If an inline block has overflowing children (for example due to negative margin) we may fail to hit test them. Test: fast/inline-block/hit-test-negative-margin-child.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Always descend into inline blocks even if their run didn't hit. LayoutTests: * fast/inline-block/hit-test-negative-margin-child-expected.txt: Added. * fast/inline-block/hit-test-negative-margin-child.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275214 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-30 Antti Koivisto [LFC][Integration] Elements that overflow inline-blocks are not hit tested correctly https://bugs.webkit.org/show_bug.cgi?id=223932 rdar://75888718 Reviewed by Zalan Bujtas. If an inline block has overflowing children (for example due to negative margin) we may fail to hit test them. Test: fast/inline-block/hit-test-negative-margin-child.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Always descend into inline blocks even if their run didn't hit. 2021-03-23 Russell Epstein Cherry-pick r271385. rdar://problem/75751024 [WinCairo] Unreviewed build fix for r271353 https://bugs.webkit.org/show_bug.cgi?id=220407 > CrossOriginAccessControl.cpp(225): error C3861: 'isInNetworkProcess': identifier not found * platform/RuntimeApplicationChecks.h: (WebCore::isInWebProcess): (WebCore::isInGPUProcess): (WebCore::isInNetworkProcess): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271385 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-11 Fujii Hironori [WinCairo] Unreviewed build fix for r271353 https://bugs.webkit.org/show_bug.cgi?id=220407 > CrossOriginAccessControl.cpp(225): error C3861: 'isInNetworkProcess': identifier not found * platform/RuntimeApplicationChecks.h: (WebCore::isInWebProcess): (WebCore::isInGPUProcess): (WebCore::isInNetworkProcess): 2021-03-17 Alan Coon Cherry-pick r274573. rdar://problem/75538214 Degraded ScriptProcessorNode performance/quality for (14.0.3+ and iOS 14.4.1+) https://bugs.webkit.org/show_bug.cgi?id=223380 Reviewed by Geoffrey Garen. By extending the scope of the lock in ScriptProcessorNode::process(), r273542 essentially disabled double-buffering and thus negatively impacted rendering quality. To address the issue, we now have 2 locks, one per rendering buffer (since we're using double buffering) and only grab the lock we require when interacting with the buffers for this index. This maintains thread-safety while re-enabling double buffering. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): Avoid duplicate call to topologyMatches() since copyTo() already calls it internally and returns false when !topologyMatches(). (WebCore::ScriptProcessorNode::process): * Modules/webaudio/ScriptProcessorNode.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274573 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-17 Chris Dumez Degraded ScriptProcessorNode performance/quality for (14.0.3+ and iOS 14.4.1+) https://bugs.webkit.org/show_bug.cgi?id=223380 Reviewed by Geoffrey Garen. By extending the scope of the lock in ScriptProcessorNode::process(), r273542 essentially disabled double-buffering and thus negatively impacted rendering quality. To address the issue, we now have 2 locks, one per rendering buffer (since we're using double buffering) and only grab the lock we require when interacting with the buffers for this index. This maintains thread-safety while re-enabling double buffering. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): Avoid duplicate call to topologyMatches() since copyTo() already calls it internally and returns false when !topologyMatches(). (WebCore::ScriptProcessorNode::process): * Modules/webaudio/ScriptProcessorNode.h: 2021-03-10 Russell Epstein Cherry-pick r274203. rdar://problem/75273198 Release assertion failures under Editor::scanSelectionForTelephoneNumbers https://bugs.webkit.org/show_bug.cgi?id=223016 Reviewed by Ryosuke Niwa. No new tests; speculative fix for a non-reproducible crash, which theoretically has been avoided in a second way on trunk. * editing/Editor.cpp: (WebCore::extendSelection): (WebCore::Editor::scanSelectionForTelephoneNumbers): In r272777, Ryosuke discovered a case where FrameSelection::isRange() can be true, but firstRange() is an invalid range; in testing, forcing this to be the case reproduces the crash as reported. While that change may have fixed the root cause of this crash, we don't know that we've found all of the ways that one can get a orphaned selection *into* FrameSelection, and want a less risky workaround for this crash, so we'll also fix it in scanSelectionForTelephoneNumbers, by null-checking the result of FrameSelection::firstRange(). Also null-check the result of extendSelection(), since I cannot prove for sure that a valid range cannot become invalid in this method. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274203 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-10 Tim Horton Release assertion failures under Editor::scanSelectionForTelephoneNumbers https://bugs.webkit.org/show_bug.cgi?id=223016 Reviewed by Ryosuke Niwa. No new tests; speculative fix for a non-reproducible crash, which theoretically has been avoided in a second way on trunk. * editing/Editor.cpp: (WebCore::extendSelection): (WebCore::Editor::scanSelectionForTelephoneNumbers): In r272777, Ryosuke discovered a case where FrameSelection::isRange() can be true, but firstRange() is an invalid range; in testing, forcing this to be the case reproduces the crash as reported. While that change may have fixed the root cause of this crash, we don't know that we've found all of the ways that one can get a orphaned selection *into* FrameSelection, and want a less risky workaround for this crash, so we'll also fix it in scanSelectionForTelephoneNumbers, by null-checking the result of FrameSelection::firstRange(). Also null-check the result of extendSelection(), since I cannot prove for sure that a valid range cannot become invalid in this method. 2021-03-04 Alan Coon Cherry-pick r273901. rdar://problem/75058990 window proxy of detached iframe doesn't respect updates to global values https://bugs.webkit.org/show_bug.cgi?id=206445 Reviewed by Chris Dumez. Source/WebCore: According to the html spec the frame should only be needing for COOP access violation reporting, which we don't support. This patch removes our old behavior of blocking stores to windows that have been detached. I also removed some stale caching code from getOwnPropertySlotByIndex since it's only accessed once now. * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::getOwnPropertySlotByIndex): (WebCore::JSDOMWindow::doPutPropertySecurityCheck): (WebCore::JSDOMWindow::put): (WebCore::JSDOMWindow::putByIndex): LayoutTests: * fast/frames/iframe-detached-window-still-writable-eval-expected.txt: Added. * fast/frames/iframe-detached-window-still-writable-eval.html: Added. * fast/frames/iframe-detached-window-still-writable-expected.txt: Added. * fast/frames/iframe-detached-window-still-writable.html: Added. * http/tests/dom/cross-origin-detached-window-properties-expected.txt: * http/tests/dom/cross-origin-detached-window-properties.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273901 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-04 Keith Miller window proxy of detached iframe doesn't respect updates to global values https://bugs.webkit.org/show_bug.cgi?id=206445 Reviewed by Chris Dumez. According to the html spec the frame should only be needing for COOP access violation reporting, which we don't support. This patch removes our old behavior of blocking stores to windows that have been detached. I also removed some stale caching code from getOwnPropertySlotByIndex since it's only accessed once now. * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::getOwnPropertySlotByIndex): (WebCore::JSDOMWindow::doPutPropertySecurityCheck): (WebCore::JSDOMWindow::put): (WebCore::JSDOMWindow::putByIndex): 2021-03-04 Alan Coon Cherry-pick r273842. rdar://problem/75049285 Crash under SubresourceLoader::notifyDone() https://bugs.webkit.org/show_bug.cgi?id=222683 Reviewed by Geoffrey Garen. We were crashing doing a null-dereference of m_documentLoader under SubresourceLoader::notifyDone(). This adds null checks for m_documentLoader similarly to what is already done elsewhere in ResourceLoader. No new tests, I do not know how to reproduce this. * loader/SubresourceLoader.cpp: (WebCore::SubresourceLoader::notifyDone): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273842 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-03 Chris Dumez Crash under SubresourceLoader::notifyDone() https://bugs.webkit.org/show_bug.cgi?id=222683 Reviewed by Geoffrey Garen. We were crashing doing a null-dereference of m_documentLoader under SubresourceLoader::notifyDone(). This adds null checks for m_documentLoader similarly to what is already done elsewhere in ResourceLoader. No new tests, I do not know how to reproduce this. * loader/SubresourceLoader.cpp: (WebCore::SubresourceLoader::notifyDone): 2021-03-03 Ruben Turcios Cherry-pick r273764. rdar://problem/74992878 The layout of SVGImage should force the layout for its clients https://bugs.webkit.org/show_bug.cgi?id=221253 Reviewed by Simon Fraser. Source/WebCore: Unlike the bitmap image, the intrinsic size of SVGImage can only be known after running its layout. Because SVGImage can be used by multiple clients, CachedImage maintains an SVGImageCache which maps a client to an SVGImageForContainer. SVGImageForContainer is just a wrapper of SVGImage with the intrinsic size of the client. Because we may set an entry for the renderer in SVGImageCache early before running a layout for SVGImage and because the renderer intrinsic size depends on the intrinsic size of SVGImage, SVGImageForContainer may have an empty intrinsic size. So basically it is a race condition: knowing the intrinsic size of the SVGImage client depends on the intrinsic size of SVGImage itself. And the intrinsic size of SVGImageForContainer depends on the intrinsic size of the client. This may lead to not rendering the clients because their sizes are empty. To fix this issue we need to force calculateBackgroundImageGeometry() once we finish the layout of the SVGImage which happens after receiving all its data and calling RenderBox::imageChanged(). Test: fast/css/background-svg-image-loading.html * loader/cache/CachedImage.cpp: (WebCore::CachedImage::finishLoading): * rendering/RenderBox.cpp: (WebCore::RenderBox::repaintLayerRectsForImage): LayoutTests: * fast/css/background-svg-image-loading-expected.html: Added. * fast/css/background-svg-image-loading.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273764 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-02 Said Abou-Hallawa The layout of SVGImage should force the layout for its clients https://bugs.webkit.org/show_bug.cgi?id=221253 Reviewed by Simon Fraser. Unlike the bitmap image, the intrinsic size of SVGImage can only be known after running its layout. Because SVGImage can be used by multiple clients, CachedImage maintains an SVGImageCache which maps a client to an SVGImageForContainer. SVGImageForContainer is just a wrapper of SVGImage with the intrinsic size of the client. Because we may set an entry for the renderer in SVGImageCache early before running a layout for SVGImage and because the renderer intrinsic size depends on the intrinsic size of SVGImage, SVGImageForContainer may have an empty intrinsic size. So basically it is a race condition: knowing the intrinsic size of the SVGImage client depends on the intrinsic size of SVGImage itself. And the intrinsic size of SVGImageForContainer depends on the intrinsic size of the client. This may lead to not rendering the clients because their sizes are empty. To fix this issue we need to force calculateBackgroundImageGeometry() once we finish the layout of the SVGImage which happens after receiving all its data and calling RenderBox::imageChanged(). Test: fast/css/background-svg-image-loading.html * loader/cache/CachedImage.cpp: (WebCore::CachedImage::finishLoading): * rendering/RenderBox.cpp: (WebCore::RenderBox::repaintLayerRectsForImage): 2021-03-02 Alan Coon Apply patch. rdar://problem/74944301 2021-03-02 Ryosuke Niwa Merge r272331. Optimize PointerCaptureController::elementWasRemoved() https://bugs.webkit.org/show_bug.cgi?id=221316 Reviewed by Ryosuke Niwa. Speedometer profiles show HashTable iteration code under PointerCaptureController::elementWasRemoved() because we always add a hash entry for the mouse pointer. Optimize away by setting a flag that's only true if any element is referenced by pointer capture. * page/PointerCaptureController.cpp: (WebCore::PointerCaptureController::pointerCaptureElement const): (WebCore::PointerCaptureController::setPointerCapture): (WebCore::PointerCaptureController::releasePointerCapture): (WebCore::PointerCaptureController::hasPointerCapture): (WebCore::PointerCaptureController::pointerLockWasApplied): (WebCore::PointerCaptureController::elementWasRemoved): (WebCore::PointerCaptureController::reset): (WebCore::PointerCaptureController::updateHaveAnyCapturingElement): (WebCore::PointerCaptureController::touchWithIdentifierWasRemoved): (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier const): (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier const): (WebCore::PointerCaptureController::pointerCaptureElement): Deleted. (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier): Deleted. (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier): Deleted. * page/PointerCaptureController.h: 2021-02-03 Simon Fraser Optimize PointerCaptureController::elementWasRemoved() https://bugs.webkit.org/show_bug.cgi?id=221316 Reviewed by Ryosuke Niwa. Speedometer profiles show HashTable iteration code under PointerCaptureController::elementWasRemoved() because we always add a hash entry for the mouse pointer. Optimize away by setting a flag that's only true if any element is referenced by pointer capture. * page/PointerCaptureController.cpp: (WebCore::PointerCaptureController::pointerCaptureElement const): (WebCore::PointerCaptureController::setPointerCapture): (WebCore::PointerCaptureController::releasePointerCapture): (WebCore::PointerCaptureController::hasPointerCapture): (WebCore::PointerCaptureController::pointerLockWasApplied): (WebCore::PointerCaptureController::elementWasRemoved): (WebCore::PointerCaptureController::reset): (WebCore::PointerCaptureController::updateHaveAnyCapturingElement): (WebCore::PointerCaptureController::touchWithIdentifierWasRemoved): (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier const): (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier const): (WebCore::PointerCaptureController::pointerCaptureElement): Deleted. (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier): Deleted. (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier): Deleted. * page/PointerCaptureController.h: 2021-03-01 Ryosuke Niwa Merge r272299. Avoid a virtual function call in HTMLFormControlElement::isDisabledOrReadOnly() https://bugs.webkit.org/show_bug.cgi?id=221319 Reviewed by Wenson Hsieh. Avoid calling isDisabledFormControl() which is a virtual function on Element. HTMLFormControlElement is the only class in its hierarchy that implements this, so we can just copy its implementation. * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::isDisabledOrReadOnly const): 2021-02-02 Simon Fraser Avoid a virtual function call in HTMLFormControlElement::isDisabledOrReadOnly() https://bugs.webkit.org/show_bug.cgi?id=221319 Reviewed by Wenson Hsieh. Avoid calling isDisabledFormControl() which is a virtual function on Element. HTMLFormControlElement is the only class in its hierarchy that implements this, so we can just copy its implementation. * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::isDisabledOrReadOnly const): 2021-03-01 Ryosuke Niwa Merge r272298. Avoid a virtual function call in HTMLInputElement::value() https://bugs.webkit.org/show_bug.cgi?id=221318 Reviewed by Wenson Hsieh. Only file upload controls override getTypeSpecificValue(), so to avoid a virtual function call, check the type first via canHaveTypeSpecificValue(). * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::value const): * html/InputType.h: (WebCore::InputType::canHaveTypeSpecificValue const): 2021-02-02 Simon Fraser Avoid a virtual function call in HTMLInputElement::value() https://bugs.webkit.org/show_bug.cgi?id=221318 Reviewed by Wenson Hsieh. Only file upload controls override getTypeSpecificValue(), so to avoid a virtual function call, check the type first via canHaveTypeSpecificValue(). * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::value const): * html/InputType.h: (WebCore::InputType::canHaveTypeSpecificValue const): 2021-03-01 Ryosuke Niwa Merge r272180. Devirtualize InputType::supportsValidation() https://bugs.webkit.org/show_bug.cgi?id=221216 Reviewed by Yusuke Suzuki. InputType::supportsValidation() can just check the type. Use an OptionSet<> of exclusions for clarity. * html/ButtonInputType.cpp: (WebCore::ButtonInputType::supportsValidation const): Deleted. * html/ButtonInputType.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::supportsValidation const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::supportsValidation const): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::supportsValidation const): Deleted. * html/InputType.h: (WebCore::InputType::supportsValidation const): * html/ResetInputType.cpp: (WebCore::ResetInputType::supportsValidation const): Deleted. * html/ResetInputType.h: 2021-02-01 Simon Fraser Devirtualize InputType::supportsValidation() https://bugs.webkit.org/show_bug.cgi?id=221216 Reviewed by Yusuke Suzuki. InputType::supportsValidation() can just check the type. Use an OptionSet<> of exclusions for clarity. * html/ButtonInputType.cpp: (WebCore::ButtonInputType::supportsValidation const): Deleted. * html/ButtonInputType.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::supportsValidation const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::supportsValidation const): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::supportsValidation const): Deleted. * html/InputType.h: (WebCore::InputType::supportsValidation const): * html/ResetInputType.cpp: (WebCore::ResetInputType::supportsValidation const): Deleted. * html/ResetInputType.h: 2021-03-01 Ryosuke Niwa Merge r272097. Devirtualize some functions on InputType https://bugs.webkit.org/show_bug.cgi?id=221121 Reviewed by Yusuke Suzuki. Virtual functions on InputType show up in Speedometer profiles. We can make many of these virtual functions non-virtual by just switching on the input type. * dom/Element.cpp: * html/BaseCheckableInputType.cpp: (WebCore::BaseCheckableInputType::isCheckable): Deleted. * html/BaseCheckableInputType.h: * html/BaseTextInputType.cpp: (WebCore::BaseTextInputType::isTextType const): Deleted. * html/BaseTextInputType.h: * html/ButtonInputType.cpp: (WebCore::ButtonInputType::isTextButton const): Deleted. * html/ButtonInputType.h: * html/CheckboxInputType.cpp: (WebCore::CheckboxInputType::isCheckbox const): Deleted. * html/CheckboxInputType.h: * html/ColorInputType.cpp: (WebCore::ColorInputType::isColorControl const): Deleted. * html/ColorInputType.h: * html/DateInputType.cpp: (WebCore::DateInputType::isDateField const): Deleted. * html/DateInputType.h: * html/DateTimeLocalInputType.cpp: (WebCore::DateTimeLocalInputType::isDateTimeLocalField const): Deleted. * html/DateTimeLocalInputType.h: * html/EmailInputType.cpp: (WebCore::EmailInputType::isEmailField const): Deleted. * html/EmailInputType.h: * html/FileInputType.cpp: (WebCore::FileInputType::isFileUpload const): Deleted. * html/FileInputType.h: * html/FormAssociatedElement.h: * html/HTMLFormControlElement.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::isHiddenType const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::isImageButton const): Deleted. (WebCore::ImageInputType::isEnumeratable): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::isTextType const): (WebCore::InputType::isTextField const): (WebCore::InputType::isTextButton const): (WebCore::InputType::isInteractiveContent const): (WebCore::InputType::supportLabels const): (WebCore::InputType::isEnumeratable): (WebCore::InputType::isCheckable): (WebCore::InputType::isRangeControl const): Deleted. (WebCore::InputType::isRadioButton const): Deleted. (WebCore::InputType::isSearchField const): Deleted. (WebCore::InputType::isHiddenType const): Deleted. (WebCore::InputType::isPasswordField const): Deleted. (WebCore::InputType::isCheckbox const): Deleted. (WebCore::InputType::isEmailField const): Deleted. (WebCore::InputType::isFileUpload const): Deleted. (WebCore::InputType::isImageButton const): Deleted. (WebCore::InputType::isNumberField const): Deleted. (WebCore::InputType::isSubmitButton const): Deleted. (WebCore::InputType::isTelephoneField const): Deleted. (WebCore::InputType::isURLField const): Deleted. (WebCore::InputType::isDateField const): Deleted. (WebCore::InputType::isDateTimeField const): Deleted. (WebCore::InputType::isDateTimeLocalField const): Deleted. (WebCore::InputType::isMonthField const): Deleted. (WebCore::InputType::isTimeField const): Deleted. (WebCore::InputType::isWeekField const): Deleted. (WebCore::InputType::isColorControl const): Deleted. * html/InputType.h: (WebCore::InputType::isCheckbox const): (WebCore::InputType::isColorControl const): (WebCore::InputType::isDateField const): (WebCore::InputType::isDateTimeField const): (WebCore::InputType::isDateTimeLocalField const): (WebCore::InputType::isEmailField const): (WebCore::InputType::isFileUpload const): (WebCore::InputType::isHiddenType const): (WebCore::InputType::isImageButton const): (WebCore::InputType::isMonthField const): (WebCore::InputType::isNumberField const): (WebCore::InputType::isPasswordField const): (WebCore::InputType::isRadioButton const): (WebCore::InputType::isRangeControl const): (WebCore::InputType::isSearchField const): (WebCore::InputType::isSubmitButton const): (WebCore::InputType::isTelephoneField const): (WebCore::InputType::isTimeField const): (WebCore::InputType::isURLField const): (WebCore::InputType::isWeekField const): * html/MonthInputType.cpp: (WebCore::MonthInputType::isMonthField const): Deleted. * html/MonthInputType.h: * html/NumberInputType.cpp: (WebCore::NumberInputType::isNumberField const): Deleted. * html/NumberInputType.h: * html/PasswordInputType.cpp: (WebCore::PasswordInputType::isPasswordField const): Deleted. * html/PasswordInputType.h: * html/RadioInputType.cpp: (WebCore::RadioInputType::isRadioButton const): Deleted. * html/RadioInputType.h: * html/RangeInputType.cpp: (WebCore::RangeInputType::isRangeControl const): Deleted. * html/RangeInputType.h: * html/ResetInputType.cpp: (WebCore::ResetInputType::isTextButton const): Deleted. * html/ResetInputType.h: * html/SearchInputType.cpp: (WebCore::SearchInputType::isSearchField const): Deleted. * html/SearchInputType.h: * html/SubmitInputType.cpp: (WebCore::SubmitInputType::isSubmitButton const): Deleted. (WebCore::SubmitInputType::isTextButton const): Deleted. * html/SubmitInputType.h: * html/TelephoneInputType.cpp: (WebCore::TelephoneInputType::isTelephoneField const): Deleted. * html/TelephoneInputType.h: * html/TextFieldInputType.cpp: (WebCore::TextFieldInputType::isTextField const): Deleted. * html/TextFieldInputType.h: * html/TimeInputType.cpp: (WebCore::TimeInputType::isTimeField const): Deleted. * html/TimeInputType.h: * html/URLInputType.cpp: (WebCore::URLInputType::isURLField const): Deleted. * html/URLInputType.h: * html/WeekInputType.cpp: (WebCore::WeekInputType::isWeekField const): Deleted. * html/WeekInputType.h: 2021-01-29 Simon Fraser Devirtualize some functions on InputType https://bugs.webkit.org/show_bug.cgi?id=221121 Reviewed by Yusuke Suzuki. Virtual functions on InputType show up in Speedometer profiles. We can make many of these virtual functions non-virtual by just switching on the input type. * dom/Element.cpp: * html/BaseCheckableInputType.cpp: (WebCore::BaseCheckableInputType::isCheckable): Deleted. * html/BaseCheckableInputType.h: * html/BaseTextInputType.cpp: (WebCore::BaseTextInputType::isTextType const): Deleted. * html/BaseTextInputType.h: * html/ButtonInputType.cpp: (WebCore::ButtonInputType::isTextButton const): Deleted. * html/ButtonInputType.h: * html/CheckboxInputType.cpp: (WebCore::CheckboxInputType::isCheckbox const): Deleted. * html/CheckboxInputType.h: * html/ColorInputType.cpp: (WebCore::ColorInputType::isColorControl const): Deleted. * html/ColorInputType.h: * html/DateInputType.cpp: (WebCore::DateInputType::isDateField const): Deleted. * html/DateInputType.h: * html/DateTimeLocalInputType.cpp: (WebCore::DateTimeLocalInputType::isDateTimeLocalField const): Deleted. * html/DateTimeLocalInputType.h: * html/EmailInputType.cpp: (WebCore::EmailInputType::isEmailField const): Deleted. * html/EmailInputType.h: * html/FileInputType.cpp: (WebCore::FileInputType::isFileUpload const): Deleted. * html/FileInputType.h: * html/FormAssociatedElement.h: * html/HTMLFormControlElement.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::isHiddenType const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::isImageButton const): Deleted. (WebCore::ImageInputType::isEnumeratable): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::isTextType const): (WebCore::InputType::isTextField const): (WebCore::InputType::isTextButton const): (WebCore::InputType::isInteractiveContent const): (WebCore::InputType::supportLabels const): (WebCore::InputType::isEnumeratable): (WebCore::InputType::isCheckable): (WebCore::InputType::isRangeControl const): Deleted. (WebCore::InputType::isRadioButton const): Deleted. (WebCore::InputType::isSearchField const): Deleted. (WebCore::InputType::isHiddenType const): Deleted. (WebCore::InputType::isPasswordField const): Deleted. (WebCore::InputType::isCheckbox const): Deleted. (WebCore::InputType::isEmailField const): Deleted. (WebCore::InputType::isFileUpload const): Deleted. (WebCore::InputType::isImageButton const): Deleted. (WebCore::InputType::isNumberField const): Deleted. (WebCore::InputType::isSubmitButton const): Deleted. (WebCore::InputType::isTelephoneField const): Deleted. (WebCore::InputType::isURLField const): Deleted. (WebCore::InputType::isDateField const): Deleted. (WebCore::InputType::isDateTimeField const): Deleted. (WebCore::InputType::isDateTimeLocalField const): Deleted. (WebCore::InputType::isMonthField const): Deleted. (WebCore::InputType::isTimeField const): Deleted. (WebCore::InputType::isWeekField const): Deleted. (WebCore::InputType::isColorControl const): Deleted. * html/InputType.h: (WebCore::InputType::isCheckbox const): (WebCore::InputType::isColorControl const): (WebCore::InputType::isDateField const): (WebCore::InputType::isDateTimeField const): (WebCore::InputType::isDateTimeLocalField const): (WebCore::InputType::isEmailField const): (WebCore::InputType::isFileUpload const): (WebCore::InputType::isHiddenType const): (WebCore::InputType::isImageButton const): (WebCore::InputType::isMonthField const): (WebCore::InputType::isNumberField const): (WebCore::InputType::isPasswordField const): (WebCore::InputType::isRadioButton const): (WebCore::InputType::isRangeControl const): (WebCore::InputType::isSearchField const): (WebCore::InputType::isSubmitButton const): (WebCore::InputType::isTelephoneField const): (WebCore::InputType::isTimeField const): (WebCore::InputType::isURLField const): (WebCore::InputType::isWeekField const): * html/MonthInputType.cpp: (WebCore::MonthInputType::isMonthField const): Deleted. * html/MonthInputType.h: * html/NumberInputType.cpp: (WebCore::NumberInputType::isNumberField const): Deleted. * html/NumberInputType.h: * html/PasswordInputType.cpp: (WebCore::PasswordInputType::isPasswordField const): Deleted. * html/PasswordInputType.h: * html/RadioInputType.cpp: (WebCore::RadioInputType::isRadioButton const): Deleted. * html/RadioInputType.h: * html/RangeInputType.cpp: (WebCore::RangeInputType::isRangeControl const): Deleted. * html/RangeInputType.h: * html/ResetInputType.cpp: (WebCore::ResetInputType::isTextButton const): Deleted. * html/ResetInputType.h: * html/SearchInputType.cpp: (WebCore::SearchInputType::isSearchField const): Deleted. * html/SearchInputType.h: * html/SubmitInputType.cpp: (WebCore::SubmitInputType::isSubmitButton const): Deleted. (WebCore::SubmitInputType::isTextButton const): Deleted. * html/SubmitInputType.h: * html/TelephoneInputType.cpp: (WebCore::TelephoneInputType::isTelephoneField const): Deleted. * html/TelephoneInputType.h: * html/TextFieldInputType.cpp: (WebCore::TextFieldInputType::isTextField const): Deleted. * html/TextFieldInputType.h: * html/TimeInputType.cpp: (WebCore::TimeInputType::isTimeField const): Deleted. * html/TimeInputType.h: * html/URLInputType.cpp: (WebCore::URLInputType::isURLField const): Deleted. * html/URLInputType.h: * html/WeekInputType.cpp: (WebCore::WeekInputType::isWeekField const): Deleted. * html/WeekInputType.h: 2021-03-01 Alan Coon Cherry-pick r273564. rdar://problem/74886917 [Cocoa] Register VP9 decoders when PlatformMediaSessionManager is created https://bugs.webkit.org/show_bug.cgi?id=222473 Reviewed by Eric Carlson. Source/WebCore: Currently, VP9 decoders are registered when a Web page is created in the WebContent process. Instead, VP9 decoders can be registered when PlatformMediaSessionManager is created, which should be a slight performance improvement, since calls into media frameworks will then not be made unconditionally when creating a Web page, but delayed until required. No new tests, covered by existing tests. * platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::setShouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP9SWDecoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9SWDecoder): * platform/audio/PlatformMediaSessionManager.h: * platform/audio/cocoa/MediaSessionManagerCocoa.mm: (WebCore::MediaSessionManagerCocoa::MediaSessionManagerCocoa): Source/WebKit: Currently, VP9 decoders are registered when a Web page is created in the WebContent process. Instead, VP9 decoders can be registered when PlatformMediaSessionManager is created, which should be a slight performance improvement, since calls into media frameworks will then not be made unconditionally when creating a Web page, but delayed until required. * WebProcess/WebPage/WebPage.cpp: (WebKit::m_lastNavigationWasAppBound): * WebProcess/WebProcess.cpp: (WebKit::WebProcess::enableVP9Decoder): Deleted. (WebKit::WebProcess::enableVP8SWDecoder): Deleted. (WebKit::WebProcess::enableVP9SWDecoder): Deleted. * WebProcess/WebProcess.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273564 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-26 Per Arne [Cocoa] Register VP9 decoders when PlatformMediaSessionManager is created https://bugs.webkit.org/show_bug.cgi?id=222473 Reviewed by Eric Carlson. Currently, VP9 decoders are registered when a Web page is created in the WebContent process. Instead, VP9 decoders can be registered when PlatformMediaSessionManager is created, which should be a slight performance improvement, since calls into media frameworks will then not be made unconditionally when creating a Web page, but delayed until required. No new tests, covered by existing tests. * platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::setShouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP9SWDecoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9SWDecoder): * platform/audio/PlatformMediaSessionManager.h: * platform/audio/cocoa/MediaSessionManagerCocoa.mm: (WebCore::MediaSessionManagerCocoa::MediaSessionManagerCocoa): 2021-03-01 Alan Coon Cherry-pick r273656. rdar://problem/74883377 REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. Source/WebCore: To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): LayoutTests: Add a new test where an element with a non-identity transform starts a transform transition with a long delay. Prior to this patch, this test failed because, while in the delay phase, the transition would mean the underlying transform was applied twice: once by the non-interpolating animation generated for the underlying "transform" value, and once by the first keyframe of the transition since it fills backwards. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform-expected.html: Added. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273656 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-01 Antoine Quint REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): 2021-03-01 Kocsen Chung Cherry-pick r273583. rdar://problem/74881429 Add AXTextMarkerRangeForNSRange attribute so that Mac clients can access this functionality. https://bugs.webkit.org/show_bug.cgi?id=222477 Source/WebCore: Reviewed by Chris Fleizach. This is a follow up to: https://bugs.webkit.org/show_bug.cgi?id=222154. As Chris Fleizach pointed out in the above review, it is necessary to add a handler in accessibilityAttributeValue:forParameter: for a new AX attribute in order for clients to access this functionality. * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): (-[WebAccessibilityObjectWrapper textMarkerRangeForNSRange:]): Deleted. Tools: Reviewed by Chris Fleizach. * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::AccessibilityUIElement::textMarkerRangeForRange): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273583 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-26 Andres Gonzalez Add AXTextMarkerRangeForNSRange attribute so that Mac clients can access this functionality. https://bugs.webkit.org/show_bug.cgi?id=222477 Reviewed by Chris Fleizach. This is a follow up to: https://bugs.webkit.org/show_bug.cgi?id=222154. As Chris Fleizach pointed out in the above review, it is necessary to add a handler in accessibilityAttributeValue:forParameter: for a new AX attribute in order for clients to access this functionality. * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): (-[WebAccessibilityObjectWrapper textMarkerRangeForNSRange:]): Deleted. 2021-03-01 Kocsen Chung Cherry-pick r273227. rdar://problem/74880937 Add [WebAccessibilityObjectWrapper textMarkerRangeForNSRange] to allow clients to efficiently get a TextMarkerRange from an NSRange. https://bugs.webkit.org/show_bug.cgi?id=222154 Reviewed by Chris Fleizach and Darin Adler. Source/WebCore: Test: accessibility/mac/textmarker-range-for-range.html Clients like VoiceOver often need the ability to convert a text range into an accessibility TextMarkerRange. This patch adds [WebAccessibilityObjectWrapper textMarkerRangeForNSRange] to allow clients to efficiently perform this conversion. This is the Mac implementation, iOS implementation is pending. * accessibility/AccessibilityObject.h: (WebCore::AccessibilityObject::allowsTextRanges const): * accessibility/AccessibilityObjectInterface.h: * accessibility/isolatedtree/AXIsolatedObject.h: * accessibility/isolatedtree/mac/AXIsolatedObjectMac.mm: (WebCore::AXIsolatedObject::textMarkerRangeForNSRange const): * accessibility/mac/AccessibilityObjectMac.mm: (WebCore::AccessibilityObject::textMarkerRangeForNSRange const): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper textMarkerRangeForNSRange:]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): Only advance the CharacterIterator if not atEnd yet. Tools: * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp: (WTR::AccessibilityUIElement::textMarkerRangeForRange): * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::AccessibilityUIElement::textMarkerRangeForRange): LayoutTests: * accessibility/mac/textmarker-range-for-range-expected.txt: Added. * accessibility/mac/textmarker-range-for-range.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273227 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-21 Andres Gonzalez Add [WebAccessibilityObjectWrapper textMarkerRangeForNSRange] to allow clients to efficiently get a TextMarkerRange from an NSRange. https://bugs.webkit.org/show_bug.cgi?id=222154 Reviewed by Chris Fleizach and Darin Adler. Test: accessibility/mac/textmarker-range-for-range.html Clients like VoiceOver often need the ability to convert a text range into an accessibility TextMarkerRange. This patch adds [WebAccessibilityObjectWrapper textMarkerRangeForNSRange] to allow clients to efficiently perform this conversion. This is the Mac implementation, iOS implementation is pending. * accessibility/AccessibilityObject.h: (WebCore::AccessibilityObject::allowsTextRanges const): * accessibility/AccessibilityObjectInterface.h: * accessibility/isolatedtree/AXIsolatedObject.h: * accessibility/isolatedtree/mac/AXIsolatedObjectMac.mm: (WebCore::AXIsolatedObject::textMarkerRangeForNSRange const): * accessibility/mac/AccessibilityObjectMac.mm: (WebCore::AccessibilityObject::textMarkerRangeForNSRange const): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper textMarkerRangeForNSRange:]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): Only advance the CharacterIterator if not atEnd yet. 2021-02-26 Alan Coon Cherry-pick r273558. rdar://problem/74800042 Unreviewed, address post-landing review feedback for r273542. Update a comment and fix a check that was reversed. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createOutputBufferForJS const): (WebCore::ScriptProcessorNode::process): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273558 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-26 Chris Dumez Unreviewed, address post-landing review feedback for r273542. Update a comment and fix a check that was reversed. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createOutputBufferForJS const): (WebCore::ScriptProcessorNode::process): 2021-02-26 Alan Coon Cherry-pick r273542. rdar://problem/74800042 Fix threading issue in ScriptProcessorNode::process() https://bugs.webkit.org/show_bug.cgi?id=222447 Reviewed by Jer Noble. It was possible for the audio thread (in ScriptProcessorNode::process()) and the main thread (via ScriptProcessorNode::fireProcessEvent()) to access the same m_inputBuffers / m_outputBuffers concurrently, causing crashes. The m_processLock was supposed to avoid this. However, the scope of the locking in ScriptProcessorNode::process() was insufficient to protect us. ScriptProcessorNode::process() now grabs the lock very early, before interacting with any buffers and we make sure not to modify the buffers when we are unable to grab the lock. Also, to make sure that the m_inputBuffers / m_outputBuffers are modified by the main thread only during the scope of the fireProcessEvent() function (during which we hold the processLock), we no longer pass our internal buffers to the JS process event handler. Instead, we pass new buffers to JS and memcpy to and from them. While this is less efficient, this is actually required because the script could store the buffers it is given and modify them outside the scope of the process event handler. * Modules/webaudio/AudioBuffer.cpp: (WebCore::AudioBuffer::AudioBuffer): (WebCore::AudioBuffer::topologyMatches const): (WebCore::AudioBuffer::copyTo const): (WebCore::AudioBuffer::clone const): * Modules/webaudio/AudioBuffer.h: * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): (WebCore::ScriptProcessorNode::createOutputBufferForJS const): (WebCore::ScriptProcessorNode::process): (WebCore::ScriptProcessorNode::fireProcessEvent): * Modules/webaudio/ScriptProcessorNode.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273542 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Chris Dumez Fix threading issue in ScriptProcessorNode::process() https://bugs.webkit.org/show_bug.cgi?id=222447 Reviewed by Jer Noble. It was possible for the audio thread (in ScriptProcessorNode::process()) and the main thread (via ScriptProcessorNode::fireProcessEvent()) to access the same m_inputBuffers / m_outputBuffers concurrently, causing crashes. The m_processLock was supposed to avoid this. However, the scope of the locking in ScriptProcessorNode::process() was insufficient to protect us. ScriptProcessorNode::process() now grabs the lock very early, before interacting with any buffers and we make sure not to modify the buffers when we are unable to grab the lock. Also, to make sure that the m_inputBuffers / m_outputBuffers are modified by the main thread only during the scope of the fireProcessEvent() function (during which we hold the processLock), we no longer pass our internal buffers to the JS process event handler. Instead, we pass new buffers to JS and memcpy to and from them. While this is less efficient, this is actually required because the script could store the buffers it is given and modify them outside the scope of the process event handler. * Modules/webaudio/AudioBuffer.cpp: (WebCore::AudioBuffer::AudioBuffer): (WebCore::AudioBuffer::topologyMatches const): (WebCore::AudioBuffer::copyTo const): (WebCore::AudioBuffer::clone const): * Modules/webaudio/AudioBuffer.h: * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): (WebCore::ScriptProcessorNode::createOutputBufferForJS const): (WebCore::ScriptProcessorNode::process): (WebCore::ScriptProcessorNode::fireProcessEvent): * Modules/webaudio/ScriptProcessorNode.h: 2021-02-26 Alan Coon Cherry-pick r273512. rdar://problem/74799698 REGRESSION(r269957): Empty font names passed to canvas2d cause all text routines to crash https://bugs.webkit.org/show_bug.cgi?id=222402 Reviewed by Darin Adler and Chris Lord. Source/WebCore: It looks like it was simply an oversight from that patch. If the font name is empty, CanvasRenderingContext2D::setFont() will set the font object to one that doesn't have its internal FontCascadeFonts pointer set. Tests: fast/text/canvas-font-resolution-2.html fast/text/canvas-font-resolution.html * html/canvas/CanvasRenderingContext2D.cpp: (WebCore::CanvasRenderingContext2D::setFont): * html/canvas/CanvasRenderingContext2DBase.h: (WebCore::CanvasRenderingContext2DBase::FontProxy::isPopulated const): * style/StyleResolveForFontRaw.cpp: (WebCore::Style::resolveForFontRaw): LayoutTests: * fast/text/canvas-font-resolution-2-expected.html: Added. * fast/text/canvas-font-resolution-2.html: Added. * fast/text/canvas-font-resolution-expected.txt: Added. * fast/text/canvas-font-resolution.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273512 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Myles C. Maxfield REGRESSION(r269957): Empty font names passed to canvas2d cause all text routines to crash https://bugs.webkit.org/show_bug.cgi?id=222402 Reviewed by Darin Adler and Chris Lord. It looks like it was simply an oversight from that patch. If the font name is empty, CanvasRenderingContext2D::setFont() will set the font object to one that doesn't have its internal FontCascadeFonts pointer set. Tests: fast/text/canvas-font-resolution-2.html fast/text/canvas-font-resolution.html * html/canvas/CanvasRenderingContext2D.cpp: (WebCore::CanvasRenderingContext2D::setFont): * html/canvas/CanvasRenderingContext2DBase.h: (WebCore::CanvasRenderingContext2DBase::FontProxy::isPopulated const): * style/StyleResolveForFontRaw.cpp: (WebCore::Style::resolveForFontRaw): 2021-02-26 Alan Coon Cherry-pick r273498. rdar://problem/74800989 [iOS] Crash when playing Dolby Atmos audio tracks with AVAudioTimePitchAlgorithmTimeDomain https://bugs.webkit.org/show_bug.cgi?id=222420 Reviewed by Eric Carlson. CoreAudio throws an assertion when using the TimeDomain pitch-correction algorithm on tracks with > 2 channels. To work around this assertion for now, only set the pitch-correction algorithm when the playbackRate is set to a non 0 or 1 value. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::audioTimePitchAlgorithmForMediaPlayerPitchCorrectionAlgorithm): (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPlayerRate): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPreservesPitch): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPitchCorrectionAlgorithm): (WebCore::MediaPlayerPrivateAVFoundationObjC::playerItemStatusDidChange): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273498 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Jer Noble [iOS] Crash when playing Dolby Atmos audio tracks with AVAudioTimePitchAlgorithmTimeDomain https://bugs.webkit.org/show_bug.cgi?id=222420 Reviewed by Eric Carlson. CoreAudio throws an assertion when using the TimeDomain pitch-correction algorithm on tracks with > 2 channels. To work around this assertion for now, only set the pitch-correction algorithm when the playbackRate is set to a non 0 or 1 value. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::audioTimePitchAlgorithmForMediaPlayerPitchCorrectionAlgorithm): (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPlayerRate): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPreservesPitch): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPitchCorrectionAlgorithm): (WebCore::MediaPlayerPrivateAVFoundationObjC::playerItemStatusDidChange): 2021-02-26 Alan Coon Cherry-pick r273539. rdar://problem/74798808 Emoji sequences with constituents in the UBLOCK_SYMBOLS_AND_PICTOGRAPHS_EXTENDED_A Unicode block don't get combined properly https://bugs.webkit.org/show_bug.cgi?id=222438 Reviewed by Zalan Bujtas. Source/WebCore: Just add UBLOCK_SYMBOLS_AND_PICTOGRAPHS_EXTENDED_A to the list. We have to do some workarounds because not all versions of ICU include this value. Luckily, these workarounds are compile-time-only, because we we're only using this value to compare to a value produced by ICU (not a value we pass into ICU). Test: fast/text/mending-heart.html * platform/text/CharacterProperties.h: (WebCore::isEmojiGroupCandidate): LayoutTests: * fast/text/mending-heart-expected.txt: Added. * fast/text/mending-heart.html: Added. * platform/ios/TestExpectations: * platform/mac/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273539 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Myles C. Maxfield Emoji sequences with constituents in the UBLOCK_SYMBOLS_AND_PICTOGRAPHS_EXTENDED_A Unicode block don't get combined properly https://bugs.webkit.org/show_bug.cgi?id=222438 Reviewed by Zalan Bujtas. Just add UBLOCK_SYMBOLS_AND_PICTOGRAPHS_EXTENDED_A to the list. We have to do some workarounds because not all versions of ICU include this value. Luckily, these workarounds are compile-time-only, because we we're only using this value to compare to a value produced by ICU (not a value we pass into ICU). Test: fast/text/mending-heart.html * platform/text/CharacterProperties.h: (WebCore::isEmojiGroupCandidate): 2021-02-25 Russell Epstein Cherry-pick r273442. rdar://problem/74753214 Regression(r269481) Kugou Music: Can not leave "MV" category after selecting it https://bugs.webkit.org/show_bug.cgi?id=222380 Reviewed by Geoffrey Garen. The new behavior in r269481 aligns us with the specification and with Blink so I am adding a linked-on-after to maintain pre-r269481 behavior until Apps get rebuilt against the new SDK. * html/HTMLDocument.cpp: (WebCore::HTMLDocument::supportedPropertyNames const): * page/Quirks.cpp: (WebCore::Quirks::shouldOmitHTMLDocumentSupportedPropertyNames): * page/Quirks.h: * platform/cocoa/VersionChecks.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273442 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-24 Chris Dumez Regression(r269481) Kugou Music: Can not leave "MV" category after selecting it https://bugs.webkit.org/show_bug.cgi?id=222380 Reviewed by Geoffrey Garen. The new behavior in r269481 aligns us with the specification and with Blink so I am adding a linked-on-after to maintain pre-r269481 behavior until Apps get rebuilt against the new SDK. * html/HTMLDocument.cpp: (WebCore::HTMLDocument::supportedPropertyNames const): * page/Quirks.cpp: (WebCore::Quirks::shouldOmitHTMLDocumentSupportedPropertyNames): * page/Quirks.h: * platform/cocoa/VersionChecks.h: 2021-02-25 Russell Epstein Cherry-pick r273501. rdar://problem/74760623 [Cocoa] Files from webmfiles.org do not play through MSE https://bugs.webkit.org/show_bug.cgi?id=222403 Reviewed by Eric Carlson. Source/WebCore: Test: media/media-source/media-source-webm-vp8-malformed-header.html As per RFC 6386, each VP8 frame begins with a three-byte (minimum) frame header, with extra bytes if that preamble indicates that the frame is a keyframe. Files from webmfiles.org (and others) have valid frame headers for keyframes, but invalid or no header for interframes; these interframes' headers, when parsed, erroneously report they are keyframes, and thus the optional extra bytes are parsed, fail parsing, and generate an error. Rather than drop frames when parsing fails, just assume the frame is an interframe, and proceed normally. * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::VideoTrackData::consumeFrameData): LayoutTests: * platform/mac-bigsur/media/media-source/content/test-vp8-malformed-header-manifest.json: Added. * platform/mac-bigsur/media/media-source/content/test-vp8-malformed-header.webm: Added. * platform/mac-bigsur/media/media-source/media-source-webm-vp8-malformed-header-expected.txt: Added. * platform/mac-bigsur/media/media-source/media-source-webm-vp8-malformed-header.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273501 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Jer Noble [Cocoa] Files from webmfiles.org do not play through MSE https://bugs.webkit.org/show_bug.cgi?id=222403 Reviewed by Eric Carlson. Test: media/media-source/media-source-webm-vp8-malformed-header.html As per RFC 6386, each VP8 frame begins with a three-byte (minimum) frame header, with extra bytes if that preamble indicates that the frame is a keyframe. Files from webmfiles.org (and others) have valid frame headers for keyframes, but invalid or no header for interframes; these interframes' headers, when parsed, erroneously report they are keyframes, and thus the optional extra bytes are parsed, fail parsing, and generate an error. Rather than drop frames when parsing fails, just assume the frame is an interframe, and proceed normally. * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::VideoTrackData::consumeFrameData): 2021-02-25 Russell Epstein Cherry-pick r273499. rdar://problem/74766327 Avoid setting page muted state if unchanged https://bugs.webkit.org/show_bug.cgi?id=222395 Reviewed by Brent Fulgham. Return early in Page::setMuted if muted state did not change. No new tests, covered by existing tests. * page/Page.cpp: (WebCore::Page::setMuted): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273499 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Per Arne Vollan Avoid setting page muted state if unchanged https://bugs.webkit.org/show_bug.cgi?id=222395 Reviewed by Brent Fulgham. Return early in Page::setMuted if muted state did not change. No new tests, covered by existing tests. * page/Page.cpp: (WebCore::Page::setMuted): 2021-02-25 Russell Epstein Cherry-pick r273477. rdar://problem/74766196 Avoid heap allocation for EventContexts https://bugs.webkit.org/show_bug.cgi?id=222095 Reviewed by Simon Fraser. This patch merges all subclasses of EventContext into itself to avoid heap allocation for each EventContext in EventPath::m_path. It also merges Node::handleLocalEvents into EventContext's handleLocalEvents to avoid the extra virtual function call. No new tests since there should be no observable behavioral differences. * dom/EventContext.cpp: (WebCore::EventContext::EventContext): Moved to the header to be inlined. (WebCore::EventContext::handleLocalEvents const): Merged handleLocalEvents of HTMLFormElement and Node. Moved the code to handle related target and touch targets from MouseOrFocusEventContext and TouchEventContext as they have been merged into this class. Also special case dispatching an event on window to preserve the behavior of WindowEventContext. (WebCore::EventContext::initializeTouchLists): Added. Creates TouchList objects. (WebCore::EventContext::isUnreachableNode const): Moved from the header. (WebCore::EventContext::isMouseOrFocusEventContext const): Deleted. (WebCore::EventContext::isTouchEventContext const): Deleted. (WebCore::MouseOrFocusEventContext::MouseOrFocusEventContext): Deleted. (WebCore::MouseOrFocusEventContext::handleLocalEvents const): Deleted. (WebCore::MouseOrFocusEventContext::isMouseOrFocusEventContext const): Deleted. (WebCore::TouchEventContext::TouchEventContext): Deleted. (WebCore::TouchEventContext::handleLocalEvents const): Deleted. (WebCore::TouchEventContext::isTouchEventContext const): Deleted. (WebCore::TouchEventContext::checkReachability const): Deleted. Merged into handleLocalEvents. * dom/EventContext.h: (WebCore::EventContext::isMouseOrFocusEventContext const): Now simply checks m_type. (WebCore::EventContext::isTouchEventContext const): Ditto. (WebCore::EventContext::isWindowContext const): Ditto. (WebCore::EventContext::relatedTarget const): Moved from MouseOrFocusEventContext. (WebCore::EventContext::setRelatedTarget): Ditto. (WebCore::EventContext::touchList): Moved from TouchEventContext. (WebCore::m_contextNodeIsFormElement): Added. Caching this state here instead of checking it at every event context during dispatching in EventContext::handleLocalEvents seems to be important to get a speed up in Intel processors. Apple silicons don't seem to be affected by this. (WebCore::m_type): Added. (WebCore::MouseOrFocusEventContext): Deleted. (WebCore::MouseOrFocusEventContext::relatedTarget const): Deleted. (WebCore::TouchEventContext): Deleted. (WebCore::EventContext::EventContext): Moved from cpp file to be inlined here. (WebCore::EventContext::isUnreachableNode const): Moved into cpp as this is only used for asserting shadow DOM related conditions. (WebCore::EventContext::touchList): Renamed from TouchEventContext::touchList. (isType): Deleted. * dom/EventDispatcher.cpp: (WebCore::EventDispatcher::dispatchEvent): Deleted the variant that takes a vector of elements since it's not used anywhere. * dom/EventDispatcher.h: * dom/EventPath.cpp: (WebCore::WindowEventContext): Deleted. (WebCore::EventPath::EventPath): Avoid calling setRelatedTarget if related target is not a node or the path is empty. These were early return conditions in setRelatedTarget before this patch. (WebCore::EventPath::buildPath): Always create EventContext. Dramatically simplifies the code. (WebCore::EventPath::setRelatedTarget): Moved the early exit to EventPath::EventPath. (WebCore::EventPath::retargetTouch): (WebCore::EventPath::retargetTouchList): (WebCore::EventPath::retargetTouchLists): (WebCore::EventPath::EventPath): Deleted the variant which takes a vector of elements as it's not used anywhere. * dom/EventPath.h: (WebCore::EventPath::contextAt const): (WebCore::EventPath::contextAt): (WebCore::EventPath::m_path): Now allocates EventContext in place. The size of the inline buffer has been reduced to 16 entries for EventContext from 32 entries for std::unique_ptr since the former is considerably larger than the latter. * dom/Node.cpp: (WebCore::Node::handleLocalEvents): Deleted. Merged into EventContext::handleLocalEvents. * dom/Node.h: * html/HTMLFormElement.cpp: (WebCore::HTMLFormElement::handleLocalEvents): Ditto. * html/HTMLFormElement.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273477 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Ryosuke Niwa Avoid heap allocation for EventContexts https://bugs.webkit.org/show_bug.cgi?id=222095 Reviewed by Simon Fraser. This patch merges all subclasses of EventContext into itself to avoid heap allocation for each EventContext in EventPath::m_path. It also merges Node::handleLocalEvents into EventContext's handleLocalEvents to avoid the extra virtual function call. No new tests since there should be no observable behavioral differences. * dom/EventContext.cpp: (WebCore::EventContext::EventContext): Moved to the header to be inlined. (WebCore::EventContext::handleLocalEvents const): Merged handleLocalEvents of HTMLFormElement and Node. Moved the code to handle related target and touch targets from MouseOrFocusEventContext and TouchEventContext as they have been merged into this class. Also special case dispatching an event on window to preserve the behavior of WindowEventContext. (WebCore::EventContext::initializeTouchLists): Added. Creates TouchList objects. (WebCore::EventContext::isUnreachableNode const): Moved from the header. (WebCore::EventContext::isMouseOrFocusEventContext const): Deleted. (WebCore::EventContext::isTouchEventContext const): Deleted. (WebCore::MouseOrFocusEventContext::MouseOrFocusEventContext): Deleted. (WebCore::MouseOrFocusEventContext::handleLocalEvents const): Deleted. (WebCore::MouseOrFocusEventContext::isMouseOrFocusEventContext const): Deleted. (WebCore::TouchEventContext::TouchEventContext): Deleted. (WebCore::TouchEventContext::handleLocalEvents const): Deleted. (WebCore::TouchEventContext::isTouchEventContext const): Deleted. (WebCore::TouchEventContext::checkReachability const): Deleted. Merged into handleLocalEvents. * dom/EventContext.h: (WebCore::EventContext::isMouseOrFocusEventContext const): Now simply checks m_type. (WebCore::EventContext::isTouchEventContext const): Ditto. (WebCore::EventContext::isWindowContext const): Ditto. (WebCore::EventContext::relatedTarget const): Moved from MouseOrFocusEventContext. (WebCore::EventContext::setRelatedTarget): Ditto. (WebCore::EventContext::touchList): Moved from TouchEventContext. (WebCore::m_contextNodeIsFormElement): Added. Caching this state here instead of checking it at every event context during dispatching in EventContext::handleLocalEvents seems to be important to get a speed up in Intel processors. Apple silicons don't seem to be affected by this. (WebCore::m_type): Added. (WebCore::MouseOrFocusEventContext): Deleted. (WebCore::MouseOrFocusEventContext::relatedTarget const): Deleted. (WebCore::TouchEventContext): Deleted. (WebCore::EventContext::EventContext): Moved from cpp file to be inlined here. (WebCore::EventContext::isUnreachableNode const): Moved into cpp as this is only used for asserting shadow DOM related conditions. (WebCore::EventContext::touchList): Renamed from TouchEventContext::touchList. (isType): Deleted. * dom/EventDispatcher.cpp: (WebCore::EventDispatcher::dispatchEvent): Deleted the variant that takes a vector of elements since it's not used anywhere. * dom/EventDispatcher.h: * dom/EventPath.cpp: (WebCore::WindowEventContext): Deleted. (WebCore::EventPath::EventPath): Avoid calling setRelatedTarget if related target is not a node or the path is empty. These were early return conditions in setRelatedTarget before this patch. (WebCore::EventPath::buildPath): Always create EventContext. Dramatically simplifies the code. (WebCore::EventPath::setRelatedTarget): Moved the early exit to EventPath::EventPath. (WebCore::EventPath::retargetTouch): (WebCore::EventPath::retargetTouchList): (WebCore::EventPath::retargetTouchLists): (WebCore::EventPath::EventPath): Deleted the variant which takes a vector of elements as it's not used anywhere. * dom/EventPath.h: (WebCore::EventPath::contextAt const): (WebCore::EventPath::contextAt): (WebCore::EventPath::m_path): Now allocates EventContext in place. The size of the inline buffer has been reduced to 16 entries for EventContext from 32 entries for std::unique_ptr since the former is considerably larger than the latter. * dom/Node.cpp: (WebCore::Node::handleLocalEvents): Deleted. Merged into EventContext::handleLocalEvents. * dom/Node.h: * html/HTMLFormElement.cpp: (WebCore::HTMLFormElement::handleLocalEvents): Ditto. * html/HTMLFormElement.h: 2021-02-25 Russell Epstein Cherry-pick r273438. rdar://problem/74753272 Regression(r268700) postMessage changes prototype of basic types https://bugs.webkit.org/show_bug.cgi?id=222228 Reviewed by Geoffrey Garen. Source/WebCore: r268700 updated ScriptExecutionContext::globalObject() to call: `WebCore::globalObject(mainThreadNormalWorld(), downcast(*this).page())` instead of `frame ? frame->script().globalObject(mainThreadNormalWorld()) : nullptr` This was not right for subframes because globalObject() gets the globalObject from the page's main frame instead of the document's frame. This patch gets rid of the error-prone WebCore::globalObject() taking in a Page* and replaces it with one taking in a Frame* to avoid such issues in the future. Test: fast/dom/Window/postMessage-Object-prototype.html * bindings/js/ScriptState.cpp: (WebCore::globalObject): * bindings/js/ScriptState.h: * dom/ScriptExecutionContext.cpp: (WebCore::ScriptExecutionContext::globalObject): * inspector/InspectorFrontendHost.cpp: (WebCore::InspectorFrontendHost::addSelfToGlobalObjectInWorld): (WebCore::InspectorFrontendHost::showContextMenu): LayoutTests: Add layout test coverage. * fast/dom/Window/postMessage-Object-prototype-expected.txt: Added. * fast/dom/Window/postMessage-Object-prototype.html: Added. * fast/dom/Window/resources/postMessage-Object-prototype-frame.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273438 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-24 Chris Dumez Regression(r268700) postMessage changes prototype of basic types https://bugs.webkit.org/show_bug.cgi?id=222228 Reviewed by Geoffrey Garen. r268700 updated ScriptExecutionContext::globalObject() to call: `WebCore::globalObject(mainThreadNormalWorld(), downcast(*this).page())` instead of `frame ? frame->script().globalObject(mainThreadNormalWorld()) : nullptr` This was not right for subframes because globalObject() gets the globalObject from the page's main frame instead of the document's frame. This patch gets rid of the error-prone WebCore::globalObject() taking in a Page* and replaces it with one taking in a Frame* to avoid such issues in the future. Test: fast/dom/Window/postMessage-Object-prototype.html * bindings/js/ScriptState.cpp: (WebCore::globalObject): * bindings/js/ScriptState.h: * dom/ScriptExecutionContext.cpp: (WebCore::ScriptExecutionContext::globalObject): * inspector/InspectorFrontendHost.cpp: (WebCore::InspectorFrontendHost::addSelfToGlobalObjectInWorld): (WebCore::InspectorFrontendHost::showContextMenu): 2021-02-25 Russell Epstein Cherry-pick r273415. rdar://problem/74763807 Move PostResolutionCallbackDisabler to resolveComputedStyle https://bugs.webkit.org/show_bug.cgi?id=222350 Reviewed by Ryosuke Niwa. It can be constructed and deleted repeatedly in styleForElementIgnoringPendingStylesheets when resolveComputedStyle calls it in a loop. * dom/Document.cpp: (WebCore::Document::styleForElementIgnoringPendingStylesheets): * dom/Element.cpp: (WebCore::Element::resolveComputedStyle): (WebCore::Element::resolvePseudoElementStyle): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273415 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-24 Antti Koivisto Move PostResolutionCallbackDisabler to resolveComputedStyle https://bugs.webkit.org/show_bug.cgi?id=222350 Reviewed by Ryosuke Niwa. It can be constructed and deleted repeatedly in styleForElementIgnoringPendingStylesheets when resolveComputedStyle calls it in a loop. * dom/Document.cpp: (WebCore::Document::styleForElementIgnoringPendingStylesheets): * dom/Element.cpp: (WebCore::Element::resolveComputedStyle): (WebCore::Element::resolvePseudoElementStyle): 2021-02-25 Russell Epstein Cherry-pick r273385. rdar://problem/74753323 Runtime-disabled CSS features still appear enabled via CSS.supports() https://bugs.webkit.org/show_bug.cgi?id=222280 rdar://74595641 Reviewed by Sam Weinig. Source/WebCore: When parsing CSS.supports() for a runtime-disabled property, we'd successfully parse a CSS-wide keyword like "inherit" and report that the property is supported. We need to explicitly check for runtime-disabled properties. Tests: css3/color-filters/color-filter-exposed-if-disabled.html fast/css/scroll-behavior-exposed-if-disabled.html * css/parser/CSSParserImpl.cpp: (WebCore::CSSParserImpl::isPropertyRuntimeDisabled const): (WebCore::CSSParserImpl::consumeDeclaration): * css/parser/CSSParserImpl.h: LayoutTests: * css3/color-filters/color-filter-exposed-if-disabled-expected.txt: Added. Fails tracked in webkit.org/b/217626 * css3/color-filters/color-filter-exposed-if-disabled.html: Added. * fast/css/overscroll-behavior-invalidate-if-disabled-expected.txt: * fast/css/overscroll-behavior-invalidate-if-disabled.html: * fast/css/scroll-behavior-exposed-if-disabled-expected.txt: Added. * fast/css/scroll-behavior-exposed-if-disabled.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273385 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-24 Simon Fraser Runtime-disabled CSS features still appear enabled via CSS.supports() https://bugs.webkit.org/show_bug.cgi?id=222280 rdar://74595641 Reviewed by Sam Weinig. When parsing CSS.supports() for a runtime-disabled property, we'd successfully parse a CSS-wide keyword like "inherit" and report that the property is supported. We need to explicitly check for runtime-disabled properties. Tests: css3/color-filters/color-filter-exposed-if-disabled.html fast/css/scroll-behavior-exposed-if-disabled.html * css/parser/CSSParserImpl.cpp: (WebCore::CSSParserImpl::isPropertyRuntimeDisabled const): (WebCore::CSSParserImpl::consumeDeclaration): * css/parser/CSSParserImpl.h: 2021-02-25 Russell Epstein Cherry-pick r273314. rdar://problem/74753323 aspect-ratio shows in computed style when disabled https://bugs.webkit.org/show_bug.cgi?id=222286 Patch by Rob Buis on 2021-02-23 Reviewed by Simon Fraser. Source/WebCore: Make aspect-ratio invisible from style when disabled. Test: fast/css/aspect-ratio-invalidate-if-disabled.html * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyInStyle): * css/CSSProperties.json: Tools: Add support for disabling aspect-ratio in wk1. * DumpRenderTree/TestOptions.cpp: (WTR::TestOptions::defaults): LayoutTests: Add test. * fast/css/aspect-ratio-invalidate-if-disabled-expected.txt: Added. * fast/css/aspect-ratio-invalidate-if-disabled.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273314 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-23 Rob Buis aspect-ratio shows in computed style when disabled https://bugs.webkit.org/show_bug.cgi?id=222286 Reviewed by Simon Fraser. Make aspect-ratio invisible from style when disabled. Test: fast/css/aspect-ratio-invalidate-if-disabled.html * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyInStyle): * css/CSSProperties.json: 2021-01-25 Chris Dumez Unreviewed, add missing header includes to address build issues. * Modules/webauthn/AuthenticationExtensionsClientOutputs.h: 2021-02-25 Alan Coon Cherry-pick r272039. rdar://problem/74451201 [GPUP][MSE] A video element does not fire “canplaythrough” event if SourceBuffer.abort() is called https://bugs.webkit.org/show_bug.cgi?id=220964 Reviewed by Jer Noble. Source/WebCore: This patch removes `initializationSegmentIsHandledSemaphore` from both `SourceBufferParserAVFObjC` and `SourceBufferParserWebM`, and implements a media sample cache mechanism in `SourceBufferPrivateAVFObjC` to ensure that "Coded Frame Processing" steps execute after `SourceBufferPrivate` has handled the initialization segment and enabled video/audio tracks. Without the cache mechanism, some media samples following the initialization segment may be dropped when we run `SourceBufferPrivateAVFObjC` in the GPU process, and the media element won't fire "canplaythrough" event because it cannot change its ready state to a value greater than HAVE_METADATA. This patch also implements the mechanism to make sure `SourceBufferPrivateAVFObjC::appendCompleted()` runs after all media samples have gone through the "Coded Frame Processing" steps, so that the source buffer object will fire "update" and "updateend" event after the parser has completedly parsed the appended buffer. * platform/graphics/avfoundation/objc/SourceBufferParserAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferParserAVFObjC.mm: (WebCore::SourceBufferParserAVFObjC::SourceBufferParserAVFObjC): (WebCore::SourceBufferParserAVFObjC::~SourceBufferParserAVFObjC): (WebCore::SourceBufferParserAVFObjC::appendData): Add a parameter "CompletionHandler" to notify the caller that the parser has parsed the whole buffer. (WebCore::SourceBufferParserAVFObjC::flushPendingMediaData): (WebCore::SourceBufferParserAVFObjC::resetParserState): (WebCore::SourceBufferParserAVFObjC::invalidate): (WebCore::SourceBufferParserAVFObjC::didParseStreamDataAsAsset): * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::SourceBufferPrivateAVFObjC): (WebCore::SourceBufferPrivateAVFObjC::~SourceBufferPrivateAVFObjC): (WebCore::SourceBufferPrivateAVFObjC::didParseInitializationData): After `SourceBufferPrivateClient` has done the configuration with the initialization segment, we need to push the cached media samples (if any) to `SourceBufferPrivate` to run the "Coded Frame Processing" steps. And we need to call "appendCompleted()" if there is a pending callback. (WebCore::SourceBufferPrivateAVFObjC::didProvideMediaDataForTrackId): `SourceBufferPrivateAVFObjC` needs to cache the media sample if the initialization segment has not been processed by `SourceBufferPrivateClient` yet. (WebCore::SourceBufferPrivateAVFObjC::append): We need to postpone the "appendCompleted()" callback if there are cached media samples. (WebCore::SourceBufferPrivateAVFObjC::appendCompleted): (WebCore::SourceBufferPrivateAVFObjC::abort): (WebCore::SourceBufferPrivateAVFObjC::setVideoLayer): (WebCore::SourceBufferPrivateAVFObjC::didProvideMediaDataForTrackID): Deleted. * platform/graphics/cocoa/SourceBufferParser.h: * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::SourceBufferParserWebM): (WebCore::SourceBufferParserWebM::~SourceBufferParserWebM): (WebCore::SourceBufferParserWebM::appendData): (WebCore::SourceBufferParserWebM::flushPendingMediaData): (WebCore::SourceBufferParserWebM::resetParserState): (WebCore::SourceBufferParserWebM::invalidate): (WebCore::SourceBufferParserWebM::OnClusterBegin): * platform/graphics/cocoa/SourceBufferParserWebM.h: Source/WebKit: * Shared/mac/MediaFormatReader/MediaFormatReader.cpp: (WebKit::MediaFormatReader::parseByteSource): LayoutTests: * gpu-process/TestExpectations: * media/media-source/media-source-webm-append-buffer-after-abort-expected.txt: Added. * media/media-source/media-source-webm-append-buffer-after-abort.html: Added. * platform/mac/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272039 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-28 Peng Liu [GPUP][MSE] A video element does not fire “canplaythrough” event if SourceBuffer.abort() is called https://bugs.webkit.org/show_bug.cgi?id=220964 Reviewed by Jer Noble. This patch removes `initializationSegmentIsHandledSemaphore` from both `SourceBufferParserAVFObjC` and `SourceBufferParserWebM`, and implements a media sample cache mechanism in `SourceBufferPrivateAVFObjC` to ensure that "Coded Frame Processing" steps execute after `SourceBufferPrivate` has handled the initialization segment and enabled video/audio tracks. Without the cache mechanism, some media samples following the initialization segment may be dropped when we run `SourceBufferPrivateAVFObjC` in the GPU process, and the media element won't fire "canplaythrough" event because it cannot change its ready state to a value greater than HAVE_METADATA. This patch also implements the mechanism to make sure `SourceBufferPrivateAVFObjC::appendCompleted()` runs after all media samples have gone through the "Coded Frame Processing" steps, so that the source buffer object will fire "update" and "updateend" event after the parser has completedly parsed the appended buffer. * platform/graphics/avfoundation/objc/SourceBufferParserAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferParserAVFObjC.mm: (WebCore::SourceBufferParserAVFObjC::SourceBufferParserAVFObjC): (WebCore::SourceBufferParserAVFObjC::~SourceBufferParserAVFObjC): (WebCore::SourceBufferParserAVFObjC::appendData): Add a parameter "CompletionHandler" to notify the caller that the parser has parsed the whole buffer. (WebCore::SourceBufferParserAVFObjC::flushPendingMediaData): (WebCore::SourceBufferParserAVFObjC::resetParserState): (WebCore::SourceBufferParserAVFObjC::invalidate): (WebCore::SourceBufferParserAVFObjC::didParseStreamDataAsAsset): * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::SourceBufferPrivateAVFObjC): (WebCore::SourceBufferPrivateAVFObjC::~SourceBufferPrivateAVFObjC): (WebCore::SourceBufferPrivateAVFObjC::didParseInitializationData): After `SourceBufferPrivateClient` has done the configuration with the initialization segment, we need to push the cached media samples (if any) to `SourceBufferPrivate` to run the "Coded Frame Processing" steps. And we need to call "appendCompleted()" if there is a pending callback. (WebCore::SourceBufferPrivateAVFObjC::didProvideMediaDataForTrackId): `SourceBufferPrivateAVFObjC` needs to cache the media sample if the initialization segment has not been processed by `SourceBufferPrivateClient` yet. (WebCore::SourceBufferPrivateAVFObjC::append): We need to postpone the "appendCompleted()" callback if there are cached media samples. (WebCore::SourceBufferPrivateAVFObjC::appendCompleted): (WebCore::SourceBufferPrivateAVFObjC::abort): (WebCore::SourceBufferPrivateAVFObjC::setVideoLayer): (WebCore::SourceBufferPrivateAVFObjC::didProvideMediaDataForTrackID): Deleted. * platform/graphics/cocoa/SourceBufferParser.h: * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::SourceBufferParserWebM): (WebCore::SourceBufferParserWebM::~SourceBufferParserWebM): (WebCore::SourceBufferParserWebM::appendData): (WebCore::SourceBufferParserWebM::flushPendingMediaData): (WebCore::SourceBufferParserWebM::resetParserState): (WebCore::SourceBufferParserWebM::invalidate): (WebCore::SourceBufferParserWebM::OnClusterBegin): * platform/graphics/cocoa/SourceBufferParserWebM.h: 2021-02-24 Russell Epstein Cherry-pick r272906. rdar://problem/74410175 [LFC][Integration] Pass child inline block scroll overflow to parent https://bugs.webkit.org/show_bug.cgi?id=221958 rdar://74050874 Reviewed by Zalan Bujtas. Source/WebCore: Integrated LFC fails to pass through overflow from nested inline blocks. Test: fast/overflow/inline-block-scroll-overflow.html * layout/integration/LayoutIntegrationInlineContentBuilder.cpp: (WebCore::LayoutIntegration::InlineContentBuilder::InlineContentBuilder): (WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLines const): Find the associated RenderBox and collect overflow from it. * layout/integration/LayoutIntegrationInlineContentBuilder.h: * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::constructContent): LayoutTests: * fast/overflow/inline-block-scroll-overflow-expected.html: Added. * fast/overflow/inline-block-scroll-overflow.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272906 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Antti Koivisto [LFC][Integration] Pass child inline block scroll overflow to parent https://bugs.webkit.org/show_bug.cgi?id=221958 rdar://74050874 Reviewed by Zalan Bujtas. Integrated LFC fails to pass through overflow from nested inline blocks. Test: fast/overflow/inline-block-scroll-overflow.html * layout/integration/LayoutIntegrationInlineContentBuilder.cpp: (WebCore::LayoutIntegration::InlineContentBuilder::InlineContentBuilder): (WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLines const): Find the associated RenderBox and collect overflow from it. * layout/integration/LayoutIntegrationInlineContentBuilder.h: * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::constructContent): 2021-02-24 Russell Epstein Cherry-pick r272977. rdar://problem/74500812 REGRESSION (r266695): Unable to scroll the menu in 北京114预约挂号 official account - WeChat https://bugs.webkit.org/show_bug.cgi?id=221948 Reviewed by Simon Fraser. r266695 caused this to regress, but it actually is a progression, because all browsers agree that this content, as it exists in the app, doesn't scroll. So, we don't want to revert the change itself, because it's a good change, but we also want to make sure that WeChat continues to work. So, we can temporarily quirk one particular element in the WeChat app, until the the content can be fixed (). Because this is a WeChat-specific quirk, it is untestable. I tested manually. * page/Quirks.cpp: (WebCore::Quirks::needsWeChatScrollingQuirk const): * page/Quirks.h: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isWechat): * platform/cocoa/VersionChecks.h: * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjustForSiteSpecificQuirks const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272977 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Myles C. Maxfield REGRESSION (r266695): Unable to scroll the menu in 北京114预约挂号 official account - WeChat https://bugs.webkit.org/show_bug.cgi?id=221948 Reviewed by Simon Fraser. r266695 caused this to regress, but it actually is a progression, because all browsers agree that this content, as it exists in the app, doesn't scroll. So, we don't want to revert the change itself, because it's a good change, but we also want to make sure that WeChat continues to work. So, we can temporarily quirk one particular element in the WeChat app, until the the content can be fixed (). Because this is a WeChat-specific quirk, it is untestable. I tested manually. * page/Quirks.cpp: (WebCore::Quirks::needsWeChatScrollingQuirk const): * page/Quirks.h: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isWechat): * platform/cocoa/VersionChecks.h: * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjustForSiteSpecificQuirks const): 2021-02-24 Russell Epstein Cherry-pick r272911. rdar://problem/74501076 MediaRecorder.stop() does not work correctly when recording has been paused. https://bugs.webkit.org/show_bug.cgi?id=221916 Reviewed by Eric Carlson. LayoutTests/imported/w3c: * web-platform-tests/mediacapture-record/MediaRecorder-pause-resume-expected.txt: * web-platform-tests/mediacapture-record/MediaRecorder-pause-resume.html: Source/WebCore: Proceed with stop steps in case of paused state, and not only in case of recording state. Covered by added WPT test. * Modules/mediarecorder/MediaRecorder.cpp: (WebCore::MediaRecorder::stopRecordingInternal): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272911 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Youenn Fablet MediaRecorder.stop() does not work correctly when recording has been paused. https://bugs.webkit.org/show_bug.cgi?id=221916 Reviewed by Eric Carlson. Proceed with stop steps in case of paused state, and not only in case of recording state. Covered by added WPT test. * Modules/mediarecorder/MediaRecorder.cpp: (WebCore::MediaRecorder::stopRecordingInternal): 2021-02-24 Russell Epstein Cherry-pick r272544. rdar://problem/74409562 [Cocoa] Encrypted media segments should generate a parser error if no encrypted media handler is present. https://bugs.webkit.org/show_bug.cgi?id=221496 Reviewed by Eric Carlson. The WebM format reader does not support encrypted media parsing, so the parser must generate an error rather than continuing to parse encrypted media data. * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::OnElementEnd): (WebCore::SourceBufferParserWebM::OnTrackEntry): * platform/graphics/cocoa/SourceBufferParserWebM.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272544 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Jer Noble [Cocoa] Encrypted media segments should generate a parser error if no encrypted media handler is present. https://bugs.webkit.org/show_bug.cgi?id=221496 Reviewed by Eric Carlson. The WebM format reader does not support encrypted media parsing, so the parser must generate an error rather than continuing to parse encrypted media data. * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::OnElementEnd): (WebCore::SourceBufferParserWebM::OnTrackEntry): * platform/graphics/cocoa/SourceBufferParserWebM.h: 2021-02-24 Russell Epstein Cherry-pick r272359. rdar://problem/74451201 [MSE] Move the call to didParseInitializationDataCallback() from the beginning of a cluster to the end of "tracks" element https://bugs.webkit.org/show_bug.cgi?id=221120 Reviewed by Daniel Bates. Source/WebCore: This patch updates the WebM parser regarding the timing to call didParseInitializationDataCallback() based on a discussion with Jer. Based on the spec, https://w3c.github.io/mse-byte-stream-format-webm/#webm-init-segments, "The user agent MUST accept and ignore any elements other than an EBML Header or a Cluster that occur before, in between, or after the Segment Information and Tracks elements." So the parser should have collected all required information of the initialization segment when it finishes parsing the "Tracks" element. Tests: media/media-source/media-source-webm.html * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::OnElementEnd): (WebCore::SourceBufferParserWebM::OnClusterBegin): LayoutTests: * media/media-source/media-source-webm-expected.txt: * media/media-source/media-source-webm.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272359 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Peng Liu [MSE] Move the call to didParseInitializationDataCallback() from the beginning of a cluster to the end of "tracks" element https://bugs.webkit.org/show_bug.cgi?id=221120 Reviewed by Daniel Bates. This patch updates the WebM parser regarding the timing to call didParseInitializationDataCallback() based on a discussion with Jer. Based on the spec, https://w3c.github.io/mse-byte-stream-format-webm/#webm-init-segments, "The user agent MUST accept and ignore any elements other than an EBML Header or a Cluster that occur before, in between, or after the Segment Information and Tracks elements." So the parser should have collected all required information of the initialization segment when it finishes parsing the "Tracks" element. Tests: media/media-source/media-source-webm.html * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::OnElementEnd): (WebCore::SourceBufferParserWebM::OnClusterBegin): 2021-02-23 Alan Coon Cherry-pick r273264. rdar://problem/74622873 REGRESSION (r266695): twitch.tv: when in fullscreen, WebKit continually does 350ms layouts. Firefox and Chrome do not https://bugs.webkit.org/show_bug.cgi?id=222202 Reviewed by Simon Fraser. PerformanceTests: New performance test for nested column flexboxes with percentage heights. * Layout/nested-column-flexboxes-relative-height.html: Added. Source/WebCore: The problem was that we were doing the initial layout for the children of the flex container twice in those cases where the child inline axis was not the main axis (for example with column flex containers in horizontal writing modes). Refactored the code (specially the way we clear overriding sizes) so that we only do it once. This saves tons of layouts in pages with nested column flexboxes with relative heights. No new tests as there is no change in functionality, we're removing duplicate extra layouts. We're however adding a new performance test for column flexboxes with percentage heights. With this patch we go from 3.5 layout/s to 145 layout/s which is ~4000% better. Inspired by Blink's crrev.com/c/1614058 by . * rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::computeInnerFlexBaseSizeForChild): Do not unconditionally clear overriding sizes. Also removed relayoutChildren which is now unused. Do not layout the item, that should have been done in computeInnerFlexBaseSizeForChild() before. Added ASSERTs to verify that child's intrinsic main size was cached as a consequence of the previous layout. (WebCore::RenderFlexibleBox::constructFlexItem): Do not pass relayoutChildren to computeInnerFlexBaseSizeForChild. Also no need to update it after laying out the child. * rendering/RenderFlexibleBox.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273264 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-22 Sergio Villar Senin REGRESSION (r266695): twitch.tv: when in fullscreen, WebKit continually does 350ms layouts. Firefox and Chrome do not https://bugs.webkit.org/show_bug.cgi?id=222202 Reviewed by Simon Fraser. The problem was that we were doing the initial layout for the children of the flex container twice in those cases where the child inline axis was not the main axis (for example with column flex containers in horizontal writing modes). Refactored the code (specially the way we clear overriding sizes) so that we only do it once. This saves tons of layouts in pages with nested column flexboxes with relative heights. No new tests as there is no change in functionality, we're removing duplicate extra layouts. We're however adding a new performance test for column flexboxes with percentage heights. With this patch we go from 3.5 layout/s to 145 layout/s which is ~4000% better. Inspired by Blink's crrev.com/c/1614058 by . * rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::computeInnerFlexBaseSizeForChild): Do not unconditionally clear overriding sizes. Also removed relayoutChildren which is now unused. Do not layout the item, that should have been done in computeInnerFlexBaseSizeForChild() before. Added ASSERTs to verify that child's intrinsic main size was cached as a consequence of the previous layout. (WebCore::RenderFlexibleBox::constructFlexItem): Do not pass relayoutChildren to computeInnerFlexBaseSizeForChild. Also no need to update it after laying out the child. * rendering/RenderFlexibleBox.h: 2021-02-23 Alan Coon Cherry-pick r273220. rdar://problem/74623537 [Paint Timing] Return early from contentful paint check when no contentful pixels/characters at all https://bugs.webkit.org/show_bug.cgi?id=222245 Reviewed by Simon Fraser. Bail from recursive contenful-paint check if there are no pixels/text characters in the entire document. Covered by existing tests, an optimization only. * dom/Document.cpp: (WebCore::Document::enqueuePaintTimingEntryIfNeeded): * page/FrameView.cpp: (WebCore::FrameView::hasContenfulDescendants const): * page/FrameView.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273220 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-21 Noam Rosenthal [Paint Timing] Return early from contentful paint check when no contentful pixels/characters at all https://bugs.webkit.org/show_bug.cgi?id=222245 Reviewed by Simon Fraser. Bail from recursive contenful-paint check if there are no pixels/text characters in the entire document. Covered by existing tests, an optimization only. * dom/Document.cpp: (WebCore::Document::enqueuePaintTimingEntryIfNeeded): * page/FrameView.cpp: (WebCore::FrameView::hasContenfulDescendants const): * page/FrameView.h: 2021-02-23 Alan Coon Cherry-pick r273158. rdar://problem/74623451 Allow to use BigInt as key identifier https://bugs.webkit.org/show_bug.cgi?id=222165 Reviewed by Darin Adler. Source/WebCore: Allow to pass a BigInt as key id so as to use all of SFrame key ID 8 bytes. A RangeError is thrown if BigInt is more than 64 bits. Update the implementation to use a Vector instead of a map to keep the keys. This allows to also use 0 and 2^64-1 values that HashMap reserves for its personal use. Covered by updated test. * Modules/mediastream/RTCRtpSFrameTransform.idl: * Modules/mediastream/RTCRtpSFrameTransformer.cpp: (WebCore::RTCRtpSFrameTransformer::setEncryptionKey): (WebCore::RTCRtpSFrameTransformer::updateEncryptionKey): (WebCore::RTCRtpSFrameTransformer::decryptFrame): * Modules/mediastream/RTCRtpSFrameTransformer.h: * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * bindings/js/JSRTCRtpSFrameTransformCustom.cpp: Added. (WebCore::JSRTCRtpSFrameTransform::setEncryptionKey): LayoutTests: * webrtc/sframe-keys-expected.txt: * webrtc/sframe-keys.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273158 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-19 Youenn Fablet Allow to use BigInt as key identifier https://bugs.webkit.org/show_bug.cgi?id=222165 Reviewed by Darin Adler. Allow to pass a BigInt as key id so as to use all of SFrame key ID 8 bytes. A RangeError is thrown if BigInt is more than 64 bits. Update the implementation to use a Vector instead of a map to keep the keys. This allows to also use 0 and 2^64-1 values that HashMap reserves for its personal use. Covered by updated test. * Modules/mediastream/RTCRtpSFrameTransform.idl: * Modules/mediastream/RTCRtpSFrameTransformer.cpp: (WebCore::RTCRtpSFrameTransformer::setEncryptionKey): (WebCore::RTCRtpSFrameTransformer::updateEncryptionKey): (WebCore::RTCRtpSFrameTransformer::decryptFrame): * Modules/mediastream/RTCRtpSFrameTransformer.h: * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * bindings/js/JSRTCRtpSFrameTransformCustom.cpp: Added. (WebCore::JSRTCRtpSFrameTransform::setEncryptionKey): 2021-02-23 Alan Coon Cherry-pick r273129. rdar://problem/74623422 Scrolling on https://www.apple.com/ipad-air/ can jitter on certain sections https://bugs.webkit.org/show_bug.cgi?id=222136 rdar://71881767 Reviewed by Zalan Bujtas. Source/WebCore: On macOS computers with 16MB of memory, https://www.apple.com/ipad-air/ can trigger the "conservative" compositing mode where RenderLayerCompositor tries to reduce the number of composited layers. On this particular page, a "will-change: transform" element with an overflow:hidden ancestor triggers some bad compositing bounds geometry computation (webkit.org/b/222092, webkit.org/b/222124) which has the end result of changing the composited bounds of the "position:sticky" layer on every scroll. This results in layer contents temporarily appearing stretched or in the wrong place (webkit.org/b/222132). For now, do a conservative fix to avoid this problem, which is to continue to allow "will-change: transform" to trigger compositing on macOS in conservative mode. This actually reduces memory use on this page, because webkit.org/b/222092 was triggering excessively large backing store. Tested by compositing/layer-creation/compositing-policy.html * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::requiresCompositingForWillChange const): LayoutTests: * platform/mac/compositing/layer-creation/compositing-policy-expected.txt: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273129 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-18 Simon Fraser Scrolling on https://www.apple.com/ipad-air/ can jitter on certain sections https://bugs.webkit.org/show_bug.cgi?id=222136 rdar://71881767 Reviewed by Zalan Bujtas. On macOS computers with 16MB of memory, https://www.apple.com/ipad-air/ can trigger the "conservative" compositing mode where RenderLayerCompositor tries to reduce the number of composited layers. On this particular page, a "will-change: transform" element with an overflow:hidden ancestor triggers some bad compositing bounds geometry computation (webkit.org/b/222092, webkit.org/b/222124) which has the end result of changing the composited bounds of the "position:sticky" layer on every scroll. This results in layer contents temporarily appearing stretched or in the wrong place (webkit.org/b/222132). For now, do a conservative fix to avoid this problem, which is to continue to allow "will-change: transform" to trigger compositing on macOS in conservative mode. This actually reduces memory use on this page, because webkit.org/b/222092 was triggering excessively large backing store. Tested by compositing/layer-creation/compositing-policy.html * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::requiresCompositingForWillChange const): 2021-02-23 Alan Coon Cherry-pick r272358. rdar://problem/74622890 Avoid an ancestor walk in HTMLFormControlElement::computeWillValidate() https://bugs.webkit.org/show_bug.cgi?id=221357 Reviewed by Ryosuke Niwa. HTMLFormControlElement::computeWillValidate() does an ancestor DOM walk to look for enclosing data list elements, but these are fairly uncommon so we can avoid this work if we know the Document has none. * dom/Document.h: (WebCore::Document::hasDataListElements const): (WebCore::Document::incrementDataListElementCount): (WebCore::Document::decrementDataListElementCount): * dom/Element.cpp: (WebCore::Element::removedFromAncestor): Avoid fetching the page twice. * html/HTMLDataListElement.cpp: (WebCore::HTMLDataListElement::HTMLDataListElement): (WebCore::HTMLDataListElement::~HTMLDataListElement): (WebCore::HTMLDataListElement::didMoveToNewDocument): * html/HTMLDataListElement.h: * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::computeWillValidate const): * page/PointerLockController.cpp: (WebCore::PointerLockController::elementWasRemoved): Renamed for consistency. (WebCore::PointerLockController::elementRemoved): Deleted. * page/PointerLockController.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272358 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Simon Fraser Avoid an ancestor walk in HTMLFormControlElement::computeWillValidate() https://bugs.webkit.org/show_bug.cgi?id=221357 Reviewed by Ryosuke Niwa. HTMLFormControlElement::computeWillValidate() does an ancestor DOM walk to look for enclosing data list elements, but these are fairly uncommon so we can avoid this work if we know the Document has none. * dom/Document.h: (WebCore::Document::hasDataListElements const): (WebCore::Document::incrementDataListElementCount): (WebCore::Document::decrementDataListElementCount): * dom/Element.cpp: (WebCore::Element::removedFromAncestor): Avoid fetching the page twice. * html/HTMLDataListElement.cpp: (WebCore::HTMLDataListElement::HTMLDataListElement): (WebCore::HTMLDataListElement::~HTMLDataListElement): (WebCore::HTMLDataListElement::didMoveToNewDocument): * html/HTMLDataListElement.h: * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::computeWillValidate const): * page/PointerLockController.cpp: (WebCore::PointerLockController::elementWasRemoved): Renamed for consistency. (WebCore::PointerLockController::elementRemoved): Deleted. * page/PointerLockController.h: 2021-02-23 Alan Coon Cherry-pick r272354. rdar://problem/74622963 Avoid frequent calls to HTMLFormControlElement::updateValidity() when constructing form control elements https://bugs.webkit.org/show_bug.cgi?id=221320 Reviewed by Geoffrey Garen. HTMLFormControlElement::updateValidity() can get called multiple times inside HTMLInputElement::parserDidSetAttributes(), so add a simple delaying scope so that validity is only updated once at the end. * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::endDelayingUpdateValidity): (WebCore::HTMLFormControlElement::computeWillValidate const): (WebCore::HTMLFormControlElement::updateValidity): * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::startDelayingUpdateValidity): (WebCore::DelayedUpdateValidityScope::DelayedUpdateValidityScope): (WebCore::DelayedUpdateValidityScope::~DelayedUpdateValidityScope): * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::parserDidSetAttributes): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272354 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Simon Fraser Avoid frequent calls to HTMLFormControlElement::updateValidity() when constructing form control elements https://bugs.webkit.org/show_bug.cgi?id=221320 Reviewed by Geoffrey Garen. HTMLFormControlElement::updateValidity() can get called multiple times inside HTMLInputElement::parserDidSetAttributes(), so add a simple delaying scope so that validity is only updated once at the end. * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::endDelayingUpdateValidity): (WebCore::HTMLFormControlElement::computeWillValidate const): (WebCore::HTMLFormControlElement::updateValidity): * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::startDelayingUpdateValidity): (WebCore::DelayedUpdateValidityScope::DelayedUpdateValidityScope): (WebCore::DelayedUpdateValidityScope::~DelayedUpdateValidityScope): * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::parserDidSetAttributes): 2021-02-17 Ruben Turcios Cherry-pick r272626. rdar://problem/74410222 Descendants of row and column headers should expose the aria-sort attribute. https://bugs.webkit.org/show_bug.cgi?id=221590 Reviewed by Chris Fleizach. Source/WebCore: Tests: accessibility/aria-sort.html accessibility/ios-simulator/aria-sort-ios.html Walk up the accessibility hierarchy to check for an inherited aria-sort attribute present in a row or column header ancestor. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::sortDirection const): LayoutTests: Expanded this test to include the case where the header contains a child element that must also expose the aria-sort attribute inherited from its parent. * accessibility/aria-sort-expected.txt: * accessibility/aria-sort.html: * accessibility/ios-simulator/aria-sort-ios-expected.txt: * accessibility/ios-simulator/aria-sort-ios.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272626 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Andres Gonzalez Descendants of row and column headers should expose the aria-sort attribute. https://bugs.webkit.org/show_bug.cgi?id=221590 Reviewed by Chris Fleizach. Tests: accessibility/aria-sort.html accessibility/ios-simulator/aria-sort-ios.html Walk up the accessibility hierarchy to check for an inherited aria-sort attribute present in a row or column header ancestor. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::sortDirection const): 2021-02-17 Ruben Turcios Cherry-pick r272165. rdar://problem/74032536 Use user media permission prompt for speech recognition https://bugs.webkit.org/show_bug.cgi?id=221082 rdar://problem/73372499 Patch by Sihui Liu on 2021-02-01 Reviewed by Youenn Fablet. Source/WebCore: Add frame identifier to SpeechRecognitionRequest as it is needed for checking user media permission. Updated existing tests for changed behavior. * Modules/speech/SpeechRecognition.cpp: (WebCore::SpeechRecognition::startRecognition): * Modules/speech/SpeechRecognitionConnection.h: * Modules/speech/SpeechRecognitionRequest.h: (WebCore::SpeechRecognitionRequest::frameIdentifier const): * Modules/speech/SpeechRecognitionRequestInfo.h: (WebCore::SpeechRecognitionRequestInfo::encode const): (WebCore::SpeechRecognitionRequestInfo::decode): * page/DummySpeechRecognitionProvider.h: Source/WebKit: Make SpeechRecognitionPermissionManager ask UserMediaPermissionRequestManagerProxy for user permission on microphone. * UIProcess/SpeechRecognitionPermissionManager.cpp: (WebKit::SpeechRecognitionPermissionManager::request): (WebKit::SpeechRecognitionPermissionManager::startProcessingRequest): (WebKit::SpeechRecognitionPermissionManager::requestUserPermission): * UIProcess/SpeechRecognitionPermissionManager.h: * UIProcess/SpeechRecognitionPermissionRequest.h: (WebKit::SpeechRecognitionPermissionRequest::create): (WebKit::SpeechRecognitionPermissionRequest::frameIdentifier const): (WebKit::SpeechRecognitionPermissionRequest::SpeechRecognitionPermissionRequest): * UIProcess/SpeechRecognitionServer.cpp: (WebKit::SpeechRecognitionServer::start): (WebKit::SpeechRecognitionServer::requestPermissionForRequest): * UIProcess/SpeechRecognitionServer.h: * UIProcess/SpeechRecognitionServer.messages.in: * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::denyRequest): (WebKit::UserMediaPermissionRequestManagerProxy::grantRequest): (WebKit::UserMediaPermissionRequestManagerProxy::checkUserMediaPermissionForSpeechRecognition): * UIProcess/UserMediaPermissionRequestManagerProxy.h: * UIProcess/UserMediaPermissionRequestProxy.cpp: (WebKit::UserMediaPermissionRequestProxy::UserMediaPermissionRequestProxy): * UIProcess/UserMediaPermissionRequestProxy.h: (WebKit::UserMediaPermissionRequestProxy::create): (WebKit::UserMediaPermissionRequestProxy::decisionCompletionHandler): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::requestSpeechRecognitionPermission): (WebKit::WebPageProxy::requestUserMediaPermissionForSpeechRecognition): * UIProcess/WebPageProxy.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::createSpeechRecognitionServer): * WebProcess/WebCoreSupport/WebSpeechRecognitionConnection.cpp: (WebKit::WebSpeechRecognitionConnection::start): * WebProcess/WebCoreSupport/WebSpeechRecognitionConnection.h: Tools: * TestWebKitAPI/Tests/WebKitCocoa/SpeechRecognition.mm: (-[SpeechRecognitionUIDelegate _webView:requestMediaCaptureAuthorization:decisionHandler:]): LayoutTests: * fast/speechrecognition/permission-error.html: * fast/speechrecognition/start-recognition-in-removed-iframe-expected.txt: * fast/speechrecognition/start-recognition-in-removed-iframe.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272165 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-01 Sihui Liu Use user media permission prompt for speech recognition https://bugs.webkit.org/show_bug.cgi?id=221082 rdar://problem/73372499 Reviewed by Youenn Fablet. Add frame identifier to SpeechRecognitionRequest as it is needed for checking user media permission. Updated existing tests for changed behavior. * Modules/speech/SpeechRecognition.cpp: (WebCore::SpeechRecognition::startRecognition): * Modules/speech/SpeechRecognitionConnection.h: * Modules/speech/SpeechRecognitionRequest.h: (WebCore::SpeechRecognitionRequest::frameIdentifier const): * Modules/speech/SpeechRecognitionRequestInfo.h: (WebCore::SpeechRecognitionRequestInfo::encode const): (WebCore::SpeechRecognitionRequestInfo::decode): * page/DummySpeechRecognitionProvider.h: 2021-02-17 Ruben Turcios Cherry-pick r271636. rdar://problem/74452635 Update media state for active speech recognition as it uses audio capture https://bugs.webkit.org/show_bug.cgi?id=220667 Patch by Sihui Liu on 2021-01-19 Reviewed by Youenn Fablet. Source/WebCore: To make sure the media capture state is correctly sent to client. API test: WebKit2.SpeechRecognitionMediaCaptureStateChange * Modules/speech/SpeechRecognition.cpp: (WebCore::SpeechRecognition::startRecognition): (WebCore::SpeechRecognition::stop): (WebCore::SpeechRecognition::didStartCapturingAudio): (WebCore::SpeechRecognition::didStopCapturingAudio): * Modules/speech/SpeechRecognition.h: * Modules/speech/SpeechRecognitionConnection.h: * dom/Document.cpp: (WebCore::Document::setActiveSpeechRecognition): (WebCore::Document::updateIsPlayingMedia): * dom/Document.h: * page/DummySpeechRecognitionProvider.h: Source/WebKit: * WebProcess/WebCoreSupport/WebSpeechRecognitionConnection.cpp: (WebKit::WebSpeechRecognitionConnection::unregisterClient): * WebProcess/WebCoreSupport/WebSpeechRecognitionConnection.h: Tools: * TestWebKitAPI/Tests/WebKitCocoa/SpeechRecognition.mm: (-[SpeechRecognitionUIDelegate _webView:mediaCaptureStateDidChange:]): (TestWebKitAPI::TEST): (-[SpeechRecognitionPermissionUIDelegate _webView:requestSpeechRecognitionPermissionForOrigin:decisionHandler:]): Deleted. (-[SpeechRecognitionPermissionUIDelegate _webView:requestMediaCaptureAuthorization:decisionHandler:]): Deleted. (-[SpeechRecognitionPermissionUIDelegate _webView:checkUserMediaPermissionForURL:mainFrameURL:frameIdentifier:decisionHandler:]): Deleted. (-[SpeechRecognitionPermissionUIDelegate webView:createWebViewWithConfiguration:forNavigationAction:windowFeatures:]): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271636 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-19 Sihui Liu Update media state for active speech recognition as it uses audio capture https://bugs.webkit.org/show_bug.cgi?id=220667 Reviewed by Youenn Fablet. To make sure the media capture state is correctly sent to client. API test: WebKit2.SpeechRecognitionMediaCaptureStateChange * Modules/speech/SpeechRecognition.cpp: (WebCore::SpeechRecognition::startRecognition): (WebCore::SpeechRecognition::stop): (WebCore::SpeechRecognition::didStartCapturingAudio): (WebCore::SpeechRecognition::didStopCapturingAudio): * Modules/speech/SpeechRecognition.h: * Modules/speech/SpeechRecognitionConnection.h: * dom/Document.cpp: (WebCore::Document::setActiveSpeechRecognition): (WebCore::Document::updateIsPlayingMedia): * dom/Document.h: * page/DummySpeechRecognitionProvider.h: 2021-02-17 Ruben Turcios Cherry-pick r272490. rdar://problem/74409784 Add support for aria-sort change notifications. https://bugs.webkit.org/show_bug.cgi?id=221495 Reviewed by Chris Fleizach. Source/WebCore: Test: accessibility/aria-sort-changed-notification.html This patch adds support for aria-sort changes. Some code cleanup by using the notificationPlatformName helper function. * accessibility/AXLogger.cpp: (WebCore::operator<<): Logging of the new notification. * accessibility/AXObjectCache.cpp: Handles the aria-sort change notification. Updates the isolated tree. (WebCore::AXObjectCache::handleAttributeChange): (WebCore::AXObjectCache::updateIsolatedTree): * accessibility/AXObjectCache.h: * accessibility/ios/AXObjectCacheIOS.mm: (WebCore::AXObjectCache::notificationPlatformName): Helper to map AXCore notifications to platform notifications. (WebCore::AXObjectCache::postPlatformNotification): Handles the AXSortDirectionChanged notification. Some code cleanup using the notificationPlatformName helper. * accessibility/ios/WebAccessibilityObjectWrapperIOS.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper postNotification:]): To be overridden by system AX bundles. (-[WebAccessibilityObjectWrapper accessibilitySortDirection]): Only ascending and descending sort directions are relevant for clients. * accessibility/isolatedtree/AXIsolatedTree.cpp: (WebCore::AXIsolatedTree::updateNodeProperty): Updates the SortDirection property. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postPlatformNotification): Handles the AXSortDirectionChanged notification. Tools: * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp: (WTR::AccessibilityUIElement::sortDirection const): * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm: (WTR::AccessibilityUIElement::sortDirection const): * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::AccessibilityUIElement::currentStateValue const): (WTR::AccessibilityUIElement::sortDirection const): LayoutTests: * accessibility/aria-sort-changed-notification-expected.txt: Added. * accessibility/aria-sort-changed-notification.html: Added. * accessibility/aria-sort-expected.txt: * accessibility/aria-sort.html: Calls sortDirection property on the JS accessible element instead of retrieving the aria-sort attribute. This matches more accurately what an actual client would do. Changed the expected file accordingly. * accessibility/ios-simulator/aria-sort-ios-expected.txt: * accessibility/ios-simulator/aria-sort-ios.html: Same as in the Mac test above. * platform/ios/TestExpectations: Added the new test to be run on the ios-simulator. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272490 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Andres Gonzalez Add support for aria-sort change notifications. https://bugs.webkit.org/show_bug.cgi?id=221495 Reviewed by Chris Fleizach. Test: accessibility/aria-sort-changed-notification.html This patch adds support for aria-sort changes. Some code cleanup by using the notificationPlatformName helper function. * accessibility/AXLogger.cpp: (WebCore::operator<<): Logging of the new notification. * accessibility/AXObjectCache.cpp: Handles the aria-sort change notification. Updates the isolated tree. (WebCore::AXObjectCache::handleAttributeChange): (WebCore::AXObjectCache::updateIsolatedTree): * accessibility/AXObjectCache.h: * accessibility/ios/AXObjectCacheIOS.mm: (WebCore::AXObjectCache::notificationPlatformName): Helper to map AXCore notifications to platform notifications. (WebCore::AXObjectCache::postPlatformNotification): Handles the AXSortDirectionChanged notification. Some code cleanup using the notificationPlatformName helper. * accessibility/ios/WebAccessibilityObjectWrapperIOS.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper postNotification:]): To be overridden by system AX bundles. (-[WebAccessibilityObjectWrapper accessibilitySortDirection]): Only ascending and descending sort directions are relevant for clients. * accessibility/isolatedtree/AXIsolatedTree.cpp: (WebCore::AXIsolatedTree::updateNodeProperty): Updates the SortDirection property. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postPlatformNotification): Handles the AXSortDirectionChanged notification. 2021-02-17 Ruben Turcios Cherry-pick r272067. rdar://problem/74444347 Support for aria-current state changed notifications. https://bugs.webkit.org/show_bug.cgi?id=221074 Reviewed by Chris Fleizach. Source/WebCore: Test: accessibility/aria-current-state-changed-notification.html Added handling of the AXCurrentStateChanged notification for Mac and iOS ports. This notification is fired when the aria-current attribute changes. Handling of this notification is required to properly update the accessibility properties of the target object and convey them to assistive technology clients. * accessibility/AXLogger.cpp: (WebCore::operator<<): Renamed notification anumerand. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::handleAttributeChange): * accessibility/AXObjectCache.h: * accessibility/atk/AXObjectCacheAtk.cpp: (WebCore::AXObjectCache::postPlatformNotification): * accessibility/ios/AXObjectCacheIOS.mm: (WebCore::AXObjectCache::postPlatformNotification): * accessibility/ios/WebAccessibilityObjectWrapperIOS.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityDOMIdentifier]): (-[WebAccessibilityObjectWrapper postCurrentStateChangedNotification]): (-[WebAccessibilityObjectWrapper accessibilityCurrentState]): (-[WebAccessibilityObjectWrapper accessibilityARIACurrentStatus]): Renamed to accessibilityCurrentState. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postPlatformNotification): Tools: Added AccessibilityUIElement::domIdentifier and currentStateValue used in LayoutTests/accessibility/aria-current-state-changed-notification.html. * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp: (WTR::AccessibilityUIElement::domIdentifier const): Non-Cocoa implementation. (WTR::AccessibilityUIElement::currentStateValue const): Non-Cocoa implementation. * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm: (WTR::AccessibilityUIElement::domIdentifier const): (WTR::AccessibilityUIElement::stringAttributeValue): (WTR::AccessibilityUIElement::currentStateValue const): * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::AccessibilityUIElement::domIdentifier const): (WTR::AccessibilityUIElement::currentStateValue const): LayoutTests: * accessibility/aria-current-state-changed-notification-expected.txt: Added. * accessibility/aria-current-state-changed-notification.html: Added. * accessibility/aria-current.html: Use AccessibilityUIElement::currentStateValue for consistency and to match closely how actual clients will invoke this functionality. * platform/gtk/TestExpectations: * platform/ios-wk1/TestExpectations: * platform/ios/TestExpectations: * platform/mac-wk1/TestExpectations: * platform/win/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272067 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-29 Andres Gonzalez Support for aria-current state changed notifications. https://bugs.webkit.org/show_bug.cgi?id=221074 Reviewed by Chris Fleizach. Test: accessibility/aria-current-state-changed-notification.html Added handling of the AXCurrentStateChanged notification for Mac and iOS ports. This notification is fired when the aria-current attribute changes. Handling of this notification is required to properly update the accessibility properties of the target object and convey them to assistive technology clients. * accessibility/AXLogger.cpp: (WebCore::operator<<): Renamed notification anumerand. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::handleAttributeChange): * accessibility/AXObjectCache.h: * accessibility/atk/AXObjectCacheAtk.cpp: (WebCore::AXObjectCache::postPlatformNotification): * accessibility/ios/AXObjectCacheIOS.mm: (WebCore::AXObjectCache::postPlatformNotification): * accessibility/ios/WebAccessibilityObjectWrapperIOS.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityDOMIdentifier]): (-[WebAccessibilityObjectWrapper postCurrentStateChangedNotification]): (-[WebAccessibilityObjectWrapper accessibilityCurrentState]): (-[WebAccessibilityObjectWrapper accessibilityARIACurrentStatus]): Renamed to accessibilityCurrentState. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postPlatformNotification): 2021-02-17 Ruben Turcios Cherry-pick r272755. rdar://problem/74409916 Unreviewed, reverting r270578. https://bugs.webkit.org/show_bug.cgi?id=221110 Caused incorrect image layout inside a flexbox container. LayoutTests/imported/w3c: * web-platform-tests/css/css-flexbox/flex-aspect-ratio-img-row-013-expected.txt: * web-platform-tests/css/css-flexbox/image-as-flexitem-size-003-expected.txt: * web-platform-tests/css/css-flexbox/image-as-flexitem-size-003v-expected.txt: * web-platform-tests/css/css-flexbox/image-as-flexitem-size-004-expected.txt: * web-platform-tests/css/css-flexbox/image-as-flexitem-size-004v-expected.txt: Source/WebCore: * rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::computeMainSizeFromAspectRatioUsing const): (WebCore::RenderFlexibleBox::childCrossSizeIsDefinite const): LayoutTests: * TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272755 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-11 Said Abou-Hallawa Unreviewed, reverting r270578. https://bugs.webkit.org/show_bug.cgi?id=221110 Caused incorrect image layout inside a flexbox container. * rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::computeMainSizeFromAspectRatioUsing const): (WebCore::RenderFlexibleBox::childCrossSizeIsDefinite const): 2021-02-23 Alan Coon Cherry-pick r272678. rdar://problem/74410058 WebCore::createBusFromInMemoryAudioFile() may crash under ExtAudioFileRead() https://bugs.webkit.org/show_bug.cgi?id=221642 Reviewed by Geoffrey Garen. The crash seems to indicate we are passing an AudioBufferList to ExtAudioFileRead() that contains a null buffer. It is not obvious how this is happening but I have made the following changes: 1. createAudioBufferList() / destroyAudioListBuffer() implementation is now shared on both macOS and iOS. The implementation now uses fastCalloc and returns null in case of failure to allocate. 2. createAudioBufferList() was renamed to tryCreateAudioBufferList() to make it clear it can return null. All call sites now properly deal with tryCreateAudioBufferList() potentially return null 3. Add a new validateAudioBufferList() function which makes sure that the AudioBufferList we are about to pass to ExtAudioFileRead() does not contain any null buffer. In case of validation failure, we log an error, generate a simulated crash log and early return gracefully instead of crashing later on. 4. Added more assertions to help catch bugs. * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * platform/audio/cocoa/AudioFileReaderCocoa.cpp: Added. (WebCore::tryCreateAudioBufferList): (WebCore::destroyAudioBufferList): (WebCore::validateAudioBufferList): * platform/audio/cocoa/AudioFileReaderCocoa.h: Added. * platform/audio/ios/AudioFileReaderIOS.cpp: (WebCore::AudioFileReader::createBus): (WebCore::createAudioBufferList): Deleted. (WebCore::destroyAudioBufferList): Deleted. * platform/audio/mac/AudioFileReaderMac.cpp: (WebCore::AudioFileReader::createBus): (WebCore::createAudioBufferList): Deleted. (WebCore::destroyAudioBufferList): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272678 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-10 Chris Dumez WebCore::createBusFromInMemoryAudioFile() may crash under ExtAudioFileRead() https://bugs.webkit.org/show_bug.cgi?id=221642 Reviewed by Geoffrey Garen. The crash seems to indicate we are passing an AudioBufferList to ExtAudioFileRead() that contains a null buffer. It is not obvious how this is happening but I have made the following changes: 1. createAudioBufferList() / destroyAudioListBuffer() implementation is now shared on both macOS and iOS. The implementation now uses fastCalloc and returns null in case of failure to allocate. 2. createAudioBufferList() was renamed to tryCreateAudioBufferList() to make it clear it can return null. All call sites now properly deal with tryCreateAudioBufferList() potentially return null 3. Add a new validateAudioBufferList() function which makes sure that the AudioBufferList we are about to pass to ExtAudioFileRead() does not contain any null buffer. In case of validation failure, we log an error, generate a simulated crash log and early return gracefully instead of crashing later on. 4. Added more assertions to help catch bugs. * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * platform/audio/cocoa/AudioFileReaderCocoa.cpp: Added. (WebCore::tryCreateAudioBufferList): (WebCore::destroyAudioBufferList): (WebCore::validateAudioBufferList): * platform/audio/cocoa/AudioFileReaderCocoa.h: Added. * platform/audio/ios/AudioFileReaderIOS.cpp: (WebCore::AudioFileReader::createBus): (WebCore::createAudioBufferList): Deleted. (WebCore::destroyAudioBufferList): Deleted. * platform/audio/mac/AudioFileReaderMac.cpp: (WebCore::AudioFileReader::createBus): (WebCore::createAudioBufferList): Deleted. (WebCore::destroyAudioBufferList): Deleted. 2021-02-17 Ruben Turcios Cherry-pick r272504. rdar://problem/74409474 NetworkRTCSocketCocoa extractDataMessages should not read too much data https://bugs.webkit.org/show_bug.cgi?id=221544 Reviewed by Eric Carlson. Source/WebCore: Move STUN/TURN message parsing to its own file routine so that we can add API test. Code is taken from Source/WebKit/NetworkProcess/webrtc/NetworkRTCSocketCocoa.mm. Fix the test verifying we can actually read a message given its expected length. Covered by API test. * Headers.cmake: * Modules/mediastream/STUNMessageParsing.cpp: Added. (WebCore::isStunMessage): (WebCore::getSTUNOrTURNMessageLengths): (WebCore::extractSTUNOrTURNMessages): (WebCore::extractDataMessages): (WebCore::extractMessages): * Modules/mediastream/STUNMessageParsing.h: Added. * Sources.txt: * WebCore.xcodeproj/project.pbxproj: Source/WebKit: * NetworkProcess/webrtc/NetworkRTCSocketCocoa.mm: Make use of WebCore method. Tools: * TestWebKitAPI/Tests/WebCore/STUNMessageParsingTest.cpp: Added. (TestWebKitAPI::TEST): * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272504 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Youenn Fablet NetworkRTCSocketCocoa extractDataMessages should not read too much data https://bugs.webkit.org/show_bug.cgi?id=221544 Reviewed by Eric Carlson. Move STUN/TURN message parsing to its own file routine so that we can add API test. Code is taken from Source/WebKit/NetworkProcess/webrtc/NetworkRTCSocketCocoa.mm. Fix the test verifying we can actually read a message given its expected length. Covered by API test. * Headers.cmake: * Modules/mediastream/STUNMessageParsing.cpp: Added. (WebCore::isStunMessage): (WebCore::getSTUNOrTURNMessageLengths): (WebCore::extractSTUNOrTURNMessages): (WebCore::extractDataMessages): (WebCore::extractMessages): * Modules/mediastream/STUNMessageParsing.h: Added. * Sources.txt: * WebCore.xcodeproj/project.pbxproj: 2021-02-19 Alan Coon Cherry-pick r273069. rdar://problem/74500798 Backgrounding a page that is playing and capturing audio will stop audio playing https://bugs.webkit.org/show_bug.cgi?id=222032 Reviewed by Eric Carlson. When a page gets backgrounded while capturing, it will continue doing capture, as can be seen with the red status bar. In that case, for video conferencing, it makes sense that audio being played continues playing, at least for MediaStreamTrack. The red status bar is an indication that the call is continuing. Also, for MediaStreamTrack, audio and video content are not buffered: they are played or discarded. The media player, whenever not visible, will stop processing video but will continue processing audio if not interrupted. This makes it working for websites using video elements for both audio and video, which is more common than websites using video elements for video and audio elements for audio. Manually tested. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::shouldOverrideBackgroundPlaybackRestriction const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273069 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-18 Youenn Fablet Backgrounding a page that is playing and capturing audio will stop audio playing https://bugs.webkit.org/show_bug.cgi?id=222032 Reviewed by Eric Carlson. When a page gets backgrounded while capturing, it will continue doing capture, as can be seen with the red status bar. In that case, for video conferencing, it makes sense that audio being played continues playing, at least for MediaStreamTrack. The red status bar is an indication that the call is continuing. Also, for MediaStreamTrack, audio and video content are not buffered: they are played or discarded. The media player, whenever not visible, will stop processing video but will continue processing audio if not interrupted. This makes it working for websites using video elements for both audio and video, which is more common than websites using video elements for video and audio elements for audio. Manually tested. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::shouldOverrideBackgroundPlaybackRestriction const): 2021-02-19 Alan Coon Cherry-pick r273003. rdar://problem/74500696 Animated keyframe style needs to go through full style adjuster https://bugs.webkit.org/show_bug.cgi?id=222036 rdar://72421747 Reviewed by Zalan Bujtas. Source/WebCore: We can create unadjusted styles via keyframe animations and those may cause problems in rendering. Test: fast/animation/animation-position-crash.html * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjustAnimatedStyle): Make this a member function and invoke Adjuster::adjust. Simplify the z-index adjustment since it is mostly handled by adjust. * style/StyleAdjuster.h: * style/StyleTreeResolver.cpp: Always use style adjuster for keyframe animation. (WebCore::Style::TreeResolver::createAnimatedElementUpdate): LayoutTests: * fast/animation/animation-position-crash-expected.html: Added. * fast/animation/animation-position-crash.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273003 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-17 Antti Koivisto Animated keyframe style needs to go through full style adjuster https://bugs.webkit.org/show_bug.cgi?id=222036 rdar://72421747 Reviewed by Zalan Bujtas. We can create unadjusted styles via keyframe animations and those may cause problems in rendering. Test: fast/animation/animation-position-crash.html * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjustAnimatedStyle): Make this a member function and invoke Adjuster::adjust. Simplify the z-index adjustment since it is mostly handled by adjust. * style/StyleAdjuster.h: * style/StyleTreeResolver.cpp: Always use style adjuster for keyframe animation. (WebCore::Style::TreeResolver::createAnimatedElementUpdate): 2021-02-19 Alan Coon Cherry-pick r272931. rdar://problem/74500616 RenderElement::containingBlockForAbsolutePosition may call RenderObject::containingBlock recursively https://bugs.webkit.org/show_bug.cgi?id=221976 Reviewed by Simon Fraser. When a RenderInline happens to be absolute positioned (this is a highly incorrect state, see webkit.org/b/221994), containingBlockForAbsolutePosition() calls containingBlock() with |this| and in return containingBlock() calls back on containingBlockForAbsolutePosition() with the same renderer. This patch ensures that we always call containingBlock() from containingBlockForAbsolutePosition() with an ancestor -mostly with the parent(). * rendering/RenderElement.cpp: (WebCore::RenderElement::containingBlockForAbsolutePosition const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272931 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Zalan Bujtas RenderElement::containingBlockForAbsolutePosition may call RenderObject::containingBlock recursively https://bugs.webkit.org/show_bug.cgi?id=221976 Reviewed by Simon Fraser. When a RenderInline happens to be absolute positioned (this is a highly incorrect state, see webkit.org/b/221994), containingBlockForAbsolutePosition() calls containingBlock() with |this| and in return containingBlock() calls back on containingBlockForAbsolutePosition() with the same renderer. This patch ensures that we always call containingBlock() from containingBlockForAbsolutePosition() with an ancestor -mostly with the parent(). * rendering/RenderElement.cpp: (WebCore::RenderElement::containingBlockForAbsolutePosition const): 2021-02-19 Alan Coon Cherry-pick r272927. rdar://problem/74500651 REGRESSION(r271515): ::marker fired at wrong time https://bugs.webkit.org/show_bug.cgi?id=221961 Reviewed by Dean Jackson. Source/WebCore: Restore the order in which we generate CSS Animations for pseudo-elements as it was prior to r271515. * style/StyleTreeResolver.cpp: (WebCore::Style::TreeResolver::resolveElement): LayoutTests: Remove flakiness for this test since it didn't allow us to spot the regression introduced by r271515. * TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272927 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Antoine Quint REGRESSION(r271515): ::marker fired at wrong time https://bugs.webkit.org/show_bug.cgi?id=221961 Reviewed by Dean Jackson. Restore the order in which we generate CSS Animations for pseudo-elements as it was prior to r271515. * style/StyleTreeResolver.cpp: (WebCore::Style::TreeResolver::resolveElement): 2021-02-19 Alan Coon Cherry-pick r272913. rdar://problem/74500965 AVAudioSessionCaptureDeviceManager should disable its audio session in a background thread https://bugs.webkit.org/show_bug.cgi?id=221949 Reviewed by Eric Carlson. Manually tested. * platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm: (WebCore::AVAudioSessionCaptureDeviceManager::disableAllDevicesQuery): Hop to a background thread before disabling the audio session. Abort if audio session is no longer marked as unneeded. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272913 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Youenn Fablet AVAudioSessionCaptureDeviceManager should disable its audio session in a background thread https://bugs.webkit.org/show_bug.cgi?id=221949 Reviewed by Eric Carlson. Manually tested. * platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm: (WebCore::AVAudioSessionCaptureDeviceManager::disableAllDevicesQuery): Hop to a background thread before disabling the audio session. Abort if audio session is no longer marked as unneeded. 2021-02-19 Alan Coon Cherry-pick r272379. rdar://problem/74500599 Supplementary code points (U+10000 - U+10FFFF) are not shaped correctly in the fast text codepath https://bugs.webkit.org/show_bug.cgi?id=221356 Reviewed by Zalan Bujtas. Source/WebCore: Supplementary code points are represented in UTF-16 as two adjacent (surrogate) code units. When we map code points to glyphs, we were originally mapping these two code units to a single glyph. However, shaping routines require that the number of code units and glyphs be equal, by injecting a 0 glyph for the trailing surrogate. Luckily, we don't actually have to delete these extra 0 glyphs, because the shaping engine will do that for us. Test: fast/text/multi-code-unit-simple-path.html * platform/graphics/WidthIterator.cpp: (WebCore::WidthIterator::advanceInternal): LayoutTests: * fast/text/multi-code-unit-simple-path-expected-mismatch.html: Added. * fast/text/multi-code-unit-simple-path.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272379 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-04 Myles C. Maxfield Supplementary code points (U+10000 - U+10FFFF) are not shaped correctly in the fast text codepath https://bugs.webkit.org/show_bug.cgi?id=221356 Reviewed by Zalan Bujtas. Supplementary code points are represented in UTF-16 as two adjacent (surrogate) code units. When we map code points to glyphs, we were originally mapping these two code units to a single glyph. However, shaping routines require that the number of code units and glyphs be equal, by injecting a 0 glyph for the trailing surrogate. Luckily, we don't actually have to delete these extra 0 glyphs, because the shaping engine will do that for us. Test: fast/text/multi-code-unit-simple-path.html * platform/graphics/WidthIterator.cpp: (WebCore::WidthIterator::advanceInternal): 2021-02-17 Alan Coon Cherry-pick r272345. rdar://problem/74195248 [WebAuthn] Allow one user gesture free prompt for each navigation https://bugs.webkit.org/show_bug.cgi?id=220897 Reviewed by Brent Fulgham. Source/WebCore: * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::resetUserGestureRequirement): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.h: * page/Quirks.cpp: * page/Quirks.cpp.h: * replay/UserInputBridge.cpp: (WebCore::UserInputBridge::loadRequest): (WebCore::UserInputBridge::reloadFrame): Adds the ability to reset the user gesture requirement flag for user initiated reloads and quirks. Source/WebKit: This is a quirk that only allows certain websites. Covered by existing tests. * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::filterTransports const): (WebKit::AuthenticatorManager::runPanel): (WebKit::AuthenticatorManager::runPresenter): Cancel the whole WebAuthn operation if no user gesture is indicated. * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.cpp: (WebKit::WebAuthenticatorCoordinator::makeCredential): (WebKit::WebAuthenticatorCoordinator::getAssertion): * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.h: Set a boolean to indicate a free coupon for each navigation. Tools: * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm: (TestWebKitAPI::TEST): LayoutTests: * http/wpt/webauthn/ctap-hid-failure.https-expected.txt: * http/wpt/webauthn/ctap-hid-success.https-expected.txt: * http/wpt/webauthn/ctap-nfc-failure.https-expected.txt: * http/wpt/webauthn/idl.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-hid-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-local-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-hid-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-local-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-u2f.https-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272345 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Jiewen Tan [WebAuthn] Allow one user gesture free prompt for each navigation https://bugs.webkit.org/show_bug.cgi?id=220897 Reviewed by Brent Fulgham. * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::resetUserGestureRequirement): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.h: * page/Quirks.cpp: * page/Quirks.cpp.h: * replay/UserInputBridge.cpp: (WebCore::UserInputBridge::loadRequest): (WebCore::UserInputBridge::reloadFrame): Adds the ability to reset the user gesture requirement flag for user initiated reloads and quirks. 2021-02-16 Ruben Turcios Cherry-pick r272880. rdar://problem/74409363 Crash under WorkerThreadableLoader::MainThreadBridge::notifyIsDone() https://bugs.webkit.org/show_bug.cgi?id=221906 Reviewed by Alex Christensen. * loader/DocumentThreadableLoader.cpp: (WebCore::DocumentThreadableLoader::computeIsDone): r267227 added this function and this was the first case where the DocumentThreadableLoader would do an async operation and ref itself during the operation. I believe this was the source of the crash as this could cause DocumentThreadableLoader to outlive its client. When DocumentThreadableLoader::notifyIsDone() would get called later on, m_client may be bad. To maintain pre-r267227 behavior, we now capture a WeakPtr to |this| instead of a Ref<>, so that we don't unnecessarily extend the lifetime of the DocumentThreadableLoader. * loader/DocumentThreadableLoader.h: (WebCore::DocumentThreadableLoader::clearClient): Add new clearClient() function to DocumentThreadableLoader so that the client can clear the raw pointer the DocumentThreadableLoader holds to it before getting destroyed. I wanted to use WeakPtr but this did not work out due to multithreading. * loader/WorkerThreadableLoader.cpp: (WebCore::WorkerThreadableLoader::MainThreadBridge::destroy): Before destroying itself, WorkerThreadableLoader::MainThreadBridge now clears the raw pointer to it that DocumentThreadableLoader holds. This is important since DocumentThreadableLoader is RefCounted and its lifetime may get extended past the MainThreadBridge. * loader/WorkerThreadableLoader.h: Use tighter typing for clarity. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272880 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-15 Chris Dumez Crash under WorkerThreadableLoader::MainThreadBridge::notifyIsDone() https://bugs.webkit.org/show_bug.cgi?id=221906 Reviewed by Alex Christensen. * loader/DocumentThreadableLoader.cpp: (WebCore::DocumentThreadableLoader::computeIsDone): r267227 added this function and this was the first case where the DocumentThreadableLoader would do an async operation and ref itself during the operation. I believe this was the source of the crash as this could cause DocumentThreadableLoader to outlive its client. When DocumentThreadableLoader::notifyIsDone() would get called later on, m_client may be bad. To maintain pre-r267227 behavior, we now capture a WeakPtr to |this| instead of a Ref<>, so that we don't unnecessarily extend the lifetime of the DocumentThreadableLoader. * loader/DocumentThreadableLoader.h: (WebCore::DocumentThreadableLoader::clearClient): Add new clearClient() function to DocumentThreadableLoader so that the client can clear the raw pointer the DocumentThreadableLoader holds to it before getting destroyed. I wanted to use WeakPtr but this did not work out due to multithreading. * loader/WorkerThreadableLoader.cpp: (WebCore::WorkerThreadableLoader::MainThreadBridge::destroy): Before destroying itself, WorkerThreadableLoader::MainThreadBridge now clears the raw pointer to it that DocumentThreadableLoader holds. This is important since DocumentThreadableLoader is RefCounted and its lifetime may get extended past the MainThreadBridge. * loader/WorkerThreadableLoader.h: Use tighter typing for clarity. 2021-02-16 Ruben Turcios Cherry-pick r272856. rdar://problem/74410114 [LFC][IFC] Do not re-measure wrapped content https://bugs.webkit.org/show_bug.cgi?id=221874 Reviewed by Antti Koivisto. This patch addresses the performance issue with extremely long content when the content gets re-measured many time while performing line breaking. When a certain text content does not fit the line we can 1. keep it on the current line and let it overflow or 2. wrap the entire content to the next line or 3. split it somewhere in the middle. In case of 2 and 3 this overflowing content turns into the leading content on the subsequent line. Now due to ligature (#3) and position dependent glyph sizing(#2) we need to remeasure this leading content again. However with unreasonably long content and relatively small horizontal constraint, this could lead to repeated, continuous text measuring. In this patch we turn the overflow width into the leading width so that we measure the long text content only once. (FIXME: This should be turned into a generic "use the overflow content as-is when turning it into leading content") * layout/inlineformatting/InlineFormattingContext.cpp: (WebCore::Layout::InlineFormattingContext::lineLayout): * layout/inlineformatting/InlineLineBuilder.cpp: (WebCore::Layout::LineBuilder::layoutInlineContent): (WebCore::Layout::LineBuilder::computedIntrinsicWidth): (WebCore::Layout::LineBuilder::placeInlineContent): (WebCore::Layout::LineBuilder::candidateContentForLine): (WebCore::Layout::LineBuilder::handleInlineContent): * layout/inlineformatting/InlineLineBuilder.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272856 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-15 Zalan Bujtas [LFC][IFC] Do not re-measure wrapped content https://bugs.webkit.org/show_bug.cgi?id=221874 Reviewed by Antti Koivisto. This patch addresses the performance issue with extremely long content when the content gets re-measured many time while performing line breaking. When a certain text content does not fit the line we can 1. keep it on the current line and let it overflow or 2. wrap the entire content to the next line or 3. split it somewhere in the middle. In case of 2 and 3 this overflowing content turns into the leading content on the subsequent line. Now due to ligature (#3) and position dependent glyph sizing(#2) we need to remeasure this leading content again. However with unreasonably long content and relatively small horizontal constraint, this could lead to repeated, continuous text measuring. In this patch we turn the overflow width into the leading width so that we measure the long text content only once. (FIXME: This should be turned into a generic "use the overflow content as-is when turning it into leading content") * layout/inlineformatting/InlineFormattingContext.cpp: (WebCore::Layout::InlineFormattingContext::lineLayout): * layout/inlineformatting/InlineLineBuilder.cpp: (WebCore::Layout::LineBuilder::layoutInlineContent): (WebCore::Layout::LineBuilder::computedIntrinsicWidth): (WebCore::Layout::LineBuilder::placeInlineContent): (WebCore::Layout::LineBuilder::candidateContentForLine): (WebCore::Layout::LineBuilder::handleInlineContent): * layout/inlineformatting/InlineLineBuilder.h: 2021-02-16 Ruben Turcios Cherry-pick r272841. rdar://problem/74409856 [iOS] MobileSafari crashes at WebCore: WebCore::VideoFullscreenInterfaceAVKit::doEnterFullscreen https://bugs.webkit.org/show_bug.cgi?id=221863 Patch by Jean-Yves Avenard on 2021-02-14 Reviewed by Darin Adler. On iPad, it's possible for AVKit to fail due to racing requests to exit full screen and enter full screen. The enterFullscreenHandler would attempt to immediately re-enter full screen. For now we bail-out early to avoid the crash. In a follow-up patch we will ensure that the condition to enter fullscreen while there's a pending operation to exit fullscreen can't occur. No new tests, can't reproduce. Analysis has been entirely theoretical. * platform/ios/VideoFullscreenInterfaceAVKit.mm: (VideoFullscreenInterfaceAVKit::enterFullscreenHandler): Exit early if error returned. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272841 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-14 Jean-Yves Avenard [iOS] MobileSafari crashes at WebCore: WebCore::VideoFullscreenInterfaceAVKit::doEnterFullscreen https://bugs.webkit.org/show_bug.cgi?id=221863 Reviewed by Darin Adler. On iPad, it's possible for AVKit to fail due to racing requests to exit full screen and enter full screen. The enterFullscreenHandler would attempt to immediately re-enter full screen. For now we bail-out early to avoid the crash. In a follow-up patch we will ensure that the condition to enter fullscreen while there's a pending operation to exit fullscreen can't occur. No new tests, can't reproduce. Analysis has been entirely theoretical. * platform/ios/VideoFullscreenInterfaceAVKit.mm: (VideoFullscreenInterfaceAVKit::enterFullscreenHandler): Exit early if error returned. 2021-02-16 Ruben Turcios Cherry-pick r272829. rdar://problem/74409245 [Mac] Sound does not play on YouTube after switching back to foreground https://bugs.webkit.org/show_bug.cgi?id=221858 Reviewed by Eric Carlson. Source/WebCore: Test: platform/mac/media/unmute-after-loading.html Remove a stray, unnecessary reset of a cached muted state which kept mute state from being changed the first time after loading. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayer): * testing/Internals.cpp: (WebCore::Internals::privatePlayerMuted): * testing/Internals.h: * testing/Internals.idl: * testing/Internals.mm: (WebCore::Internals::privatePlayerMuted): LayoutTests: * platform/mac/media/unmute-after-loading-expected.txt: Added. * platform/mac/media/unmute-after-loading.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272829 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-12 Jer Noble [Mac] Sound does not play on YouTube after switching back to foreground https://bugs.webkit.org/show_bug.cgi?id=221858 Reviewed by Eric Carlson. Test: platform/mac/media/unmute-after-loading.html Remove a stray, unnecessary reset of a cached muted state which kept mute state from being changed the first time after loading. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayer): * testing/Internals.cpp: (WebCore::Internals::privatePlayerMuted): * testing/Internals.h: * testing/Internals.idl: * testing/Internals.mm: (WebCore::Internals::privatePlayerMuted): 2021-02-16 Ruben Turcios Cherry-pick r272777. rdar://problem/74410399 Nullopt crash in DOMSelection::getRangeAt https://bugs.webkit.org/show_bug.cgi?id=221786 Reviewed by Darin Adler. No new tests since we don't have any way to reproduce this crash. * page/DOMSelection.cpp: (WebCore::DOMSelection::getRangeAt): Added a nullopt check with an assertion. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272777 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-12 Ryosuke Niwa Nullopt crash in DOMSelection::getRangeAt https://bugs.webkit.org/show_bug.cgi?id=221786 Reviewed by Darin Adler. No new tests since we don't have any way to reproduce this crash. * page/DOMSelection.cpp: (WebCore::DOMSelection::getRangeAt): Added a nullopt check with an assertion. 2021-02-16 Ruben Turcios Cherry-pick r272703. rdar://problem/74409698 Reduce the overhead of DocumentFragment in innerHTML & outerHTML https://bugs.webkit.org/show_bug.cgi?id=221535 Reviewed by Geoffrey Garen. Source/WebCore: This patch reduces the overhead of using DocumentFragment in innerHTMl and outerHTML setters by 1. Cache DocumentFragment used for innerHTML and outerHTML. 2. Adding a fast path to removeAllChildrenWithScriptAssertion when removing child nodes from (1) immediately before appending it to the new parent. This is safe for now since no DOM nodes or API store information about its root node or parent node when it's DocumentFragment, and and there are no node flags to be updated or invalidated since we're removing already-disconnected nodes to which no script ever had access up until this point. We release-assert these conditions before going into the fast path. No new tests since there should be no observable behavior change. * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Added a fast path. See above. * dom/Document.cpp: (WebCore::Document::commonTeardown): Clear m_documentFragmentForInnerOuterHTML as it would keep the ownewr document (this Document) alive otherwise. (WebCore::Document::documentFragmentForInnerOuterHTML): Added. Lazily create a DocumentFragment used to parse the fragment for innerHTML and outerHTML setters. Remove any child nodes left in the document fragment in the case the last call to replaceChildrenWithFragment took a fast path for a single text node, which case we don't remove any child nodes from DocumentFragment. * dom/Document.h: * dom/DocumentFragment.h: (WebCore::DocumentFragment::setIsDocumentFragmentForInnerOuterHTML): Added. * dom/Node.h: (WebCore::Node::isDocumentFragmentForInnerOuterHTML const): Added. * editing/markup.cpp: (WebCore::createFragmentForMarkup): Extracted from createFragmentForInnerOuterHTML to share code between createFragmentForInnerOuterHTML and createContextualFragment. (WebCore::createFragmentForInnerOuterHTML): Reuse the fragment in createFragmentForMarkup. (WebCore::createContextualFragment): Don't reuse the fragment in createFragmentForMarkup as this function is used by Range::createContextualFragment which exposes the document fragment to arbitrary author scripts. (WebCore::hasOneChild): Deleted since we now have Node::hasOneChild. (WebCore::hasOneTextChild): Use Node::hasOneChild. (WebCore::replaceChildrenWithFragment): Added assertions to make sure we don't have any child nodes left after replacing the children. Source/WTF: Added a helper function for writing assertions. * wtf/WeakPtr.h: (WTF::WeakPtrFactory::isInitialized const): Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272703 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-10 Ryosuke Niwa Reduce the overhead of DocumentFragment in innerHTML & outerHTML https://bugs.webkit.org/show_bug.cgi?id=221535 Reviewed by Geoffrey Garen. This patch reduces the overhead of using DocumentFragment in innerHTMl and outerHTML setters by 1. Cache DocumentFragment used for innerHTML and outerHTML. 2. Adding a fast path to removeAllChildrenWithScriptAssertion when removing child nodes from (1) immediately before appending it to the new parent. This is safe for now since no DOM nodes or API store information about its root node or parent node when it's DocumentFragment, and and there are no node flags to be updated or invalidated since we're removing already-disconnected nodes to which no script ever had access up until this point. We release-assert these conditions before going into the fast path. No new tests since there should be no observable behavior change. * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Added a fast path. See above. * dom/Document.cpp: (WebCore::Document::commonTeardown): Clear m_documentFragmentForInnerOuterHTML as it would keep the ownewr document (this Document) alive otherwise. (WebCore::Document::documentFragmentForInnerOuterHTML): Added. Lazily create a DocumentFragment used to parse the fragment for innerHTML and outerHTML setters. Remove any child nodes left in the document fragment in the case the last call to replaceChildrenWithFragment took a fast path for a single text node, which case we don't remove any child nodes from DocumentFragment. * dom/Document.h: * dom/DocumentFragment.h: (WebCore::DocumentFragment::setIsDocumentFragmentForInnerOuterHTML): Added. * dom/Node.h: (WebCore::Node::isDocumentFragmentForInnerOuterHTML const): Added. * editing/markup.cpp: (WebCore::createFragmentForMarkup): Extracted from createFragmentForInnerOuterHTML to share code between createFragmentForInnerOuterHTML and createContextualFragment. (WebCore::createFragmentForInnerOuterHTML): Reuse the fragment in createFragmentForMarkup. (WebCore::createContextualFragment): Don't reuse the fragment in createFragmentForMarkup as this function is used by Range::createContextualFragment which exposes the document fragment to arbitrary author scripts. (WebCore::hasOneChild): Deleted since we now have Node::hasOneChild. (WebCore::hasOneTextChild): Use Node::hasOneChild. (WebCore::replaceChildrenWithFragment): Added assertions to make sure we don't have any child nodes left after replacing the children. 2021-02-16 Ruben Turcios Cherry-pick r272633. rdar://problem/74410421 REGRESSION: (r272458): [BigSur Debug] ASSERTION FAILED: m_haveAddedMediaUsageManagerSession in WebCore::MediaElementSession::updateMediaUsageIfChanged() https://bugs.webkit.org/show_bug.cgi?id=221634 Reviewed by Ryosuke Niwa. No new tests, this fixes an assertion in an existing test. * html/MediaElementSession.cpp: (WebCore::MediaElementSession::MediaElementSession): (WebCore::MediaElementSession::addMediaUsageManagerSessionIfNecessary): (WebCore::MediaElementSession::inActiveDocumentChanged): (WebCore::MediaElementSession::updateMediaUsageIfChanged): (WebCore::MediaElementSession::addedMediaUsageManagerSessionIfNecessary): Deleted. * html/MediaElementSession.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272633 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Eric Carlson REGRESSION: (r272458): [BigSur Debug] ASSERTION FAILED: m_haveAddedMediaUsageManagerSession in WebCore::MediaElementSession::updateMediaUsageIfChanged() https://bugs.webkit.org/show_bug.cgi?id=221634 Reviewed by Ryosuke Niwa. No new tests, this fixes an assertion in an existing test. * html/MediaElementSession.cpp: (WebCore::MediaElementSession::MediaElementSession): (WebCore::MediaElementSession::addMediaUsageManagerSessionIfNecessary): (WebCore::MediaElementSession::inActiveDocumentChanged): (WebCore::MediaElementSession::updateMediaUsageIfChanged): (WebCore::MediaElementSession::addedMediaUsageManagerSessionIfNecessary): Deleted. * html/MediaElementSession.h: 2021-02-16 Ruben Turcios Cherry-pick r272622. rdar://problem/74410599 Reduce the overhead of HTMLDocumentParser in innerHTML setter https://bugs.webkit.org/show_bug.cgi?id=221596 Reviewed by Simon Fraser. This patch reduces the overhead of HTMLDocumentParser for innerHTML. This appears to be ~0.5% Speedometer progression. No new tests since there should be no observable behavior differences. * dom/ScriptableDocumentParser.h: (WebCore::ScriptableDocumentParser:isWaitingForScripts): Removed since this abstract virtual function is only used in HTMLDocumentParser. * html/FTPDirectoryDocument.cpp: (WebCore::FTPDirectoryDocument::isWaitingForScripts): Removed. There are no scripts in ftp directory document but there is no need to override it here. * html/parser/HTMLDocumentParser.cpp: (WebCore::HTMLDocumentParser::pumpTokenizer): Exit early when we're parsing a fragment to avoid accessing the scheduler, preloader, and document loader for various things since they're all irrelevant for fragment parsing. (WebCore::HTMLDocumentParser::isWaitingForScripts const): Return false immediately when parsing a document fragment as a fast path. * html/parser/HTMLDocumentParser.h: * xml/parser/XMLDocumentParser.cpp: (WebCore::XMLDocumentParser::isWaitingForScripts const): Removed. Unused. * xml/parser/XMLDocumentParser.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272622 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Ryosuke Niwa Reduce the overhead of HTMLDocumentParser in innerHTML setter https://bugs.webkit.org/show_bug.cgi?id=221596 Reviewed by Simon Fraser. This patch reduces the overhead of HTMLDocumentParser for innerHTML. This appears to be ~0.5% Speedometer progression. No new tests since there should be no observable behavior differences. * dom/ScriptableDocumentParser.h: (WebCore::ScriptableDocumentParser:isWaitingForScripts): Removed since this abstract virtual function is only used in HTMLDocumentParser. * html/FTPDirectoryDocument.cpp: (WebCore::FTPDirectoryDocument::isWaitingForScripts): Removed. There are no scripts in ftp directory document but there is no need to override it here. * html/parser/HTMLDocumentParser.cpp: (WebCore::HTMLDocumentParser::pumpTokenizer): Exit early when we're parsing a fragment to avoid accessing the scheduler, preloader, and document loader for various things since they're all irrelevant for fragment parsing. (WebCore::HTMLDocumentParser::isWaitingForScripts const): Return false immediately when parsing a document fragment as a fast path. * html/parser/HTMLDocumentParser.h: * xml/parser/XMLDocumentParser.cpp: (WebCore::XMLDocumentParser::isWaitingForScripts const): Removed. Unused. * xml/parser/XMLDocumentParser.h: 2021-02-16 Ruben Turcios Cherry-pick r272602. rdar://problem/74409444 [LFC][IFC] Disable BIDI processing for modern line layout https://bugs.webkit.org/show_bug.cgi?id=221615 Reviewed by Sam Weinig. This was added in preparation for BIDI content support but we are not there yet. Let's just disable it for now. * layout/integration/LayoutIntegrationInlineContentBuilder.cpp: (WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLineRuns const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272602 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Zalan Bujtas [LFC][IFC] Disable BIDI processing for modern line layout https://bugs.webkit.org/show_bug.cgi?id=221615 Reviewed by Sam Weinig. This was added in preparation for BIDI content support but we are not there yet. Let's just disable it for now. * layout/integration/LayoutIntegrationInlineContentBuilder.cpp: (WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLineRuns const): 2021-02-16 Ruben Turcios Cherry-pick r272583. rdar://problem/74409637 MediaStream-backed video elements should not compute the mediaType based on track muted states https://bugs.webkit.org/show_bug.cgi?id=221601 Reviewed by Eric Carlson. Source/WebCore: In case of entering background, two things happen: - video elements get paused - local video capture track gets muted When entering foreground: - video element should resume but did not as the local video track was muted and video element was considered as an audio element. - local video capture track gets unmuted but this is too late. To fix this, compute hasVideo/hasAudio based on available tracks, no matter their active state. Test: fast/mediastream/MediaStream-video-element-enter-background.html * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::hasVideo const): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::hasAudio const): LayoutTests: * fast/mediastream/MediaStream-video-element-enter-background-expected.txt: Added. * fast/mediastream/MediaStream-video-element-enter-background.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272583 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Youenn Fablet MediaStream-backed video elements should not compute the mediaType based on track muted states https://bugs.webkit.org/show_bug.cgi?id=221601 Reviewed by Eric Carlson. In case of entering background, two things happen: - video elements get paused - local video capture track gets muted When entering foreground: - video element should resume but did not as the local video track was muted and video element was considered as an audio element. - local video capture track gets unmuted but this is too late. To fix this, compute hasVideo/hasAudio based on available tracks, no matter their active state. Test: fast/mediastream/MediaStream-video-element-enter-background.html * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::hasVideo const): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::hasAudio const): 2021-02-16 Ruben Turcios Cherry-pick r272567. rdar://problem/74410033 REGRESSION (r269458): yahoo.com social / comments bar shows as transparent when scrolling page https://bugs.webkit.org/show_bug.cgi?id=221582 Source/WebCore: Reviewed by Tim Horton. Fix some copypasta in r269458 that resulted in scrolling state fixed nodes failing to get the right dirty bits after attach, resulting bad viewport constraint data. Test: scrollingcoordinator/fixed-node-reattach.html * page/scrolling/ScrollingStateFixedNode.cpp: (WebCore::ScrollingStateFixedNode::applicableProperties const): LayoutTests: Reviewed by Tim Horton. * scrollingcoordinator/fixed-node-reattach-expected.html: Added. * scrollingcoordinator/fixed-node-reattach.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272567 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Simon Fraser REGRESSION (r269458): yahoo.com social / comments bar shows as transparent when scrolling page https://bugs.webkit.org/show_bug.cgi?id=221582 Reviewed by Tim Horton. Fix some copypasta in r269458 that resulted in scrolling state fixed nodes failing to get the right dirty bits after attach, resulting bad viewport constraint data. Test: scrollingcoordinator/fixed-node-reattach.html * page/scrolling/ScrollingStateFixedNode.cpp: (WebCore::ScrollingStateFixedNode::applicableProperties const): 2021-02-16 Ruben Turcios Cherry-pick r272550. rdar://problem/74409264 Make the UserContentController for ServiceWorker pages be non-optional. and https://bugs.webkit.org/show_bug.cgi?id=221503 Reviewed by Alex Christensen. Source/WebCore: * loader/EmptyClients.cpp: (WebCore::pageConfigurationWithEmptyClients): * page/Page.cpp: (WebCore::Page::Page): * page/PageConfiguration.cpp: (WebCore::PageConfiguration::PageConfiguration): * page/PageConfiguration.h: Source/WebKit: Normal Pages always have a UserContentProvider, even if they just create an empty default one. Same should be true for ServiceWorkers. * Shared/ServiceWorkerInitializationData.cpp: (WebKit::ServiceWorkerInitializationData::decode): * Shared/ServiceWorkerInitializationData.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::userContentControllerIdentifierForServiceWorkers): (WebKit::WebProcessPool::createWebPage): * UIProcess/WebProcessPool.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::enableServiceWorkers): * UIProcess/WebProcessProxy.h: * WebProcess/Storage/WebSWContextManagerConnection.cpp: (WebKit::m_userContentController): (WebKit::m_userAgent): Deleted. * WebProcess/Storage/WebSWContextManagerConnection.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::m_limitsNavigationsToAppBoundDomains): Source/WebKitLegacy/mac: * WebView/WebView.mm: (-[WebView _commonInitializationWithFrameName:groupName:]): Source/WebKitLegacy/win: * WebView.cpp: (WebView::initWithFrame): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272550 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Brady Eidson Make the UserContentController for ServiceWorker pages be non-optional. and https://bugs.webkit.org/show_bug.cgi?id=221503 Reviewed by Alex Christensen. * loader/EmptyClients.cpp: (WebCore::pageConfigurationWithEmptyClients): * page/Page.cpp: (WebCore::Page::Page): * page/PageConfiguration.cpp: (WebCore::PageConfiguration::PageConfiguration): * page/PageConfiguration.h: 2021-02-16 Ruben Turcios Cherry-pick r272495. rdar://problem/74409320 [macOS] Return key binding for date inputs conflicts with return to submit form https://bugs.webkit.org/show_bug.cgi?id=221532 Reviewed by Wenson Hsieh. Source/WebCore: Currently, pressing the return key within a focused date input presents the calendar view, rather than submitting an associated form. This is a usability issue for keyboard users, and is different from the behavior in Chrome. This patch matches the behavior in Chrome, and makes it so that a return keypress submits an associated form. However, since the return key is now reserved for form submission, we need a new key to present the calendar view for the date input. Chrome and Firefox use the space key for this functionality, so this patch matches that behavior. Note that r267281 updated date inputs to focus the next editable component when pressing the space key. This behavior is now removed in favor of presenting the calendar. Other separator keys, and arrow keys, can still be used to focus the next editable component. Tests: fast/forms/date/date-editable-components/date-picker-show-on-space-keypress.html fast/forms/date/date-editable-components/form-submit-on-return-keypress.html * html/BaseDateAndTimeInputType.cpp: (WebCore::BaseDateAndTimeInputType::handleKeypressEvent): Date and time inputs are BaseClickableWithKeyInputTypes. This gives them activation behavior on return and space keypresses, similar to button and color inputs. However, since date/time inputs are closer to textfields, than buttons, we elide activation behavior on a return keypress, allowing the event to submit an associated form. Activation behavior on a space keypress is supported by going through the existing code path. * html/shadow/DateTimeFieldElement.cpp: (WebCore::DateTimeFieldElement::defaultKeyboardEventHandler): Remove "Space" from the list of separator keys that focus the next editable component. LayoutTests: Added tests to verify that pressing the space key in a focused date input presents a calendar view, and pressing the enter key in a focused date input submits a form. Rebaselined existing tests to account for the fact that the space key no longer focuses the next editable component within a date input. * fast/forms/date/date-editable-components/date-editable-components-keyboard-events-expected.txt: * fast/forms/date/date-editable-components/date-editable-components-keyboard-events.html: * fast/forms/date/date-editable-components/date-picker-show-on-space-keypress-expected.txt: Added. * fast/forms/date/date-editable-components/date-picker-show-on-space-keypress.html: Added. * fast/forms/date/date-editable-components/form-submit-on-return-keypress-expected.txt: Added. * fast/forms/date/date-editable-components/form-submit-on-return-keypress.html: Added. * fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-editable-components-keyboard-events-expected.txt: * fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-editable-components-keyboard-events.html: * fast/forms/month/month-editable-components/month-editable-components-keyboard-events-expected.txt: * fast/forms/month/month-editable-components/month-editable-components-keyboard-events.html: * fast/forms/time/time-editable-components/time-editable-components-keyboard-events-expected.txt: * fast/forms/time/time-editable-components/time-editable-components-keyboard-events.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272495 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Aditya Keerthi [macOS] Return key binding for date inputs conflicts with return to submit form https://bugs.webkit.org/show_bug.cgi?id=221532 Reviewed by Wenson Hsieh. Currently, pressing the return key within a focused date input presents the calendar view, rather than submitting an associated form. This is a usability issue for keyboard users, and is different from the behavior in Chrome. This patch matches the behavior in Chrome, and makes it so that a return keypress submits an associated form. However, since the return key is now reserved for form submission, we need a new key to present the calendar view for the date input. Chrome and Firefox use the space key for this functionality, so this patch matches that behavior. Note that r267281 updated date inputs to focus the next editable component when pressing the space key. This behavior is now removed in favor of presenting the calendar. Other separator keys, and arrow keys, can still be used to focus the next editable component. Tests: fast/forms/date/date-editable-components/date-picker-show-on-space-keypress.html fast/forms/date/date-editable-components/form-submit-on-return-keypress.html * html/BaseDateAndTimeInputType.cpp: (WebCore::BaseDateAndTimeInputType::handleKeypressEvent): Date and time inputs are BaseClickableWithKeyInputTypes. This gives them activation behavior on return and space keypresses, similar to button and color inputs. However, since date/time inputs are closer to textfields, than buttons, we elide activation behavior on a return keypress, allowing the event to submit an associated form. Activation behavior on a space keypress is supported by going through the existing code path. * html/shadow/DateTimeFieldElement.cpp: (WebCore::DateTimeFieldElement::defaultKeyboardEventHandler): Remove "Space" from the list of separator keys that focus the next editable component. 2021-02-16 Ruben Turcios Cherry-pick r272488. rdar://problem/74410510 Perform layout before running Editor::findString https://bugs.webkit.org/show_bug.cgi?id=220384 Patch by Frédéric Wang on 2021-02-08 Reviewed by Ryosuke Niwa. This ensures that the layout is up-to-date before performing any search. Also disable any post-resolution that could cause more changes to happen. * editing/Editor.cpp: (WebCore::Editor::findString): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272488 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Frédéric Wang Perform layout before running Editor::findString https://bugs.webkit.org/show_bug.cgi?id=220384 Reviewed by Ryosuke Niwa. This ensures that the layout is up-to-date before performing any search. Also disable any post-resolution that could cause more changes to happen. * editing/Editor.cpp: (WebCore::Editor::findString): 2021-02-16 Ruben Turcios Cherry-pick r272483. rdar://problem/74409975 Nullptr crash in editingIgnoresContent via InsertParagraphSeparatorCommand::doApply https://bugs.webkit.org/show_bug.cgi?id=220349 Patch by Carlos Garcia Campos on 2021-02-08 Reviewed by Ryosuke Niwa. Add an early return to InsertParagraphSeparatorCommand::doApply if insert position is null. * editing/CompositeEditCommand.cpp: (WebCore::CompositeEditCommand::insertNodeBefore): Return early if a InsertNodeBeforeCommand can't be created. * editing/InsertParagraphSeparatorCommand.cpp: (WebCore::InsertParagraphSeparatorCommand::doApply): Abort the insertion if the insert position is null. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272483 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Carlos Garcia Campos Nullptr crash in editingIgnoresContent via InsertParagraphSeparatorCommand::doApply https://bugs.webkit.org/show_bug.cgi?id=220349 Reviewed by Ryosuke Niwa. Add an early return to InsertParagraphSeparatorCommand::doApply if insert position is null. * editing/CompositeEditCommand.cpp: (WebCore::CompositeEditCommand::insertNodeBefore): Return early if a InsertNodeBeforeCommand can't be created. * editing/InsertParagraphSeparatorCommand.cpp: (WebCore::InsertParagraphSeparatorCommand::doApply): Abort the insertion if the insert position is null. 2021-02-16 Ruben Turcios Cherry-pick r272439. rdar://problem/74409122 [Cocoa] CRASH in MediaPlayerPrivateMediaSourceAVFObjC::removeAudioRenderer() https://bugs.webkit.org/show_bug.cgi?id=221490 Reviewed by Eric Carlson. Add null-checks to every use of player() in SourceBufferPrivateAVFObjC. * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::didParseInitializationData): (WebCore::SourceBufferPrivateAVFObjC::willProvideContentKeyRequestInitializationDataForTrackID): (WebCore::SourceBufferPrivateAVFObjC::didProvideContentKeyRequestInitializationDataForTrackID): (WebCore::SourceBufferPrivateAVFObjC::appendCompleted): (WebCore::SourceBufferPrivateAVFObjC::destroyParser): (WebCore::SourceBufferPrivateAVFObjC::destroyRenderers): (WebCore::SourceBufferPrivateAVFObjC::readyState const): (WebCore::SourceBufferPrivateAVFObjC::setReadyState): (WebCore::SourceBufferPrivateAVFObjC::trackDidChangeEnabled): (WebCore::SourceBufferPrivateAVFObjC::flushVideo): (WebCore::SourceBufferPrivateAVFObjC::enqueueSample): (WebCore::SourceBufferPrivateAVFObjC::bufferWasConsumed): (WebCore::SourceBufferPrivateAVFObjC::setDecompressionSession): (WebCore::SourceBufferPrivateAVFObjC::player const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272439 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-05 Jer Noble [Cocoa] CRASH in MediaPlayerPrivateMediaSourceAVFObjC::removeAudioRenderer() https://bugs.webkit.org/show_bug.cgi?id=221490 Reviewed by Eric Carlson. Add null-checks to every use of player() in SourceBufferPrivateAVFObjC. * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::didParseInitializationData): (WebCore::SourceBufferPrivateAVFObjC::willProvideContentKeyRequestInitializationDataForTrackID): (WebCore::SourceBufferPrivateAVFObjC::didProvideContentKeyRequestInitializationDataForTrackID): (WebCore::SourceBufferPrivateAVFObjC::appendCompleted): (WebCore::SourceBufferPrivateAVFObjC::destroyParser): (WebCore::SourceBufferPrivateAVFObjC::destroyRenderers): (WebCore::SourceBufferPrivateAVFObjC::readyState const): (WebCore::SourceBufferPrivateAVFObjC::setReadyState): (WebCore::SourceBufferPrivateAVFObjC::trackDidChangeEnabled): (WebCore::SourceBufferPrivateAVFObjC::flushVideo): (WebCore::SourceBufferPrivateAVFObjC::enqueueSample): (WebCore::SourceBufferPrivateAVFObjC::bufferWasConsumed): (WebCore::SourceBufferPrivateAVFObjC::setDecompressionSession): (WebCore::SourceBufferPrivateAVFObjC::player const): 2021-02-16 Ruben Turcios Cherry-pick r272435. rdar://problem/74410448 [LFC][Integration] Hit testing broken for descendants of pointer-events:none boxes https://bugs.webkit.org/show_bug.cgi?id=221460 Reviewed by Zalan Bujtas. Source/WebCore: Descendants of pointer-events:none boxes may still be hittestable if they override the value. LFC integration hit testing code didn't take this into account. Test: fast/events/hittest-pointer-event-none-descendants.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Replaced and inline-block boxes do the visibility/pointer-events test themselves. This code just needs to take care of text boxes. LayoutTests: * fast/events/hittest-pointer-event-none-descendants-expected.html: Added. * fast/events/hittest-pointer-event-none-descendants.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272435 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-05 Antti Koivisto [LFC][Integration] Hit testing broken for descendants of pointer-events:none boxes https://bugs.webkit.org/show_bug.cgi?id=221460 Reviewed by Zalan Bujtas. Descendants of pointer-events:none boxes may still be hittestable if they override the value. LFC integration hit testing code didn't take this into account. Test: fast/events/hittest-pointer-event-none-descendants.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Replaced and inline-block boxes do the visibility/pointer-events test themselves. This code just needs to take care of text boxes. 2021-02-16 Ruben Turcios Cherry-pick r272394. rdar://problem/74409285 Avoid creating JS wrapper on a removed node when the subtree is not observable https://bugs.webkit.org/show_bug.cgi?id=221243 Reviewed by Geoffrey Garen. Prior to this patch, WebKit forced the creation the JS wrapper on the root DOM node of a removed subtree to avoid script observable deletion of nodes. This is necessary because DOM nodes are reference counted in the C++ side, and while a DOM node keeps its child nodes alive, it won't keep its parent node alive to avoid reference cycles (leaks). If we didn't force the creation of the JS wrapper and the root node of the removed subtree didn't have any external reference to it in C++ side, we would happily delete it and all its descendant nodes above any subtree with a JS wrapper or an external C++ reference. While this turned out to be an effective strategy for implementing DOM nodes' GC semantics correctly, it has a significant runtime and memory cost - the latter is because we don't collect the JS wrappers of DOM nodes once they're created until they're ready to be destructed. This patch introduces a new optimization to avoid creating these JS wrappers when the removed subtree won't be observable by scripts in the future. The current heuristic is to check if the removed node has any external reference to it (i.e. refCount() > 0 excluding any reference counting that happens within our algorithm). This is sufficient because a given node should not be observable at a later time unless it has an external reference to it. This is ~0.5% progression on Speedometer-2.0 on MacBookAir7,2. To do this, we take advantage of the fact notifyChildNodeRemoved already traverses each removed subtree, and check if any of them has a reference count greater than 1 (greater than 1 because notifyChildNodeRemoved itself increments node's reference count before calling itself on child nodes). Note that we exclude the root node of the removed subtree as these JS wrapper creation is only needed to keep the root node alive. If the root node is already kept alive by some external reference to it, there is no need to keep it alive again by creating a JS wrapper on it. No new tests since existing tests such as fast/dom/gc-3.html covers it. * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Call willCreatePossiblyOrphanedTreeByRemoval if the removed subtree contains an observable node. (WebCore::ContainerNode::removeNodeWithScriptAssertion): Ditto. (WebCore::ContainerNode::removeSelfOrChildNodesForInsertion): Renamed from collectChildrenAndRemoveFromOldParent. Avoid collecting the removed nodes in this function in addition to removeAllChildrenWithScriptAssertion. (WebCore::ContainerNode::insertBefore): (WebCore::ContainerNode::replaceChild): (WebCore::ContainerNode::appendChildWithoutPreInsertionValidityCheck): (WebCore::dispatchChildRemovalEvents): Don't call willCreatePossiblyOrphanedTreeByRemoval here. * dom/ContainerNode.h: * dom/ContainerNodeAlgorithms.cpp: (WebCore::observabilityOfRemovedNode): Added. Checks the observability of a node excluding the root node of the removed subtree since it needs a special case in removeAllChildrenWithScriptAssertion. As notifyNodeRemovedFromDocument and notifyNodeRemovedFromTree ref's each child node before recursing on itself, we check refCount() > 1 here. (WebCore::updateObservability): Added. A helper function to update RemovedSubtreeObservability. (WebCore::notifyNodeRemovedFromDocument): Now returns RemovedSubtreeObservability, (WebCore::notifyNodeRemovedFromTree): Ditto. (WebCore::notifyChildNodeRemoved): Ditto. * dom/ContainerNodeAlgorithms.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272394 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-04 Ryosuke Niwa Avoid creating JS wrapper on a removed node when the subtree is not observable https://bugs.webkit.org/show_bug.cgi?id=221243 Reviewed by Geoffrey Garen. Prior to this patch, WebKit forced the creation the JS wrapper on the root DOM node of a removed subtree to avoid script observable deletion of nodes. This is necessary because DOM nodes are reference counted in the C++ side, and while a DOM node keeps its child nodes alive, it won't keep its parent node alive to avoid reference cycles (leaks). If we didn't force the creation of the JS wrapper and the root node of the removed subtree didn't have any external reference to it in C++ side, we would happily delete it and all its descendant nodes above any subtree with a JS wrapper or an external C++ reference. While this turned out to be an effective strategy for implementing DOM nodes' GC semantics correctly, it has a significant runtime and memory cost - the latter is because we don't collect the JS wrappers of DOM nodes once they're created until they're ready to be destructed. This patch introduces a new optimization to avoid creating these JS wrappers when the removed subtree won't be observable by scripts in the future. The current heuristic is to check if the removed node has any external reference to it (i.e. refCount() > 0 excluding any reference counting that happens within our algorithm). This is sufficient because a given node should not be observable at a later time unless it has an external reference to it. This is ~0.5% progression on Speedometer-2.0 on MacBookAir7,2. To do this, we take advantage of the fact notifyChildNodeRemoved already traverses each removed subtree, and check if any of them has a reference count greater than 1 (greater than 1 because notifyChildNodeRemoved itself increments node's reference count before calling itself on child nodes). Note that we exclude the root node of the removed subtree as these JS wrapper creation is only needed to keep the root node alive. If the root node is already kept alive by some external reference to it, there is no need to keep it alive again by creating a JS wrapper on it. No new tests since existing tests such as fast/dom/gc-3.html covers it. * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Call willCreatePossiblyOrphanedTreeByRemoval if the removed subtree contains an observable node. (WebCore::ContainerNode::removeNodeWithScriptAssertion): Ditto. (WebCore::ContainerNode::removeSelfOrChildNodesForInsertion): Renamed from collectChildrenAndRemoveFromOldParent. Avoid collecting the removed nodes in this function in addition to removeAllChildrenWithScriptAssertion. (WebCore::ContainerNode::insertBefore): (WebCore::ContainerNode::replaceChild): (WebCore::ContainerNode::appendChildWithoutPreInsertionValidityCheck): (WebCore::dispatchChildRemovalEvents): Don't call willCreatePossiblyOrphanedTreeByRemoval here. * dom/ContainerNode.h: * dom/ContainerNodeAlgorithms.cpp: (WebCore::observabilityOfRemovedNode): Added. Checks the observability of a node excluding the root node of the removed subtree since it needs a special case in removeAllChildrenWithScriptAssertion. As notifyNodeRemovedFromDocument and notifyNodeRemovedFromTree ref's each child node before recursing on itself, we check refCount() > 1 here. (WebCore::updateObservability): Added. A helper function to update RemovedSubtreeObservability. (WebCore::notifyNodeRemovedFromDocument): Now returns RemovedSubtreeObservability, (WebCore::notifyNodeRemovedFromTree): Ditto. (WebCore::notifyChildNodeRemoved): Ditto. * dom/ContainerNodeAlgorithms.h: 2021-02-16 Ruben Turcios Cherry-pick r272390. rdar://problem/74409535 AX: expose focusable elements even if element or ancestor has aria-hidden=true https://bugs.webkit.org/show_bug.cgi?id=220534 Reviewed by Zalan Bujtas. Source/WebCore: ARIA states that if an item is focused, then it should override aria-hidden status. https://github.com/w3c/aria/pull/1387/files Test: accessibility/focusable-inside-hidden.html * accessibility/AXObjectCache.cpp: (WebCore::isNodeAriaVisible): * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::isAXHidden const): (WebCore::AccessibilityObject::setIsIgnoredFromParentDataForChild): LayoutTests: * accessibility/focusable-inside-hidden-expected.txt: Added. * accessibility/focusable-inside-hidden.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272390 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-04 Chris Fleizach AX: expose focusable elements even if element or ancestor has aria-hidden=true https://bugs.webkit.org/show_bug.cgi?id=220534 Reviewed by Zalan Bujtas. ARIA states that if an item is focused, then it should override aria-hidden status. https://github.com/w3c/aria/pull/1387/files Test: accessibility/focusable-inside-hidden.html * accessibility/AXObjectCache.cpp: (WebCore::isNodeAriaVisible): * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::isAXHidden const): (WebCore::AccessibilityObject::setIsIgnoredFromParentDataForChild): 2021-02-10 Alan Coon Revert r272541. rdar://problem/74208306 2021-02-08 Russell Epstein Cherry-pick r272345. rdar://problem/74032500 [WebAuthn] Allow one user gesture free prompt for each navigation https://bugs.webkit.org/show_bug.cgi?id=220897 Reviewed by Brent Fulgham. Source/WebCore: * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::resetUserGestureRequirement): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.h: * page/Quirks.cpp: * page/Quirks.cpp.h: * replay/UserInputBridge.cpp: (WebCore::UserInputBridge::loadRequest): (WebCore::UserInputBridge::reloadFrame): Adds the ability to reset the user gesture requirement flag for user initiated reloads and quirks. Source/WebKit: This is a quirk that only allows certain websites. Covered by existing tests. * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::filterTransports const): (WebKit::AuthenticatorManager::runPanel): (WebKit::AuthenticatorManager::runPresenter): Cancel the whole WebAuthn operation if no user gesture is indicated. * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.cpp: (WebKit::WebAuthenticatorCoordinator::makeCredential): (WebKit::WebAuthenticatorCoordinator::getAssertion): * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.h: Set a boolean to indicate a free coupon for each navigation. Tools: * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm: (TestWebKitAPI::TEST): LayoutTests: * http/wpt/webauthn/ctap-hid-failure.https-expected.txt: * http/wpt/webauthn/ctap-hid-success.https-expected.txt: * http/wpt/webauthn/ctap-nfc-failure.https-expected.txt: * http/wpt/webauthn/idl.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-hid-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-local-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-hid-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-local-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-u2f.https-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272345 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Jiewen Tan [WebAuthn] Allow one user gesture free prompt for each navigation https://bugs.webkit.org/show_bug.cgi?id=220897 Reviewed by Brent Fulgham. * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::resetUserGestureRequirement): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.h: * page/Quirks.cpp: * page/Quirks.cpp.h: * replay/UserInputBridge.cpp: (WebCore::UserInputBridge::loadRequest): (WebCore::UserInputBridge::reloadFrame): Adds the ability to reset the user gesture requirement flag for user initiated reloads and quirks. 2021-02-08 Russell Epstein Cherry-pick r272422. rdar://problem/74033021 Make sure click attribution is processed in case of redirected kept alive loads https://bugs.webkit.org/show_bug.cgi?id=221453 Reviewed by John Wilander. Source/WebCore: Test: http/tests/privateClickMeasurement/attribution-conversion-through-fetch-keepalive.html * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::addSubresourceLoader): Update assertion to cope with keep alive fetches which are similar to beacon/ping loads. Source/WebKit: * NetworkProcess/NetworkResourceLoader.cpp: (WebKit::NetworkResourceLoader::continueWillSendRedirectedRequest): Move the click attribution processing before kept alive check. LayoutTests: * http/tests/privateClickMeasurement/attribution-conversion-through-fetch-keepalive-expected.txt: Added. * http/tests/privateClickMeasurement/attribution-conversion-through-fetch-keepalive.html: Added. * http/tests/privateClickMeasurement/resources/redirectToConversion.php: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272422 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-05 Youenn Fablet Make sure click attribution is processed in case of redirected kept alive loads https://bugs.webkit.org/show_bug.cgi?id=221453 Reviewed by John Wilander. Test: http/tests/privateClickMeasurement/attribution-conversion-through-fetch-keepalive.html * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::addSubresourceLoader): Update assertion to cope with keep alive fetches which are similar to beacon/ping loads. 2021-02-08 Russell Epstein Cherry-pick r272368. rdar://problem/74032667 [macOS] Selecting a date on datetime-local inputs unexpectedly adds second and millisecond fields https://bugs.webkit.org/show_bug.cgi?id=221350 Reviewed by Devin Rousso. Source/WebCore: Currently, when setting the value of a datetime-local input using the picker, the length of the current value of the input is used to determine whether or not to return a value with second/millisecond precision. This is approach is incorrect, since the value could be empty, while the step attribute can specify second/millisecond precision. To fix, ensure the DateTimeChooserParameters knows whether the input has second and millisecond fields. That information can then be used by the UIProcess to return a correctly formatted value to the WebProcess. Test: fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-choose-value-from-picker.html * html/BaseDateAndTimeInputType.cpp: (WebCore::BaseDateAndTimeInputType::handleDOMActivateEvent): (WebCore::BaseDateAndTimeInputType::didChangeValueFromControl): (WebCore::BaseDateAndTimeInputType::setupDateTimeChooserParameters): Moved this method from HTMLInputElement to the input type, since it is specific to date/time input types, and to leverage the existing shouldHaveSecondField and shouldHaveMillisecondField methods when building the DateTimeChooserParameters. * html/BaseDateAndTimeInputType.h: * html/HTMLInputElement.cpp: * html/HTMLInputElement.h: * platform/DateTimeChooserParameters.h: Added hasSecondField and hasMillisecondField members, so that the UIProcess knows whether or not to return a string that contains seconds/milliseconds. (WebCore::DateTimeChooserParameters::encode const): (WebCore::DateTimeChooserParameters::decode): Source/WebKit: * UIProcess/mac/WebDateTimePickerMac.mm: (-[WKDateTimePicker updatePicker:]): (-[WKDateTimePicker dateFormatStringForType:]): Do not use the length of the value to determine whether or seconds and milliseconds should be present, since the value can be empty. Instead, use the new information in DateTimeChooserParameters, matching the visual appearance of the input. Tools: Added a method to UIScriptController to simulate selecting a date using the presented date picker. * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.h: (WTR::UIScriptController::chooseDateTimePickerValue): * WebKitTestRunner/mac/UIScriptControllerMac.h: * WebKitTestRunner/mac/UIScriptControllerMac.mm: (WTR::UIScriptControllerMac::chooseDateTimePickerValue): LayoutTests: Added a test to to verify that the presence of seconds and milliseconds in the value of a datetime-local input after selecting a date using the picker matches the configuration. * fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-choose-value-from-picker-expected.txt: Added. * fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-choose-value-from-picker.html: Added. * resources/ui-helper.js: (window.UIHelper.chooseDateTimePickerValue): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272368 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-04 Aditya Keerthi [macOS] Selecting a date on datetime-local inputs unexpectedly adds second and millisecond fields https://bugs.webkit.org/show_bug.cgi?id=221350 Reviewed by Devin Rousso. Currently, when setting the value of a datetime-local input using the picker, the length of the current value of the input is used to determine whether or not to return a value with second/millisecond precision. This is approach is incorrect, since the value could be empty, while the step attribute can specify second/millisecond precision. To fix, ensure the DateTimeChooserParameters knows whether the input has second and millisecond fields. That information can then be used by the UIProcess to return a correctly formatted value to the WebProcess. Test: fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-choose-value-from-picker.html * html/BaseDateAndTimeInputType.cpp: (WebCore::BaseDateAndTimeInputType::handleDOMActivateEvent): (WebCore::BaseDateAndTimeInputType::didChangeValueFromControl): (WebCore::BaseDateAndTimeInputType::setupDateTimeChooserParameters): Moved this method from HTMLInputElement to the input type, since it is specific to date/time input types, and to leverage the existing shouldHaveSecondField and shouldHaveMillisecondField methods when building the DateTimeChooserParameters. * html/BaseDateAndTimeInputType.h: * html/HTMLInputElement.cpp: * html/HTMLInputElement.h: * platform/DateTimeChooserParameters.h: Added hasSecondField and hasMillisecondField members, so that the UIProcess knows whether or not to return a string that contains seconds/milliseconds. (WebCore::DateTimeChooserParameters::encode const): (WebCore::DateTimeChooserParameters::decode): 2021-02-08 Russell Epstein Cherry-pick r272353. rdar://problem/74105476 [Cocoa] WebM audio goes out-of-sync or stops playing after a seek https://bugs.webkit.org/show_bug.cgi?id=221354 Reviewed by Eric Carlson. Source/WebCore: Add a new flag to MediaSample indicating whether the sample has any information about whether it is an sync-sample or not, and expose that through a new method hasSyncInfo(). Drive-by Fix: Force all video samples to contain a sample attachments dictionary, whether or not the sample is sync. Drive-by Fix #2: SampleMap does an equality comparison for `flags() == MediaSample::IsSync`. This breaks as soon as any sample has both `IsSync` and any other flag. Replace with a specific call to `isSync()` instead. * platform/MediaSample.h: * platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm: (WebCore::doesCMSampleBufferHaveSyncInfo): (WebCore::MediaSampleAVFObjC::flags const): * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::VideoTrackData::createSampleBuffer): Source/WebKit: The MTPluginFormatReader will attempt to determine whether an audio sample needs priming frames by querying for, among other things, its "syncInfo". Previously, we had just presumed all samples without a sample attachment dictionary were sync samples, and reported them as such from MediaSampleCursor, but this causes the format reader plugin to walk backwards all the way to the beginning of the audio track looking for priming samples. Instead, since the sample in question has no sync info (it was synthesized by MediaSample), return kCMBaseObjectError_ValueNotAvailable in this case, which causes the plugin format reader to assume all samples are both sync and do not require explicit priming frames. * Shared/mac/MediaFormatReader/MediaSampleCursor.cpp: (WebKit::MediaSampleCursor::getSampleTiming const): (WebKit::MediaSampleCursor::getSyncInfo const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272353 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Jer Noble [Cocoa] WebM audio goes out-of-sync or stops playing after a seek https://bugs.webkit.org/show_bug.cgi?id=221354 Reviewed by Eric Carlson. Add a new flag to MediaSample indicating whether the sample has any information about whether it is an sync-sample or not, and expose that through a new method hasSyncInfo(). Drive-by Fix: Force all video samples to contain a sample attachments dictionary, whether or not the sample is sync. Drive-by Fix #2: SampleMap does an equality comparison for `flags() == MediaSample::IsSync`. This breaks as soon as any sample has both `IsSync` and any other flag. Replace with a specific call to `isSync()` instead. * platform/MediaSample.h: * platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm: (WebCore::doesCMSampleBufferHaveSyncInfo): (WebCore::MediaSampleAVFObjC::flags const): * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::VideoTrackData::createSampleBuffer): 2021-02-08 Russell Epstein Cherry-pick r272303. rdar://problem/74105623 Animation of "rotate" or "scale" property does not correctly account for static "translate" property https://bugs.webkit.org/show_bug.cgi?id=219894 Unreviewed build fix for Mojave. * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272303 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-01 Antoine Quint Animation of "rotate" or "scale" property does not correctly account for static "translate" property https://bugs.webkit.org/show_bug.cgi?id=219894 Unreviewed build fix for Mojave. * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): 2021-02-08 Russell Epstein Cherry-pick r272234. rdar://problem/74105068 [macOS] Force loading the HEIF reader symbols before transcoding any HEIF image https://bugs.webkit.org/show_bug.cgi?id=221191 Reviewed by Tim Horton. Source/WebCore: Transcoding the HEIF images requires loading the HEIF reader symbols which is not happening in macOS Catalina. A workaround for this bug in WebKit is to call CGImageSourceGetCount() for the CGImageSource of the HEIF image. * platform/graphics/cg/ImageUtilitiesCG.cpp: (WebCore::transcodeImage): Source/WTF: Add a HAVE macro for the fix of . * wtf/PlatformHave.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272234 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-02 Said Abou-Hallawa [macOS] Force loading the HEIF reader symbols before transcoding any HEIF image https://bugs.webkit.org/show_bug.cgi?id=221191 Reviewed by Tim Horton. Transcoding the HEIF images requires loading the HEIF reader symbols which is not happening in macOS Catalina. A workaround for this bug in WebKit is to call CGImageSourceGetCount() for the CGImageSource of the HEIF image. * platform/graphics/cg/ImageUtilitiesCG.cpp: (WebCore::transcodeImage): 2021-02-08 Russell Epstein Cherry-pick r272214. rdar://problem/74032646 Unreviewed, address post-landing review comment by Darin Adler for r272211. * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::cookiesForURL): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272214 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-02 Chris Dumez Unreviewed, address post-landing review comment by Darin Adler for r272211. * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::cookiesForURL): 2021-02-08 Russell Epstein Cherry-pick r272211. rdar://problem/74032646 Crash under NetworkStorageSession::cookiesForSession() https://bugs.webkit.org/show_bug.cgi?id=221227 Reviewed by Geoffrey Garen. Retain NSArray of cookies in NetworkStorageSession::cookiesForSession() for clearer lifetime management. This is a speculative fix for . * platform/network/NetworkStorageSession.h: * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::httpCookies const): (WebCore::cookiesForURL): (WebCore::NetworkStorageSession::httpCookiesForURL const): (WebCore::NetworkStorageSession::cookiesForURL const): (WebCore::NetworkStorageSession::cookiesForSession const): (WebCore::NetworkStorageSession::getRawCookies const): (WebCore::NetworkStorageSession::deleteCookie const): (WebCore::NetworkStorageSession::getHostnamesWithCookies): (WebCore::NetworkStorageSession::deleteCookiesForHostnames): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272211 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-02 Chris Dumez Crash under NetworkStorageSession::cookiesForSession() https://bugs.webkit.org/show_bug.cgi?id=221227 Reviewed by Geoffrey Garen. Retain NSArray of cookies in NetworkStorageSession::cookiesForSession() for clearer lifetime management. This is a speculative fix for . * platform/network/NetworkStorageSession.h: * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::httpCookies const): (WebCore::cookiesForURL): (WebCore::NetworkStorageSession::httpCookiesForURL const): (WebCore::NetworkStorageSession::cookiesForURL const): (WebCore::NetworkStorageSession::cookiesForSession const): (WebCore::NetworkStorageSession::getRawCookies const): (WebCore::NetworkStorageSession::deleteCookie const): (WebCore::NetworkStorageSession::getHostnamesWithCookies): (WebCore::NetworkStorageSession::deleteCookiesForHostnames): 2021-02-08 Russell Epstein Cherry-pick r272201. rdar://problem/74105623 Animation of "rotate" or "scale" property does not correctly account for static "translate" property https://bugs.webkit.org/show_bug.cgi?id=219894 Reviewed by Dean Jackson. Source/WebCore: The CSS transform-related properties are designed to be applied in a specific order, guaranteeing that "translate" is applied prior to both "scale" and "rotate". Since Core Animation has no concept of these individual transform-related CSS properties, we use additive Core Animation animations to apply the value of each CSS property, using non-interpolating animations set to start at the earliest time in the Core Animation timeline and lasting forever to set the value of any underlying, non-animated value. As such, in an example where an element would have a static "translate" property set as well as a "rotate" or "scale" animation, we would yield the following animations, added in this order: 1. non-interpolating animation beginning at 1s setting the identity transform (the "clean slate" animation) 2. interpolating animation beginning at a time > 1s for the "scale" or "rotate" animation 3. non-interpolating animation beginning at 1s setting the "translate" value Note that animations 2 and 3 are additive and thus added in the inverse order that we expect animations to be applied. Due to a peculiarity of Core Animation (introduced in macOS 10.15), additive animations are applied in an inverse order, hence the build-time flag CA_WHERE_ADDITIVE_TRANSFORMS_ARE_REVERSED. However, Core Animation will first sort all animations based on their begin time, only respecting the order in which animations are added when their begin time is equal. This means that in practice, our animations were applied in the order 1, 3, 2, and thus the "translate" property was applied after the "rotate" or "scale" animation. In order to address this, we now create a CAAnimationGroup for each set of animations created for a given CSS property. Each of these groups shares the same begin time, 1s, to allow for "forever" non-interpolating animations to be applied, but also to set a common base time for animations to be applied in the expected order. Tests: webanimations/relative-ordering-of-translate-and-rotate-properties-accelerated.html webanimations/relative-ordering-of-translate-and-scale-properties-accelerated.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): * platform/graphics/ca/GraphicsLayerCA.h: (WebCore::GraphicsLayerCA::LayerPropertyAnimation::computedBeginTime const): LayoutTests: Add two new tests that ensure that translate is indeed applied before rotate and scale. * webanimations/relative-ordering-of-translate-and-rotate-properties-accelerated-expected.html: Added. * webanimations/relative-ordering-of-translate-and-rotate-properties-accelerated.html: Added. * webanimations/relative-ordering-of-translate-and-scale-properties-accelerated-expected.html: Added. * webanimations/relative-ordering-of-translate-and-scale-properties-accelerated.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272201 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-01 Antoine Quint Animation of "rotate" or "scale" property does not correctly account for static "translate" property https://bugs.webkit.org/show_bug.cgi?id=219894 Reviewed by Dean Jackson. The CSS transform-related properties are designed to be applied in a specific order, guaranteeing that "translate" is applied prior to both "scale" and "rotate". Since Core Animation has no concept of these individual transform-related CSS properties, we use additive Core Animation animations to apply the value of each CSS property, using non-interpolating animations set to start at the earliest time in the Core Animation timeline and lasting forever to set the value of any underlying, non-animated value. As such, in an example where an element would have a static "translate" property set as well as a "rotate" or "scale" animation, we would yield the following animations, added in this order: 1. non-interpolating animation beginning at 1s setting the identity transform (the "clean slate" animation) 2. interpolating animation beginning at a time > 1s for the "scale" or "rotate" animation 3. non-interpolating animation beginning at 1s setting the "translate" value Note that animations 2 and 3 are additive and thus added in the inverse order that we expect animations to be applied. Due to a peculiarity of Core Animation (introduced in macOS 10.15), additive animations are applied in an inverse order, hence the build-time flag CA_WHERE_ADDITIVE_TRANSFORMS_ARE_REVERSED. However, Core Animation will first sort all animations based on their begin time, only respecting the order in which animations are added when their begin time is equal. This means that in practice, our animations were applied in the order 1, 3, 2, and thus the "translate" property was applied after the "rotate" or "scale" animation. In order to address this, we now create a CAAnimationGroup for each set of animations created for a given CSS property. Each of these groups shares the same begin time, 1s, to allow for "forever" non-interpolating animations to be applied, but also to set a common base time for animations to be applied in the expected order. Tests: webanimations/relative-ordering-of-translate-and-rotate-properties-accelerated.html webanimations/relative-ordering-of-translate-and-scale-properties-accelerated.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): * platform/graphics/ca/GraphicsLayerCA.h: (WebCore::GraphicsLayerCA::LayerPropertyAnimation::computedBeginTime const): 2021-02-08 Russell Epstein Cherry-pick r272188. rdar://problem/74032553 [Cocoa] Disable interstitial events on AVPlayerItem. https://bugs.webkit.org/show_bug.cgi?id=221215 Reviewed by Eric Carlson. Source/WebCore: * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem): Source/WebCore/PAL: * pal/spi/cocoa/AVFoundationSPI.h: Source/WTF: * wtf/PlatformHave.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272188 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-01 Jer Noble [Cocoa] Disable interstitial events on AVPlayerItem. https://bugs.webkit.org/show_bug.cgi?id=221215 Reviewed by Eric Carlson. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem): 2021-02-08 Russell Epstein Cherry-pick r272185. rdar://problem/74032429 REGRESSION (iOS 14.2): Can't play html audio with muted attribute https://bugs.webkit.org/show_bug.cgi?id=219295 Reviewed by Eric Carlson. In r266844, we added a power-saving feature that would disable the audio decoder for initially muted media elements. However, this caused an issue for .mp3 files, where the duration of the track is computed by the decoder, and not the parser. Since the goal of the power-saving feature was to reduce the CPU cost for decoding a muted audio track on a