https://bugs.webkit.org/show_bug.cgi?id=229217
<rdar://problem/81919223>
Reviewed by Ryan Haddad.
* Scripts/webkitpy/layout_tests/controllers/layout_test_runner.py:
(LayoutTestRunner.update_summary_with_result): Replace existing result with unexpected result so
that unexpected results always take precedence over expected ones.
* Scripts/webkitpy/layout_tests/models/test_run_results.py:
(TestRunResults.add): Do not replace existing result.
Canonical link: https://commits.webkit.org/240653@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281216 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229238
Reviewed by Eric Carlson.
Manually tested.
* GPUProcess/mac/com.apple.WebKit.GPUProcess.sb.in:
Align to iOS and only allow microphone access in sandbox if com.apple.webkit.microphone is sent to GPUProcess.
* Shared/WebPreferencesDefaultValues.cpp:
(WebKit::defaultCaptureAudioInGPUProcessEnabled):
Do audio capture in UIProcess for non Safari applications until rdar://problem/29448368 is fixed.
Canonical link: https://commits.webkit.org/240645@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281201 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229220
<rdar://problem/82057459>
Reviewed by Chris Fleizach.
Source/WebCore:
Test: accessibility/mac/line-index-for-textmarker.html
There was not a layout test that exercised directly the handler for the
AXLineForTextMarker attribute in [WebAccessibilityObjectWrapper
accessibilityAttributeValue:withParameter:].
This patch adds the above test to exercise this method for textarea and
contenteditable elements. The text in these elements includes soft and
hard linebreaks, which are important test cases for this API.
The handler for AXLineForTextMarker in turn calls
AccessibilityObject::lineForPosition, and analyzing this method, made a
minor optimization by getting rid off of an unnecessary local variable
and object copy.
* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::lineForPosition const):
Tools:
Added AccessibilityUIElement::lineIndexForTextMarker.
* WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp:
(WTR::AccessibilityUIElement::lineIndexForTextMarker const):
* WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:
* WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl:
* WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:
(WTR::AccessibilityUIElement::lineIndexForTextMarker const):
LayoutTests:
* accessibility/mac/line-index-for-textmarker-expected.txt: Added.
* accessibility/mac/line-index-for-textmarker.html: Added.
* platform/mac-wk1/TestExpectations:
Canonical link: https://commits.webkit.org/240644@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281200 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229236
Reviewed by Chris Dumez.
When UI process fails to get network process connection for the first time, it will retry on next runloop
iteration. On the retry, it terminates existing network process and relaunch a network process, because the
failure may indicate something is wrong in the network process. If existing network process is different from
the one on first try, the existing process can be functional and we should not terminate it.
* UIProcess/WebsiteData/WebsiteDataStore.cpp:
(WebKit::WebsiteDataStore::getNetworkProcessConnection):
Canonical link: https://commits.webkit.org/240643@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281199 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229222
rdar://81636256
Reviewed by Simon Fraser.
Add a layout test to exercise the hang fixed in bug #229200. This test can be manually run by opening it in
browser and verifying that the page does not hang (and outputs the expected PASS messages).
* fast/canvas/draw-text-repeatedly-into-disconnected-canvas-expected.txt: Added.
* fast/canvas/draw-text-repeatedly-into-disconnected-canvas.html: Added.
Canonical link: https://commits.webkit.org/240639@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281195 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229201
<rdar://81807216>
Reviewed by Eric Carlson.
In r280723, we stopped unconditionally creating an AVPlayerLayer when we create an AVPlayer. However,
we will still create an AVPlayerItemVideoOutput when we create an AVPlayerItem. This leaves our
AVPlayer in a state where AVFoundation will throw a "temporary error; try again later" when given
an otherwise valid protected HLS stream and key data through EME.
To work around this behavior, delay creating the AVPlayerItemVideoOutput until explicitly told to
create video renderers, typically simultaneous to creating an AVPlayerLayer.
* platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem):
Canonical link: https://commits.webkit.org/240637@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281193 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229152
Patch by Michael Catanzaro <mcatanzaro@gnome.org> on 2021-08-18
Reviewed by Philippe Normand.
Source/JavaScriptCore:
* PlatformGTK.cmake:
* javascriptcoregtk.pc.in:
Source/WebKit:
CMake is expanding templates in the pkg-config files that are not supposed to be expanded.
Oops! Let's switch back to using @SVN_REVISION@ instead of ${SVN_REVISION} as the template
for inserting the SVN revision into the pkg-config file, so we can tell CMake to leave the
${} variables alone.
* PlatformGTK.cmake:
* PlatformWPE.cmake:
* Shared/glib/BuildRevision.h.in:
* gtk/webkit2gtk-web-extension.pc.in:
* gtk/webkit2gtk.pc.in:
Tools:
* glib/apply-build-revision-to-files.py:
(main):
Canonical link: https://commits.webkit.org/240636@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281192 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=227949
<rdar://problem/80895783>
Reviewed by Frédéric Wang.
LayoutTests/imported/w3c:
* web-platform-tests/css/css-scroll-snap/snap-to-visible-areas-both-expected.txt: This bidirectional
scrolling test no longer snaps because we don't have support for choosing between two candidates
properly yet.
* web-platform-tests/css/css-scroll-snap/snap-to-visible-areas-x-axis-expected.txt: Updated to show newly passing test.
* web-platform-tests/css/css-scroll-snap/snap-to-visible-areas-y-axis-expected.txt: Ditto.
Source/WebCore:
No new tests. This is covered by two existing WPT tests.
* page/scrolling/ScrollSnapOffsetsInfo.cpp:
(WebCore::componentForAxis): Added this helper.
(WebCore::hasCompatibleSnapArea): Added this helper that checks to see if any of the snap areas
at a given scroll snap position are compatible with the viewport.
(WebCore::adjustPreviousAndNextForOnscreenSnapAreas): Adjusts the selected previous and next snap
positions by looking backward and forward for the first compatible snap position.
(WebCore::closestSnapOffsetWithInfoAndAxis): Use the new helper.
Canonical link: https://commits.webkit.org/240633@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281189 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229196
<rdar://82016054>
Reviewed by Geoffrey Garen.
Early return in IntersectionObserver::notify() if the callback has already been destroyed.
This is not supposed to happen as we're supposed to be keeping the JSIntersectionObserver
wrapper alive as long as the IntersectionObserver may fire events, which should keep the
callback alive too. However, despite Ryosuke's fix in r280549, the crash is still happening
in the wild. To address the crash, I am simply doing an early return for now, similarly to
what we already do in MutationObserver::deliver(), while keeping a debug assertion around
in hope of finding the root cause at some point.
No new tests, we do not not how this is happening yet.
* page/IntersectionObserver.cpp:
(WebCore::IntersectionObserver::notify):
Canonical link: https://commits.webkit.org/240632@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281188 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229200
rdar://81636256
Reviewed by Myles C. Maxfield.
The changes in https://webkit.org/b/228216 to fix rdar://80473805 introduced a mechanism to keep track of uses
of cached fonts and images in display list items in the web and GPU processes, via a `useCount` counter variable
that's incremented in the web process whenever the font or image is used in a display list item and decremented
in the GPU process whenever the item is processed.
However, the code to increment `useCount` in the web process currently only triggers at most once per rendering
update — this means that if there are multiple canvas drawing commands that use fonts in the same rendering
update, the web process' notion of `useCount` will fall out of sync with the GPU process' notion of `useCount`.
In most cases, this causes the cached font to remain for longer in the GPU process than necessary; however, in
this specific scenario, it's possible for the web process to tell the GPU process to release the cached font too
early, which causes the GPU process to prematurely purge the font from the cache, and subsequently wait for the
cached font to arrive (which will never arrive, since the web process has already released the font).
In other words, the timeline of events between the web and GPU processes looks like this (where `f` is a cached
web font, `A_f` is a drawing command that uses `f`, and `B_f` is another drawing command that uses `f`).
WEB GPU
==============================================================
1. Cache `f`
2. Append `A_f`
3. Cache `f`
4. Play back `A_f`
5. Append `B_f`
6. Release `f` (use count was 1 here)
7. Release `f` (use count dropped from 1 to 0)
8. Play back `B_f`
...and then display list playback stops due to `f` not being in
the cache.
To address this, we simply move the `useCount` increment in the web process out of the rendering update check.
The original intent of the fix for bug #228216 was to allow for `useCount` to increment as many times as needed
per rendering update, so this limitation was unintentional.
Unfortunately, I have not been able to come up with a layout test that reliably reproduces this scenario (yet).
* WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp:
(WebKit::RemoteResourceCacheProxy::recordFontUse):
Canonical link: https://commits.webkit.org/240631@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=224415
<rdar://problem/76811968>
Reviewed by Simon Fraser.
Source/WebCore:
Improve sticky positioning applied to inline items. The first improvement is to
skip anonymous RenderBlock parents of inline display items when looking for the
containing block used to calculate sticky constraints. These anonymous parents
are not the containing block that constrains the movement of these kind of stickily
positioned items. Instead look for containing block for the anonymous parent,
which does limit the scroll boundaries of inline stickily position items.
Previously, when converting the frame rect from the coordinate space of the stickily
positioned item to that of the scrolling container, the code used to apply the offset
from the containing block to the scrolling ancestor directly to the frame rect. That
doesn't work when the containing block that determines sticky constraints is not the
direct containing block of the stickily positioned items (as it is for inlines).
Instead, the code now just maps the frame rect directly from the item parent to
the scrolling ancestor. This simplifies things a bit and allows it to work with
inline stickily positioned items.
Finally, this change adds comments to make it clearer what this method is doing.
No new tests. This is covered by existing WPT tests. Specifically the following
tests are now passing:
imported/w3c/web-platform-tests/css/css-position/sticky/position-sticky-hyperlink.html
imported/w3c/web-platform-tests/css/css-position/sticky/position-sticky-nested-table.html
imported/w3c/web-platform-tests/css/css-position/sticky/position-sticky-table-parts.html
imported/w3c/web-platform-tests/css/css-position/sticky/position-sticky-table-th-bottom.html
imported/w3c/web-platform-tests/css/css-position/sticky/position-sticky-nested-thead-th.html
* css/CSSComputedStyleDeclaration.cpp:
(WebCore::positionOffsetValue): enclosingClippingBoxForStickyPosition now returns a pair
to avoid passing in a pointer. Only look at the first part of the pair here.
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::computeStickyPositionConstraints const): Modified this method
to return a pair in order to avoid dealing with input parameters. This allows simplifying this
method, making the code a bit simpler.
(WebCore::RenderBoxModelObject::enclosingClippingBoxForStickyPosition const): Deleted.
(WebCore::RenderBoxModelObject::computeStickyPositionConstraints const): Make two changes
to this method to improve sticky positioning for inline elements. The first change is
to be a bit better about finding the appropriate containing block for calculating sticky
constraints. The second is to more resiliently move from coordinate systems. In addition,
improve the comments for this method to make it clearer what is happening at each step.
* rendering/RenderBoxModelObject.h: Updated method declaration.
LayoutTests:
* TestExpectations: Unskip newly passing tests and skip one test which was
a false pass previously.
Canonical link: https://commits.webkit.org/240630@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281185 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229185
Reviewed by Philippe Normand.
Improve flatpakutils.py by ensuring that we don't make redundant
calls to flatpak during initialization of the data structures. This
saves 5 seconds on every call to build-webkit and run-webkit-tests.
Before:
$ time ./Tools/Scripts/webkit-flatpak -c true
real 0m6,297s
user 0m0,786s
sys 0m0,513s
After:
$ time ./Tools/Scripts/webkit-flatpak -c true
real 0m1,243s
user 0m0,375s
sys 0m0,162s
* flatpak/flatpakutils.py:
(FlatpakPackages.__init__): Separate the update into another
method so that it can be called directly when a package is installed.
Add new packages directly to self.packages.
(FlatpakRepos.__init__): Ensure that we only update our repositories
and package list once we've initialized our list of repositories.
(FlatpakRepos.add): Return True if this method actually changed anything
and accept a parameter determining whether an update is done to
the repository and package list.
(FlatpakRepos.is_package_installed): Added this method which replaces
FlatpakRepo.is_app_installed.
(FlatpakRepo.__init__): Remove the app registry because it is duplicated
by FlatpakPackages.
(FlatpakPackage.is_installed): Now call FlatpakRepos.is_package_installed.
(WebkitFlatpak._reset_repository): Set up both repositories here and
pass then as part of the FlatpakRepos constructor.
(WebkitFlatpak.main): Separate out the check which deletes the Flatpak
repository from the one that checks if the packages are installed. This
makes sure we don't install packages and then immediately delete them.
(WebkitFlatpak.check_installed_packages): rename _get_packages to _get_dependency_packages
in order to make it clear that it doesn't return installed packages.
(WebkitFlatpak._get_dependency_packages): Ditto.
(WebkitFlatpak.install_all): Ditto.
(FlatpakRepo.is_app_installed): Deleted.
(WebkitFlatpak._get_packages): Deleted.
Canonical link: https://commits.webkit.org/240629@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281184 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229145
Reviewed by Alicia Boya Garcia.
Source/WebCore:
Added GStreamerEMEUtilities to include implementation of
InitData::extractCencIfNeeded. This tries to parse the possible
XML inside an init data that could come from MPD manifests. If it
succeeds, it keeps the parsed init data, if not, it returns the
original one.
Based on a patch by Philippe Normand.
* platform/GStreamer.cmake:
* platform/graphics/gstreamer/eme/GStreamerEMEUtilities.cpp: Added.
(WebCore::markupStartElement):
(WebCore::markupEndElement):
(WebCore::markupText):
(WebCore::markupPassthrough):
(WebCore::markupError):
(WebCore::InitData::extractCencIfNeeded):
* platform/graphics/gstreamer/eme/GStreamerEMEUtilities.h:
(WebCore::InitData::InitData):
Source/WTF:
* wtf/glib/GUniquePtr.h: Added deleter for GMarkupParseContext.
Canonical link: https://commits.webkit.org/240628@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281183 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229181
* TestExpectations:
r281147 changed this test from flaky to differently flaky.
It used to pass sometimes because the whole document would load before any script was executed, so there was no PerformanceNavigationTiming
object to update as the document loaded. r281147 fixed that, making it basically always pass when loaded over the real internet.
Now, sometimes it loads locally so fast that Performance::reduceTimeResolution makes some of the values 0, which is allowed by the spec but not
by the tests. In practice, pages don't load over the internet in less than 1ms, so this isn't much of an issue, just in our test bots.
I'll propose a fix for the web platform test, but for now I mark it as flaky.
Canonical link: https://commits.webkit.org/240626@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281181 268f45cc-cd09-0410-ab3c-d52691b4dbfc
<https://webkit.org/b/229128>
<rdar://problem/81964007>
Reviewed by Alex Christensen.
* src/libANGLE/renderer/metal/DisplayMtl.h:
(rx::DisplayMtl::getMetalDeviceMatchingAttribute):
- Change to return mtl::AutoObjCPtr<> to make ownership clear.
(rx::DisplayMtl::mMetalDevice):
- No need to initialize to nil.
* src/libANGLE/renderer/metal/DisplayMtl.mm:
(rx::DisplayMtl::initializeImpl):
- Update for changes to getMetalDeviceMatchingAttribute().
(rx::DisplayMtl::getMetalDeviceMatchingAttribute):
- Change to return mtl::AutoObjCPtr<> to make ownership clear.
- Fix leak of `deviceList`, `externalGPUs`, `integratedGPUs`, and
`discreteGPUs`.
- Use mtl::adoptObjCObj<>() to prevent leak of
MTLCreateSystemDefaultDevice().
* src/libANGLE/renderer/metal/IOSurfaceSurfaceMtl.mm:
- Fix leak of `captureDescriptor` in two different if blocks.
* src/libANGLE/renderer/metal/ProgramMtl.mm:
- Fix leak of `funcConstants` in early return on error path.
* src/libANGLE/renderer/metal/ProvokingVertexHelper.mm:
(rx::ProvokingVertexHelper::getSpecializedShader):
- Fix leak of `fcValues`.
* src/libANGLE/renderer/metal/SurfaceMtl.mm:
- Fix leak of `captureDescriptor` in two different if blocks.
* src/libANGLE/renderer/metal/mtl_common.h:
(rx::mtl::WrappedObject::retainAssign):
- Move statement inside #if/#endif that isn't needed for ARC.
(rx::mtl::WrappedObject::unretainAssign): Add.
(rx::mtl::AutoObjCPtr::AutoObjCPtr): Add.
(rx::mtl::adoptObjCObj): Add.
- Add a helper method to adopt an Objective-C object to
eliminate the need to autorelease a +1 retained object before
an mtl::AutoObjCPtr<> object wraps it. Modeled after
WTF::RetainPtr<> in WebKit.
* src/libANGLE/renderer/metal/mtl_state_cache.mm:
(rx::mtl::RenderPipelineCache::createRenderPipelineState):
(rx::mtl::ProvokingVertexComputePipelineCache::createComputePipelineState):
- Use adoptObjCObj<>() to fix potential leak on the early return
path since these methods return an mtl::AutoObjCPtr<>.
Canonical link: https://commits.webkit.org/240610@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281160 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=228095
<rdar://problem/81393898>
Reviewed by Don Olmstead.
Source/WebKit:
If a page dispatches a keepalive fetch and the page is navigated
away, the alive NetworkResourceLoader is transferred to the
NetworkSession by NetworkConnectionToWebProcess::transferKeptAliveLoad.
After the NetworkResourceLoader receives a response, it is canceled
by PolicyAction::Ignore.
However, NetworkDataTaskCurl didn't properly cancel the kept alive
NetworkResourceLoader. They remained in m_keptAliveLoads of
NetworkSession even after the requests were canceled.
Test: http/tests/fetch/keepalive-fetch-2.html
* NetworkProcess/curl/NetworkDataTaskCurl.cpp:
(WebKit::NetworkDataTaskCurl::invokeDidReceiveResponse): Call didCompleteWithError on PolicyAction::Ignore.
LayoutTests:
* http/tests/fetch/keepalive-fetch-2-expected.txt: Added.
* http/tests/fetch/keepalive-fetch-2.html: Added.
* http/tests/fetch/resources/get-set-temp-file.py: Added.
* http/tests/fetch/resources/keepalive-fetch-2-window.html: Added.
Canonical link: https://commits.webkit.org/240608@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281158 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=229193
Reviewed by Eric Carlson.
Source/WebCore:
Don't include a Objective-C header in a file which will be included by C++ source; forward-declare
the class instead.
* platform/graphics/avfoundation/objc/VideoLayerManagerObjC.h:
* platform/graphics/avfoundation/objc/VideoLayerManagerObjC.mm:
Source/WebKit:
Rather than have two, separate implementations of the MediaPlayerPrivateRemote constructor (one for Cocoa),
just wrap the initializer for the Cocoa-specific ivar in PLATFORM(COCOA) guards.
* WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:
(WebKit::MediaPlayerPrivateRemote::MediaPlayerPrivateRemote):
* WebProcess/GPU/media/cocoa/MediaPlayerPrivateRemoteCocoa.mm:
(WebKit::MediaPlayerPrivateRemote::MediaPlayerPrivateRemote): Deleted.
Canonical link: https://commits.webkit.org/240607@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281157 268f45cc-cd09-0410-ab3c-d52691b4dbfc