[webkit-changes] [WebKit/WebKit] 8f58d3: [Grid] Plumb GridLayoutState through GridTrackSizi...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8f58d37f11a9e7e5556eb1c4bbd523cc956db99f
  
https://github.com/WebKit/WebKit/commit/8f58d37f11a9e7e5556eb1c4bbd523cc956db99f
  Author: Sammy Gill 
  Date:   2024-08-01 (Thu, 01 Aug 2024)

  Changed paths:
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.h
M Source/WebCore/rendering/RenderGrid.cpp

  Log Message:
  ---
  [Grid] Plumb GridLayoutState through GridTrackSizingAlgorithm
https://bugs.webkit.org/show_bug.cgi?id=277449
rdar://132930737

Reviewed by Alan Baradlay and Tim Nguyen.

GridLayoutState is supposed to be a stack based helper class that helps
hold onto information that is only needed during layout. This is to
avoid tossing state onto the renderer or other long lived objects and
risk having stale state which could result in the form of bugs. In
the initial implementation I ended up having GridTrackSizingAlgorithm
hold onto this state with a WeakPtr and guarded it using a CheckedRef.
This is wrong and instead we should plumb it throughout
GridTrackSizingAlgorithm so that it can access it wherever it is needed.

* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::sizeTrackToFitNonSpanningItem):
(WebCore::GridTrackSizingAlgorithm::itemSizeForTrackSizeComputationPhase const):
(WebCore::GridTrackSizingAlgorithm::increaseSizesToAccommodateSpanningItems):
(WebCore::GridTrackSizingAlgorithmStrategy::logicalHeightForGridItem const):
(WebCore::GridTrackSizingAlgorithmStrategy::minContentForGridItem const):
(WebCore::GridTrackSizingAlgorithmStrategy::maxContentForGridItem const):
(WebCore::GridTrackSizingAlgorithmStrategy::minSizeForGridItem const):
(WebCore::IndefiniteSizeStrategy::accumulateFlexFraction const):
(WebCore::IndefiniteSizeStrategy::findUsedFlexFraction const):
(WebCore::DefiniteSizeStrategy::findUsedFlexFraction const):
(WebCore::DefiniteSizeStrategy::minContentForGridItem const):
(WebCore::GridTrackSizingAlgorithm::accumulateIntrinsicSizesForTrack):
(WebCore::GridTrackSizingAlgorithm::accumulateIntrinsicSizesForTrackMasonry):
(WebCore::GridTrackSizingAlgorithm::computeIndefiniteItemsForMasonry const):
(WebCore::GridTrackSizingAlgorithm::resolveIntrinsicTrackSizes):
(WebCore::GridTrackSizingAlgorithm::resolveIntrinsicTrackSizesMasonry):
(WebCore::GridTrackSizingAlgorithm::stretchFlexibleTracks):
(WebCore::GridTrackSizingAlgorithm::setup):
(WebCore::GridTrackSizingAlgorithm::run):
* Source/WebCore/rendering/GridTrackSizingAlgorithm.h:
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::computeTrackSizesForDefiniteSize):
(WebCore::RenderGrid::layoutGrid):
(WebCore::RenderGrid::computeTrackSizesForIndefiniteSize const):

Canonical link: https://commits.webkit.org/281711@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] bf6d6e: [Grid][Overflow] Start considering grid areas in l...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: bf6d6e8f80af5c5c99fb3481e55903be90ab688a
  
https://github.com/WebKit/WebKit/commit/bf6d6e8f80af5c5c99fb3481e55903be90ab688a
  Author: Sammy Gill 
  Date:   2024-07-30 (Tue, 30 Jul 2024)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-overflow/scrollable-overflow-zero-one-axis-expected.txt
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderGrid.h

  Log Message:
  ---
  [Grid][Overflow] Start considering grid areas in layout overflow.
https://bugs.webkit.org/show_bug.cgi?id=260292
rdar://113985286

Reviewed by Alan Baradlay.

The grid area, which is composed of the rows and columns, can
potentially overflow the grid container itself even if the grid does
not have any grid items or none of the grid items overflow the grid.

We can let RenderGrid override computeOverflow in order to determine
if the grid area is overflowing in either dimension. This is done by
consulting the position of the last column and row line, which are
offsets within the border box of the grid, to determine the bounds of
the grid area, and passing it off to addLayoutOverflow to potentially
expand the bounds of the overflow rect.

* LayoutTests/imported/w3c/web-platform-
* Source/WebCore/rendering/RenderGrid.cp
(WebCore::RenderGrid::computeOverflow):# Please populate the above commit 
message. Lines starting
* Source/WebCore/rendering/RenderGrid.h:

Canonical link: https://commits.webkit.org/281594@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 7442ff: [Grid][Replaced] flydenver.com: Images of airlines...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7442fff8d8744bcd2eb94face4ed371fae927c21
  
https://github.com/WebKit/WebKit/commit/7442fff8d8744bcd2eb94face4ed371fae927c21
  Author: Sammy Gill 
  Date:   2024-07-25 (Thu, 25 Jul 2024)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-in-table-cell-with-img-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-in-table-cell-with-img.html
M Source/WebCore/rendering/RenderBox.cpp

  Log Message:
  ---
  [Grid][Replaced] flydenver.com: Images of airlines logos have incorrect sizes.
https://bugs.webkit.org/show_bug.cgi?id=277086
rdar://132105152

Reviewed by Alan Baradlay.

A grid item's containing block is defined by its grid area. Once the
grid track sizing algorithm is done the size of this area becomes
definite and grid expresses this by setting the overriding containing
block dimensions of the grid item.

So in computeReplacedLogicalHeightUsing we should check to see if these
values are set for grid items and use them to resolve percent or
calculated logical heights.

Otherwise, we would would end up falling back to some logic that walks
up the containing block chain and could end up using the intrinsic
logical height of the image in certain scenarios which does not seem
correct for grid items.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-in-table-cell-with-img-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-in-table-cell-with-img.html:
 Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::computeReplacedLogicalHeightUsing const):

Canonical link: https://commits.webkit.org/281378@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3d47cc: [Grid] Rename child/children references to gridIte...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3d47cc57612d6c856089aa3dfb6cdb9dd598e538
  
https://github.com/WebKit/WebKit/commit/3d47cc57612d6c856089aa3dfb6cdb9dd598e538
  Author: Sammy Gill 
  Date:   2024-07-24 (Wed, 24 Jul 2024)

  Changed paths:
M Source/WebCore/rendering/AncestorSubgridIterator.cpp
M Source/WebCore/rendering/Grid.cpp
M Source/WebCore/rendering/Grid.h
M Source/WebCore/rendering/GridBaselineAlignment.cpp
M Source/WebCore/rendering/GridBaselineAlignment.h
M Source/WebCore/rendering/GridLayoutFunctions.cpp
M Source/WebCore/rendering/GridLayoutFunctions.h
M Source/WebCore/rendering/GridMasonryLayout.cpp
M Source/WebCore/rendering/GridMasonryLayout.h
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.h
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderGrid.h
M Source/WebCore/rendering/style/GridPositionsResolver.cpp

  Log Message:
  ---
  [Grid] Rename child/children references to gridItem/gridItems.
https://bugs.webkit.org/show_bug.cgi?id=276978
rdar://problem/132364014

Reviewed by Alan Baradlay.

These renderers participate in grid layout and are grid items so
renaming them to such in the code makes it more consistent with the
spec and easier to read. There are some instances that are used as part
of generic render tree logic and not specifially grid layout which I
left alone.

There were also a couple of instances of "childIterator" in the
grid track sizing algorithm that I changed to "subgridIterator,"" since
that's what they are.

* Source/WebCore/rendering/AncestorSubgridIterator.cpp:
(WebCore::AncestorSubgridIterator::operator++):
* Source/WebCore/rendering/Grid.cpp:
(WebCore::Grid::insert):
(WebCore::GridIterator::GridIterator):
(WebCore::GridIterator::nextGridItem):
(WebCore::GridIterator::isEmptyAreaEnough const):
(WebCore::GridIterator::createForSubgrid):
* Source/WebCore/rendering/Grid.h:
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::logicalAscentForGridItem const):
(WebCore::GridBaselineAlignment::ascentForGridItem const):
(WebCore::GridBaselineAlignment::descentForGridItem const):
(WebCore::GridBaselineAlignment::isDescentBaselineForGridItem const):
(WebCore::GridBaselineAlignment::isOrthogonalGridItemForBaseline const):
(WebCore::GridBaselineAlignment::isParallelToAlignmentAxisForGridItem const):
(WebCore::GridBaselineAlignment::baselineGroupForGridItem const):
(WebCore::GridBaselineAlignment::updateBaselineAlignmentContext):
(WebCore::GridBaselineAlignment::baselineOffsetForGridItem const):
(WebCore::GridBaselineAlignment::logicalAscentForChild const): Deleted.
(WebCore::GridBaselineAlignment::ascentForChild const): Deleted.
(WebCore::GridBaselineAlignment::descentForChild const): Deleted.
(WebCore::GridBaselineAlignment::isDescentBaselineForChild const): Deleted.
(WebCore::GridBaselineAlignment::isOrthogonalChildForBaseline const): Deleted.
(WebCore::GridBaselineAlignment::isParallelToAlignmentAxisForChild const): 
Deleted.
(WebCore::GridBaselineAlignment::baselineGroupForChild const): Deleted.
(WebCore::GridBaselineAlignment::baselineOffsetForChild const): Deleted.
* Source/WebCore/rendering/GridBaselineAlignment.h:
* Source/WebCore/rendering/GridLayoutFunctions.cpp:
(WebCore::GridLayoutFunctions::marginStartIsAuto):
(WebCore::GridLayoutFunctions::marginEndIsAuto):
(WebCore::GridLayoutFunctions::gridItemHasMargin):
(WebCore::GridLayoutFunctions::computeMarginLogicalSizeForGridItem):
(WebCore::GridLayoutFunctions::hasRelativeOrIntrinsicSizeForGridItem):
(WebCore::GridLayoutFunctions::extraMarginForSubgrid):
(WebCore::GridLayoutFunctions::extraMarginForSubgridAncestors):
(WebCore::GridLayoutFunctions::marginLogicalSizeForGridItem):
(WebCore::GridLayoutFunctions::isOrthogonalGridItem):
(WebCore::GridLayoutFunctions::isAspectRatioBlockSizeDependentGridItem):
(WebCore::GridLayoutFunctions::flowAwareDirectionForGridItem):
(WebCore::GridLayoutFunctions::overridingContainingBlockContentSizeForGridItem):
(WebCore::GridLayoutFunctions::isSubgridReversedDirection):
(WebCore::GridLayoutFunctions::childHasMargin): Deleted.
(WebCore::GridLayoutFunctions::computeMarginLogicalSizeForChild): Deleted.
(WebCore::GridLayoutFunctions::hasRelativeOrIntrinsicSizeForChild): Deleted.
(WebCore::GridLayoutFunctions::marginLogicalSizeForChild): Deleted.
(WebCore::GridLayoutFunctions::isOrthogonalChild): Deleted.
(WebCore::GridLayoutFunctions::isAspectRatioBlockSizeDependentChild): Deleted.
(WebCore::GridLayoutFunctions::flowAwareDirectionForChild): Deleted.
(WebCore::GridLayoutFunctions::overridingContainingBlockContentSizeForChild): 
Deleted.
* Source/WebCore/rendering/GridLayoutFunctions.h:
* Source/WebCore/rendering/GridMasonryLayout.cpp:
(WebCore::GridMasonryLayout::collectMasonryItems):
(WebCore::GridMasonryLayout::placeItemsUsingOrderModifie

[webkit-changes] [WebKit/WebKit] 8ffc33: [Grid][Cleanup] Factor out some logic used in intr...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8ffc3352b0699dc3457f2cff6b0154879c48247f
  
https://github.com/WebKit/WebKit/commit/8ffc3352b0699dc3457f2cff6b0154879c48247f
  Author: Sammy Gill 
  Date:   2024-07-19 (Fri, 19 Jul 2024)

  Changed paths:
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.h

  Log Message:
  ---
  [Grid][Cleanup] Factor out some logic used in intrinsic track sizing to 
standalone functions
https://bugs.webkit.org/show_bug.cgi?id=276798
rdar://132040421

Reviewed by Ryan Reno.

This is an initial patch aimed to help slightly improve the readability
of the intrinsic track sizing logic by first moving some logic into
their own standalone functions. I think we can continue to improve the
code in this area but this is just a first step.

1.) Change extraMarginFromSubgridAncestorGutters in
accumulateIntrinsicSizesForTrack from being a lambda to a static function.

2.) Move the logic in accumulateIntrinsicSizesForTrack that determines
whether we should consider an item for sizing in this track for masonry
to shouldExcludeGridItemForMasonryTrackSizing

3.) Change the computeIndefiniteItems lambda in resolveIntrinsicTrackSizes
to a standalone method and renamed it to computeIndefiniteItemsForMasonry
to help distinguish it is for masonry layout.

* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::extraMarginFromSubgridAncestorGutters):
(WebCore::GridTrackSizingAlgorithm::shouldExcludeGridItemForMasonryTrackSizing 
const):
(WebCore::GridTrackSizingAlgorithm::accumulateIntrinsicSizesForTrack):
(WebCore::GridTrackSizingAlgorithm::computeIndefiniteItemsForMasonry const):
(WebCore::GridTrackSizingAlgorithm::resolveIntrinsicTrackSizes):
* Source/WebCore/rendering/GridTrackSizingAlgorithm.h:

Canonical link: https://commits.webkit.org/281141@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 364adc: [css-grid] Add LayoutRequirement to indicate when ...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 364adc3b7d9e55c7947b770c1a95f435d002b988
  
https://github.com/WebKit/WebKit/commit/364adc3b7d9e55c7947b770c1a95f435d002b988
  Author: Sammy Gill 
  Date:   2024-07-18 (Thu, 18 Jul 2024)

  Changed paths:
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
A Source/WebCore/rendering/GridLayoutState.h
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.h
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderGrid.h

  Log Message:
  ---
  [css-grid] Add LayoutRequirement to indicate when a grid item needs 
stretching in column axis.
https://bugs.webkit.org/show_bug.cgi?id=276609
rdar://problem/131751762

Reviewed by Alan Baradlay.

Currently grid will invalidate an item before stretching its block
size in one of the following scenarios

1.) Its current block size is not the stretched size
2.) It has percent height descendants

Let's try to limit 2 when we stretch in the column axis. This is done
by adding a new bit via LayoutRequirements to indicate when this should
be done.

There are two different scenarios in which we will currently set this
bit.

The first opportunity to set this bit is by checking damaged grid items
before we perform grid layout. If we find a damaged grid item,
then we will check if it needs to be stretched in the column axis by
checking its style.

The second time we may need to set this bit is during the grid track
sizing algorithm in GridTrackSizingAlgorithmStrategy::logicalHeightForChild.
Here we may clear any overriding sizes, mark the renderer as dirty, and
perform layout on it. If an item was previously stretched here then we
will lose its stretched size after this. If this is the case then we
will attempt to set the new bit if the item's style requires stretching.

Later on when we get to the stretch alignment logic, then we will check
to see if this bit is set when stretching an item in the column axis and
its block axis is in the same direction. In other cases we will fall
back to the original logic.

In order to accomplish this I added GridLayoutState, which is a new
helper class that should help keep track of extra layout related
information as we perform grid layout. This is a stack based class so
it will be created at the beginning of layout and destroyed at the end.

* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/rendering/GridLayoutState.h: Added.
(WebCore::GridLayoutState::itemsLayoutRequirements):
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithmStrategy::logicalHeightForChild const):
(WebCore::GridTrackSizingAlgorithm::setup):
* Source/WebCore/rendering/GridTrackSizingAlgorithm.h:
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::computeTrackSizesForDefiniteSize):
(WebCore::RenderGrid::repeatTracksSizingIfNeeded):
(WebCore::RenderGrid::canSetColumnAxisStretchRequirementForItem const):
(WebCore::RenderGrid::computeLayoutRequirementsForItemsBeforeLayout const):
(WebCore::RenderGrid::layoutGrid):
(WebCore::RenderGrid::layoutMasonry):
(WebCore::RenderGrid::computeIntrinsicLogicalWidths const):
(WebCore::RenderGrid::computeTrackSizesForIndefiniteSize const):
(WebCore::RenderGrid::updateGridAreaForAspectRatioItems):
(WebCore::RenderGrid::layoutGridItems):
(WebCore::RenderGrid::layoutMasonryItems):
(WebCore::RenderGrid::applyStretchAlignmentToChildIfNeeded):
* Source/WebCore/rendering/RenderGrid.h:

Canonical link: https://commits.webkit.org/281090@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6a18e3: [Flex] Rename layoutFlexItems to performFlexLayout

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6a18e32fbbfc5f8a404f102665d6e6a6263b9048
  
https://github.com/WebKit/WebKit/commit/6a18e32fbbfc5f8a404f102665d6e6a6263b9048
  Author: Sammy Gill 
  Date:   2024-07-16 (Tue, 16 Jul 2024)

  Changed paths:
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h

  Log Message:
  ---
  [Flex] Rename layoutFlexItems to performFlexLayout
https://bugs.webkit.org/show_bug.cgi?id=276669
rdar://131855250

Reviewed by Alan Baradlay.

We currently have layoutFlexItems and
layoutAndPlaceFlexItems. Let's rename layoutFlexItems
to performFlexLayout as it encapsulates all of the
flex layout logic.

* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::layoutBlock):
(WebCore::RenderFlexibleBox::performFlexLayout):
(WebCore::RenderFlexibleBox::layoutFlexItems): Deleted.
* Source/WebCore/rendering/RenderFlexibleBox.h:

Canonical link: https://commits.webkit.org/281021@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] fc1751: [UnifiedPDF] Cannot zoom out on certain large docu...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: fc175103f7d8716147c3cb41ea4066e84f51b08a
  
https://github.com/WebKit/WebKit/commit/fc175103f7d8716147c3cb41ea4066e84f51b08a
  Author: Sammy Gill 
  Date:   2024-06-03 (Mon, 03 Jun 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Cannot zoom out on certain large documents
https://bugs.webkit.org/show_bug.cgi?id=275072
rdar://128915788

Reviewed by Simon Fraser.

Some clients may have a lower and upper bounds in which they restrict
their page scales. In certain circumstances we may compute a normalized
scale factor which ends up being below the upper bound. It appears that
this can occur frequently in large documents because we compute a
"large," scale for the actual size and end up computing a "small,"
normalization factor. This is what ends up happening if you open the PDF
in the bugzilla with Minibrowser. To limit this pathological behavior
with the increased document size let's make sure that when we compute
the normalization scale factor it is relative to the actual size scale.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::computeNormalizationFactor):

Canonical link: https://commits.webkit.org/279688@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b7d0e2: [UnifiedPDF] Select element for choice annotations...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b7d0e2efd37914f2c13e5a148dc3213386ac3bc6
  
https://github.com/WebKit/WebKit/commit/b7d0e2efd37914f2c13e5a148dc3213386ac3bc6
  Author: Sammy Gill 
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
M Source/WebKit/Shared/WebHitTestResultData.cpp
M Source/WebKit/Shared/WebHitTestResultData.h
M Source/WebKit/Shared/WebHitTestResultData.serialization.in
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm

  Log Message:
  ---
  [UnifiedPDF] Select element for choice annotations will sometimes flicker
https://bugs.webkit.org/show_bug.cgi?id=274634
rdar://128406464

Reviewed by Abrar Rahman Protyasha.

The choice annotation has a HTML select element backing it for user
interaction. Sometimes clicking on the choice annotation while the
corresponding HTML element is already active will result in the
element disappearing and reappearing resulting in a flicker. It appears
this is due to the logic in WebPageMac::performImmediateActionHitTestAtLocation
taking focus away from the HTML element and giving it to the plugin
document.

To fix this let the plugin note that the the hit test is over an already
active annotation via WebHitTestResultData. If this is the case then
we will not focus the plugin document and keep the focus on the
HTML annotation.

* Source/WebKit/Shared/WebHitTestResultData.cpp:
(WebKit::WebHitTestResultData::WebHitTestResultData):
* Source/WebKit/Shared/WebHitTestResultData.h:
* Source/WebKit/Shared/WebHitTestResultData.serialization.in:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::textForImmediateActionHitTestAtPoint):
* Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm:
(WebKit::WebPage::performImmediateActionHitTestAtLocation):

Canonical link: https://commits.webkit.org/279381@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 17182b: [UnifiedPDF] Going from continuous to discrete lay...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 17182bac125549892aa4d01a30e3c35b22b2f5df
  
https://github.com/WebKit/WebKit/commit/17182bac125549892aa4d01a30e3c35b22b2f5df
  Author: Sammy Gill 
  Date:   2024-05-06 (Mon, 06 May 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Going from continuous to discrete layout modes lands the user in 
a different page number.
https://bugs.webkit.org/show_bug.cgi?id=273779
rdar://127445845

Reviewed by Abrar Rahman Protyasha and Simon Fraser.

In order to leverage our scroll snapping mechanisms we create various
structures to represent all of the scroll snap areas and offsets and
pass them as state to the scroll snapping logic for use later.

The issue is that we determine the geometry of the pages using
`pageBoundsInContentsSpace` (which is actually returning values in
something close to scrolled contents space but I plan to address that
separately), but this is problematic since this factors in the page
scale while the scroll snap logic takes the current scroll offset and
factors it out when looking at the provided geometry of the scroll
offsets/areas.

To factor out the page scale we can use our helper conversion functions
to convert from document space to actual contents space. We also need
to do the same thing in our logic that attempts to determine the
the currently snapped page since that uses the scroll offset.

Finally, we attempt hook into the resnapping logic when we switch
layout modes, but this is also an issue because it seems to keep the
page scale factored into the scroll offset while looking at the snap
areas geometries. Instead, let's just scroll to the currently snapped
page since we determined this ourselves anyway.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updateSnapOffsets):
(WebKit::UnifiedPDFPlugin::determineCurrentlySnappedPage):
(WebKit::UnifiedPDFPlugin::setDisplayModeAndUpdateLayout):

Canonical link: https://commits.webkit.org/278421@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d62376: [UnifiedPDF] Going between page layout modes doesn...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d6237610e33903698a8368b9bc1a7bf4af9495cc
  
https://github.com/WebKit/WebKit/commit/d6237610e33903698a8368b9bc1a7bf4af9495cc
  Author: Sammy Gill 
  Date:   2024-05-03 (Fri, 03 May 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Going between page layout modes doesn't rescale or center 
appropriately
https://bugs.webkit.org/show_bug.cgi?id=273696
rdar://125381629

Reviewed by Abrar Rahman Protyasha and Simon Fraser.

To fix this, we can just force m_shouldUpdateAutoSizeScale to be set
right before we perform a document layout in this scenario. This will make
sure that the document gets refitted to the available width.

However, we should also respect if the document is already in
"Automatically Resize," mode. This means that we should not adjust the
page scale factor when performing this layout if the state was *already*
set.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setDisplayModeAndUpdateLayout):

Canonical link: https://commits.webkit.org/278342@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8cf954: [UnifiedPDF] Snapshots don't get the correct scrol...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8cf954d346bc1cc6b549e8a60cb95bda9c7d15f1
  
https://github.com/WebKit/WebKit/commit/8cf954d346bc1cc6b549e8a60cb95bda9c7d15f1
  Author: Sammy Gill 
  Date:   2024-05-01 (Wed, 01 May 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Snapshots don't get the correct scroll offset
https://bugs.webkit.org/show_bug.cgi?id=273565
rdar://126945237

Reviewed by Simon Fraser and Abrar Rahman Protyasha.

In order to make the snapshots appear correct in the tab preview we
need to make a few related changes.

The first change we need to make is to take into consideration the page
scale. This is the main factor that is driving the incorrect scroll
offset in the snapshots. However, we must also recenter the document
by adding in the padding that is used to center it. Finally, we must
also make sure that we paint the grey background that is shown on the
page itself.

One other related change we need to make is to factor out the page scale
in the clip rect we pass to paintPDFContent. This is because we will
pass in the rect to pageCoverageForRect, which seems to expect that the
passed in rect is in document space, in order to determine which pages
need to get painted. With the page scale factored into the rect we
can get into a state where we scroll to a new page in the document but
not have that page appear in the snapshot.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::paint):

