⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Timeline



Jun 12, 2022:

9:26 PM Changeset in webkit [295481] by Said Abou-Hallawa
  • 50 edits
    4 adds in trunk

[Filters] LightSource should keep its points in <length-percentage> units
​https://bugs.webkit.org/show_bug.cgi?id=241535
<rdar://problem/94973414>

Reviewed by Cameron McCormack.

PointLightSource and SpotLightSource are created with points in user space coordinates.
See SVGFEPointLightElement::lightSource() and SVGFESpotLightElement::lightSource().
But this requires knowing the filter targetBoundingBox and the primitiveUnits at
the LightSource creation time.

When dynamically updating these points through SVGFEDiffuseLightingElement::
setFilterEffectAttribute() or SVGFESpecularLightingElement::setFilterEffectAttribute()
the SVGFilter is not available and these points are stored as <length-percentage>
coordinates. This means if the primitiveUnits is SVG_UNIT_TYPE_OBJECTBOUNDINGBOX,
fractions of the targetBoundingBox will be treated as lengths in user space.

The fix is to store the LightSources points in <length-percentage> units and to
resolve them to user space coordinates in initPaintingData().

  • LayoutTests/svg/filters/feDiffuseLighting-feSpotLight-dynamic-update-expected.svg: Added.
  • LayoutTests/svg/filters/feDiffuseLighting-feSpotLight-dynamic-update.svg: Added.
  • LayoutTests/svg/filters/feSpecularLighting-fePointLight-dynamic-update-expected.svg: Added.
  • LayoutTests/svg/filters/feSpecularLighting-fePointLight-dynamic-update.svg: Added.
  • Source/WebCore/platform/graphics/filters/Filter.h:

(WebCore::Filter::resolvedPoint3D const):

  • Source/WebCore/platform/graphics/filters/PointLightSource.cpp:

(WebCore::PointLightSource::PointLightSource):
(WebCore::PointLightSource::initPaintingData const):
(WebCore::PointLightSource::setX):
(WebCore::PointLightSource::setY):
(WebCore::PointLightSource::setZ):

  • Source/WebCore/platform/graphics/filters/PointLightSource.h:

(WebCore::PointLightSource::position const):
(WebCore::PointLightSource::encode const):

  • Source/WebCore/platform/graphics/filters/SpotLightSource.cpp:

(WebCore::SpotLightSource::SpotLightSource):
(WebCore::SpotLightSource::initPaintingData const):
(WebCore::SpotLightSource::setX):
(WebCore::SpotLightSource::setY):
(WebCore::SpotLightSource::setZ):
(WebCore::SpotLightSource::setPointsAtX):
(WebCore::SpotLightSource::setPointsAtY):
(WebCore::SpotLightSource::setPointsAtZ):

  • Source/WebCore/platform/graphics/filters/SpotLightSource.h:

(WebCore::SpotLightSource::position const):
(WebCore::SpotLightSource::direction const):
(WebCore::SpotLightSource::encode const):

  • Source/WebCore/svg/SVGFEBlendElement.cpp:

(WebCore::SVGFEBlendElement::filterEffect const):

  • Source/WebCore/svg/SVGFEBlendElement.h:
  • Source/WebCore/svg/SVGFEColorMatrixElement.cpp:

(WebCore::SVGFEColorMatrixElement::filterEffect const):

  • Source/WebCore/svg/SVGFEColorMatrixElement.h:
  • Source/WebCore/svg/SVGFEComponentTransferElement.cpp:

(WebCore::SVGFEComponentTransferElement::filterEffect const):

  • Source/WebCore/svg/SVGFEComponentTransferElement.h:
  • Source/WebCore/svg/SVGFECompositeElement.cpp:

(WebCore::SVGFECompositeElement::filterEffect const):

  • Source/WebCore/svg/SVGFECompositeElement.h:
  • Source/WebCore/svg/SVGFEConvolveMatrixElement.cpp:

