Context Navigation

← Previous Period
Next Period →

Timeline

Mar 15, 2021:

11:55 PM Changeset in webkit [274467] by commit-queue@webkit.org

5 edits in trunk

Fix table-element-001.html
https://bugs.webkit.org/show_bug.cgi?id=223063

Patch by Rob Buis <rbuis@igalia.com> on 2021-03-15
Reviewed by Simon Fraser.

Source/WebCore:

The aspect-ratio property should not apply to table boxes [1].
Tables themselves should respect the property.

[1] https://drafts.csswg.org/css-sizing-4/#aspect-ratio

rendering/RenderBox.cpp:

(WebCore::RenderBox::computeLogicalHeight const):
(WebCore::RenderBox::shouldIgnoreAspectRatio const):
(WebCore::RenderBox::shouldComputeLogicalHeightFromAspectRatio const):
(WebCore::RenderBox::shouldComputeLogicalWidthFromAspectRatio const):

rendering/RenderBox.h:

LayoutTests:

Enable test that passes now.

TestExpectations:

10:55 PM Changeset in webkit [274466] by Nikita Vasilyev

5 edits in trunk/Source/WebInspectorUI

Web Inspector: remove experimental setting and enable Layout sidebar
https://bugs.webkit.org/show_bug.cgi?id=221246
<rdar://problem/74130753>

Reviewed by BJ Burg.

Localizations/en.lproj/localizedStrings.js:
UserInterface/Base/Setting.js:
UserInterface/Views/ElementsTabContentView.js:

(WI.ElementsTabContentView):

UserInterface/Views/SettingsTabContentView.js:

(WI.SettingsTabContentView.prototype._createExperimentalSettingsView):

10:08 PM Changeset in webkit [274465] by Patrick Angle

3 edits in trunk/Source/WebInspectorUI

Web Inspector: Styles sidebar pseudo-class checkboxes appear cramped after resizing window at narrow widths
https://bugs.webkit.org/show_bug.cgi?id=222990

Reviewed by Devin Rousso.

Fixed two compounding bugs that meant that a sidebar could end up using the base minimum width of 250px
instead of the actual minimum width as reported by the selected panel.

UserInterface/Views/MultiSidebar.js:

(WI.MultiSidebar.prototype.didInsertSidebarPanel):
(WI.MultiSidebar.prototype.didRemoveSidebarPanel):
(WI.MultiSidebar.prototype.didSetCollapsed):

Drive-by: Remove unused (and always undefined) flag argument.

(WI.MultiSidebar.prototype._updateMinimumWidthForMultipleSidebars):

Add logic to make sure we can calculate a valid _minimumWidthForMultipleSidebars, and add a mechanism to

allow ignoring the presence of a cached value to force a recalculation.
(WI.MultiSidebar.prototype.get _hasWidthForMultipleSidebars):

Ensure if possible that there is a valid _minimumWidthForMultipleSidebars.

(WI.MultiSidebar.prototype._makeSidebarPanelExclusive):

Sets the sidebar as non-collapsible (which sets collapsed to false) before adding the panel and setting it

as the selected panel so that we don't set the selected panel on a collapsed sidebar.

UserInterface/Views/SingleSidebar.js:

(WI.SingleSidebar.prototype.didSetCollapsed):

Drive-by: Remove always undefined flag argument, use this.collapsed instead.

9:33 PM Changeset in webkit [274464] by Patrick Angle

7 edits in trunk/Source/WebCore

Web Inspector: Grid overlay does not adjust for element inside iframes
https://bugs.webkit.org/show_bug.cgi?id=222920

Reviewed by Simon Fraser.

Resolves an issue when overlays are applied to grids within iframes, which need to account for the
position/transform of their containing frame, and any other parent frames, to appear correctly in relation to
the root frame. This patch also has the side effect of changing how drawing the grid overlay while the page is
scrolled by allowing localPointToRootPoint to account for the scroll translation instead of explicitly
offsetting drawing by the scroll offset.

Widget, ScrollView, and FrameView are updated to retain floating-point precision where necessary.

inspector/InspectorOverlay.cpp:

(WebCore::localPointToRootPoint):