Canonical link: https://commits.webkit.org/278244@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3f7f7e: [UnifiedPDF] Snapshots after the first page are pa...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3f7f7ed16b4fb150585c2adba8d3913f72ba1712
  
https://github.com/WebKit/WebKit/commit/3f7f7ed16b4fb150585c2adba8d3913f72ba1712
  Author: Sammy Gill 
  Date:   2024-04-24 (Wed, 24 Apr 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Snapshots after the first page are partially dark-shaded
https://bugs.webkit.org/show_bug.cgi?id=273213
rdar://126817702

Reviewed by Abrar Rahman Protyasha and Simon Fraser.

277273@main attempted to address this issue by making adding in the
white background as a fill as part of the async rendering codepath. It
turns out that this was quite not enough and snapshots of pages after
the first page are still appearing as dark. It looks like this is due
to the fact that we modify the graphics context by making it so that the
origin is at the bottom of the page before we pass it off to PDFKit.
So, instead we will start adding the fill before we perform this
coordinate space transformation.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::paintPDFContent):

Canonical link: https://commits.webkit.org/277965@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 50bb1b: [Unified PDF] find-in-page highlights can get deta...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 50bb1b20d213353ede7449797bfdc0850fcbc6c8
  
https://github.com/WebKit/WebKit/commit/50bb1b20d213353ede7449797bfdc0850fcbc6c8
  Author: Sammy Gill 
  Date:   2024-04-16 (Tue, 16 Apr 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [Unified PDF] find-in-page highlights can get detached from the document
https://bugs.webkit.org/show_bug.cgi?id=272710
rdar://125787367

Reviewed by Tim Horton.

In cases where we zoom but do not end up changing the scroll offset we
need to update our find overlay to repaint the rects correctly.

Also, whenever we zoom we need to hide the find indicator that showcases
the current selection to match shipping behavior in web content. We
should also adopt this logic whenever the scroll offset changes.
Otherwise you could find yourself in scenarios where the holes get
updated properly but the text indicator for the current selection does
not.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::setPageScaleFactor):
(WebKit::UnifiedPDFPlugin::didChangeScrollOffset):
(WebKit::UnifiedPDFPlugin::collectFindMatchRects):
(WebKit::UnifiedPDFPlugin::updateFindOverlay):

Canonical link: https://commits.webkit.org/277551@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 67629e: REGRESSION (276433@main): Snapshots are partially ...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 67629e39b0e9bc6a179cbb7c9dffe819a7015bdc
  
https://github.com/WebKit/WebKit/commit/67629e39b0e9bc6a179cbb7c9dffe819a7015bdc
  Author: Sammy Gill 
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  REGRESSION (276433@main): Snapshots are partially dark-shaded.
https://bugs.webkit.org/show_bug.cgi?id=272410
rdar://125791769

Reviewed by Simon Fraser and Abrar Rahman Protyasha.

These dark regions are due to the fact that we are missing the white
background when painting the previews. This patch adds them back in the
async case since the preview is painted without the async renderer.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::paintPDFContent):

Canonical link: https://commits.webkit.org/277273@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 59d121: [UnifiedPDF] PDFDocumentLayout::nearestPageIndexFo...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 59d1217ce3006a187f88917be67d5ed8100b
  
https://github.com/WebKit/WebKit/commit/59d1217ce3006a187f88917be67d5ed8100b
  Author: Sammy Gill 
  Date:   2024-03-29 (Fri, 29 Mar 2024)

  Changed paths:
M Source/WebCore/platform/graphics/GeometryUtilities.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm

  Log Message:
  ---
  [UnifiedPDF] PDFDocumentLayout::nearestPageIndexForDocumentPoint sometimes 
returns the incorrect page index
https://bugs.webkit.org/show_bug.cgi?id=271777
rdar://125502090

Reviewed by Abrar Rahman Protyasha.

The current heuristic worked well for the purposes of next/previous page
context menu navigation, but it likely will not be sufficient to adopt
anywhere else. In order to make this much more precise in two up mode,
we need to rework the heuristic. There are two main changes:

1.) Now iterate over the pairs of pages rather than individual ones.
This makes the rest of the logic much more intuitive since in two up
mode we are almost always working with pairs of pages. There are cases
where we may only have one page, but this is handled naturally by the
fact that the second page in PairedPageLayoutBounds is optional.

2.) Instead of picking the page with the closer x coordinate after
determining the pair of pages to consider, we should instead compare
the distance from the point in document space to various points on the
pages. In particular, we should compare the distance to the corners of
the page and to the side of the page it is next to (if possible). The
smallest distance between all of these points should represent the page
closest to the point in question.

One other change I made is related to the logic when the document point
is below the PDF. In this case we should perform the same type of logic
with the last pages instead of blindly returning the last page index
like we were doing before.

* Source/WebCore/platform/graphics/GeometryUtilities.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::nearestPageIndexForDocumentPoint const):

Canonical link: https://commits.webkit.org/276852@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ba849a: [css-grid] Grid track sizing algorithm logical hei...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ba849a630cec232ab5f53e05503f0fdf40cccebd
  
https://github.com/WebKit/WebKit/commit/ba849a630cec232ab5f53e05503f0fdf40cccebd
  Author: Sammy Gill 
  Date:   2024-03-25 (Mon, 25 Mar 2024)

  Changed paths:
A PerformanceTests/Layout/nested-grid-subgrid-free-space-columns.html
M Source/WebCore/Headers.cmake
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/style/RenderStyle.h
M Source/WebCore/rendering/style/RenderStyleInlines.h

  Log Message:
  ---
  [css-grid] Grid track sizing algorithm logical height computation 
unnecessarily dirties grid items.
https://bugs.webkit.org/show_bug.cgi?id=271083
rdar://124713418

Reviewed by Matt Woodrow.

In certain situations when trying to compute the logical height for a
grid item, the grid track sizing algorithm will update the grid item's
overriding containing block size and mark it dirty for layout. This
dirtying would occur even it we end up setting the override size to the
same value and could result in bad performance with particular types
of content. For example, nested grid content would run grid layout
multiple times which is currently expensive.

In this patch we avoid this extra call to layout by checking to see if
the override size is already set to the value we are attempting to set
it to. If it is then we will avoid dirtying the renderer.

This also ended up exposing an invalidation bug in which we were not
properly invalidating the grid items when there was a style change on
the grid related to its column or row sizes. This was demonstrated with
new failures in css-grid/layout-algorithm/grid-intrinsic-track-sizes-001.html
which was performing this behavior. Now when the grid style changes we
will check to see if any of the sizes for the columns or the rows are
different. If this occurs we should mark the grid items as dirty. This
is likely to be more than necessary since we could probably try to
identify the exact set of grid items that need to be invalidated, but
this approach is the least risky for now. Future patches should attempt
to reign this invalidation in a bit more.

Without this patch I was getting about 2 runs/s and afterwards I was
able to get about ~690 runs/s.

* PerformanceTests/Layout/nested-grid-subgrid-free-space-columns.html: Added.
* Source/WebCore/Headers.cmake:
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithmStrategy::logicalHeightForChild const):
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::styleDidChange):
* Source/WebCore/rendering/style/RenderStyle.h:
* Source/WebCore/rendering/style/RenderStyleInlines.h:
(WebCore::RenderStyle::gridTrackSizes const):

Canonical link: https://commits.webkit.org/276633@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 088d35: [UnifiedPDF] Adjust automatically resize logic.

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 088d359b366f55a78bb11def3043463624bdc006
  
https://github.com/WebKit/WebKit/commit/088d359b366f55a78bb11def3043463624bdc006
  Author: Sammy Gill 
  Date:   2024-03-19 (Tue, 19 Mar 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Adjust automatically resize logic.
https://bugs.webkit.org/show_bug.cgi?id=271264
rdar://123417338

Reviewed by Simon Fraser and Abrar Rahman Protyasha.

This patch aims to make the "Automatically Resize," context menu item
logic a little more intuitive. The way that this setting works now
with this patch is as follows:

1. Defaults to off
- PDFDocumentLayout has m_autoSizeState initialized to
ShouldUpdateAutoSizeScale::Yes, but the plugin will set it to No after
the first layout. This is so that the document gets fitted according to
our existing logic on initial load. Any sort of window resizing at this
point will not resize the document.

2. Turning it on rescales the PDF to the window width
- This is done by adjusting the logic that we have when we handle the
associated context menu event. Instead of setting the plugin's scale
factor to its initial scale that was computed on load, we will set it
to 1.0.

3. Any type of zooming turns it off
- This is already handled already in UnifiedPDFPlugin::setPageScaleFactor.
This includes HUD, pinch, and keyboard zooming.

4. The setting can also be toggleable
- Expanded the associated context menu action handling to include this.
When the setting is toggled off the scales will remain the same even
during window resizing. Toggling it back on will reset the plugin's
scale factor and adjust the document fitting scale so that the document
once again fits the available width.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::updateLayout):
(WebKit::UnifiedPDFPlugin::performContextMenuAction):

Canonical link: https://commits.webkit.org/276371@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a7b53c: [UnifiedPDF] Pinch and keyboard zooming do not dis...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a7b53c30f92b3c9864be53a3c9383b066a7620d4
  
https://github.com/WebKit/WebKit/commit/a7b53c30f92b3c9864be53a3c9383b066a7620d4
  Author: Sammy Gill 
  Date:   2024-03-18 (Mon, 18 Mar 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Pinch and keyboard zooming do not disable automatically resize 
option.
https://bugs.webkit.org/show_bug.cgi?id=271088
rdar://problem/124717930

Reviewed by Tim Horton.

When pinch zooming is performed we should stop updating the document
fitting scale. Zooming via keyboard shortcuts should also have the same
beheavior. Let's do this when the page's scale factor has changed so
that it catches both cases.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::didBeginMagnificationGesture):

Canonical link: https://commits.webkit.org/276309@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c8fad1: Provide initial infrastructure for creating PDF re...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c8fad15f783eb5b7f84b415d0c2a8c97b24fc786
  
https://github.com/WebKit/WebKit/commit/c8fad15f783eb5b7f84b415d0c2a8c97b24fc786
  Author: Sammy Gill 
  Date:   2024-03-15 (Fri, 15 Mar 2024)

  Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/pdf/unifiedpdf/annotations/checkbox-set-active-expected.html
A LayoutTests/pdf/unifiedpdf/annotations/checkbox-set-active.html
A 
LayoutTests/pdf/unifiedpdf/annotations/dropdown-select-second-option-expected.html
A LayoutTests/pdf/unifiedpdf/annotations/dropdown-select-second-option.html
A 
LayoutTests/pdf/unifiedpdf/annotations/radio-buttons-select-second-expected.html
A LayoutTests/pdf/unifiedpdf/annotations/radio-buttons-select-second.html
A LayoutTests/pdf/unifiedpdf/resources/annotation-checkbox-active.pdf
A LayoutTests/pdf/unifiedpdf/resources/annotation-checkbox-inactive.pdf
A 
LayoutTests/pdf/unifiedpdf/resources/annotation-dropdown-first-option-selected.pdf
A 
LayoutTests/pdf/unifiedpdf/resources/annotation-dropdown-second-option-selected.pdf
A 
LayoutTests/pdf/unifiedpdf/resources/annotation-two-radio-buttons-first-active.pdf
A 
LayoutTests/pdf/unifiedpdf/resources/annotation-two-radio-buttons-second-active.pdf
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/plugins/PluginViewBase.h
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp
M Source/WebKit/WebProcess/Plugins/PluginView.h

  Log Message:
  ---
  Provide initial infrastructure for creating PDF ref tests.
https://bugs.webkit.org/show_bug.cgi?id=270044
rdar://problem/123573535

Reviewed by Tim Horton.

This patch provides the very initial infrastructure that we will build
upon for creating PDF ref tests. The main focus was to create a way
for us to test PDF annotations, but we can build upon this to test other
parts of PDF functionality. I added three very basic tests to cover PDF
annotation interaction: selecting radio buttons, checkboxes, and select
menus.

Two APIs were added to window.internals to make this possible:
1.) registerPDFTestCallback
2.) pdfAnnotationRects

registerPDFTestCallback takes two arguments: the HTML element that
corresponds to the plugin and a callback that will get executed once
the PDF document is installed in the plugin. The callback is supposed to
act as the test that we would like to run and should contain all of the
logic involved with testing a particular part of PDF functionality.
This callback is taken and plumbed into the PDFPlugin so that it can
execute once the document is ready so that it can use any other APIs
that return information about the document. This is done by calling into
the corresponding private method on PluginViewBase that is available to
Internals since it is a friend. I chose this approach because I did not
want this to become a public API on PluginViewBase that can be used
arbitrarily. Also, if the document is already loaded in the plugin then
we will execute the callback immediately in order to avoid holding onto
it.

pdfAnotationRects is a simple API that just returns a list
of the geometry of all the annotations in the document in plugin space.
Returning the geometry of all the annotations was the simplest and was
sufficient enough for the tests that were added in this patch. However,
we can build upon this to filter out which annotations should be
retruned based upon what we find useful for testing.

The current approach to creating a PDF ref test is to load a document
in either a iframe or embed and then register a callback that will
contain all of the logic for the test once the document has been loaded
in the plugin. For example, the tests for the annotations in this patch
use UIHelper pdfAnnotationRects to interact with the document.

One current limitation with the initial infrastructure is that you need
to have a reference document with the modified PDF that the test will be
compared against. The annotation tests mutate the document in the test
itself, but the result is compared with a PDF that is mutated to be the
expectation of the test result. I tried to make it so that the reference
could use the legacy plugin, but my initial attempts were fruitless so
opted for the simpler approach for the sake of getting the groundwork
laid out so that we could iterate on it for future patches. Another
alternative improvement to consider besides getting the legacy plugin
to work is to add some additional APIs that gather data on the PDF
document and then have the tests assert against

[webkit-changes] [WebKit/WebKit] d583f1: [Unified PDF] Form control partial repaint for "re...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d583f18ce8eded8a598b3aafd181c9f1864fd3f6
  
https://github.com/WebKit/WebKit/commit/d583f18ce8eded8a598b3aafd181c9f1864fd3f6
  Author: Sammy Gill 
  Date:   2024-03-05 (Tue, 05 Mar 2024)

  Changed paths:
M Source/WebKit/Platform/spi/Cocoa/PDFKitSPI.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [Unified PDF] Form control partial repaint for "related" fields is broken, 
results in fields getting stuck.
https://bugs.webkit.org/show_bug.cgi?id=270539
rdar://123637341

Reviewed by Abrar Rahman Protyasha and Tim Horton.

In order to avoid repainting the world we attempt to perform very
targeted repaints. For annotations this generally means we need to find
the bounds for the annotation and provide the geometry of the area to
the async renderer to that it can repaint the affected area. However,
certain annotations may also have an effect on a set of related
annotations. For example, when interacting with radio buttons in the
same group we want to make sure that not only is the newly selected
radio button displayed as active but also that the previously selected one
is no longer active. For these annotations we want to make sure that
those get repainted as well in order to properly display the state
changes.

Since we already have an observer that listens for form field changes
that are sent by the document, we can use the same notification to tell
the plugin of the field that changed and get the geometry of the
annotations. We can take the field name given by the observer and ask
the document for all of the annotations associated with this field name
through IPI.

In order for the repainting to happen correctly we had to slightly
change how the async renderer handled requests for tile repaints.
Previously, it would check to see if a repaint request for a particular
tile had already been enqueued and drop the current request if it had.
This approach was too conservative since multiple annotations may need
to get repainted within a tile and observer gets notified of multiple
fields independently (e.g. a button action that resets form fields
sends a separate notification for each field in the form). Now the
async observer will drop the request if:

1.) There is not a clip rect provided for the request (to match current
behavior)
2.) The tile rect clip for the repaint request is already contained
completely within the tile rect clip for the enqueued tile update

If a repaint request comes in for the same tile but it is not being
handled by an enqueued tile update then we will take the existing
update's tile rect, combine it with the rect in the new request, and
update the enqueued tile update. As we complete the tile update we will
check to see if the area that was repainted is the same as the one that
was enqueued. If it is not this means that the tile update was updated
with a new rect so we do not proceed to cache the tile.

* Source/WebKit/Platform/spi/Cocoa/PDFKitSPI.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm:
(WebKit::AsyncPDFRenderer::didCompleteTileUpdateRender):
(WebKit::AsyncPDFRenderer::updateTilesForPaintingRect):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(-[WKPDFFormMutationObserver formChanged:]):
(WebKit::UnifiedPDFPlugin::repaintAnnotationsForFormField):

Canonical link: https://commits.webkit.org/275727@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5fbb03: [UnifiedPDF] Don't show the form hover highlight f...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5fbb03ee1c6210c79779d6fa1a9e7290daa746d1
  
https://github.com/WebKit/WebKit/commit/5fbb03ee1c6210c79779d6fa1a9e7290daa746d1
  Author: Sammy Gill 
  Date:   2024-02-27 (Tue, 27 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Don't show the form hover highlight for non-fillable forms
https://bugs.webkit.org/show_bug.cgi?id=270184
rdar://123667854

Reviewed by Tim Horton.

If the plugin does not support forms, because it is not a main frame
or iframe plugin, then we should not start tracking the text widget
annotations. This will make sure that we do not keep around any state
that would be used later on for painting the hover indicator.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::paintHoveredAnnotationOnPage):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):

Canonical link: https://commits.webkit.org/275413@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a7d90b: [UnifiedPDF] Annotation hover rectangle is wrong o...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a7d90be9008dcb5f27fab671a887cccab006e1cc
  
https://github.com/WebKit/WebKit/commit/a7d90be9008dcb5f27fab671a887cccab006e1cc
  Author: Sammy Gill 
  Date:   2024-02-27 (Tue, 27 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Annotation hover rectangle is wrong on rotated pages
https://bugs.webkit.org/show_bug.cgi?id=270191
rdar://122931284

Reviewed by Simon Fraser.

This appears to be the same issue that 275351@main fixed for selections
but this time for annotations. To make sure that our painting code
displays the blue rectangle properly we need to factor out the rotation
that is implicit in bounds of the annotation that we get back from
PDFKit.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::paintPDFContent):

Canonical link: https://commits.webkit.org/275411@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e5936d: [UnifiedPDF] Annotation tracking stops working whe...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e5936dcccb934ed15938c9a6374dac5964f230ab
  
https://github.com/WebKit/WebKit/commit/e5936dcccb934ed15938c9a6374dac5964f230ab
  Author: Sammy Gill 
  Date:   2024-02-26 (Mon, 26 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Annotation tracking stops working when the mouse leaves the 
annotation.
https://bugs.webkit.org/show_bug.cgi?id=270117
rdar://123123950

Reviewed by Simon Fraser.

Currently annotation tracking begins in two scenarios:
1.) Mouse over of a texxt annotation
2.) Left click on other types of annotations

For the latter we finish tracking the annotation when the left mouse
button is released or if it is dragged off the tracked annotation. The
second case is incorrect, however, and we should contiue to keep track
of the annotation.

If the mouse is dragged off of the tracked annotation it should not be
highlighted anymore unless the mouse is dragged back onto it. If the
left mouse button is relased on the annotation then we want to perform
the associated action (e.g. activating a checkbox), but if it is
released off of the annotation then we should do nothing and just stop
tracking the annotation.

To accomplish the first part all we need to do is stop calling
finishTrackingAnnotation and instead call a new method:
updateTrackedAnnotation. All this new method does is update the
highlight of the tracked annotation but it does not modify the
annotation tracking state. For the second change, we need to pass in
the annotation under the mouse to finishTrackingAnnotation so the
annotation tracking state will only perform the associated action if
the annotation under the mouse is the annotation it is tracking.

One other small change that I made is to not change the cursor type when
the mouse is dragged off the annotation to make it consistent with
shipping.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::updateTrackedAnnotation):
(WebKit::UnifiedPDFPlugin::finishTrackingAnnotation):
(WebKit::AnnotationTrackingState::finishAnnotationTracking):

Canonical link: https://commits.webkit.org/275362@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a22474: [UnifiedPDF] PDFPluginChoiceAnnotations have incor...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a2247463abb0064a8213ab4d24a23c9d38378514
  
https://github.com/WebKit/WebKit/commit/a2247463abb0064a8213ab4d24a23c9d38378514
  Author: Sammy Gill 
  Date:   2024-02-23 (Fri, 23 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] PDFPluginChoiceAnnotations have incorrect font size.
https://bugs.webkit.org/show_bug.cgi?id=269923
rdar://123119103

Reviewed by Simon Fraser.

The PDFPluginChoiceAnnotation sets its font size
based on the size of the font in the underlying
annotation within the document and then scales it
based on its scale factor. The UnifiedPDFPlugin's
scale factor is its zoom scale factor, but we
could also have scaled the document to fit in the
available width. PDFPluginTextAnnotations take
into consideration both scale factors so we should
do the same here.

In order to do this more cleanly, I introduced
contentScaleFactor on the plugins. For the legacy
PDF plugin this is just the same as its
scaleFactor, but for the UnifiedPDFPlugin this is
both the document fitting scale and the zoom
scale (it seems like this is what the legacy
plugin considers to be its scaleFactor as well).

* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::contentScaleFactor const):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.mm:
(WebKit::PDFPluginChoiceAnnotation::updateGeometry):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm:
(WebKit::PDFPluginTextAnnotation::updateGeometry):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::contentScaleFactor const):
(WebKit::UnifiedPDFPlugin::updateSnapOffsets):
(WebKit::UnifiedPDFPlugin::searchInDictionary):

Canonical link: https://commits.webkit.org/275264@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8aed81: [UnifiedPDF] PDFPluginAnnotations need to be repos...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8aed81df35f81ca9f75368e75b52f1e012ce89f0
  
https://github.com/WebKit/WebKit/commit/8aed81df35f81ca9f75368e75b52f1e012ce89f0
  Author: Sammy Gill 
  Date:   2024-02-21 (Wed, 21 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] PDFPluginAnnotations need to be repositioned on layout changes
https://bugs.webkit.org/show_bug.cgi?id=269870
rdar://123119217

Reviewed by Simon Fraser.

Whenever the plugin's geometry is updated, then we need to check if
there is a currently active annotation. If there is then we inform
the annotation of this and have it update its geometry in response to
the change.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::geometryDidChange):

Canonical link: https://commits.webkit.org/275150@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 55b051: [UnifiedPDF] Fix context menu page navigation for ...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 55b05170db3b61e4d6266a0a9580f4665adcbb39
  
https://github.com/WebKit/WebKit/commit/55b05170db3b61e4d6266a0a9580f4665adcbb39
  Author: Sammy Gill 
  Date:   2024-02-16 (Fri, 16 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Fix context menu page navigation for 2up.
https://bugs.webkit.org/show_bug.cgi?id=269501
rdar://problem/123032781

Reviewed by Simon Fraser.

274737@main provided the initial implementation for navigating between
pages using context menu options. It worked fine for pages in single
page display modes but not all the time in two up display modes. This
patch tries to address that by making sure we navigate between pairs
of pages in two up mode.

When determining which page to scroll to in two up mode we need to
consider whether the "current page," is the first page in the row or the
second page in the row. If we are navigating forwards and the "current
page," is the first page in the row, then we need to navigate two pages
forward to go to the next row. Similarly, if we are navigating backwards
and the "current page," is the second page in the row, we need to
go two pages backwards.

I also changed indexForCurrentPageInView to use a new method,
nearestPageIndexForDocumentPoint, instead of pageIndexForDocumentPoint
since it was not guaranteed the later would alawys return a page index.
Fow single page mode, this new method iterates over the pages in order
and compares the point with the bottom of each page. Once we find a page
point's Y location that is lower than the document points' then we have
found the page the point is contained in. Two up modes works in the
same way except we also need to compare the X location for the points.

I also renamed the DisplayModes enums to explicitly state whether they
are discrete or continuous to help introduce some new helpers without
them having confusing names (isSinglePageDisplayMode and
isTwoUpDisplayMode).

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
(WebKit::PDFDocumentLayout::isSinglePageDisplayMode const):
(WebKit::PDFDocumentLayout::isTwoUpDisplayMode const):
(WebKit::PDFDocumentLayout::pagesPerRow const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::isLeftPageIndex const):
(WebKit::PDFDocumentLayout::isRightPageIndex const):
(WebKit::PDFDocumentLayout::isLastPageIndex const):
(WebKit::PDFDocumentLayout::nearestPageIndexForDocumentPoint const):
(WebKit::PDFDocumentLayout::updateLayout):
(WebKit::PDFDocumentLayout::layoutPages):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::shouldUseScrollSnapping const):
(WebKit::UnifiedPDFPlugin::shouldDisplayPage):
(WebKit::UnifiedPDFPlugin::indexForCurrentPageInView const):
(WebKit::UnifiedPDFPlugin::contextMenuItemTagFromDisplayMode const):
(WebKit::UnifiedPDFPlugin::displayModeFromContextMenuItemTag const):
(WebKit::UnifiedPDFPlugin::navigationContextMenuItems const):
(WebKit::UnifiedPDFPlugin::performContextMenuAction):