(WebCore::SVGFEConvolveMatrixElement::filterEffect const):

  • Source/WebCore/svg/SVGFEConvolveMatrixElement.h:
  • Source/WebCore/svg/SVGFEDiffuseLightingElement.cpp:

(WebCore::SVGFEDiffuseLightingElement::filterEffect const):

  • Source/WebCore/svg/SVGFEDiffuseLightingElement.h:
  • Source/WebCore/svg/SVGFEDisplacementMapElement.cpp:

(WebCore::SVGFEDisplacementMapElement::filterEffect const):

  • Source/WebCore/svg/SVGFEDisplacementMapElement.h:
  • Source/WebCore/svg/SVGFEDistantLightElement.cpp:

(WebCore::SVGFEDistantLightElement::lightSource const):

  • Source/WebCore/svg/SVGFEDistantLightElement.h:
  • Source/WebCore/svg/SVGFEDropShadowElement.cpp:

(WebCore::SVGFEDropShadowElement::filterEffect const):

  • Source/WebCore/svg/SVGFEDropShadowElement.h:
  • Source/WebCore/svg/SVGFEFloodElement.cpp:

(WebCore::SVGFEFloodElement::filterEffect const):

  • Source/WebCore/svg/SVGFEFloodElement.h:
  • Source/WebCore/svg/SVGFEGaussianBlurElement.cpp:

(WebCore::SVGFEGaussianBlurElement::filterEffect const):

  • Source/WebCore/svg/SVGFEGaussianBlurElement.h:
  • Source/WebCore/svg/SVGFEImageElement.cpp:

(WebCore::SVGFEImageElement::filterEffect const):

  • Source/WebCore/svg/SVGFEImageElement.h:
  • Source/WebCore/svg/SVGFELightElement.h:
  • Source/WebCore/svg/SVGFEMergeElement.cpp:

(WebCore::SVGFEMergeElement::filterEffect const):

  • Source/WebCore/svg/SVGFEMergeElement.h:
  • Source/WebCore/svg/SVGFEMorphologyElement.cpp:

(WebCore::SVGFEMorphologyElement::filterEffect const):

  • Source/WebCore/svg/SVGFEMorphologyElement.h:
  • Source/WebCore/svg/SVGFEOffsetElement.cpp:

(WebCore::SVGFEOffsetElement::filterEffect const):

  • Source/WebCore/svg/SVGFEOffsetElement.h:
  • Source/WebCore/svg/SVGFEPointLightElement.cpp:

(WebCore::SVGFEPointLightElement::lightSource const):

  • Source/WebCore/svg/SVGFEPointLightElement.h:
  • Source/WebCore/svg/SVGFESpecularLightingElement.cpp:

(WebCore::SVGFESpecularLightingElement::filterEffect const):

  • Source/WebCore/svg/SVGFESpecularLightingElement.h:
  • Source/WebCore/svg/SVGFESpotLightElement.cpp:

(WebCore::SVGFESpotLightElement::lightSource const):

  • Source/WebCore/svg/SVGFESpotLightElement.h:
  • Source/WebCore/svg/SVGFETileElement.cpp:

(WebCore::SVGFETileElement::filterEffect const):

  • Source/WebCore/svg/SVGFETileElement.h:
  • Source/WebCore/svg/SVGFETurbulenceElement.cpp:

(WebCore::SVGFETurbulenceElement::filterEffect const):

  • Source/WebCore/svg/SVGFETurbulenceElement.h:
  • Source/WebCore/svg/SVGFilterPrimitiveStandardAttributes.h:
  • Source/WebCore/svg/graphics/filters/SVGFilter.cpp:

(WebCore::SVGFilter::resolvedPoint3D const):

  • Source/WebCore/svg/graphics/filters/SVGFilter.h:
  • Source/WebCore/svg/graphics/filters/SVGFilterBuilder.cpp:

(WebCore::SVGFilterBuilder::buildFilterExpression):

Canonical link: ​https://commits.webkit.org/251486@main

8:22 PM Changeset in webkit [295480] by Jean-Yves Avenard
  • 1 edit in trunk/Source/WebCore/platform/graphics/cocoa/SourceBufferParserWebM.cpp