Use floating-point precision instead of integer precision.

(WebCore::InspectorOverlay::drawGridOverlay):

Use localPointToRootPoint to calculate absolute points relative to a renderGrid's parent hierarchy.
Remove graphics context translation, as localPointToRootPoint will account for this translation.
page/FrameView.cpp:

(WebCore::FrameView::convertFromRendererToContainingView const):
(WebCore::FrameView::convertToContainingView const):

page/FrameView.h:
platform/ScrollView.cpp:

(WebCore::ScrollView::contentsToView const):

platform/ScrollView.h:

(WebCore::ScrollView::convertChildToSelf const):

platform/Widget.cpp:

(WebCore::Widget::convertToContainingView const):

8:54 PM Changeset in webkit [274463] by commit-queue@webkit.org

5 edits in trunk

REGRESSION: (r255611) [ Mac ] 3 lldb tests failing related to HashMap
https://bugs.webkit.org/show_bug.cgi?id=207204

Patch by Alex Christensen <achristensen@webkit.org> on 2021-03-15
Reviewed by Simon Fraser.

Source/WTF:

wtf/HashTable.h:

Tools:

In r255780 I removed WebKit LLDB support for HashTables because the LLDB python API doesn't have a way to
do the equivalent of reinterpret_cast. With clever use of a union, I can get a pointer to the table and
tell LLDB it is actually a pointer to an unsigned integer array. Then, using pointer->unsigned->pointer
transformations I can dereference a negative index. It's gross, but it works and makes the tests pass again.

lldb/lldb_webkit.py:

(lldb_init_module):
(lldb_init_module.lldb_webkit):
(WTFHashTable_SummaryProvider):
(WTFHashMap_SummaryProvider):
(WTFHashSet_SummaryProvider):
(WTFHashMapProvider):
(WTFHashMapProvider.init):
(WTFHashMapProvider.tableSize):
(WTFHashMapProvider.keyCount):
(WTFHashSetProvider):
(WTFHashSetProvider.init):
(WTFHashSetProvider.tableSize):
(WTFHashSetProvider.keyCount):
(WTFHashTableProvider):
(WTFHashTableProvider.init):
(WTFHashTableProvider.metadataWithIndex):
(WTFHashTableProvider.tableSize):
(WTFHashTableProvider.keyCount):
(WTFHashTableProvider.num_children):
(WTFHashTableProvider.get_child_index):
(WTFHashTableProvider.get_child_at_index):
(WTFHashTableProvider.update):
(WTFHashTableProvider.has_children):

lldb/lldb_webkit_unittest.py:

(TestSummaryProviders):
(TestSummaryProviders.serial_test_WTFHashMap_tablesize_and_size):
(TestSummaryProviders.serial_test_WTFHashMap_of_vectors_tablesize_and_size):
(TestSummaryProviders.serial_test_WTFHashSet_tablesize_and_size):

8:24 PM Changeset in webkit [274462] by Chris Dumez

18 edits
2 deletes in trunk/Source/WebKit

Unreviewed, revert r272629 as it caused regressions in some apps
https://bugs.webkit.org/show_bug.cgi?id=223232
<rdar://75440378>

SourcesCocoa.txt:
UIProcess/API/Cocoa/WKWebView.mm:
UIProcess/API/Cocoa/WKWebViewInternal.h:
UIProcess/API/Cocoa/WKWebViewPrivate.h:
UIProcess/Cocoa/PageClientImplCocoa.h:
UIProcess/Cocoa/PageClientImplCocoa.mm:
UIProcess/Cocoa/WKBlankOverlayView.h: Removed.
UIProcess/PageClient.h:
UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::didCommitLoadForFrame):
(WebKit::WebPageProxy::runJavaScriptAlert):
(WebKit::WebPageProxy::runJavaScriptConfirm):
(WebKit::WebPageProxy::runJavaScriptPrompt):

UIProcess/WebPageProxy.h:
UIProcess/WebPageProxy.messages.in:
UIProcess/ios/WebPageProxyIOS.mm:

(WebKit::WebPageProxy::didCommitLayerTree):