Canonical link: https://commits.webkit.org/274858@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f2eb34: [UnifiedPDF] Add support for the "Automatically Re...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f2eb34598ea0a1e2e06f6716c724e22e9d228cf7
  
https://github.com/WebKit/WebKit/commit/f2eb34598ea0a1e2e06f6716c724e22e9d228cf7
  Author: Sammy Gill 
  Date:   2024-02-15 (Thu, 15 Feb 2024)

  Changed paths:
M Source/WebCore/platform/LocalizedStrings.cpp
M Source/WebCore/platform/LocalizedStrings.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Add support for the "Automatically Resize" option.
https://bugs.webkit.org/show_bug.cgi?id=269510
rdar://122208120

Reviewed by Tim Horton.

The automatic resize feature controls whether or not the document
fitting scale is changed in response to the plugin's available width
changing. This is on by default but is disabled whenever any sort of
zooming occurs. We can keep track of this by adding some extra state to
PDFDocumentLayout that keeps track of whether the document fitting scale
should be adjusted during the layout of the document.

Zooming will update this state to disable the behavior. If the behavior
is disabled but the "Automatically Resize," context menu item is
selected, then the behavior will be enabled again, the zoom will get
reset to its initial value, and the document will need get laid out
again to compute the new document fitting scale.

* Source/WebCore/platform/LocalizedStrings.cpp:
(WebCore::contextMenuItemPDFAutoSize):
* Source/WebCore/platform/LocalizedStrings.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
(WebKit::PDFDocumentLayout::setShouldUpdateAutoSizeScale):
(WebKit::PDFDocumentLayout::shouldUpdateAutoSizeScale const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::layoutSingleColumn):
(WebKit::PDFDocumentLayout::layoutTwoUpColumn):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::toContextMenuItemTag const):
(WebKit::UnifiedPDFPlugin::titleForContextMenuItemTag const):
(WebKit::UnifiedPDFPlugin::contextMenuItem const):
(WebKit::UnifiedPDFPlugin::scaleContextMenuItems const):
(WebKit::UnifiedPDFPlugin::performContextMenuAction):
(WebKit::UnifiedPDFPlugin::zoomIn):
(WebKit::UnifiedPDFPlugin::zoomOut):
(WebKit::UnifiedPDFPlugin::resetZoom):

Canonical link: https://commits.webkit.org/274800@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 799678: [UnifiedPDF] Context menu should have "Next Page" ...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 799678c6dd8cd120146f7acb293ba006761b569d
  
https://github.com/WebKit/WebKit/commit/799678c6dd8cd120146f7acb293ba006761b569d
  Author: Sammy Gill 
  Date:   2024-02-15 (Thu, 15 Feb 2024)

  Changed paths:
M Source/WebCore/platform/LocalizedStrings.cpp
M Source/WebCore/platform/LocalizedStrings.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Context menu should have "Next Page" and "Previous Page" 
navigation options.
https://bugs.webkit.org/show_bug.cgi?id=269347
rdar://122931085

Reviewed by Tim Horton.

Adds the next and previous page items to the context menu. The "Next
Page," option is only able to be selected if the current page that is
in the view is not the last page. Likewise, the "Previous Page," option
is only selectable if the current page is not the first page. Regardless
both of the options are shown but are disabled in those scenarios.

In order to determine which page we are on we take the very center of
the view and see which page that point is contained in. This code
currently works only for single page display modes so a follow up will
be needed to get it working for two page display modes.

For scrolling between the pages we take the layout bounds, convert them
to the contents space, subtract out the page margins, and then
perform a scroll without animation to that point. Modified
scrollToPointInPage to use this new helper function that subtracts out
the page margins instead of the document margins like it was before and
which I don't think was correct.

Also rearranged the context menu slightly so that the ordering of the
items matches the current order displayed with the legacy plugin.

* Source/WebCore/platform/LocalizedStrings.cpp:
(WebCore::contextMenuItemPDFActualSize):
(WebCore::contextMenuItemPDFAutoSize):
* Source/WebCore/platform/LocalizedStrings.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::indexForCurrentPageInView const):
(WebKit::UnifiedPDFPlugin::convertFromPageToContents const):
(WebKit::UnifiedPDFPlugin::convertFromDocumentToContents const):
(WebKit::UnifiedPDFPlugin::offsetContentsSpacePointByPageMargins const):
(WebKit::UnifiedPDFPlugin::scrollToPointInPage):
(WebKit::UnifiedPDFPlugin::scrollToPage):
(WebKit::UnifiedPDFPlugin::toContextMenuItemTag const):
(WebKit::UnifiedPDFPlugin::createContextMenu const):
(WebKit::UnifiedPDFPlugin::titleForContextMenuItemTag const):
(WebKit::UnifiedPDFPlugin::contextMenuItem const):
(WebKit::UnifiedPDFPlugin::navigationContextMenuItems const):
(WebKit::UnifiedPDFPlugin::performContextMenuAction):

Canonical link: https://commits.webkit.org/274737@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3bfd75: [UnifiedPDF] Find in PDF without overlays

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3bfd7513a9aff5e2ae3f35fbf1547843adf0306a
  
https://github.com/WebKit/WebKit/commit/3bfd7513a9aff5e2ae3f35fbf1547843adf0306a
  Author: Sammy Gill 
  Date:   2024-02-14 (Wed, 14 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Find in PDF without overlays
https://bugs.webkit.org/show_bug.cgi?id=269328
rdar://problem/122917321

Reviewed by Tim Horton.

Provides the initial support for the find in PDF functionality. This
is done by querying the PDFDocument for the string that was passed in
for search.

In order to accomplish this we need to keep track of the last string
that was searched for. If the target string is the same as the last one
then we need to continue the search from the last match/result we found.
We keep track of the results as the current selection. If the target is
not as the last string we found, then we need to clear the selection
before we attempt to search for the string.

When we find the string we will update its selection to the one that
was returned to us from PDFDocument and potentially scroll to it if it
is currently out of view.

* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::pdfPageRectToDocumentRect const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::convertFromPageToDocument const):
(WebKit::UnifiedPDFPlugin::convertFromPageToContents const):
(WebKit::UnifiedPDFPlugin::countFindMatches):
(WebKit::UnifiedPDFPlugin::findString):

Canonical link: https://commits.webkit.org/274646@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f3ce15: [UnifiedPDF] Handle PDF actions that move betwen p...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f3ce152618e8b172daa501d4d579128f439dcfa7
  
https://github.com/WebKit/WebKit/commit/f3ce152618e8b172daa501d4d579128f439dcfa7
  Author: Sammy Gill 
  Date:   2024-02-13 (Tue, 13 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Handle PDF actions that move betwen pages and perform zooms.
https://bugs.webkit.org/show_bug.cgi?id=268508
rdar://122049363

Reviewed by Tim Horton.

To start handling PDFActions we will check to see if an annotation has
an associated action. If it does then we check to see what type of
action it is. In this patch we provide support for actions that go to
next/previous pages, the first/last pages and zooming in/out.

We already have logic for these things so this is just a matter of
hooking up the PDFActions to them. For zooming in/out we hook into their
respective functions. For any sort page navigations we can use
scrollToPage. PDFDestination navigations are handled in a similar way.

Finally, I added in some logic to take into consideration page margins
in scrollToPointInPage.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::scrollToPointInPage):
(WebKit::UnifiedPDFPlugin::handlePDFActionForAnnotation):

Canonical link: https://commits.webkit.org/274598@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5d64ca: [UnifiedPDF] Handle PDF annotations actions that r...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5d64ca88eee23e4cb2fd828d581875dc6abf2192
  
https://github.com/WebKit/WebKit/commit/5d64ca88eee23e4cb2fd828d581875dc6abf2192
  Author: Sammy Gill 
  Date:   2024-02-13 (Tue, 13 Feb 2024)

  Changed paths:
M Source/WebKit/Platform/spi/Cocoa/PDFKitSPI.h
M Source/WebKit/Shared/Cocoa/PDFKitSoftLink.h
M Source/WebKit/Shared/Cocoa/PDFKitSoftLink.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Handle PDF annotations actions that reset form fields.
https://bugs.webkit.org/show_bug.cgi?id=269122
rdar://problem/122680796

Reviewed by Tim Horton.

A certain type of PDF annotation action can reset various fields on a
form. PDFKit represents this type of action as a PDFKitActionResetForm.

Basically what we will do is check to see if an annotation has an action
associated with it and will handle it if it does. This first patch
supports the reset form action and will check to see if the action is
of that type when handling it. If it is, we will call into the
appropriate PDFKit SPI which will do the actual work for us.

Also, the PDF specification says that an action is composed of a type,
which specifies the type of action that it is, and a list of subsequent
actions that are supposed to be performed. So we need to handle this
scenario also by:
1.) Performing the action
2.) Store the subsequent actions on a stack in reverse order (so that
the first action is at the top of the stack).
We keep handling the action at the top of the stack until it is empty.

* Source/WebKit/Platform/spi/Cocoa/PDFKitSPI.h:
* Source/WebKit/Shared/Cocoa/PDFKitSoftLink.h:
* Source/WebKit/Shared/Cocoa/PDFKitSoftLink.mm:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::handlePDFActionForAnnotation):

Canonical link: https://commits.webkit.org/274546@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3b5f85: [UnifiedPDF] Add ability to start focusing next/pr...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3b5f85622e9c64d8e6e1c748eeff3b9bdfafa82f
  
https://github.com/WebKit/WebKit/commit/3b5f85622e9c64d8e6e1c748eeff3b9bdfafa82f
  Author: Sammy Gill 
  Date:   2024-02-08 (Thu, 08 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Add ability to start focusing next/previous text annotations.
https://bugs.webkit.org/show_bug.cgi?id=268349
rdar://problem/121890426

Reviewed by Simon Fraser.

When a text annotation is currently active, the user should be able
to focus the next/previous one using the appropriate keyboard shortcut.
Effectivley, what we will need to do is iterate over the annotations in
the appropriate direction until we find a text annotation that can be
interacted with (this could be the same annotation if there are no
others to be found).

We start by checking the current page the active annotation is on. If
there are any remaining annotations on the page, then we will iterate
over them to see if the next one is on the page. If we could not find an
appropriate text annotation on the page then we repeat the process by
going to the next page in the appropriate direction. This process is
repeated until we find an appropriate text annotation to return. There
should always be at least one text annotation to return: the original
one.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::findFirstTextAnnotationStartingAtIndex):
(WebKit::UnifiedPDFPlugin::nextTextAnnotation const):
(WebKit::UnifiedPDFPlugin::focusNextAnnotation):
(WebKit::UnifiedPDFPlugin::focusPreviousAnnotation):

Canonical link: https://commits.webkit.org/274337@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8147bb: [UnifiedPDF] Text annotations do not have blue bac...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8147bb3d60a35215dcb9493678a34f1673f9329d
  
https://github.com/WebKit/WebKit/commit/8147bb3d60a35215dcb9493678a34f1673f9329d
  Author: Sammy Gill 
  Date:   2024-02-07 (Wed, 07 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Text annotations do not have blue background on hover
https://bugs.webkit.org/show_bug.cgi?id=268497
rdar://problem/122041412

Reviewed by Tim Horton.

In order to display the blue rectangle that appears when a mouse cursor
is over a text annotation we must first start keeping track of that
in AnnotationTrackingState. We can simply add a new field there that
keepts track of this and can be queried later on when we need to check
if we need to paint it over the text annotation field.

startAnnotationTracking will set this field if the mouse event type
is a mouse move and no mouse button was pressed. This bit will get
reset when the client determines the mouse has moved off the text
annotation and calls finishAnnotationTracking().

If the mouse cursor is hovering over a text annotation and the left
mouse button is clicked to bring up the HTML input, then the blue
rectangle should still appear after the text has been inputted and if
the cursor did not move off the annotation. If the cursor moves off
the annotation then the blue rectangle should not appear the text has
been inputted even if it is brought back on top of the cursor while the
HTML input is up.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
(WebKit::AnnotationTrackingState::trackedAnnotation const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::paintPDFContent):
(WebKit::textAnnotationHoverColor):
(WebKit::UnifiedPDFPlugin::paintPDFOverlays):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::AnnotationTrackingState::startAnnotationTracking):
(WebKit::AnnotationTrackingState::finishAnnotationTracking):
(WebKit::AnnotationTrackingState::handleMouseDraggedOffTrackedAnnotation):
(WebKit::AnnotationTrackingState::isBeingHovered const):
(WebKit::AnnotationTrackingState::resetAnnotationTrackingState):

Canonical link: https://commits.webkit.org/274272@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6ade66: [UnifiedPDF] Documents should be saved with modifi...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6ade66019ba329793f0851d597827c5430cefd8a
  
https://github.com/WebKit/WebKit/commit/6ade66019ba329793f0851d597827c5430cefd8a
  Author: Sammy Gill 
  Date:   2024-02-07 (Wed, 07 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Documents should be saved with modified annotations.
https://bugs.webkit.org/show_bug.cgi?id=268923
rdar://119632592

Reviewed by Tim Horton.

When returning the document's data to save it we have two different
options: we can either return the data from the resource that was loaded
or we returning the data from PDFKit. We would want to return the former
so that documents that cannot be loaded by PDFKit can be saved and the
latter when the PDF was mutated. In order to determine which one we want
to use we need to keep track of when the PDF was mutated. This can be
done by hooking up an observer that will listen for events that are
sent by the PDFDocument when an annotation changed. This observer will
then modify some state to indicate that this occurred and which we will
consult when returning the document data.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(-[WKPDFFormMutationObserver initWithPlguin:]):
(-[WKPDFFormMutationObserver formChanged:]):
(WebKit::UnifiedPDFPlugin::UnifiedPDFPlugin):
(WebKit::mutationObserverNotificationString):
(WebKit::UnifiedPDFPlugin::teardown):
(WebKit::UnifiedPDFPlugin::installPDFDocument):
(WebKit::UnifiedPDFPlugin::liveResourceData const):
(WebKit::UnifiedPDFPlugin::liveData const):

Canonical link: https://commits.webkit.org/274261@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9730bd: [UnifiedPDF] HTML text annotations need to conside...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9730bdcb3f50d7e6eb221c0546fea1a916975a4b
  
https://github.com/WebKit/WebKit/commit/9730bdcb3f50d7e6eb221c0546fea1a916975a4b
  Author: Sammy Gill 
  Date:   2024-02-07 (Wed, 07 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h

  Log Message:
  ---
  [UnifiedPDF] HTML text annotations need to consider document layout scale 
factor
https://bugs.webkit.org/show_bug.cgi?id=268847
rdar://118550829

Reviewed by Tim Horton.

UnifiedPDF has two different scale factors: one scale based on the
size of the largest page and the available width and one based on
zooming. HTML text annotations currently only consider the latter when
determining the font size but should consider both.

* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm:
(WebKit::PDFPluginTextAnnotation::updateGeometry):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:

Canonical link: https://commits.webkit.org/274241@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5d02fd: Update Sammy Gill GitHub username.

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5d02fd42dbe1c9da4d2b9369b5ab1560ea38ef92
  
https://github.com/WebKit/WebKit/commit/5d02fd42dbe1c9da4d2b9369b5ab1560ea38ef92
  Author: Sammy Gill 
  Date:   2024-02-05 (Mon, 05 Feb 2024)

  Changed paths:
M metadata/contributors.json

  Log Message:
  ---
  Update Sammy Gill GitHub username.
https://bugs.webkit.org/show_bug.cgi?id=268791
rdar://problem/122352874

Reviewed by Tim Nguyen.

Changed username from sgill26 to sammygill.

* metadata/contributors.json:

Canonical link: https://commits.webkit.org/274130@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 81962d: [UnifiedPDF] Refactor annotation tracking logic in...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 81962dc8143b9e02da51e61edd07e9c8761454ad
  
https://github.com/WebKit/WebKit/commit/81962dc8143b9e02da51e61edd07e9c8761454ad
  Author: Sammy Gill 
  Date:   2024-02-05 (Mon, 05 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Refactor annotation tracking logic into its own class.
https://bugs.webkit.org/show_bug.cgi?id=268670
rdar://problem/122211531

Reviewed by Simon Fraser and Tim Horton.

Instead of haphazardly modifying and keeping track of the logic needed
to track annotations through mouse events, we can refactor this logic
into its own class and make the rest of the UnifiedPDFPlugin logic
simpler. Whenever we need to actually modify any annotation tracking
state, the calling code will do so by using startAnnotationTracking or
finishAnnotationTracking. The state will be modified by taking into
consideration the type of annotation, the mouse event type, and mouse
event button.

The annotation that is being tracked can be accessed via
trackedAnnotation(). If any other state needs to be kept and queried
in the future (e.g. state that helps know if annotation is being
hovered that I plan on adding), it can be done by adding extra fields
to this class.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
(WebKit::AnnotationTrackingState::trackedAnnotation const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::AnnotationTrackingState::startAnnotationTracking):
(WebKit::AnnotationTrackingState::finishAnnotationTracking):
(WebKit::AnnotationTrackingState::handleMouseDraggedOffTrackedAnnotation):
(WebKit::UnifiedPDFPlugin::startAnnotationTracking): Deleted.
(WebKit::UnifiedPDFPlugin::finishAnnotationTracking): Deleted.
(WebKit::UnifiedPDFPlugin::handleMouseDraggedOffTrackedAnnotation): Deleted.

Canonical link: https://commits.webkit.org/274095@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9e6c27: [UnifiedPDF] Text annotation HTML inputs do not ge...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9e6c27d881d0057a37b86cc3062bd968c12b33b4
  
https://github.com/WebKit/WebKit/commit/9e6c27d881d0057a37b86cc3062bd968c12b33b4
  Author: Sammy Gill 
  Date:   2024-02-02 (Fri, 02 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Text annotation HTML inputs do not get repositioned or scaled 
when zooming
https://bugs.webkit.org/show_bug.cgi?id=268360
rdar://121907350

Reviewed by Tim Horton.

UnifiedPDFPlugin was incorrectly returning the annotation bounds in
document space when the PDFPluginAnnotation was expecting the bounds in
plugin view space. Fix this by providing the bounds in the correct coordinate
space so that it can update its geomtetry correctly. This requires
that PDFPluginAnnotation stops subtracting out the scroll positions
since this is part of the document to plugin space translation.

The size of the annotation should be determined with both the document
fitting sale and the zoom scale.

Also rename boundsForannotation to pluginBoundsForAnnotation to make it
clear what coordinate space this function is returning geometry in.

* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::pluginBoundsForAnnotation const):
(WebKit::PDFPlugin::boundsForAnnotation const): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.mm:
(WebKit::PDFPluginAnnotation::updateGeometry):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::convertFromDocumentToPlugin const):
(WebKit::UnifiedPDFPlugin::pluginBoundsForAnnotation const):
(WebKit::UnifiedPDFPlugin::boundsForAnnotation const): Deleted.

Canonical link: https://commits.webkit.org/274038@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] dceee4: [UnifiedPDF] Support radio buttons, checkboxes, an...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: dceee48d7d3f9528cc05346a2a765fd7588485bc
  
https://github.com/WebKit/WebKit/commit/dceee48d7d3f9528cc05346a2a765fd7588485bc
  Author: Sammy Gill 
  Date:   2024-02-01 (Thu, 01 Feb 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Support radio buttons, checkboxes, and choice annotations.
https://bugs.webkit.org/show_bug.cgi?id=268196
rdar://problem/121692745

Reviewed by Simon Fraser.

Choice annotations are similar to text widget annotations, which we
already support, in that they use a PDFPluginAnnotation to support
user interaction and just commit the result to the underlying annotation
afterwards.

Radio buttons and checkboxes involve slightly more work as we must keep
track of the mouse as the user interacts with them. Holding the left
mouse button on them will create a highlight effect indicating that this
action is occuring and releasing it will trigger the effect of the
checkbox/radio button. If the mouse is dragged off while the left mouse
button is held down on it, then the highlight disappears and no effect
should occur when the button is released. In order to accomplish this,
we need to start tracking the annotation that is being interacted with
through various mouse events. m_trackedAnnotation was added for this
purpose and is updated through the various events.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::annotationForRootViewPoint const):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::startAnnotationTracking):
(WebKit::UnifiedPDFPlugin::finishAnnotationTracking):
(WebKit::UnifiedPDFPlugin::handleMouseDraggedOffTrackedAnnotation):

Canonical link: https://commits.webkit.org/273921@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ed7b19: iOS build broken after 273837@main

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ed7b19896be4fbd22b519f7d3e5b7b77fddce6f2
  
https://github.com/WebKit/WebKit/commit/ed7b19896be4fbd22b519f7d3e5b7b77fddce6f2
  Author: Sammy Gill 
  Date:   2024-01-31 (Wed, 31 Jan 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  iOS build broken after 273837@main
https://bugs.webkit.org/show_bug.cgi?id=268486
rdar://122029805

Unreviewed build fix.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::didChangeScrollOffset):

Canonical link: https://commits.webkit.org/273846@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 14b3ba: [UnifiedPDF] Text annotation HTML inputs do not ge...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 14b3ba128b7aa7dfbd192866ded19359364e1dcf
  
https://github.com/WebKit/WebKit/commit/14b3ba128b7aa7dfbd192866ded19359364e1dcf
  Author: Sammy Gill 
  Date:   2024-01-31 (Wed, 31 Jan 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Text annotation HTML inputs do not get repositioned when 
scrolling
https://bugs.webkit.org/show_bug.cgi?id=268358
rdar://121907236

Reviewed by Simon Fraser.

When the scroll offset is changed, we should make sure that the geometry
of any active annotation gets updated also. The annotation will update
its location based off the new scroll position.

* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::didChangeScrollOffset):

Canonical link: https://commits.webkit.org/273837@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 32bbe7: Cherry-pick 268964@main (3f64447f2aa9). https://bu...

[Sammy Gill]

24)

  Changed paths:
M Source/JavaScriptCore/llint/LLIntOpcode.h
M Source/JavaScriptCore/llint/LowLevelInterpreter.cpp

  Log Message:
  ---
  Cherry-pick 272012@main (aa62ce7b9059). 
https://bugs.webkit.org/show_bug.cgi?id=266294

BYTECODE_HELPER_ID LLint opcodes need look up for wide versions.
https://bugs.webkit.org/show_bug.cgi?id=266294
rdar://119563251

Reviewed by Justin Michaud.

FOR_EACH_BYTECODE_HELPER_ID was mistakenly lumped in with 
FOR_EACH_LLINT_NATIVE_HELPER, which
does not populate their entries in g_opcodeMapWide16 and g_opcodeMapWide32. 
 This patch fixes
that.

This was causing CLoop runs to crash on nullptr derefs on these 
non-initialized entries.

* Source/JavaScriptCore/llint/LLIntOpcode.h:
* Source/JavaScriptCore/llint/LowLevelInterpreter.cpp:
(JSC::CLoop::execute):

Canonical link: https://commits.webkit.org/272012@main


  Commit: 78b6821d76ed2889788e1215b883247a74267894
  
https://github.com/WebKit/WebKit/commit/78b6821d76ed2889788e1215b883247a74267894
  Author: Youenn Fablet 
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
M Source/WebKit/NetworkProcess/cache/NetworkCacheSubresourcesEntry.h

  Log Message:
  ---
  Cherry-pick 272062@main (3096c561acce). 
https://bugs.webkit.org/show_bug.cgi?id=265634