Handle case where only a single video frame was appended.
​https://bugs.webkit.org/show_bug.cgi?id=241453

Reviewed by Jer Noble.

Under some circumstances, only a single frame will be appended.
When the queue of pending samples gets flushed we can't rely on the last sample's time
nor the last duration.

  • Source/WebCore/platform/graphics/cocoa/SourceBufferParserWebM.cpp:

(WebCore::WebMParser::VideoTrackData::flushPendingSamples):

Canonical link: ​https://commits.webkit.org/251485@main

7:40 PM Changeset in webkit [295479] by Wenson Hsieh
  • 5 edits
    1 copy
    1 add in trunk

REGRESSION (r290875): [iOS] Safari renders many blank tiles after navigating back to webpage from PDF
​https://bugs.webkit.org/show_bug.cgi?id=241536
rdar://94637323

Reviewed by Tim Horton.

When using a standard content view, the logic in WKApplicationStateTrackingView creates a
WebKit::ApplicationStateTracker after the view becomes parented in the view hierarchy (in
-didMoveToWindow), and holds onto it until it is about to be unparented from the view hierarchy
(in -willMoveToWindow:).

However, in the case where WKApplicationStateTrackingView is a WKPDFView (i.e. we're hosting a
remote PDFKit view controller), the behavior is much more intricate; this is because the WKPDFView
is replaced in the view hierarchy by the remote view controller's sizing view once the
PDFHostViewController has finished loading its remote content. Once this happens, the
-_contentView of the WKApplicationStateTrackingView points to this sizing view instead, and the
WKPDFView (which subclasses WKApplicationStateTrackingView) is no longer in the view hierarchy.

Prior to r290875: when we remove WKPDFView from the view hierarchy and replace it with a sizing
view, self._contentView in both cases already points to the _UISizeTrackingView, even though it
hasn't been added to the view hierarchy yet. Since we bail if this size tracking view is not in the
view hierarchy, we previously ended up never clearing out the application state tracker when loading
a PDF, which means that -[WKPDFView isBackground] would always return NO, despite the view not
being in the view hierarchy.

In r290875, I replaced the !self._contentView.window check with !_applicationStateTracker, which
caused us to now clear out the application state tracker when unparenting WKPDFView. This, in
turn, means that -[WKPDFView isBackground] now returns YES when the WKPDFView is removed and
replaced with the size tracking view. When navigating back to the previous page, this causes us to
end up in a state where the WindowIsActive flag in WebPageProxy::m_activityState is off until
the next page load, since we only update this flag in WebPageProxy::finishAttachingToWebProcess,
which is called when WKPDFView is still being used as the custom content view. This ultimately
causes the symptoms observed in this bug, which include blank tiles when scrolling.

To address this bug, we first revert the changes in r290875, which allows WKPDFView to behave as
if it were in the foreground, even when it's not in the view hierarchy:

`

  • (void)willMoveToWindow:(UIWindow *)newWindow

{

if (!self._contentView.window
newWindow)

return;

…

`

Of course, this (by itself) would bring back <​https://webkit.org/b/237505>; to preserve that fix, we
additionally limit the early return to cases where the window is *not* in the process of being
destroyed (that is, -willMoveToWindow: is called with both the new window == nil, while the
current window self.window == nil):

`

  • (void)willMoveToWindow:(UIWindow *)newWindow

{

BOOL windowIsBeingDeallocated = !self.window && !newWindow;
if (!windowIsBeingDeallocated) {

if (!self._contentView.window
newWindow)

return;

}
…

`

Note that this is logically equivalent to:

`

  • (void)willMoveToWindow:(UIWindow *)newWindow

{

if ((self.window
newWindow) && (!self._contentView.window newWindow))

return;

…

`

...which can also be rewritten a bit more succinctly as:

`

  • (void)willMoveToWindow:(UIWindow *)newWindow

{

if ((self.window && !self._contentView.window)
newWindow)

return;

…

`

