Timeline



Nov 26, 2020:

8:42 PM Changeset in webkit [270180] by Wenson Hsieh
  • 2 edits in trunk/Source/WebKit

Calling waitForAndDispatchImmediately<M> on a loop fails when multiple M messages arrive simultaneously
​https://bugs.webkit.org/show_bug.cgi?id=219240

Reviewed by Chris Dumez.

Fixes a race that may occur when calling waitForAndDispatchImmediately<N> in a loop, when multiple messages
N arrive on the IPC thread simultaneously. This may result from the following sequence of events (note that
(Main) and (IPC) in the timeline below refer to the main thread and IPC background thread, respectively):

(Main) Call waitForAndDispatchImmediately, and begin waiting.

(IPC) A message N arrives, and is handled in processIncomingMessage by setting the decoder of

m_waitingForMessage and notifying the condition variable.

(Main) The main thread wakes up and starts to process N, clearing out m_waitingForMessage in the process.

(IPC) A second message N arrives. We see that m_waitingForMessage is null, so we don't set the decoder

and bail. Instead, we prepare to call enqueueIncomingMessage and push the message onto the main
thread, *but importantly*, we haven't done so yet.

(Main) Call waitForAndDispatchImmediately again, set m_waitingForMessage, and begin waiting. Since the

incoming message that was just received above has not been enqueued yet, we are unable to avoid waiting
due to the incoming message.

(IPC) We finally call enqueueIncomingMessage, which pushes the message N into m_incomingMessages and

dispatches onto the main thread. However, this is too late, since the main thread is already stuck
waiting for the incoming IPC message that we've now just enqueued.

Two minor adjustments are required to fix this, described in the below comments. The combination of these two
changes ensures that the scenario described above is impossible, since we'll either set m_waitingForMessage's
decoder and wake up the main thread in the case where waitForMessage is called before processIncomingMessage,
or we'll bail early in waitForMessage with the enqueued IPC message in the case where processIncomingMessage
runs before waitForMessage.

  • Platform/IPC/Connection.cpp:

(IPC::Connection::waitForMessage):

Move logic that checks the incoming messages queue when calling Connection::waitForMessage into the
m_waitForMessageMutex critical section.

(IPC::Connection::processIncomingMessage):

Extend the critical section of m_waitForMessageMutex when processing an incoming message, such that it
encompasses the part that enqueues the incoming message.

8:41 PM Changeset in webkit [270179] by Lauro Moura
  • 2 edits in trunk/Tools

[GTK] Unreviewed. Remove leftover test case after Internet Explorer quirks changes

The test cases were still expecting Linux platform for
drive.google.com, which now uses the IE quirk and thus the Windows
platform.

  • TestWebKitAPI/Tests/WebCore/UserAgentQuirks.cpp:

(TestWebKitAPI::TEST):

8:21 PM Changeset in webkit [270178] by Lauro Moura
  • 4 edits in trunk

[GTK][GTK4] Building with GObject-Introspection support does not work
​https://bugs.webkit.org/show_bug.cgi?id=219221

Reviewed by Carlos Garcia Campos.

.:

  • Source/cmake/OptionsGTK.cmake: Allow introspection with GTK4.

Source/WebKit:

  • PlatformGTK.cmake: Forward GTK version to gir scanner and use correct pkg-config package.
6:55 PM Changeset in webkit [270177] by Lauro Moura
  • 2 edits in trunk/Source/WebKit

[GTK4] Declare lambda return type to avoid build error deducing it
​https://bugs.webkit.org/show_bug.cgi?id=219268

Reviewed by Adrian Perez de Castro.

  • UIProcess/gtk/WebPopupMenuProxyGtk.cpp:

(WebKit::WebPopupMenuProxyGtk::createPopupMenu):

6:53 PM Changeset in webkit [270176] by Lauro Moura
  • 2 edits in trunk/Source/WebCore

[GTK4] Build fix. Add cast when taking const data ownership
​https://bugs.webkit.org/show_bug.cgi?id=219267

Reviewed by Carlos Garcia Campos.