Samesite=Lax is not always working in Safari
https://bugs.webkit.org/show_bug.cgi?id=265634
rdar://119362503

Reviewed by Brent Fulgham and Alex Christensen.

We were not setting isSameSite correctly when reading it from disk cache, 
which was then triggering different cookies being sent between
speculative loads and the actual would be loads.
Websites could use Vary Cookie headers to handle that case, but they do not 
tend to.

* Source/WebKit/NetworkProcess/cache/NetworkCacheSubresourcesEntry.h:
(WebKit::NetworkCache::SubresourceInfo::SubresourceInfo):

Canonical link: https://commits.webkit.org/272062@main


  Commit: 9d55c4dceb7e18a287613a1ceb1c1d7d35e3b751
  
https://github.com/WebKit/WebKit/commit/9d55c4dceb7e18a287613a1ceb1c1d7d35e3b751
  Author: Sammy Gill 
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows.html
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp

  Log Message:
  ---
  Cherry-pick 272085@main (cf2a9868136a). 
https://bugs.webkit.org/show_bug.cgi?id=260201

REGRESSION(261003@main): [css-contain][css-grid] Size containment is not 
allowing the track sizing algorithm to distribute extra space to auto tracks
https://bugs.webkit.org/show_bug.cgi?id=260201
rdar://problem/113915953

Reviewed by Brent Fulgham.

Size containment is supposed to size a box as if it had no content, so
for the purposes of grid layout this would mean that we would want to
skip parts of the algorithm that take into consideration the content.

The "Stretch auto Tracks," portion of the grid track sizing algorithm
should not be skipped, however, as it has nothing to do with the content
of the grid. We should be able to distribute any definite free space
that we computed up to this point.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows.html:
 Added.
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::run):

Canonical link: https://commits.webkit.org/272085@main


Compare: https://github.com/WebKit/WebKit/compare/e136566934c0...9d55c4dceb7e
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e0038b: [UnifiedPDF] Start handling text widget annotations.

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e0038b5b7ace4173ca4547fbbf9f4e124dec0675
  
https://github.com/WebKit/WebKit/commit/e0038b5b7ace4173ca4547fbbf9f4e124dec0675
  Author: Sammy Gill 
  Date:   2024-01-24 (Wed, 24 Jan 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Start handling text widget annotations.
https://bugs.webkit.org/show_bug.cgi?id=267967
rdar://problem/121474907

Reviewed by Simon Fraser.

To start handling text annotations, we start by handling mouse left
clicks. When doing this we check to see if there is an annotation under
the left click event and if is a text annotation widget. If this is the
case then we will set the active annotation to this one (making sure
to commit any other previously active annotation).

The PDFPluginAnnotation that is created will need the bounds for the
underlying annotation to properly style the HTML input element that is
used. This is a matter of getting the bounds from the annotation, which
is in page space, and then converting it into document space. Before
this patch the PDFPluginAnnotation was performing this conversion, but
I moved this responsibility to the PDFPlugins instead so that the
annotations can just do everything in document space.

* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::boundsForAnnotation const):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.mm:
(WebKit::PDFPluginAnnotation::updateGeometry):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.mm:
(WebKit::PDFDocumentLayout::indexForPage const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::UnifiedPDFPlugin):
(WebKit::documentSpaceToPageSpaceTransform):
(WebKit::UnifiedPDFPlugin::convertFromDocumentToPage const):
(WebKit::UnifiedPDFPlugin::convertFromPageToDocument const):
(WebKit::UnifiedPDFPlugin::handleMouseEvent):
(WebKit::UnifiedPDFPlugin::boundsForAnnotation const):
(WebKit::UnifiedPDFPlugin::setActiveAnnotation):

Canonical link: https://commits.webkit.org/273456@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a41c12: [UnifiedPDF] Make PDFPluginAnnotations agnostic of...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a41c12c7f45ac004a807697b084279562ac41f6f
  
https://github.com/WebKit/WebKit/commit/a41c12c7f45ac004a807697b084279562ac41f6f
  Author: Sammy Gill 
  Date:   2024-01-19 (Fri, 19 Jan 2024)

  Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginPasswordField.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginPasswordField.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Make PDFPluginAnnotations agnostic of plugin implementation.
https://bugs.webkit.org/show_bug.cgi?id=266097
rdar://problem/119397505

Reviewed by Simon Fraser.

Currently PDFPluginAnnotations depends on the PDFLayerController to
interact with the PDF. In order to get the UnifiedPDFPlugin working
with annotations, the plugin annotations need to move away from this
dependence and instead use an API that is agnostic of the underlying
plugin implementation.

This requires two main things:
1.) PDFPluginAnnotations should no longer hold onto a PDFLayerController
2.) They should hold onto a PDFPluginBase instead of a PDFPlugin

Any PDFPlugin API that was used by the plugin annotations needs to be
moved over to PDFPluginBase as virtual functions. Similarly, any
functionality from the PDFLayerController that was used should be
exposed in the same way.

* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::createPasswordEntryForm):
(WebKit::PDFPlugin::setActiveAnnotation):
(WebKit::PDFPlugin::boundsForAnnotation const):
(WebKit::PDFPlugin::contentSizeRespectingZoom const):
(WebKit::PDFPlugin::supportsForms): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.h:
(WebKit::PDFPluginAnnotation::plugin const):
(WebKit::PDFPluginAnnotation::PDFPluginAnnotation):
(WebKit::PDFPluginAnnotation::parent const):
(WebKit::PDFPluginAnnotation::pdfLayerController const): Deleted.
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginAnnotation.mm:
(WebKit::PDFPluginAnnotation::create):
(WebKit::PDFPluginAnnotation::updateGeometry):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::didMutatePDFDocument):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::supportsForms):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.h:
(WebKit::PDFPluginChoiceAnnotation::PDFPluginChoiceAnnotation):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginChoiceAnnotation.mm:
(WebKit::PDFPluginChoiceAnnotation::create):
(WebKit::PDFPluginChoiceAnnotation::updateGeometry):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginPasswordField.h:
(WebKit::PDFPluginPasswordField::PDFPluginPasswordField):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginPasswordField.mm:
(WebKit::PDFPluginPasswordField::create):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.h:
(WebKit::PDFPluginTextAnnotation::PDFPluginTextAnnotation):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm:
(WebKit::PDFPluginTextAnnotation::create):
(WebKit::PDFPluginTextAnnotation::updateGeometry):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::contentSizeRespectingZoom const):
(WebKit::UnifiedPDFPlugin::boundsForAnnotation const):
(WebKit::UnifiedPDFPlugin::focusNextAnnotation):
(WebKit::UnifiedPDFPlugin::focusPreviousAnnotation):
(WebKit::UnifiedPDFPlugin::setActiveAnnotation):
(WebKit::UnifiedPDFPlugin::attemptToUnlockPDF):

Canonical link: https://commits.webkit.org/273241@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 78a954: Overflow should establish an independent formattin...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 78a954e5a2bd3f1acacb08e8fd5c370809ea4fe7
  
https://github.com/WebKit/WebKit/commit/78a954e5a2bd3f1acacb08e8fd5c370809ea4fe7
  Author: Sammy Gill 
  Date:   2024-01-17 (Wed, 17 Jan 2024)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/overflow-hidden-does-not-prohibit-subgrid-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/overflow-hidden-does-not-prohibit-subgrid.html
M Source/WebCore/rendering/RenderBox.h
M Source/WebCore/rendering/RenderBoxInlines.h
M Source/WebCore/rendering/RenderElement.cpp
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/rendering/RenderObjectInlines.h

  Log Message:
  ---
  Overflow should establish an independent formatting context on only block 
boxes.
https://bugs.webkit.org/show_bug.cgi?id=267085
rdar://problem/120848131

Reviewed by Tim Nguyen.

css-overflow-3 states: If the computed value of overflow on a block box
is neither visible nor clip nor a combination thereof, it establishes
an independent formatting context for its contents.
https://drafts.csswg.org/css-overflow-3/#overflow-control

This means other types of boxes (e.g. grid items or flex items)
should not be establshing independent formatting contexts. This is
important in cases such as when a grid item is also a subgrid. If a grid
item which is supposed to be a subgrid establishes an independent
formatting context (e.g. due to layout containment), then the grid item
would not actually be a subgrid. A grid item with certain values of
overflow do not appear to be a case in which this would occur.

Currently establishesIndependentFormattingContext returns true
unconditionally if hasPotentiallyScrollableOverflow() returns true.
Instead, we should make sure this only occurs if the box is a block box
to match the spec.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/overflow-hidden-does-not-prohibit-subgrid-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/overflow-hidden-does-not-prohibit-subgrid.html:
 Added.
* Source/WebCore/rendering/RenderBox.h:
(WebCore::RenderBox::isFlexItem const):
* Source/WebCore/rendering/RenderBoxInlines.h:
(WebCore::RenderBox::intrinsicLogicalHeight const):
(WebCore::RenderBox::isBlockLevelBox const): Deleted.
* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::establishesIndependentFormattingContext const):
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::isBlockBox const):
* Source/WebCore/rendering/RenderObject.h:
* Source/WebCore/rendering/RenderObjectInlines.h:
(WebCore::RenderObject::isBlockLevelBox const):

Canonical link: https://commits.webkit.org/273134@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9abc57: Use CheckedRef inside render tree's FlexItem

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9abc579db90c65162c39830cd913b943f0f8c0cf
  
https://github.com/WebKit/WebKit/commit/9abc579db90c65162c39830cd913b943f0f8c0cf
  Author: Sammy Gill 
  Date:   2024-01-10 (Wed, 10 Jan 2024)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-column-inline-multiline.html
M Source/WebCore/rendering/FlexibleBoxAlgorithm.cpp
M Source/WebCore/rendering/FlexibleBoxAlgorithm.h
M Source/WebCore/rendering/RenderFlexibleBox.cpp

  Log Message:
  ---
  Use CheckedRef inside render tree's FlexItem
https://bugs.webkit.org/show_bug.cgi?id=267301
rdar://120751074

Reviewed by Alan Baradlay.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-column-inline-multiline.html:
* Source/WebCore/rendering/FlexibleBoxAlgorithm.cpp:
(WebCore::FlexLayoutAlgorithm::removeMarginEndFromFlexSizes const):
(WebCore::FlexLayoutAlgorithm::computeNextFlexLine):
* Source/WebCore/rendering/FlexibleBoxAlgorithm.h:
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::trimMainAxisMarginStart):
(WebCore::RenderFlexibleBox::trimMainAxisMarginEnd):
(WebCore::RenderFlexibleBox::layoutFlexItems):
(WebCore::RenderFlexibleBox::autoMarginOffsetInMainAxis):
(WebCore::RenderFlexibleBox::freezeViolations):
(WebCore::RenderFlexibleBox::freezeInflexibleItems):
(WebCore::RenderFlexibleBox::resolveFlexibleLengths):
(WebCore::RenderFlexibleBox::layoutAndPlaceChildren):
(WebCore::RenderFlexibleBox::layoutColumnReverse):
(WebCore::RenderFlexibleBox::alignChildren):
(WebCore::RenderFlexibleBox::flipForRightToLeftColumn):

Canonical link: https://commits.webkit.org/272884@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6bdeb8: [css-grid] Margins for grid item's ascent should b...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6bdeb823e16e81ec11433826136fb738e1b00981
  
https://github.com/WebKit/WebKit/commit/6bdeb823e16e81ec11433826136fb738e1b00981
  Author: Sammy Gill 
  Date:   2024-01-10 (Wed, 10 Jan 2024)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-001-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-002-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-justify-baseline-002-expected.txt
M Source/WebCore/rendering/GridBaselineAlignment.cpp
M Source/WebCore/rendering/RenderBox.h

  Log Message:
  ---
  [css-grid] Margins for grid item's ascent should be based off of the 
alignment context axis.
https://bugs.webkit.org/show_bug.cgi?id=260570
rdar://114299208

Reviewed by Matt Woodrow.

The ascent value for a grid item needs to include its margin alongside
its baseline value since grid items are aligned by their margin box.

Currently code uses isDescentBaselineForChild to determine whether it
should get its margin using marginUnderForChild or marginOverForchild.
It is not super clear why these two functions are choosing certain
margins off the grid item's margin box.

Choosing which margin to use should just be a matter of checking which
direction the alignment context is in. If the alignment context
direction is in the grid's column axis (i.e. grid items are being
aligned in the grid's block direction), then that should be the grid
item's block-start margin according to the grid's writing mode.
Similarly, if the alignment context direction is in the row axis (i.e.
grid items are being aligned in the grid's inline direction), then that
should be the grid item's inline-start margin according to the grid's
writing mode.

I also renamed the variable "margin," to "gridItemMargin," to better
reflect what it corresponds to. Instances where this value was being
added to the grid item's baseline value have also been changed to be in
the form of "gridItemMargin + gridItemBaseline" since that is generally
the order in which we depict/imagine the structure of the ascent value.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-001-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-002-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-justify-baseline-002-expected.txt:
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::ascentForChild const):
(WebCore::GridBaselineAlignment::marginOverForChild const): Deleted.
(WebCore::GridBaselineAlignment::marginUnderForChild const): Deleted.
* Source/WebCore/rendering/RenderBox.h:
(WebCore::RenderBox::marginBlockStart const):
(WebCore::RenderBox::marginInlineStart const):

Canonical link: https://commits.webkit.org/272860@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5e996b: [css-grid] Rename GridBaselineAlignment's m_blockF...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5e996b5167f06a420715b3718bdf05860eaa5b3e
  
https://github.com/WebKit/WebKit/commit/5e996b5167f06a420715b3718bdf05860eaa5b3e
  Author: Sammy Gill 
  Date:   2024-01-02 (Tue, 02 Jan 2024)

  Changed paths:
M Source/WebCore/rendering/GridBaselineAlignment.cpp
M Source/WebCore/rendering/GridBaselineAlignment.h
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp

  Log Message:
  ---
  [css-grid] Rename GridBaselineAlignment's m_blockFlow to m_writingMode.
https://bugs.webkit.org/show_bug.cgi?id=266993
rdar://problem/120379902

Reviewed by Tim Nguyen.

This variable refers to the grid's writing mode and not its block flow
direction. We can get the block flow direction from the writing mode,
but we also need to know its writing mode since the spec will use it in
certain scenarions.

See: https://drafts.csswg.org/css-align-3/#baseline-export

* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::ascentForChild const):
(WebCore::GridBaselineAlignment::isDescentBaselineForChild const):
(WebCore::GridBaselineAlignment::isHorizontalBaselineAxis const):
(WebCore::GridBaselineAlignment::isOrthogonalChildForBaseline const):
* Source/WebCore/rendering/GridBaselineAlignment.h:
(WebCore::GridBaselineAlignment::setWritingMode):
(WebCore::GridBaselineAlignment::setBlockFlow): Deleted.
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::computeBaselineAlignmentContext):

Canonical link: https://commits.webkit.org/272582@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] fcb681: [css-grid] Rename GridBaselineAlignment's isBaseli...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: fcb681a31f038cac1be045d5b5491a53ec0f42dc
  
https://github.com/WebKit/WebKit/commit/fcb681a31f038cac1be045d5b5491a53ec0f42dc
  Author: Sammy Gill 
  Date:   2024-01-02 (Tue, 02 Jan 2024)

  Changed paths:
M Source/WebCore/rendering/GridBaselineAlignment.cpp
M Source/WebCore/rendering/GridBaselineAlignment.h

  Log Message:
  ---
  [css-grid] Rename GridBaselineAlignment's isBaselineAxis variables and 
GridBaselineAlignment::isHorizontalBaselineAxis.
https://bugs.webkit.org/show_bug.cgi?id=266991
rdar://problem/120378682

Reviewed by Alan Baradlay.

There are spec terms that can be used to better represent what these
variables are capturing. The baselineAxis variables seem to be referring
to which direction in which alignment is occurring. The "baseline axis,"
is not a spec term, but the "alignment axis" is so we should use that
instead. I changed all instances of baselineAxis as well as various
function arguments that were just "axis," since those were being passed
in baselineAxis anyway.

I also changed isHorizontalBaselineAxis to isVerticalAlignmentContext.
These are equivalent since whenever the axis of the alignment context is
vertical that means we have a horizontal alignment axis. It is better
to know the direction of the alignment context axis anyways since the
spec makes decisions based off of that.

https://drafts.csswg.org/css-align-3/
https://drafts.csswg.org/css-align-3/#baseline-rules

* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::marginOverForChild const):
(WebCore::GridBaselineAlignment::marginUnderForChild const):
(WebCore::GridBaselineAlignment::logicalAscentForChild const):
(WebCore::GridBaselineAlignment::ascentForChild const):
(WebCore::GridBaselineAlignment::descentForChild const):
(WebCore::GridBaselineAlignment::isDescentBaselineForChild const):
(WebCore::GridBaselineAlignment::isVerticalAlignmentContext const):
(WebCore::GridBaselineAlignment::isParallelToAlignmentAxisForChild const):
(WebCore::GridBaselineAlignment::baselineGroupForChild const):
(WebCore::GridBaselineAlignment::updateBaselineAlignmentContext):
(WebCore::GridBaselineAlignment::baselineOffsetForChild const):
(WebCore::GridBaselineAlignment::clear):
(WebCore::GridBaselineAlignment::isHorizontalBaselineAxis const): Deleted.
(WebCore::GridBaselineAlignment::isParallelToBaselineAxisForChild const): 
Deleted.
* Source/WebCore/rendering/GridBaselineAlignment.h:

Canonical link: https://commits.webkit.org/272579@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 57fdd1: [css-contain][css-grid] Relax size containment con...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 57fdd17822df399a4c26a0a3f3ad8342051c1eff
  
https://github.com/WebKit/WebKit/commit/57fdd17822df399a4c26a0a3f3ad8342051c1eff
  Author: Sammy Gill 
  Date:   2023-12-19 (Tue, 19 Dec 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-indefinite-height-min-height-flex-row-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-indefinite-height-min-height-flex-row.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-indefinite-height-min-height-flex-row-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-indefinite-height-min-height-flex-row.html
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/RenderGrid.h

  Log Message:
  ---
  [css-contain][css-grid] Relax size containment constraints on "Expand 
Flexible Tracks," portion of grid track sizing algorithm.
https://bugs.webkit.org/show_bug.cgi?id=266506
rdar://119736473

Reviewed by Alan Baradlay.

This patch expands upon 272085@main which fixed a bug related to an
interaction between grid layout and size containment. In particular,
the patch allowed the grid track sizing algorithm to stretch auto sized
tracks even during size containment.

For the exact same reason we also want to relax the size containment
constraint imposed upon the grid track sizing algorithm to allow it to
perform portions of the "Expand Flexible Tracks," section. The only
portion of this step we want to skip is when we are computing the flex
fraction and the free space is indefinite, since this is the only part of
this section that takes into consideration the grid's contents. To
compute the flex fraction in this case, the spec says that it is the
maximum of:

- For each flexible track, if the flexible track’s flex factor is
greater than one, the result of dividing the track’s base size by its
flex factor; otherwise, the track’s base size.
- For each grid item that crosses a flexible track, the result of
finding the size of an fr using all the grid tracks that the item
crosses and a space to fill of the item’s max-content contribution.

During the size containment "Sizing as if empty," phase we can
completely take into consideration the first computation, but we should
not compute or consider the second.

https://drafts.csswg.org/css-contain/#containment-size
https://drafts.csswg.org/css-grid-2/#algo-flex-tracks

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-indefinite-height-min-height-flex-row-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-indefinite-height-min-height-flex-row.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-indefinite-height-min-height-flex-row-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-indefinite-height-min-height-flex-row.html:
 Added.
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::IndefiniteSizeStrategy::findUsedFlexFraction const):
(WebCore::GridTrackSizingAlgorithm::run):
* Source/WebCore/rendering/RenderGrid.h:

Canonical link: https://commits.webkit.org/272276@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] cf2a98: REGRESSION(261003@main): [css-contain][css-grid] S...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: cf2a9868136a77126003c51af66e7e1b13220ae4
  
https://github.com/WebKit/WebKit/commit/cf2a9868136a77126003c51af66e7e1b13220ae4
  Author: Sammy Gill 
  Date:   2023-12-14 (Thu, 14 Dec 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows.html
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp

  Log Message:
  ---
  REGRESSION(261003@main): [css-contain][css-grid] Size containment is not 
allowing the track sizing algorithm to distribute extra space to auto tracks
https://bugs.webkit.org/show_bug.cgi?id=260201
rdar://problem/113915953

Reviewed by Brent Fulgham.

Size containment is supposed to size a box as if it had no content, so
for the purposes of grid layout this would mean that we would want to
skip parts of the algorithm that take into consideration the content.

The "Stretch auto Tracks," portion of the grid track sizing algorithm
should not be skipped, however, as it has nothing to do with the content
of the grid. We should be able to distribute any definite free space
that we computed up to this point.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows.html:
 Added.
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::run):

Canonical link: https://commits.webkit.org/272085@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9a598c: [Test Gardening] css-contain/contain-size-block-00...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9a598c84d4d6fd610d63fdf1b4d1d9a091765ea8
  
https://github.com/WebKit/WebKit/commit/9a598c84d4d6fd610d63fdf1b4d1d9a091765ea8
  Author: Sammy Gill 
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
M LayoutTests/TestExpectations
M LayoutTests/platform/gtk/TestExpectations

  Log Message:
  ---
  [Test Gardening] css-contain/contain-size-block-003.html and 
css-contain/contain-size-inline-block-003.html only fail on GTK.
https://bugs.webkit.org/show_bug.cgi?id=266345
rdar://problem/119617786

Unreviewed, test gardening.

* LayoutTests/TestExpectations:
* LayoutTests/platform/gtk/TestExpectations:

Canonical link: https://commits.webkit.org/272010@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] efb0cb: [css-flex] Flex layout should not invalidate prefe...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: efb0cb853cc0218e2a987af1a313ec360ea1419c
  
https://github.com/WebKit/WebKit/commit/efb0cb853cc0218e2a987af1a313ec360ea1419c
  Author: Sammy Gill 
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/nested-flex-image-loading-invalidates-intrinsic-sizes-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/nested-flex-image-loading-invalidates-intrinsic-sizes.html
M Source/WebCore/rendering/RenderFlexibleBox.cpp

  Log Message:
  ---
  [css-flex] Flex layout should not invalidate preferred width bits of flex 
items at the end of layout.
https://bugs.webkit.org/show_bug.cgi?id=264303
rdar://117181858

Reviewed by Alan Baradlay.

In certain situations flex layout will invalidate the preferred widths
bits of flex items towards the end of layout (in layoutAndPlaceChildren),
with a call to updateBlockChildDirtyBitsBeforeLayout. This is incorrect
since by the time we reach layoutAndPlaceChildren flex layout will not
compute the preferred widths of these items again. This leaves the
render tree in a bad state where we may compute the preferred widths
of a flex item at some point during layout, dirty this bit later, and
exit layout with this bit dirtied.

In this state we may not be able to correctly invalidate the ancestor
chain of a flex item in certain situations like in the added test case.
When the image is loaded in the test case we will be unable to
invalidate the preferred widths bits of its ancestor chain since the
item had already been dirtied so we assume the rest of the chain has
already been handled.

Instead, we should be performing this type of invalidation in one of
the following scenarios:
1.) The content of a flex item changes
2.) Certain style changes on the flex item that would impact the
preferred widths computations of its items. One example of this is a
flex item with an aspect ratio since the aspect ratio could impact its
"content based minimum size," if the flexbox's cross size size changes
in a specific way: 
https://drafts.csswg.org/css-flexbox-1/#content-based-minimum-size

This patch focuses on correcting flex layout to more closely follow
the principles in 2. updateFlexItemDirtyBitsBeforeLayout was added to
replace the call to updateBlockChildDirtyBitsBeforeLayout so that we
can continue to dirty flex items for layout without dirtying their
preferred widths bits as well.

Instead, in RenderFlexibleBox::styleDidChange we can call
needsPreferredWidthsRecalculation on each flex item to determine if we
should dirty the preferred widths bit of it.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/nested-flex-image-loading-invalidates-intrinsic-sizes-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/nested-flex-image-loading-invalidates-intrinsic-sizes.html:
 Added.
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::updateFlexItemDirtyBitsBeforeLayout):
(WebCore::RenderFlexibleBox::styleDidChange):
(WebCore::RenderFlexibleBox::layoutAndPlaceChildren):

Canonical link: https://commits.webkit.org/271995@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2a7a56: [UnifiedPDF] Add display mode options to context m...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2a7a56ba875aa86999ee64b2bcdf53e4e0e82929
  
https://github.com/WebKit/WebKit/commit/2a7a56ba875aa86999ee64b2bcdf53e4e0e82929
  Author: Sammy Gill 
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
M Source/WebCore/platform/LocalizedStrings.cpp
M Source/WebCore/platform/LocalizedStrings.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Add display mode options to context menu.
https://bugs.webkit.org/show_bug.cgi?id=265827
rdar://problem/119155634

Reviewed by Tim Horton and Simon Fraser.

Adds the option to select the display mode from the context menu. Also
updates the selected choice on PDFDocumentLayout and performs a layout
again to reflect the new value.

* Source/WebCore/platform/LocalizedStrings.cpp:
(WebCore::contextMenuItemPDFSinglePage):
(WebCore::contextMenuItemPDFSinglePageContinuous):
(WebCore::contextMenuItemPDFTwoPages):
(WebCore::contextMenuItemPDFTwoPagesContinuous):
(WebCore::contextMenuItemPDFAutoSize):
(WebCore::contextMenuItemPDFZoomIn):
(WebCore::contextMenuItemPDFZoomOut):
(WebCore::contextMenuItemPDFActualSize):
* Source/WebCore/platform/LocalizedStrings.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDocumentLayout.h:
(WebKit::PDFDocumentLayout::setDisplayMode):
(WebKit::PDFDocumentLayout::displayMode const):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::createContextMenu const):
(WebKit::UnifiedPDFPlugin::performContextMenuAction):
(WebKit::UnifiedPDFPlugin::performContextMenuAction const): Deleted.

Canonical link: https://commits.webkit.org/271573@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6e2b89: Replace bools in PDFContextMenuItem with enum clas...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6e2b89f53e56d4171becce375bf908ce725e9d30
  
https://github.com/WebKit/WebKit/commit/6e2b89f53e56d4171becce375bf908ce725e9d30
  Author: Sammy Gill 
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
M Source/WebKit/Shared/mac/PDFContextMenu.h
M Source/WebKit/Shared/mac/PDFContextMenuItem.serialization.in
M Source/WebKit/UIProcess/mac/WebPageProxyMac.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  Replace bools in PDFContextMenuItem with enum classes.
https://bugs.webkit.org/show_bug.cgi?id=265815.
rdar://problem/119150073.

Reviewed by Simon Fraser.

enabled, separator, and hasAction are all bools which can be represented
as an enum class.

* Source/WebKit/Shared/mac/PDFContextMenu.h:
* Source/WebKit/Shared/mac/PDFContextMenuItem.serialization.in:
* Source/WebKit/UIProcess/mac/WebPageProxyMac.mm:
(WebKit::WebPageProxy::showPDFContextMenu):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::handleContextMenuEvent):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::createContextMenu const):

Canonical link: https://commits.webkit.org/271554@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6a92ad: [UnifiedPDF] Start creating context menu in Unifie...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6a92aded2a217de967647f6a04139b078abf36c5
  
https://github.com/WebKit/WebKit/commit/6a92aded2a217de967647f6a04139b078abf36c5
  Author: Sammy Gill 
  Date:   2023-12-02 (Sat, 02 Dec 2023)

  Changed paths:
M Source/WebCore/en.lproj/Localizable.strings
M Source/WebCore/platform/LocalizedStrings.cpp
M Source/WebCore/platform/LocalizedStrings.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  ---
  [UnifiedPDF] Start creating context menu in UnifiedPDFPlugin.
https://bugs.webkit.org/show_bug.cgi?id=265605
rdar://119001947

Reviewed by Simon Fraser.

UnifiedPDF will need to start creating its own context menu so we can
lay the initial groundwork by creating a context menu with a single
item. This will hopefully allow us to easily add additional items in
a subsequent patch without worrying about the architecture too much.
In this patch the item we will use will be the "Open with Preview,"
option.

UnifiedPDFPlugin will create its own PDFContextMenu with items and
send this over to the web page proxy. Each item will contain a tag that
is a ContextMenuAction that will be used to indicate what type of action
to perform once we get the result back.

* Source/WebCore/en.lproj/Localizable.strings:
* Source/WebCore/platform/LocalizedStrings.cpp:
(WebCore::contextMenuItemPDFOpenWithPreview):
* Source/WebCore/platform/LocalizedStrings.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::createContextMenu const):
(WebKit::UnifiedPDFPlugin::handleContextMenuEvent):
(WebKit::UnifiedPDFPlugin::performContextMenuAction const):

Canonical link: https://commits.webkit.org/271429@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2c5b45: [css-grid][aspect-ratio] availableLogicalHeightUsi...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2c5b45546cbb71e62c00d1fefb3f20afbb74f0d0
  
https://github.com/WebKit/WebKit/commit/2c5b45546cbb71e62c00d1fefb3f20afbb74f0d0
  Author: Sammy Gill 
  Date:   2023-11-01 (Wed, 01 Nov 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-with-aspect-ratio-uses-content-box-height-for-track-sizing-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-with-aspect-ratio-uses-content-box-height-for-track-sizing.html
M Source/WebCore/rendering/RenderBox.cpp

  Log Message:
  ---
  [css-grid][aspect-ratio] availableLogicalHeightUsing needs to consider 
AvailableLogicalHeightType when computing logical height from the aspect ratio
https://bugs.webkit.org/show_bug.cgi?id=263310
rdar://117138268

Reviewed by Alan Baradlay.

When availableLogicalHeightUsing determines that it needs to use the
box's logical width and aspect-ratio to compute the logical height, it
simply returns the value given from blockSizeFromAspectRatio. This is
not correct because blockSizeFromAspectRatio returns the computed border
box size which is not what the caller may want depending on the
specified value of heightType.

If the caller specifies a heightType of ExcludeMarginBorderPadding,
then we should remove the border and padding from the block sides of the
box. This is what grid expects when calling
availableLogicalHeight(ExcludeMarginBorderPadding)) to compute the
definite free space for the rows for the track sizing algorithm.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-with-aspect-ratio-uses-content-box-height-for-track-sizing-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-with-aspect-ratio-uses-content-box-height-for-track-sizing.html:
 Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::availableLogicalHeightUsing const):

Canonical link: https://commits.webkit.org/270098@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2688e1: [css-grid] Use synthesizedBaseline to synthesize t...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2688e1f33c192b78b77f2a49f787171cce7f6db1
  
https://github.com/WebKit/WebKit/commit/2688e1f33c192b78b77f2a49f787171cce7f6db1
  Author: Sammy Gill 
  Date:   2023-10-27 (Fri, 27 Oct 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt
M Source/WebCore/rendering/GridBaselineAlignment.cpp

  Log Message:
  ---
  [css-grid] Use synthesizedBaseline to synthesize the correct baseline of grid 
items in the column axis.
https://bugs.webkit.org/show_bug.cgi?id=263600
rdar://problem/117424263

Reviewed by Alan Baradlay.

Currently GridBaselineAlignment::ascentForChild does not correctly
syntheisze the central baseline in certain situations. It appears that
the current code attempts to only synthesize the alphabetic baseline.
Accoring to the spec, alignment-baseline: baseline, which is the initial
value, refers to the box's parent's dominant-baseline, which is the
initial value of "auto," since we do not implement it yet either.
The description for "dominant-baseline: auto," says:

Equivalent to alphabetic in horizontal writing modes and in vertical
writing modes when text-orientation is sideways. Equivalent to central
in vertical writing modes when text-orientation is mixed or upright.

Instead of attempting to synthesize the baseline within grid layout
code, we can use synthesizedBaseline in RenderBox which synthesizes
a baseline value depending on the arguments it is given. This function
will compute the central baseline of the box in the scenarios that are
described above in the property value's description. We perform this
logic only when we are aligning in the column axis and fallback to
the old behavior for the row axis. Attempting to change this logic for
both at this time causes regressions so a closer look will be needed in
order to address that case in a separate patch.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt:
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::ascentForChild const):

Canonical link: https://commits.webkit.org/269857@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b3db10: [css-grid] align-items/align-self: last baseline s...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b3db1071742474d5876270a3f5bd3d7c391dc083
  
https://github.com/WebKit/WebKit/commit/b3db1071742474d5876270a3f5bd3d7c391dc083
  Author: Sammy Gill 
  Date:   2023-10-25 (Wed, 25 Oct 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-005-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-007-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt
M Source/WebCore/rendering/GridBaselineAlignment.cpp
M Source/WebCore/rendering/GridBaselineAlignment.h
M Source/WebCore/rendering/GridLayoutFunctions.cpp
M Source/WebCore/rendering/GridLayoutFunctions.h
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp

  Log Message:
  ---
  [css-grid] align-items/align-self: last baseline should take into 
consideration the extra margin from non-orthogonal ancestor subgrids
https://bugs.webkit.org/show_bug.cgi?id=262646
rdar://problem/116484865

Reviewed by Matt Woodrow.

Grid performs last baseline alignment by using the "descent," value of
grid items, which is the distance from the under side of the grid item's
margin box to its ascent value. For subgridded items, this can include
extra margins imposed by ancestor subgrids. In order to properly
support subgridded items for last baseline alignment we need the extra
layer of margin on the under side of the grid item so that we can
properly compute its descent value. This patch is a first step at that
by focusing on the scenario in which we are aligning in the grid's
column axis (align-self/align-items) and there are no orthogonal
ancestor subgrids or orthogonal "root," grid.

This requires 3 main changes:
1.) Start using extraMarginForSubgridAncestors() to compute the margins
imposed by the ancestor subgrids. Previously, for first baseline
alignment, we were walking up the ancestor subgrid chain and collecting
the extra layer of margin. extraMarginForSubgridAncestors() already did
this (and includes the subgrids' gutters), so we should be using this
instead of duplicating code.

2.) Refactor extraMarginForSubgrid and extraMarginForSubgridAncestors
to return a new type: ExtraMarginsFromSubgrids. Instead of returning the
sum of the extra layer of margins both both sides of the track, this
struct keeps them separate and allows the caller to choose whether they
want the sum or the margins on a specific side.

3.) Pass extraTotalMargin() to descentForChild(). Since the descent
value is computed by finding the distance from the grid item's under
side of the margin box, extraTotalMargin() is needed to find the correct
side of the item's margin box with the extra layer of margins.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-005-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-007-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt:
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::logicalAscentForChild const):
(WebCore::GridBaselineAlignment::ascentForChild const):
(WebCore::GridBaselineAlignment::descentForChild const):
* Source/WebCore/rendering/GridBaselineAlignment.h:
* Source/WebCore/rendering/GridLayoutFunctions.cpp:
(WebCore::GridLayoutFunctions::extraMarginForSubgrid):
(WebCore::GridLayoutFunctions::extraMarginForSubgridAncestors):
(WebCore::GridLayoutFunctions::marginLogicalSizeForChild):
* Source/WebCore/rendering/GridLayoutFunctions.h:
(WebCore::ExtraMarginsFromSubgrids::extraTrackStartMargin const):
(WebCore::ExtraMarginsFromSubgrids::extraTrackEndMargin const):
(WebCore::ExtraMarginsFromSubgrids::extraTotalMargin const):
(WebCore::ExtraMarginsFromSubgrids::operator+=):
(WebCore::ExtraMarginsFromSubgrids::addTrackStartMargin):
(WebCore::ExtraMarginsFromSubgrids::addTrackEndMargin):
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithmStrategy::updateOverridingContainingBlockContentSizeForChild
 const):

Canonical link: https://commits.webkit.org/269781@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] bc94fc: synthesizedBaseline uses incorrect line under edge...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: bc94fc496ea98de389ed201f55ab2b4f089a0f7e
  
https://github.com/WebKit/WebKit/commit/bc94fc496ea98de389ed201f55ab2b4f089a0f7e
  Author: Sammy Gill 
  Date:   2023-10-23 (Mon, 23 Oct 2023)

  Changed paths:
M LayoutTests/TestExpectations
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/baseline-synthesis-vert-lr-line-under-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/baseline-synthesis-vert-lr-line-under.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-container-baseline-001-expected.txt
M Source/WebCore/rendering/RenderBox.cpp

  Log Message:
  ---
  synthesizedBaseline uses incorrect line under edge for vertical-lr and 
sideways items
https://bugs.webkit.org/show_bug.cgi?id=263461
rdar://117273063

Reviewed by Alan Baradlay.

To synthesize a baseline, the spec says the following: "synthesize the
alphabetic baseline from the line-under line, and the central baseline
by averaging the positions of the two edges or lines."

When the writing mode is vertical-lr and text-orientation is sideways,
we must synthesize the alphabetic baseline. This means that the baseline
for the item in this writing-mode is its block-start and not the
block-end like in vertical-rl writing mode.

We can first determine the baseline that we are synthesizing according
to the logic in: 
https://drafts.csswg.org/css-inline-3/#dominant-baseline-property
If the baseline type is alphabetic and we are in a vertical-lr writing
mode according to the formatting context root, then we can return 0_lu
for the synthesized baseline.

* LayoutTests/TestExpectations:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/baseline-synthesis-vert-lr-line-under-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/baseline-synthesis-vert-lr-line-under.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-container-baseline-001-expected.txt:
* Source/WebCore/rendering/RenderBox.cpp:
 (WebCore::synthesizedBaseline):

Canonical link: https://commits.webkit.org/269668@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] dfe253: [css-grid] Introduce AncestorSubgridIterator

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: dfe2536d72733b14b2167988444f227ac3ca799f
  
https://github.com/WebKit/WebKit/commit/dfe2536d72733b14b2167988444f227ac3ca799f
  Author: Sammy Gill 
  Date:   2023-10-17 (Tue, 17 Oct 2023)

  Changed paths:
M Source/WebCore/Sources.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
A Source/WebCore/rendering/AncestorSubgridIterator.cpp
A Source/WebCore/rendering/AncestorSubgridIterator.h
M Source/WebCore/rendering/GridLayoutFunctions.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/style/GridPositionsResolver.cpp
M Source/WebCore/rendering/svg/RenderSVGPath.cpp

  Log Message:
  ---
  [css-grid] Introduce AncestorSubgridIterator
https://bugs.webkit.org/show_bug.cgi?id=263262
rdar://117083828

Reviewed by Matt Woodrow.

This patch adds an iterator that can be used to traverse a chain of
ancestor subgrids and also uses it in a few different places where it
can be used. The iterator is very similar to the RenderAncestorIterator,
but the main difference is that we need to check if the next ancestor
we are traversing is a subgrid in the appropriate direction.

There are two main ways to use the iterator:
1.) Providing the first subgrid ancestor that will be used in the
traversal along with the traversal direction.

2.) Using the ancestorSubgridsOfGridItem helper function. This is
useful when you have a subgridded item that you want to traverse the
ancestor subgrids of.

* Source/WebCore/Sources.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/rendering/AncestorSubgridIterator.cpp: Added.
(WebCore::AncestorSubgridIterator::AncestorSubgridIterator):
(WebCore::AncestorSubgridIterator::begin):
(WebCore::AncestorSubgridIterator::end):
(WebCore::AncestorSubgridIterator::operator++):
(WebCore::AncestorSubgridIterator::operator*):
(WebCore::AncestorSubgridIterator::operator== const):
(WebCore::ancestorSubgridsOfGridItem):
* Source/WebCore/rendering/AncestorSubgridIterator.h: Added.
* Source/WebCore/rendering/GridLayoutFunctions.cpp:
(WebCore::GridLayoutFunctions::extraMarginForSubgridAncestors):
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::accumulateIntrinsicSizesForTrack):
* Source/WebCore/rendering/style/GridPositionsResolver.cpp:
(WebCore::NamedLineCollection::NamedLineCollection):
* Source/WebCore/rendering/svg/RenderSVGPath.cpp:

Canonical link: https://commits.webkit.org/269443@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d28a4d: [css-grid] Resolve and set the row start, non-auto...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d28a4da714e84e52e8c59db1b828d7f601c34036
  
https://github.com/WebKit/WebKit/commit/d28a4da714e84e52e8c59db1b828d7f601c34036
  Author: Sammy Gill 
  Date:   2023-10-17 (Tue, 17 Oct 2023)

  Changed paths:
M 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/align-self-baseline-with-subgrid-mbp-expected.txt
M 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-005-expected.txt
M 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt
M 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-007-expected.txt
M 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.h
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderGrid.h

  Log Message:
  ---
  [css-grid] Resolve and set the row start, non-auto margins for subgrids with 
baseline aligned items.
https://bugs.webkit.org/show_bug.cgi?id=262508
rdar://problem/116369419

Reviewed by Matt Woodrow.

Note: This patch focuses on when we are performing baseline alignment
in the block direction of a grid (i.e. align-self/align-items).

When subgrids baseline align their items as part of alignment in the
outer grid, the sum of the subgrid's margin, border, and padding are
treated as an extra layer of margin for the grid item. Since an item's
margin is part of what determines the ascent value for the purposes of
baseline alignment, we must have that information when it gets added
into a baseline alignment context.

This process occurs at the end of the GridTrackSizingAlgorithm's setup
phase by the call to computeBaselineAlignmentContext, but the issue is
that by the time we call computeBaselineAlignmentContext none of the
subgrids have their margins resolved as part of their m_marginBox. This
information gets set during the actual grid track sizing algorithm when
the subgrid goes through layout as we attempt to compute the min content
size of the subgridded item.

When we call cacheBaselineAlignedChildren on the "root" grid (the grid
that subgrids will share tracks with), we can keep track of a bool that
is initially set to true to represent this state in which we want to
cache row subgrids. After we cache a baseline aligned item in
cacheBaselineAlignedItem we can then check to see if this flag is true
and also cache the item's grid if it is a row subgrid of the root grid.

Later on we will go through these subgrids and resolve their
margins just before we start creating the baseline alignment context
for the GridColumnAxis. We will only do this as part of the first/second
iteration of the row track sizing since we will just have determined the
size of the columns in the previous step. The sizes of the columns are
needed so that we can get the available width from the grid area the
subgrid is contained in, which may be needed to resolve its margins in
certain cases.

The affected tests below are brought more in like with their non-iOS
counterparts which share the same expected results. The discrepancy
between the two platforms is because on macOS, for example, an
additional layout occurs via a call to LocalFrameView::adjustViewSize
that does not occur when running the tests on iOS. The second layout
then uses the margin box information for the subgrids that was set
previously.

* 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/align-self-baseline-with-subgrid-mbp-expected.txt:
* 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-005-expected.txt:
* 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt:
* 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-007-expected.txt:
* 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt:
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::computeGridSpanSize):
(WebCore::GridTrackSizingAlgorithm::gridAreaBreadthForChild const):
(WebCore::GridTrackSizingAlgorithm::cacheBaselineAlignedItem):
(WebCore::GridTrackSizingAlgorithm::setup):
* Source/WebCore/rendering/GridTrackSizingAlgorithm.h:
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::cacheBaselineAlignedChildren):
(WebCore::RenderGrid::computeIntrinsicLogicalWidths const):
(WebCore::RenderGrid::isSubgridOf const):
(WebCore::RenderGrid::isSubgridOf): Deleted.
* Source/WebCore/rendering/RenderGrid.h:

Canonical link: https://commits.webkit.org/269424@main


___
webkit-changes mailing list
webk

[webkit-changes] [WebKit/WebKit] dedaa2: [css-grid] Anecstor subgrids' gutters should add t...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: dedaa29e2a66866ec206ffa113d0953eabc092ad
  
https://github.com/WebKit/WebKit/commit/dedaa29e2a66866ec206ffa113d0953eabc092ad
  Author: Sammy Gill 
  Date:   2023-10-11 (Wed, 11 Oct 2023)

  Changed paths:
M LayoutTests/TestExpectations
M Source/WebCore/rendering/GridLayoutFunctions.cpp
M Source/WebCore/rendering/GridLayoutFunctions.h
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp

  Log Message:
  ---
  [css-grid] Anecstor subgrids' gutters should add to the extra layer of margin 
for descendant subgrids
https://bugs.webkit.org/show_bug.cgi?id=260532
rdar://114271857

Reviewed by Matt Woodrow.

268947@main starts to accumulate the margin, border, and padding of
nested subgrids to act as a single layer of additional margin for the
track. This was needed for the specific scenario in which there were
subgrids without any items as for other types of grid items we would
walk back up the ancestor chain to compute this value. Subgrids are
treated differently so that behavior is not done and we needed this
extra change.

This patch aims to expand on the scenario by including the gutter sizes
from ancestor subgrids to this extra layer of margin. We can do this
by walking back up the ancestor chain to compute the total value of the
gutters that would act as an additional margin for items in the track.

This computation is only done if the subgrid's start/end position is one
of the lines of the track in the outer grid. Otherwise, this subgrid
spans *through* the track and cannot have the any gutters from subgrids
act as margins for this track.

Notably, we want to make sure that we do not add this value directly
to currentAccumulatedMbp and recurse into
accumulateIntrinsicSizesForTrack with it. We will compute this value
for each subgrid that acts as a grid item by walking up the ancestor
chain. This is because it is difficult to know ahead of time whether
a subgrid that is positioned in a track will have nested subgrids that
are also positioned in the same track and avoid adding the gutters
multiple times.

* LayoutTests/TestExpectations:
* Source/WebCore/rendering/GridLayoutFunctions.cpp:
(WebCore::GridLayoutFunctions::hasRelativeOrIntrinsicSizeForChild):
* Source/WebCore/rendering/GridLayoutFunctions.h:
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::accumulateIntrinsicSizesForTrack):

Canonical link: https://commits.webkit.org/269194@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 0d2e95: [css-grid] enums in grid code should be enum classes

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 0d2e95a2786bc89afe987be509593e5edbeece34
  
https://github.com/WebKit/WebKit/commit/0d2e95a2786bc89afe987be509593e5edbeece34
  Author: Sammy Gill 
  Date:   2023-10-10 (Tue, 10 Oct 2023)

  Changed paths:
M Source/WebCore/css/ComputedStyleExtractor.cpp
M Source/WebCore/rendering/Grid.cpp
M Source/WebCore/rendering/GridBaselineAlignment.cpp
M Source/WebCore/rendering/GridLayoutFunctions.cpp
M Source/WebCore/rendering/GridLayoutFunctions.h
M Source/WebCore/rendering/GridMasonryLayout.cpp
M Source/WebCore/rendering/GridMasonryLayout.h
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.h
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderGrid.h
M Source/WebCore/rendering/style/GridPosition.cpp
M Source/WebCore/rendering/style/GridPosition.h
M Source/WebCore/rendering/style/GridPositionsResolver.cpp
M Source/WebCore/rendering/style/GridPositionsResolver.h
M Source/WebCore/style/StyleBuilderConverter.h
M Source/WebCore/style/StyleBuilderCustom.h

  Log Message:
  ---
  [css-grid] enums in grid code should be enum classes
https://bugs.webkit.org/show_bug.cgi?id=262975
rdar://problem/116755214

Reviewed by Simon Fraser.

The follwing are enums in grid code that should be enum classes.

cacheBaselineAlignedChildren uses bitwise operators with GridAxis so
a couple of static_casts were needed there.