In other words:

  • In the case where a standard content view is used (i.e. self == self._contentView), we always

clear out _applicationStateTracker if the window we're moving to is nil. This takes care of the
normal scenario of unparenting a web view, as well as the corner case where the web view is
unparented in the middle of -[UIWindow dealloc].

  • In the case of PDFHostViewController where a custom content view is used, we'll return early

in -willMoveToWindow: and keep the existing _applicationStateTracker, because the size tracking
view has not been parented yet.

Test: ApplicationStateTracking.NavigatingFromPDFDoesNotLeaveWebViewInactive

  • Source/WebKit/UIProcess/ios/WKApplicationStateTrackingView.mm:

(-[WKApplicationStateTrackingView willMoveToWindow:]):

  • Tools/TestWebKitAPI/Configurations/Base.xcconfig:

Add Source/WebKit/Platform/spi/ios as a relative header include path for iOS family, such that we
can import the internal PDFKitSPI.h in API tests.

  • Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • Tools/TestWebKitAPI/Tests/ios/ApplicationStateTracking.mm:

(TestWebKitAPI::TEST):

Introduce a new API test that loads a simple webpage, navigates to a PDF document (and uses a remote
PDFKit view controller to render it), and then navigate back to the original webpage.

  • Tools/TestWebKitAPI/cocoa/TestWKWebView.mm:

(-[WKWebView _isBackground]): Deleted.

Remove a workaround for API tests that's no longer necessary, so that the new API test fails without
this fix. This workaround was added in r231663, but became unnecessary after r236989, which removed
the dependency on -_isBackground.

  • Tools/TestWebKitAPI/ios/TestPDFHostViewController.h:
  • Tools/TestWebKitAPI/ios/TestPDFHostViewController.mm: Added.

Add a helper class that allows us to swizzle out +createHostView:forExtensionIdentifier:, and
return a PDFHostViewController subclass, with a subset of method stubs required to avoid crashes
when running API tests. This allows us to simulate PDFKit remote view controller presentation in API
tests.

(-[TestPDFHostViewController setDelegate:]):
(-[TestPDFHostViewController setDocumentData:withScrollView:]):
(-[TestPDFHostViewController currentPageIndex]):
(-[TestPDFHostViewController pageCount]):
(-[TestPDFHostViewController minimumZoomScale]):
(-[TestPDFHostViewController maximumZoomScale]):
(-[TestPDFHostViewController findString:withOptions:]):
(-[TestPDFHostViewController cancelFindString]):
(-[TestPDFHostViewController cancelFindStringWithHighlightsCleared:]):
(-[TestPDFHostViewController focusOnSearchResultAtIndex:]):
(-[TestPDFHostViewController clearSearchHighlights]):
(-[TestPDFHostViewController goToPageIndex:]):
(-[TestPDFHostViewController updatePDFViewLayout]):
(-[TestPDFHostViewController gestureRecognizerShouldBegin:]):
(-[TestPDFHostViewController pageNumberIndicator]):
(-[TestPDFHostViewController snapshotViewRect:snapshotWidth:afterScreenUpdates:withResult:]):
(-[TestPDFHostViewController beginPDFViewRotation]):
(-[TestPDFHostViewController endPDFViewRotation]):
(TestWebKitAPI::swizzledCreateHostViewForExtensionIdentifier):
(TestWebKitAPI::createPDFHostViewControllerSwizzler):

Canonical link: ​https://commits.webkit.org/251484@main

7:45 AM Changeset in webkit [295478] by Alan Bujtas
  • 1 edit
    2 adds in trunk

Incorrect sizing of elements with visually hidden text inside
​https://bugs.webkit.org/show_bug.cgi?id=241459

Reviewed by Antti Koivisto.

This patch fixes the incorrect inline width computation when an inline box (e.g. <span>) with margin-inline-start (e.g. margin-left) is followed by an out-of-flow element.

<div id=container>some<span style="margin-left: 10px"><div style="position: absolute"></div>text</span></div>