r269614 introduced the NativeImage class, which returns a const platform image and
uses an Observer scheme to release the data.

  • platform/graphics/gtk/ImageGtk.cpp:

(WebCore::BitmapImage::gdkTexture): Keep using the direct approach and use a const_cast
to release the data.

6:18 PM Changeset in webkit [270175] by Fujii Hironori
  • 12 edits
    9 adds in trunk

[WinCairo] Enable GPU process
​https://bugs.webkit.org/show_bug.cgi?id=219294

Reviewed by Don Olmstead.

.:

  • Source/cmake/OptionsWin.cmake: Turned ENABLE_GPU_PROCESS on for WinCairo.

Source/WebCore:

  • platform/graphics/FontPlatformData.cpp:
  • platform/graphics/win/FontPlatformDataCairoWin.cpp:

(WebCore::FontPlatformData::familyName const): Added.

Source/WebKit:

Added stub functions to build GPU process.

Invoke the following command to enable GPU process:

reg add HKEY_CURRENT_USER\Software\WebKit /v gpu_process_canvas_rendering /t REG_DWORD /d 1 /f

Invoke the following command to disable GPU process:

reg delete HKEY_CURRENT_USER\Software\WebKit /v gpu_process_canvas_rendering /f

  • GPUProcess/media/win/RemoteMediaPlayerProxyWin.cpp: Added.

(WebKit::RemoteMediaPlayerProxy::prepareForPlayback):
(WebKit::RemoteMediaPlayerProxy::mediaPlayerFirstVideoFrameAvailable):
(WebKit::RemoteMediaPlayerProxy::mediaPlayerRenderingModeChanged):
(WebKit::RemoteMediaPlayerProxy::enterFullscreen):
(WebKit::RemoteMediaPlayerProxy::exitFullscreen):

  • GPUProcess/win/GPUProcessMainWin.cpp: Added.

(WebKit::initializeAuxiliaryProcess<GPUProcess>):
(WebKit::GPUProcessMain):

  • GPUProcess/win/GPUProcessWin.cpp: Added.

(WebKit::GPUProcess::initializeProcess):
(WebKit::GPUProcess::initializeProcessName):
(WebKit::GPUProcess::initializeSandbox):

  • PlatformWin.cmake:
  • Shared/WebPreferencesDefaultValues.h:
  • Shared/curl/WebCoreArgumentCodersCurl.cpp:

(IPC::ArgumentCoder<FontAttributes>::encodePlatformData): Deleted.
(IPC::ArgumentCoder<FontAttributes>::decodePlatformData): Deleted.
(IPC::ArgumentCoder<Ref<Font>>::encodePlatformData): Deleted.
(IPC::ArgumentCoder<Ref<Font>>::decodePlatformData): Deleted.

  • Shared/win/WebCoreArgumentCodersWin.cpp: Added.

(IPC::ArgumentCoder<FontAttributes>::encodePlatformData):
(IPC::ArgumentCoder<FontAttributes>::decodePlatformData):
(IPC::ArgumentCoder<Ref<Font>>::encodePlatformData):
(IPC::ArgumentCoder<Ref<Font>>::decodePlatformData):

  • Shared/win/WebPreferencesDefaultValuesWin.cpp: Added.

(WebKit::isFeatureFlagEnabled):

  • WebProcess/GPU/graphics/RemoteRenderingBackendProxy.cpp:

(WebKit::RemoteRenderingBackendProxy::submitDisplayList):
(WebKit::RemoteRenderingBackendProxy::createItemBuffer):

  • WebProcess/GPU/media/win/VideoLayerRemoteWin.cpp: Added.

(WebKit::createVideoLayerRemote):

Source/WTF:

  • wtf/PlatformHave.h: Turned HAVE_SYSTEM_FEATURE_FLAGS on for Windows.
6:14 PM Changeset in webkit [270174] by Fujii Hironori
  • 24 edits in trunk/LayoutTests

[WinCairo] Unreviewed test gardening

  • platform/wincairo/TestExpectations:
  • platform/wincairo/css1/formatting_model/height_of_lines-expected.txt:
  • platform/wincairo/css1/text_properties/vertical_align-expected.txt:
  • platform/wincairo/css2.1/20110323/replaced-intrinsic-ratio-001-expected.txt:
  • platform/wincairo/editing/input/caret-at-the-edge-of-contenteditable-expected.txt:
  • platform/wincairo/editing/input/reveal-caret-of-multiline-input-expected.txt:
  • platform/wincairo/editing/inserting/paragraph-separator-in-table-1-expected.txt:
  • platform/wincairo/fast/css/named-images-expected.txt:
  • platform/wincairo/fast/css/text-overflow-input-expected.txt:
  • platform/wincairo/fast/dom/HTMLMeterElement/meter-element-expected.txt:
  • platform/wincairo/fast/dom/HTMLMeterElement/meter-element-repaint-on-update-value-expected.txt:
  • platform/wincairo/fast/dom/HTMLMeterElement/meter-styles-changing-pseudo-expected.txt:
  • platform/wincairo/fast/dom/HTMLMeterElement/meter-styles-expected.txt:
  • platform/wincairo/fast/dom/HTMLProgressElement/indeterminate-progress-001-expected.txt:
  • platform/wincairo/fast/dom/HTMLProgressElement/native-progress-bar-expected.txt:
  • platform/wincairo/fast/dom/HTMLProgressElement/progress-bar-value-pseudo-element-expected.txt:
  • platform/wincairo/fast/dom/HTMLProgressElement/progress-element-expected.txt:
  • platform/wincairo/fast/dom/HTMLTextAreaElement/reset-textarea-expected.txt:
  • platform/wincairo/fast/text/basic/generic-family-reset-expected.txt:
  • platform/wincairo/fast/text/hyphenate-limit-before-after-expected.txt:
  • platform/wincairo/fast/text/international/bidi-LDB-2-CSS-expected.txt:
  • platform/wincairo/fast/text/international/bidi-LDB-2-HTML-expected.txt:
  • platform/wincairo/fast/text/international/bidi-LDB-2-formatting-characters-expected.txt:
6:05 PM Changeset in webkit [270173] by aakash_jain@apple.com
  • 2 edits in trunk/Tools

[build.webkit.org] Update Run32bitJSCTests step for new buildbot
​https://bugs.webkit.org/show_bug.cgi?id=219085

Reviewed by Jonathan Bedard.

  • CISupport/build-webkit-org/steps.py:

(Run32bitJSCTests):
(Run32bitJSCTests.start): Initialized log observer.
(Run32bitJSCTests.parseOutputLine): Parse each log line as they come.
(Run32bitJSCTests.countFailures): Updated to return failedTestCount.

5:21 PM Changeset in webkit [270172] by yoshiaki.jitsukawa@sony.com
  • 2 edits in trunk/Source/WebCore

AXObjectCache::focusedObjectForPage() is not defined when ENABLE(ACCESSIBILITY) is off
​https://bugs.webkit.org/show_bug.cgi?id=219290

Reviewed by Chris Fleizach.

Define AXObjectCache::focusedObjectForPage() as a function which
returns a nullptr.

  • accessibility/AXObjectCache.h:

(WebCore::AXObjectCache::focusedObjectForPage): Defined.

4:48 PM Changeset in webkit [270171] by youenn@apple.com
  • 7 edits
    2 adds in trunk

​https://collab-project.github.io/videojs-record/demo/video-only.html is not working
​https://bugs.webkit.org/show_bug.cgi?id=219258
<rdar://problem/69759808>

Reviewed by Eric Carlson.

Source/WebCore:

Make 'HTMLMediaElement.srcObject = blob' functional by making sure to register a blob URL before trying to load.
Clean-up internal slots when srcObject is set to make sure we do not load a MediaStream even if the current MediaProvider is a Blob.

Fix a Use-After-Move bug that can be triggered in case of synchronous media loading failure.

Test: http/wpt/mediarecorder/set-srcObject-MediaStream-Blob.html

  • html/HTMLMediaElement.cpp:

(WebCore::HTMLMediaElement::~HTMLMediaElement):
(WebCore::HTMLMediaElement::setSrcObject):
(WebCore::HTMLMediaElement::loadResource):

  • html/HTMLMediaElement.h:
  • platform/graphics/avfoundation/objc/WebCoreAVFResourceLoader.mm:

(WebCore::WebCoreAVFResourceLoader::startLoading):

Source/WebKit:

Fixed a potential null pointer crash in case load is aborted by WebCore at creation time.

  • WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:

(WebKit::MediaPlayerPrivateRemote::requestResource):

LayoutTests:

  • http/wpt/mediarecorder/set-srcObject-MediaStream-Blob-expected.txt: Added.
  • http/wpt/mediarecorder/set-srcObject-MediaStream-Blob.html: Added.
4:40 PM Changeset in webkit [270170] by commit-queue@webkit.org
  • 4 edits in trunk/Tools

[GTK] Allow WebKitTestServer to run non-loopback addresses for API tests
​https://bugs.webkit.org/show_bug.cgi?id=219257

GTK API tests currently assumes that loopback IP addresses can be treated as mixed content
in order to test WEBKIT_INSECURE_CONTENT_RUN and WEBKIT_INSECURE_CONTENT_DISPLAYED APIs.
After bug 218623, this will no longer be true so this patch adds an option to
WebKitTestServer so that it can run a server listening to "localhost" instead. This approach
will work until bug 171934 is fixed, but we might add a way to launch a server listening to
non-localhost addresses (bug 219198) or review the whole mixed content handling in the
future (bug 140625). This patch also tweaks a bit WebKitTestServer options, so they use a
bitset instead.

Patch by Frederic Wang <​fwang@igalia.com> on 2020-11-26
Reviewed by Michael Catanzaro.

  • TestWebKitAPI/Tests/WebKitGLib/TestSSL.cpp:

(beforeAll): Add a ServerNonLoopback bit to the HTTPS server used by the tests, so that
insecure content APIs will still work after bug 218623. Also remove explicit options for the
HTTP server since it just uses the default (no bits set).

  • TestWebKitAPI/glib/WebKitGLib/WebKitTestServer.cpp:

(WebKitTestServer::WebKitTestServer): Use the new bitset syntax. Starts a server listening to
"localhost" if the ServerNonLoopback bit is set.

  • TestWebKitAPI/glib/WebKitGLib/WebKitTestServer.h: Make the enum a list of bit positions

and the parameter a bitset of options. Add the new ServerNonLoopback option and remove
ServerHTTP, which corresponds to the default value (no bits set).

4:38 PM Changeset in webkit [270169] by yoshiaki.jitsukawa@sony.com
  • 4 edits in trunk

[PlayStation] Enable ResourceLoadStatistics
​https://bugs.webkit.org/show_bug.cgi?id=219292

Reviewed by Fujii Hironori.

.:

  • Source/cmake/OptionsPlayStation.cmake:

Source/WebKit:

  • PlatformPlayStation.cmake:
4:36 PM Changeset in webkit [270168] by commit-queue@webkit.org
  • 6 edits in trunk

[WPE][GTK] Use Internet Explorer quirk for Google Docs
​https://bugs.webkit.org/show_bug.cgi?id=219278

Patch by Michael Catanzaro <Michael Catanzaro> on 2020-11-26
Reviewed by Carlos Garcia Campos.

Source/WebCore:

Since r266584, we've suffered from an annoying unsupported browser warning when using Google
Docs. We don't have many options to avoid it. I'm afraid that Firefox or Chrome quirks are
too risky, since these seem to tempt Google into using web platform features that WebKit
does not support. The safest quirk is the macOS platform quirk, but that doesn't work well
here because it breaks various keyboard shortcuts like Ctrl+A and Ctrl+Z. So an Internet
Explorer quirk is really the last card we have left.

I think this is the safest Google quirk we've ever had, in that it's pretty unlikely that
Google will try to send Internet Explorer anything that doesn't work in WebKit. However, it
will break eventually, whenever Google decides that Internet Explorer is no longer
supported. I guess that date is probably at least five years away, so we can only hope that
Google drops this anticompetitive nonsense before then.

P.S. Let's also switch Google Drive to this new quirk. The unsupported browser warning on
Google Drive seems to be completely independent, but the IE quirk seems safer that the
existing Firefox quirk, so why not?

  • platform/UserAgentQuirks.cpp:

(WebCore::isGoogle):
(WebCore::urlRequiresInternetExplorerBrowser):
(WebCore::urlRequiresWindowsPlatform):
(WebCore::urlRequiresLinuxDesktopPlatform):
(WebCore::UserAgentQuirks::quirksForURL):
(WebCore::UserAgentQuirks::stringForQuirk):

  • platform/UserAgentQuirks.h:
  • platform/glib/UserAgentGLib.cpp:

(WebCore::buildUserAgentString):

Tools:

  • TestWebKitAPI/Tests/WebCore/UserAgentQuirks.cpp:

(TestWebKitAPI::assertUserAgentForURLHasChromeBrowserQuirk):
(TestWebKitAPI::assertUserAgentForURLHasFirefoxBrowserQuirk):
(TestWebKitAPI::assertUserAgentForURLHasInternetExplorerBrowserQuirk):
(TestWebKitAPI::assertUserAgentForURLHasWindowsPlatformQuirk):
(TestWebKitAPI::TEST):

3:59 PM Changeset in webkit [270167] by Darin Adler
  • 4 edits in trunk/Source/WebCore

Fix non-unified build problem in CSSPropertyParserHelpers.cpp along with a little refactoring
​https://bugs.webkit.org/show_bug.cgi?id=219222

Reviewed by Sam Weinig.

  • css/parser/CSSPropertyParser.cpp:

(WebCore::fontStyleIsWithinRange): Deleted.
(WebCore::consumeFontStyleRange): Updated for name change to isFontStyleAngleInRange,
don't force angles to float since the values are stored as double. Use local variables
to avoid multiple calls to doubleValue.

  • css/parser/CSSPropertyParserHelpers.cpp:

(WebCore::CSSPropertyParserHelpers::isCSSWideKeyword): Moved inline function here
from the header since it's only used inside this file.
(WebCore::CSSPropertyParserHelpers::consumeFontStyleRaw): Updated for the name change
of isFontStyleAngleInRange, and also eliminated local since it's clear without it.

  • css/parser/CSSPropertyParserHelpers.h:

(WebCore::CSSPropertyParserHelpers::isCSSWideKeyword): Deleted. This had "static" on it
in a header, which is not good style, but also didn't need to be in a header.
(WebCore::CSSPropertyParserHelpers::isFontStyleAngleInRange): Moved this here so we can
use it in two different .cpp files. Also renamed it for improved clarity, and used an
inline function because this is super simple.

3:56 PM Changeset in webkit [270166] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WTF

[WPE][GTK] Fix build with GCC 11
​https://bugs.webkit.org/show_bug.cgi?id=219264

Patch by Michael Catanzaro <Michael Catanzaro> on 2020-11-26
Reviewed by Carlos Garcia Campos.

It's not uncommon for really old code like this to abuse volatile as if it were a
synchronization primitive. It's not. This code is already synchronized by use of GOnce, so
it can be safely removed. References:

​https://gitlab.gnome.org/GNOME/glib/-/issues/600#note_877282
​http://isvolatileusefulwiththreads.in/C++/

  • wtf/glib/WTFGType.h:

Nov 22, 2020:

7:26 PM Changeset in webkit [270165] by Diego Pino Garcia
  • 5 edits
    1 add in trunk/LayoutTests

[GLIB][GTK] Unreviewed test gardening. Updated expectations and baselines after 270164.

  • platform/glib/TestExpectations:
  • platform/gtk/TestExpectations:
  • platform/gtk/editing/selection/simple-line-layout-caret-is-gone-expected.txt: Added.
  • platform/gtk/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt: Updated after r270103.
  • platform/gtk/imported/w3c/web-platform-tests/html/dom/idlharness.worker-expected.txt: Updated after r270103.
6:52 AM Changeset in webkit [270164] by Antti Koivisto
  • 5 edits in trunk/Source/WebCore

[LFC][Integration] Convert some remaining InlineBox access to use inline iterator
​https://bugs.webkit.org/show_bug.cgi?id=219244

Reviewed by Zalan Bujtas.

  • dom/Position.cpp:

(WebCore::hasInlineRun):
(WebCore::nextRenderedEditable):
(WebCore::previousRenderedEditable):
(WebCore::hasInlineBoxWrapper): Deleted.

  • rendering/RenderElement.cpp:

(WebCore::RenderElement::getLeadingCorner const):

  • rendering/RenderText.cpp:

(WebCore::RenderText::topOfFirstText const): Deleted.

  • rendering/RenderText.h:
5:52 AM Changeset in webkit [270163] by Alan Bujtas
  • 4 edits in trunk/Source/WebCore

[LFC][IFC] Only process floats that fit the current line.
​https://bugs.webkit.org/show_bug.cgi?id=219239

Reviewed by Antti Koivisto.

Now that we process floats as soft wrap opportunities, all the intrusive logic can be removed.
Any float that we put on the line is considered intrusive and shrinks the available space.

  • layout/inlineformatting/InlineFormattingContext.cpp:

(WebCore::Layout::InlineFormattingContext::computeGeometryForLineContent):

  • layout/inlineformatting/InlineLineBuilder.cpp:

(WebCore::Layout::LineCandidate::InlineContent::operator() const):
(WebCore::Layout::LineCandidate::reset):
(WebCore::Layout::LineBuilder::placeInlineContent):
(WebCore::Layout::LineBuilder::constraintsForLine):
(WebCore::Layout::LineBuilder::candidateContentForLine):
(WebCore::Layout::LineBuilder::handleFloatOrInlineContent):
(WebCore::Layout::LineBuilder::rebuildLine):
(WebCore::Layout::LineCandidate::InlineContent::continuousContent const): Deleted.
(WebCore::Layout::LineCandidate::FloatContent::list const): Deleted.
(WebCore::Layout::LineCandidate::FloatContent::intrusiveWidth const): Deleted.
(WebCore::Layout::LineCandidate::FloatContent::append): Deleted.
(WebCore::Layout::LineCandidate::FloatContent::reset): Deleted.
(WebCore::Layout::LineBuilder::nextContentForLine): Deleted.
(WebCore::Layout::LineBuilder::commitFloats): Deleted.
(WebCore::Layout::LineBuilder::handleFloatsAndInlineContent): Deleted.

  • layout/inlineformatting/InlineLineBuilder.h:
5:11 AM Changeset in webkit [270162] by Philippe Normand
  • 4 edits in trunk/LayoutTests

Unreviewed GLib gardening

Skip WebSpeech-related tests on GTK and WPE because these ports
don't support WebSpeech yet.

  • platform/glib/TestExpectations:
  • platform/gtk/TestExpectations:
  • platform/wpe/TestExpectations:
4:02 AM Changeset in webkit [270161] by Lauro Moura
  • 2 edits in trunk/LayoutTests

[GStreamer] Gardening webspeech related crash

Unreviewed test gardening.

  • platform/glib/TestExpectations:
12:30 AM Changeset in webkit [270160] by commit-queue@webkit.org
  • 3 edits
    2 adds in trunk

Fix getIndexedParameter indexing crash
​https://bugs.webkit.org/show_bug.cgi?id=218601

Patch by Rob Buis <​rbuis@igalia.com> on 2020-11-22
Reviewed by Ryosuke Niwa.

Source/WebCore:

Like in setBoundIndexedTransformFeedbackBuffer ASSERT, the index should
always be smaller than size for indexing to be safe, so bail if the index
is greater than or equal to size.

  • html/canvas/WebGLTransformFeedback.cpp:

(WebCore::WebGLTransformFeedback::getBoundIndexedTransformFeedbackBuffer):

LayoutTests:

Add testcase.

  • fast/canvas/webgl/getIndexedParameter-crash-expected.txt: Added.
  • fast/canvas/webgl/getIndexedParameter-crash.html: Added.
Note: See TracTimeline for information about the timeline view.