2018-05-31 Kocsen Chung Cherry-pick r232315. rdar://problem/40641066 Revert changes made to URLWithUserTypedString made in https://trac.webkit.org/changeset/232281 https://bugs.webkit.org/show_bug.cgi?id=186108 Reviewed by Alex Christensen. Covered by existing API tests. * platform/mac/WebCoreNSURLExtras.mm: (WebCore::URLWithUserTypedString): Return early if WebCore::URL is not able to create a CFURL. Use CFURL otherwise to keep the existing behavior as much as possible. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@232315 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-30 Youenn Fablet Revert changes made to URLWithUserTypedString made in https://trac.webkit.org/changeset/232281 https://bugs.webkit.org/show_bug.cgi?id=186108 Reviewed by Alex Christensen. Covered by existing API tests. * platform/mac/WebCoreNSURLExtras.mm: (WebCore::URLWithUserTypedString): Return early if WebCore::URL is not able to create a CFURL. Use CFURL otherwise to keep the existing behavior as much as possible. 2018-05-31 Kocsen Chung Cherry-pick r232281. rdar://problem/40641066 Add a consistency check between URL and CFURL Source/WebCore: https://bugs.webkit.org/show_bug.cgi?id=186057 Reviewed by Geoff Garen. It is important that WebCore::URL used in WebCore and CFURL that gets serialized in the network pipe remain consistent. Otherwise, we will end-up with odd bugs. We add such a check when creating a CFURL from an URL. To make things more consistent, we also rely now more on WebCore::URL instead of directly creating a CFURL. * platform/URL.h: * platform/cf/CFURLExtras.cpp: (WebCore::isCFURLSameOrigin): * platform/cf/CFURLExtras.h: * platform/cf/URLCF.cpp: (WebCore::URL::createCFURL const): * platform/mac/URLMac.mm: (WebCore::URL::createCFURL const): * platform/mac/WebCoreNSURLExtras.mm: (WebCore::URLWithUserTypedString): Source/WebKit: https://bugs.webkit.org/show_bug.cgi?id=186057 Reviewed by Geoff Garen. * Shared/Cocoa/WKNSURLExtras.mm: (+[NSURL _web_URLWithWTFString:relativeToURL:]): (urlWithWTFString): Deleted. (+[NSURL _web_URLWithWTFString:]): Deleted. Tools: https://bugs.webkit.org/show_bug.cgi?id=182444 Reviewed by Geoff Garen. DRT code expected a non null URL which is no longer the case now. Updated DRT to remove that assumption. * DumpRenderTree/TestRunner.cpp: (TestRunner::redirectionDestinationForURL): * DumpRenderTree/TestRunner.h: * DumpRenderTree/mac/ResourceLoadDelegate.mm: (-[ResourceLoadDelegate webView:resource:willSendRequest:redirectResponse:fromDataSource:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@232281 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-29 Youenn Fablet Add a consistency check between URL and CFURL https://bugs.webkit.org/show_bug.cgi?id=186057 Reviewed by Geoff Garen. It is important that WebCore::URL used in WebCore and CFURL that gets serialized in the network pipe remain consistent. Otherwise, we will end-up with odd bugs. We add such a check when creating a CFURL from an URL. To make things more consistent, we also rely now more on WebCore::URL instead of directly creating a CFURL. * platform/URL.h: * platform/cf/CFURLExtras.cpp: (WebCore::isCFURLSameOrigin): * platform/cf/CFURLExtras.h: * platform/cf/URLCF.cpp: (WebCore::URL::createCFURL const): * platform/mac/URLMac.mm: (WebCore::URL::createCFURL const): * platform/mac/WebCoreNSURLExtras.mm: (WebCore::URLWithUserTypedString): 2018-05-23 Jer Noble [El Capitan] FAIL http/tests/security/webaudio-render-remote-audio-allowed-crossorigin.html https://bugs.webkit.org/show_bug.cgi?id=185920 Reviewed by Eric Carlson. Disable the recently added CORS checks for MediaElementAudioSourceNode on El Capitan; no custom media loading is available there, so we don't have the ability to tell if HTMLMediaElement loads are CORS-valid. * Modules/webaudio/MediaElementAudioSourceNode.cpp: (WebCore::MediaElementAudioSourceNode::setFormat): 2018-05-17 Kocsen Chung Cherry-pick r229503. rdar://problem/39841080 [macOS] Copying a table from the Numbers app and pasting into iCloud Numbers fails https://bugs.webkit.org/show_bug.cgi?id=183485 Reviewed by Ryosuke Niwa. Source/WebCore: After r222656, WebKit now treats raw image data on the pasteboard as files for the purposes of computing DataTransfer.files and DataTransfer.types. However, this is combined with existing policies that suppress DataTransfer.getData and DataTransfer.setData when the pasteboard contains files (generalized to copy/paste in r222688). This means we now don't allow web pages to access "text/plain" in the case where the user copies part of a table from the native Numbers app since Numbers additionally writes a snapshot of the table to the platform pasteboard. This restriction on getData/setData was intended to prevent web pages from extracting users' file paths when pasting or dropping, so it doesn't make sense to enforce this restriction even when there is only in-memory image data on the pasteboard. To fix this bug, we make Pasteboard::fileContentState() differentiate between cases where there are (real) files on the pasteboard, and cases where we've fallen back to treating image data as files. Rebaselined existing LayoutTests to match new behavior. Also covered by 4 new API tests: - PasteMixedContent.ImageDataAndPlainText - PasteMixedContent.ImageDataAndPlainTextAndURL - PasteMixedContent.ImageDataAndPlainTextAndURLAndHTML - UIPasteboardTests.DataTransferGetDataWhenPastingImageAndText * dom/DataTransfer.cpp: (WebCore::DataTransfer::shouldSuppressGetAndSetDataToAvoidExposingFilePaths const): If custom pasteboard data is enabled, suppress getData and setData if and only if we might actually expose file paths (see Pasteboard::fileContentState). (WebCore::DataTransfer::types const): Only allow "text/html" or "text/uri-list" in the case where there are actual files in the pasteboard. If there's only image data, add all of the DOM-safe types back into the list of types. * platform/Pasteboard.h: * platform/StaticPasteboard.h: Add an enum type to represent the result of Pasteboard::fileContentState. - NoFileOrImageData indicates that there was nothing on the pasteboard that could be considered a file from the point of view of the page. - InMemoryImage indicates that there are no files on the pasteboard, but there is image data that we consider to be files, exposed via DataTransfer API. - MayContainFilePaths indicates that there might be file paths on the pasteboard. This means that the source has either written file paths to the pasteboard (for example, through NSFilenamesPboardType) or the source has written image data along with a URL type of some sort that does not match one of the allowed URL schemes that are safe to expose (currently, these are http-family, data, or blob). * platform/cocoa/PasteboardCocoa.mm: (WebCore::Pasteboard::fileContentState): Refactor to return one of the three enum types described above. (WebCore::Pasteboard::containsFiles): Deleted. * platform/gtk/PasteboardGtk.cpp: (WebCore::Pasteboard::fileContentState): (WebCore::Pasteboard::containsFiles): Deleted. * platform/win/PasteboardWin.cpp: (WebCore::Pasteboard::fileContentState): (WebCore::Pasteboard::containsFiles): Deleted. * platform/wpe/PasteboardWPE.cpp: (WebCore::Pasteboard::fileContentState): (WebCore::Pasteboard::containsFiles): Deleted. Adjust for Pasteboard::fileContentState() tweaks. Tools: Add new API tests to cover scenarios in which we paste image data alongside text data. * TestWebKitAPI/Tests/WebKitCocoa/PasteMixedContent.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/ios/UIPasteboardTests.mm: (TestWebKitAPI::TEST): LayoutTests: Rebaseline some pasteboard-related layout tests, in which we now expose text/plain alongside files that were written to the DataTransfer by the page itself. * editing/pasteboard/data-transfer-item-list-add-file-multiple-times-expected.txt: * editing/pasteboard/data-transfer-item-list-add-file-on-copy-expected.txt: * editing/pasteboard/data-transfer-item-list-add-file-on-drag-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@229503 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-03-10 Wenson Hsieh [macOS] Copying a table from the Numbers app and pasting into iCloud Numbers fails https://bugs.webkit.org/show_bug.cgi?id=183485 Reviewed by Ryosuke Niwa. After r222656, WebKit now treats raw image data on the pasteboard as files for the purposes of computing DataTransfer.files and DataTransfer.types. However, this is combined with existing policies that suppress DataTransfer.getData and DataTransfer.setData when the pasteboard contains files (generalized to copy/paste in r222688). This means we now don't allow web pages to access "text/plain" in the case where the user copies part of a table from the native Numbers app since Numbers additionally writes a snapshot of the table to the platform pasteboard. This restriction on getData/setData was intended to prevent web pages from extracting users' file paths when pasting or dropping, so it doesn't make sense to enforce this restriction even when there is only in-memory image data on the pasteboard. To fix this bug, we make Pasteboard::fileContentState() differentiate between cases where there are (real) files on the pasteboard, and cases where we've fallen back to treating image data as files. Rebaselined existing LayoutTests to match new behavior. Also covered by 4 new API tests: - PasteMixedContent.ImageDataAndPlainText - PasteMixedContent.ImageDataAndPlainTextAndURL - PasteMixedContent.ImageDataAndPlainTextAndURLAndHTML - UIPasteboardTests.DataTransferGetDataWhenPastingImageAndText * dom/DataTransfer.cpp: (WebCore::DataTransfer::shouldSuppressGetAndSetDataToAvoidExposingFilePaths const): If custom pasteboard data is enabled, suppress getData and setData if and only if we might actually expose file paths (see Pasteboard::fileContentState). (WebCore::DataTransfer::types const): Only allow "text/html" or "text/uri-list" in the case where there are actual files in the pasteboard. If there's only image data, add all of the DOM-safe types back into the list of types. * platform/Pasteboard.h: * platform/StaticPasteboard.h: Add an enum type to represent the result of Pasteboard::fileContentState. - NoFileOrImageData indicates that there was nothing on the pasteboard that could be considered a file from the point of view of the page. - InMemoryImage indicates that there are no files on the pasteboard, but there is image data that we consider to be files, exposed via DataTransfer API. - MayContainFilePaths indicates that there might be file paths on the pasteboard. This means that the source has either written file paths to the pasteboard (for example, through NSFilenamesPboardType) or the source has written image data along with a URL type of some sort that does not match one of the allowed URL schemes that are safe to expose (currently, these are http-family, data, or blob). * platform/cocoa/PasteboardCocoa.mm: (WebCore::Pasteboard::fileContentState): Refactor to return one of the three enum types described above. (WebCore::Pasteboard::containsFiles): Deleted. * platform/gtk/PasteboardGtk.cpp: (WebCore::Pasteboard::fileContentState): (WebCore::Pasteboard::containsFiles): Deleted. * platform/win/PasteboardWin.cpp: (WebCore::Pasteboard::fileContentState): (WebCore::Pasteboard::containsFiles): Deleted. * platform/wpe/PasteboardWPE.cpp: (WebCore::Pasteboard::fileContentState): (WebCore::Pasteboard::containsFiles): Deleted. Adjust for Pasteboard::fileContentState() tweaks. 2018-05-17 Kocsen Chung Cherry-pick r230533. rdar://problem/40345980 IDN spoofing with Hebrew combining characters https://bugs.webkit.org/show_bug.cgi?id=184472 Reviewed by Brent Fulgham. Source/WebCore: Covered by new API tests. * platform/mac/WebCoreNSURLExtras.mm: (WebCore::isLookalikeCharacter): Punycode-encode hosts with Hebrew combining marks that look like dots and Vav with a combining dot above like we do with dotless i and j. Tools: * TestWebKitAPI/Tests/WebCore/cocoa/URLExtras.mm: (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230533 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-04-10 Alex Christensen IDN spoofing with Hebrew combining characters https://bugs.webkit.org/show_bug.cgi?id=184472 Reviewed by Brent Fulgham. Covered by new API tests. * platform/mac/WebCoreNSURLExtras.mm: (WebCore::isLookalikeCharacter): Punycode-encode hosts with Hebrew combining marks that look like dots and Vav with a combining dot above like we do with dotless i and j. 2018-05-15 Kocsen Chung Cherry-pick r231392. rdar://problem/40230018 Release assert in ScriptController::canExecuteScripts via HTMLMediaElement::~HTMLMediaElement() https://bugs.webkit.org/show_bug.cgi?id=185288 Reviewed by Jer Noble. The crash is caused by HTMLMediaElement::~HTMLMediaElement canceling the resource load via CachedResource which ends up calling FrameLoader::checkCompleted() and fire load event on the document synchronously. Speculatively fix the crash by scheduling the check instead. In long term, ResourceLoader::cancel should never fire load event synchronously: webkit.org/b/185284. Unfortunately, no new tests since I can't get MediaResource to get destructed at the right time. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::isRunningDestructor): Added to detect this specific case. (WebCore::HTMLMediaElementDestructorScope): Added. (WebCore::HTMLMediaElementDestructorScope::HTMLMediaElementDestructorScope): Added. (WebCore::HTMLMediaElementDestructorScope::~HTMLMediaElementDestructorScope): Added. (WebCore::HTMLMediaElement::~HTMLMediaElement): Instantiate HTMLMediaElement. * html/HTMLMediaElement.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::checkCompleted): Call scheduleCheckCompleted instead of synchronously calling checkCompleted if we're in the middle of destructing a HTMLMediaElement. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231392 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-03 Ryosuke Niwa Release assert in ScriptController::canExecuteScripts via HTMLMediaElement::~HTMLMediaElement() https://bugs.webkit.org/show_bug.cgi?id=185288 Reviewed by Jer Noble. The crash is caused by HTMLMediaElement::~HTMLMediaElement canceling the resource load via CachedResource which ends up calling FrameLoader::checkCompleted() and fire load event on the document synchronously. Speculatively fix the crash by scheduling the check instead. In long term, ResourceLoader::cancel should never fire load event synchronously: webkit.org/b/185284. Unfortunately, no new tests since I can't get MediaResource to get destructed at the right time. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::isRunningDestructor): Added to detect this specific case. (WebCore::HTMLMediaElementDestructorScope): Added. (WebCore::HTMLMediaElementDestructorScope::HTMLMediaElementDestructorScope): Added. (WebCore::HTMLMediaElementDestructorScope::~HTMLMediaElementDestructorScope): Added. (WebCore::HTMLMediaElement::~HTMLMediaElement): Instantiate HTMLMediaElement. * html/HTMLMediaElement.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::checkCompleted): Call scheduleCheckCompleted instead of synchronously calling checkCompleted if we're in the middle of destructing a HTMLMediaElement. 2018-05-15 Kocsen Chung Cherry-pick r231713. rdar://problem/40172913 LinkLoader fails to remove CachedResourceClient in some cases https://bugs.webkit.org/show_bug.cgi?id=185553 Reviewed by Geoffrey Garen. Source/WebCore: Test: http/tests/preload/link-preload-client-remove.html * loader/LinkLoader.cpp: (WebCore::LinkLoader::loadLink): If there is a link preload already in progress, we fail to clear the client for the ongoing load. This may leave the CachedResource client map in a bad state. LayoutTests: * http/tests/preload/link-preload-client-remove-expected.txt: Added. * http/tests/preload/link-preload-client-remove.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231713 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-11 Antti Koivisto LinkLoader fails to remove CachedResourceClient in some cases https://bugs.webkit.org/show_bug.cgi?id=185553 Reviewed by Geoffrey Garen. Test: http/tests/preload/link-preload-client-remove.html * loader/LinkLoader.cpp: (WebCore::LinkLoader::loadLink): If there is a link preload already in progress, we fail to clear the client for the ongoing load. This may leave the CachedResource client map in a bad state. 2018-05-15 Kocsen Chung Cherry-pick r231267. rdar://problem/39988097 REGRESSION(r225868): Release assert when removing an SVGUseElement from Document::m_svgUseElements https://bugs.webkit.org/show_bug.cgi?id=182188 Reviewed by Antti Koivisto. Fixed the crash by removing up the release assert. The crash is likely caused by re-entrancy to Document::resolveStyle during SVGUseElement::updateShadowTree. Because Document::resolveStyle invokes updateShadowTree on SVG use elements in Document::m_svgUseElements without clearing the map, the nested call to resolveStyle ends up calling updateShadowTree() for all elements in m_svgUseElements and removing them all from the map. When the stack frame eventually comes back to the outer invocation of Document::resolveStyle, updateShadowTree gets invoked for the second time on SVG use elements whose shadow tree had already been updated within the inner invocation to updateShadowTree, and release-asserts. There is an alternative fix: avoid calling updateShadowTree on a svg element when shadowTreeNeedsUpdate returns true on the element in resolveStyle. However, removing the release assert is a sure way to fix the crash so this patch opts for that fix instead especially since we don't have any reproducible test case for this crash. This release assertion was added in r225868 as a cautious measure to catch any use-after-frees of SVGUseElement's since m_svgUseElements stored raw pointes to SVG use elements but this crash is not an indicative of any UAF, and there is no evidence that r225868 has led to new UAFs even after five months. No new tests. I couldn't find a way to trigger a nested style update inside SVGUseElement::updateShadowTree. * dom/Document.cpp: (WebCore::Document::removeSVGUseElement): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231267 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-01 Ryosuke Niwa REGRESSION(r225868): Release assert when removing an SVGUseElement from Document::m_svgUseElements https://bugs.webkit.org/show_bug.cgi?id=182188 Reviewed by Antti Koivisto. Fixed the crash by removing up the release assert. The crash is likely caused by re-entrancy to Document::resolveStyle during SVGUseElement::updateShadowTree. Because Document::resolveStyle invokes updateShadowTree on SVG use elements in Document::m_svgUseElements without clearing the map, the nested call to resolveStyle ends up calling updateShadowTree() for all elements in m_svgUseElements and removing them all from the map. When the stack frame eventually comes back to the outer invocation of Document::resolveStyle, updateShadowTree gets invoked for the second time on SVG use elements whose shadow tree had already been updated within the inner invocation to updateShadowTree, and release-asserts. There is an alternative fix: avoid calling updateShadowTree on a svg element when shadowTreeNeedsUpdate returns true on the element in resolveStyle. However, removing the release assert is a sure way to fix the crash so this patch opts for that fix instead especially since we don't have any reproducible test case for this crash. This release assertion was added in r225868 as a cautious measure to catch any use-after-frees of SVGUseElement's since m_svgUseElements stored raw pointes to SVG use elements but this crash is not an indicative of any UAF, and there is no evidence that r225868 has led to new UAFs even after five months. No new tests. I couldn't find a way to trigger a nested style update inside SVGUseElement::updateShadowTree. * dom/Document.cpp: (WebCore::Document::removeSVGUseElement): 2018-05-15 Kocsen Chung Cherry-pick r230983. rdar://problem/39988114 Release assert in ScriptController::canExecuteScripts via CachedSVGFont::ensureCustomFontData during Document::updateStyleIfNeeded https://bugs.webkit.org/show_bug.cgi?id=184950 Reviewed by Zalan Bujtas. Convert an existing ScriptDisallowedScope::EventAllowedScope which only disables the debug assertions by ScriptDisallowedScope::DisableAssertionsInScope which also disables the release assertion. Because SVG font is loaded in a document isolated from the rest of the page (m_externalSVGDocument), there is no security implication to execute scripts in this isolated document. Unfortunately, no new tests. I could never make CachedSVGFont::ensureCustomFontData to get called inside style resolution with m_externalSVGDocument set to nullptr after many attempts. Even EventAllowedScope I added 13 months ago in r211965, which this patch replaces by DisableAssertionsInScope, is not utilized by the existing layout tests since removing the assertion doesn't cause any layout test to hit an assertion. * dom/ScriptDisallowedScope.h: Updated the comment. * loader/cache/CachedSVGFont.cpp: (WebCore::CachedSVGFont::ensureCustomFontData): Replaced the asssertion. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230983 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-04-24 Ryosuke Niwa Release assert in ScriptController::canExecuteScripts via CachedSVGFont::ensureCustomFontData during Document::updateStyleIfNeeded https://bugs.webkit.org/show_bug.cgi?id=184950 Reviewed by Zalan Bujtas. Convert an existing ScriptDisallowedScope::EventAllowedScope which only disables the debug assertions by ScriptDisallowedScope::DisableAssertionsInScope which also disables the release assertion. Because SVG font is loaded in a document isolated from the rest of the page (m_externalSVGDocument), there is no security implication to execute scripts in this isolated document. Unfortunately, no new tests. I could never make CachedSVGFont::ensureCustomFontData to get called inside style resolution with m_externalSVGDocument set to nullptr after many attempts. Even EventAllowedScope I added 13 months ago in r211965, which this patch replaces by DisableAssertionsInScope, is not utilized by the existing layout tests since removing the assertion doesn't cause any layout test to hit an assertion. * dom/ScriptDisallowedScope.h: Updated the comment. * loader/cache/CachedSVGFont.cpp: (WebCore::CachedSVGFont::ensureCustomFontData): Replaced the asssertion. 2018-05-09 Jason Marcell Cherry-pick r231516. rdar://problem/40096750 Unreviewed build fix; add missing function definition. * html/HTMLMediaElement.h: (WebCore::HTMLMediaElement::didPassCORSAccessCheck const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231516 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-08 Jer Noble Unreviewed build fix; add missing function definition. * html/HTMLMediaElement.h: (WebCore::HTMLMediaElement::didPassCORSAccessCheck const): 2018-05-09 Jason Marcell Cherry-pick r231513. rdar://problem/40096750 Mute MediaElementSourceNode when tainted. https://bugs.webkit.org/show_bug.cgi?id=184866 Reviewed by Eric Carlson. Source/WebCore: Test: http/tests/security/webaudio-render-remote-audio-blocked-no-crossorigin.html * Modules/webaudio/AudioContext.cpp: (WebCore::AudioContext::wouldTaintOrigin const): * Modules/webaudio/AudioContext.h: * Modules/webaudio/MediaElementAudioSourceNode.cpp: (WebCore::MediaElementAudioSourceNode::setFormat): (WebCore::MediaElementAudioSourceNode::wouldTaintOrigin): (WebCore::MediaElementAudioSourceNode::process): * Modules/webaudio/MediaElementAudioSourceNode.h: LayoutTests: * http/tests/media/resources/1000Hz-sin.wav: Added. * http/tests/security/webaudio-render-remote-audio-allowed-crossorigin-expected.txt: Added. * http/tests/security/webaudio-render-remote-audio-allowed-crossorigin.html: Added. * http/tests/security/webaudio-render-remote-audio-blocked-no-crossorigin-expected.txt: Added. * http/tests/security/webaudio-render-remote-audio-blocked-no-crossorigin.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231513 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-08 Jer Noble Mute MediaElementSourceNode when tainted. https://bugs.webkit.org/show_bug.cgi?id=184866 Reviewed by Eric Carlson. Test: http/tests/security/webaudio-render-remote-audio-blocked-no-crossorigin.html * Modules/webaudio/AudioContext.cpp: (WebCore::AudioContext::wouldTaintOrigin const): * Modules/webaudio/AudioContext.h: * Modules/webaudio/MediaElementAudioSourceNode.cpp: (WebCore::MediaElementAudioSourceNode::setFormat): (WebCore::MediaElementAudioSourceNode::wouldTaintOrigin): (WebCore::MediaElementAudioSourceNode::process): * Modules/webaudio/MediaElementAudioSourceNode.h: 2018-05-08 Jason Marcell Cherry-pick r231441. rdar://problem/40050720 WebGL: Reset simulated values after validation fails https://bugs.webkit.org/show_bug.cgi?id=185363 Reviewed by Anders Carlsson. Source/WebCore: While fixing a previous bug, I forgot to reset some values when validation fails. This caused a bug where a subsequent invalid call might use those values and escape detection. Test: fast/canvas/webgl/index-validation-with-subsequent-draws.html * html/canvas/WebGLRenderingContextBase.cpp: (WebCore::WebGLRenderingContextBase::simulateVertexAttrib0): Reset the sizes when validation fails. * html/canvas/WebGLRenderingContextBase.h: LayoutTests: * fast/canvas/webgl/index-validation-with-subsequent-draws-expected.txt: Added. * fast/canvas/webgl/index-validation-with-subsequent-draws.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231441 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-06 Dean Jackson WebGL: Reset simulated values after validation fails https://bugs.webkit.org/show_bug.cgi?id=185363 Reviewed by Anders Carlsson. While fixing a previous bug, I forgot to reset some values when validation fails. This caused a bug where a subsequent invalid call might use those values and escape detection. Test: fast/canvas/webgl/index-validation-with-subsequent-draws.html * html/canvas/WebGLRenderingContextBase.cpp: (WebCore::WebGLRenderingContextBase::simulateVertexAttrib0): Reset the sizes when validation fails. * html/canvas/WebGLRenderingContextBase.h: 2018-05-08 Jason Marcell Cherry-pick r231236. rdar://problem/40050705 Source/WebCore: Prevent Debug ASSERT when changing forms https://bugs.webkit.org/show_bug.cgi?id=185173 Reviewed by Ryosuke Niwa. Form submission could trigger a debug assertion during validation when a form is changed during an input submission. Fix this by cleaning up the event handling logic and make it more consistent with modern WebKit coding style. Test: fast/forms/form-submission-crash-3.html * html/HTMLButtonElement.cpp: (WebCore::HTMLButtonElement::defaultEventHandler): Make sure layout runs before attempting to perform event handling. * html/HTMLFormElement.cpp: (WebCore::HTMLFormElement::reportValidity): Ditto. (WebCore::HTMLFormElement::validateInteractively): Remove call to perform layout here, since we expect this to happen earlier in the layout pass. Add an assertion that the tree is not dirty. * html/ImageInputType.cpp: (WebCore::ImageInputType::handleDOMActivateEvent): Make sure layout runs before attempting to perform event handling. * html/SubmitInputType.cpp: (WebCore::SubmitInputType::handleDOMActivateEvent): Ditto. LayoutTests: Prevent assertion when changing forms https://bugs.webkit.org/show_bug.cgi?id=185173 Reviewed by Ryosuke Niwa. * fast/forms/form-submission-crash-3-expected.txt: Added. * fast/forms/form-submission-crash-3.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231236 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-01 Brent Fulgham Prevent Debug ASSERT when changing forms https://bugs.webkit.org/show_bug.cgi?id=185173 Reviewed by Ryosuke Niwa. Form submission could trigger a debug assertion during validation when a form is changed during an input submission. Fix this by cleaning up the event handling logic and make it more consistent with modern WebKit coding style. Test: fast/forms/form-submission-crash-3.html * html/HTMLButtonElement.cpp: (WebCore::HTMLButtonElement::defaultEventHandler): Make sure layout runs before attempting to perform event handling. * html/HTMLFormElement.cpp: (WebCore::HTMLFormElement::reportValidity): Ditto. (WebCore::HTMLFormElement::validateInteractively): Remove call to perform layout here, since we expect this to happen earlier in the layout pass. Add an assertion that the tree is not dirty. * html/ImageInputType.cpp: (WebCore::ImageInputType::handleDOMActivateEvent): Make sure layout runs before attempting to perform event handling. * html/SubmitInputType.cpp: (WebCore::SubmitInputType::handleDOMActivateEvent): Ditto. 2018-05-08 Jason Marcell Cherry-pick r231335. rdar://problem/40050807 Widgets should hold a WeakPtr to their parents https://bugs.webkit.org/show_bug.cgi?id=185239 Reviewed by Zalan Bujtas. * platform/ScrollView.h: (WebCore::ScrollView::weakPtrFactory): Added. * platform/Widget.cpp: (WebCore::Widget::init): Don't perform an unnecessary assignment. (WebCore::Widget::setParent): Grab a WeakPtr to the parent ScrollView. * platform/Widget.h: (WebCore::Widget::parent const): Change type to a WeakPtr. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231335 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-02 Brent Fulgham Widgets should hold a WeakPtr to their parents https://bugs.webkit.org/show_bug.cgi?id=185239 Reviewed by Zalan Bujtas. * platform/ScrollView.h: (WebCore::ScrollView::weakPtrFactory): Added. * platform/Widget.cpp: (WebCore::Widget::init): Don't perform an unnecessary assignment. (WebCore::Widget::setParent): Grab a WeakPtr to the parent ScrollView. * platform/Widget.h: (WebCore::Widget::parent const): Change type to a WeakPtr. 2018-05-08 Jason Marcell Cherry-pick r231291. rdar://problem/40050729 Use RetainPtr for form input type https://bugs.webkit.org/show_bug.cgi?id=185210 Reviewed by Ryosuke Niwa. Source/WebCore: Refactor our HTMLInputElement class to store its InputType member as a RefPtr. Test: fast/forms/access-key-mutation-2.html. * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::HTMLInputElement): (WebCore::HTMLInputElement::didAddUserAgentShadowRoot): (WebCore::HTMLInputElement::accessKeyAction): (WebCore::HTMLInputElement::parseAttribute): (WebCore::HTMLInputElement::appendFormData): * html/HTMLInputElement.h: * html/InputType.cpp: (WebCore::createInputType): (WebCore::InputType::create): (WebCore::InputType::createText): * html/InputType.h: LayoutTests: * fast/forms/access-key-mutation-2-expected.txt: Added. * fast/forms/access-key-mutation-2.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231291 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-02 Brent Fulgham Use RetainPtr for form input type https://bugs.webkit.org/show_bug.cgi?id=185210 Reviewed by Ryosuke Niwa. Refactor our HTMLInputElement class to store its InputType member as a RefPtr. Test: fast/forms/access-key-mutation-2.html. * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::HTMLInputElement): (WebCore::HTMLInputElement::didAddUserAgentShadowRoot): (WebCore::HTMLInputElement::accessKeyAction): (WebCore::HTMLInputElement::parseAttribute): (WebCore::HTMLInputElement::appendFormData): * html/HTMLInputElement.h: * html/InputType.cpp: (WebCore::createInputType): (WebCore::InputType::create): (WebCore::InputType::createText): * html/InputType.h: 2018-05-08 Jason Marcell Cherry-pick r231187. rdar://problem/39987469 Improve the performance of FontCascadeDescription's effectiveFamilies https://bugs.webkit.org/show_bug.cgi?id=184720 PerformanceTests: Reviewed by Simon Fraser. This performance test calls SystemFontDatabase::systemFontCascadeList() around 2,000,000 times (before this patch is applied), which is roughly equivalent to the page we found the performance problem on. The calling pattern is roughly equivalent in this test. * Layout/system-ui.html: Added. Source/WebCore: Reviewed by Simon Fraser. The page that had the performance problem renders many different Chinese characters in system-ui with only a small number of individual fonts. It turns out we were calling into the system-ui machinery for each character in order to opportunistically start loading data URLs (see also: https://bugs.webkit.org/show_bug.cgi?id=175845). These data URLS will never represent the system font, so we don't need to invoke the system-ui machinery at all. This patch makes a 92x performance improvement on the associated performance test. This test is designed to test Chinese text rendered with system-ui. Performance test: Layout/system-ui.html * platform/graphics/FontCascadeFonts.cpp: (WebCore::opportunisticallyStartFontDataURLLoading): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231187 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-04-30 Myles C. Maxfield Improve the performance of FontCascadeDescription's effectiveFamilies https://bugs.webkit.org/show_bug.cgi?id=184720 Reviewed by Simon Fraser. The page that had the performance problem renders many different Chinese characters in system-ui with only a small number of individual fonts. It turns out we were calling into the system-ui machinery for each character in order to opportunistically start loading data URLs (see also: https://bugs.webkit.org/show_bug.cgi?id=175845). These data URLS will never represent the system font, so we don't need to invoke the system-ui machinery at all. This patch makes a 92x performance improvement on the associated performance test. This test is designed to test Chinese text rendered with system-ui. Performance test: Layout/system-ui.html * platform/graphics/FontCascadeFonts.cpp: (WebCore::opportunisticallyStartFontDataURLLoading): 2018-05-02 Jason Marcell Cherry-pick r231242. rdar://problem/39860939 [iOS] Provide audio route information when invoking AirPlay picker https://bugs.webkit.org/show_bug.cgi?id=185199 Reviewed by Jer Noble. Source/WebCore: No new tests, this requires a specific hardware setup. * dom/Document.cpp: (WebCore::Document::showPlaybackTargetPicker): Pass route sharing policy and routing context UID. * dom/Document.h: * html/MediaElementSession.cpp: (WebCore::MediaElementSession::showPlaybackTargetPicker): Ditto. * loader/EmptyClients.h: * page/ChromeClient.h: * page/Page.cpp: (WebCore::Page::showPlaybackTargetPicker): Ditto. * page/Page.h: * platform/audio/AudioSession.cpp: (WebCore::AudioSession::routeSharingPolicy const): Empty implementation for non-iOS ports. (WebCore::routingContextUID const): Ditto. * platform/audio/AudioSession.h: * platform/audio/ios/AudioSessionIOS.mm: (WebCore::AudioSession::routeSharingPolicy const): Return the route sharing policy. (WebCore::AudioSession::routingContextUID const): Return the route context UID. Source/WebCore/PAL: * pal/spi/mac/AVFoundationSPI.h: Add additional AVAudioSession SPI. Source/WebKit: * Scripts/webkit/messages.py: * UIProcess/PageClient.h: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::showPlaybackTargetPicker): Pass route sharing policy and routing context UID. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _showPlaybackTargetPicker:fromRect:routeSharingPolicy:routingContextUID:]): Take same. (-[WKContentView _showPlaybackTargetPicker:fromRect:]): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::showPlaybackTargetPicker): Pass route sharing policy and routing context UID. * UIProcess/ios/forms/WKAirPlayRoutePicker.h: * UIProcess/ios/forms/WKAirPlayRoutePicker.mm: (-[WKAirPlayRoutePicker showFromView:routeSharingPolicy:routingContextUID:]): Take same. (-[WKAirPlayRoutePicker showFromView:]): Deleted. * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm: (WebKit::WebChromeClient::showPlaybackTargetPicker): Source/WebKitLegacy/ios: * WebCoreSupport/WebChromeClientIOS.h: * WebCoreSupport/WebChromeClientIOS.mm: (WebChromeClientIOS::showPlaybackTargetPicker): Pass route sharing policy and routing context UID. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231242 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-05-02 Eric Carlson [iOS] Provide audio route information when invoking AirPlay picker https://bugs.webkit.org/show_bug.cgi?id=185199 Reviewed by Jer Noble. No new tests, this requires a specific hardware setup. * dom/Document.cpp: (WebCore::Document::showPlaybackTargetPicker): Pass route sharing policy and routing context UID. * dom/Document.h: * html/MediaElementSession.cpp: (WebCore::MediaElementSession::showPlaybackTargetPicker): Ditto. * loader/EmptyClients.h: * page/ChromeClient.h: * page/Page.cpp: (WebCore::Page::showPlaybackTargetPicker): Ditto. * page/Page.h: * platform/audio/AudioSession.cpp: (WebCore::AudioSession::routeSharingPolicy const): Empty implementation for non-iOS ports. (WebCore::routingContextUID const): Ditto. * platform/audio/AudioSession.h: * platform/audio/ios/AudioSessionIOS.mm: (WebCore::AudioSession::routeSharingPolicy const): Return the route sharing policy. (WebCore::AudioSession::routingContextUID const): Return the route context UID. 2018-04-30 Jason Marcell Apply patch. rdar://problem/39741039 2018-04-30 Brent Fulgham Don't Block First Party Cookies on Redirects https://bugs.webkit.org/show_bug.cgi?id=184948 Reviewed by Youenn Fablet. The Navigation scheduler looses the 'requester' value when performing a ScheduledRedirect. Test: http/tests/resourceLoadStatistics/do-not-block-top-level-navigation-redirect.html * loader/NavigationScheduler.cpp: 2018-04-26 Jason Marcell Cherry-pick r231002. rdar://problem/39762191 [iOS] Set route sharing policy when setting audio session category https://bugs.webkit.org/show_bug.cgi?id=184979 Reviewed by Jer Noble. * platform/audio/ios/AudioSessionIOS.mm: (WebCore::AudioSession::setCategory): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231002 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-04-25 Eric Carlson [iOS] Set route sharing policy when setting audio session category https://bugs.webkit.org/show_bug.cgi?id=184979 Reviewed by Jer Noble. * platform/audio/ios/AudioSessionIOS.mm: (WebCore::AudioSession::setCategory): 2018-04-17 Kocsen Chung Cherry-pick r230530. rdar://problem/39462749 Show punycode if URL contains Latin dum character https://bugs.webkit.org/show_bug.cgi?id=184477 Reviewed by David Kilzer. Source/WebCore: Revise our "lookalike character" logic to include the small Latin dum character. Test: fast/url/host.html * platform/mac/WebCoreNSURLExtras.mm: (WebCore::isLookalikeCharacter): LayoutTests: * fast/url/host-expected.txt: * fast/url/host.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230530 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-04-11 Brent Fulgham Show punycode if URL contains Latin dum character https://bugs.webkit.org/show_bug.cgi?id=184477 Reviewed by David Kilzer. Revise our "lookalike character" logic to include the small Latin dum character. Test: fast/url/host.html * platform/mac/WebCoreNSURLExtras.mm: (WebCore::isLookalikeCharacter): 2018-04-11 Kocsen Chung Cherry-pick r230513. rdar://problem/39337459 FrameSelection::appearanceUpdateTimerFired should be robust against layout passes underneath it https://bugs.webkit.org/show_bug.cgi?id=183395 Reviewed by Zalan Bujtas. Source/WebCore: In the case where a FrameSelection updates its appearance when m_appearanceUpdateTimer is fired, the FrameSelection's Frame is unprotected, and can be removed by arbitrary script. This patch applies a simple mitigation by wrapping the Frame in a Ref when firing the appearance update timer. Test: editing/selection/iframe-update-selection-appearance.html * editing/FrameSelection.cpp: (WebCore::FrameSelection::appearanceUpdateTimerFired): LayoutTests: Add a new layout test that passes if we didn't crash. * editing/selection/iframe-update-selection-appearance-expected.txt: Added. * editing/selection/iframe-update-selection-appearance.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230513 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-04-10 Wenson Hsieh FrameSelection::appearanceUpdateTimerFired should be robust against layout passes underneath it https://bugs.webkit.org/show_bug.cgi?id=183395 Reviewed by Zalan Bujtas. In the case where a FrameSelection updates its appearance when m_appearanceUpdateTimer is fired, the FrameSelection's Frame is unprotected, and can be removed by arbitrary script. This patch applies a simple mitigation by wrapping the Frame in a Ref when firing the appearance update timer. Test: editing/selection/iframe-update-selection-appearance.html * editing/FrameSelection.cpp: (WebCore::FrameSelection::appearanceUpdateTimerFired): 2018-04-10 Kocsen Chung Cherry-pick r230467. rdar://problem/39317878 Refactor Ignore HSTS code https://bugs.webkit.org/show_bug.cgi?id=184433 Reviewed by Darin Adler. This patch refactors our ignore HSTS code. The convenience functions are moved out of CFNetwork SPI in PAL, and into where they are used. It also switches from performSelector: calls to straight function calls, after checking that there is a responder. Source/WebCore: * platform/network/mac/WebCoreURLResponse.mm: (WebCore::schemeWasUpgradedDueToDynamicHSTS): Add convenience function here since it was moved out of CFNetworkSPI.h. Source/WebCore/PAL: * pal/spi/cf/CFNetworkSPI.h: (schemeWasUpgradedDueToDynamicHSTS): Deleted. (setIgnoreHSTS): Deleted. (ignoreHSTS): Deleted. Source/WebKit: * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (schemeWasUpgradedDueToDynamicHSTS): (setIgnoreHSTS): (ignoreHSTS): Add convenience functions here since they were moved out of CFNetworkSPI.h. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230467 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-04-09 John Wilander Refactor Ignore HSTS code https://bugs.webkit.org/show_bug.cgi?id=184433 Reviewed by Darin Adler. This patch refactors our ignore HSTS code. The convenience functions are moved out of CFNetwork SPI in PAL, and into where they are used. It also switches from performSelector: calls to straight function calls, after checking that there is a responder. * platform/network/mac/WebCoreURLResponse.mm: (WebCore::schemeWasUpgradedDueToDynamicHSTS): Add convenience function here since it was moved out of CFNetworkSPI.h. 2018-04-05 Jason Marcell Cherry-pick r228334. rdar://problem/38712636 2018-02-09 Brent Fulgham [macOS, iOS] Expose OS marketing version in UserAgent https://bugs.webkit.org/show_bug.cgi?id=182629 Reviewed by Daniel Bates. Revert back to dynamically reading the operating system marketing version rather than using a hard-coded version. * page/cocoa/UserAgent.mm: (WebCore::systemMarketingVersionForUserAgentString): 2018-04-05 Jason Marcell Apply patch. rdar://problem/39191858 fix-httponly-cookie 2018-04-04 Youenn Fablet iOS 11.4 Beta WKWebView does not send cookies with HttpOnly flag set, for cache manifest request and its resources Reviewed by Brady Eidson. Test: http/tests/appcache/document-cookie-http-only.php Before that patch, we were using cookie as visible by the DOM document for loading manifest and other cached resources. We now are back to the exact same behavior as preElk/Emet by fully respecting cookies for appcache: - HttpOnly headers are used for appcache loading - Cookie is retrieved for each appcache loading so that cookie scopes are respected. * loader/appcache/ApplicationCacheGroup.cpp: (WebCore::ApplicationCacheGroup::update): (WebCore::ApplicationCacheGroup::createResourceHandle): * loader/appcache/ApplicationCacheGroup.h: 2018-04-04 Ryan Haddad Cherry-pick r230016. rdar://problem/38154623 2018-03-27 Daniel Bates Attempt to fix media control layout tests after (https://bugs.webkit.org/show_bug.cgi?id=179983) Exempt elements in user agent shadow DOM from having to perform a potentially CORS- enabled fetch for a mask image to try to fix the following tests from timing out: media/modern-media-controls/media-controller/media-controller-inline-to-fullscreen-to-inline.html media/modern-media-controls/media-controller/media-controller-inline-to-fullscreen-to-pip-to-inline.html * style/StylePendingResources.cpp: (WebCore::Style::loadPendingImage): 2018-04-03 Jason Marcell Cherry-pick r230063. rdar://problem/39155049 The SVGAnimatedProperty wrappers have to be detached from the referenced values before the SVGAnimatedType is deleted https://bugs.webkit.org/show_bug.cgi?id=183972 Reviewed by Daniel Bates. If the SVGAnimatedType is a list type, e.g. SVGLengthListValues, the wrappers of the animated properties have to be detached from the items in the list before it's deleted. * svg/SVGAnimateElementBase.cpp: (WebCore::SVGAnimateElementBase::clearAnimatedType): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230063 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-03-28 Said Abou-Hallawa The SVGAnimatedProperty wrappers have to be detached from the referenced values before the SVGAnimatedType is deleted https://bugs.webkit.org/show_bug.cgi?id=183972 Reviewed by Daniel Bates. If the SVGAnimatedType is a list type, e.g. SVGLengthListValues, the wrappers of the animated properties have to be detached from the items in the list before it's deleted. * svg/SVGAnimateElementBase.cpp: (WebCore::SVGAnimateElementBase::clearAnimatedType): 2018-04-03 Jason Marcell Cherry-pick r230006. rdar://problem/38154623 CSS mask images should be retrieved using potentially CORS-enabled fetch https://bugs.webkit.org/show_bug.cgi?id=179983 Reviewed by Brent Fulgham. Source/WebCore: As per (Editor’s Draft, 23 December 2017) we should fetch CSS mask images using a potentially CORS-enabled fetch. Both cross-origin CSS shape-outside images and CSS mask images may be sensitive to timing attacks that can be used to reveal their pixel data when retrieved without regard to CORS. For the same reason that we fetch CSS shape-outside images using a potentially CORS-enabled fetch we should fetch CSS mask the same way. This also makes the behavior of WebKit more closely align with the behavior in the spec. Test: http/tests/security/css-mask-image.html * page/Settings.yaml: Add a setting for toggle "Anonymous" mode fetching of mask images (defaults: true). We need this setting to avoid breaking the developer convenience feature that some modern media controls layout tests employ to load assets from the filesystem as opposed to using the hardcoded data URLs baked into the WebKit binary. * style/StylePendingResources.cpp: Substitute LoadPolicy::NoCORS and LoadPolicy::Anonymous for LoadPolicy::Normal and LoadPolicy::ShapeOutside, respectively, to match the terminology used in the HTML, CSS Shapes Module Level 1, and CSS Masking Module Level 1 specs. (WebCore::Style::loadPendingImage): Ditto. (WebCore::Style::loadPendingResources): Use load policy LoadPolicy::Anonymous when fetching a mask image or shape-outside image. LayoutTests: Add a test to ensure we do not fetch a cross-origin CSS mask image that does not allow CORS access. * http/tests/security/css-mask-image-expected.html: Added. * http/tests/security/css-mask-image.html: Added. * http/tests/security/resources/black-square.png: Added. * http/tests/security/resources/fail-mask.png: Added. * media/modern-media-controls/resources/media-controls-loader.js: Disable "Anonymous" mode fetching of mask images to allow modern media controls to load mask assets from the filesystem. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230006 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-03-27 Daniel Bates CSS mask images should be retrieved using potentially CORS-enabled fetch https://bugs.webkit.org/show_bug.cgi?id=179983 Reviewed by Brent Fulgham. As per (Editor’s Draft, 23 December 2017) we should fetch CSS mask images using a potentially CORS-enabled fetch. Both cross-origin CSS shape-outside images and CSS mask images may be sensitive to timing attacks that can be used to reveal their pixel data when retrieved without regard to CORS. For the same reason that we fetch CSS shape-outside images using a potentially CORS-enabled fetch we should fetch CSS mask the same way. This also makes the behavior of WebKit more closely align with the behavior in the spec. Test: http/tests/security/css-mask-image.html * page/Settings.yaml: Add a setting for toggle "Anonymous" mode fetching of mask images (defaults: true). We need this setting to avoid breaking the developer convenience feature that some modern media controls layout tests employ to load assets from the filesystem as opposed to using the hardcoded data URLs baked into the WebKit binary. * style/StylePendingResources.cpp: Substitute LoadPolicy::NoCORS and LoadPolicy::Anonymous for LoadPolicy::Normal and LoadPolicy::ShapeOutside, respectively, to match the terminology used in the HTML, CSS Shapes Module Level 1, and CSS Masking Module Level 1 specs. (WebCore::Style::loadPendingImage): Ditto. (WebCore::Style::loadPendingResources): Use load policy LoadPolicy::Anonymous when fetching a mask image or shape-outside image. 2018-04-03 Jason Marcell Cherry-pick r230146. rdar://problem/39155245 Show punycode if URL contains hyphen character https://bugs.webkit.org/show_bug.cgi?id=184221 Reviewed by Darin Adler. Source/WebCore: Revise our "lookalike character" logic to include the hyphen, non-breaking hyphen, and minus sign. Test: fast/url/host.html * platform/mac/WebCoreNSURLExtras.mm: (WebCore::isLookalikeCharacter): LayoutTests: * fast/url/host-expected.txt: * fast/url/host.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230146 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-03-31 Brent Fulgham Show punycode if URL contains hyphen character https://bugs.webkit.org/show_bug.cgi?id=184221 Reviewed by Darin Adler. Revise our "lookalike character" logic to include the hyphen, non-breaking hyphen, and minus sign. Test: fast/url/host.html * platform/mac/WebCoreNSURLExtras.mm: (WebCore::isLookalikeCharacter): 2018-04-03 Jason Marcell Cherry-pick r230102. rdar://problem/38154594 A stack overflow in the parsing of a builtin (called by createExecutable) cause a crash instead of a catchable js exception https://bugs.webkit.org/show_bug.cgi?id=184074 Reviewed by Keith Miller. JSTests: * stress/stack-overflow-while-parsing-builtin.js: Added. (f): Source/JavaScriptCore: Fixing this requires getting the ParserError (with information about the failure) and an ExecState* (to throw an exception) in the same place. It is surprisingly painful, with quite a long call stack between the last function with an access to an ExecState* and the first function with the ParserError. Even worse, many of these functions are generated by macros, themselves generated by a maze of python scripts. As a result, this patch is grotesquely large, while all it does is adding enough plumbing to throw a proper exception in this specific case. There are now bare calls to '.value()' on several paths that may crash. It is not a problem in my opinion, since we previously crashed in every case regardless of the path that took us to createExecutable when encountering a stack overflow. If we ever find an example that can cause these calls to fail, it should be doable to throw a proper exception there too. Two other minor changes: - I removed BuiltinExecutableCreator.{cpp, h} as it was nearly empty, and only used in one place. That place now includes BuiltinExecutables.h directly instead. - I moved code from ParserError.h into a newly created ParserError.cpp, as I see no need to inline functions that are only used when encountering a parser error, and ParserError.h is now included in quite a few places. * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/builtins/builtins_generate_combined_header.py: (BuiltinsCombinedHeaderGenerator.generate_forward_declarations): (ParserError): (generate_section_for_object): Deleted. (generate_externs_for_object): Deleted. (generate_macros_for_object): Deleted. (generate_section_for_code_table_macro): Deleted. (generate_section_for_code_name_macro): Deleted. (generate_section_for_global_private_code_name_macro): Deleted. * Scripts/builtins/builtins_generate_separate_header.py: (generate_secondary_header_includes): * Scripts/builtins/builtins_templates.py: * Sources.txt: * builtins/BuiltinExecutableCreator.cpp: Removed. * builtins/BuiltinExecutableCreator.h: Removed. * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createDefaultConstructor): (JSC::BuiltinExecutables::createBuiltinExecutable): (JSC::createBuiltinExecutable): (JSC::BuiltinExecutables::createExecutableOrCrash): (JSC::BuiltinExecutables::createExecutable): * builtins/BuiltinExecutables.h: * bytecompiler/BytecodeGenerator.h: * parser/ParserError.cpp: Added. (JSC::ParserError::toErrorObject): (JSC::ParserError::throwStackOverflowOrOutOfMemory): (WTF::printInternal): * parser/ParserError.h: (JSC::ParserError::toErrorObject): Deleted. (WTF::printInternal): Deleted. * runtime/AsyncIteratorPrototype.cpp: (JSC::AsyncIteratorPrototype::finishCreation): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::addFunctionProperties): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSObject.cpp: (JSC::JSObject::getOwnStaticPropertySlot): (JSC::JSObject::reifyAllStaticProperties): * runtime/JSObject.h: (JSC::JSObject::getOwnNonIndexPropertySlot): (JSC::JSObject::getOwnPropertySlot): (JSC::JSObject::getPropertySlot): * runtime/JSObjectInlines.h: (JSC::JSObject::getNonIndexPropertySlot): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/Lookup.cpp: (JSC::reifyStaticAccessor): (JSC::setUpStaticFunctionSlot): * runtime/Lookup.h: (JSC::getStaticPropertySlotFromTable): (JSC::reifyStaticProperty): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): * tools/JSDollarVM.cpp: (JSC::functionCreateBuiltin): Source/WebCore: I had to slightly change the type of some bindings between JSC and WebCore. No functional change intended on the WebCore side. * bindings/js/JSReadableStreamPrivateConstructors.cpp: (WebCore::JSBuiltinReadableStreamDefaultReaderPrivateConstructor::initializeExecutable): (WebCore::JSBuiltinReadableStreamDefaultControllerPrivateConstructor::initializeExecutable): (WebCore::JSBuiltinReadableByteStreamControllerPrivateConstructor::initializeExecutable): (WebCore::JSBuiltinReadableStreamBYOBReaderPrivateConstructor::initializeExecutable): (WebCore::JSBuiltinReadableStreamBYOBRequestPrivateConstructor::initializeExecutable): * bindings/scripts/CodeGeneratorJS.pm: (GenerateConstructorHelperMethods): * bindings/scripts/test/JS/JSTestClassWithJSBuiltinConstructor.cpp: (WebCore::JSTestClassWithJSBuiltinConstructorConstructor::initializeExecutable): * bindings/scripts/test/JS/JSTestJSBuiltinConstructor.cpp: (WebCore::JSTestJSBuiltinConstructorConstructor::initializeExecutable): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230102 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-03-30 Robin Morisset A stack overflow in the parsing of a builtin (called by createExecutable) cause a crash instead of a catchable js exception https://bugs.webkit.org/show_bug.cgi?id=184074 Reviewed by Keith Miller. I had to slightly change the type of some bindings between JSC and WebCore. No functional change intended on the WebCore side. * bindings/js/JSReadableStreamPrivateConstructors.cpp: (WebCore::JSBuiltinReadableStreamDefaultReaderPrivateConstructor::initializeExecutable): (WebCore::JSBuiltinReadableStreamDefaultControllerPrivateConstructor::initializeExecutable): (WebCore::JSBuiltinReadableByteStreamControllerPrivateConstructor::initializeExecutable): (WebCore::JSBuiltinReadableStreamBYOBReaderPrivateConstructor::initializeExecutable): (WebCore::JSBuiltinReadableStreamBYOBRequestPrivateConstructor::initializeExecutable): * bindings/scripts/CodeGeneratorJS.pm: (GenerateConstructorHelperMethods): * bindings/scripts/test/JS/JSTestClassWithJSBuiltinConstructor.cpp: (WebCore::JSTestClassWithJSBuiltinConstructorConstructor::initializeExecutable): * bindings/scripts/test/JS/JSTestJSBuiltinConstructor.cpp: (WebCore::JSTestJSBuiltinConstructorConstructor::initializeExecutable): 2018-04-03 Jason Marcell Cherry-pick r230052. rdar://problem/39155251 WebSocket cookie incorrectly stored https://bugs.webkit.org/show_bug.cgi?id=184100 Reviewed by Brent Fulgham. Source/WebCore: A cookie received in a WebSocket response should be stored with respect to the origin of the WebSocket server in order for it to be sent in a subsequent request. Also removed a FIXME about implementing support for the long since deprecated Set-Cookie2 header. Test: http/tests/websocket/tests/hybi/websocket-cookie-overwrite-behavior.html * Modules/websockets/WebSocketChannel.cpp: (WebCore::WebSocketChannel::processBuffer): * Modules/websockets/WebSocketHandshake.h: LayoutTests: * http/tests/websocket/tests/hybi/cookie_wsh.py: Added. Downloaded from . (_add_set_cookie): (web_socket_do_extra_handshake): (web_socket_transfer_data): * http/tests/websocket/tests/hybi/websocket-cookie-overwrite-behavior-expected.txt: Added. * http/tests/websocket/tests/hybi/websocket-cookie-overwrite-behavior.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230052 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-03-28 Daniel Bates WebSocket cookie incorrectly stored https://bugs.webkit.org/show_bug.cgi?id=184100 Reviewed by Brent Fulgham. A cookie received in a WebSocket response should be stored with respect to the origin of the WebSocket server in order for it to be sent in a subsequent request. Also removed a FIXME about implementing support for the long since deprecated Set-Cookie2 header. Test: http/tests/websocket/tests/hybi/websocket-cookie-overwrite-behavior.html * Modules/websockets/WebSocketChannel.cpp: (WebCore::WebSocketChannel::processBuffer): * Modules/websockets/WebSocketHandshake.h: 2018-04-03 Jason Marcell Cherry-pick r229830. rdar://problem/39155360 Disconnect the SVGPathSegList items from their SVGPathElement before rebuilding a new list https://bugs.webkit.org/show_bug.cgi?id=183723 Patch by Said Abou-Hallawa on 2018-03-21 Reviewed by Daniel Bates. Source/WebCore: When setting the "d" attribute directly on a path, we rebuild the list of path segments held for creating the property tear off. The old path segments need to get disconnected from the path element. We already do that when a path segment is replaced or removed. Test: svg/dom/reuse-pathseg-after-changing-d.html * svg/SVGPathElement.cpp: (WebCore::SVGPathElement::svgAttributeChanged): * svg/SVGPathSegList.cpp: (WebCore::SVGPathSegList::clear): SVGPathSegListValues::clearContextAndRoles() will now be called from SVGPathSegListValues::clear() via SVGListProperty::clearValues(). (WebCore::SVGPathSegList::replaceItem): (WebCore::SVGPathSegList::removeItem): (WebCore::SVGPathSegList::clearContextAndRoles): Deleted. * svg/SVGPathSegList.h: SVGPathSegListValues::clearContextAndRoles() will now be called from SVGPathSegListValues::clear() via SVGListProperty::initializeValues(). * svg/SVGPathSegListValues.cpp: (WebCore::SVGPathSegListValues::clearItemContextAndRole): (WebCore::SVGPathSegListValues::clearContextAndRoles): * svg/SVGPathSegListValues.h: (WebCore::SVGPathSegListValues::operator=): (WebCore::SVGPathSegListValues::clear): LayoutTests: * svg/dom/reuse-pathseg-after-changing-d-expected.txt: Added. * svg/dom/reuse-pathseg-after-changing-d.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@229830 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-03-21 Said Abou-Hallawa Disconnect the SVGPathSegList items from their SVGPathElement before rebuilding a new list https://bugs.webkit.org/show_bug.cgi?id=183723 Reviewed by Daniel Bates. When setting the "d" attribute directly on a path, we rebuild the list of path segments held for creating the property tear off. The old path segments need to get disconnected from the path element. We already do that when a path segment is replaced or removed. Test: svg/dom/reuse-pathseg-after-changing-d.html * svg/SVGPathElement.cpp: (WebCore::SVGPathElement::svgAttributeChanged): * svg/SVGPathSegList.cpp: (WebCore::SVGPathSegList::clear): SVGPathSegListValues::clearContextAndRoles() will now be called from SVGPathSegListValues::clear() via SVGListProperty::clearValues(). (WebCore::SVGPathSegList::replaceItem): (WebCore::SVGPathSegList::removeItem): (WebCore::SVGPathSegList::clearContextAndRoles): Deleted. * svg/SVGPathSegList.h: SVGPathSegListValues::clearContextAndRoles() will now be called from SVGPathSegListValues::clear() via SVGListProperty::initializeValues(). * svg/SVGPathSegListValues.cpp: (WebCore::SVGPathSegListValues::clearItemContextAndRole): (WebCore::SVGPathSegListValues::clearContextAndRoles): * svg/SVGPathSegListValues.h: (WebCore::SVGPathSegListValues::operator=): (WebCore::SVGPathSegListValues::clear): 2018-03-21 Jason Marcell Cherry-pick r229297. rdar://problem/38682578 2018-03-05 Andy Estes [Mac] Teach WebCore::Pasteboard about file promise drags https://bugs.webkit.org/show_bug.cgi?id=183314 Reviewed by Darin Adler. While WebKit does support receiving file promise drags (since r210360), WebCore::Pasteboard has not been instructed on how to read their file paths. When the various pasteboard readers ask for file paths after a file promise drop, they receive an empty vector. This impacts various features, most notably the DataTransfer API. Pasteboard actually cannot learn about promised file paths from the pasteboard itself, as the pasteboard only contains the dragged files' UTIs. Promised file paths aren't known until the WebKits call -[NSFilePromiseReceiver receivePromisedFilesAtDestination:...], at which point the file paths are passed to WebCore as part of WebCore::DragData. When we construct new Pasteboards for drag and drop, we need to store any promised file paths from the DragData. Then, when the various pasteboard readers ask for file paths and NSFilesPromisePboardType is on the pasteboard, we can return these promised file paths. Tests: editing/pasteboard/data-transfer-items-drag-drop-file-promise.html editing/pasteboard/data-transfer-items-drop-file-promise.html editing/pasteboard/datatransfer-items-drop-plaintext-file-promise.html editing/pasteboard/datatransfer-types-dropping-text-file-promise.html editing/pasteboard/drag-file-promises-to-editable-element-as-URLs.html editing/pasteboard/drag-file-promises-to-editable-element-as-attachment.html editing/pasteboard/file-input-files-access-promise.html * platform/FileSystem.h: * platform/Pasteboard.h: (WebCore::Pasteboard::Pasteboard): * platform/mac/DragDataMac.mm: (WebCore::DragData::containsPromise const): * platform/mac/PasteboardMac.mm: (WebCore::Pasteboard::Pasteboard): (WebCore::Pasteboard::createForDragAndDrop): (WebCore::toString): (WebCore::Pasteboard::read): (WebCore::Pasteboard::readFilePaths): (WebCore::absoluteURLsFromPasteboardFilenames): Deleted. * platform/mac/PlatformPasteboardMac.mm: (WebCore::PlatformPasteboard::numberOfFiles const): 2018-03-21 Jason Marcell Cherry-pick r229585. rdar://problem/38681880 2018-03-13 Youenn Fablet Changing link element rel attribute from preload to stylesheet should succeed loading the stylesheet https://bugs.webkit.org/show_bug.cgi?id=183601 Reviewed by Antti Koivisto. Test: http/wpt/preload/change-link-rel-attribute.html * loader/LinkPreloadResourceClients.h: (WebCore::LinkPreloadResourceClient::clearResource): Remove the call to CachedResource::cancelLoad. This call is expected to be called by ResourceLoader when cancelling the load from below CachedResource. * loader/cache/CachedResource.cpp: (WebCore::CachedResource::allClientsRemoved): In case of preload, cancel the load if not finished when there is no more client attached to it. * loader/cache/CachedResource.h: 2018-03-20 Jason Marcell Apply patch. rdar://problem/38651613 2018-03-20 Youenn Fablet REGRESSION (iOS 11.3): WKWebView does not send cookies for cache manifest request. rdar://problem/38505756. Reviewed by Brady Eidson Covered by tests added in https://bugs.webkit.org/show_bug.cgi?id=183716 and https://bugs.webkit.org/show_bug.cgi?id=183757 Get the document cookie when trying to load the cache manifest. Use that cookie for the cache manifest and all cached resource. * loader/appcache/ApplicationCacheGroup.cpp: (WebCore::ApplicationCacheGroup::update): (WebCore::ApplicationCacheGroup::createResourceHandle): * loader/appcache/ApplicationCacheGroup.h: 2018-03-20 Jason Marcell Cherry-pick r229643. rdar://problem/38651639 2018-03-15 Keith Rollin Telemetry for stalled webpage loads https://bugs.webkit.org/show_bug.cgi?id=183221 Reviewed by Chris Dumez. Add telemetry for page loads, tracking the pages that succeed, fail, or are canceled. This information will be used to track the overall health of our page loading as time goes on. No new tests -- no new/changed user-level functionality. * page/DiagnosticLoggingKeys.cpp: (WebCore::DiagnosticLoggingKeys::telemetryPageLoadKey): (WebCore::DiagnosticLoggingKeys::timedOutKey): (WebCore::DiagnosticLoggingKeys::canceledLessThan2SecondsKey): (WebCore::DiagnosticLoggingKeys::canceledLessThan5SecondsKey): (WebCore::DiagnosticLoggingKeys::canceledLessThan20SecondsKey): (WebCore::DiagnosticLoggingKeys::canceledMoreThan20SecondsKey): (WebCore::DiagnosticLoggingKeys::failedLessThan2SecondsKey): (WebCore::DiagnosticLoggingKeys::failedLessThan5SecondsKey): (WebCore::DiagnosticLoggingKeys::failedLessThan20SecondsKey): (WebCore::DiagnosticLoggingKeys::failedMoreThan20SecondsKey): (WebCore::DiagnosticLoggingKeys::occurredKey): (WebCore::DiagnosticLoggingKeys::succeededLessThan2SecondsKey): (WebCore::DiagnosticLoggingKeys::succeededLessThan5SecondsKey): (WebCore::DiagnosticLoggingKeys::succeededLessThan20SecondsKey): (WebCore::DiagnosticLoggingKeys::succeededMoreThan20SecondsKey): * page/DiagnosticLoggingKeys.h: * platform/network/cf/ResourceError.h: (WebCore::ResourceError::ResourceError): * platform/network/mac/ResourceErrorMac.mm: (WebCore::ResourceError::ResourceError): (WebCore::ResourceError::getNSURLErrorDomain const): (WebCore::ResourceError::getCFErrorDomainCFNetwork const): (WebCore::ResourceError::mapPlatformError): 2018-03-20 Jason Marcell Cherry-pick r229614. rdar://problem/38651603 2018-03-14 Youenn Fablet MessagePort should remove its listeners when being closed https://bugs.webkit.org/show_bug.cgi?id=183644 Reviewed by Chris Dumez. Test: http/tests/workers/worker-messageport.html * dom/MessagePort.cpp: (WebCore::MessagePort::close): (WebCore::MessagePort::contextDestroyed): 2018-03-20 Jason Marcell Cherry-pick r229505. rdar://problem/38651624 2018-03-09 Zalan Bujtas Turn off offset*/scroll* optimization for input elements with shadow content https://bugs.webkit.org/show_bug.cgi?id=182383 Reviewed by Antti Koivisto. We normally ensure clean tree before calling offsetHeight/Width, scrollHeight/Width. In certain cases (see updateLayoutIfDimensionsOutOfDate() for details), it's okay to return the previously computed values even when some part of the tree is dirty. In case of shadow content, updateLayoutIfDimensionsOutOfDate() might return false (no need to layout) for the root, while true (needs layout) for the shadow content. This could confuse the caller (Element::scrollWidth/Height etc) and lead to incorrect result. Test: fast/forms/scrollheight-with-mutation-crash.html * dom/Document.cpp: (WebCore::Document::updateLayoutIfDimensionsOutOfDate): 2018-03-20 Jason Marcell Cherry-pick r229483. rdar://problem/38651620 2018-03-09 Youenn Fablet ServiceWorker should respect IDB and DOMCache partitioning https://bugs.webkit.org/show_bug.cgi?id=183496 Reviewed by Brady Eidson. Test: http/wpt/service-workers/third-party-registration.html Set the correct top origin of service worker ScriptExecutionContext. * workers/service/context/ServiceWorkerThread.cpp: (WebCore::ServiceWorkerThread::ServiceWorkerThread): 2018-03-11 Jason Marcell Cherry-pick r229086. rdar://problem/37992301 2018-02-27 Youenn Fablet Do not trigger a service worker match in case of document redirection if it will be already served by AppCache https://bugs.webkit.org/show_bug.cgi?id=183185 Reviewed by Chris Dumez. Disabling service worker matching in case there is a substitute data. Otherwise there is a risk for a double load, substitute data first and the new load triggered if matching a new registration. A future fix should first do service worker registration matching and if there is no registration query appcache. Test: http/tests/appcache/main-resource-redirect-with-sw.html * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::redirectReceived): 2018-03-11 Jason Marcell Cherry-pick r229028. rdar://problem/37992284 2018-02-26 Youenn Fablet MessagePort is not always destroyed in the right thread https://bugs.webkit.org/show_bug.cgi?id=183053 Reviewed by Chris Dumez. Make existingMessagePortForIdentifier take a lambda so that we hold the lock until there is no longer a need to keep the MessagePort around. This is very time sensitive and does not happen a lot when running WPT tests. Update existing call sites to pass a lambda. * dom/MessagePort.cpp: (WebCore::MessagePort::existingMessagePortForIdentifier): * dom/MessagePort.h: * dom/messageports/MessagePortChannelProviderImpl.cpp: (WebCore::MessagePortChannelProviderImpl::postMessageToRemote): (WebCore::MessagePortChannelProviderImpl::checkProcessLocalPortForActivity): 2018-03-11 Jason Marcell Cherry-pick r228279. rdar://problem/38154561 2018-02-08 Chris Fleizach AX: Defer attribute computation until needed. https://bugs.webkit.org/show_bug.cgi?id=182386 Reviewed by Zalan Bujtas. Accessibility is doing too much work when handling attribute changes. Here's how we can improve this: 1) Defer attribute changes while the tree is dirty (and coalesce them). 2) Don't create AXObjects when an attribute changes unnecessarily. If no client has requested an ax object, it's likely no work needs to be done (with the exception of a few attributes like aria-modal) 3) Stop calculating the entire accessible ARIA label when trying to decide if an element should be ignored. That's generally wasteful and the consequence of including more AX elements in the tree is very minimal. * accessibility/AXObjectCache.cpp: (WebCore::rendererNeedsDeferredUpdate): (WebCore::nodeAndRendererAreValid): (WebCore::AXObjectCache::remove): (WebCore::AXObjectCache::handleAriaExpandedChange): (WebCore::AXObjectCache::handleAriaRoleChanged): (WebCore::AXObjectCache::deferAttributeChangeIfNeeded): (WebCore::AXObjectCache::shouldProcessAttributeChange): (WebCore::AXObjectCache::handleAttributeChange): (WebCore::AXObjectCache::prepareForDocumentDestruction): (WebCore::AXObjectCache::performDeferredCacheUpdate): (WebCore::AXObjectCache::deferRecomputeIsIgnoredIfNeeded): (WebCore::AXObjectCache::deferRecomputeIsIgnored): (WebCore::AXObjectCache::deferTextChangedIfNeeded): (WebCore::AXObjectCache::deferSelectedChildrenChangedIfNeeded): (WebCore::AXObjectCache::handleAttributeChanged): Deleted. * accessibility/AXObjectCache.h: (WebCore::AXObjectCache::deferAttributeChangeIfNeeded): (WebCore::AXObjectCache::handleAttributeChanged): Deleted. * accessibility/AccessibilityNodeObject.cpp: (WebCore::AccessibilityNodeObject::hasAttributesRequiredForInclusion const): * accessibility/AccessibleNode.cpp: (WebCore::AccessibleNode::notifyAttributeChanged): * dom/Element.cpp: (WebCore::Element::attributeChanged): 2018-02-26 Jason Marcell Cherry-pick r229027. rdar://problem/37909130 2018-02-26 Commit Queue Unreviewed, rolling out r226745. https://bugs.webkit.org/show_bug.cgi?id=183132 This is breaking some websites (Requested by youenn on #webkit). Reverted changeset: "Use no-cache fetch mode when loading main documents with location.reload()" https://bugs.webkit.org/show_bug.cgi?id=181285 https://trac.webkit.org/changeset/226745 2018-02-26 Jason Marcell Cherry-pick r228978. rdar://problem/37909154 2018-02-25 Chris Dumez Service workers do not work well inside Web.app https://bugs.webkit.org/show_bug.cgi?id=183105 Reviewed by Youenn Fablet. SessionID::defaultSessionID() was hardcoded in the ServiceWorkerThread constructor instead of using the sessionID of the SWServer that created the service worker thread. As a result, when the Service Worker would establish a SWClientConnection to the server, it would use the wrong sessionID and would end up using a different SWServer (Since we have a different SWServer instance per sessionID). As a result, ServiceWorkerRegistration / ServiceWorker objects inside the service worker would not be kept in sync with the server (since they registered themselves with the wrong SWServer). Covered by new API test. * workers/service/ServiceWorkerContextData.cpp: (WebCore::ServiceWorkerContextData::isolatedCopy const): * workers/service/ServiceWorkerContextData.h: (WebCore::ServiceWorkerContextData::encode const): (WebCore::ServiceWorkerContextData::decode): * workers/service/context/ServiceWorkerThread.cpp: (WebCore::ServiceWorkerThread::ServiceWorkerThread): * workers/service/context/ServiceWorkerThreadProxy.cpp: (WebCore::createPageForServiceWorker): (WebCore::ServiceWorkerThreadProxy::ServiceWorkerThreadProxy): * workers/service/server/RegistrationDatabase.cpp: (WebCore::RegistrationDatabase::importRecords): * workers/service/server/RegistrationStore.h: (WebCore::RegistrationStore::server): * workers/service/server/SWServer.cpp: (WebCore::SWServer::updateWorker): * workers/service/server/SWServerWorker.cpp: (WebCore::SWServerWorker::contextData const): 2018-02-26 Jason Marcell Cherry-pick r228972. rdar://problem/37909121 2018-02-23 Chris Dumez Crash under SchemeRegistry::shouldTreatURLSchemeAsLocal(WTF::String const&) https://bugs.webkit.org/show_bug.cgi?id=183066 Reviewed by Ryosuke Niwa. SecurityOrigin objects are constructed on various threads. However, someone added a shouldTreatAsPotentiallyTrustworthy() call to the SecurityOrigin constructor which was not thread safe. This is because this function relies on SchemeRegistry::shouldTreatURLSchemeAsSecure() and SchemeRegistry::shouldTreatURLSchemeAsLocal() which were relying on global static HashMaps without locks. Update SecurityOrigin to initialize m_isPotentiallyTrustworthy lazily, to avoid paying initialization cost in the constructor. This is only queries by SecurityContext::isSecureContext(). Make SchemeRegistry::shouldTreatURLSchemeAsLocal() and SchemeRegistry::shouldTreatURLSchemeAsSecure() thread-safe, since they are needed to initialize SecurityOrigin::m_isPotentiallyTrustworthy from various threads. SchemeRegistry::shouldTreatURLSchemeAsSecure() is only called from SecurityOrigin (which requires thread-safety), and getUserMedia() which is not hot code so the extra locking there should not be an issue. SchemeRegistry::shouldTreatURLSchemeAsLocal() is called from SecurityOrigin (which requires thread- safety). It is also called from isQuickLookPreviewURL(), MHTMLArchive::create(), Page::userStyleSheetLocationChanged(), isRemoteWebArchive() and HTMLPlugInImageElement. All these are not hot code so I do not think we need a fast path. * page/SecurityOrigin.cpp: (WebCore::isLoopbackIPAddress): (WebCore::shouldTreatAsPotentiallyTrustworthy): (WebCore::SecurityOrigin::isPotentiallyTrustworthy const): (WebCore::SecurityOrigin::isLocalHostOrLoopbackIPAddress): * page/SecurityOrigin.h: * platform/SchemeRegistry.cpp: (WebCore::localURLSchemesLock): (WebCore::localURLSchemes): (WebCore::secureSchemesLock): (WebCore::secureSchemes): (WebCore::SchemeRegistry::registerURLSchemeAsLocal): (WebCore::SchemeRegistry::removeURLSchemeRegisteredAsLocal): (WebCore::SchemeRegistry::shouldTreatURLSchemeAsLocal): (WebCore::SchemeRegistry::registerURLSchemeAsSecure): (WebCore::SchemeRegistry::shouldTreatURLSchemeAsSecure): * platform/SchemeRegistry.h: 2018-02-23 Jason Marcell Apply patch. rdar://problem/37836719 2018-02-23 Chris Dumez Add release asserts for service worker fetch and postMessage events https://bugs.webkit.org/show_bug.cgi?id=183025 Reviewed by Chris Dumez. Moving from release assert to early exit with release logging. * workers/service/context/ServiceWorkerThread.cpp: (WebCore::ServiceWorkerThread::postMessageToServiceWorker): * workers/service/context/ServiceWorkerThreadProxy.h: 2018-02-23 Jason Marcell Cherry-pick r228919. rdar://problem/37836719 2018-02-22 Youenn Fablet Add release asserts for service worker fetch and postMessage events https://bugs.webkit.org/show_bug.cgi?id=183025 rdar://problem/37765052 Reviewed by Daniel Bates. Add release assertion so that a service worker will only dispatch a message event for clients and service workers with the same origin. No change of behavior. * platform/network/ResourceRequestBase.h: * workers/service/context/ServiceWorkerThread.cpp: (WebCore::ServiceWorkerThread::postMessageToServiceWorker): * workers/service/context/ServiceWorkerThreadProxy.h: 2018-02-23 Jason Marcell Cherry-pick r228947. rdar://problem/37833040 2018-02-22 Antoine Quint REGRESSION (r228445): A big pause button shows over YouTube videos if you tap "Tap To Unmute" on iOS https://bugs.webkit.org/show_bug.cgi?id=183074 Reviewed by Eric Carlson. Test: media/modern-media-controls/start-support/start-support-disable-controls-and-re-enable-post-play.html In the fix for webkit.org/b/182668, we made it so that when the "controls" attribute is absent from a media element we stop listening to the bulk of media events and prevent controls from updating any DOM properties so as to minimize the amount of CPU usage by the Web process. An unfortunate side effect was that, if the media controls were disabled at the time the video starts playing, the StartSupport class would thus not catch the "play" event and would not be able to set the "hasPlayed" property to "true" on the MediaController, which would then prevent the _shouldShowStartButton() from returning "false". As a result, if the "controls" attribute was turned back on after the media started playing, they would default to showing the start button, which would be then in the play state, ie. showing the pause icon. We now set the "hasPlayed" property in the "play" event handler on MediaController, which is always registered regardless of the "controls" attribute setting. We also ensure we invalidate the "showStartButton" property on the media controls when StartSupport is enabled, which is the case when the "controls" attribute is toggled back to "true" from a previous "false" value. * Modules/modern-media-controls/media/media-controller.js: (MediaController.prototype.handleEvent): * Modules/modern-media-controls/media/start-support.js: (StartSupport): (StartSupport.prototype.enable): (StartSupport.prototype.handleEvent): (StartSupport.prototype._updateShowsStartButton): 2018-02-23 Jason Marcell Cherry-pick r228934. rdar://problem/37816677 2018-02-22 Chris Dumez ResourceRequestBase::isolatedCopy() fails to isolate copy the cachePartition https://bugs.webkit.org/show_bug.cgi?id=183059 Reviewed by Youenn Fablet. Update ResourceRequestBase::setAsIsolatedCopy() to call isolatedCopy() on the cachePartition as well, given that it is a String and it would not be safe to send it to another thread otherwise. * platform/network/ResourceRequestBase.cpp: (WebCore::ResourceRequestBase::setAsIsolatedCopy): 2018-02-23 Jason Marcell Cherry-pick r228931. rdar://problem/37816658 2018-02-22 Chris Dumez ServiceWorkerContainer::startScriptFetchForJob() fails to isolate copy the registrationKey before passing it to the main thread https://bugs.webkit.org/show_bug.cgi?id=183050 Reviewed by Youenn Fablet. Create an isolated copy of the registrationKey before passing it to the main thread in ServiceWorkerContainer's startScriptFetchForJob() / jobFinishedLoadingScript() / jobFailedLoadingScript(). * workers/service/ServiceWorkerContainer.cpp: (WebCore::ServiceWorkerContainer::startScriptFetchForJob): (WebCore::ServiceWorkerContainer::jobFinishedLoadingScript): (WebCore::ServiceWorkerContainer::jobFailedLoadingScript): 2018-02-23 Jason Marcell Cherry-pick r228928. rdar://problem/37816673 2018-02-22 Chris Dumez ServiceWorkerContainer::scheduleJob() fails to isolate copy the jobData before passing it to the main thread https://bugs.webkit.org/show_bug.cgi?id=183046 Reviewed by Youenn Fablet. Make sure we isolate copy the jobData before passing it to the main thread in ServiceWorkerContainer::scheduleJob(). The jobData contains Strings / URLs so it is not safe to have non-isolated copies of it on various threads. * workers/service/ServiceWorkerContainer.cpp: (WebCore::ServiceWorkerContainer::scheduleJob): 2018-02-21 Jason Marcell Cherry-pick r228895. rdar://problem/37767705 2018-02-21 Youenn Fablet ServiceWorkerJob::m_lastResponse is unneeded https://bugs.webkit.org/show_bug.cgi?id=183013 Reviewed by Chris Dumez. Remove this field since not used anywhere. * workers/service/ServiceWorkerJob.cpp: (WebCore::ServiceWorkerJob::didReceiveResponse): * workers/service/ServiceWorkerJob.h: 2018-02-21 Jason Marcell Cherry-pick r228903. rdar://problem/37765339 2018-02-21 Chris Dumez Regression(r228708): Crash under WebCore::MediaResource::responseReceived(WebCore::CachedResource&, WebCore::ResourceResponse const&) https://bugs.webkit.org/show_bug.cgi?id=183018 Reviewed by Eric Carlson. The fix at r228708 was trying to address the fact that avplayer sometimes deallocates WebCoreNSURLSessionDataTask objects on a non-main thread, which was not safe because its _resource data member needs to be deallocated on the main thread. The issue is that r228708 caused _resource to outlive its WebCoreNSURLSessionDataTask. This is an issue because _resource has a client data member (of type WebCoreNSURLSessionDataTaskClient) which has a raw pointer to the WebCoreNSURLSessionDataTask. This means that the main thread could call methods like responseReceived() on the resource, which would call responseReceived() on the client, which would try to call [WebCoreNSURLSessionDataTask receivedResponse:] with an invalid m_task pointer. To address the issue, I introduced a clearTask() method on WebCoreNSURLSessionDataTaskClient, which gets called from a non-main thread to clear the client's m_task pointer when the task is destroyed on a non-main thread. So that this is safe, every time the client tries to use m_task, we now acquire a lock for thread-safety and do a null-check on m_task. No new tests, no known reproduction case. * platform/graphics/PlatformMediaResourceLoader.h: (WebCore::PlatformMediaResource::client): * platform/network/cocoa/WebCoreNSURLSession.mm: (WebCore::WebCoreNSURLSessionDataTaskClient::clearTask): (WebCore::WebCoreNSURLSessionDataTaskClient::dataSent): (WebCore::WebCoreNSURLSessionDataTaskClient::responseReceived): (WebCore::WebCoreNSURLSessionDataTaskClient::shouldCacheResponse): (WebCore::WebCoreNSURLSessionDataTaskClient::dataReceived): (WebCore::WebCoreNSURLSessionDataTaskClient::redirectReceived): (WebCore::WebCoreNSURLSessionDataTaskClient::accessControlCheckFailed): (WebCore::WebCoreNSURLSessionDataTaskClient::loadFailed): (WebCore::WebCoreNSURLSessionDataTaskClient::loadFinished): (-[WebCoreNSURLSessionDataTask dealloc]): 2018-02-21 Jason Marcell Cherry-pick r228851. rdar://problem/37734494 2018-02-20 Chris Dumez Crash under JSC::JSCell::toNumber(JSC::ExecState*) https://bugs.webkit.org/show_bug.cgi?id=182984 Reviewed by Mark Lam. The issue was caused by DOMMatrix attributes potentially returning "impure" NaN values. We would call JSC::jsNumber(double) to construct the JSValue but this is only safe for pure NaN values. Make sure we purify the double returned by the implementation for IDL attributes of type 'unrestricted double' before calling JSC::jsNumber(double). No new tests, extended existing test. * bindings/js/JSDOMConvertNumbers.h: (WebCore::JSConverter::convert): * testing/TypeConversions.h: (WebCore::TypeConversions::testImpureNaNUnrestrictedDouble const): (WebCore::TypeConversions::testImpureNaN2UnrestrictedDouble const): (WebCore::TypeConversions::testQuietNaNUnrestrictedDouble const): * testing/TypeConversions.idl: 2018-02-21 Jason Marcell Cherry-pick r228857. rdar://problem/37734496 2018-02-20 Nan Wang AX: Keyboard focus not following VoiceOver cursor into web content or within web content. https://bugs.webkit.org/show_bug.cgi?id=182752 Reviewed by Ryosuke Niwa. Call the assistive technology specific method for becoming first responder. Test: accessibility/mac/accessibility-make-first-responder.html * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper _accessibilitySetValue:forAttribute:]): * page/ChromeClient.h: 2018-02-20 Jason Marcell Cherry-pick r228714. rdar://problem/37714031 2018-02-19 Tim Horton REGRESSION (r219342): Touch event coordinates and elementFromPoint coordinates differ https://bugs.webkit.org/show_bug.cgi?id=182910 Reviewed by Simon Fraser. We reverted other changes to the definition of client coordinates in r219829 due to compatibility concerns. However, we failed to revert r219342 on trunk, leaving elementFromPoint() using coordinates relative to the layout viewport. Add a currently off-by-default setting to switch on layout-viewport-relative client coordinates and guard the elementFromPoint changes behind it. A future patch should roll r219829 back in also behind this setting, so that everything remains consistent regardless of which coordinate space we choose. * dom/TreeScope.cpp: (WebCore::absolutePointIfNotClipped): * page/Settings.yaml: * rendering/RenderLayer.cpp: (WebCore::RenderLayer::hitTest): 2018-02-20 Jason Marcell Cherry-pick r228601. rdar://problem/37697671 2018-02-20 Jason Marcell Cherry-pick r228825. rdar://problem/37714030 2018-02-20 Wenson Hsieh [iOS 11.3 Beta] Can't copy a URL from Safari and paste it into the Gmail app https://bugs.webkit.org/show_bug.cgi?id=182952 Reviewed by Tim Horton. After r220865 refactored the iOS copy codepaths to use NSItemProviders, we stopped writing the URL as plain text to the pasteboard. However, this means clients that only check for "text/plain" (or one of its aliases) on the pasteboard won't read any data on paste. To fix this, we restore the pre-iOS 11.3 behavior of writing both the URL and plain text to the pasteboard. Since we're using item providers, we also ensure that the NSURL is at a higher fidelity than the string to make it clear that the data should be consumed as a URL. This patch also rebaselines an existing drag and drop test to cover this change, and adds a new API test, ActionSheetTests.CopyLinkWritesURLAndPlainText, which simulates copying a link using the share sheet and pasting into a DataTransfer-dumping test harness. * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::write): 2018-02-20 Jason Marcell Cherry-pick r228824. rdar://problem/37714015 2018-02-20 Eric Carlson [iOS] Returning from Auto-PiP causes Safari to be unresponsive https://bugs.webkit.org/show_bug.cgi?id=182977 Reviewed by Jer Noble. Remove the error handling added in r228115, it breaks auto-pip. * platform/ios/VideoFullscreenInterfaceAVKit.mm: (VideoFullscreenInterfaceAVKit::applicationDidBecomeActive): (VideoFullscreenInterfaceAVKit::enterFullscreenStandard): (VideoFullscreenInterfaceAVKit::exitFullscreen): (VideoFullscreenInterfaceAVKit::cleanupFullscreen): (VideoFullscreenInterfaceAVKit::didStartPictureInPicture): (VideoFullscreenInterfaceAVKit::prepareForPictureInPictureStopWithCompletionHandler): (VideoFullscreenInterfaceAVKit::exitFullscreenHandler): (VideoFullscreenInterfaceAVKit::enterFullscreenHandler): 2018-02-20 Jason Marcell Cherry-pick r228716. rdar://problem/37714038 2018-02-19 Chris Dumez Crash under MIMETypeRegistry::isSupportedJavaScriptMIMEType() https://bugs.webkit.org/show_bug.cgi?id=182927 Reviewed by Antti Koivisto. Make it safe to call MIMETypeRegistry::isSupportedJavaScriptMIMEType() from the non-main thread. It is currently being called from a background thread in the following places: - ServiceWorkerJob::didReceiveResponse() - WorkerGlobalScope::importScripts() These call sites on non-main threads were added recently with the support for service workers. No new tests, already covered by existing tests that flakily experience service worker process crashes. * platform/MIMETypeRegistry.cpp: (WebCore::MIMETypeRegistry::isSupportedJavaScriptMIMEType): 2018-02-20 Jason Marcell Cherry-pick r228708. rdar://problem/37714034 2018-02-19 Chris Dumez CrashTracer: com.apple.WebKit.WebContent at WebCore: WebCore::TimerBase::~TimerBase https://bugs.webkit.org/show_bug.cgi?id=182931 Reviewed by Antti Koivisto. Make sure PlatformMediaResource is ThreadSafeRefCounted since it is being used from several threads in WebCoreNSURLSession. Also make sure it is always destroyed on the main thread since it ends up destroying a CachedRawResource object. No new tests, no known reproduction case. * platform/graphics/PlatformMediaResourceLoader.h: * platform/network/cocoa/WebCoreNSURLSession.mm: (-[WebCoreNSURLSessionDataTask dealloc]): 2018-02-20 Jason Marcell Cherry-pick r228594. rdar://problem/37697671 2018-02-16 Daniel Bates Remove UTF-32 BOM parsing code https://bugs.webkit.org/show_bug.cgi?id=182900 Reviewed by Alexey Proskuryakov. The UTF-32 encodings were removed from the text codec registry in r224747. So, we no longer need code to parse UTF-32{BE, LE} BOM or encode and decode these variants. * dom/TextDecoder.cpp: (WebCore::codeUnitByteSize): * loader/TextResourceDecoder.cpp: (WebCore::TextResourceDecoder::checkForBOM): (WebCore::TextResourceDecoder::checkForHeadCharset): * platform/text/TextEncoding.cpp: (WebCore::TextEncoding::isNonByteBasedEncoding const): (WebCore::UTF32BigEndianEncoding): Deleted. (WebCore::UTF32LittleEndianEncoding): Deleted. * platform/text/TextEncoding.h: 2018-02-20 Jason Marcell Cherry-pick r228586. rdar://problem/37697673 2018-02-16 Chris Dumez http/tests/security/http-0.9/xhr-blocked.html is flaky https://bugs.webkit.org/show_bug.cgi?id=182857 Reviewed by Antti Koivisto. WebCoreResourceHandleAsOperationQueueDelegate does not own the messageQueue and the detachHandle function was failing to nullout m_messageQueue when the resourceHandle gets destroyed. This means that callFunctionOnMainThread would sometimes try to append to a dead messageQueue. No new tests, already covered by: http/tests/security/http-0.9/xhr-blocked.html is flaky * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm: (-[WebCoreResourceHandleAsOperationQueueDelegate detachHandle]): 2018-02-20 Jason Marcell Cherry-pick r228585. rdar://problem/37697677 2018-02-16 Antti Koivisto Assert in mixed blend animation https://bugs.webkit.org/show_bug.cgi?id=182887 Reviewed by Zalan Bujtas. Test: fast/css/calc-mixed-blend-crash.html * platform/CalculationValue.cpp: (WebCore::CalcExpressionBlendLength::CalcExpressionBlendLength): Fix mismatch between the type test and the value used. 2018-02-20 Jason Marcell Cherry-pick r228574. rdar://problem/37697675 2018-02-16 Chris Dumez Crash under WebCore::EventTarget::fireEventListeners https://bugs.webkit.org/show_bug.cgi?id=182880 Reviewed by Youenn Fablet. Make sure the 'ended' event does not get dispatched on a AudioScheduledSourceNode after ActiveDOMObjects have been stopped. Test: webaudio/audiobuffersource-ended-detached-frame.html * Modules/webaudio/AudioScheduledSourceNode.cpp: (WebCore::AudioScheduledSourceNode::finish): 2018-02-19 Jason Marcell Apply patch. rdar://problem/37590759 Disable release assertions in updateStyleIfNeeded and updateLayout 2018-02-19 Ryosuke Niwa Disable release assertions in updateStyleIfNeeded and updateLayout https://bugs.webkit.org/show_bug.cgi?id=182854 Reviewed by Simon Fraser. No new tests. Replacing release assertions with debug assertions. * dom/Document.cpp: (WebCore::Document::updateStyleIfNeeded): (WebCore::Document::updateLayout): * page/LayoutContext.cpp: (WebCore::LayoutContext::layout): 2018-02-16 Jason Marcell Cherry-pick r228545. rdar://problem/37615437 2018-02-15 Chris Dumez Flaky Test: imported/w3c/web-platform-tests/fetch/api/redirect/redirect-to-dataurl-worker.html https://bugs.webkit.org/show_bug.cgi?id=182270 Reviewed by Antti Koivisto. No new tests, already covered by existing tests that crash flakily on the bots. * loader/ThreadableLoaderClientWrapper.h: (WebCore::ThreadableLoaderClientWrapper::ThreadableLoaderClientWrapper): isolate copy the initiator string as this object can be destroyed on a different thread. This was causing the test to flakily crash as well when destroying ThreadLocalData. * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.h: * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm: (scheduledWithCustomRunLoopMode): (-[WebCoreResourceHandleAsOperationQueueDelegate callFunctionOnMainThread:]): Fix thread safety issue in callFunctionOnMainThread. This function is called from a background thread to get to the main thread. However, it relied on m_handle which would get nullified on the main thread by detachHandle when the ResourceHandle is destroyed. Fix the issue by not relying on m_handle anymore. (-[WebCoreResourceHandleAsOperationQueueDelegate initWithHandle:messageQueue:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:willSendRequest:redirectResponse:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:canAuthenticateAgainstProtectionSpace:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveResponse:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:willCacheResponse:]): - Go back to using autorelease() instead of get() for the returned objects to match the code pre-r224522. - Dispatch the protectedSelf variables that were added in r227073 to the main thread to make sure we do not get destroyed on the background thread when protectedSelf is the last strong reference to self. Destroying the WebCoreResourceHandleAsOperationQueueDelegate on the background safe is unsafe due to its m_messageQueue data member which contains lambdas that may capture anything. - Add a Lock to protect against detachHandle getting called on the main thread and nulling out m_handle / m_requestResult / m_cachedResponseResult while the background thread may be accessing them. 2018-02-16 Jason Marcell Cherry-pick r228519. rdar://problem/37615441 2018-02-15 Antoine Quint [Modern Media Controls] REGRESSION: Inline media controls are not disabled while in fullscreen on iOS https://bugs.webkit.org/show_bug.cgi?id=182830 Reviewed by Eric Carlson. The test media/modern-media-controls/media-controller/ios/media-controller-stop-updates-in-fullscreen.html regressed when fixing webkit.org/b/182668 since we now started only caring about the presence of the "controls" attribute to identify that WebKit media controls should be available. We now have a dedicated _shouldControlsBeAvailable() method which more clearly establishes the conditions under which controls should be available and correctly disables them while in fullscreen on iOS, regardless of the "controls" attribute value. * Modules/modern-media-controls/media/media-controller.js: (MediaController.prototype._shouldControlsBeAvailable): (MediaController.prototype._updateControlsAvailability): 2018-02-15 Jason Marcell Cherry-pick r228482. rdar://problem/37559826 2018-02-12 Ryosuke Niwa REGRESSION (r223440): Copying & pasting a list from Microsoft Word to TinyMCE fails https://bugs.webkit.org/show_bug.cgi?id=182564 Reviewed by Wenson Hsieh. Unfortunately, r228352 was inadaquate to fix copying & pasting of a list item from Microsoft Word into TinyMCE in older verions of TinyMCE. This patch amends the approach taken by r228352 to make it work across the board as well as unbreak GMail. Turns out older versions of TinyMCE can't handle list items when computed styles are added as inline style declarations by WebKit. To make this work, avoid adding any computed styles as inline styles within mso-list conditionals as well as any p elements whose style attribute contains "mso-list" property. We would instead preserve these styles by keeping Microsoft Word's CSS style rules in addition to special @list rules. In addition, not keeping the style element of Microsoft Word in a head element as done in r228352 causes some versions of TinyMCE to treat it as regular text, and inserting a bunch of @list rules as user visible text. To work around this problem, we serialize the style rules as a comment () within a head element. Furthermore, when Microsoft Word is in the compatibility mode, it does not generate xmlns:o as the first xmlns declaration. Generalized the code to detect Microsoft Word's HTML declaration by looking for xmlns:o and xmlns:w xmls declarations. Finally, it turns out that Gmail has its own handling of list items copy & pasted from Microsoft Word, and also needs this quirks but in the pasted HTML, not the one exposed in getData. As such, this patch also enables the MSO list quirks in the pasted content as well as the one exposed in getData. Tests: PasteHTML.PreservesMSOList PasteHTML.PreservesMSOListInCompatibilityMode PasteHTML.StripsMSOListWhenMissingMSOHTMLElement PasteWebArchive.PreservesMSOList PasteWebArchive.PreservesMSOListInCompatibilityMode PasteWebArchive.StripsMSOListWhenMissingMSOHTMLElement * editing/HTMLInterchange.h: * editing/ReplaceSelectionCommand.cpp: (WebCore::removeHeadContents): Don't remove the special style element needed for the MSO list quirks since we don't keep the computed style as inline styles in this case. * editing/cocoa/WebContentReaderCocoa.mm: (WebCore::WebContentReader::readWebArchive): Enable the quirks in the pasted content as well as opposed to just in DataTransfer API exposed to the JavaScript. (WebCore::WebContentReader::readHTML): Ditto. * editing/markup.cpp: (WebCore::shouldPreserveMSOLists): Added. Generalized the logic to detect a Microsoft Word document. more xmlns declarations. (WebCore::StyledMarkupAccumulator::shouldPreserveMSOListStyleForElement): Added. (WebCore::StyledMarkupAccumulator::appendElement): Don't generate the second style element here for elements with most-list properties. Instead, avoid overriding inline styles with computed styles altogether. (WebCore::StyledMarkupAccumulator::appendNodeToPreserveMSOList): Include the style rules as well as list rules and wrap the "style" element in a "head" element to make it compatible with older versions of TinyMCE. 2018-02-15 Jason Marcell Cherry-pick r228352. rdar://problem/37559826 2018-02-08 Ryosuke Niwa REGRESSION (r223440): Copying & pasting a list from Microsoft Word to TinyMCE fails https://bugs.webkit.org/show_bug.cgi?id=182564 Reviewed by Wenson Hsieh. Turns out that Microsoft Word generates p and span elements with special styles instead of standard ul and ol elements when copying a list items, and TinyMCE has a specialized code path to process this proprietary format of Microsoft Word. The regression was caused by WebKit's sanitization code stripping away these non-standard CSS rules and inline styles. To preseve pre-r223440 behavior in TinyMCE, we preserve the following in a HTML markup: 1. The "html" element at the beginning with xmlns content attributes 2. @list rules in a style element starting with "/* List Definitions */" comment 3. inline style content attribute with "mso-list" property 4. comments conditional sections with "[if !supportLists]" and "[endif]" (1) is needed for TinyMCE to trigger the specialized code path for Microsoft Word. (2) contains the information about the structure of list items. (3) is needed to associate each p element with a rule in (2). (4) is needed to strip away the content generated as list markers (e.g. dots). We enable this "MSO list quirks" when the content comes from a non-WebKit client or a WebKit client that doesn't enable custom pasteboard data (detected by the content origin being null), and the HTML markup starts with a specific sequence of characters generated by Microsoft Word. Test: http/tests/security/clipboard/copy-paste-html-across-origin-strips-mso-list.html PasteHTML.PreservesMSOList PasteHTML.StripsMSOListWhenMissingMSOHTMLElement PasteWebArchive.PreservesMSOList PasteWebArchive.StripsMSOListWhenMissingMSOHTMLElement * editing/MarkupAccumulator.cpp: (WebCore::MarkupAccumulator::appendTextSubstring): Added. * editing/MarkupAccumulator.h: * editing/WebContentReader.cpp: (WebCore::FrameWebContentReader::msoListQuirksForMarkup const): Added. Enables the MSO list quirks if the content origin is null. The content origin specifies the pasteboard content's origin if it's copied in WebKit with custom pasteboard data types enabled. In all other applications, it would be set to null. * editing/WebContentReader.h: * editing/cocoa/WebContentReaderCocoa.mm: (WebCore::markupForFragmentInDocument): Moved to markup.cpp as sanitizedMarkupForFragmentInDocument. (WebCore::sanitizeMarkupWithArchive): (WebCore::WebContentReader::readWebArchive): Always disables MSO list quirks since this code path is only used by WebKit's native code to paste content. (WebCore::WebContentMarkupReader::readWebArchive): Calls msoListQuirksForMarkup since this is the code path used by DataTransfer. (WebCore::WebContentReader::readHTML): Always disables MSO list quirks since this code path is only used by WebKit's native code to paste content. (WebCore::WebContentMarkupReader::readHTML): Calls msoListQuirksForMarkup since this is the code path used by DataTransfer. * editing/markup.cpp: (WebCore::sanitizeMarkup): Use sanitizedMarkupForFragmentInDocument to share code. (WebCore::MSOListMode): Added. Set to Preserve if the sanitized markup is the one generated by Microsoft Word, and MSO list quirks should actually kick in. This is unlike MSOListQuirks, which is set to Enable whenever the content COULD be the one generated by Microsoft Word. (WebCore::StyledMarkupAccumulator): Added a special MSO list preservation mode enabled by MSOListMode. (WebCore::StyledMarkupAccumulator::StyledMarkupAccumulator): (WebCore::StyledMarkupAccumulator::appendElement): Preseve (3). Unfortunately, TinyMCE only recognizes mso-list and related properties only if they appear on their own. But we also need to preserve the inline style generated using the computed style since we would lose the inline styles of the text otherwise (e.g. red text and bold font). To workaround this, we generate two style content attributes, one containing computed styles and another one containing mso-list. Luckily, the HTML parsing algorithm dictates that the first attribute always wins when more than one attributes of the same name appears, so we place the computed style's style attribute first so that the pasted content in non-TinyMCE environment will continue to work. (WebCore::StyledMarkupAccumulator::traverseNodesForSerialization): (WebCore::StyledMarkupAccumulator::appendNodeToPreserveMSOList): Added. Generates special markup for the conditional statements and the special style element with @list rules. (WebCore::createMarkupInternal): (WebCore::createMarkup): (WebCore::sanitizedMarkupForFragmentInDocument): Moved from WebContentReaderCocoa.mm. If MSOListQuirks is set to Enable, and the markup starts with a specific sequence of characters, generate the markup with the newly added quirks code in StyledMarkupAccumulator, and wrap it in a special "html" element TinyMCE recognizes. * editing/markup.h: (WebCore::MSOListQuirks): Added. Set to CheckIfNeeded if the content COULD require MSO list quirks. 2018-02-14 Jason Marcell Cherry-pick r228476. rdar://problem/37549893 2018-02-14 Dean Jackson CrashTracer: com.apple.WebKit.WebContent at com.apple.WebCore: WebCore::HTMLPlugInImageElement::didAddUserAgentShadowRoot + 618 https://bugs.webkit.org/show_bug.cgi?id=182798 Reviewed by Eric Carlson. Speculative fix for a crash in HTMLPlugInImageElement::didAddUserAgentShadowRoot. The guess is that the m_swapRendererTimer is set, and the display state changes to something that does not require a shadow root, but before the timer fires. Fix this by ensuring that the timer is reset on every display state change. * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::setDisplayState): Guard for sets that wouldn't actually change value, and make sure we always reset the timer. 2018-02-14 Jason Marcell Cherry-pick r228471. rdar://problem/37559829 2018-02-14 Antoine Quint [Modern Media Controls] Don't use arrays as values for localisable strings https://bugs.webkit.org/show_bug.cgi?id=182791 Reviewed by Dean Jackson. Localization tools expect localizable strings to be specified as key-value pairs where both the key and the pair are plain strings. For the skip buttons, we used an array value to specify a replacement string. We now perform this task in code with a centralized SkipSeconds constant defining the skip amount. * English.lproj/modern-media-controls-localized-strings.js: * Modules/modern-media-controls/controls/icon-service.js: * Modules/modern-media-controls/main.js: (UIString): * Modules/modern-media-controls/media/skip-back-support.js: (SkipBackSupport.prototype.buttonWasPressed): * Modules/modern-media-controls/media/skip-forward-support.js: (SkipForwardSupport.prototype.buttonWasPressed): 2018-02-13 Jason Marcell Cherry-pick r228445. rdar://problem/37523940 2018-02-13 Antoine Quint Removing the controls attribute from a