* Source/WebCore/css/ComputedStyleExtractor.cpp:
(WebCore::valueForGridTrackSizeList):
(WebCore::valueForGridTrackList):
(WebCore::ComputedStyleExtractor::valueForPropertyInStyle const):
* Source/WebCore/rendering/Grid.cpp:
(WebCore::Grid::numTracks const):
(WebCore::Grid::ensureGridSize):
(WebCore::Grid::explicitGridStart const):
(WebCore::Grid::setAutoRepeatTracks):
(WebCore::Grid::autoRepeatTracks const):
(WebCore::Grid::hasAutoRepeatEmptyTracks const):
(WebCore::Grid::autoRepeatEmptyTracks const):
(WebCore::Grid::gridItemSpan const):
(WebCore::GridIterator::GridIterator):
(WebCore::GridIterator::nextGridItem):
(WebCore::GridIterator::isEmptyAreaEnough const):
(WebCore::GridIterator::nextEmptyGridArea):
(WebCore::GridIterator::createForSubgrid):
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::isHorizontalBaselineAxis const):
(WebCore::GridBaselineAlignment::isParallelToBaselineAxisForChild const):
(WebCore::GridBaselineAlignment::baselineGroupForChild const):
(WebCore::GridBaselineAlignment::updateBaselineAlignmentContext):
(WebCore::GridBaselineAlignment::clear):
* Source/WebCore/rendering/GridLayoutFunctions.cpp:
(WebCore::GridLayoutFunctions::marginStartIsAuto):
(WebCore::GridLayoutFunctions::marginEndIsAuto):
(WebCore::GridLayoutFunctions::childHasMargin):
(WebCore::GridLayoutFunctions::computeMarginLogicalSizeForChild):
(WebCore::GridLayoutFunctions::hasRelativeOrIntrinsicSizeForChild):
(WebCore::GridLayoutFunctions::extraMarginForSubgrid):
(WebCore::GridLayoutFunctions::marginLogicalSizeForChild):
(WebCore::GridLayoutFunctions::flowAwareDirectionForChild):
(WebCore::GridLayoutFunctions::flowAwareDirectionForParent):
(WebCore::GridLayoutFunctions::hasOverridingContainingBlockContentSizeForChild):
(WebCore::GridLayoutFunctions::overridingContainingBlockContentSizeForChild):
(WebCore::GridLayoutFunctions::isFlippedDirection):
* Source/WebCore/rendering/GridLayoutFunctions.h:
(): Deleted.
* Source/WebCore/rendering/GridMasonryLayout.cpp:
(WebCore::GridMasonryLayout::performMasonryPlacement):
(WebCore::GridMasonryLayout::allocateCapacityForMasonryVectors):
(WebCore::GridMasonryLayout::setItemGridAxisContainingBlockToGridArea):
(WebCore::GridMasonryLayout::masonryAxisMarginBoxForItem):
(WebCore::GridMasonryLayout::gridAxisDirection const):
(WebCore::GridMasonryLayout::gridAxisSpanFromArea const):
(WebCore::GridMasonryLayout::masonryGridAreaFromGridAxisSpan const):
* Source/WebCore/rendering/GridMasonryLayout.h:
(WebCore::GridMasonryLayout::itemGridAreaStartsAtFirstLine):
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::gridAxisForDirection):
(WebCore::gridDirectionForAxis):
(WebCore::hasRelativeMarginOrPaddingForChild):
(WebCore::hasRelativeOrIntrinsicSizeForChild):
(WebCore::setOverridingContainingBlockContentSizeForChild):
(WebCore::GridTrackSizingAlgorithm::setFreeSpace):
(WebCore::GridTrackSizingAlgorithm::setAvailableSpace):
(WebCore::GridTrackSizingAlgorithm::rawGridTrackSize const):
(WebCore::GridTrackSizingAlgorithm::itemSizeForTrackSizeComputationPhase const):
(WebCore::shouldProcessTrackForTrackSizeComputationPhase):
(WebCore::trackSizeForTrackSizeComputationPhase):
(WebCore::updateTrackSizeForTrackSizeComputationPhase):
(WebCore::trackShouldGrowBeyondGrowthLimitsForTrackSizeComputationPhase):
(WebCore::markAsInfinitelyGrowableForTrackSizeComputationPhase):
(WebCore

[webkit-changes] [WebKit/WebKit] 6126b9: [css-grid] Update test expectations for css-grid/s...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6126b9b5fa7170ed88e8561b0a6afb74befe5a40
  
https://github.com/WebKit/WebKit/commit/6126b9b5fa7170ed88e8561b0a6afb74befe5a40
  Author: Sammy Gill 
  Date:   2023-10-10 (Tue, 10 Oct 2023)

  Changed paths:
M LayoutTests/TestExpectations
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/orthogonal-writing-mode-005-expected.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/orthogonal-writing-mode-005-ref.html

  Log Message:
  ---
  [css-grid] Update test expectations for 
css-grid/subgrid/orthogonal-writing-mode-005.
https://bugs.webkit.org/show_bug.cgi?id=262912
rdar://116685783

Reviewed by Tim Nguyen.

There was a CSSWG discussion regarding some of the subtests within
this test: https://github.com/w3c/csswg-drafts/issues/9418

Based off of the discussion, the subtests should be updated to reflect
the current WebKit rendering.

* LayoutTests/TestExpectations:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/orthogonal-writing-mode-005-expected.html:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/orthogonal-writing-mode-005-ref.html:

Canonical link: https://commits.webkit.org/269141@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ebd030: [css-grid] Accumulate nested subgrids' margin, bor...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ebd030f9b8667698930ad2ffa5de7c56bbbab8cd
  
https://github.com/WebKit/WebKit/commit/ebd030f9b8667698930ad2ffa5de7c56bbbab8cd
  Author: Sammy Gill 
  Date:   2023-10-05 (Thu, 05 Oct 2023)

  Changed paths:
M LayoutTests/TestExpectations
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.h

  Log Message:
  ---
  [css-grid] Accumulate nested subgrids' margin, border, and padding to base 
size of outer grid tracks.
https://bugs.webkit.org/show_bug.cgi?id=260531
rdar://114271839

Reviewed by Matt Woodrow.

Currently, if there is a subgrid we will take the sum of its margin,
border, and padding (mbp) at each edge and apply it to the track sizing
algorithm for the track the edge is in. This sum may then get applied to
the base size of the track if needed.

However, if there are nested subgrids, we need to take them into account
and accumulate their values as well so that any adjacent chunks of mbp
are considered as a single layer when sizing the track.

We can accomplish this by keeping track of a variable that stores the
accumulated value as we recurse through nested subgrids. This value will
first be set to 0 in the first call to accumulateIntrinsicSizesForTrack.
As we iterate over the track's items, if we find a subgrid we will
compute the margin, border, and padding values it contributes to the
track and add it to the variable we are using to store the accumulated
value and potentially update the track size.

The key idea is that when we recurse into a new level of a nested
subgrid we will pass along and use this updated accumulated value with
the subgrid's mbp, but as we traverse through subgrids within the same
level will: use the same accumulated value, add the subgrid's mbp to
the value, and then potentially update the track size.

* LayoutTests/TestExpectations:
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::computeSubgridMarginBorderPadding):
(WebCore::GridTrackSizingAlgorithm::accumulateIntrinsicSizesForTrack):
(WebCore::GridTrackSizingAlgorithm::resolveIntrinsicTrackSizes):
(WebCore::addSubgridMarginBorderPadding): Deleted.
* Source/WebCore/rendering/GridTrackSizingAlgorithm.h:

Canonical link: https://commits.webkit.org/268947@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 94edba: [css-grid] Consider sum of non-orthogonal nested s...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 94edbaabbf368aa6ffa9a0d21601c668a0ba095a
  
https://github.com/WebKit/WebKit/commit/94edbaabbf368aa6ffa9a0d21601c668a0ba095a
  Author: Sammy Gill 
  Date:   2023-10-05 (Thu, 05 Oct 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-005-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-007-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt
M Source/WebCore/rendering/GridBaselineAlignment.cpp
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp

  Log Message:
  ---
  [css-grid] Consider sum of non-orthogonal nested subgrids' margin,
border,  and padding for first baseline alignment in the column axis.
https://bugs.webkit.org/show_bug.cgi?id=262605
rdar://problem/116443747

Reviewed by Matt Woodrow.

To compute the extra layer of margin for subridded items in this
scenario, we will simply walk up the subgrid ancestors until we reach
the outermost parent grid. For each subgrid, we will take its mbp and
add it to a cumulative offset value. By the time we reach the outermost
parent grid we should have a sum of all of the nested subgrid margin,
border, and padding values.

If at any point we run into an orthogonal subgrid we will return 0 to
fallback to previous behavior.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-005-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-007-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt:
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::ascentForChild const):

Canonical link: https://commits.webkit.org/268928@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d93507: [css-grid] Start considering subgrid's margin, bor...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d935079e09c41c82bd1e9f3b5cd4f7d38bda6972
  
https://github.com/WebKit/WebKit/commit/d935079e09c41c82bd1e9f3b5cd4f7d38bda6972
  Author: Sammy Gill 
  Date:   2023-10-03 (Tue, 03 Oct 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/align-self-baseline-with-subgrid-mbp-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/align-self-baseline-with-subgrid-mbp.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-005-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-007-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt
A 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/align-self-baseline-with-subgrid-mbp-expected.txt
M Source/WebCore/rendering/GridBaselineAlignment.cpp

  Log Message:
  ---
  [css-grid] Start considering subgrid's margin, border, and padding for 
align-self baseline items.
https://bugs.webkit.org/show_bug.cgi?id=262336
rdar://problem/116206243

Reviewed by Matt Woodrow.

For baseline alignment we currently do not consider the extra layer of
margin imposed by a subgrid's margin, border, and padding on a subgrid
item. For the purposes of baseline alignment this extra layer can
influence the ascent of a subgrid item.

This patch is a first step in towards considering these values for the
purposes of baseline alignment. We start with the most simple case where
we have a non-orthogonal and one level deep subgrid. We will want to
add additional patches to consider the scenarios where subgrids start
nesting and possibly even switch writing modes.

We can compute this "subgrid offset," when we compute the ascent value
for a grid item by checking to see if its parent is a subgrid in
ascentForChild. As a result, this means that the ascent value for a
subgrid item will always be relative to parent (non-subgrid) grid.

We will bail out of this computation and ultimately fall back to the old
behavior in any of the following conditions:
- The subgrid is orthogonal to its parent
- The baseline axis is the row axis (e.g. justify-self: baseline)
- The alignment is last baseline alignment

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/align-self-baseline-with-subgrid-mbp-expected.txt:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/align-self-baseline-with-subgrid-mbp.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-005-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-006-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-007-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/subgrid/subgrid-baseline-008-expected.txt:
* 
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-grid/subgrid/align-self-baseline-with-subgrid-mbp-expected.txt:
 Added.
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::ascentForChild const):

Canonical link: https://commits.webkit.org/268804@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c2e83f: [css-grid] adjustGridPositionsFromStyle should set...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c2e83fc185932b1b09c3ef4d75468cf47b2515d2
  
https://github.com/WebKit/WebKit/commit/c2e83fc185932b1b09c3ef4d75468cf47b2515d2
  Author: Sammy Gill 
  Date:   2023-09-27 (Wed, 27 Sep 2023)

  Changed paths:
M LayoutTests/TestExpectations
M Source/WebCore/rendering/style/GridPositionsResolver.cpp

  Log Message:
  ---
  [css-grid] adjustGridPositionsFromStyle should set a subgrid's indefinite 
span to use the null string
https://bugs.webkit.org/show_bug.cgi?id=260527
rdar://114271485

Reviewed by Matt Woodrow.

If a subgrid has an indefinite span in the subgridded dimension,
adjustGridPositionsFromStyle will attempt to set the span size based
on the the number of named lines that it has. This is done with a call
similar to span.setSpanPosition(std::max(1, lineCount - 1), emtpyString()).

This code presumably does not want to set the m_namedGridLine portion
of the GridPosition as we are not actually referencing a named grid
line. However, we should probably be using String() here instead of
emptyString() to set that value to the null string as the rest of the
code checks against !position.namedGridLine().isNull() when attempting
to use the named grid line. This change helps us avoid entering code
guarded by that type of logic when we probably do not want to.

* LayoutTests/TestExpectations:
* Source/WebCore/rendering/style/GridPositionsResolver.cpp:
(WebCore::adjustGridPositionsFromStyle):

Canonical link: https://commits.webkit.org/268510@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 515686: [margin-trim] Remove margin-trim behavior for floats

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5156868db8d51fa1651d6246f6e92ea0a6385363
  
https://github.com/WebKit/WebKit/commit/5156868db8d51fa1651d6246f6e92ea0a6385363
  Author: Sammy Gill 
  Date:   2023-09-20 (Wed, 20 Sep 2023)

  Changed paths:
M LayoutTests/TestExpectations
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-start-trim-float-drives-container-intrinsic-size-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-start-trim-float-drives-container-intrinsic-size-orthogonal-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-start-trim-float-drives-container-intrinsic-size-orthogonal.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-start-trim-float-drives-container-intrinsic-size-rtl-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-start-trim-float-drives-container-intrinsic-size-rtl.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-start-trim-float-drives-container-intrinsic-size.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-trim-float-drives-container-intrinsic-size-inline-layout-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-trim-float-drives-container-intrinsic-size-inline-layout.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-trim-text-drives-container-intrinsic-size-inline-layout-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-trim-text-drives-container-intrinsic-size-inline-layout-vert-lr-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-trim-text-drives-container-intrinsic-size-inline-layout-vert-lr.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-inline-trim-text-drives-container-intrinsic-size-inline-layout.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-nested-inside-nested-inline-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-float-nested-inside-nested-inline.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-floats-adjacent-to-containing-block-should-be-trimmed-only-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-floats-adjacent-to-containing-block-should-be-trimmed-only.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-left-positioned-float-intersecting-other-float-to-fit-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-left-positioned-float-intersecting-other-float-to-fit.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-left-positioned-float-overconstraining-line-box-to-fit-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-left-positioned-float-overconstraining-line-box-to-fit-rtl-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-left-positioned-float-overconstraining-line-box-to-fit-rtl.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-left-positioned-float-overconstraining-line-box-to-fit-vert-lr-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-left-positioned-float-overconstraining-line-box-to-fit-vert-lr.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-left-positioned-float-overconstraining-line-box-to-fit.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-orthogonal-float-overconstraining-line-box-to-fit-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-orthogonal-float-overconstraining-line-box-to-fit.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-right-positioned-float-intersecting-other-float-to-fit-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-right-positioned-float-intersecting-other-float-to-fit.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-right-positioned-float-overconstraining-line-box-to-fit-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-right-positioned-float-overconstraining-line-box-to-fit-rtl-expected.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-right-positioned-float-overconstraining-line-box-to-fit-rtl.html
R 
LayoutTests/fast/inline/legacy-margin-trim/block-container-trimmed-margin-allows-right-positioned-float-overconstraining-line

[webkit-changes] [WebKit/WebKit] ad8e8d: [css-grid] Use ShorthandSerializer for grid-column...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ad8e8db1b46be5e928eccbae1370fa3c09170f4a
  
https://github.com/WebKit/WebKit/commit/ad8e8db1b46be5e928eccbae1370fa3c09170f4a
  Author: Sammy Gill 
  Date:   2023-09-19 (Tue, 19 Sep 2023)

  Changed paths:
M LayoutTests/fast/css-grid-layout/grid-item-column-row-get-set-expected.txt
M LayoutTests/fast/css-grid-layout/grid-item-column-row-get-set.html
M LayoutTests/fast/css-grid-layout/grid-item-end-after-get-set-expected.txt
M LayoutTests/fast/css-grid-layout/grid-item-end-after-get-set.html
M 
LayoutTests/fast/css-grid-layout/grid-item-start-before-get-set-expected.txt
M LayoutTests/fast/css-grid-layout/grid-item-start-before-get-set.html
M 
LayoutTests/fast/css-grid-layout/named-grid-lines-with-named-grid-areas-get-set-expected.txt
M 
LayoutTests/fast/css-grid-layout/named-grid-lines-with-named-grid-areas-get-set.html
M 
LayoutTests/fast/css-grid-layout/resources/grid-item-column-row-parsing-utils.js
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-layout-properties-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-column-invalid-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-column-invalid.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-column-shortest-serialization-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-column-shortest-serialization.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-column-shorthand-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-column-shorthand.html
M Source/WebCore/css/CSSComputedStyleDeclaration.cpp

  Log Message:
  ---
  [css-grid] Use ShorthandSerializer for grid-column in 
CSSComputedStyleDeclaration::getPropertyValue.
https://bugs.webkit.org/show_bug.cgi?id=261575
rdar://115521440

Reviewed by Tim Nguyen.

We can reuse the logic that the ShorthandSerializer provides to
correctly serialize the computed style of this property. This will
help us avoid duplicating logic to get the computed value.

This change also exposed some incorrect tests within
fast/css-grid-layout. The underlying issue between all of the subtests
was the same as in 268132@main but for the grid-column property:
the tests did not correctly use the shortest possible
serialization for the grid-column property. For the same reason as in
268132@main, we moved these incorrect tests to their WPT version.

The tests were expecting the computed value of grid-column to serialize
to one of the following forms which is incorrect:
- auto / auto
-  / auto
- span  / auto
-   / auto
- span  / auto
- span   / auto
-  /  (where the idents were exactly the
same)
In all of these cases the computed value of grid-column should serialize
to just the grid-column portion in the grammars above as that is the
shortest possible representation for each. These type of tests were
moved to css/css-grid/parsing/grid-column-shortest-serialization.html

All of the subtests testing the invalid values for this property were
moved to css/css-grid/parsing/grid-column-invalid.html

The modified inheritance tests were also problematic because in some
cases they were setting the value of grid-column to one of the problematic
versions, so I simply ended up modifying the value of grid-column they
were using since they were testing inheritance rather than the
serialization of a specific value.

Tests that were testing the value of "initial," for grid-column could also
be removed with no issue as this is already being tested in
css/css-grid/grid-layout-properties.html.

* LayoutTests/fast/css-grid-layout/grid-item-column-row-get-set-expected.txt:
* LayoutTests/fast/css-grid-layout/grid-item-column-row-get-set.html:
* LayoutTests/fast/css-grid-layout/grid-item-end-after-get-set-expected.txt:
* LayoutTests/fast/css-grid-layout/grid-item-end-after-get-set.html:
* LayoutTests/fast/css-grid-layout/grid-item-start-before-get-set-expected.txt:
* LayoutTests/fast/css-grid-layout/grid-item-start-before-get-set.html:
* 
LayoutTests/fast/css-grid-layout/named-grid-lines-with-named-grid-areas-get-set-expected.txt:
* 
LayoutTests/fast/css-grid-layout/named-grid-lines-with-named-grid-areas-get-set.html:
* 
LayoutTests/fast/css-grid-layout/resources/grid-item-column-row-parsing-utils.js:
(window.testRowCSSParsing):
(window.testColumnRowJSParsing):
(window.testColumnJSParsing): Deleted.
(window.testColumnRowInvalidJSParsing): Deleted.
(window.testColumnInvalidJSParsing): Deleted.
(window.testColumnEndJSParsing): Deleted.
(window.testColumnInitialJSParsing): Deleted.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-layout-properties-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-column-invalid-expected.txt:
 Added.
* 
L

[webkit-changes] [WebKit/WebKit] 5780a0: [css-grid] Use ShorthandSerializer for grid-row in...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5780a097f69233bdd55feb4cf5fc16acb8400364
  
https://github.com/WebKit/WebKit/commit/5780a097f69233bdd55feb4cf5fc16acb8400364
  Author: Sammy Gill 
  Date:   2023-09-19 (Tue, 19 Sep 2023)

  Changed paths:
M LayoutTests/fast/css-grid-layout/grid-item-column-row-get-set-expected.txt
M LayoutTests/fast/css-grid-layout/grid-item-column-row-get-set.html
M LayoutTests/fast/css-grid-layout/grid-item-end-after-get-set-expected.txt
M LayoutTests/fast/css-grid-layout/grid-item-end-after-get-set.html
M 
LayoutTests/fast/css-grid-layout/grid-item-start-before-get-set-expected.txt
M LayoutTests/fast/css-grid-layout/grid-item-start-before-get-set.html
M 
LayoutTests/fast/css-grid-layout/named-grid-lines-with-named-grid-areas-get-set-expected.txt
M 
LayoutTests/fast/css-grid-layout/named-grid-lines-with-named-grid-areas-get-set.html
M 
LayoutTests/fast/css-grid-layout/resources/grid-item-column-row-parsing-utils.js
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-layout-properties-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-row-invalid-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-row-invalid.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-row-shortest-serialization-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-row-shortest-serialization.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-row-shorthand-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-row-shorthand.html
M Source/WebCore/css/CSSComputedStyleDeclaration.cpp

  Log Message:
  ---
  [css-grid] Use ShorthandSerializer for grid-row in 
CSSComputedStyleDeclaration::getPropertyValue.
https://bugs.webkit.org/show_bug.cgi?id=261576
rdar://115521465

Reviewed by Tim Nguyen.

We can reuse the logic that the ShorthandSerializer provides to
correctly serialize the computed style of this property. This will
help us avoid duplicating logic to get the computed value.

This change also exposed some incorrect tests within
fast/css-grid-layout. The underlying issue between all of the subtests
was the same: the tests did not correctly use the shortest possible
serialization for the grid-row property. Attempting to correct the
already existing subtests would have been costly as that would have
required rewritting some custom JS that we have for these specific
tests. Instead, I opted to remove the incorrect subtests and add WPT
versions of these same tests so that we do not actually lose the
coverage provided by them. This will make it much easier to maintain
these tests in the future as we can continue to leverage the WPT testing
infrastructure.

Below is an explanation of the type of subtests that were modified and
the corresponding WPT that they were moved to.

Many of the subtests were calling testColumnRowCSSParsing,
testColumnRowJSParsing, or testColumnEndRowEndJSParsing to set the value
of grid-row (or grid-row-end for testColumnEndJSParsing) and check the
values of grid-row, grid-row-start, and grid-row-end. These subtests
ended up having grid-row take one of the following forms:
- auto / auto
-  / auto
- span  / auto
-   / auto
- span  / auto
- span   / auto
-  /  (where the idents were exactly the
same)
In all of these cases the computed value of grid-row should serialize
to just the grid-row portion in the grammars above as that is the
shortest possible representation for each. These type of tests were
moved to css/css-grid/grid-row-shortest-serialization.html

Other subtests were calling testColumnRowInvalidJSParsing to test
invalid values of grid-row and grid-column. I moved all of the grid-row
ones into their own css/css-grid/grid-row-invalid.html WPT that has the
exact same tests.

The modified inheritance tests were also problematic because in some
cases they were setting the value of grid-row to one of the problematic
versions, so I simply ended up modifying the value of grid-row they
were using since they were testing inheritance rather than the
serialization of a specific value. For example, I changed
testStartBeforeInheritJSParsing("inherit", "18") to
testStartBeforeInheritJSParsing("inherit", "a") so that we would set
grid-row-start to "a" rather than "18."

Tests that were testing the value of "initial," for grid-row could also
be removed with no issue as this is already being tested in
css/css-grid/grid-layout-properties.html.

* LayoutTests/fast/css-grid-layout/grid-item-column-row-get-set-expected.txt:
* LayoutTests/fast/css-grid-layout/grid-item-column-row-get-set.html:
* LayoutTests/fast/css-grid-layout/grid-item-end-after-get-set-expected.txt:
* LayoutTests/fast/css-grid-layout/grid-item-end-

[webkit-changes] [WebKit/WebKit] b508fd: [css-grid] getBaselineChild should consider both f...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b508fd690c0973b5824b82e26e6013e2b73b6470
  
https://github.com/WebKit/WebKit/commit/b508fd690c0973b5824b82e26e6013e2b73b6470
  Author: Sammy Gill 
  Date:   2023-09-15 (Fri, 15 Sep 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-grid-001-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-grid-002-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-grid-003-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-grid-001-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-grid-002-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-grid-003-expected.txt
M Source/WebCore/rendering/GridLayoutFunctions.cpp
M Source/WebCore/rendering/GridLayoutFunctions.h
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/RenderGrid.cpp

  Log Message:
  ---
  [css-grid] getBaselineChild should consider both first and last baseline 
aligned grid items.
https://bugs.webkit.org/show_bug.cgi?id=261523.
rdar://115441833.

Reviewed by Matt Woodrow.

getbaselineChild is responsible for selecting the correct grid item to
use when determining the baseline for the grid itself. The spec states:

The first (last) baselines of a grid container are determined as follows:
1.) Find the first (last) row of the grid container containing at
least one grid item.

If any of the grid items intersecting this row participate in
baseline alignment in that row, the grid containers baseline set is
generated from the shared alignment baseline of those grid items.

Since the spec states that we should look for any grid items that
"participate in baseline alignment in that row" it seems like we should
also look at items that are being last baseline aligned.