UIProcess/mac/WebPageProxyMac.mm:
WebKit.xcodeproj/project.pbxproj:
WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::didCommitLoad):

WebProcess/WebPage/WebPage.h:
WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:

(WebKit::TiledCoreAnimationDrawingArea::updateRendering):

WebProcess/WebPage/mac/WebPageMac.mm:

8:07 PM Changeset in webkit [274461] by Simon Fraser

6 edits in trunk/Source/WebCore

Optimize canvas repaints
https://bugs.webkit.org/show_bug.cgi?id=223056

Reviewed by Said Abou-Hallawa.

Currently many draw operations in a canvas trigger a repaint via the didDraw()
code path which goes to HTMLCanvasElement::didDraw(). HTMLCanvasElement did track
a dirty rect and short-circuited repaints which were already dirty, but we paid
the cost of computing the dirty rect (e.g. getting the bounds of a path), and of
the hash lookup in Document::prepareCanvasesForDisplayIfNeeded() every time.

Optimize this by moving the dirty rect tracking into CanvasRenderingContext2DBase.
If the entire canvas is already dirty, we can avoid all the work (this is common,
since pages often clear the entire canvas at the start of every frame). Otherwise,
accumulate into m_dirtyRect. m_dirtyRect is cleared when we paint the canvas.

It would be nice to share more of the didDraw() code in CanvasRenderingContext2DBase
functions, but we want to be able to compute the dirty rect only if it's used, and
a WTF::function()-based approach benchmarked as slower.

This patch is an up-to-10% progression on some canvas subtests in MotionMark.

html/HTMLCanvasElement.cpp:

(WebCore::HTMLCanvasElement::didDraw):
(WebCore::HTMLCanvasElement::paint):

html/HTMLCanvasElement.h:
html/canvas/CanvasRenderingContext.h:

(WebCore::CanvasRenderingContext::clearAccumulatedDirtyRect):
(WebCore::CanvasRenderingContext::paintRenderingResultsToCanvas):

html/canvas/CanvasRenderingContext2DBase.cpp:

(WebCore::CanvasRenderingContext2DBase::fillInternal):
(WebCore::CanvasRenderingContext2DBase::strokeInternal):
(WebCore::CanvasRenderingContext2DBase::fillRect):
(WebCore::CanvasRenderingContext2DBase::strokeRect):
(WebCore::CanvasRenderingContext2DBase::drawImage):
(WebCore::CanvasRenderingContext2DBase::didDraw):
(WebCore::CanvasRenderingContext2DBase::clearAccumulatedDirtyRect):
(WebCore::CanvasRenderingContext2DBase::isEntireBackingStoreDirty const):
(WebCore::CanvasRenderingContext2DBase::putImageData):
(WebCore::CanvasRenderingContext2DBase::drawTextUnchecked):

html/canvas/CanvasRenderingContext2DBase.h:

(WebCore::CanvasRenderingContext2DBase::didDraw):
(WebCore::CanvasRenderingContext2DBase::backingStoreBounds const):

8:03 PM Changeset in webkit [274460] by jer.noble@apple.com

7 edits
1 add in trunk

[WK2] Can get stuck in fullscreen mode if node is removed prior to receiving willEnterFullscreen()
https://bugs.webkit.org/show_bug.cgi?id=223218
<rdar://75009548>

Reviewed by Eric Carlson.

Source/WebCore:

Return false from the following functions if a preflight check kept the function
from completing.

dom/FullscreenManager.cpp:

(WebCore::FullscreenManager::willEnterFullscreen):
(WebCore::FullscreenManager::didEnterFullscreen):
(WebCore::FullscreenManager::willExitFullscreen):
(WebCore::FullscreenManager::didExitFullscreen):

dom/FullscreenManager.h:

Source/WebKit:

There are a number of preflight checks made in each of the listed functions below,
and those preflights can corrupt the state machine of the UIProcess's fullscreen
code. If any of the preflights fail, use the new return value of those methods to
close() the fullscreen presentation.

WebProcess/FullScreen/WebFullScreenManager.cpp:

(WebKit::WebFullScreenManager::willEnterFullScreen):
(WebKit::WebFullScreenManager::didEnterFullScreen):
(WebKit::WebFullScreenManager::willExitFullScreen):
(WebKit::WebFullScreenManager::requestExitFullScreen):

Tools:

TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
TestWebKitAPI/Tests/WebKitCocoa/FullscreenRemoveNodeBeforeEnter.mm: Added.

(TestWebKitAPI::TEST):

7:01 PM Changeset in webkit [274459] by Chris Dumez

2 edits in trunk/Source/WebKit

Avoid heap allocation in RemoteAudioDestinationProxy::renderQuantum()
https://bugs.webkit.org/show_bug.cgi?id=223228

Reviewed by Darin Adler.

Avoid heap allocation in RemoteAudioDestinationProxy::renderQuantum() since this runs on the
audio thread.

WebProcess/GPU/media/RemoteAudioDestinationProxy.cpp:

(WebKit::RemoteAudioDestinationProxy::connectToGPUProcess):
(WebKit::RemoteAudioDestinationProxy::renderQuantum):

6:57 PM Changeset in webkit [274458] by Chris Dumez

3 edits in trunk/Source/WTF

RunLoop::isMain() should not need to do any heap allocations
https://bugs.webkit.org/show_bug.cgi?id=223227

Reviewed by Darin Adler.

RunLoop::isMain() should not need to do any heap allocations. Before this change,
calling RunLoop::isMain() on a non-main thread would call RunLoop::current() which
would allocate the RunLoop for the current thread. This is inefficient and an issue
for WebAudio since we're not allowed to do heap allocation on the audio rendering
thread.

wtf/RunLoop.cpp:

(WTF::RunLoop::runLoopHolder):
(WTF::RunLoop::current):
(WTF::RunLoop::isMain):

wtf/RunLoop.h:

6:25 PM Changeset in webkit [274457] by Wenson Hsieh

15 edits
2 adds in trunk

[iOS] WebPageProxy's EditorState may be stale until the next remote layer tree commit
https://bugs.webkit.org/show_bug.cgi?id=223207
<rdar://problem/75410700>

Reviewed by Tim Horton.

Source/WebKit:

Fixes a race condition wherein it's possible for the cached EditorState in the UI process (on WebPageProxy)
to be set to a stale (older) value after being set to a newer value. This can happen in the case where:

An editor state update is computed and set on a remote layer tree transaction in the web process, inside

WebPage::willCommitLayerTree. A pending BackingStoreFlusher is created, and we dispatch a task onto a
background queue to flush the layer tree commit.

IPC that updates the selection arrives in the web process (e.g. WebPage::selectTextWithGranularityAtPoint),

and causes us to send an EditorStateChanged message to the UI process with this new selection.

The pending BackingStoreFlusher created in step (1) dispatches on the background queue, and sends its

editor state over to the UI process.

As a result, the UI process receives the EditorStateChanged message in step (2) before it receives the remote
layer tree transaction sent in step (3), which contains the editor state computed prior to step (2); we then set
WebPageProxy::m_editorState from its value computed in step (2) to the value computed in step (1).

To fix this (and any similar issues involving out-of-band editor state updates), we introduce a monotonically
increasing transaction ID on editor state that's similar to the one used for remote layer tree commits; we then
avoid updating the editor state in WebPageProxy if we receive an EditorState whose transaction ID is less
than our current ID.

Test: fast/images/image-extraction/ios/reselect-word-in-image-overlay.html

Shared/EditorState.cpp:

(WebKit::EditorState::encode const):
(WebKit::EditorState::decode):

Shared/EditorState.h:

Add the TransactionID, and add encoding/decoding support for the new member.

UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:

(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):

UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::editorStateChanged):
(WebKit::WebPageProxy::updateEditorState):

Refactor this to return a bool, indicating whether the editor state was modified (this only returns false in
the case where the incoming editor state was older than the one we currently have). We also make this method
platform-agnostic, and move the platform-dependent logic previously implemented by individual updateEditorState
implementations into WebPageProxy::didUpdateEditorState instead.

UIProcess/WebPageProxy.h:
UIProcess/gtk/WebPageProxyGtk.cpp: