Branch: refs/heads/safari-7616.1.14.10-branch
Home: https://github.com/WebKit/WebKit
Commit: 47212f0dff65964ca103a313655c176c172d9f74
https://github.com/WebKit/WebKit/commit/47212f0dff65964ca103a313655c176c172d9f74
Author: Myah Cobbs <mco...@apple.com>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
Identifier: 263769.29@safari-7616.1.14.10-branch
Commit: eca1876e391623dd11a48c7edd2952de8c5fc07e
https://github.com/WebKit/WebKit/commit/eca1876e391623dd11a48c7edd2952de8c5fc07e
Author: Sammy Gill <sammy.g...@apple.com>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M LayoutTests/TestExpectations
A
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/masonry-columns-item-containing-block-is-grid-content-width-expected.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/masonry-columns-item-containing-block-is-grid-content-width.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.h
M Source/WebCore/rendering/RenderGrid.cpp
Log Message:
-----------
Cherry-pick ff409be22993. rdar://problem/109170495
[css-grid][masonry] Containing block for items in a masonry columns grid
should be the grid's content box logical width
https://bugs.webkit.org/show_bug.cgi?id=256611
rdar://109170495
Reviewed by Matt Woodrow.
The masonry spec states, "The containing block for a grid item is
formed by its grid area in the grid axis and the grid container’s
content-box in the masonry axis."
This means that for a grid that has masonry columns specified, the
masonry axis will be in the logical width direction of the grid. The
items should have their containing block set to the content box logical
box of the grid.
We can modify GridTrackSizingAlgorithm::gridAreaBreadthForChild to
return this value when the grid is a masonry columns grid since normally
the grid area would be used as the containing block in non-masonry
grids. This allows the rest of the code to use the grid area sizes of
the containing block in both masonry and non-masonry scenarios.
Previously, this function would have attempted to compute the
value by iterating over the tracks in the specified direction, but there
are no tracks in the masonry direction so we use the logic specified by
the masonry spec instead.
However, in order for this change to work properly we had to make a
change in RenderGrid::layoutMasonry by removing code that was
incorrectly overriding the logical width of the grid. The previous code
was attempting to set the logical width of the grid to the masonry
content size when the grid had masonry columns specified and an auto
logical width. There were 2 main issues with this piece of code:
1.) m_masonryLayout.gridContentSize() will always return 0 since we
actually haven't performed masonry layout at this point
2.) The grid shouldn't be overriding its logical width like this anyways
and it should instead be set by sized by the rules of the formatting
context it is participating in (e.g. block or inline layout).
By removing this code we can get the actual width of the grid later on
when we call m_renderGrid->contentLogicalWidth() rather than the
incorrect 0 value that it was being set to.
The following example highlights the changes that were made.
<style>
grid {
display: grid;
grid-template-columns:masonry;
grid-template-rows: auto;
}
</style>
<grid>
<svg width="100" height="100" viewBox="0 0 1 1" style="width: 100%;
max-width: 100px; background: green;"></svg>
</grid>
By removing the extra code in RenderGrid::layoutMasonry, the grid will
get sizes as a block level box in the block formatting context it is
participating in, giving it a logical width that takes up its available
space. The svg's containing block logical width is set to its value so
it is able to resolve its percentage width to the correct value whereas
before the containing block logical width would have been 0px.
https://drafts.csswg.org/css-grid-3/#containing-block
* LayoutTests/TestExpectations:
*
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/masonry-columns-item-containing-block-is-grid-content-width-expected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/masonry-columns-item-containing-block-is-grid-content-width.html:
Added.
* LayoutTests/platform/glib/TestExpectations:
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::gridAreaBreadthForChild const):
* Source/WebCore/rendering/GridTrackSizingAlgorithm.h:
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::layoutMasonry):
Canonical link: https://commits.webkit.org/264011@main
Identifier: 263769.30@safari-7616.1.14.10-branch
Commit: 2b611c6f3bb30277a79bb5bcae42460ceca91426
https://github.com/WebKit/WebKit/commit/2b611c6f3bb30277a79bb5bcae42460ceca91426
Author: Said Abou-Hallawa <s...@apple.com>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M Source/WebKit/Shared/cg/ShareableBitmapCG.cpp
Log Message:
-----------
Cherry-pick 58702859275c. rdar://problem/108072383
[GPU Process] (REGRESSION 262607@main): Copy pixels of CGImage only if it
is not a sub-image
https://bugs.webkit.org/show_bug.cgi?id=255677
rdar://108072383
Reviewed by Simon Fraser.
In ShareableBitmap::createFromImagePixels(), CGImage and its CGDataProvider
may disagree about how many bytes are in the pixels buffers. CGImage is most
likely a sub-image of another CGImage which inherits its meta data but not
the full pixels buffer.
In this case we should fallback to ShareableBitmap::createFromImageDraw().
Ortherwise ShareableBitmapConfiguration will falsely describe the data in
the
SharedMemory.
* Source/WebKit/Shared/cg/ShareableBitmapCG.cpp:
(WebKit::ShareableBitmap::createFromImagePixels):
Canonical link: https://commits.webkit.org/264021@main
Identifier: 263769.31@safari-7616.1.14.10-branch
Commit: 2cb2cce241db5f95ec6aae9eed700d80d00862ae
https://github.com/WebKit/WebKit/commit/2cb2cce241db5f95ec6aae9eed700d80d00862ae
Author: Chris Dumez <cdu...@apple.com>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M Source/WebKit/UIProcess/API/APIPageConfiguration.cpp
M Source/WebKit/UIProcess/API/APIPageConfiguration.h
M Source/WebKit/UIProcess/API/Cocoa/WKProcessGroup.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfiguration.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h
M Source/WebKit/UIProcess/Inspector/WebInspectorUtilities.cpp
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Source/WebKit/UIProcess/WebProcessPool.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm
Log Message:
-----------
Cherry-pick 7f048d704b87. rdar://problem/109277324
Add SPI to delay a WKWebView's WebProcess launch
https://bugs.webkit.org/show_bug.cgi?id=256727
rdar://109277324
Reviewed by Ben Nham.
Add SPI to delay a WKWebView's WebProcess launch. We already have this
preference internally but it could not be controlled by the client
application.
* Source/WebKit/UIProcess/API/APIPageConfiguration.cpp:
(API::PageConfiguration::delaysWebProcessLaunchUntilFirstLoad const):
* Source/WebKit/UIProcess/API/APIPageConfiguration.h:
(API::PageConfiguration::setDelaysWebProcessLaunchUntilFirstLoad):
* Source/WebKit/UIProcess/API/Cocoa/WKProcessGroup.mm:
(-[WKProcessGroup setDelegate:]):
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _launchInitialProcessIfNecessary]):
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfiguration.mm:
(-[WKWebViewConfiguration _delaysWebProcessLaunchUntilFirstLoad]):
(-[WKWebViewConfiguration _setDelaysWebProcessLaunchUntilFirstLoad:]):
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:
* Source/WebKit/UIProcess/Inspector/WebInspectorUtilities.cpp:
(WebKit::prepareProcessPoolForInspector):
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::globalDelaysWebProcessLaunchDefaultValue):
(WebKit::WebProcessPool::createWebPage):
* Source/WebKit/UIProcess/WebProcessPool.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:
Canonical link: https://commits.webkit.org/264031@main
Identifier: 263769.32@safari-7616.1.14.10-branch
Commit: 6e7d9a19f2fb283fa9e4d25038487748844e6591
https://github.com/WebKit/WebKit/commit/6e7d9a19f2fb283fa9e4d25038487748844e6591
Author: Sihui Liu <sihui_...@apple.com>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M Source/WebCore/workers/service/server/SWRegistrationDatabase.cpp
M Source/WebCore/workers/service/server/SWRegistrationDatabase.h
M Source/WebKit/NetworkProcess/storage/ServiceWorkerStorageManager.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsiteDataStoreCustomPaths.mm
Log Message:
-----------
Cherry-pick abde730eecbb. rdar://problem/108841865
ServiceWorkerStorageManager should only delete its own files when clearing
registrations
https://bugs.webkit.org/show_bug.cgi?id=256725
rdar://108841865
Reviewed by Chris Dumez.
Existing SPI allows clients to set the same path for different data types,
so directory of ServiceWorkerStorageManager
might contain files for other types. Therefore, ServiceWorkerStorageManager
should not remove the directory when
clearing registrations.
Test: WKWebsiteDataStoreConfiguration.SameCustomPathForDifferentTypes
* Source/WebCore/workers/service/server/SWRegistrationDatabase.cpp:
(WebCore::SWRegistrationDatabase::~SWRegistrationDatabase):
(WebCore::SWRegistrationDatabase::close):
(WebCore::SWRegistrationDatabase::clearAllRegistrations):
* Source/WebCore/workers/service/server/SWRegistrationDatabase.h:
* Source/WebKit/NetworkProcess/storage/ServiceWorkerStorageManager.cpp:
(WebKit::ServiceWorkerStorageManager::clearAllRegistrations):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsiteDataStoreCustomPaths.mm:
(TEST):
Canonical link: https://commits.webkit.org/264036@main
Identifier: 263769.33@safari-7616.1.14.10-branch
Commit: d721aae18b77b362b8994ee8830b3e9b6dc9764f
https://github.com/WebKit/WebKit/commit/d721aae18b77b362b8994ee8830b3e9b6dc9764f
Author: Matthew Finkel <sys...@apple.com>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M Source/WebCore/Headers.cmake
M Source/WebCore/Sources.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/html/CanvasBase.cpp
M Source/WebCore/html/CanvasBase.h
A Source/WebCore/html/CanvasNoiseInjection.cpp
A Source/WebCore/html/CanvasNoiseInjection.h
M Source/WebCore/html/HTMLCanvasElement.cpp
Log Message:
-----------
Cherry-pick 9084db41d592. rdar://problem/107371244
Refactor Canvas noise injection logic and improve support for gradients in
post-processed ImageData
https://bugs.webkit.org/show_bug.cgi?id=255993
rdar://107371244
Reviewed by Kimmo Kinnunen.
Gradients present an interesting problem when post-processing canvas
ImageData
because tweaking colors result in significant visual anomalies. This change
introduces some naive gradient detection by looking at all of the immediate
neighbors of a pixel. We decide that a pixel is within a gradient if the
current color is between its opposing adjacent colors (e.g., above and
below,
left and right, etc). If a color is decided to be within a gradient, then we
set those adjacent colors as bounds within which we can tweak the current
color.
In addition, within this change, we move the noise injection logic into its
own
class, it removes the dependency on supplied colors for post-processing,
and it
reduces the magnitude of noise from ~5% to ~1%.
* Source/WebCore/Headers.cmake:
* Source/WebCore/Sources.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/html/CanvasBase.cpp:
(WebCore::CanvasBase::makeRenderingResultsAvailable):
(WebCore::CanvasBase::didDraw): We clip the rect before passing it into
CanvasNoiseInjection, and if the rect is std::nullopt then we pass in the
entire canvas.
(WebCore::CanvasBase::postProcessPixelBufferResults const):
(WebCore::CanvasBase::postProcessDirtyCanvasBuffer const): Deleted.
* Source/WebCore/html/CanvasBase.h:
* Source/WebCore/html/CanvasNoiseInjection.cpp: Added.
(WebCore::CanvasNoiseInjection::updateDirtyRect):
(WebCore::isIndexInBounds):
(WebCore::setTightnessBounds):
(WebCore::getGradientNeighbors):
(WebCore::CanvasNoiseInjection::postProcessDirtyCanvasBuffer):
(WebCore::CanvasNoiseInjection::postProcessPixelBufferResults const):
* Source/WebCore/html/CanvasNoiseInjection.h: Added.
* Source/WebCore/html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::getImageData):
Originally-landed-as: 264019@main (bfc25dc6ca1c). rdar://107371244
Identifier: 263769.34@safari-7616.1.14.10-branch
Commit: 581a650640d01d268223ff394bbaffa7cdf026c5
https://github.com/WebKit/WebKit/commit/581a650640d01d268223ff394bbaffa7cdf026c5
Author: Myah Cobbs <mco...@apple.com>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M LayoutTests/TestExpectations
R
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/masonry-columns-item-containing-block-is-grid-content-width-expected.html
R
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/masonry-columns-item-containing-block-is-grid-content-width.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.h
M Source/WebCore/rendering/RenderGrid.cpp
Log Message:
-----------
Revert ff409be22993. rdar://problem/109170495
Identifier: 263769.35@safari-7616.1.14.10-branch
Commit: 40f28720e0f3bf8367761dba1cb3c29a70b2ff4d
https://github.com/WebKit/WebKit/commit/40f28720e0f3bf8367761dba1cb3c29a70b2ff4d
Author: Myah Cobbs <mco...@apple.com>
Date: 2023-05-16 (Tue, 16 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
Identifier: 263769.36@safari-7616.1.14.10-branch
Commit: c8c136c12d8903270b1cf8ba7f58d0e03b0191d9
https://github.com/WebKit/WebKit/commit/c8c136c12d8903270b1cf8ba7f58d0e03b0191d9
Author: Wenson Hsieh <wenson_hs...@apple.com>
Date: 2023-05-16 (Tue, 16 May 2023)
Changed paths:
M Source/WebCore/platform/graphics/FontCascade.cpp
M Source/WebCore/platform/graphics/FontCascade.h
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/rendering/RenderText.cpp
M Source/WebCore/rendering/RenderText.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/editable-body-mixed-text.html
Log Message:
-----------
Cherry-pick 299bc278524d. rdar://problem/106950483
[iOS] Typing is extremely slow when editing very long sentences, with
out-of-process keyboard
https://bugs.webkit.org/show_bug.cgi?id=256762
rdar://106950483
Reviewed by Myles Maxfield, Alan Baradlay and Tim Horton.
When out-of-process keyboard is enabled, UIKit requests document editing
contexts upon every
selection change, and asks for three sentences-worth of context before and
after the selection. For
extremely long sentences (e.g. 1000+ characters), each document context
request can take hundreds of
milliseconds to process, causing the web process to noticeably hang during
each keystroke. The vast
majority of this time is spent computing individual rects corresponding to
each character in the
editing context range; the way we currently do this is by:
1. Using `CharacterIterator` to construct a single-character `SimpleRange`
for each character in
the editing context range.
2. Using `RenderObject::absoluteTextRects` on each character range, and
uniting the results.
3. Mapping each rect back into root view coordinate space.
The performance issues arise in step (2), since
`RenderObject::absoluteTextRects` for a range in a
text run works by using text layout helpers to advance from the start of
the run to the beginning
of the requested range, advancing to the end of the requested range, and
using the difference in
width to compute the final rect. When called over *all* individual
character ranges in a given text
run of length `N`, this means that the number of times we advance through
the text run is `O(N^2)`.
As such, the current performance characteristics of step (2) above are
`O(MN^2)`, where `M` is the
number of text runs in the context and `N` represents (on average) the
number of characters per run.
To fix this, we improve the `O(N^2)` algorithm for computing character
rects to just `O(N)`, by
introducing and adopting new helper methods to ask for a list of each
individual character rect in
a given text run. In my testing on an iPad Pro 3rd generation with ~3000
characters worth of context
before and after the selection, this speeds document editing request time
up by a factor of roughly
25x, which is enough to make typing and text interactions feel instantly
responsive.
Though these changes shouldn't change behavior (since it's only a
performance optimization), the
patch adds 4 new API tests to help exercise some additional corner cases
that aren't already covered
by existing tests: `DocumentEditingContext.CharacterRectConsistency*`. See
below for more details.
* Source/WebCore/layout/integration/inline/InlineIteratorTextBox.cpp:
* Source/WebCore/layout/integration/inline/InlineIteratorTextBox.h:
* Source/WebCore/platform/graphics/FontCascade.cpp:
(WebCore::FontCascade::characterSelectionRectsForText const):
Add a new helper method to return a list of character rects, in the given
range in a text run. This
works similarly to the existing `adjustSelectionRectForText` method, except
that it uses a single
complex text controller to advance from the start to the end, and emits a
character rect every time
it advances.
* Source/WebCore/platform/graphics/FontCascade.h:
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::absoluteTextQuads):
Refactor this to pass the whole `OptionSet` of behaviors down to
`absoluteQuadsForRange`.
(WebCore::absoluteRectsForRangeInText):
* Source/WebCore/rendering/RenderObject.h:
Add a new `BoundingRectBehavior` type: `ComputeIndividualCharacterRects`,
which indicates that the
client wants a rect representing each individual text character.
* Source/WebCore/rendering/RenderText.cpp:
(WebCore::RenderText::absoluteRectsForRange const):
Refactor this to pass in an `OptionSet`.
(WebCore::characterRects const):
Add a new helper function to return a list of character rects, in the given
range.
(WebCore::RenderText::absoluteQuadsForRange const):
Make this take an `OptionSet` of behaviors instead of individual boolean
flags. I opted for this
approach over adding a third `bool` parameter to this function, since it
would be cleaner (and make
this more extensible moving forward).
* Source/WebCore/rendering/RenderText.h:
(WebCore::RenderText::absoluteQuadsForRange):
Honor `ComputeIndividualCharacterRects` here by using the per-character
helpers described above to
compute a list of character rects for each character in the given range.
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::requestDocumentEditingContext):
Switch from `CharacterIterator` to `TextIterator`, and ask for rects for
each text run found by the
text iterator using the new `ComputeIndividualCharacterRects` option.
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm:
(-[NSString composedCharacterRanges]):
(-[UIWKDocumentContext boundingRectForCharacterRange:]):
(-[TestWKWebView firstSelectionRect]):
(-[TestWKWebView waitForFirstSelectionRectToChange:]):
Add several API test helper methods.
(checkThatAllCharacterRectsAreConsistentWithSelectionRects):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/editable-body-mixed-text.html:
Added.
Add a few new test cases to verify that the character rects received via
document editing context
are consistent with actual selection rects. To do this, we first use the
document context API to
request character rects after focusing the test page; we then select every
grapheme cluster in the
page, and verify that the final selection rect (as presented by UIKit)
matches what we got in the
beginning, via the context's character rect info.
This approach keeps the tests robust over time against platform changes (as
opposed to more naive
approaches like checking against hard-coded values). We also exercise
various text layout scenarios
that aren't fully covered by existing tests:
- Emojis and other glyphs that span multiple codepoints
- Bidirectional text
- Left-to-right vs. right-to-left text on the body
- Horizontal vs. vertical writing mode on the body
Canonical link: https://commits.webkit.org/264086@main
Identifier: 263769.37@safari-7616.1.14.10-branch
Commit: 8e7792e8762fae199a033dc502811f19f4406b21
https://github.com/WebKit/WebKit/commit/8e7792e8762fae199a033dc502811f19f4406b21
Author: Russell Epstein <repst...@apple.com>
Date: 2023-05-16 (Tue, 16 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.3
Canonical link: https://commits.webkit.org/263769.38@safari-7616.1.14.10-branch
Commit: b26d9a939776000a61f0f7982d16e304bd474cb6
https://github.com/WebKit/WebKit/commit/b26d9a939776000a61f0f7982d16e304bd474cb6
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.4
Identifier: 263769.39@safari-7616.1.14.10-branch
Commit: fe600fae0ce82df84e7e8d03a9ca3e8cfe963491
https://github.com/WebKit/WebKit/commit/fe600fae0ce82df84e7e8d03a9ca3e8cfe963491
Author: Myah Cobbs <mco...@apple.com>
Date: 2023-05-19 (Fri, 19 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
Identifier: 263769.40@safari-7616.1.14.10-branch
Commit: bbc8deb87cf19ea0cbbaabad4d7a13865a295ab8
https://github.com/WebKit/WebKit/commit/bbc8deb87cf19ea0cbbaabad4d7a13865a295ab8
Author: Youenn Fablet <youe...@gmail.com>
Date: 2023-05-19 (Fri, 19 May 2023)
Changed paths:
M Source/WebCore/platform/mediastream/mac/AVCaptureDeviceManager.h
M Source/WebCore/platform/mediastream/mac/AVCaptureDeviceManager.mm
Log Message:
-----------
Cherry-pick 49ad76ecb745. rdar://problem/109220107
[iOS] AVCatpureDeviceManager should set userPreferrerCamera
https://bugs.webkit.org/show_bug.cgi?id=256882
rdar://109220107
Reviewed by Eric Carlson.
Before https://bugs.webkit.org/show_bug.cgi?id=255451, we were forcing the
default camera to be the front camera using media constraints.
This was blocking edfaulting to higher priority cameras, hence the fix.
The drawback is that we are now fully relying on systemPreferredCamera to
select the default camera.
systemPreferredCamera might change depending on which camera was last used
by the application.
We do not want that behavior, so we use userPreferredCamera to state that
we are more interested in the front camera than in the back cameras.
Other camneras should still be higher priority if available.
Manually tested.
* Source/WebCore/platform/mediastream/mac/AVCaptureDeviceManager.h:
* Source/WebCore/platform/mediastream/mac/AVCaptureDeviceManager.mm:
(WebCore::AVCaptureDeviceManager::computeCaptureDevices):
(WebCore::AVCaptureDeviceManager::refreshCaptureDevicesInternal):
(WebCore::AVCaptureDeviceManager::setUserPreferredCamera):
(WebCore::AVCaptureDeviceManager::refreshCaptureDevices): Deleted.
Canonical link: https://commits.webkit.org/264165@main
Identifier: 263769.41@safari-7616.1.14.10-branch
Commit: 524c0cd7a2893a17bb8305b3900ff71355ecafc7
https://github.com/WebKit/WebKit/commit/524c0cd7a2893a17bb8305b3900ff71355ecafc7
Author: Alan Baradlay <za...@apple.com>
Date: 2023-05-19 (Fri, 19 May 2023)
Changed paths:
A
LayoutTests/fast/inline/range-replace-partial-layout-invalidation-expected.html
A LayoutTests/fast/inline/range-replace-partial-layout-invalidation.html
M
Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp
Log Message:
-----------
Cherry-pick 8922f7c4d332. rdar://problem/109538333
(REGRESSION 262148@main) No repaint when deleting text, possibly only when
the deleted text spans more than one line
https://bugs.webkit.org/show_bug.cgi?id=257043
<rdar://109538333>
Reviewed by Antti Koivisto.
Normally while editing inline content in a content-editable container e.g
"This is some long
long long long
long text content"
and select/delete "long long text" (spanning over line#2 and #3)
What happens is RenderText receives a content mutation event pointing to
the _beginning_ of "long long text".
As a result we damage line #2 and run a partial layout staring from line#2
until after we see no layout change anymore or we hit content end.
However some JS based editors call innerHTML instead to mimic editing steps
turning the above example to a "range replace"
type of mutation where the entire text content is getting replaced with the
"new", shortened content.
In such cases, instead of receiving the position of the actual damage, we
end up with the offset value of 0
since the entire content is being replaced (even though it's just a slight
change in the text content)
Now we damage line#0 and start running layout from the very first line
until we see no layout change...which is the second line
since the actual damage is on the third line.
Since IFC does not support such mutations yet, in this patch we disable
range based bailout which means while
we still run partial inline layout, we always go all the way to the bottom
of the content.
/fast/inline/range-replace-partial-layout-invalidation-expected.html: Added.
* LayoutTests/fast/inline/range-replace-partial-layout-invalidation.html:
Added.
*
Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp:
(WebCore::Layout::InlineInvalidation::textWillBeRemoved):
Canonical link: https://commits.webkit.org/264274@main
Identifier: 263769.42@safari-7616.1.14.10-branch
Commit: 1573a06e8fe4e3b19ca5b130e9735bb5eef4e645
https://github.com/WebKit/WebKit/commit/1573a06e8fe4e3b19ca5b130e9735bb5eef4e645
Author: Brady Eidson <beid...@apple.com>
Date: 2023-05-19 (Fri, 19 May 2023)
Changed paths:
M Source/WebKit/SwiftOverlay/WebKitSwiftOverlay.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick fbe202e644f1. rdar://problem/108176822
WebKitSwiftOverlay should (once again) include a WebKitAdditions overlay
https://bugs.webkit.org/show_bug.cgi?id=257046
rdar://109577606
Reviewed by Andy Estes.
Include WebKitAdditionsSwiftOverlay from a well known location.
* Source/WebKit/SwiftOverlay/WebKitSwiftOverlay.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/264278@main
Identifier: 263769.43@safari-7616.1.14.10-branch
Commit: 4b95cae88a62817134aba45a4704425e428f094f
https://github.com/WebKit/WebKit/commit/4b95cae88a62817134aba45a4704425e428f094f
Author: Russell Epstein <repst...@apple.com>
Date: 2023-05-20 (Sat, 20 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.6
Identifier: 263319.494@safari-7616.1.14.10-branch
Commit: 3c53d4ebf73eed6d0b6814287f852ec0bf5cbbc7
https://github.com/WebKit/WebKit/commit/3c53d4ebf73eed6d0b6814287f852ec0bf5cbbc7
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2023-05-22 (Mon, 22 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.7
Identifier: 263769.45@safari-7616.1.14.10-branch
Commit: 20fd0853e47f5ae9e1103b8cada61c3b4dba77f4
https://github.com/WebKit/WebKit/commit/20fd0853e47f5ae9e1103b8cada61c3b4dba77f4
Author: Matt Woodrow <mattwood...@apple.com>
Date: 2023-05-22 (Mon, 22 May 2023)
Changed paths:
M Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.cpp
M Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.h
M Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.messages.in
M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp
M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.h
M Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.cpp
M Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.h
M Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.cpp
M Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.h
M Source/WebKit/WebProcess/GPU/graphics/RemoteRenderingBackendProxy.cpp
M Source/WebKit/WebProcess/GPU/graphics/RemoteRenderingBackendProxy.h
M
Source/WebKit/WebProcess/GPU/graphics/RemoteRenderingBackendProxy.messages.in
M
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm
Log Message:
-----------
Cherry-pick d2f31696424a. rdar://problem/108642579
RemoteImageBufferProxyFlushState::waitForDidFlushOnSecondaryThread blocks
on a task running on the main thread.
https://bugs.webkit.org/show_bug.cgi?id=256073
<rdar://108642579>
Reviewed by Simon Fraser.
We attempt to wait for flushes of RemoteImageBufferProxy on a background
thread, but the 'didFlush' IPC message is received on the main thread.
This can mean it gets delayed (and we don't know the flush is completed) if
the main thread is otherwise busy. This delays first-paint on CPLT.
This change passes a Semphore across to the GPUP instead of the flush
identifier, and we signal it when the flush is completed rather than sending a
return 'didFlush' message.
The WebProcess waits on each flush Semaphore in a background WorkQueue, and
then processes the equivalent of 'didFlush' asynchronously and notifies the
condition variable to wake any waiting threads.
waitForDidFlushWithTimeout is removed, and all waiters now use the
waitForDidFlushOnSecondaryThread code path (renamed) since all waiters are now
'secondary' WRT the flushing WorkQueue.
Synchronous flushes now use a proper synchronous IPC message, rather than
relying on async + wait.
Adds a 0-delay asynchronous callOnMainThread hop when triggering the
rendering update from
RemoteLaterTreeDisplayRefreshMonitor::requestRefreshCallback.
It appears that when doing the first requestRefreshCallback after idle, we
currently just trigger a rendering update immediately, rather than waiting for
displayDidRefresh. This differs
from the non-GPUP code.
This 0-delay step makes our behaviour more similar to the old code, but
adding a proper displayDidRefresh wait would be preferable in the longer term.
* Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.cpp:
(WebKit::RemoteDisplayListRecorder::flushContext):
(WebKit::RemoteDisplayListRecorder::flushContextSync):
* Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.h:
* Source/WebKit/GPUProcess/graphics/RemoteDisplayListRecorder.messages.in:
* Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::RemoteRenderingBackend::didFlush): Deleted.
* Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.h:
* Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.cpp:
(WebKit::RemoteDisplayListRecorderProxy::sendSync):
(WebKit::RemoteDisplayListRecorderProxy::flushContext):
(WebKit::RemoteDisplayListRecorderProxy::flushContextSync):
* Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.h:
* Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.cpp:
(WebKit::RemoteImageBufferProxy::flushDrawingContext):
(WebKit::RemoteImageBufferProxy::flushDrawingContextAsync):
(WebKit::RemoteImageBufferProxyFlushState::waitForDidFlush):
(WebKit::RemoteImageBufferProxy::waitForDidFlushWithTimeout): Deleted.
(WebKit::RemoteImageBufferProxyFlushState::waitForDidFlushOnSecondaryThread):
Deleted.
* Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.h:
* Source/WebKit/WebProcess/GPU/graphics/RemoteRenderingBackendProxy.cpp:
(WebKit::RemoteRenderingBackendProxy::RemoteRenderingBackendProxy):
(WebKit::RemoteRenderingBackendProxy::disconnectGPUProcess):
(WebKit::RemoteRenderingBackendProxy::addPendingFlush):
(WebKit::RemoteRenderingBackendProxy::waitForDidFlush): Deleted.
(WebKit::RemoteRenderingBackendProxy::didFlush): Deleted.
* Source/WebKit/WebProcess/GPU/graphics/RemoteRenderingBackendProxy.h:
*
Source/WebKit/WebProcess/GPU/graphics/RemoteRenderingBackendProxy.messages.in:
*
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm:
(WebKit::RemoteLayerTreeDisplayRefreshMonitor::requestRefreshCallback):
Canonical link: https://commits.webkit.org/263993@main
Identifier: 263769.46@safari-7616.1.14.10-branch
Commit: d58a337ccefff1e901d1957f8c104256504c3940
https://github.com/WebKit/WebKit/commit/d58a337ccefff1e901d1957f8c104256504c3940
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2023-05-23 (Tue, 23 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.8
Identifier: 263769.47@safari-7616.1.14.10-branch
Commit: 04d12df4bf77a57e340abcd3c6ad4dfc5243ede5
https://github.com/WebKit/WebKit/commit/04d12df4bf77a57e340abcd3c6ad4dfc5243ede5
Author: Jer Noble <jer.no...@apple.com>
Date: 2023-05-24 (Wed, 24 May 2023)
Changed paths:
M Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm
Log Message:
-----------
Cherry-pick 0c7bb633923a. rdar://problem/109528876
[iOS] Auto-PiP on Yahoo.com may display black feed
https://bugs.webkit.org/show_bug.cgi?id=257059
rdar://109528876
Reviewed by Eric Carlson.
Auto-PiP (as opposed to an explicit PiP operation) works by creating a
empty WebAVPlayerLayerView,
and WebAVPlayerViewController, and returning YES from the
-playerViewControllerShouldStartPictureInPictureFromInlineWhenEnteringBackground:
delegate. However,
auto-PiP will transfer the video view from the empty WebAVPlayerLayerView
to the PiP window, and if
the empty view doesn't have a video view, the resulting PiP window will be
empty.
* Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm:
(VideoFullscreenInterfaceAVKit::doSetup):
Canonical link: https://commits.webkit.org/264307@main
Identifier: 262728.1089@safari-7616.1.14.10-branch
Commit: c8446e404ceb5d71b856412ff0a9bee80f7813d1
https://github.com/WebKit/WebKit/commit/c8446e404ceb5d71b856412ff0a9bee80f7813d1
Author: Russell Epstein <repst...@apple.com>
Date: 2023-05-24 (Wed, 24 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.8
Identifier: 262728.1090@safari-7616.1.14.10-branch
Commit: 645d9c0b8064c4ba437dda9efb28d90338b06232
https://github.com/WebKit/WebKit/commit/645d9c0b8064c4ba437dda9efb28d90338b06232
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2023-05-24 (Wed, 24 May 2023)
Changed paths:
A LayoutTests/fast/images/decode-decoding-change-image-src-expected.html
A LayoutTests/fast/images/decode-decoding-change-image-src.html
M LayoutTests/fast/images/decoding-attribute-async-small-image.html
M LayoutTests/fast/images/decoding-attribute-dynamic-async-small-image.html
M Source/WebCore/rendering/RenderBoxModelObject.cpp
Log Message:
-----------
Apply patch. rdar://problem/108930635
Identifier: 263769.50@safari-7616.1.14.10-branch
Commit: 0cc8a5f9a958a35aa9c45d58babd18b8034c9566
https://github.com/WebKit/WebKit/commit/0cc8a5f9a958a35aa9c45d58babd18b8034c9566
Author: Brent Fulgham <bfulg...@apple.com>
Date: 2023-05-24 (Wed, 24 May 2023)
Changed paths:
M Source/WebKit/GPUProcess/GPUProcess.cpp
M Source/WebKit/GPUProcess/GPUProcess.h
M Source/WebKit/GPUProcess/GPUProcess.messages.in
M Source/WebKit/GPUProcess/GPUProcessCreationParameters.cpp
M Source/WebKit/GPUProcess/GPUProcessCreationParameters.h
M Source/WebKit/UIProcess/Cocoa/GPUProcessProxyCocoa.mm
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit/UIProcess/GPU/GPUProcessProxy.cpp
M Source/WebKit/UIProcess/GPU/GPUProcessProxy.h
Log Message:
-----------
Cherry-pick 20d3e87d7269. rdar://problem/107631614
[Cocoa] Extend access to the 'com.apple.gputools.service' mach service if
Web Inspector is enabled
https://bugs.webkit.org/show_bug.cgi?id=256673
<rdar://107631614>
Reviewed by Per Arne Vollan.
Access to the `com.apple.gputools.service` mach service is denied to the
GPU Process.
Unfortunately, some developer diagnostic tools for graphics investigation
need this
access to work.
We should have the UI Process extend permission for the GPU Process to talk
to relevant
services when the Web Inspector has been enabled.
* Source/WebKit/GPUProcess/GPUProcess.cpp:
(WebKit::GPUProcess::initializeGPUProcess): Consume the GPU tools
extensions if present.
(WebKit::GPUProcess::updateSandboxAccess): Move outside the MEDIA_SESSION
enablement macro
so we can use it for WebInspector purposes.
* Source/WebKit/GPUProcess/GPUProcess.h:
* Source/WebKit/GPUProcess/GPUProcess.messages.in: Ditto.
* Source/WebKit/GPUProcess/GPUProcessCreationParameters.cpp:
(WebKit::GPUProcessCreationParameters::encode const): Update for additional
sandbox extensions.
(WebKit::GPUProcessCreationParameters::decode): Ditto.
* Source/WebKit/GPUProcess/GPUProcessCreationParameters.h:
* Source/WebKit/UIProcess/Cocoa/GPUProcessProxyCocoa.mm:
(WebKit::GPUProcessProxy::platformInitializeGPUProcessParameters): Add GPU
tools extensions to
process launch parameters if needed.
(WebKit::GPUProcessProxy::createGPUToolsSandboxExtensionHandlesIfNeeded):
Added.
* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::platformInitializeWebProcess): Extend GPU tools
extensions to the GPU
process if they haven't been sent before, but the WebInspector is now
enabled.
* Source/WebKit/UIProcess/GPU/GPUProcessProxy.cpp:
(WebKit::GPUProcessProxy::GPUProcessProxy):
* Source/WebKit/UIProcess/GPU/GPUProcessProxy.h:
Canonical link: https://commits.webkit.org/264029@main
Identifier: 263769.51@safari-7616.1.14.10-branch
Commit: 835f87755a7f426c0466686af51bf08015487155
https://github.com/WebKit/WebKit/commit/835f87755a7f426c0466686af51bf08015487155
Author: Brent Fulgham <bfulg...@apple.com>
Date: 2023-05-24 (Wed, 24 May 2023)
Changed paths:
M Source/WebKit/GPUProcess/GPUProcess.cpp
M Source/WebKit/GPUProcess/cocoa/GPUProcessCocoa.mm
Log Message:
-----------
Cherry-pick fe4af8b17fb6. rdar://problem/109380900
[Cocoa] Call [AVCaptureDevice ensureServerConnection] when new extensions
are made to the GPU Process
https://bugs.webkit.org/show_bug.cgi?id=257241
<rdar://109380900>
Reviewed by Eric Carlson.
Our current code only calls [AVCaptureDevice ensureServerConnection] the
first time we extend the sandbox.
This can lead to problems if the user visits a site that only needs
Microphone access (for example), and
then visits a site that needs Camera access. Because the camera-related
extensions are only recognized by
the video capture system when [AVCaptureDevice ensureServiceConnection] is
called, the fact that we called
it before the new sandbox extensions were in place mean we never activate
the relevant features.
To fix this, we should simply call [AVCaptureDevice ensureServerConnection]
any time we extend the sandbox.
I have confirmed with the relevant teams that this call is low-cost
(performance wise), and is not harmful
to call repeatedly for things that have already been activated.
This patch also adds new logging to help debug similar problems in the
future.
* Source/WebKit/GPUProcess/GPUProcess.cpp:
(WebKit::GPUProcess::updateSandboxAccess): Add logging.
(WebKit::GPUProcess::updateCaptureAccess): Ditto.
* Source/WebKit/GPUProcess/cocoa/GPUProcessCocoa.mm:
(WebKit::GPUProcess::ensureAVCaptureServerConnection): Add new logging, no
longer make this a 'std::call_once'.
Canonical link: https://commits.webkit.org/264460@main
Identifier: 263769.52@safari-7616.1.14.10-branch
Commit: 042a2b78092aa533dbdcae79cb6ad51e1d4fe9d2
https://github.com/WebKit/WebKit/commit/042a2b78092aa533dbdcae79cb6ad51e1d4fe9d2
Author: J Pascoe <j_pas...@apple.com>
Date: 2023-05-24 (Wed, 24 May 2023)
Changed paths:
M Source/WebKit/UIProcess/WebAuthentication/Cocoa/CcidService.h
M Source/WebKit/UIProcess/WebAuthentication/Cocoa/CcidService.mm
Log Message:
-----------
Cherry-pick 52e6f05d3e91. rdar://problem/109060751
[WebAuthn] Clean up observers in CcidService
https://bugs.webkit.org/show_bug.cgi?id=257240
rdar://109060751
Reviewed by Brent Fulgham.
This change ensures removeObserver:forKeyPath: is called for each observer
we
add via addObserver in CcidService.
* Source/WebKit/UIProcess/WebAuthentication/Cocoa/CcidService.h:
* Source/WebKit/UIProcess/WebAuthentication/Cocoa/CcidService.mm:
(WebKit::CcidService::~CcidService):
(WebKit::CcidService::removeObservers):
(WebKit::CcidService::platformStartDiscovery):
(WebKit::CcidService::updateSlots):
(-[_WKSmartCardSlotStateObserver
observeValueForKeyPath:ofObject:change:context:]):
(-[_WKSmartCardSlotStateObserver removeObserver]):
Canonical link: https://commits.webkit.org/264485@main
Identifier: 263769.53@safari-7616.1.14.10-branch
Commit: 5c1e0cc622259fbba9afb8641f378e7dd6ef0ce1
https://github.com/WebKit/WebKit/commit/5c1e0cc622259fbba9afb8641f378e7dd6ef0ce1
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2023-05-24 (Wed, 24 May 2023)
Changed paths:
M Source/WebKit/GPUProcess/GPUProcess.cpp
M Source/WebKit/GPUProcess/cocoa/GPUProcessCocoa.mm
Log Message:
-----------
Revert "Cherry-pick fe4af8b17fb6. rdar://problem/109380900"
This reverts commit 835f87755a7f426c0466686af51bf08015487155.
Identifier: 263769.54@safari-7616.1.14.10-branch
Commit: 0ba620bea6e184f92865472d6ef69f7086f7b23b
https://github.com/WebKit/WebKit/commit/0ba620bea6e184f92865472d6ef69f7086f7b23b
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2023-05-24 (Wed, 24 May 2023)
Changed paths:
M Source/WebKit/GPUProcess/GPUProcess.cpp
M Source/WebKit/GPUProcess/GPUProcess.h
M Source/WebKit/GPUProcess/GPUProcess.messages.in
M Source/WebKit/GPUProcess/GPUProcessCreationParameters.cpp
M Source/WebKit/GPUProcess/GPUProcessCreationParameters.h
M Source/WebKit/UIProcess/Cocoa/GPUProcessProxyCocoa.mm
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit/UIProcess/GPU/GPUProcessProxy.cpp
M Source/WebKit/UIProcess/GPU/GPUProcessProxy.h
Log Message:
-----------
Revert "Cherry-pick 20d3e87d7269. rdar://problem/107631614"
This reverts commit 0cc8a5f9a958a35aa9c45d58babd18b8034c9566.
Identifier: 263769.55@safari-7616.1.14.10-branch
Commit: 67f23c4f71fe18a56c29f4088b6ce469f9b3160b
https://github.com/WebKit/WebKit/commit/67f23c4f71fe18a56c29f4088b6ce469f9b3160b
Author: Russell Epstein <repst...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.9
Identifier: 262728.1097@safari-7616.1.14.10-branch
Commit: 723517a531bdfc0f82a93def21fc59b7129c9a53
https://github.com/WebKit/WebKit/commit/723517a531bdfc0f82a93def21fc59b7129c9a53
Author: Kimmo Kinnunen <kkinnu...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/WebCore/platform/ScrollbarsController.h
M Source/WebCore/platform/graphics/cocoa/IOSurface.h
M Source/WebCore/platform/graphics/cocoa/IOSurface.mm
M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.cpp
A
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBitmapBackend.cpp
A
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBitmapBackend.h
M
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollbarsController.h
Log Message:
-----------
Cherry-pick b9e5b9ff4fe9. rdar://problem/106651668
Cocoa Small RemoteLayerBackingStores should be drawn with software
https://bugs.webkit.org/show_bug.cgi?id=253447
rdar://problem/106651668
Reviewed by Simon Fraser.
Add a specific GPUP side backend for ImageBitmaps used for LayerBacking
purposes, e.g. RemoteLayerBackingStore buffers. The buffers are drawn
to with software rasterization.
Fixes a bug in RemoteDisplayListRecorderProxy::createImageBuffer where
intermediate ImageBuffers for filters would be created as Layer
rendering purpose, where as the Layer purpose is supposed to be only
for the Layer backing stores.
Fixes a bug in RenderingPurpose where missing ShareableLocalSnapshot
was not part of the enum serialization, making the serialization
incorrect.
* Source/WebCore/platform/ScrollbarsController.h:
* Source/WebCore/platform/graphics/cocoa/IOSurface.h:
* Source/WebCore/platform/graphics/cocoa/IOSurface.mm:
(WebCore::IOSurface::createBitmapPlatformContext):
* Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::isSmallLayerBacking):
(WebKit::RemoteRenderingBackend::createImageBufferWithQualifiedIdentifier):
(WebKit::RemoteRenderingBackend::prepareLayerBuffersForDisplay):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.cpp:
(WebKit::RemoteDisplayListRecorderProxy::createImageBuffer const):
*
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBitmapBackend.cpp:
Added.
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::create):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::ImageBufferShareableMappedIOSurfaceBitmapBackend):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::createBackendHandle
const):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::context):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::setOwnershipIdentity):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::backendSize
const):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::bytesPerRow
const):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::copyNativeImage):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::copyNativeImageForDrawing):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::sinkIntoNativeImage):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::isInUse const):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::releaseGraphicsContext):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::setVolatile):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::setNonVolatile):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::volatilityState
const):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::setVolatilityState):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::transferToNewContext):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::getPixelBuffer):
(WebKit::ImageBufferShareableMappedIOSurfaceBitmapBackend::putPixelBuffer):
*
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBitmapBackend.h:
Added.
*
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollbarsController.h:
Canonical link: https://commits.webkit.org/264004@main
Identifier: 262728.1098@safari-7616.1.14.10-branch
Commit: b9dabf6ac3b91d32a7ed58cdd7a0b258bbb63224
https://github.com/WebKit/WebKit/commit/b9dabf6ac3b91d32a7ed58cdd7a0b258bbb63224
Author: Matthew Finkel <sys...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/WebCore/html/CanvasBase.cpp
Log Message:
-----------
Cherry-pick 1212e9728215. rdar://problem/109318643
Ensure we have an image buffer before considering Canvas noise
https://bugs.webkit.org/show_bug.cgi?id=257143
rdar://109318643
Reviewed by Matt Woodrow.
If we don't have a ImageBuffer, then we don't have a canvas that needs
post-processing. We can shortcircuit this path by checking if the image
buffer
is present.
* Source/WebCore/html/CanvasBase.cpp:
(WebCore::CanvasBase::shouldInjectNoiseBeforeReadback const):
Canonical link: https://commits.webkit.org/264427@main
Identifier: 263769.58@safari-7616.1.14.10-branch
Commit: 6ddbb89bf57125c8c6c33594892485d2e7119fd9
https://github.com/WebKit/WebKit/commit/6ddbb89bf57125c8c6c33594892485d2e7119fd9
Author: Myah Cobbs <mco...@apple.com>
Date: 2023-05-25 (Thu, 25 May 2023)
Changed paths:
M Source/WebCore/platform/ScrollbarsController.h
M Source/WebCore/platform/graphics/cocoa/IOSurface.h
M Source/WebCore/platform/graphics/cocoa/IOSurface.mm
M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.cpp
R
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBitmapBackend.cpp
R
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBitmapBackend.h
M
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollbarsController.h
Log Message:
-----------
Revert Cherry-pick rdar://106651668 (MotionMark marketing benchmark regressed
3% (Cocoa Small RemoteLayerBackingStores should be drawn with software
(253447)))
* Source/WebCore/platform/ScrollbarsController.h:
* Source/WebCore/platform/graphics/cocoa/IOSurface.h:
* Source/WebCore/platform/graphics/cocoa/IOSurface.mm:
(WebCore::IOSurface::createBitmapPlatformContext): Deleted.
* Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::RemoteRenderingBackend::createImageBufferWithQualifiedIdentifier):
(WebKit::RemoteRenderingBackend::prepareLayerBuffersForDisplay):
(WebKit::isSmallLayerBacking): Deleted.
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.cpp:
(WebKit::RemoteDisplayListRecorderProxy::createImageBuffer const):
*
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBitmapBackend.cpp:
Removed.
*
Source/WebKit/WebProcess/GPU/graphics/cocoa/ImageBufferShareableMappedIOSurfaceBitmapBackend.h:
Removed.
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollbarsController.h:
Identifier: 263769.59@safari-7616.1.14.10-branch
Commit: e425ec5b722931bfbfda91d9f52733152fbc4284
https://github.com/WebKit/WebKit/commit/e425ec5b722931bfbfda91d9f52733152fbc4284
Author: Myah Cobbs <mco...@apple.com>
Date: 2023-05-26 (Fri, 26 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.10
Identifier: 263769.60@safari-7616.1.14.10-branch
Commit: cb082b2e116b3103fd1a99e26ffc827f135dd509
https://github.com/WebKit/WebKit/commit/cb082b2e116b3103fd1a99e26ffc827f135dd509
Author: Brent Fulgham <bfulg...@apple.com>
Date: 2023-05-26 (Fri, 26 May 2023)
Changed paths:
M Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.GPU.sb.in
Log Message:
-----------
Cherry-pick 21a4b1c5559f. rdar://problem/109409569
[iOS] REGRESSION (264028@main): Memory regression
https://bugs.webkit.org/show_bug.cgi?id=257126
<rdar://109409569>
Reviewed by Per Arne Vollan.
Relaxing the iOS GPU Process Sandbox in Bug 256728 had the unintended
effect of increasing memory use. Since blocking this call didn't create any
functional issues, but regressed memory, we will instead silence the logging to
avoid flooding telemetry with irrelevant logging.
* Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.GPU.sb.in:
Canonical link: https://commits.webkit.org/264386@main
Identifier: 263769.61@safari-7616.1.14.10-branch
Commit: 1cd2f18593f45e6d812afbf40042e03de29dd545
https://github.com/WebKit/WebKit/commit/1cd2f18593f45e6d812afbf40042e03de29dd545
Author: Myah Cobbs <mco...@apple.com>
Date: 2023-05-31 (Wed, 31 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.11
Identifier: 263319.512@safari-7616.1.14.10-branch
Commit: 238d8991db20c6ce660ca5aa56d0569469c6500e
https://github.com/WebKit/WebKit/commit/238d8991db20c6ce660ca5aa56d0569469c6500e
Author: Per Arne Vollan <pvol...@apple.com>
Date: 2023-05-31 (Wed, 31 May 2023)
Changed paths:
M
Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in
Log Message:
-----------
Cherry-pick 46d0ad25749c. rdar://problem/109916897
Fix syscall sandbox violations in Lockdown Mode
https://bugs.webkit.org/show_bug.cgi?id=257542
rdar://109916897
Reviewed by Brent Fulgham and Chris Dumez.
Fix syscall sandbox violations in Lockdown Mode in the WebContent process
on iOS.
These have been identified from telemetry and local reports.
*
Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in:
Canonical link: https://commits.webkit.org/264743@main
Identifier: 263319.513@safari-7616.1.14.10-branch
Commit: 1484f73a1aad72dca500cdb222d55820134e470c
https://github.com/WebKit/WebKit/commit/1484f73a1aad72dca500cdb222d55820134e470c
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2023-05-31 (Wed, 31 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.14.10.12
Identifier: 263769.64@safari-7616.1.14.10-branch
Commit: 778737e5c78b604d21e9158f14846d627a63e4dd
https://github.com/WebKit/WebKit/commit/778737e5c78b604d21e9158f14846d627a63e4dd
Author: Dan Robson <dtr_bugzi...@apple.com>
Date: 2023-05-31 (Wed, 31 May 2023)
Changed paths:
M Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.GPU.sb.in
Log Message:
-----------
Revert "Cherry-pick 21a4b1c5559f. rdar://problem/109409569"
This reverts commit cb082b2e116b3103fd1a99e26ffc827f135dd509.
Identifier: 263769.65@safari-7616.1.14.10-branch
Compare: https://github.com/WebKit/WebKit/compare/47212f0dff65%5E...778737e5c78b
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