In the case that an item spans multiple rows, we need to double check
the alignment context that it is participating in (which row) is the
same as the row we are using to determine the baseline (first row for
first baseline and last row for last baseline).

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-grid-001-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-grid-002-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-grid-003-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-grid-001-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-grid-002-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-grid-003-expected.txt:
* Source/WebCore/rendering/GridLayoutFunctions.cpp:
(WebCore::GridLayoutFunctions::alignmentContextForBaselineAlignment):
* Source/WebCore/rendering/GridLayoutFunctions.h:
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::updateBaselineAlignmentContext):
(WebCore::GridTrackSizingAlgorithm::baselineOffsetForChild const):
(WebCore::alignmentContextForBaselineAlignment): Deleted.
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::getBaselineChild const):

Canonical link: https://commits.webkit.org/268029@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c07a7a: [css-grid] Use ShorthandSerializer for grid-area i...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c07a7a053c8c94486f771a89ae195a2fa427ea9e
  
https://github.com/WebKit/WebKit/commit/c07a7a053c8c94486f771a89ae195a2fa427ea9e
  Author: Sammy Gill 
  Date:   2023-09-15 (Fri, 15 Sep 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-layout-properties-expected.txt
M Source/WebCore/css/CSSComputedStyleDeclaration.cpp

  Log Message:
  ---
  [css-grid] Use ShorthandSerializer for grid-area in 
CSSComputedStyleDeclaration::getPropertyValue.
https://bugs.webkit.org/show_bug.cgi?id=261577
rdar://115521493

Reviewed by Tim Nguyen.

We can reuse the logic that the ShorthandSerializer provides to
correctly serialize the computed style of this property. This will
help us avoid duplicating logic to get the computed value.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-layout-properties-expected.txt:
* Source/WebCore/css/CSSComputedStyleDeclaration.cpp:
(WebCore::CSSComputedStyleDeclaration::getPropertyValue const):

Canonical link: https://commits.webkit.org/268026@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 7d7be7: REGRESSION(267280@main): costco.com crash in WebCo...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7d7be769ce2d1407bdac2234c29f91630ca959fd
  
https://github.com/WebKit/WebKit/commit/7d7be769ce2d1407bdac2234c29f91630ca959fd
  Author: Sammy Gill 
  Date:   2023-09-14 (Thu, 14 Sep 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-template-node-not-connected-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-template-node-not-connected.html
M Source/WebCore/css/ShorthandSerializer.cpp

  Log Message:
  ---
  REGRESSION(267280@main): costco.com crash in 
WebCore::ShorthandSerializer::serializeGridTemplate const
https://bugs.webkit.org/show_bug.cgi?id=261421
rdar://115046351

Reviewed by Darin Adler.

Costco's checkout page uses element.TextContent = "" which ends up
disconnecting some nodes from the tree. When the ShorthandSerializer
tries to get the value for each of the longhands of grid-template,
the ComputedStyleExtractor is unable to resolve the RenderStyle to use
via computeRenderStyleForProperty and returns nullptr for the longhand
value. This results in a hard nullptr deref
ShorthandSerializer::longhandValue.

Any time we are using the ComputedStyleExtractor version of the
ShorthandSerializer and we end up getting a nullptr back for one of
the longhand values we should instead set m_result to the emptyString
(which would have been returned anyways in
CSSComputedStyleDeclaration::getPropertyValue if we used the
ComputedStyleExtractor rather than the ShorthandSerializer for the
shorthand's computed style) and return true from
commonSerializationChecks. The serialize function will see that
commonSerializationChecks set the value and return it back to the
caller.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-template-node-not-connected-expected.txt:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-template-node-not-connected.html:
 Added.
* Source/WebCore/css/ShorthandSerializer.cpp:
(WebCore::ShorthandSerializer::commonSerializationChecks):

Canonical link: https://commits.webkit.org/267989@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] caab01: [css-grid] Last baseline aligned grid items should...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: caab01d5e748531c1ff7fbcdab9b2da36801d73e
  
https://github.com/WebKit/WebKit/commit/caab01d5e748531c1ff7fbcdab9b2da36801d73e
  Author: Sammy Gill 
  Date:   2023-09-12 (Tue, 12 Sep 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-001-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-002-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-justify-baseline-002-expected.txt
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp

  Log Message:
  ---
  [css-grid] Last baseline aligned grid items should use the start of the last 
track they span for their alignment context
https://bugs.webkit.org/show_bug.cgi?id=261244
rdar://115083708

Reviewed by Matt Woodrow.

Instead of using span.endLine() for a last baseline aligned grid item's
alignment context, we should use span.endLine() - 1. This will allow
them to be in the same alignment context and potentially the same
baseline sharing group as first baseline aligned items in the same
track. For example, both items in the following grid should be in
the same baseline sharing group and should be aligned together as a
result:


  display: grid;
  grid-auto-flow: column;
  align-items: last baseline;
  width: 200px;
  writing-mode: vertical-lr;
}
  background: lime;
  margin-right: 20px;
  padding-right: 20px;
  font-size: 20px;
  line-height: 20px;
  align-self: first baseline;
  writing-mode: vertical-rl;
}
  background: hotpink;
  font-size: 30px;
  line-height: 30px;
  writing-mode: vertical-lr;
}


  line1line2
  line1line2


* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-001-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-002-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-justify-baseline-002-expected.txt:
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::alignmentContextForBaselineAlignment):
(WebCore::GridTrackSizingAlgorithm::updateBaselineAlignmentContext):
(WebCore::GridTrackSizingAlgorithm::baselineOffsetForChild const):

Canonical link: https://commits.webkit.org/267922@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 256590: [css-grid] Consider fallback alignment for first/l...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 256590954964b0f4ead4ad3aa3289bb97bc1f5c4
  
https://github.com/WebKit/WebKit/commit/256590954964b0f4ead4ad3aa3289bb97bc1f5c4
  Author: Sammy Gill 
  Date:   2023-09-08 (Fri, 08 Sep 2023)

  Changed paths:
M 
LayoutTests/fast/css-grid-layout/grid-self-baseline-two-dimensional-expected.txt
M LayoutTests/fast/css-grid-layout/grid-self-baseline-two-dimensional.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-001-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-002-expected.txt
M Source/WebCore/rendering/RenderGrid.cpp

  Log Message:
  ---
  [css-grid] Consider fallback alignment for first/last baseline when 
determining non-orthogonal grid item's columnAxisPosition.
https://bugs.webkit.org/show_bug.cgi?id=261290
rdar://problem/115136343

Reviewed by Matt Woodrow.

columnAxisPositionForChild maps first baseline to GridAxisStart and
last baseline to GridAxisEnd. This does not work in all cases, such as
when the grid item has an opposite block flow direction from the grid
container. In these cases the fallback alignment is flipped from these
values, so we should take this scenario into consideration.

We only need to apply this logic for non-orthogonal children as
orthogonal children will use the grid's writing mode (since the
alignment context is perpendicular to the grid's block flow direction).

fast/css-grid-layout/grid-self-baseline-two-dimensional had subtests
that were incorrect as they did not take certain things into account
like fallback alignment. I rebased these to match Blink's output as
that seems to match the spec.

https://drafts.csswg.org/css-align-3/#baseline-rules
https://drafts.csswg.org/css-align-3/#align-by-baseline

* 
LayoutTests/fast/css-grid-layout/grid-self-baseline-two-dimensional-expected.txt:
* LayoutTests/fast/css-grid-layout/grid-self-baseline-two-dimensional.html:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-001-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-002-expected.txt:
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::columnAxisPositionForChild const):

Canonical link: https://commits.webkit.org/267811@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ac15c3: Check implicitly assigned line names in NamedLineC...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ac15c399013cbb04e8ebea7e35ad09abf2483b4d
  
https://github.com/WebKit/WebKit/commit/ac15c399013cbb04e8ebea7e35ad09abf2483b4d
  Author: Sammy Gill 
  Date:   2023-08-25 (Fri, 25 Aug 2023)

  Changed paths:
M LayoutTests/TestExpectations
M Source/WebCore/rendering/style/GridPositionsResolver.cpp
M Source/WebCore/rendering/style/GridPositionsResolver.h

  Log Message:
  ---
  Check implicitly assigned line names in NamedLineCollectionBase::contains.
https://bugs.webkit.org/show_bug.cgi?id=260526
rdar://114271506

Reviewed by Matt Woodrow.

NamedLineCollection::contains does 3 main things:
1.) Check to see if the line we are looking for is beyond the bounds
of the grid and return false if it is. This can happen when we are
checking to see if a parent grid's line is within a subgrid.
2.) Checks to see if the line is within the collection of the grid's
implicitly assigned lines and return true if it is.
3.) Call into NamedLineCollectionBase::contains

Since we already do 1 in NamedLineCollectionBase::contains, the only
difference between the methods is 2. It seems like this contains method
should be checking this anyways since we check to see if the line is
within the collection of other types of grid lines (m_namedLinesIndices
and m_autoRepeatNamedLinesIndices). By moving this logic to the method
in the base class we no longer need to have the version in the subclass.

THis helped fix a bug where items in a subgrid were not being placed
correctly using *-start and *-end line names that were implicitly
created from a grid area in the parent grid.

In the following example the  element would get placed into the 8th
grid column when it should be placed inth the 7th.


i {
  grid-row: 1;
  counter-increment: i;
}
i::before { content: counter(i, decimal); }



  
  
x
  


When we create a NamedLineCollectionBase for the parent grid we will
look and see if any of those lines are within our grid (the subgrid).
However since this uses the base class the parent class was nothing
checking against the implicitly created lines. Now these lines should
be detected and added into the local line collection that subgrid
creates.

* LayoutTests/TestExpectations:
* Source/WebCore/rendering/style/GridPositionsResolver.cpp:
(WebCore::NamedLineCollectionBase::contains const):
(WebCore::NamedLineCollection::NamedLineCollection):
(WebCore::NamedLineCollectionBase::hasExplicitNamedLines const):
(WebCore::NamedLineCollectionBase::hasNamedLines const):
(WebCore::NamedLineCollection::hasExplicitNamedLines const): Deleted.
(WebCore::NamedLineCollection::hasNamedLines const): Deleted.
(WebCore::NamedLineCollection::contains const): Deleted.
* Source/WebCore/rendering/style/GridPositionsResolver.h:

Canonical link: https://commits.webkit.org/267281@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 4820e6: Use ShorthandSerializer for grid-template shorthand.

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4820e6a9d6603660f37396c83f290b9b44afd92b
  
https://github.com/WebKit/WebKit/commit/4820e6a9d6603660f37396c83f290b9b44afd92b
  Author: Sammy Gill 
  Date:   2023-08-25 (Fri, 25 Aug 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-layout-properties-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/cssom/cssom-getPropertyValue-common-checks-expected.txt
M Source/WebCore/css/CSSComputedStyleDeclaration.cpp
M Source/WebCore/css/ShorthandSerializer.cpp
M Source/WebCore/css/ShorthandSerializer.h

  Log Message:
  ---
  Use ShorthandSerializer for grid-template shorthand.
https://bugs.webkit.org/show_bug.cgi?id=260397.
rdar://114097919.

Reviewed by Darin Adler.

The ShorthandSerializer already serializes the shorthand into its
shortest representation. When we get the property value for the computed
style, we can use the ShorthandSerializer instead.

In order to do this, the ShorthandSeralizer needs a new constructor that
can take a ComputedStyleExtractor. This will be used in 
commonSerializationChecks
to set the longhand values appropriately.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/grid-layout-properties-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/cssom/cssom-getPropertyValue-common-checks-expected.txt:
* Source/WebCore/css/CSSComputedStyleDeclaration.cpp:
(WebCore::CSSComputedStyleDeclaration::getPropertyValue const):
* Source/WebCore/css/ShorthandSerializer.cpp:
(WebCore::ShorthandSerializer::ShorthandSerializer):
(WebCore::ShorthandSerializer::commonSerializationChecks):
(WebCore::serializeShorthandValue):
* Source/WebCore/css/ShorthandSerializer.h:

Canonical link: https://commits.webkit.org/267280@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 74849b: Directly check values of grid-template-rows and gr...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 74849b01b11986fbd6aec530fa9a90e283cf8db3
  
https://github.com/WebKit/WebKit/commit/74849b01b11986fbd6aec530fa9a90e283cf8db3
  Author: Sammy Gill 
  Date:   2023-08-22 (Tue, 22 Aug 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-template-shorthand-areas-valid-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-template-shorthand-valid-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-template-shorthand-valid.html
M Source/WebCore/css/ShorthandSerializer.cpp
M Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp
M Source/WebCore/css/parser/CSSPropertyParserHelpers.h

  Log Message:
  ---
  Directly check values of grid-template-rows and grid-template-columns when 
serializing grid-template with grid areas
https://bugs.webkit.org/show_bug.cgi?id=260494
rdar://114224504

Reviewed by Tim Nguyen.

The grid-template shorthand has two different options for its syntax:
- [ <'grid-template-rows'> / <'grid-template-columns'> ]
- [ ?  ? ? ]+ [ / 
 ]?

In the latter version of the syntax, ShorthandSerializer would bail out
early (and not serialize any values) if grid-template-areas (the 
portion of the syntax) was not set by the grid-template shorthand. We
should instead check the values of grid-template-rows and grid-template-columns
directly to see if they can be expressed inside of this shorthand.

For the rows portion we build up the shorthand iteratively, so we can
just check if the value is a valid  and return an empty
string if it is not since that would mean the value could not be
expressed in the shorthand. A value being a valid  means that
it must be one of: minmax(), fit-content(), length-percentage, flex,
min-content, max-content, or auto. If it is not one of these then the
value is not a .

For the columns portion we have to check the entire value of 
grid-template-columns
beforehand since we will end up appending the whole value to the end
of the shorthand. To check to see if a value is a valid ,
we need to make sure the value contains only s and s
with at least one  in the value.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-template-shorthand-areas-valid-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/parsing/grid-template-shorthand-valid.html:
* Source/WebCore/css/ShorthandSerializer.cpp:
(WebCore::ShorthandSerializer::commonSerializationChecks):
(WebCore::ShorthandSerializer::serializeGridTemplate const):
* Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp:
(WebCore::CSSPropertyParserHelpers::isGridBreadthIdent):
(WebCore::CSSPropertyParserHelpers::consumeGridBreadth):
* Source/WebCore/css/parser/CSSPropertyParserHelpers.h:

Canonical link: https://commits.webkit.org/267155@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f5c4ea: ComputedStyleExtractor methods should be const whe...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f5c4eacf1b680be9ab02d77323051599228a47c0
  
https://github.com/WebKit/WebKit/commit/f5c4eacf1b680be9ab02d77323051599228a47c0
  Author: Sammy Gill 
  Date:   2023-08-18 (Fri, 18 Aug 2023)

  Changed paths:
M Source/WebCore/css/ComputedStyleExtractor.cpp
M Source/WebCore/css/ComputedStyleExtractor.h
M Source/WebCore/css/SVGCSSComputedStyleDeclaration.cpp

  Log Message:
  ---
  ComputedStyleExtractor methods should be const when possible.
https://bugs.webkit.org/show_bug.cgi?id=260401
rdar://problem/114099664

Reviewed by Tim Nguyen.

Many of the methods for ComputedStyleExtractor compute a value and then
return it without modifying any sort of state in the class. In these
cases we should try to mark these methods as const if this can be
easily done. This is useful for other code that many use a const
ComputedStyleExtractor and would like to use these methods. For example,
in 260397 I plan on passing in a const ComputedStyleExtractor into
ShorthandSerializer so that we can use it for the computed style
of the grid-template property.

* Source/WebCore/css/ComputedStyleExtractor.cpp:
(WebCore::ComputedStyleExtractor::whiteSpaceShorthandValue const):
(WebCore::ComputedStyleExtractor::getFontSizeCSSValuePreferringKeyword const):
(WebCore::ComputedStyleExtractor::useFixedFontDefaultSize const):
(WebCore::ComputedStyleExtractor::fontVariantShorthandValue const):
(WebCore::ComputedStyleExtractor::customPropertyValue const):
(WebCore::ComputedStyleExtractor::customPropertyText const):
(WebCore::ComputedStyleExtractor::propertyValue const):
(WebCore::ComputedStyleExtractor::hasProperty const):
(WebCore::ComputedStyleExtractor::valueForPropertyInStyle const):
(WebCore::ComputedStyleExtractor::propertyMatches const):
(WebCore::ComputedStyleExtractor::getCSSPropertyValuesForShorthandProperties 
const):
(WebCore::ComputedStyleExtractor::getCSSPropertyValuesFor2SidesShorthand const):
(WebCore::ComputedStyleExtractor::getCSSPropertyValuesFor4SidesShorthand const):
(WebCore::ComputedStyleExtractor::getCSSPropertyValuesForGridShorthand const):
(WebCore::ComputedStyleExtractor::copyProperties const):
(WebCore::ComputedStyleExtractor::getLayerCount const):
(WebCore::ComputedStyleExtractor::getFillLayerPropertyShorthandValue const):
(WebCore::ComputedStyleExtractor::getBackgroundShorthandValue const):
(WebCore::ComputedStyleExtractor::getMaskShorthandValue const):
(WebCore::ComputedStyleExtractor::whiteSpaceShorthandValue): Deleted.
(WebCore::ComputedStyleExtractor::getFontSizeCSSValuePreferringKeyword): 
Deleted.
(WebCore::ComputedStyleExtractor::useFixedFontDefaultSize): Deleted.
(WebCore::ComputedStyleExtractor::fontVariantShorthandValue): Deleted.
(WebCore::ComputedStyleExtractor::customPropertyValue): Deleted.
(WebCore::ComputedStyleExtractor::customPropertyText): Deleted.
(WebCore::ComputedStyleExtractor::propertyValue): Deleted.
(WebCore::ComputedStyleExtractor::hasProperty): Deleted.
(WebCore::ComputedStyleExtractor::valueForPropertyInStyle): Deleted.
(WebCore::ComputedStyleExtractor::propertyMatches): Deleted.
(WebCore::ComputedStyleExtractor::getCSSPropertyValuesForShorthandProperties): 
Deleted.
(WebCore::ComputedStyleExtractor::getCSSPropertyValuesFor2SidesShorthand): 
Deleted.
(WebCore::ComputedStyleExtractor::getCSSPropertyValuesFor4SidesShorthand): 
Deleted.
(WebCore::ComputedStyleExtractor::getCSSPropertyValuesForGridShorthand): 
Deleted.
(WebCore::ComputedStyleExtractor::copyProperties): Deleted.
(WebCore::ComputedStyleExtractor::getLayerCount): Deleted.
(WebCore::ComputedStyleExtractor::getFillLayerPropertyShorthandValue): Deleted.
(WebCore::ComputedStyleExtractor::getBackgroundShorthandValue): Deleted.
(WebCore::ComputedStyleExtractor::getMaskShorthandValue): Deleted.
* Source/WebCore/css/ComputedStyleExtractor.h:
* Source/WebCore/css/SVGCSSComputedStyleDeclaration.cpp:
(WebCore::ComputedStyleExtractor::svgPropertyValue const):
(WebCore::ComputedStyleExtractor::svgPropertyValue): Deleted.

Canonical link: https://commits.webkit.org/267055@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c4b5ac: [css-flex][baseline-alignment] Baseline aligned fl...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c4b5ac727df88b0b59f8e541b87e3ef091af5518
  
https://github.com/WebKit/WebKit/commit/c4b5ac727df88b0b59f8e541b87e3ef091af5518
  Author: Sammy Gill 
  Date:   2023-08-17 (Thu, 17 Aug 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-flexbox-item-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-grid-item-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-items-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-table-item-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-001-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-002-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-003-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-004-expected.txt
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h
M Source/WebCore/rendering/style/RenderStyle.h
M Source/WebCore/rendering/style/RenderStyleInlines.h

  Log Message:
  ---
  [css-flex][baseline-alignment] Baseline aligned flex items should be also 
aligned using their fallback alignment.
https://bugs.webkit.org/show_bug.cgi?id=256947
rdar://109496710

Reviewed by Alan Baradlay.

css-align-3 states the following to be done after items have been aligned
within their baseline sharing groups:

9.3. Aligning Boxes by Baseline step 3:
Position the aligned baseline-sharing group within the alignment container
according to its fallback alignment. The fallback alignment of a
baseline-sharing group is the fallback alignment of its items as
resolved to physical directions.

For flex layout we only need to consider the case where we may need to
push a baseline sharing group towards the cross axis end of the flexbox.
This is because when we align items within the baseline sharing group,
we align the items with respect to the item that has the highest ascent
in the flexbox. In other words, the item that has this max ascent value,
will already be placed flush against the cross axis start of the flexbox,
so the baseline sharing group could not be pushed closer towards it.

shouldAdjustItemTowardsCrossAxisEnd is a small helper function that will
help us determine if we need to move a baseline sharing group towards
the end of the cross axis. This is done by iterating over each item in
the baseline sharing group and taking 3 things into consideration:

1.) The alignment of the flex item (first vs last baseline)
2.) The used writing mode of the flex item
3.) The direction of the flexbox's cross axis

We need these 3 things in order to be able to resolve the fallback
alignment of the group/item in terms of physical directions.

First baseline aligned items need to be be adjusted when their block
flow direction is opposite of the cross axis direction. This is because
the self-start will be in that direction. Example:


  
one  two  three
  


Last baseline aligned items need to be adjusted when their block
direction is the same as the flexbox's cross axis direction. self-end
will be in that direction. Example:


  
one  two  three
  


* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-flexbox-item-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-grid-item-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-items-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-table-item-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-001-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-002-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-003-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-004-expected.txt:
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::performBaselineAlignment):
* Source/WebCore/rendering/RenderFlexibleBox.h:
(WebCore::RenderFlexibleBox::crossAxisDirection const):
* Source/WebCore/rendering/style/RenderStyle.h:
* Source/WebCore/rendering/style/RenderStyleInlines.h:
(WebCore::RenderStyle::isRowFlexDirection const):

Canonical link: https://commits.webkit.org/267026@main


___
webkit

[webkit-changes] [WebKit/WebKit] d8aa06: [css-flex] Use FlexItems as a type alias for Vecto...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d8aa063fb4e499692a9fe09f663008d5f3bc675e
  
https://github.com/WebKit/WebKit/commit/d8aa063fb4e499692a9fe09f663008d5f3bc675e
  Author: Sammy Gill 
  Date:   2023-08-14 (Mon, 14 Aug 2023)

  Changed paths:
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h

  Log Message:
  ---
  [css-flex] Use FlexItems as a type alias for Vector.
https://bugs.webkit.org/show_bug.cgi?id=260106
rdar://problem/113777139

Reviewed by Tim Nguyen.

We can refer to a Vector simply as FlexItems. Changed all
uses of this type to the new alias and also instances where a variable
named "children," was used with this type to "flexItems." We can
probably also find other spots where "child," can be replaced with
"flexItem," but that would probably increase the size of the patch
and this is a good start for now.

* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::LineState::LineState):
(WebCore::RenderFlexibleBox::layoutFlexItems):
(WebCore::RenderFlexibleBox::autoMarginOffsetInMainAxis):
(WebCore::RenderFlexibleBox::freezeInflexibleItems):
(WebCore::RenderFlexibleBox::resolveFlexibleLengths):
(WebCore::RenderFlexibleBox::layoutAndPlaceChildren):
(WebCore::RenderFlexibleBox::layoutColumnReverse):
* Source/WebCore/rendering/RenderFlexibleBox.h:

Canonical link: https://commits.webkit.org/266864@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ef40ef: Use FlexLineStates as a type alias for Vector

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ef40ef0a52fe2468e1bf8d276b96f5a1b8085d41
  
https://github.com/WebKit/WebKit/commit/ef40ef0a52fe2468e1bf8d276b96f5a1b8085d41
  Author: Sammy Gill 
  Date:   2023-08-11 (Fri, 11 Aug 2023)

  Changed paths:
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h

  Log Message:
  ---
  Use FlexLineStates as a type alias for Vector.
https://bugs.webkit.org/show_bug.cgi?id=260108
rdar://problem/113778236

Reviewed by Tim Nguyen.

The new alias helps with readability throughtout the code. Also renamed
the "linesState," variables to "lineStates," since the former was a bit
confusing to read given the type.

* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::repositionLogicalHeightDependentFlexItems):
(WebCore::RenderFlexibleBox::layoutFlexItems):
(WebCore::RenderFlexibleBox::layoutAndPlaceChildren):
(WebCore::RenderFlexibleBox::alignFlexLines):
(WebCore::RenderFlexibleBox::alignChildren):
(WebCore::RenderFlexibleBox::flipForRightToLeftColumn):
(WebCore::RenderFlexibleBox::flipForWrapReverse):
* Source/WebCore/rendering/RenderFlexibleBox.h:

Canonical link: https://commits.webkit.org/266843@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b7b43b: [css-flexbox][baseline-alignment] Use BaslineConte...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b7b43b9bf044a2edb16f3fc873f69f1bdf3d8379
  
https://github.com/WebKit/WebKit/commit/b7b43b9bf044a2edb16f3fc873f69f1bdf3d8379
  Author: Sammy Gill 
  Date:   2023-07-28 (Fri, 28 Jul 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-001-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-002-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-003-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-004-expected.txt
M Source/WebCore/rendering/BaselineAlignment.cpp
M Source/WebCore/rendering/BaselineAlignment.h
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h

  Log Message:
  ---
  [css-flexbox][baseline-alignment] Use BaslineContext/BaselineGroup to perform 
baseline alignment.
https://bugs.webkit.org/show_bug.cgi?id=256793
rdar://109362699

Reviewed by Alan Baradlay.

The BaselineContext and BaselineGroup classes provide us with the ability
to represent baseline alignment contexts and baseline sharing groups
as described in css-align-3. The main purpose of this patch is to replace
the data structures we use in flex layout to hold state for baseline
alignment with these new objects.

Previously, we were storing our baseline alignment state, in particular
the max ascent for baseline and last baseline alignment, for each
flex line inside of LineContext. The maxAscent value was computed
off of all of the items which had baseline alignment specified and
lastBaselineMaxAscent was computed off of all of the items which had
last baseline alignment specified.

This was not quite right since the spec mentions ways in which items
there are baseline and last baseline aligned could get placed in the
same baseline sharing group and should get aligned together. In the
following example the two flex items are placed in the same baseline
sharing group:


  line1line2
  line1line2


With the new addition of the BaselineContext and BaselineGroup objects
we can now place items into the correct baseline sharing group as
described in the spec and the max ascent values are now kept track of
within the baseline sharing group. However, the above example does
still not render correctly because there are still some outstanding
bugs related to baseline alignment, but this serves as a good starting
point for addressing them.

In order to perform baseline alignment with these new classes, a slight
refactoring was needed. Instead of iterating over all of the children
on the flex line we instead iterate over all of the baseline sharing
groups on the line and perform the alignment for each group. We do this
by checking to see if the LineContext has a BaselineContext early in
alignChildren() and for into performBaselineAlignment(). This is a
little more intuitive and will be useful as we address the rest of the
portions of the spec in css-align-3 as it mentions working with baseline
sharing groups as a whole.

Since we have not added any new functionality in regards to baseline
alignment besides just separating items into baseline sharing groups,
we should ideally not be regressing any scenarios in which we perform
baseline and last baseline alignment correctly.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-001-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-002-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-003-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-004-expected.txt:
* Source/WebCore/rendering/BaselineAlignment.cpp:
(WebCore::BaselineAlignmentState::sharedGroups):
* Source/WebCore/rendering/BaselineAlignment.h:
(WebCore::BaselineGroup::begin):
(WebCore::BaselineGroup::end):
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::LineState::LineState):
(WebCore::alignmentOffset):
(WebCore::RenderFlexibleBox::staticCrossAxisPositionForPositionedChild):
(WebCore::RenderFlexibleBox::layoutAndPlaceChildren):
(WebCore::RenderFlexibleBox::alignChildren):
(WebCore::RenderFlexibleBox::performBaselineAlignment):
* Source/WebCore/rendering/RenderFlexibleBox.h:

Canonical link: https://commits.webkit.org/266387@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 4c1bcd: Add Sammy Gill as a reviewer in contributors.json

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4c1bcda4acbd71a9a580a94627c76a4a2179f9b3
  
https://github.com/WebKit/WebKit/commit/4c1bcda4acbd71a9a580a94627c76a4a2179f9b3
  Author: Sammy Gill 
  Date:   2023-07-21 (Fri, 21 Jul 2023)

  Changed paths:
M metadata/contributors.json

  Log Message:
  ---
  Add Sammy Gill as a reviewer in contributors.json
https://bugs.webkit.org/show_bug.cgi?id=259399
rdar://112669430

Reviewed by Tim Nguyen.

* metadata/contributors.json:

Canonical link: https://commits.webkit.org/266209@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3f1250: Silence Window resize events while backgrounding Z...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3f1250c62c35f53e033bc6c7965bd864c852f089
  
https://github.com/WebKit/WebKit/commit/3f1250c62c35f53e033bc6c7965bd864c852f089
  Author: Sammy Gill 
  Date:   2023-06-29 (Thu, 29 Jun 2023)

  Changed paths:
M Source/WebCore/page/LocalFrameView.cpp
M Source/WebCore/page/Quirks.cpp

  Log Message:
  ---
  Silence Window resize events while backgrounding Zillow on iOS
https://bugs.webkit.org/show_bug.cgi?id=258648
rdar://109480544

Reviewed by Brent Fulgham.

There is currently a bug on Zillow that will cause the map to reset
to its initial location if the window is sized to a small size (enough
to make the map disappear) and resized back to its original size. This is
caused when window resize events are triggered and cause unusual
behavior on iPad due to the background snapshotting behavior of Safari.

Since this process does not happen to other browsers, because they
do not participate in this snapshotting process, it results in a bad
experience to those using Safari. To bring the behavior that occurs in
Safari in line with other browsers we can add a quirk that disables
window resize events from triggering while backgrounding. This should
be removed when the bug is fixed on Zillow's end.

We will also start logging this behavior to console whenever it gets
triggered.

* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::scheduleResizeEventIfNeeded):
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldSilenceWindowResizeEvents const):

Canonical link: https://commits.webkit.org/265621@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e54ba8: Silence ResizeObservers while backgrounding YouTub...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e54ba88232e1805a9027fa848a4b3f8db79aa42a
  
https://github.com/WebKit/WebKit/commit/e54ba88232e1805a9027fa848a4b3f8db79aa42a
  Author: Sammy Gill 
  Date:   2023-06-28 (Wed, 28 Jun 2023)

  Changed paths:
M Source/WebCore/dom/Document.cpp
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h

  Log Message:
  ---
  Silence ResizeObservers while backgrounding YouTube on iOS.
rdar://109837319
https://bugs.webkit.org/show_bug.cgi?id=258588

Reviewed by Brent Fulgham.

Currently, if you background and foreground Safari on iPad while on
YouTube, you will get a different page layout compared to what was
displayed before the backgrounding process. Since the viewport sizes are
the same one would expect there to be no difference in the page layout.
This is due to a ResizeObserver callback using requestAnimationFrame to
execute some logic to reinitalize the ResizeObserver, but the observer
is ultimately put into a bad state due to the quick viewport size
changed. By silencing ResizeObservers during this process we should not
trigger this behavior and reintroduce the expected page layout again.

* Source/WebCore/dom/Document.cpp:
(WebCore::Document::updateResizeObservations):
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldSilenceResizeObservers const):
* Source/WebCore/page/Quirks.h:

Canonical link: https://commits.webkit.org/265603@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6bb366: Move BaselineAlignmentInlines into the rendering d...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6bb3661e454195342cb22fca8c5aeaa30e052503
  
https://github.com/WebKit/WebKit/commit/6bb3661e454195342cb22fca8c5aeaa30e052503
  Author: Sammy Gill 
  Date:   2023-06-08 (Thu, 08 Jun 2023)

  Changed paths:
M Source/WebCore/WebCore.xcodeproj/project.pbxproj

  Log Message:
  ---
  Move BaselineAlignmentInlines into the rendering directory within Xcode
https://bugs.webkit.org/show_bug.cgi?id=257859
rdar://110478170

Reviewed by Tim Horton.

This file lives within the rendering directory of WebCore, so it should
be reflected that way within XCode.

* Source/WebCore/WebCore.xcodeproj/project.pbxproj:

Canonical link: https://commits.webkit.org/265009@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c8996a: [css-flexbox] Rename LineContext to LineState.

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c8996adb70693fd8248900697852545a7a9539d9
  
https://github.com/WebKit/WebKit/commit/c8996adb70693fd8248900697852545a7a9539d9
  Author: Sammy Gill 
  Date:   2023-05-24 (Wed, 24 May 2023)

  Changed paths:
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h

  Log Message:
  ---
  [css-flexbox] Rename LineContext to LineState.
https://bugs.webkit.org/show_bug.cgi?id=257225
rdar://109738350

Reviewed by Alan Baradlay.

LineState is a slightly better name in the flex layout code here
since there are various points at which we are modifying it and
"context," seems to imply some level of immutability.

* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::LineState::LineState):
(WebCore::RenderFlexibleBox::repositionLogicalHeightDependentFlexItems):
(WebCore::RenderFlexibleBox::layoutFlexItems):
(WebCore::RenderFlexibleBox::layoutAndPlaceChildren):
(WebCore::RenderFlexibleBox::alignFlexLines):
(WebCore::RenderFlexibleBox::alignChildren):
(WebCore::RenderFlexibleBox::flipForRightToLeftColumn):
(WebCore::RenderFlexibleBox::flipForWrapReverse):
(WebCore::RenderFlexibleBox::LineContext::LineContext): Deleted.
* Source/WebCore/rendering/RenderFlexibleBox.h:

Canonical link: https://commits.webkit.org/264500@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 271ed0: Change enums and unspecified enum classes to enum ...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 271ed0f956ebf2bae8dc134368dd0d18883b5b20
  
https://github.com/WebKit/WebKit/commit/271ed0f956ebf2bae8dc134368dd0d18883b5b20
  Author: Sammy Gill 
  Date:   2023-05-24 (Wed, 24 May 2023)

  Changed paths:
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h

  Log Message:
  ---
  Change enums and unspecified enum classes to enum class uint8_t in 
RenderFlexibleBox.
https://bugs.webkit.org/show_bug.cgi?id=257242
rdar://109745776

Reviewed by Aditya Keerthi.

We prefer to use enum classes whenever possible and RenderFlexibleBox
has an instance of an enum that can be modified. Also, all of the enums
in this class can fit into a uint8_t so we can also specify that.

* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::layoutFlexItems):
(WebCore::RenderFlexibleBox::freezeInflexibleItems):
(WebCore::RenderFlexibleBox::resolveFlexibleLengths):
* Source/WebCore/rendering/RenderFlexibleBox.h:

Canonical link: https://commits.webkit.org/264494@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 48c6a9: [baseline-alignment]Rename BaselineContext to Base...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 48c6a9eda4fdc93834a69222bd4db466c7b94e52
  
https://github.com/WebKit/WebKit/commit/48c6a9eda4fdc93834a69222bd4db466c7b94e52
  Author: Sammy Gill 
  Date:   2023-05-24 (Wed, 24 May 2023)

  Changed paths:
M Source/WebCore/rendering/BaselineAlignment.cpp
M Source/WebCore/rendering/BaselineAlignment.h
M Source/WebCore/rendering/GridBaselineAlignment.cpp
M Source/WebCore/rendering/GridBaselineAlignment.h

  Log Message:
  ---
  [baseline-alignment]Rename BaselineContext to BaselineAlignmentState.
https://bugs.webkit.org/show_bug.cgi?id=257233
rdar://109742609

Reviewed by Alan Baradlay.

This class is used primarily to provide an API for a formatting context
to interact with baseline sharing groups for baseline alignment. Also, a
baseline alignment context refers to a particular aspect of a formatting
context upon which baseline alignment occurs, such as lines in flex
layout.

Instead we can refer to this as BaselineAlignmentState since this is
the type of information we are holding in it.

* Source/WebCore/rendering/BaselineAlignment.cpp:
(WebCore::BaselineAlignmentState::BaselineAlignmentState):
(WebCore::BaselineAlignmentState::sharedGroup const):
(WebCore::BaselineAlignmentState::updateSharedGroup):
(WebCore::BaselineAlignmentState::findCompatibleSharedGroup):
(WebCore::BaselineContext::BaselineContext): Deleted.
(WebCore::BaselineContext::sharedGroup const): Deleted.
(WebCore::BaselineContext::updateSharedGroup): Deleted.
(WebCore::BaselineContext::findCompatibleSharedGroup): Deleted.
* Source/WebCore/rendering/BaselineAlignment.h:
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::updateBaselineAlignmentContext):
* Source/WebCore/rendering/GridBaselineAlignment.h:

Canonical link: https://commits.webkit.org/264484@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2c6261: [css-flexbox][baseline-alignment] Do not synthesiz...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2c62617577b66ac454176fbe5f4cf85f998272c3
  
https://github.com/WebKit/WebKit/commit/2c62617577b66ac454176fbe5f4cf85f998272c3
  Author: Sammy Gill 
  Date:   2023-05-23 (Tue, 23 May 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-lr-flexbox-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-lr-flexbox-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-lr-grid-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-lr-grid-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-lr-items-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-lr-items.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-lr-table-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-lr-table-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-flexbox-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-flexbox-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-grid-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-grid-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-items-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-items.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-table-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-column-vert-rl-table-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-lr-column-horz-flexbox-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-lr-column-horz-flexbox-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-lr-column-horz-grid-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-lr-column-horz-grid-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-lr-column-horz-items-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-lr-column-horz-items.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-lr-column-horz-table-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-lr-column-horz-table-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-rl-column-horz-flexbox-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-rl-column-horz-flexbox-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-rl-column-horz-grid-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-rl-column-horz-grid-item.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-rl-column-horz-items-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-rl-column-horz-items.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-rl-column-horz-table-item-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/align-items-baseline-vert-rl-column-horz-table-item.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-001-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-002-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-003-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-004-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-006-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-007-expected.txt
M Source/WebCore/rendering

[webkit-changes] [WebKit/WebKit] 62aba9: Change BaselineGroup's items HashSet to WeakHashSet.

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 62aba919edb6ed15b57340857d66d55c4d6034df
  
https://github.com/WebKit/WebKit/commit/62aba919edb6ed15b57340857d66d55c4d6034df
  Author: Sammy Gill 
  Date:   2023-05-16 (Tue, 16 May 2023)

  Changed paths:
M Source/WebCore/rendering/BaselineAlignment.cpp
M Source/WebCore/rendering/BaselineAlignment.h
M Source/WebCore/rendering/GridBaselineAlignment.cpp

  Log Message:
  ---
  Change BaselineGroup's items HashSet to WeakHashSet.
https://bugs.webkit.org/show_bug.cgi?id=256795
rdar://109363884

Reviewed by Tim Nguyen.

In order to keep track of items within a baseline sharing group, this
class currently stores raw pointers to renderers within a HashSet.
To improve upon this we can change the HashSet into a WeakHashSet
since the baseline alignment code does not need to express any
sort of ownership over the renderers.

The size() method on BaselineGroup was also changed to computeSize()
to make it clear that we will need to non-trivially determine the
number of items in the baseline sharing group.

* Source/WebCore/rendering/BaselineAlignment.cpp:
(WebCore::BaselineGroup::update):
(WebCore::BaselineGroup::isCompatible const):
* Source/WebCore/rendering/BaselineAlignment.h:
(WebCore::BaselineGroup::computeSize const):
(WebCore::BaselineGroup::size const): Deleted.
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::GridBaselineAlignment::baselineOffsetForChild const):

Canonical link: https://commits.webkit.org/264132@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9e1f20: Change AllowedBaseline enum to enum class.

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9e1f206c762c490815fb1fd90f4116c9a030d9e9
  
https://github.com/WebKit/WebKit/commit/9e1f206c762c490815fb1fd90f4116c9a030d9e9
  Author: Sammy Gill 
  Date:   2023-05-16 (Tue, 16 May 2023)

  Changed paths:
M Source/WebCore/rendering/BaselineAlignmentInlines.h
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderGrid.h

  Log Message:
  ---
  Change AllowedBaseline enum to enum class.
https://bugs.webkit.org/show_bug.cgi?id=256794
rdar://109362850

Reviewed by Tim Nguyen.

It is preferable to use enum classes over standard enums and this is
another one that can be converted from an enum to an enum class.

* Source/WebCore/rendering/BaselineAlignmentInlines.h:
(): Deleted.
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::isBaselineAlignmentForChild const):
(WebCore::RenderGrid::getBaselineChild const):
* Source/WebCore/rendering/RenderGrid.h:

Canonical link: https://commits.webkit.org/264127@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 493db5: [baseline-alignment] Move BaselineContext and Base...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 493db53c8c0b4ad4b3c1180d356af40a679db746
  
https://github.com/WebKit/WebKit/commit/493db53c8c0b4ad4b3c1180d356af40a679db746
  Author: Sammy Gill 
  Date:   2023-05-16 (Tue, 16 May 2023)

  Changed paths:
M Source/WebCore/Sources.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
A Source/WebCore/rendering/BaselineAlignment.cpp
A Source/WebCore/rendering/BaselineAlignment.h
A Source/WebCore/rendering/BaselineAlignmentInlines.h
M Source/WebCore/rendering/GridBaselineAlignment.cpp
M Source/WebCore/rendering/GridBaselineAlignment.h
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderGrid.h
M Source/WebCore/rendering/style/TextSizeAdjustment.cpp

  Log Message:
  ---
  [baseline-alignment] Move BaselineContext and BaselineGroup out of 
GridBaselineAlignment.
https://bugs.webkit.org/show_bug.cgi?id=256775
rdar://problem/109336789

Reviewed by Brent Fulgham and Tim Nguyen.

These two classes represent parts of the baseline alignment spec in
css-align-3 in general and are not specific to grid. These classes
can be useful for baseline alignment in other formatting contexts, such
as flex, so we will attempt to share them between all of the contexts
where needed. We may be able to abstract more things out of 
GridBaselineAlignment,
but it is not super clear what else at this point so it will be best to
start here, integrate the classes into another formatting context, and
then come back and see what else, if anything, can be moved around.

A couple of new #includes were needed in TextSizeAdjustment.cpp and
RenderGrid.cpp due to new compile errors in the unified sources.

* Source/WebCore/Sources.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/rendering/BaselineAlignment.cpp: Added.
(WebCore::BaselineGroup::BaselineGroup):
(WebCore::BaselineGroup::update):
(WebCore::BaselineGroup::isOppositeBlockFlow const):
(WebCore::BaselineGroup::isOrthogonalBlockFlow const):
(WebCore::BaselineGroup::isCompatible const):
(WebCore::BaselineContext::BaselineContext):
(WebCore::BaselineContext::sharedGroup const):
(WebCore::BaselineContext::updateSharedGroup):
(WebCore::BaselineContext::findCompatibleSharedGroup):
* Source/WebCore/rendering/BaselineAlignment.h: Copied from 
Source/WebCore/rendering/GridBaselineAlignment.h.
(WebCore::BaselineGroup::maxAscent const):
(WebCore::BaselineGroup::size const):
* Source/WebCore/rendering/BaselineAlignmentInlines.h: Added.
(WebCore::isBaselinePosition):
(WebCore::isFirstBaselinePosition):
* Source/WebCore/rendering/GridBaselineAlignment.cpp:
(WebCore::BaselineGroup::BaselineGroup): Deleted.
(WebCore::BaselineGroup::update): Deleted.
(WebCore::BaselineGroup::isOppositeBlockFlow const): Deleted.
(WebCore::BaselineGroup::isOrthogonalBlockFlow const): Deleted.
(WebCore::BaselineGroup::isCompatible const): Deleted.
(WebCore::BaselineContext::BaselineContext): Deleted.
(WebCore::BaselineContext::sharedGroup const): Deleted.
(WebCore::BaselineContext::updateSharedGroup): Deleted.
(WebCore::BaselineContext::findCompatibleSharedGroup): Deleted.
* Source/WebCore/rendering/GridBaselineAlignment.h:
(WebCore::BaselineGroup::maxAscent const): Deleted.
(WebCore::BaselineGroup::size const): Deleted.
(): Deleted.
(WebCore::isBaselinePosition): Deleted.
(WebCore::isFirstBaselinePosition): Deleted.
* Source/WebCore/rendering/RenderGrid.cpp:
* Source/WebCore/rendering/style/TextSizeAdjustment.cpp:

Canonical link: https://commits.webkit.org/264113@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ff409b: [css-grid][masonry] Containing block for items in ...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ff409be22993805de88d0d684204696e8e2dd32b
  
https://github.com/WebKit/WebKit/commit/ff409be22993805de88d0d684204696e8e2dd32b
  Author: Sammy Gill 
  Date:   2023-05-12 (Fri, 12 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:
  ---
  [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.

grid {
display: grid;
grid-template-columns:masonry;
grid-template-rows: auto;
}





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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 1e66b0: [baseline-alignment][flex] Ascent for flex items t...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1e66b0fc954597d3d357d1c7db0c7b8373dad8b1
  
https://github.com/WebKit/WebKit/commit/1e66b0fc954597d3d357d1c7db0c7b8373dad8b1
  Author: Sammy Gill 
  Date:   2023-05-11 (Thu, 11 May 2023)

  Changed paths:
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-line-clamp-001.tentative-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-overflow-001-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-overflow-002-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-overflow-003-expected.txt
M Source/WebCore/rendering/RenderBox.h
M Source/WebCore/rendering/RenderFlexibleBox.cpp

  Log Message:
  ---
  [baseline-alignment][flex] Ascent for flex items that are scroll containers 
should be clamped to the border box.
https://bugs.webkit.org/show_bug.cgi?id=246229
rdar://100908615

Reviewed by Alan Baradlay.

If a flex item is a scroll container (e.g. overflow scroll/hidden) then
it may provide an ascent value that is outside the visible content box
and result in a non-visible position being used for baseline alignment.

When determining the ascent of a flex item, we will check to see if it
is a scroll container by checking to see if it has an overflow value
of either scroll, hidden, or auto and then clamp the used ascent value
of the box to the bottom/top edges of its border box if it is.

https://drafts.csswg.org/css-align/#baseline-export

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-line-clamp-001.tentative-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-overflow-001-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-overflow-002-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-overflow-003-expected.txt:
* Source/WebCore/rendering/RenderBox.h:
(WebCore::RenderBox::isScrollContainerX const):
(WebCore::RenderBox::isScrollContainerY const):
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::flexItemIsScrollContainerCrossAxis const):
(WebCore::RenderFlexibleBox::marginBoxAscentForChild):
(WebCore::RenderFlexibleBox::layoutAndPlaceChildren):
* Source/WebCore/rendering/RenderFlexibleBox.h:

Canonical link: https://commits.webkit.org/263974@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 215644: [grid][masonry] Update masonry items' offsets usin...

[Sammy Gill]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 215644fbb8d3ce7fad0dc7732864cbf76928253a
  
https://github.com/WebKit/WebKit/commit/215644fbb8d3ce7fad0dc7732864cbf76928253a
  Author: Sammy Gill 
  Date:   2023-05-04 (Thu, 04 May 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/item-placement/masonry-rows-with-grid-width-changed-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/item-placement/masonry-rows-with-grid-width-changed-ref.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/item-placement/masonry-rows-with-grid-width-changed.html
M Source/WebCore/rendering/GridMasonryLayout.cpp

  Log Message:
  ---
  [grid][masonry] Update masonry items' offsets using HashMap's set() instead 
of add().
https://bugs.webkit.org/show_bug.cgi?id=255023
rdar://107666148

Reviewed by Brent Fulgham.

During Masonry layout we compute the offsets that each item should have
in the masonry axis and store them into a HashMap that we will reference
later to adjust the items to their final position in the grid. Currently,
we add() to the HashMap which is problematic if we need to relayout the
items when, for example, the size of the window changes. This will not
update the offsets for the items correctly and so instead we should use
set() to accomplish this.

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/item-placement/masonry-rows-with-grid-width-changed-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/item-placement/masonry-rows-with-grid-width-changed-ref.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/masonry/tentative/item-placement/masonry-rows-with-grid-width-changed.html:
 Added.
* Source/WebCore/rendering/GridMasonryLayout.cpp:
(WebCore::GridMasonryLayout::updateItemOffset):

Canonical link: https://commits.webkit.org/263709@main


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes