Context Navigation

← Previous Period
Next Period →

Timeline

Sep 2, 2019:

10:59 PM Changeset in webkit [249417] by ysuzuki@apple.com

2 edits in trunk/Source/WebCore

[WebCore] Resource usage accounting should accept non KERN_SUCCESS
https://bugs.webkit.org/show_bug.cgi?id=201409

Reviewed by Andreas Kling.

While iterating threads, we are not suspending these threads. Underlying threads can have gone
at any time and we will get non KERN_SUCCESS error code when a thread has gone. We should ignore
these threads.

page/cocoa/ResourceUsageThreadCocoa.mm:

(WebCore::threadInfos):

6:55 PM Changeset in webkit [249416] by Fujii Hironori

5 edits
31 adds
2 deletes in trunk

[SVG] fragment-only url 'url(#fragment)' should be resolved against the current document with regardless to HTML <base> element
https://bugs.webkit.org/show_bug.cgi?id=189499
<rdar://problem/44466206>

Reviewed by Said Abou-Hallawa.

Source/WebCore:

Fragment-only URL 'url(#fragment)' should be resolved against the
current document even if HTML <base> element is specified.
Spec: <https://drafts.csswg.org/css-values/#local-urls>

Tests: css3/filters/effect-reference-local-url-with-base.html

css3/masking/clip-path-reference-local-url-with-base.html
http/tests/svg/local-url-with-valid-base-and-resource.html
svg/animations/local-url-target-reference.html
svg/custom/local-url-reference-clip-path.html
svg/custom/local-url-reference-fill.html
svg/custom/local-url-reference-filter.html
svg/custom/local-url-reference-marker.html
svg/custom/local-url-reference-mask.html
svg/custom/local-url-reference-pattern.html
svg/custom/local-url-reference-radial-gradient.html
svg/custom/local-url-reference-srcdoc.html
svg/custom/local-url-reference-stroke.html
svg/custom/local-url-reference-use.html
svg/text/textpath-local-url-reference.html

svg/SVGURIReference.cpp:

(WebCore::SVGURIReference::fragmentIdentifierFromIRIString): Return the fragment if the URL starts with '#'.

LayoutTests:

These test cases are imported from Blink's commit, and modified for WebKit.
<https://chromium.googlesource.com/chromium/src/+/e7d7225c33aa7fc42ee390125b01df9167fad106%5E%21/>

TestExpectations:
css3/filters/effect-reference-local-url-with-base-expected.html: Added.
css3/filters/effect-reference-local-url-with-base.html: Added.
css3/filters/effect-reference.html:
css3/masking/clip-path-reference-local-url-with-base-expected.html: Added.
css3/masking/clip-path-reference-local-url-with-base.html: Added.
http/tests/svg/local-url-with-valid-base-and-resource-expected.html: Added.
http/tests/svg/local-url-with-valid-base-and-resource.html: Added.
http/tests/svg/resources/red100x100.svg: Added.
platform/gtk/TestExpectations: Marked svg/custom/local-url-reference-marker.html as ImageOnlyFailure for Bug 113849.
platform/wpe/TestExpectations: Ditto.
svg/animations/local-url-target-reference-expected.html: Added.
svg/animations/local-url-target-reference.html: Added.
svg/custom/linking-base-external-reference-expected.txt: Removed. This was a test for old spec.
svg/custom/linking-base-external-reference.xhtml: Ditto.
svg/custom/local-url-reference-clip-path-expected.html: Added.
svg/custom/local-url-reference-clip-path.html: Added.
svg/custom/local-url-reference-fill-expected.html: Added.
svg/custom/local-url-reference-fill.html: Added.
svg/custom/local-url-reference-filter-expected.html: Added.
svg/custom/local-url-reference-filter.html: Added.
svg/custom/local-url-reference-marker-expected.html: Added.
svg/custom/local-url-reference-marker.html: Added.
svg/custom/local-url-reference-mask-expected.html: Added.
svg/custom/local-url-reference-mask.html: Added.
svg/custom/local-url-reference-pattern-expected.html: Added.
svg/custom/local-url-reference-pattern.html: Added.
svg/custom/local-url-reference-radial-gradient-expected.html: Added.
svg/custom/local-url-reference-radial-gradient.html: Added.
svg/custom/local-url-reference-srcdoc-expected.html: Added.
svg/custom/local-url-reference-srcdoc.html: Added.
svg/custom/local-url-reference-stroke-expected.html: Added.
svg/custom/local-url-reference-stroke.html: Added.
svg/custom/local-url-reference-use-expected.html: Added.
svg/custom/local-url-reference-use.html: Added.
svg/text/textpath-local-url-reference-expected.html: Added.
svg/text/textpath-local-url-reference.html: Added.

6:53 PM Changeset in webkit [249415] by Fujii Hironori

3 edits in trunk/Source/WebCore

[Win] Remove a unused PlatformWheelEvent constructor
https://bugs.webkit.org/show_bug.cgi?id=201398

Reviewed by Don Olmstead.

No behavior change.

platform/PlatformWheelEvent.h:
platform/win/WheelEventWin.cpp:

Removed a unused PlatformWheelEvent constructor.

2:37 PM Changeset in webkit [249414] by Brent Fulgham

5 edits in trunk/Source/WebCore

[FTW] NativeImagePtr is drawn with invalid scaling
https://bugs.webkit.org/show_bug.cgi?id=201391

Reviewed by Don Olmstead.

The current implementation of FTW improperly applies scaling factors to native images,
resulting in blocky images (in some cases).

This patch corrects the handling of native images, corrects a bug in bitmap render
context scaling, and retrieves more data from the ImageDecoder's metadata system.

platform/graphics/win/Direct2DUtilities.cpp:

(WebCore::Direct2D::createBitmapRenderTargetOfSize): Supply an appropriately sized
pixel dimension for non-unity scale factors.

platform/graphics/win/ImageBufferDirect2D.cpp:

(WebCore::ImageBuffer::ImageBuffer): Include the scale factor when creating a
bitmap render target.

platform/graphics/win/ImageDecoderDirect2D.cpp:

(WebCore::ImageDecoderDirect2D::frameOrientationAtIndex const): Read the orientation
data form the image metadata.
(WebCore::ImageDecoderDirect2D::frameAllowSubsamplingAtIndex const): Always return
true, to match the CG implementation.
(WebCore::ImageDecoderDirect2D::frameHasAlphaAtIndex const): Correct to match the
behavior of CG.

platform/graphics/win/NativeImageDirect2D.cpp:

(WebCore::drawNativeImage): Pass through the Direct2DOperations helper method, which
handles scaling and subsampling properly.

3:54 AM Changeset in webkit [249413] by Carlos Garcia Campos

2 edits in releases/WebKitGTK/webkit-2.26/Source/WebKit

Merge r249375 - [Cairo] out-of-bounds read in ShareableBitmap::paint if a fractional device scale factor is used
https://bugs.webkit.org/show_bug.cgi?id=196340

Reviewed by Brent Fulgham.

In ShareableBitmap::paint, srcRectScaled can be out-of-bounds of
the surface if a fractional device scale factor is used.

Shared/cairo/ShareableBitmapCairo.cpp:

(WebKit::ShareableBitmap::paint): Use cairoSurfaceSetDeviceScale
to set a device scale factor to the surface instead of multiplying
srcRect with a device scale factor.

3:54 AM Changeset in webkit [249412] by Carlos Garcia Campos

16 edits in releases/WebKitGTK/webkit-2.26/Source/JavaScriptCore

Merge r249372 - [JSC] Merge op_check_traps into op_enter and op_loop_hint
https://bugs.webkit.org/show_bug.cgi?id=201373

Reviewed by Mark Lam.

This patch removes op_check_traps. Previously we were conditionally emitting op_check_traps based on Options and Platform configurations.
But now we are always emitting op_check_traps. So it is not necessary to have separate bytecode as op_check_traps. We can do checking in
op_enter and op_loop_hint.

While this patch moves check_traps implementation to op_enter and op_loop_hint, we keep separate DFG nodes (CheckTraps or InvalidationPoint),
since inserted nodes are different based on configurations and options. And emitting multiple DFG nodes from one bytecode is easy.

We also inline op_enter's slow path's write-barrier emission in LLInt.

bytecode/BytecodeList.rb:
bytecode/BytecodeUseDef.h:

(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):

bytecompiler/BytecodeGenerator.cpp:

(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitLoopHint):
(JSC::BytecodeGenerator::emitCheckTraps): Deleted.

bytecompiler/BytecodeGenerator.h:
dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
(JSC::DFG::ByteCodeParser::parseBlock):

dfg/DFGCapabilities.cpp:

(JSC::DFG::capabilityLevel):

jit/JIT.cpp:

(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::emitEnterOptimizationCheck): Deleted.

jit/JIT.h:
jit/JITOpcodes.cpp:

(JSC::JIT::emit_op_loop_hint):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_enter):
(JSC::JIT::emitSlow_op_enter):
(JSC::JIT::emit_op_check_traps): Deleted.
(JSC::JIT::emitSlow_op_check_traps): Deleted.

jit/JITOpcodes32_64.cpp:

(JSC::JIT::emit_op_enter): Deleted.

llint/LowLevelInterpreter.asm:
llint/LowLevelInterpreter32_64.asm:
llint/LowLevelInterpreter64.asm:
runtime/CommonSlowPaths.cpp:
runtime/CommonSlowPaths.h:

3:54 AM Changeset in webkit [249411] by Carlos Garcia Campos

2 edits in releases/WebKitGTK/webkit-2.26/Source/JavaScriptCore

Merge r249370 - [JSC] Fix testb3 debug failures
https://bugs.webkit.org/show_bug.cgi?id=201382

Reviewed by Mark Lam.

Fix testb3 debug failures due to incorrect types of operations like pointer + int32.

b3/testb3_8.cpp:

(testByteCopyLoop):
(testByteCopyLoopStartIsLoopDependent):
(testByteCopyLoopBoundIsLoopDependent):

3:54 AM Changeset in webkit [249410] by Carlos Garcia Campos

6 edits
3 adds in releases/WebKitGTK/webkit-2.26

Merge r249367 - HTMLImageElement::decode() should return a resolved promise for decoding non bitmap images
https://bugs.webkit.org/show_bug.cgi?id=201243

Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-09-01
Reviewed by Youenn Fablet.

LayoutTests/imported/w3c:

web-platform-tests/html/semantics/embedded-content/the-img-element/decode/image-decode-picture-expected.txt:

Source/WebCore:

The specs: https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode
states that, decode() should resolve the pending promise if the decoding
was requested for a non bitmap image.

Test: fast/images/decode-non-bitmap-image-resolve.html

loader/ImageLoader.cpp:

(WebCore::resolveDecodePromises):
(WebCore::rejectDecodePromises):
(WebCore::ImageLoader::notifyFinished):
(WebCore::ImageLoader::decode):
(WebCore::ImageLoader::decodeError): Deleted.

loader/ImageLoader.h:

(WebCore::ImageLoader::hasPendingDecodePromises const):

LayoutTests:

fast/images/decode-non-bitmap-image-resolve-expected.txt: Added.
fast/images/decode-non-bitmap-image-resolve.html: Added.
fast/images/resources/green-100x100.svg: Added.

3:54 AM Changeset in webkit [249409] by Carlos Garcia Campos

2 edits in releases/WebKitGTK/webkit-2.26/Source/JavaScriptCore

Merge r249365 - Speculative build fix for ARMv7 and MIPS.
https://bugs.webkit.org/show_bug.cgi?id=201389

Not reviewed.

bytecode/CodeBlock.cpp:

(JSC::CodeBlock::jettison):

3:54 AM Changeset in webkit [249408] by Carlos Garcia Campos

2 edits in releases/WebKitGTK/webkit-2.26/Source/JavaScriptCore

Merge r249362 - [JSC] LLInt op should not emit the same code three times
https://bugs.webkit.org/show_bug.cgi?id=201370

Reviewed by Mark Lam.

LLInt op macro (not llintOp macro) is used to generate some stub code like llint_program_prologue.
But now it generates the same code three times for narrow, wide16, and wide32. We should emit code only once.

llint/LowLevelInterpreter.asm:

3:54 AM Changeset in webkit [249407] by Carlos Garcia Campos

7 edits in releases/WebKitGTK/webkit-2.26

Merge r249361 - XMLHttpRequest: responseXML returns null if the Content-Type is valid (end in +xml) in some cases
https://bugs.webkit.org/show_bug.cgi?id=46146

Patch by Rob Buis <rbuis@igalia.com> on 2019-08-31
Reviewed by Youenn Fablet.

LayoutTests/imported/w3c:

Updated expected result.

web-platform-tests/xhr/responsexml-media-type-expected.txt:

Source/WebCore:

Make response MIME type fallback to text/xml in case mimeType could
not be extracted [1] and use the stricter ParsedContentType for that.

Behavior matches Firefox.

Test: web-platform-tests/xhr/responsexml-media-type.htm

[1] https://xhr.spec.whatwg.org/#response-mime-type

xml/XMLHttpRequest.cpp:

(WebCore::XMLHttpRequest::responseMIMEType const):

LayoutTests:

Adjust test to match the specification: make response MIME type fallback to
text/xml in case mimeType could not be extracted.

Behavior matches Firefox.

http/tests/xmlhttprequest/supported-xml-content-types-expected.txt:
http/tests/xmlhttprequest/supported-xml-content-types.html:

3:54 AM Changeset in webkit [249406] by Carlos Garcia Campos

10 edits
10 adds in releases/WebKitGTK/webkit-2.26

Merge r249360 - Fix interpretation of fraction shifts
https://bugs.webkit.org/show_bug.cgi?id=201242

Patch by Frederic Wang <fwang@igalia.com> on 2019-08-31
Reviewed by Rob Buis.

LayoutTests/imported/w3c:

Update tests and support files for fractions/stacks parameters.

web-platform-tests/mathml/presentation-markup/fractions/frac-parameters-2-expected.txt:

Update expectation now that AxisHeight is no longer involved in stacks.

web-platform-tests/fonts/math/fraction-denominatordisplaystyleshiftdown6000-axisheight1000-rulethickness1000.woff: Added.
web-platform-tests/fonts/math/fraction-denominatorshiftdown3000-axisheight1000-rulethickness1000.woff: Added.
web-platform-tests/fonts/math/fraction-numeratordisplaystyleshiftup2000-axisheight1000-rulethickness1000.woff: Added.
web-platform-tests/fonts/math/fraction-numeratorshiftup11000-axisheight1000-rulethickness1000.woff: Added.
web-platform-tests/fonts/math/stack-bottomdisplaystyleshiftdown5000-axisheight1000.woff: Added.
web-platform-tests/fonts/math/stack-bottomshiftdown6000-axisheight1000.woff: Added.
web-platform-tests/fonts/math/stack-topdisplaystyleshiftup3000-axisheight1000.woff: Added.
web-platform-tests/fonts/math/stack-topshiftup9000-axisheight1000.woff: Added.
web-platform-tests/mathml/presentation-markup/fractions/frac-parameters-1.html:
web-platform-tests/mathml/presentation-markup/fractions/frac-parameters-2.html:
web-platform-tests/mathml/support/feature-detection.js: Added.

(MathMLFeatureDetection.has_mspace):
(MathMLFeatureDetection.has_operator_spacing):
(MathMLFeatureDetection.has_mfrac):
(MathMLFeatureDetection.has_msqrt):
(MathMLFeatureDetection.has_menclose):
(MathMLFeatureDetection.has_dir):
(MathMLFeatureDetection.ensure_for_match_reftest):

Source/WebCore:

In fractions, numerator/denominator shifts are currently interpreted relative to the math
axis while they should be relative to the baseline [1]. This patch refactors the
RenderMathMLFraction to do that and aligns more on MathML Core [2] [3]. This fixes serious
rendering bugs in fractions.

[1] https://github.com/mathml-refresh/mathml/issues/123
[2] https://mathml-refresh.github.io/mathml-core/#fraction-with-nonzero-line-thickness
[3] https://mathml-refresh.github.io/mathml-core/#fraction-with-zero-line-thickness

No new tests, existing tests updated.

rendering/mathml/RenderMathMLFraction.h: ascentOverHorizontalAxis() is replaced with

fractionAscent() which gives the actual baseline position rather than the math axis position.
fractionParameters() and stackParameters() are modified so that they only return the shifts,
now stored in a shared FractionParameters struct.

rendering/mathml/RenderMathMLFraction.cpp:

(WebCore::RenderMathMLFraction::fractionParameters const): Store existing parameters in local
variables and perform adjustments to the shift values so that the minimal gap constraints
are satisfied. Return them as a FractionParameters.
(WebCore::RenderMathMLFraction::stackParameters const): Ditto.
(WebCore::RenderMathMLFraction::fractionAscent const): This calculates the ascent above
the baseline as described in [2] [3] and replaces ascentOverHorizontalAxis. To minimize
changeset, this continues to ignore contribution of denominator size and not to distinguish
ink or non-ink metrics.
(WebCore::RenderMathMLFraction::layoutBlock): The position of the denominator is now just
calculated as a shift from the baseline. The height is given by the bottom of the
denominator. The old "ascent + mathAxisHeight() + denominatorDescent" does not make any
sense.
(WebCore::RenderMathMLFraction::paint): Use fractionAscent() instead of
ascentOverHorizontalAxis().
(WebCore::RenderMathMLFraction::firstLineBaseline const): Ditto.

LayoutTests:

TestExpectations: Skip mathml/presentation/stretchy-depth-height-symmetric.html since it

cannot work in a reliable way and should be rewritten. Equivalent checks seem essentially
covered by WPT test mathml/presentation-markup/operators/mo-axis-height-1.html.
See bug 201356.

platform/win/mathml/presentation/roots-expected.txt: Update windows expectation.

3:54 AM Changeset in webkit [249405] by Carlos Garcia Campos

2 edits in releases/WebKitGTK/webkit-2.26/Source/WebCore

Merge r249352 - Minor optimization in determineNonLayerDescendantsPaintedContent()
https://bugs.webkit.org/show_bug.cgi?id=201352

Reviewed by Antti Koivisto.

It's cheaper to call renderText.hasRenderedText() than renderText.linesBoundingBox(), because
the latter has to traverse all the InlineTextBoxes. This code path is fairly hot when
scrolling twitter feeds, since it's called from RenderLayer::updateLayerPositionsAfterScroll()
which calls RenderLayer::isVisuallyNonEmpty().

rendering/RenderLayer.cpp:

(WebCore::RenderLayer::calculateClipRects const):

3:53 AM Changeset in webkit [249404] by Carlos Garcia Campos

2 edits in releases/WebKitGTK/webkit-2.26/Source/JavaScriptCore

Merge r249345 - Fix a bug in SlotVisitor::reportZappedCellAndCrash() and also capture more information.
https://bugs.webkit.org/show_bug.cgi?id=201345

Reviewed by Yusuke Suzuki.

This patch fixes a bug where SlotVisitor::reportZappedCellAndCrash() was using
the wrong pointer for capture the cell headerWord and zapReason. As a result,
we get junk for those 2 values.

Previously, we were only capturing the upper 32-bits of the cell header slot,
and the lower 32-bit of the next slot in the zapped cell. We now capture the
full 64-bits of both slots. If the second slot did not contain a zapReason as we
expect, the upper 32-bits might give us a clue as to what type of value the slot
contains.

This patch also adds capturing of the found MarkedBlock address for the zapped
cell, as well as some state bit values.

heap/SlotVisitor.cpp:

(JSC::SlotVisitor::reportZappedCellAndCrash):

3:53 AM Changeset in webkit [249403] by Carlos Garcia Campos

3 edits in releases/WebKitGTK/webkit-2.26/Source/WebKit

Merge r249341 - Allow process cache to cache processes when using a non-default persistent WebsiteDataStore
https://bugs.webkit.org/show_bug.cgi?id=201329

Reviewed by Chris Dumez.

Treat all persistent sessions the same when deciding whether to clear all cached web processes using a particular website data store.
This removes a huge performance regression on warm plt when switching to using a non-default persistent session.
I also removed a call to removeSession which is redundant with the one in the WebsiteDataStore destructor, which is where it should be.

UIProcess/WebProcessCache.cpp:

(WebKit::WebProcessCache::canCacheProcess const):

UIProcess/WebProcessPool.cpp:

(WebKit::WebProcessPool::pageBeginUsingWebsiteDataStore):
(WebKit::WebProcessPool::pageEndUsingWebsiteDataStore):

3:53 AM Changeset in webkit [249402] by Carlos Garcia Campos

5 edits
1 add in releases/WebKitGTK/webkit-2.26

Merge r249337 - [JSC] Generate new.target register only when it is used
https://bugs.webkit.org/show_bug.cgi?id=201335

Reviewed by Mark Lam.

JSTests:

stress/ensure-new-register-allocated.js: Added.

(shouldBe):
(basic):
(arrow):
(Base):
(Derived):
(evaluate):

Source/JavaScriptCore:

