https://bugs.webkit.org/show_bug.cgi?id=228936
rdar://80911502
Reviewed by Chris Dumez.
Need to notify accessibility clients that a WebProcess in the process
cache is suspended. Otherwise accessibility clients may continue making
requests to the cached Webprocess and be waiting indefinitely for a
suspended process.
Deleted WebProcess::accessibilityProcessSuspendedNotification and
instead use IPC::AccessibilityProcessSuspendedNotification
* Platform/IPC/Connection.h:
* Platform/IPC/cocoa/ConnectionCocoa.mm:
(IPC::AccessibilityProcessSuspendedNotification):
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::setIsInProcessCache):
(WebKit::WebProcess::prepareToSuspend):
(WebKit::WebProcess::processDidResume):
* WebProcess/WebProcess.h:
* WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::accessibilityProcessSuspendedNotification): Deleted.
Canonical link: https://commits.webkit.org/240405@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280865 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228662
<rdar://problem/81344181>
Reviewed by Dewei Zhu.
* Scripts/libraries/webkitcorepy/setup.py: Bump version.
* Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py: Bump version, export Terminal.
* Scripts/libraries/webkitcorepy/webkitcorepy/terminal.py: Added.
(Terminal):
(Terminal.assert_writeable_stream): Assert that the provided object is a writable stream.
(Terminal.supports_color): Check if the provided file supports colored output.
(Terminal.isatty): Check if a stream is an atty, both according to the stream itself and our override.
(Terminal.override_atty): Allow callers to override and declare explicitly if a stream is an atty.
(Terminal.Text): Group text colors and styles.
(Terminal.Style): Group functions modifying style of a stream.
(Terminal.Style.enabled): Check if styled printing is enabled on a stream.
(Terminal.Style.disable): Disable styled printing on a stream.
(Terminal.Style.enable): Enable styled printing on a stream.
(Terminal.Style.is_styled): Check if a stream is currently styled.
(Terminal.Style.__init__): Construct a text style.
(Terminal.Style.__repr__): Output the terminal characters styling a stream.
(Terminal.Style.set): Apply style to a stream.
(Terminal.Style.apply): Apply style to a stream, unapply when exiting context.
* Scripts/libraries/webkitscmpy/setup.py:
* Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py:
* Scripts/libraries/webkitscmpy/webkitscmpy/program/blame.py: Pass isatty to child process.
* Scripts/libraries/webkitscmpy/webkitscmpy/program/command.py:
(FilteredCommand.pager): Pass isatty to child process, ask 'more' to display colors.
(FilteredCommand.main): Color header and error.
* Scripts/libraries/webkitscmpy/webkitscmpy/program/log.py: Pass isatty to child process.
* Scripts/libraries/webkitscmpy/webkitscmpy/test/log_unittest.py: Override atty behavior.
Canonical link: https://commits.webkit.org/240404@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280864 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228242
Reviewed by Alex Christensen.
Source/WebCore:
The main resource and subresource load tracepoints aren't interpreted correctly if there are
multiple resource loads in flight at the same time. To fix this, we pass the pointer to the
FrameLoader or SubresourceLoader to ktrace so that the tracing tool can use that pointer to
properly nest overlapping resource loading trace intervals.
One additional change I made is to move the SubresourceLoadWillStart tracepoint to after the
call to willSendRequestInternal. The reason for this is because I wanted to log the resource
ID associated with the subresource request, but we only generate that ID after the call to
willSendRequestInternal.
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::provisionalLoadStarted):
(WebCore::FrameLoader::checkLoadCompleteForThisFrame):
* loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::willSendRequestInternal):
(WebCore::SubresourceLoader::didFinishLoading):
(WebCore::SubresourceLoader::didFail):
(WebCore::SubresourceLoader::didCancel):
Tools:
Use page and resource ids to properly handle nested main resource and subresource load
tracepoint intervals.
* Tracing/SystemTracePoints.plist:
Canonical link: https://commits.webkit.org/240400@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280859 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228931
Reviewed by Mark Lam.
Source/JavaScriptCore:
Right now current debugging code expects that the JS return PC on
the stack is already unsigned. This is not true on arm64e.
This patch now properly unsigns the return PC before passing it to
the ReturnAddressPC constructor.
* assembler/MacroAssemblerCodeRef.h:
(JSC::ReturnAddressPtr::fromTaggedPC):
* interpreter/AbstractPC.cpp:
(JSC::AbstractPC::AbstractPC):
* interpreter/AbstractPC.h:
(JSC::AbstractPC::AbstractPC):
(JSC::AbstractPC::jitReturnAddress const):
* interpreter/CallFrame.h:
(JSC::CallFrame::returnPC const):
Source/WTF:
Add a new helper to untag the return pc from a stack frame.
* wtf/PtrTag.h:
(WTF::untagReturnPC):
Canonical link: https://commits.webkit.org/240399@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280858 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228933
Reviewed by Alex Christensen.
LayoutTests/imported/w3c:
Rebaseline WPT tests now that more checks are passing.
* web-platform-tests/html/infrastructure/urls/terminology-0/document-base-url-expected.txt:
* web-platform-tests/html/semantics/document-metadata/the-base-element/base_about_blank-expected.txt:
* web-platform-tests/html/semantics/document-metadata/the-base-element/base_href_invalid-expected.txt:
* web-platform-tests/html/semantics/document-metadata/the-base-element/base_srcdoc-expected.txt:
Source/WebCore:
Document.baseURI is inaccurate for iframe srcdoc documents:
- https://html.spec.whatwg.org/#fallback-base-url
This aligns our behavior with both Chrome and Firefox.
No new tests, rebaselined existing tests.
* dom/Document.cpp:
(WebCore::Document::fallbackBaseURL const):
(WebCore::Document::updateBaseURL):
Extract "fallback base URL" logic out of updateBaseURL() and into its own function so that
it can be called from other places. Add logic to deal with iframe srcdoc documents to
our "fallback base URL" logic, as per:
- https://html.spec.whatwg.org/#fallback-base-url
(WebCore::Document::processBaseElement):
As per https://html.spec.whatwg.org/#set-the-frozen-base-url, we should use the document's fallback base URL
as base URL when parsing the base element's href attribute.
* dom/Document.h:
* html/HTMLBaseElement.cpp:
(WebCore::HTMLBaseElement::href const):
Per https://html.spec.whatwg.org/#dom-base-href, we should use the document's fallback base URL when
parsing the base element's href attribute. Also we should return the attribute value if the URL fails
parsing, not a null URL.
* xml/parser/XMLDocumentParserLibxml2.cpp:
(WebCore::openFunc):
Keep in sync with HTMLBaseElement::href(), as per comment.
Source/WebKitLegacy/mac:
* DOM/DOMHTMLBaseElement.mm:
(-[DOMHTMLBaseElement href]):
LayoutTests:
Update existing layout test to reflect behavior change.
* fast/dom/HTMLBaseElement/href-attribute-resolves-with-respect-to-document.html: Removed.
* http/tests/misc/href-attribute-resolves-with-respect-to-document-expected.txt: Renamed from LayoutTests/fast/dom/HTMLBaseElement/href-attribute-resolves-with-respect-to-document-expected.txt.
* http/tests/misc/href-attribute-resolves-with-respect-to-document.html: Added.
Canonical link: https://commits.webkit.org/240398@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280855 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228908
Patch by Kimmo Kinnunen <kkinnunen@apple.com> on 2021-08-10
Reviewed by Per Arne Vollan.
Source/JavaScriptCore:
* Scripts/generate-derived-sources.sh:
Quote the use of CC so that future copy-paste does not make the same mistake
as this bug.
Source/WebCore:
* Scripts/generate-derived-sources.sh:
Quote the use of CC so that future copy-paste does not make the same mistake
as this bug.
Source/WebKit:
Change variable references in the sh script to quoted "$VAR".
[ -z $VAR ] with VAR="a b" would mean
[ -z a b ].
-z is unary operator, so the expression b would be in position
where test would expect an operator.
The correct form is [ -z "a b" ].
In general, sh scripts usually refer to variables using quotes.
* Scripts/generate-derived-sources.sh:
Fix a bug where multiple space separated paths in
WEBKITADDITIONS_HEADER_SEARCH_PATHS would cause
test expression to receive arguments after the -z arg.
Quote the use of CC so future copy-paste does not make the same mistake
as this bug.
Tools:
* DumpRenderTree/Scripts/generate-derived-sources.sh:
* WebKitTestRunner/Scripts/generate-derived-sources.sh:
Quote the use of CC so that future copy-paste does not make the same mistake
as this bug.
Canonical link: https://commits.webkit.org/240397@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280854 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228929
rdar://81634182
Reviewed by Wenson Hsieh.
If we do not have an SYNotesActivationObserver then we do not need to make one to say that it is not visible
or that it's not occuding the screen. This is a performance optimization for all WebViews that are not
in Safari as well as all pages that do not have highlights to restore.
* UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::appHighlightsVisibility):
(WebKit::WebPageProxy::appHighlightsOverlayRect):
Canonical link: https://commits.webkit.org/240395@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280850 268f45cc-cd09-0410-ab3c-d52691b4dbfc
<https://webkit.org/b/228932>
Reviewed by Chris Dumez.
Covered by numerous layout tests running with TSan including:
crypto/crypto-random-values-types.html
* UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::setMediaAccessibilityPreferences):
- Make an isolatedCopy() of Vector<String> object before passing
it to the main thread.
Canonical link: https://commits.webkit.org/240392@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280841 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228939
<rdar://problem/80427578>
Reviewed by Eric Carlson.
Source/WebCore:
Test: VideoControlsManager.VideoControlsManagerDoesNotChangeValuesExposedToJavaScript
* platform/mac/PlaybackSessionInterfaceMac.mm:
(WebCore::PlaybackSessionInterfaceMac::rateChanged):
Make sure to change the `defaultPlaybackRate` before the `rate` as otherwise the former will
override changes made to the latter (see r278850 (and r277203) for details as to why).
* platform/mac/WebPlaybackControlsManager.h:
* platform/mac/WebPlaybackControlsManager.mm:
(-[WebPlaybackControlsManager setDefaultPlaybackRate:]):
(-[WebPlaybackControlsManager setDefaultPlaybackRate:fromJavaScript:]): Added.
(-[WebPlaybackControlsManager setRate:]):
(-[WebPlaybackControlsManager setRate:fromJavaScript:]): Added.
Add a way to distinguish whether the change to the `rate`/`defaultPlaybackRate` came from JS
or some native call (e.g. AVKit). If the former, don't propagate the change to the playback
model (which eventually is the `HTMLMediaElement` in the WebProcess) as that's where the
value came from in the first place. Note that we still want to propagate the `rate` to the
`defaultPlaybackRate` (and vice versa when `isPlaying`) in the UIProcess for the reasons
described in r278850 (and r277203), but we don't want to expose it to JS.
* platform/ios/PlaybackSessionInterfaceAVKit.mm:
(WebCore::PlaybackSessionInterfaceAVKit::rateChanged):
* platform/ios/WebAVPlayerController.h:
* platform/ios/WebAVPlayerController.mm:
(-[WebAVPlayerController setDefaultPlaybackRate:]):
(-[WebAVPlayerController setDefaultPlaybackRate:fromJavaScript:]): Added.
(-[WebAVPlayerController setRate:]):
(-[WebAVPlayerController setRate:fromJavaScript:]): Added.
Drive-by: r278850 was based r277203 (which added the above), so fix that code now too.
Tools:
* TestWebKitAPI/Tests/WebKitCocoa/VideoControlsManager.mm:
(TestWebKitAPI::TEST.VideoControlsManager.VideoControlsManagerDoesNotChangeValuesExposedToJavaScript): Added.
Canonical link: https://commits.webkit.org/240391@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280840 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228943
rdar://81700268
Reviewed by Mark Lam.
Source/WebCore:
In r280256, custom accessors start getting holder's JSGlobalObject (this is right behavior).
We also introduced IncumbentWindow IDL attribute to get the caller's JSGlobalObject, which is
necessary in Location. At that time, we replaced all ActiveWindow to IncumbentWindow, but it
changes the JSGlobalObject of `replace`, `assign`, and `reload` since they are functions (not
custom accessors). We observed that, after this change, facetime Web page is broken: when opening
the link to Facetime, it should show the prompt of "Open in Facetime app" in iOS. But after this
change, it won't happen.
We revert the semantic change by using ActiveWindow for replace, assign, and reload. This is
not the correct semantics from the spec, but this is the same to one before r280256, and we
will change this once we find the way to bypass this issue.
* page/Location.cpp:
(WebCore::Location::assign):
(WebCore::Location::replace):
(WebCore::Location::reload):
* page/Location.h:
* page/Location.idl:
LayoutTests:
* fast/frames/sandboxed-iframe-navigation-parent-expected.txt:
* fast/frames/sandboxed-iframe-navigation-parent.html:
* http/tests/security/frameNavigation/context-for-location-assign-expected.txt:
Canonical link: https://commits.webkit.org/240389@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280826 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=227944
Reviewed by Alexey Shvayka.
JSTests:
* test262/expectations.yaml:
Source/JavaScriptCore:
There are non-Latin1 white-spaces and line-terminators, but Lexer::scanRegExp's code did not assume that.
As a result, if there is a non-Latin1 white-spaces or line-terminators after RegExp, we raise SyntaxError
while this is valid. This patch fixes that.
* parser/Lexer.cpp:
(JSC::Lexer<T>::scanRegExp):
Canonical link: https://commits.webkit.org/240388@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280825 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228923
Reviewed by Geoff Garen.
Source/WebCore:
Blob URL changes after loading it. This is because we use URLWithBlobURLLifetimeExtension to
extend the lifetime of the Blob URL during the load and URLWithBlobURLLifetimeExtension ends
up creating a new public Blob URL. This is Web-observable so we need a way to extend the
lifetime of a Blob URL without actually generating a new Blob URL.
This patch replaces URLWithBlobURLLifetimeExtension with a new BlobURLHandle class which
extends the lifetime of a Blob URL as long as there are BlobURLHandle objects referring
to it. BlobURLHandle works with both private and public Blob URLs so it replaces
Blob::Handle as well (which I recently introduced via r280547). The Blob URL no longer
changes when we extend its lifetime. Instead, the Blob registry now keeps track of
references to a given Blob and only removes a Blob URL once there are no longer any
references to it.
Test: fast/files/blob-as-frame-url.html
* Headers.cmake:
* WebCore.xcodeproj/project.pbxproj:
* bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneSerializer::serialize):
(WebCore::CloneSerializer::CloneSerializer):
(WebCore::CloneSerializer::dumpIfTerminal):
(WebCore::SerializedScriptValue::SerializedScriptValue):
(WebCore::SerializedScriptValue::create):
* bindings/js/SerializedScriptValue.h:
(WebCore::SerializedScriptValue::blobHandles const):
(WebCore::SerializedScriptValue::SerializedScriptValue):
* fileapi/Blob.cpp:
(WebCore::Blob::Blob):
(WebCore::Blob::slice const):
(WebCore::Blob::size const):
(WebCore::Blob::handle const):
* fileapi/Blob.h:
(WebCore::Blob::url const):
* fileapi/BlobURL.cpp:
(WebCore::BlobURLHandle::BlobURLHandle):
(WebCore::BlobURLHandle::~BlobURLHandle):
(WebCore::BlobURLHandle::registerBlobURLHandleIfNecessary):
(WebCore::BlobURLHandle::unregisterBlobURLHandleIfNecessary):
(WebCore::BlobURLHandle::operator=):
(WebCore::BlobURLHandle::clear):
* fileapi/BlobURL.h:
(WebCore::BlobURLHandle::BlobURLHandle):
(WebCore::BlobURLHandle::url const):
* fileapi/ThreadableBlobRegistry.cpp:
(WebCore::ThreadableBlobRegistry::registerBlobURLHandle):
(WebCore::ThreadableBlobRegistry::unregisterBlobURLHandle):
* fileapi/ThreadableBlobRegistry.h:
* loader/PolicyChecker.cpp:
(WebCore::FrameLoader::PolicyChecker::extendBlobURLLifetimeIfNecessary const):
(WebCore::FrameLoader::PolicyChecker::checkNavigationPolicy):
(WebCore::FrameLoader::PolicyChecker::checkNewWindowPolicy):
* loader/PolicyChecker.h:
* platform/network/BlobRegistry.h:
* platform/network/BlobRegistryImpl.cpp:
(WebCore::BlobRegistryImpl::registerFileBlobURL):
(WebCore::BlobRegistryImpl::registerBlobURL):
(WebCore::BlobRegistryImpl::registerBlobURLOptionallyFileBacked):
(WebCore::BlobRegistryImpl::registerBlobURLForSlice):
(WebCore::BlobRegistryImpl::unregisterBlobURL):
(WebCore::BlobRegistryImpl::addBlobData):
(WebCore::BlobRegistryImpl::registerBlobURLHandle):
(WebCore::BlobRegistryImpl::unregisterBlobURLHandle):
* platform/network/BlobRegistryImpl.h:
* xml/XMLHttpRequest.cpp:
(WebCore::XMLHttpRequest::setResponseType):
(WebCore::XMLHttpRequest::open):
(WebCore::XMLHttpRequest::prepareToSend):
(WebCore::XMLHttpRequest::send):
(WebCore::XMLHttpRequest::createRequest):
(WebCore::XMLHttpRequest::clearRequest):
(WebCore::XMLHttpRequest::didFinishLoading):
* xml/XMLHttpRequest.h:
Source/WebKit:
* NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::registerBlobURLHandle):
(WebKit::NetworkConnectionToWebProcess::unregisterBlobURLHandle):
* NetworkProcess/NetworkConnectionToWebProcess.h:
* NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* NetworkProcess/NetworkProcessPlatformStrategies.cpp:
(WebKit::NetworkProcessPlatformStrategies::createBlobRegistry):
* WebProcess/FileAPI/BlobRegistryProxy.cpp:
(WebKit::BlobRegistryProxy::registerBlobURLHandle):
(WebKit::BlobRegistryProxy::unregisterBlobURLHandle):
* WebProcess/FileAPI/BlobRegistryProxy.h:
Source/WebKitLegacy/mac:
* WebCoreSupport/WebPlatformStrategies.mm:
Source/WebKitLegacy/win:
* WebCoreSupport/WebPlatformStrategies.cpp:
LayoutTests:
Add layout test coverage.
* fast/files/blob-as-frame-url-expected.txt: Added.
* fast/files/blob-as-frame-url.html: Added.
Canonical link: https://commits.webkit.org/240387@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280824 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228764
Reviewed by Simon Fraser.
Source/WebKit:
* Platform/Logging.h:
* Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:
(WebKit::setAppleLanguagesPreference):
* UIProcess/Launcher/mac/ProcessLauncherMac.mm:
(WebKit::ProcessLauncher::launchProcess):
* UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::setOverrideLanguages):
(WebKit::WebProcessPool::initializeNewWebProcess):
* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::getLaunchOptions):
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeWebProcess):
(WebKit::WebProcess::userPreferredLanguagesChanged const):
Source/WTF:
There have been a variety of bug reports over the past months/years about the procedure
by which we determine navigator.language. It's actually somewhat convoluted, so this
patch adds a (debug) log channel for it so we can follow what it's doing easily.
To enable all the logging, run these commands:
% defaults write com.apple.WebKit.WebContent.Development WTFLogging Language
% defaults write com.apple.WebKit.WebContent.Development WebKit2Logging Language
% defaults write com.apple.WebKit.WebContent WTFLogging Language
% defaults write com.apple.WebKit.WebContent WebKit2Logging Language
% defaults write -g WTFLogging Language
% defaults write -g WebKit2Logging Language
% defaults write /Users/$USER/Library/Containers/com.apple.Safari/Data/Library/Preferences/com.apple.Safari.plist WTFLogging Language
% defaults write /Users/$USER/Library/Containers/com.apple.Safari/Data/Library/Preferences/com.apple.Safari.plist WebKit2Logging Language
* wtf/Language.cpp:
(WTF::defaultLanguage):
(WTF::overrideUserPreferredLanguages):
(WTF::userPreferredLanguages):
* wtf/Logging.cpp:
* wtf/Logging.h:
* wtf/cf/LanguageCF.cpp:
(WTF::platformUserPreferredLanguages):
* wtf/cocoa/LanguageCocoa.mm:
(WTF::minimizedLanguagesFromLanguages):
Canonical link: https://commits.webkit.org/240381@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280811 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228890
Reviewed by Keith Miller.
This patch cleans up and does minor fix to the previous patch (https://bugs.webkit.org/show_bug.cgi?id=228047).
For the modifications in b3/B3Generate.cpp and b3/B3CanonicalizePrePostIncrements.cpp, we
need to convert post-index candidates to the canonical form. So, the address value needs to
be moved immediately before the load. This is subject to the dominance constraints that add
must be controlled equivalent to the load. So, similarly, if we need to move the offset to
just before the load, the dominance constraints must be satisfied. Since it is a constant
value, a better approach is to add a new constant value before the memory value. Then,
eliminate the dead code.
There is a bug in b3/B3CanonicalizePrePostIncrements.cpp. The insertionSet.execute(BasicBlock)
will reorder value indexes in the basic block. So, we should re-search for the value index in
the block every time after the execution.
In b3/B3LowerToAir.cpp, we need m_locked checks on address and base values. If they are already
locked, there is no need to convert the Load instruction to the pre/post-increment form.
* b3/B3CanonicalizePrePostIncrements.cpp:
(JSC::B3::canonicalizePrePostIncrements):
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3LowerToAir.cpp:
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isValidIncrementIndexForm):
(JSC::B3::Air::Arg::isValidForm const):
(JSC::B3::Air::Arg::isValidPreIndexForm): Deleted.
(JSC::B3::Air::Arg::isValidPostIndexForm): Deleted.
* b3/air/opcode_generator.rb:
Canonical link: https://commits.webkit.org/240378@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280808 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228891
<rdar://81640239>
Reviewed by Antti Koivisto.
Source/WebCore:
If a page has a horizontal scrolling carousel with a non-passive wheel event handler, and a
user with a clicky scroll wheel mouse tries to vertically scroll over that carousel, then
we'd fail to propagate the scroll to the page. This affects apple.com/store.
This happened because we don't do latching for legacy mouse wheel events, so we hit the code
in EventHandler::handleWheelEventInAppropriateEnclosingBox(); this finds the carousel and
calls handleWheelEventInScrollableArea(), but that dispatches to the scrolling thread in way
that does not propagate the event to the nearest ancestor that can handle it.
The fix is to check that the ScrollableArea can handle the event, sharing some code that
already exists and was used by findEnclosingScrollableContainer(). This is a conservative
fix; it's possible that scrollableAreaCanHandleEvent() could be called down in
handleWheelEventInScrollableArea() but that will affect other call sites.
Test: fast/scrolling/mac/vertical-scroll-in-horizontal-scroller.html
* page/EventHandler.cpp:
(WebCore::EventHandler::handleWheelEventInAppropriateEnclosingBox):
(WebCore::EventHandler::scrollableAreaCanHandleEvent):
* page/EventHandler.h:
* page/mac/EventHandlerMac.mm:
(WebCore::findEnclosingScrollableContainer):
LayoutTests:
* fast/scrolling/mac/vertical-scroll-in-horizontal-scroller-expected.txt: Added.
* fast/scrolling/mac/vertical-scroll-in-horizontal-scroller.html: Added.
* tiled-drawing/scrolling/overflow-scroll-reduced-content.html: Convert this test to use
async scrolling. webkit.org/b/228898 tracks an existing problem that caused the test
to fail with non-async scrolling.
Canonical link: https://commits.webkit.org/240377@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280807 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228916
Reviewed by Tim Horton.
Enable tests in editing/selection/ios in OpenSource EWS. This greatly improves pre-commit test coverage of
various WebKit2 editing behaviors that are currently only covered by Apple-internal post-commit testers.
* fast/events/touch/ios/become-key-window-when-focusing-editable-area-expected.txt: Renamed from LayoutTests/editing/selection/ios/become-key-window-when-focusing-editable-area-expected.txt.
* fast/events/touch/ios/become-key-window-when-focusing-editable-area.html: Renamed from LayoutTests/editing/selection/ios/become-key-window-when-focusing-editable-area.html.
* fast/events/touch/ios/selection-handles-after-touch-end-expected.txt: Renamed from LayoutTests/editing/selection/ios/selection-handles-after-touch-end-expected.txt.
* fast/events/touch/ios/selection-handles-after-touch-end.html: Renamed from LayoutTests/editing/selection/ios/selection-handles-after-touch-end.html.
Move a couple of tests that rely on touch events out of this directory, and into `fast/events/touch/ios`
instead.
* platform/ios-wk2/TestExpectations:
* platform/ios/TestExpectations:
Canonical link: https://commits.webkit.org/240372@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280794 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228879
<rdar://problem/80655397>
Reviewed by Brent Fulgham.
Source/WebCore:
Warn about risks of using AES-CBC and AES-CTR modes in WebCrypto,
based on recommendations in
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/encrypt.
We should encourage authenticated encryption instead.
* crypto/SubtleCrypto.cpp:
(WebCore::SubtleCrypto::encrypt):
(WebCore::SubtleCrypto::decrypt):
LayoutTests:
Update layout tests.
* crypto/subtle/aes-cbc-cfb-decrypt-malformed-parameters-expected.txt:
* crypto/subtle/aes-cbc-cfb-encrypt-malformed-parameters-expected.txt:
* crypto/subtle/aes-cbc-generate-key-encrypt-decrypt-expected.txt:
* crypto/subtle/aes-cbc-import-key-decrypt-expected.txt:
* crypto/subtle/aes-cbc-import-key-encrypt-expected.txt:
* crypto/subtle/aes-ctr-encrypt-malformed-parameters-expected.txt:
* crypto/subtle/aes-ctr-generate-key-encrypt-decrypt-expected.txt:
* crypto/subtle/aes-ctr-import-key-decrypt-expected.txt:
* crypto/subtle/aes-ctr-import-key-encrypt-expected.txt:
* crypto/subtle/decrypt-malformed-parameters-expected.txt:
* crypto/subtle/encrypt-malformed-parameters-expected.txt:
* TestExpectations:
We should probably not change imported test expectations, this marks
those tests as having console logging go to stderr. Additionally, some
tests call encrypt/decrypt functions up to 1000 times to test for
crashing, we should probably not log console to stdout in that case.
Canonical link: https://commits.webkit.org/240369@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280790 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228812
<rdar://80967782>
Reviewed by Per Arne Vollan.
Source/WebCore:
No need to pass kCGImageSourceEnableRestrictedDecoding to ImageIO anymore.
* platform/graphics/cg/ImageDecoderCG.cpp:
(WebCore::createImageSourceOptions):
Source/WebCore/PAL:
Delete unneeded SPIs and their soft-linking.
* PAL.xcodeproj/project.pbxproj:
* pal/cf/VideoToolboxSoftLink.cpp:
* pal/cf/VideoToolboxSoftLink.h:
* pal/cocoa/MediaToolboxSoftLink.cpp:
* pal/cocoa/MediaToolboxSoftLink.h:
* pal/spi/cg/ImageIOSPI.h:
* pal/spi/cocoa/VideoToolboxSPI.h: Removed.
Source/WebKit:
If the running application is Mail, add a sandbox extension to allow HEIF
image decoding. There is no plan right now to enable HEIF in WebKit. So
do not try to support decoding it outside Mail.
* Shared/WebProcessCreationParameters.cpp:
(WebKit::WebProcessCreationParameters::encode const):
(WebKit::WebProcessCreationParameters::decode):
* Shared/WebProcessCreationParameters.h:
* UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::platformInitializeWebProcess):
* WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::platformInitializeWebProcess):
(WebKit::WebProcess::initializeSandbox):
(WebKit::restrictImageAndVideoDecoders): Deleted.
LayoutTests:
Delete the only HEIF ref test since the HEIF format has not been enabled
in WebKit and it requires a sandbox extension to be decoded correctly on
recent macOS versions.
* TestExpectations:
* fast/images/heic-as-background-image-expected.html: Removed.
* fast/images/heic-as-background-image.html: Removed.
* fast/images/resources/green-400x400.heic: Removed.
* platform/ios/TestExpectations:
* platform/mac/TestExpectations:
Canonical link: https://commits.webkit.org/240368@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280789 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228904
rdar://79198313
Reviewed by Anders Carlsson.
We can't use the ANGLE Metal backend for WebGL 2 on A8 devices (e.g. iPad Mini 4
and iPad Air 2). In this case revert back to the OpenGL backend.
It would be better if this check was exposed as API from ANGLE, but
its only a small number of devices, and this code can be removed once
they are no longer supported.
* platform/graphics/cocoa/GraphicsContextGLOpenGLCocoa.mm:
(WebCore::platformSupportsMetal): Add a parameter to indicate WebGL 2, and
check the Metal device family support.
(WebCore::GraphicsContextGLOpenGL::GraphicsContextGLOpenGL):
Canonical link: https://commits.webkit.org/240365@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280782 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=226557
<rdar://problem/79103658>
Patch by Michael Catanzaro <mcatanzaro@gnome.org> on 2021-08-09
Reviewed by Adrian Perez de Castro.
Suppressing the -Warray-bounds warning introduces the -Wstringop-truncation warning, which
cannot be suppressed with pragmas. The only solution I found is -Wno-stringop-truncation. I
could apply it globally, but this warning does not have many false positives, so I think
it's better to suppress the warning only for WebSocket.cpp. Unfortunately we have to remove
it from the unified build in order to add custom flags, but it seems worth it to avoid
suppressing the warning globally.
* CMakeLists.txt:
Canonical link: https://commits.webkit.org/240362@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228873
<rdar://81271107>
Reviewed by Eric Carlson.
Source/WebCore:
Coalesce calls to renderingModeChanged() by setting a flag to call renderingModeChanged() in
the next run loop, and call into this coalescing method, setNeedsRenderingModeChanged(),
whenever the MediaPlayerPrivateAVFoundation subclasses create or destroy a video layer
or software painting context. This ensures that the MediaPlayerClient is always notified
when the rendering mode changes, regardless of why that change occurred.
Drive-by fix: replace the call in createVideoLayer() to "callOnMainThread()"
with "ensureOnMainThread()". The call to "callOnMainThread()" was added to avoid a
deadlock in WebKitLegacy, and "ensureOnMainThread()" has the correct behavior there, but
will be synchronous in WebKit.
* platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
(WebCore::MediaPlayerPrivateAVFoundation::setUpVideoRendering):
(WebCore::MediaPlayerPrivateAVFoundation::setNeedsRenderingModeChanged):
(WebCore::MediaPlayerPrivateAVFoundation::renderingModeChanged):
(WebCore::MediaPlayerPrivateAVFoundation::prepareForRendering):
* platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h:
* platform/graphics/avfoundation/cf/MediaPlayerPrivateAVFoundationCF.cpp:
(WebCore::MediaPlayerPrivateAVFoundationCF::destroyVideoLayer):
(WebCore::AVFWrapper::createAVCFVideoLayer):
(WebCore::AVFWrapper::createImageGenerator):
(WebCore::AVFWrapper::destroyImageGenerator):
* platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::createVideoLayer):
(WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerLayer):
(WebCore::MediaPlayerPrivateAVFoundationObjC::destroyVideoLayer):
(WebCore::MediaPlayerPrivateAVFoundationObjC::createVideoOutput):
(WebCore::MediaPlayerPrivateAVFoundationObjC::destroyVideoOutput):
Source/WebKit:
Currently, the RemoteMediaPlayerProxy will insert its MediaPlayer's platformLayer() into the
remotely hosted context when it receives a "firstVideoFrameAvailable()" notification.
However this is problematic for two reasons: AVPlayerLayer may not become "ready for
playback" when it is not in an active CALayer heirarchy, and for
MediaPlayerPrivateAVFoundation, firstVideoFrameAvailable() is only fired during
updateStates(), which is not guaranteed to occur unless another state change occurs.
Instead, reparent the MediaPlayer's platformLayer() when we receive a
mediaPlayerRenderingModeChanged() notification, which notifies the client whenever a
platformLayer() is created or destroyed.
* GPUProcess/media/RemoteMediaPlayerProxy.cpp:
* GPUProcess/media/cocoa/RemoteMediaPlayerProxyCocoa.mm:
(WebKit::RemoteMediaPlayerProxy::mediaPlayerFirstVideoFrameAvailable):
(WebKit::RemoteMediaPlayerProxy::mediaPlayerRenderingModeChanged):
Canonical link: https://commits.webkit.org/240360@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280776 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228825
Reviewed by Xabier Rodriguez-Calvar.
A mistake introduced with the WebKitMediaSrc v2 patch made the call to
updateTracks() in MediaPlayerPrivateGStreamer asynchronous.
This introduced a subtle race condition in which the "resize" event
may be handled before updateTracks() is called, therefore m_hasVideo
has not yet been set to true, and querying the video size from the
"resize" event handler returns 0x0.
This fixes a timeout flake in media/media-source/media-source-resize.html.
* platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::handleStreamCollectionMessage):
Canonical link: https://commits.webkit.org/240359@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280775 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228858
Reviewed by Yusuke Suzuki.
We have a memory optimization where the HTML parser will atomize any
text node string that is all whitespace. This can be expensive,
as we need to loop over the string's characters three times: to detect
that it is indeed all whitespace, to hash the string, and to compare
to any existing entry in the atom hash table.
Many whitespace strings encountered during parsing have a limited
form -- they have a few runs of consecutive equal whitespace
characters, e.g. it's common to see a newline followed by a number
of space characters. We can take advantage of this by compressing
the whitespace string into a simple run-length encoded form while
we loop over the characters to check that the string is all
whitespace. Unlike a hash, this encoded form perfectly identifies the
string content.
We add a WhitespaceCache that is owned by the Document, which stores
the most recently atomized all-whitespace string encountered by the
parser for a given length, and keys it with the encoded form. The
parser can then look up the WhitespaceCache and find an AtomString
without the need to perform a lookup in the atom hash table.
The WhitespaceCache continues to hold on to the cached whitespace
atoms for the life of the document. The WhitespaceCache itself
takes a bit over 1 KiB when empty, and if completely populated would
take a bit over 2 KiB plus 8 KiB of atom string data (a 1 byte string,
plus a 2 byte string, plus a 3 byte string, etc.). This doesn't seem
high enough to be worth clearing this out just to avoid memory usage
from text nodes that have been removed from the document.
We have the Document own the WhitespaceCache so that it's not just the
initial document load, but any uses of innerHTML or other fragment
parsing APIs, that can re-use previously atomized whitespace strings.
The choice of WhitespaceCache::maximumCachedStringLength = 128 is
somewhat arbitrary. The value must be <= 255 to avoid overflowing
the specific 64 bit code format used to encode the whitespace string.
Testing on Speedometer shows whitespace strings only up to length 26,
but it may be worth testing other content to see if it's worth
reducing maximumCachedStringLength.
When running Speedometer 2, no entries in the cache ever get replaced
by a different whitespace string of the same length, and 16 unique
whitespace string lengths are encountered.
We don't compute codes for 16 bit strings, since 16 bit strings passed
in to WhitespaceCache::lookup() are almost always the entirety of an
HTMLToken's data, and HTMLToken tracks whether any 16 bit characters are
present. If there are any, then we know the string cannot be all
whitespace, and we use a WhitespaceMode value of NotAllWhitespace to
skip the atomization altogether.
This patch is an almost 1% improvement on Speedometer 2.
* dom/Document.cpp:
(WebCore::m_whitespaceCache):
* dom/Document.h:
(WebCore::Document::whitespaceCache):
* html/parser/HTMLConstructionSite.cpp:
(WebCore::HTMLConstructionSite::HTMLConstructionSite):
(WebCore::HTMLConstructionSite::insertTextNode):
(WebCore::WhitespaceCache::codeForString):
(WebCore::WhitespaceCache::lookup):
* html/parser/HTMLConstructionSite.h:
* html/parser/HTMLTreeBuilder.cpp:
(WebCore::HTMLTreeBuilder::insertPhoneNumberLink):
(WebCore::HTMLTreeBuilder::linkifyPhoneNumbers):
(WebCore::HTMLTreeBuilder::processCharacterBufferForInBody):
* html/parser/HTMLTreeBuilder.h:
Canonical link: https://commits.webkit.org/240356@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280772 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Andres Gonzalez