In LineBreaker::nextLineBreak, while iterating through the content of [container], the margin-left of the inline box (span) is included twice; first for the out-of-flow box and second for the [text] content. This patch ensures that when we reach the [text] content, we check if we have already reserved the space for the inline box's margin (padding and border).
(While out-of-flow inline level boxes are not supposed to participate in inline layout, (in legacy line layout) in order to compute their static position we include them in line layout. A more involved fix would be to exclude all out-of-flow boxes from line layout and deal with their static positioning after completing the core line layout).

  • LayoutTests/fast/block/shrink-to-fit-with-out-of-flow-and-inline-box-margin-expected.html: Added.
  • LayoutTests/fast/block/shrink-to-fit-with-out-of-flow-and-inline-box-margin.html: Added.
  • Source/WebCore/rendering/line/BreakingContext.h: Make sure when the out-of-flow box takes the margin, we don't add it again for the text content. Also, reset this flag for subsequent content.

(WebCore::inlineLogicalWidth):

Canonical link: ​https://commits.webkit.org/251483@main

Jun 11, 2022:

8:25 PM Changeset in webkit [295477] by Alan Bujtas
  • 1 edit in trunk/Source/WebCore/rendering/LegacyLineLayout.cpp

Reset the dirty bit on the inline level renderers when counter is present
​https://bugs.webkit.org/show_bug.cgi?id=241534

Reviewed by Antti Koivisto.

While the actual line layout happens in layoutRunsAndFloats, we pre-reset the needsLayout flag as we walk the renderers and prepare them for the inline layout.
Normally this simple DOM order walk clears all the layout bits just fine, but counters can re-dirty any "connected" renderer in a seemingly random order.
This patch ensures that all inline level box renders are marked clean before returning from layoutLineBoxes.

  • Source/WebCore/rendering/LegacyLineLayout.cpp:

(WebCore::LegacyLineLayout::layoutLineBoxes):

Canonical link: ​https://commits.webkit.org/251482@main

4:44 PM Changeset in webkit [295476] by mmaxfield@apple.com
  • 22 edits
    2 adds in trunk

Delay system font shorthand resolution until after parsing
​https://bugs.webkit.org/show_bug.cgi?id=241454

Reviewed by Antti Koivisto.

This is the fifth piece of ​https://bugs.webkit.org/show_bug.cgi?id=237817, and is the main crux
of the fix to that bug. When content says something like "font: caption" or "font: -apple-system-body"
we have to map that to CSS properties like font-size and font-weight, so inheritance works properly
across different elements. On iOS, system settings can affect this mapping. Before this patch, we
were performing this mapping inside the parser, which is wrong because we'll never re-parse things
in response to a change in the environment. So, if the page is live, and then the user changes a setting
in system preferences, we won't re-parse, which means the page won't update to accomodate the new setting
the user changed.

This patch changes the parser to not do this mapping, but instead just to emit CSSValues which directly
and simply represent the value that was present in the CSS source itself. So, if the content says
"font: caption" we'll create CSSPrimitiveValues which just hold "caption" and use that for all the longhands
of the font property. Then, we do the mapping when the values are applied, inside StyleBuilder. StyleBuilder
is re-run in response to environment changes, so this piece is necessary for system settings to immediately
take effect without a reload of the page.

This change is web-exposed, because the contents of CSSValues are exposed to webpages via inspecting the
CSSStyleSheet in JavaScript. So, the change is a little scary, but I think it's the only way to have the
right thing happen with system settings.

This patch also deletes the now-unused system font shorthand cache, which was reimplemented in
​https://github.com/WebKit/WebKit/commit/10cdfcb983187328f4229d5812a0da2a4210e4ef.

This patch isn't sufficient to make system settings fully work - there are some follow-up patches which
are still necessary on top of this:

  1. Have font creation code actually interrogate system settings, and react accordingly, to create fonts

with the appropriate size/weight

  1. Make sure the right things get invalidated, so we don't get erroneous cache hits when system settings

change

  1. Make sure the right events are being delivered to the right places, and triggering the right invalidation,