Since bytecode generator knows whether new.target register can be used, we should emit and use new.target register
only when it is actually required.

bytecompiler/BytecodeGenerator.cpp:

(JSC::BytecodeGenerator::BytecodeGenerator):

bytecompiler/BytecodeGenerator.h:

(JSC::BytecodeGenerator::newTarget):

parser/Nodes.h:

(JSC::ScopeNode::needsNewTargetRegisterForThisScope const):

3:53 AM Changeset in webkit [249401] by Carlos Garcia Campos

10 edits in releases/WebKitGTK/webkit-2.26/Source/WebCore

Merge r249333 - IndexedDB: update size of database when database operation is completed
https://bugs.webkit.org/show_bug.cgi?id=201057

Reviewed by Youenn Fablet.

Currently when a database operation was completed, we re-computed the disk usage of the origin. This computation
listed all databases in the origin directory and read the size of each database file, which was very inefficient
because the completed operation should only affect one database.

This patch makes UniqueIDBDatabase keep track of database size and reports size change to QuotaUser.

Tested PerformanceTests/IndexedDB/basic/objectstore-add.html on release build minibrowser. This change makes
the test over 50% faster.

Modules/indexeddb/server/IDBBackingStore.h:
Modules/indexeddb/server/IDBServer.cpp:

(WebCore::IDBServer::IDBServer::QuotaUser::increaseSpaceUsed):
(WebCore::IDBServer::IDBServer::QuotaUser::decreaseSpaceUsed):
(WebCore::IDBServer::IDBServer::computeSpaceUsedForOrigin):
(WebCore::IDBServer::IDBServer::increaseSpaceUsed):
(WebCore::IDBServer::IDBServer::decreaseSpaceUsed):
(WebCore::IDBServer::IDBServer::setSpaceUsed): Deleted.

Modules/indexeddb/server/IDBServer.h:
Modules/indexeddb/server/MemoryIDBBackingStore.cpp:

(WebCore::IDBServer::MemoryIDBBackingStore::databaseSize const):
(WebCore::IDBServer::MemoryIDBBackingStore::close):
(WebCore::IDBServer::MemoryIDBBackingStore::databasesSizeForOrigin const): Deleted.

Modules/indexeddb/server/MemoryIDBBackingStore.h:
Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:

(WebCore::IDBServer::SQLiteIDBBackingStore::databasesSizeForDirectory):
(WebCore::IDBServer::SQLiteIDBBackingStore::databaseSize const):
(WebCore::IDBServer::SQLiteIDBBackingStore::close):
(WebCore::IDBServer::SQLiteIDBBackingStore::databasesSizeForFolder): Deleted.
(WebCore::IDBServer::SQLiteIDBBackingStore::databasesSizeForOrigin const): Deleted.

Modules/indexeddb/server/SQLiteIDBBackingStore.h:
Modules/indexeddb/server/UniqueIDBDatabase.cpp:

(WebCore::IDBServer::UniqueIDBDatabase::deleteBackingStore):
(WebCore::IDBServer::UniqueIDBDatabase::shutdownForClose):
(WebCore::IDBServer::UniqueIDBDatabase::didShutdownForClose):
(WebCore::IDBServer::UniqueIDBDatabase::didDeleteBackingStore):
(WebCore::IDBServer::UniqueIDBDatabase::openBackingStore):
(WebCore::IDBServer::UniqueIDBDatabase::didOpenBackingStore):
(WebCore::IDBServer::UniqueIDBDatabase::postDatabaseTaskReply):
(WebCore::IDBServer::UniqueIDBDatabase::updateSpaceUsedIfNeeded):

Modules/indexeddb/server/UniqueIDBDatabase.h:

3:53 AM Changeset in webkit [249400] by Carlos Garcia Campos

3 edits
2 adds in releases/WebKitGTK/webkit-2.26

Merge r249332 - [MSE][GStreamer] Replaying the video should update currentTime
https://bugs.webkit.org/show_bug.cgi?id=201307

Reviewed by Xabier Rodriguez-Calvar.

LayoutTests/imported/w3c:

web-platform-tests/media-source/mediasource-replay-expected.txt: Added.
web-platform-tests/media-source/mediasource-replay.html: Added.

Source/WebCore:

While writing a test to confirm that https://bugs.webkit.org/show_bug.cgi?id=190050
has indeed been fixed I noticed a non-conformity: when the video has
ended, right after calling .play() for a second playback currentTime
did not return zero, but the video duration.

This turned to be due to the m_isEndReached flag not being reseted on
seeks (replaying a video incurs in a seek done from multi-platform
code).

Test: imported/w3c/web-platform-tests/media-source/mediasource-replay.html

platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:

(WebCore::MediaPlayerPrivateGStreamerMSE::seek):

3:53 AM Changeset in webkit [249399] by Carlos Garcia Campos

6 edits in releases/WebKitGTK/webkit-2.26

Merge r249325 - [MSE][GStreamer] Gracefully fail on invalid non-first initialization segment
https://bugs.webkit.org/show_bug.cgi?id=201322

Reviewed by Xabier Rodriguez-Calvar.

Source/WebCore:

In normal operation of AppendPipeline, except during tear down,
qtdemux never removes a pad. Even if a new initialization segment is
appended, the pad is reused.

There is an exception though: when the new initialization segment has
an incompatible set of tracks. This is invalid under the MSE spec and
should produce an error, but in this case this was making an assertion
fail -- in particular by sending an EOS to the to-be-removed pad, which
AppendPipeline doesn't expect.

This patch changes the assertion with graceful error handling for that
error.

Fixes media/media-source/media-source-seek-detach-crash.html

platform/graphics/gstreamer/mse/AppendPipeline.cpp:

(WebCore::AppendPipeline::AppendPipeline):
(WebCore::AppendPipeline::handleErrorConditionFromStreamingThread):
(WebCore::AppendPipeline::handleErrorSyncMessage):

platform/graphics/gstreamer/mse/AppendPipeline.h:

LayoutTests:

platform/gtk/TestExpectations:
platform/wpe/TestExpectations:

3:53 AM Changeset in webkit [249398] by Carlos Garcia Campos

8 edits in releases/WebKitGTK/webkit-2.26

Merge r249324 - [WPE][GTK] New API to remove a filter from an user content manager given its identifier
https://bugs.webkit.org/show_bug.cgi?id=200479

Reviewed by Carlos Garcia Campos.

Source/WebKit:

UIProcess/API/glib/WebKitUserContentManager.cpp:

(webkit_user_content_manager_remove_filter_by_id): Add new public API function.

UIProcess/API/gtk/WebKitUserContentManager.h: Add declaration for

webkit_user_content_manager_remove_filter_by_id().

UIProcess/API/gtk/docs/webkit2gtk-4.0-sections.txt: List new function.
UIProcess/API/wpe/WebKitUserContentManager.h: Add declaration for

webkit_user_content_manager_remove_filter_by_id().

UIProcess/API/wpe/docs/wpe-1.0-sections.txt: List new function.

Tools:

TestWebKitAPI/Tests/WebKitGLib/TestWebKitUserContentManager.cpp:

(testUserContentManagerContentFilter): Test also the new
webkit_user_content_manager_remove_filter_by_id() public API function.

3:53 AM Changeset in webkit [249397] by Carlos Garcia Campos

4 edits in releases/WebKitGTK/webkit-2.26/Source/WebCore

Merge r249321 - [GStreamer] Do not ref the player count from background threads.
https://bugs.webkit.org/show_bug.cgi?id=201222

Reviewed by Xabier Rodriguez-Calvar.

Test: imported/w3c/web-platform-tests/encrypted-media/clearkey-mp4-playback-retrieve-persistent-license.https.html

In the sync-message handler, a ref() was being taken waiting for a
CDM instance to be attached. This hits asserts since you are not
allowed to ref() an object created on the main thread
(BasePlayer) on a background thread.

The protection condition was overly scoped, tidied up the locking
and made it more granular. To avoid needing to hold a ref() in the
background thread, use instead a semaphore to signal when a CDM
instance is attached, or the player has been destroyed.

Also remove an erroneous safe-guard, the operator= in
isCDMInstanceAvailable will ref() the CDMInstance for us. This use
of holding a reference to CDMInstance in the decryptors is not
thread-safe, and now we have a problem since there's no clean way
to communicate with CDMInstance from background threads without
being thread unsafe. For ClearKey and Widevine, a thread safe
ProxyCDM needs to be designed and passed to background
threads (upcoming patch).

platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:

(WebCore::MediaPlayerPrivateGStreamerBase::~MediaPlayerPrivateGStreamerBase):
(WebCore::MediaPlayerPrivateGStreamerBase::handleSyncMessage):
(WebCore::MediaPlayerPrivateGStreamerBase::cdmInstanceAttached):
(WebCore::MediaPlayerPrivateGStreamerBase::cdmInstanceDetached):
(WebCore::MediaPlayerPrivateGStreamerBase::handleProtectionEvent):

platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.h:
platform/graphics/gstreamer/eme/WebKitCommonEncryptionDecryptorGStreamer.cpp:

(isCDMInstanceAvailable):

3:53 AM Changeset in webkit [249396] by Carlos Garcia Campos

5 edits
1 add in releases/WebKitGTK/webkit-2.26

Merge r249319 - [JSC] DFG ByteCodeParser should not copy JIT-related part of SimpleJumpTable
https://bugs.webkit.org/show_bug.cgi?id=201331

Reviewed by Mark Lam.

JSTests:

stress/simple-jump-table-copy.js: Added.

(let.code):
(g2):

Source/JavaScriptCore:

SimpleJumpTable's non-JIT part is not changed after CodeBlock is finalized well. On the other hand, JIT related part is allocated on-demand.
For example, ctiOffsets can be grown by Baseline JIT compiler. There is race condition as follows.

DFG ByteCodeParser is inlining and copying SimpleJumpTable
Baseline JIT compiler is expanding JIT-related part of SimpleJumpTable

Then, (1) reads the broken Vector, and crashes. Since JIT-related part is unnecessary in (1), we should not clone that.
This patch adds CodeBlock::addSwitchJumpTableFromProfiledCodeBlock, which only copies non JIT-related part of the given SimpleJumpTable offered
by profiled CodeBlock.

bytecode/CodeBlock.h:

(JSC::CodeBlock::addSwitchJumpTableFromProfiledCodeBlock):

bytecode/JumpTable.h:

(JSC::SimpleJumpTable::cloneNonJITPart const):
(JSC::SimpleJumpTable::clear):

dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):

3:53 AM Changeset in webkit [249395] by Carlos Garcia Campos

5 edits in releases/WebKitGTK/webkit-2.26

Merge r249318 - [WPE][Qt] loadingChanged signal parameter is unusable
https://bugs.webkit.org/show_bug.cgi?id=201301

Reviewed by Carlos Garcia Campos.

Source/WebKit:

UIProcess/API/wpe/qt/WPEQtView.h: Explicitely name signal

parameter. It is a runtime requirement for QML.

Tools:

MiniBrowser/wpe/qt/main.qml: Add a basic loadingChange signal handler.
Scripts/webkitpy/style/checker.py: White-list WPEQtView.h for

readablity/parameter_name code styl checker rule.

3:53 AM Changeset in webkit [249394] by Carlos Garcia Campos

3 edits
1 add in releases/WebKitGTK/webkit-2.26

Merge r249317 - [JSC] DFG inlining CheckBadCell slow path does not assume result VirtualRegister can be invalid
https://bugs.webkit.org/show_bug.cgi?id=201332

Reviewed by Mark Lam.

JSTests:

This test is very flaky, it is hard to reproduce.

stress/setter-inlining-resulting-bad-cell-result-virtual-register-should-be-invalid.js: Added.

(code):

Source/JavaScriptCore:

When inlining setter calls in DFG, result VirtualRegister becomes invalid one. While other call-related DFG code correctly assumes
that result may be invalid, only CheckBadCell slow path missed this case. Since this is OSR exit path and VirtualRegister result
does not exist, set BottomValue only when "result" is valid as the other DFG code is doing.

dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::handleInlining):

3:53 AM Changeset in webkit [249393] by Carlos Garcia Campos

6 edits in releases/WebKitGTK/webkit-2.26

Merge r249316 - [wk2] LayoutTest imported/w3c/web-platform-tests/IndexedDB/fire-error-event-exception.html is a flaky failure
https://bugs.webkit.org/show_bug.cgi?id=169621

Reviewed by Alex Christensen.

Source/WebCore:

Event handlers of IDB objects were called in unexpected order because of race, which made the console messages
in the tests come out of order.
Usually, an operation/request result is handled as follows:

IDBServer sends IDBResultData to IDBClient.
IDBClient receives IDBResultData and finishes a IDBTransaction operation with that result.
IDBTransaction schedules operation completed timer.
(Some time later) Timer fires, and IDBTransaction completes a request with the result and dispatches event.
(Some time later) IDBTransaction is notified that event is dispatched. If there are other results received,

IDBTransaction schedules operation completed timer.

In previous implementation, if the IDBClient received a second IDBResultData for the same IDBTransaction between
step 3 and step 4, it would not schedule timer because timer was still active; if it received the result between
step 4 and step 5, it would schedule timer again.

Consider a flow like this:
result1 of transaction1 received, timer of transaction1 scheduled
result2 of transaction2 received, timer of transaction2 scheduled
result3 of transaction1 is received, timer of transaction1 active so no scheduling
timer of transaction1 fired, event1 to be dispatched to request1
timer of transaction2 fired, event2 to be dispatched to request2
result4 of transaction2 received, timer of transaction2 scheduled
event1 dispatched, timer of transaction1 scheduled (for handling result3)
event2 dispatched, timer of transaction2 active so no scheduling
timer of transaction2 fired, event3 to dispatch to request4
timer of transaction1 fired, event4 to dispatch to request3

request4 would get event before request3, though result3 was received before result4. We should stop scheduling
event if an IDBTransaction is in between step 4 and 5, which means its m_currentlyCompletingRequest is not null.

Modules/indexeddb/IDBTransaction.cpp:

(WebCore::IDBTransaction::operationCompletedOnServer):

LayoutTests:

Update test expectations to PASS.

platform/gtk/TestExpectations:
platform/ios-wk2/TestExpectations:
platform/mac-wk2/TestExpectations:

3:53 AM Changeset in webkit [249392] by Carlos Garcia Campos

23 edits in releases/WebKitGTK/webkit-2.26/Source

Merge r249313 - Add "IsolatedCopy" in the name of String getters that call isolatedCopy() on the string
https://bugs.webkit.org/show_bug.cgi?id=201318

Reviewed by Alex Christensen.

Add "IsolatedCopy" in the name of String getters that call isolatedCopy() on the string, for clarity.

Source/WebCore:

Modules/indexeddb/server/IDBServer.cpp:

(WebCore::IDBServer::IDBServer::createBackingStore):
(WebCore::IDBServer::IDBServer::performGetAllDatabaseNames):
(WebCore::IDBServer::IDBServer::removeDatabasesModifiedSinceForVersion):
(WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesModifiedSince):
(WebCore::IDBServer::IDBServer::removeDatabasesWithOriginsForVersion):
(WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesForOrigins):
(WebCore::IDBServer::IDBServer::computeSpaceUsedForOrigin):
(WebCore::IDBServer::IDBServer::upgradeFilesIfNecessary):

Modules/indexeddb/server/IDBServer.h:

(WebCore::IDBServer::IDBServer::databaseDirectoryPathIsolatedCopy const):

Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:

(WebCore::IDBServer::SQLiteIDBBackingStore::fullDatabaseDirectoryWithUpgrade):
(WebCore::IDBServer::SQLiteIDBBackingStore::databasesSizeForOrigin const):
(WebCore::IDBServer::SQLiteIDBBackingStore::deleteBackingStore):

Modules/indexeddb/server/SQLiteIDBBackingStore.h:

(WebCore::IDBServer::SQLiteIDBBackingStore::databaseRootDirectoryIsolatedCopy const):

Modules/webdatabase/Database.cpp:

(WebCore::Database::markAsDeletedAndClose):
(WebCore::Database::stringIdentifierIsolatedCopy const):
(WebCore::Database::displayNameIsolatedCopy const):
(WebCore::Database::expectedVersionIsolatedCopy const):
(WebCore::Database::fileNameIsolatedCopy const):
(WebCore::Database::details const):
(WebCore::Database::didCommitWriteTransaction):
(WebCore::Database::didExceedQuota):

Modules/webdatabase/Database.h:
Modules/webdatabase/DatabaseTracker.cpp:

(WebCore::DatabaseTracker::maximumSize):
(WebCore::DatabaseTracker::doneCreatingDatabase):
(WebCore::DatabaseTracker::addOpenDatabase):
(WebCore::DatabaseTracker::removeOpenDatabase):

Modules/webdatabase/SQLError.h:

(WebCore::SQLError::messageIsolatedCopy const):

Modules/webdatabase/SQLError.idl:
Modules/webdatabase/SQLTransaction.cpp:

(WebCore::SQLTransaction::openTransactionAndPreflight):

workers/service/server/RegistrationDatabase.cpp:

(WebCore::RegistrationDatabase::openSQLiteDatabase):
(WebCore::RegistrationDatabase::clearAll):

workers/service/server/RegistrationDatabase.h:

(WebCore::RegistrationDatabase::databaseDirectoryIsolatedCopy const):

Source/WebKit:

NetworkProcess/Classifier/ResourceLoadStatisticsPersistentStorage.cpp:

(WebKit::ResourceLoadStatisticsPersistentStorage::storageDirectoryPathIsolatedCopy const):
(WebKit::ResourceLoadStatisticsPersistentStorage::resourceLogFilePath const):
(WebKit::ResourceLoadStatisticsPersistentStorage::monitorDirectoryForNewStatistics):

NetworkProcess/Classifier/ResourceLoadStatisticsPersistentStorage.h:
NetworkProcess/cache/NetworkCacheBlobStorage.cpp:

(WebKit::NetworkCache::BlobStorage::blobDirectoryPathIsolatedCopy const):
(WebKit::NetworkCache::BlobStorage::synchronize):
(WebKit::NetworkCache::BlobStorage::blobPathForHash const):

NetworkProcess/cache/NetworkCacheBlobStorage.h:
NetworkProcess/cache/NetworkCacheStorage.cpp:

(WebKit::NetworkCache::Storage::basePathIsolatedCopy const):
(WebKit::NetworkCache::Storage::versionPath const):
(WebKit::NetworkCache::Storage::recordsPathIsolatedCopy const):
(WebKit::NetworkCache::Storage::synchronize):
(WebKit::NetworkCache::Storage::recordDirectoryPathForKey const):
(WebKit::NetworkCache::Storage::traverse):
(WebKit::NetworkCache::Storage::clear):
(WebKit::NetworkCache::Storage::shrink):
(WebKit::NetworkCache::Storage::deleteOldVersions):

NetworkProcess/cache/NetworkCacheStorage.h:

3:52 AM Changeset in webkit [249391] by Carlos Garcia Campos

3 edits
1 add in releases/WebKitGTK/webkit-2.26

Merge r249310 - [JSC] Repatch should construct CallCases and CasesValue at the same time
https://bugs.webkit.org/show_bug.cgi?id=201325

Reviewed by Saam Barati.

JSTests:

stress/repatch-switch.js: Added.

(main.f2.f0):
(main.f2.f3):
(main.f2.f1):
(main.f2):
(main):

Source/JavaScriptCore:

In linkPolymorphicCall, we should create callCases and casesValue at the same time to assert callCases.size() == casesValue.size().
If the call variant is isClosureCall and InternalFunction, we skip adding it to casesValue. So we should not add this variant to callCases too.

jit/Repatch.cpp:

(JSC::linkPolymorphicCall):

3:52 AM Changeset in webkit [249390] by Carlos Garcia Campos

4 edits in releases/WebKitGTK/webkit-2.26/Source/WebCore

Merge r249309 - Avoid running the outline painting phase if no renderers have outlines
https://bugs.webkit.org/show_bug.cgi?id=201284

Reviewed by Said Abou-Hallawa.

The outline painting phase (paintOutlineForFragments()) can take up to 20% of the painting time
even when there are no outlines. Keep track of which renderers have outlines, and only run the phase
when printing (for hasOutlineAnnotation()) or if there are any renderers with outlines.

rendering/RenderElement.cpp:

(WebCore::RenderElement::styleWillChange):
(WebCore::RenderElement::styleDidChange):
(WebCore::RenderElement::willBeDestroyed):

rendering/RenderLayer.cpp:

(WebCore::RenderLayer::paintLayerContents):

rendering/RenderView.h:

3:52 AM Changeset in webkit [249389] by Carlos Garcia Campos

5 edits in releases/WebKitGTK/webkit-2.26

Merge r249307 - Copying and pasting two paragraphs with a newline between them results in stray paragraph with newline inside.
https://bugs.webkit.org/show_bug.cgi?id=201306

Reviewed by Wenson Hsieh.

Source/WebCore:

Test: editing/pasteboard/paste-without-nesting.html

editing/ReplaceSelectionCommand.cpp:

(WebCore::ReplaceSelectionCommand::moveNodeOutOfAncestor): Consider the ancestor node safe to remove
if there is no rendered text inside, not just if there are any child nodes.

LayoutTests:

editing/pasteboard/paste-without-nesting-expected.txt: Updated results.
editing/pasteboard/paste-without-nesting.html: Added new test case.

3:52 AM Changeset in webkit [249388] by Carlos Garcia Campos

3 edits
1 add in releases/WebKitGTK/webkit-2.26

Merge r249306 - [JSC] ObjectAllocationSinkingPhase wrongly deals with always-taken branches during interpretation
https://bugs.webkit.org/show_bug.cgi?id=198650

Reviewed by Saam Barati.

JSTests:

stress/object-allocation-sinking-interpretation-can-interpret-edges-that-can-be-proven-unreachable-in-ai.js:

(main.v0):
(main):

Source/JavaScriptCore:

Object Allocation Sinking phase has a lightweight abstract interpreter which interprets DFG nodes related to allocations and properties.
This interpreter is lightweight since it does not track abstract values and conditions as deeply as AI does. It can happen that this
interpreter interpret the control-flow edge that AI proved that is never taken.
AI already knows some control-flow edges are never taken, and based on this information, AI can remove CheckStructure nodes. But
ObjectAllocationSinking phase can trace this never-taken edges and propagate structure information that contradicts to the analysis
done in ObjectAllocationSinking.

Let's see the example.

BB#0

35: NewObject([%AM:Object])
...
47: Branch(ConstantTrue, T:#1, F:#2)

BB#1 This basic block is never taken due to @47's jump.

...
71: PutByOffset(@35, @66, id2{a}, 0, W:NamedProperties(2))
72: PutStructure(@35, %AM:Object -> %Dx:Object, ID:60066)
...
XX: Jump(#2)

BB#2

...
92: CheckStructure(@35, [%Dx:Object])
93: PutByOffset(@35, @35, id2{a}, 0, W:NamedProperties(2))
...

AI removes @92 because AI knows BB#0 only takes BB#1 branch. @35's Structure is always %Dx so @92 is redundant.
AI proved that @71 and @72 are always executed while BB#0 -> BB#2 edge is never taken so that @35 object's structure is proven at @92.
After AI removes @92, ObjectAllocationSinking starts looking into this graph.

BB#0

35: NewObject([%AM:Object])
...
47: Branch(ConstantTrue, T:#1, F:#2)

BB#1 This basic block is never taken due to @47's jump.

...
71: PutByOffset(@35, @66, id2{a}, 0, W:NamedProperties(2))
72: PutStructure(@35, %AM:Object -> %Dx:Object, ID:60066)
...
XX: Jump(#2)

BB#2

...
93: PutByOffset(@35, @35, id2{a}, 0, W:NamedProperties(2))
...
YY: Jump(#3)

BB#3

...
ZZ: <HERE> want to materialize @35's sunk object.

Since AI does not change the @47 Branch to Jump (it is OK anyway), BB#0 -> BB#2 edge remains and ObjectAllocationSinking phase propagates information in
BB#0's %AM structure information to BB#2. ObjectAllocationSinking phase converts @35 to PhantomNewObject, removes PutByOffset and PutStructure, and
insert MaterializeNewObject in @ZZ. At this point, ObjectAllocationSinking lightweight interpreter gets two structures while AI gets one: @35's original
one (%AM) and @72's replaced one (%Dx). Since AI already proved @ZZ only gets %Dx, AI removed @92 CheckStructure. But this is not known to ObjectAllocationSinking
phase's interpretation. So when creating recovery data, MultiPutByOffset includes two structures, %AM and %Dx. This is OK since MultiPutByOffset takes
conservative set of structures and performs switching. But the problem here is that %AM's id2{a} offset is -1 since %AM does not have such a property.
So when creating MultiPutByOffset in ObjectAllocationSinking, we accidentally create MultiPutByOffset with -1 offset data, and lowering phase hits the debug
assertion.

187: MultiPutByOffset(@138, @138, id2{a}, <Replace: [%AM:Object], offset = -1, >, <Replace: [%Dx:Object], offset = 0, >)

This bug is harmless since %AM structure comparison never meets at runtime. But we are not considering the case including -1 offset property in MultiPutByOffset data.
In this patch, we just filter out apparently wrong structures when creating MultiPutByOffset in ObjectAllocationSinking. This is OK since it never comes at runtime.

dfg/DFGObjectAllocationSinkingPhase.cpp:

3:52 AM Changeset in webkit [249387] by Carlos Garcia Campos

5 edits in releases/WebKitGTK/webkit-2.26/Source/WebKit

Merge r249303 - Speculative loads should use the NetworkSession owning their Cache
https://bugs.webkit.org/show_bug.cgi?id=201314

Patch by Alex Christensen <achristensen@webkit.org> on 2019-08-29
Reviewed by Chris Dumez.

This provides a performance improvement when using non-default persistent WKWebsiteDataStores.

NetworkProcess/NetworkSession.cpp:

(WebKit::NetworkSession::NetworkSession):

NetworkProcess/cache/NetworkCache.cpp:

(WebKit::NetworkCache::Cache::open):
(WebKit::NetworkCache::Cache::Cache):

NetworkProcess/cache/NetworkCache.h:

(WebKit::NetworkCache::Cache::sessionID const):

NetworkProcess/cache/NetworkCacheSpeculativeLoad.cpp:

(WebKit::NetworkCache::SpeculativeLoad::SpeculativeLoad):

3:52 AM Changeset in webkit [249386] by Carlos Garcia Campos

31 edits in releases/WebKitGTK/webkit-2.26

Merge r249301 - Web Inspector: replace uses of Array.prototype.concat with Array.prototype.push
https://bugs.webkit.org/show_bug.cgi?id=201082

Reviewed by Joseph Pecoraro.

Source/WebInspectorUI:

x = x.concat(y) is very slow, as x has to be fully copied in order to add y to it.
Introduce Array.prototype.pushIterable, which iterates the given iterable and adds each
item to the this array.

UserInterface/Controllers/DOMDebuggerManager.js:

(WI.DOMDebuggerManager.prototype.get domBreakpoints):
(WI.DOMDebuggerManager.prototype.domBreakpointsInSubtree):

UserInterface/Controllers/JavaScriptRuntimeCompletionProvider.js:

(WI.JavaScriptRuntimeCompletionProvider.completionControllerCompletionsNeeded.receivedPropertyNames):

UserInterface/Models/CSSCompletions.js:

(WI.CSSCompletions):

UserInterface/Models/CSSKeywordCompletions.js:

(WI.CSSKeywordCompletions.forProperty):
(WI.CSSKeywordCompletions.forProperty.addKeywordsForName):
(WI.CSSKeywordCompletions.forFunction):

UserInterface/Models/Canvas.js:

(WI.Canvas.prototype.recordingProgress):

UserInterface/Models/DOMNodeStyles.js:

(WI.DOMNodeStyles.prototype._updateStyleCascade):
(WI.DOMNodeStyles.prototype._collectStylesInCascadeOrder):

UserInterface/Models/TimelineRecording.js:

(WI.TimelineRecording.prototype.get sourceCodeTimelines):
(WI.TimelineRecording.prototype.initializeCallingContextTrees):

UserInterface/Protocol/RemoteObject.js:

(WI.RemoteObject.prototype._getPropertyDescriptorsResolver):

UserInterface/Views/ConsoleMessageView.js:

(WI.ConsoleMessageView.prototype._appendMessageTextAndArguments):

UserInterface/Views/ContentBrowser.js:

(WI.ContentBrowser.prototype.get currentRepresentedObjects):

UserInterface/Views/DOMTreeElement.js:

(WI.DOMTreeElement.prototype._visibleChildren):

UserInterface/Views/DataGridNode.js:

(WI.DataGridNode.prototype.get filterableData):

UserInterface/Views/HeapAllocationsTimelineView.js:

(WI.HeapAllocationsTimelineView.prototype.get selectionPathComponents):

UserInterface/Views/IndexedDatabaseObjectStoreContentView.js:

(WI.IndexedDatabaseObjectStoreContentView.prototype._fetchMoreData.processEntries):

UserInterface/Views/NavigationItem.js:

(WI.NavigationItem.prototype.get _classNames):

UserInterface/Views/ObjectTreeView.js:

(WI.ObjectTreeView.prototype._updateProperties):

UserInterface/Views/OpenResourceDialog.js:

(WI.OpenResourceDialog.prototype._addResourcesForFrame):

UserInterface/Views/OverviewTimelineView.js:

(WI.OverviewTimelineView.prototype._loadExistingRecords):

UserInterface/Views/ResourceCollectionContentView.js:

(WI.ResourceCollectionContentView.prototype.get navigationItems):

UserInterface/Views/ResourceHeadersContentView.js:

(WI.ResourceHeadersContentView.prototype._perfomSearchOnKeyValuePairs):

UserInterface/Views/ResourceSecurityContentView.js:

(WI.ResourceSecurityContentView.prototype._perfomSearchOnKeyValuePairs):

UserInterface/Views/ScriptClusterTimelineView.js:

(WI.ScriptClusterTimelineView.prototype.get selectionPathComponents):

UserInterface/Views/ScrubberNavigationItem.js:

(WI.ScrubberNavigationItem.prototype.get additionalClassNames):

UserInterface/Views/SpreadsheetStyleProperty.js:

(WI.SpreadsheetStyleProperty.prototype._addGradientTokens):
(WI.SpreadsheetStyleProperty.prototype._addColorTokens.pushPossibleColorToken):
(WI.SpreadsheetStyleProperty.prototype._addTimingFunctionTokens):
(WI.SpreadsheetStyleProperty.prototype._addVariableTokens):

UserInterface/Views/TreeOutline.js:

(WI.TreeOutline.prototype.selfOrDescendant):

UserInterface/Views/View.js:

(WI.View._visitViewTreeForLayout):

LayoutTests:

inspector/unit-tests/array-utilities.html:
inspector/unit-tests/array-utilities-expected.txt:

Add tests for added utility Array.prototype.pushIterable.

3:52 AM Changeset in webkit [249385] by Carlos Garcia Campos

7 edits
3 adds in releases/WebKitGTK/webkit-2.26

Merge r249295 - document.fonts.ready is resolved too quickly
https://bugs.webkit.org/show_bug.cgi?id=174030
<rdar://problem/33083550>

Reviewed by Frédéric Wang.

LayoutTests/imported/w3c:

Test from https://github.com/web-platform-tests/wpt/pull/18489.

web-platform-tests/fonts/ahem.css: Added.

(@font-face):

web-platform-tests/infrastructure/assumptions/document-fonts-ready-expected.txt: Added.
web-platform-tests/infrastructure/assumptions/document-fonts-ready.html: Added.

Source/WebCore:

As described in https://drafts.csswg.org/css-font-loading/#font-face-set-ready, the ready promise
is only fulfilled after layout operations complete and no additional font loads are necessary.

This patch implements this by notifying the FontFaceSet created for the document when the document
is finished loading. At that time, the promise will be resolved as soon as fonts are finished loading if any.

Test: imported/w3c/web-platform-tests/infrastructure/assumptions/document-fonts-ready.html

css/CSSFontSelector.cpp:

(WebCore::CSSFontSelector::optionalFontFaceSet):

css/CSSFontSelector.h:
css/FontFaceSet.cpp:

(WebCore::FontFaceSet::FontFaceSet):
(WebCore::FontFaceSet::startedLoading):
(WebCore::FontFaceSet::didFirstLayout):
(WebCore::FontFaceSet::completedLoading):

css/FontFaceSet.h:
dom/Document.cpp:

(WebCore::Document::implicitClose):

3:52 AM Changeset in webkit [249384] by Carlos Garcia Campos

8 edits in releases/WebKitGTK/webkit-2.26/Source/WebInspectorUI

Merge r249291 - Web Inspector: REGRESSION (r248873): Debugger: pressing delete on a breakpoint will also delete any resource/element parent immediately before it in the list
https://bugs.webkit.org/show_bug.cgi?id=200939

Reviewed by Joseph Pecoraro.

UserInterface/Views/DebuggerSidebarPanel.js:

(WI.DebuggerSidebarPanel.prototype._breakpointTreeOutlineDeleteTreeElement):
(WI.DebuggerSidebarPanel.prototype._handleBreakpointElementAddedOrRemoved):
(WI.DebuggerSidebarPanel.prototype._breakpointTreeOutlineDeleteTreeElement.checkIfSelectionAdjustmentNeeded): Deleted.

UserInterface/Views/SourcesNavigationSidebarPanel.js:

(WI.SourcesNavigationSidebarPanel):
(WI.SourcesNavigationSidebarPanel.prototype._handleBreakpointElementAddedOrRemoved):
(WI.SourcesNavigationSidebarPanel.this._breakpointsTreeOutline.ondelete.checkIfSelectionAdjustmentNeeded): Deleted.
When the WI.TreeOutline's own ondelete is called, that means we must be handling a
delete that was _not_ handled by a WI.TreeElement. This means that the selectedTreeElement
has to be a resource/script, the window object, or one of the non-deletable breakpoints.

In the case of a non-deletable breakpoint, since they're never removed from their parent
WI.TreeOutline, we just shift the selection to the next selectable WI.TreeElement.

Otherwise, wait for the WI.TreeOutline.Event.ElementRemoved event to be fired, and adjust
the selection then based on whether the new selectedTreeElement is one of the "top" items,
namely the "All Exceptions", "Uncaught Exceptions", and "Assertion Failures" breakpoints.

UserInterface/Views/BreakpointTreeElement.js:

(WI.BreakpointTreeElement.prototype.ondelete):

UserInterface/Views/DOMBreakpointTreeElement.js:

(WI.DOMBreakpointTreeElement.prototype.ondelete):

UserInterface/Views/DOMNodeTreeElement.js:

(WI.DOMNodeTreeElement.prototype.ondelete):

UserInterface/Views/EventBreakpointTreeElement.js:

(WI.EventBreakpointTreeElement.prototype.ondelete):

UserInterface/Views/URLBreakpointTreeElement.js:

(WI.URLBreakpointTreeElement.prototype.ondelete):
Add return true; to let the parent WI.TreeOutline know that the delete event was handled.
This prevents the parent WI.TreeOutline's own ondelete from being called, which would
cause a double-delete as there would be a different selectedTreeElement.

3:52 AM Changeset in webkit [249383] by Carlos Garcia Campos

2 edits in releases/WebKitGTK/webkit-2.26/Source/WTF

Merge r249280 - CompletionHandler default constructor does not initialize m_wasConstructedOnMainThread
https://bugs.webkit.org/show_bug.cgi?id=201249

Reviewed by Joseph Pecoraro and Alex Christensen.

wtf/CompletionHandler.h:

(WTF::CompletionHandler<Out):

3:52 AM Changeset in webkit [249382] by Carlos Garcia Campos

2 edits in releases/WebKitGTK/webkit-2.26/Source/JavaScriptCore

Merge r249279 - Remove a bad assertion in ByteCodeParser::inlineCall().
https://bugs.webkit.org/show_bug.cgi?id=201292
<rdar://problem/54121659>

Reviewed by Michael Saboff.

In the DFG bytecode parser, we've already computed the inlining cost of a candidate
inlining target, and determine that it is worth inlining before invoking
ByteCodeParser::inlineCall(). However, in ByteCodeParser::inlineCall(), it
recomputes the inlining cost again only for the purpose of asserting that it isn't
too high.

Not consider a badly written test that does the following:

function bar() {

...
foo(); Call in a hot loop here.
...

}

bar(); <===== foo is inlineable into bar here.
noInline(foo); <===== Change mind, and make foo not inlineable.
bar();

With this bad test, the following racy scenario can occur:

the first invocation of bar() gets hot, and a concurrent compile is kicked off.
the compiler thread computes foo()'s inliningCost() and determines that it is worthy to be inlined, and will imminently call inlineCall().
the mutator calls the noInline() test utility on foo(), thereby making it NOT inlineable.
the compiler thread calls inlineCall(). In inlineCall(), it re-computes the inliningCost for foo() and now finds that it is not inlineable. An assertion failure follows.

Technically, the test is in error because noInline() shouldn't be used that way.
However, fuzzers that are not clued into noInline()'s proper usage may generate
code like this.

On the other hand, ByteCodeParser::inlineCall() should not be recomputing that the
inlining cost and asserting on it. The only reason inlineCall() is invoked is
because it was already previously determined that a target function is inlineable
based on its inlining cost. Today, in practice, I don't think we have any real
world condition where the mutator can affect the inlining cost of a target
function midway through execution. So, this assertion isn't a problem if no one
writes a test that abuses noInline(). However, should things change such that the
mutator is able to affect the inlining cost of a target function, then it is
incorrect for the compiler to assume that the inlining cost is immutable. Once
the compiler decides to inline a function, it should just follow through.

This patch removes this assertion in ByteCodeParser::inlineCall(). It is an
annoyance at best (for fuzzers), and at worst, incorrect if the mutator gains the
ability to affect the inlining cost of a target function.

dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::inlineCall):

3:52 AM Changeset in webkit [249381] by Carlos Garcia Campos

2 edits in releases/WebKitGTK/webkit-2.26/Source/WebCore

Merge r249276 - [GStreamer] Do not use makeWeakPtr from streaming thread.
https://bugs.webkit.org/show_bug.cgi?id=201220

Reviewed by Xabier Rodriguez-Calvar.

Test: imported/w3c/web-platform-tests/encrypted-media/clearkey-mp4-playback-retrieve-persistent-license.https.html

Recently some asserts were added that you can't create WeakPtr's
from streaming threads when the factory is created on the
main-thread. The fix is to eagerly create the WeakPtr at player
initialization time, rather than lazily when the streaming thread
first asks for it.

platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.h:

3:51 AM Changeset in webkit [249380] by Carlos Garcia Campos

3 edits in releases/WebKitGTK/webkit-2.26/Source/WebKit

Merge r249274 - Use inline data member initialization in ProcessLauncher
https://bugs.webkit.org/show_bug.cgi?id=201247

Reviewed by Ryosuke Niwa.

UIProcess/Launcher/ProcessLauncher.cpp:

(WebKit::ProcessLauncher::ProcessLauncher):

UIProcess/Launcher/ProcessLauncher.h:

2:31 AM Changeset in webkit [249379] by youenn@apple.com

11 edits in trunk/Source

Make NetworkConnectionToWebProcess keyed by their WebProcess identifier
https://bugs.webkit.org/show_bug.cgi?id=201300

Reviewed by Alex Christensen.

Make sure to create each NetworkConnectionToWebProcess for a given WebProcess.
Pass the process identifier at creation time.
This will allow to have the message registry be moved to NetworkProcess
so as to check port activity between processes.
This identifier might also be used in the future for other connections like
service worker context/client/server identifiers.

No observable change of behavior.

NetworkProcess/NetworkConnectionToWebProcess.cpp:

(WebKit::NetworkConnectionToWebProcess::create):
(WebKit::NetworkConnectionToWebProcess::NetworkConnectionToWebProcess):

NetworkProcess/NetworkConnectionToWebProcess.h:

(WebKit::NetworkConnectionToWebProcess::webProcessIdentifier const):

NetworkProcess/NetworkProcess.cpp:

(WebKit::NetworkProcess::removeNetworkConnectionToWebProcess):
(WebKit::NetworkProcess::createNetworkConnectionToWebProcess):
(WebKit::NetworkProcess::actualPrepareToSuspend):
(WebKit::NetworkProcess::resume):

NetworkProcess/NetworkProcess.h:
NetworkProcess/NetworkProcess.messages.in:
Platform/IPC/Connection.h:

(IPC::Connection::sendWithAsyncReply):
Allow to pass send options.

UIProcess/Network/NetworkProcessProxy.cpp:

(WebKit::NetworkProcessProxy::NetworkProcessProxy):
(WebKit::NetworkProcessProxy::getNetworkProcessConnection):
Make use of async reply to simplify the handling of lambdas.
(WebKit::NetworkProcessProxy::openNetworkProcessConnection):
(WebKit::NetworkProcessProxy::didFinishLaunching):

UIProcess/Network/NetworkProcessProxy.h:
UIProcess/Network/NetworkProcessProxy.messages.in:

2:31 AM Changeset in webkit [249378] by youenn@apple.com

22 edits
1 copy
1 add in trunk/Source

Introduce WorkerMessagePortChannelRegistry
https://bugs.webkit.org/show_bug.cgi?id=201333

Reviewed by Alex Christensen.

Source/WebCore:

This patch introduces a dedicated registry for workers.
This registry will hop to the main thread and use the
regular main thread registry to do the actual processing.

Covered by existing tests.

Sources.txt:
WebCore.xcodeproj/project.pbxproj:
dom/Document.cpp:

(WebCore::Document::messagePortChannelProvider):

dom/Document.h:
dom/MessageChannel.cpp:

(WebCore::MessageChannel::MessageChannel):

dom/MessagePort.cpp:

(WebCore::MessagePort::entangle):
(WebCore::MessagePort::postMessage):
(WebCore::MessagePort::disentangle):
(WebCore::MessagePort::close):
(WebCore::MessagePort::dispatchMessages):
(WebCore::MessagePort::hasPendingActivity const):

dom/messageports/MessagePortChannel.cpp:

(WebCore::MessagePortChannel::takeAllMessagesForPort):
(WebCore::MessagePortChannel::checkRemotePortForActivity):

dom/messageports/MessagePortChannel.h:
dom/messageports/MessagePortChannelProvider.cpp:

(WebCore::MessagePortChannelProvider::singleton):
(WebCore::MessagePortChannelProvider::fromContext):

dom/messageports/MessagePortChannelProvider.h:
dom/messageports/MessagePortChannelProviderImpl.cpp:

(WebCore::MessagePortChannelProviderImpl::takeAllMessagesForPort):
(WebCore::MessagePortChannelProviderImpl::checkRemotePortForActivity):

dom/messageports/MessagePortChannelProviderImpl.h:
dom/messageports/MessagePortChannelRegistry.cpp:

(WebCore::MessagePortChannelRegistry::takeAllMessagesForPort):
(WebCore::MessagePortChannelRegistry::checkRemotePortForActivity):

dom/messageports/MessagePortChannelRegistry.h:
dom/messageports/WorkerMessagePortChannelProvider.cpp: Added.

(WebCore::WorkerMessagePortChannelProvider::WorkerMessagePortChannelProvider):
(WebCore::WorkerMessagePortChannelProvider::~WorkerMessagePortChannelProvider):
(WebCore::WorkerMessagePortChannelProvider::createNewMessagePortChannel):
(WebCore::WorkerMessagePortChannelProvider::entangleLocalPortInThisProcessToRemote):
(WebCore::WorkerMessagePortChannelProvider::messagePortDisentangled):
(WebCore::WorkerMessagePortChannelProvider::messagePortClosed):
(WebCore::WorkerMessagePortChannelProvider::postMessageToRemote):
(WebCore::WorkerMessagePortChannelProvider::takeAllMessagesForPort):
(WebCore::WorkerMessagePortChannelProvider::checkRemotePortForActivity):
(WebCore::WorkerMessagePortChannelProvider::checkProcessLocalPortForActivity):

dom/messageports/WorkerMessagePortChannelProvider.h: Added.
workers/WorkerGlobalScope.cpp:

(WebCore::WorkerGlobalScope::messagePortChannelProvider):

workers/WorkerGlobalScope.h:

Source/WebKit:

By introducing WorkerMessagePortChannelRegistry, we are making
sure UIMessagePortChannelProvider is only called from the main thread.
This will help when moving the registry to network process.

UIProcess/UIMessagePortChannelProvider.cpp:

(WebKit::UIMessagePortChannelProvider::takeAllMessagesForPort):
(WebKit::UIMessagePortChannelProvider::checkRemotePortForActivity):

UIProcess/UIMessagePortChannelProvider.h:
WebProcess/WebCoreSupport/WebMessagePortChannelProvider.cpp:

(WebKit::WebMessagePortChannelProvider::takeAllMessagesForPort):
(WebKit::WebMessagePortChannelProvider::didTakeAllMessagesForPort):
(WebKit::WebMessagePortChannelProvider::didCheckRemotePortForActivity):
(WebKit::WebMessagePortChannelProvider::checkRemotePortForActivity):

WebProcess/WebCoreSupport/WebMessagePortChannelProvider.h:

1:52 AM Changeset in webkit [249377] by zandobersek@gmail.com

3 edits in trunk/Tools

[WPE] WindowBackend should do resizing properly
https://bugs.webkit.org/show_bug.cgi?id=201386

Reviewed by Carlos Garcia Campos.

The WindowBackend implementation is resized via the XDG protocol. The
initial size is stored for the object's lifetime and fallen back to when
the XDG protocol reports (0,0) configuration size.

Upon each resize, we have to recreate the texture. We also have to size
the GL viewport accordingly.

wpe/backends/WindowViewBackend.cpp:

(WPEToolingBackends::WindowViewBackend::WindowViewBackend):
(WPEToolingBackends::WindowViewBackend::createViewTexture):
(WPEToolingBackends::WindowViewBackend::resize):
(WPEToolingBackends::WindowViewBackend::displayBuffer):

wpe/backends/WindowViewBackend.h:

Sep 1, 2019:

11:20 PM Changeset in webkit [249376] by youenn@apple.com

5 edits in trunk/Source/WebKit

Abstract out LibWebRTCSocketClient so that rtc sockets can be implemented without libwebrtc sockets
https://bugs.webkit.org/show_bug.cgi?id=201302

Reviewed by Alex Christensen.

Introduce NetworkRTCProvider::Socket to be able to implement RTC socket support with non libwebrtc API

NetworkProcess/webrtc/LibWebRTCSocketClient.h:
NetworkProcess/webrtc/NetworkRTCProvider.cpp:

(WebKit::NetworkRTCProvider::createSocket):
(WebKit::NetworkRTCProvider::createUDPSocket):
(WebKit::NetworkRTCProvider::createServerTCPSocket):
(WebKit::NetworkRTCProvider::proxyInfoFromSession):
(WebKit::NetworkRTCProvider::createClientTCPSocket):
(WebKit::NetworkRTCProvider::wrapNewTCPConnection):
(WebKit::NetworkRTCProvider::addSocket):
(WebKit::NetworkRTCProvider::takeSocket):
(WebKit::NetworkRTCProvider::newConnection):
(WebKit::NetworkRTCProvider::closeListeningSockets):
(WebKit::NetworkRTCProvider::callSocket):

NetworkProcess/webrtc/NetworkRTCProvider.h:
NetworkProcess/webrtc/NetworkRTCProvider.mm:

(WebKit::NetworkRTCProvider::createClientTCPSocket):

NetworkProcess/webrtc/NetworkRTCSocket.cpp:

(WebKit::NetworkRTCSocket::sendTo):
(WebKit::NetworkRTCSocket::close):
(WebKit::NetworkRTCSocket::setOption):

11:03 PM Changeset in webkit [249375] by Fujii Hironori

2 edits in trunk/Source/WebKit

[Cairo] out-of-bounds read in ShareableBitmap::paint if a fractional device scale factor is used
https://bugs.webkit.org/show_bug.cgi?id=196340

Reviewed by Brent Fulgham.

In ShareableBitmap::paint, srcRectScaled can be out-of-bounds of
the surface if a fractional device scale factor is used.

Shared/cairo/ShareableBitmapCairo.cpp:

(WebKit::ShareableBitmap::paint): Use cairoSurfaceSetDeviceScale
to set a device scale factor to the surface instead of multiplying
srcRect with a device scale factor.

10:23 PM Changeset in webkit [249374] by mmaxfield@apple.com

7 edits
6 adds in trunk

[WHLSL] Resources don't work when only a subset of a bind group is referenced by a shader
https://bugs.webkit.org/show_bug.cgi?id=201383

Reviewed by Dean Jackson.

Source/WebCore:

Bind groups correspond to argument buffers in Metal. Both the Metal API and Metal Shading Language
have to agree on the layout of exactly which resources lie at which byte offsets within an argument
buffer.

Before this patch, we only emitted code for the items in the argument buffer that were actually
referenced by the shader source code. However, because these items are held inside a struct, if
we omit one item from the middle of the struct, the byte offets of all the successive items would
be wrong. This means that the Metal API and the shader would disagree about how to access these
resources, making the resources inaccessible (and causing security problems).

Tests: webgpu/whlsl/sparse-bind-group-2.html

webgpu/whlsl/sparse-bind-group-3.html
webgpu/whlsl/sparse-bind-group.html

Modules/webgpu/WHLSL/Metal/WHLSLEntryPointScaffolding.cpp:

(WebCore::WHLSL::Metal::EntryPointScaffolding::emitResourceHelperTypes):
(WebCore::WHLSL::Metal::VertexEntryPointScaffolding::emitHelperTypes):
(WebCore::WHLSL::Metal::FragmentEntryPointScaffolding::emitHelperTypes):
(WebCore::WHLSL::Metal::ComputeEntryPointScaffolding::emitHelperTypes):

Modules/webgpu/WHLSL/Metal/WHLSLEntryPointScaffolding.h:
Modules/webgpu/WHLSL/WHLSLSemanticMatcher.cpp:

(WebCore::WHLSL::matchResources):
(WebCore::WHLSL::matchVertexAttributes):
(WebCore::WHLSL::matchColorAttachments):

LayoutTests:

webgpu/whlsl/compute.html:
webgpu/whlsl/sparse-bind-group-2-expected.txt: Added.
webgpu/whlsl/sparse-bind-group-2.html: Added.
webgpu/whlsl/sparse-bind-group-3-expected.txt: Added.
webgpu/whlsl/sparse-bind-group-3.html: Added.
webgpu/whlsl/sparse-bind-group-expected.txt: Added.
webgpu/whlsl/sparse-bind-group.html: Added.

9:38 PM Changeset in webkit [249373] by commit-queue@webkit.org

7 edits
6 deletes in trunk

Unreviewed, rolling out r249369.
https://bugs.webkit.org/show_bug.cgi?id=201394

broke WHLSL tests (Requested by litherum on #webkit).

Reverted changeset:

"[WHLSL] Resources don't work when only a subset of a bind
group is referenced by a shader"
https://bugs.webkit.org/show_bug.cgi?id=201383
https://trac.webkit.org/changeset/249369

8:44 PM Changeset in webkit [249372] by ysuzuki@apple.com

16 edits in trunk/Source/JavaScriptCore

[JSC] Merge op_check_traps into op_enter and op_loop_hint
https://bugs.webkit.org/show_bug.cgi?id=201373

Reviewed by Mark Lam.

We also inline op_enter's slow path's write-barrier emission in LLInt.

bytecode/BytecodeList.rb:
bytecode/BytecodeUseDef.h:

(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):

bytecompiler/BytecodeGenerator.cpp:

(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitLoopHint):
(JSC::BytecodeGenerator::emitCheckTraps): Deleted.

bytecompiler/BytecodeGenerator.h:
dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
(JSC::DFG::ByteCodeParser::parseBlock):

dfg/DFGCapabilities.cpp:

(JSC::DFG::capabilityLevel):

jit/JIT.cpp:

(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::emitEnterOptimizationCheck): Deleted.

jit/JIT.h:
jit/JITOpcodes.cpp:

jit/JITOpcodes32_64.cpp:

(JSC::JIT::emit_op_enter): Deleted.

llint/LowLevelInterpreter.asm:
llint/LowLevelInterpreter32_64.asm:
llint/LowLevelInterpreter64.asm:
runtime/CommonSlowPaths.cpp:
runtime/CommonSlowPaths.h:

7:11 PM Changeset in webkit [249371] by Fujii Hironori

9 edits in trunk

Unreviewed, rolling out r249366.

WinCairo WebKit2 crashes in some websites and the device scale
factor is not correct in high DPI.

Reverted changeset:

"[WinCairo, FTW] Properly handle device scale factor"
https://bugs.webkit.org/show_bug.cgi?id=201361
https://trac.webkit.org/changeset/249366

4:35 PM Changeset in webkit [249370] by ysuzuki@apple.com

2 edits in trunk/Source/JavaScriptCore

[JSC] Fix testb3 debug failures
https://bugs.webkit.org/show_bug.cgi?id=201382

Reviewed by Mark Lam.

Fix testb3 debug failures due to incorrect types of operations like pointer + int32.

b3/testb3_8.cpp:

(testByteCopyLoop):
(testByteCopyLoopStartIsLoopDependent):
(testByteCopyLoopBoundIsLoopDependent):

4:08 PM Changeset in webkit [249369] by mmaxfield@apple.com

7 edits
6 adds in trunk

[WHLSL] Resources don't work when only a subset of a bind group is referenced by a shader
https://bugs.webkit.org/show_bug.cgi?id=201383

Reviewed by Dean Jackson.

Source/WebCore:

Tests: webgpu/whlsl/sparse-bind-group-2.html

webgpu/whlsl/sparse-bind-group-3.html
webgpu/whlsl/sparse-bind-group.html

Modules/webgpu/WHLSL/Metal/WHLSLEntryPointScaffolding.cpp:

Modules/webgpu/WHLSL/Metal/WHLSLEntryPointScaffolding.h:
Modules/webgpu/WHLSL/WHLSLSemanticMatcher.cpp:

(WebCore::WHLSL::matchResources):
(WebCore::WHLSL::matchVertexAttributes):
(WebCore::WHLSL::matchColorAttachments):

LayoutTests:

webgpu/whlsl/compute.html:
webgpu/whlsl/sparse-bind-group-2-expected.txt: Added.
webgpu/whlsl/sparse-bind-group-2.html: Added.
webgpu/whlsl/sparse-bind-group-3-expected.txt: Added.
webgpu/whlsl/sparse-bind-group-3.html: Added.
webgpu/whlsl/sparse-bind-group-expected.txt: Added.
webgpu/whlsl/sparse-bind-group.html: Added.

1:42 PM Changeset in webkit [249368] by Wenson Hsieh

11 edits
6 adds in trunk

Long presses that interrupt accelerated scrolling dispatch clicks on apps linked against iOS 12 or earlier
https://bugs.webkit.org/show_bug.cgi?id=201346
<rdar://problem/54885784>

Reviewed by Dean Jackson.

Source/WebKit:

For apps that are linked on or after iOS 13, we add a context menu interaction to the content view, which
requires us to disable (or avoid adding) the highlight long press gesture recognizer. However, for apps that are
linked on the iOS 12 SDK or prior, this gesture is still present, and fires when long pressing for (roughly) up
to 0.75 seconds if a tap gesture was not recognized instead. Firing this gesture sends a click event to the
page; this brings back some form of <rdar://problem/53889373>, but only when holding for slightly longer than a
normal tap, and also only in apps linked on iOS 12 or earlier. To fix this, we apply a similar solution as in
r248433 and detect whether a long press gesture interrupted scroll view deceleration in
-gestureRecognizerShouldBegin:. If so, we return NO to avoid clicking. See per-method comments below for more
details.

Testing this bug as-is was tricky, since there's no way in layout tests to simulate being linked on or before a
given SDK version. Luckily, recall that:

This bug occurs when the highlight gesture recognizer is enabled and added to the content view.
The highlight gesture recognizer only needs to be disabled or removed when context menu interaction is added.

As such, we should be able to restore the highlight gesture recognizer by suppressing the context menu
interaction in an app linked-on-or-after iOS 13, by setting allowsLinkPreview to NO. Unfortunately, this doesn't
quite work, since we currently always avoid adding the highlight gesture recognizer if the app is linked on
iOS 13 or later.

However, this means that the highlight gesture recognizer is absent from the content view in apps linked against
iOS 13 that disable link previews, even though its absence is not required. This means that long pressing a
clickable element in a web view that disables link previews does not show a tap highlight on iOS 13, whereas it
would on iOS 12; this is a regression, albeit a very subtle one. To fix this subtle issue and make it possible
to write a test for this bug, we refactor some logic for creating and configuring the highlight long press
gesture, such that we now unconditionally add the highlight gesture, but only enable it in apps linked on or
after iOS 13 if link previews (i.e. context menu interaction) are not allowed.

Test: fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-overflow.html

SourcesCocoa.txt:
UIProcess/API/Cocoa/WKWebView.mm:

(-[WKWebView setAllowsLinkPreview:]):

UIProcess/ios/WKContentViewInteraction.h:
UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView setupInteraction]):

Refactor our gesture setup logic to always create and add the long press and highlight long press gestures, but
conditionally disable them based on whether or not (1) the context menu is available, and (2) WKWebView's
allowsLinkPreview property.

(-[WKContentView _didChangeLinkPreviewAvailability]):
(-[WKContentView _updateLongPressAndHighlightLongPressGestures]):

Add a new helper to update the enabled state of the long press and highlight long press gestures, by consulting
-_shouldUseContextMenu and -allowsLinkPreview. This is called when setting up the gestures, as well as whenever
-allowsLinkPreview changes.

(-[WKContentView gestureRecognizerShouldBegin:]):

Factor out logic to ascend the view hierarchy in search of a UIScrollView that was interrupted while
decelerating into a local lambda function; use this for both the highlight gesture and the single tap gesture,
to determine whether they should begin.

UIProcess/ios/WKHighlightLongPressGestureRecognizer.h: Added.
UIProcess/ios/WKHighlightLongPressGestureRecognizer.mm: Added.

In order to remember the UIScrollView (if any) tracked by the highlight long press gesture, we subclass
_UIWebHighlightLongPressGestureRecognizer. While UILongPressGestureRecognizer does have SPI to ask for a list of
UITouches, by the time the gesture has been recognized and the gesture delegates are invoked, these UITouches
no longer correspond to UIViews. As such, the only time we have access to the list of UITouches with their
UIViews is during the touches* subclass hooks.

(-[WKHighlightLongPressGestureRecognizer reset]):

Clear out the tracked UIScrollView here, when the gesture is reset (i.e. after ending, or being canceled).

(-[WKHighlightLongPressGestureRecognizer touchesBegan:withEvent:]):

Remember the last touched UIScrollView here.

(-[WKHighlightLongPressGestureRecognizer lastTouchedScrollView]):

WebKit.xcodeproj/project.pbxproj:

Tools:

Add a new test option to allow tests to disable link previews.

WebKitTestRunner/TestController.cpp:

(WTR::updateTestOptionsFromTestHeader):

WebKitTestRunner/TestOptions.h:

Drive-by fix: also check enableLazyImageLoading when determining whether two TestOptions are the same.

(WTR::TestOptions::hasSameInitializationOptions const):

WebKitTestRunner/cocoa/TestControllerCocoa.mm:

(WTR::TestController::platformCreateWebView):

LayoutTests:

Add a couple of new layout tests to verify that using a long press gesture to interrupt momentum scrolling in a
web view that uses API to disable link previews does not result in a click.

fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-main-frame-expected.txt: Added.
fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-main-frame.html: Added.
fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-overflow-expected.txt: Added.
fast/scrolling/ios/click-events-after-long-press-during-momentum-scroll-in-overflow.html: Added.

11:28 AM Changeset in webkit [249367] by commit-queue@webkit.org

6 edits
3 adds in trunk

HTMLImageElement::decode() should return a resolved promise for decoding non bitmap images
https://bugs.webkit.org/show_bug.cgi?id=201243

Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-09-01
Reviewed by Youenn Fablet.

LayoutTests/imported/w3c:

web-platform-tests/html/semantics/embedded-content/the-img-element/decode/image-decode-picture-expected.txt:

Source/WebCore:

The specs: https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode
states that, decode() should resolve the pending promise if the decoding
was requested for a non bitmap image.

Test: fast/images/decode-non-bitmap-image-resolve.html

loader/ImageLoader.cpp:

(WebCore::resolveDecodePromises):
(WebCore::rejectDecodePromises):
(WebCore::ImageLoader::notifyFinished):
(WebCore::ImageLoader::decode):
(WebCore::ImageLoader::decodeError): Deleted.

loader/ImageLoader.h:

(WebCore::ImageLoader::hasPendingDecodePromises const):

LayoutTests:

fast/images/decode-non-bitmap-image-resolve-expected.txt: Added.
fast/images/decode-non-bitmap-image-resolve.html: Added.
fast/images/resources/green-100x100.svg: Added.

11:13 AM Changeset in webkit [249366] by Brent Fulgham

9 edits in trunk

[WinCairo, FTW] Properly handle device scale factor
https://bugs.webkit.org/show_bug.cgi?id=201361

Reviewed by Don Olmstead.

Source/WebCore:

Update the Direct2D ImageBuffer/ImageBufferData classes to correctly handle
the device scale factor.

platform/graphics/win/ImageBufferDataDirect2D.cpp:

(WebCore::ImageBufferData::putData):

platform/graphics/win/ImageBufferDirect2D.cpp:

(WebCore::ImageBuffer::putByteArray):

Source/WebKit:

Update the WebView and WebProcess to correctly handle
the device scale factor.

UIProcess/win/WebView.cpp:

(WebKit::WebView::WebView): Tell the page the current device scale factor.

WebProcess/win/WebProcessMainWin.cpp:

(WebKit::WebProcessMainWin): Tell the process to be aware of device scale.

Tools:

Reset zoom to 1.0; device scale is handled elsewhere.

MiniBrowser/win/WebKitBrowserWindow.cpp:

(WebKitBrowserWindow::resetZoom):

9:31 AM Changeset in webkit [249365] by mark.lam@apple.com

2 edits in trunk/Source/JavaScriptCore

Speculative build fix for ARMv7 and MIPS.
https://bugs.webkit.org/show_bug.cgi?id=201389

Not reviewed.

bytecode/CodeBlock.cpp:

(JSC::CodeBlock::jettison):

Note: See TracTimeline for information about the timeline view.

Download in other formats:

RSS Feed