in response to system settings being changed.

  • LayoutTests/fast/text/font-shorthand-resolution-expected.txt: Added.
  • LayoutTests/fast/text/font-shorthand-resolution.html: Added.
  • Source/WebCore/css/CSSProperties.json:
  • Source/WebCore/css/parser/CSSPropertyParser.cpp:

(WebCore::CSSPropertyParser::consumeSystemFont):
(WebCore::CSSPropertyParser::parseShorthand):

  • Source/WebCore/css/parser/CSSPropertyParserHelpers.h:

(WebCore::CSSPropertyParserHelpers::isSystemFontShorthand):
(WebCore::CSSPropertyParserHelpers::lowerFontShorthand):

  • Source/WebCore/platform/graphics/SystemFontDatabase.h:
  • Source/WebCore/rendering/RenderTheme.h:
  • Source/WebCore/rendering/RenderThemeCocoa.h:
  • Source/WebCore/rendering/RenderThemeCocoa.mm:

(WebCore::RenderThemeCocoa::systemFont const): Deleted.

  • Source/WebCore/rendering/RenderThemeGtk.cpp:

(WebCore::RenderThemeGtk::systemFont const): Deleted.

  • Source/WebCore/rendering/RenderThemePlayStation.cpp:

(WebCore::RenderThemePlayStation::systemFont const): Deleted.

  • Source/WebCore/rendering/RenderThemeWin.cpp:

(WebCore::RenderThemeWin::systemFont const): Deleted.

  • Source/WebCore/style/StyleBuilderConverter.h:

(WebCore::Style::BuilderConverter::convertFontWeight):
(WebCore::Style::BuilderConverter::convertFontVariantCaps):
(WebCore::Style::BuilderConverter::convertLineHeight):

  • Source/WebCore/style/StyleBuilderCustom.h:

(WebCore::Style::BuilderCustom::applyValueFontFamily):
(WebCore::Style::BuilderCustom::applyValueFontStyle):
(WebCore::Style::BuilderCustom::applyValueFontSize):

  • Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::contentSizeCategoryDidChange):

  • Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::WebProcess::accessibilityPreferencesDidChange):

Canonical link: ​https://commits.webkit.org/251481@main

3:32 PM Changeset in webkit [295475] by rniwa@webkit.org
  • 4 edits
    2 adds in trunk

ValidityState object should be the same on each access (JS object getting GC'd incorrectly)
​https://bugs.webkit.org/show_bug.cgi?id=33733

Reviewed by Darin Adler.

Fixed the bug by making the form associated element an opaque root of ValidityState.

  • LayoutTests/fast/forms/ValidityState-gc-expected.txt: Added.
  • LayoutTests/fast/forms/ValidityState-gc.html: Added.
  • Source/WebCore/html/HTMLFormControlElement.h:
  • Source/WebCore/html/HTMLObjectElement.h:
  • Source/WebCore/html/ValidityState.h:

(WebCore::ValidityState::element):
(WebCore::ValidityState::opaqueRootConcurrently):

  • Source/WebCore/html/ValidityState.idl:

Canonical link: ​https://commits.webkit.org/251480@main

8:11 AM Changeset in webkit [295474] by Adrian Perez de Castro
  • 3 edits in trunk/Source

Non-unified build fixes, pre- Web Engines Hackfest edition
​https://bugs.webkit.org/show_bug.cgi?id=241532

Unreviewed non-unified build fixes.

  • Source/WebCore/platform/graphics/filters/FilterResults.cpp: Add missing ImageBuffer.h header inclusion.
  • Source/WebCore/platform/graphics/gtk/SystemFontDatabaseGTK.cpp: Add missing inclusion of headers PlatformScreen.h, <gtk/gtk.h>, and wtf/glib/GUniquePtr.h.
  • Source/WebKit/NetworkProcess/Cookies/WebCookieManager.cpp: Add missing NetworkProcessProxyMessages.h header inclusion.

Canonical link: ​https://commits.webkit.org/251479@main

Note: See TracTimeline for information about the timeline view.