Timeline
Sep 1, 2019:
- 11:20 PM Changeset in webkit [249376] by
-
- 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
-
- 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
-
- 7 edits6 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
-
- 7 edits6 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
-
- 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.
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:
- 7:11 PM Changeset in webkit [249371] by
-
- 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
-
- 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
-
- 7 edits6 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.
- 1:42 PM Changeset in webkit [249368] by
-
- 11 edits6 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
-
- 6 edits3 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
-
- 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
-
- 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):
Aug 31, 2019:
- 5:47 PM Changeset in webkit [249364] by
-
- 25 edits18 adds7 deletes in trunk
Source/WebCore:
EXIF orientation should be respected when rendering images
https://bugs.webkit.org/show_bug.cgi?id=201123
Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-08-31
Reviewed by Simon Fraser.
-- Image::size() will return the rendered size based on the image
orientation. If image orientation is FromImage, ImageSource will query
the actual image orientation from the ImageDecoder. The low level APIs
might transpose the size just before calling the system API to draw
the image.
-- RenderElement::imageOrientation() will return ImageOrientation::FromImage
for all images and for all ports till the CSS image-orientation specs
is finalized.
-- The default of ImagePaintingOptions argument of GraphicsContext::drawImage()
will be changed to { ImageOrientation::FromImage }.
-- Image element: RenderImage::paintIntoRect() will pass imageOrientation()
which returns ImageOrientation::FromImage to GraphicsContext::drawImage().
-- CSS background image: RenderBoxModelObject::paintFillLayerExtended will
pass ImageOrientation::FromImage by default to GraphicsContext::drawTiledImage().
-- Images on canvas: CanvasRenderingContext2DBase::drawImage() will pass
ImageOrientation::FromImage by default to GraphicsContext::drawImage().
-- SVG images: RenderSVGImage::paintForeground() calls GraphicsContext::drawImage()
with the default ImagePaintingOptions which is now { ImageOrientation::FromImage }.
-- SVG feImage filters: FEImage::platformApplySoftware() calls
GraphicsContext::drawImage() with the default ImagePaintingOptions
which is now { ImageOrientation::FromImage }.
-- ImageDocument: RenderElement::imageOrientation() returns FromImage
always and for all ports.
Tests: fast/images/exif-orientation-background.html
fast/images/exif-orientation-canvas.html
fast/images/exif-orientation-content.html
fast/images/exif-orientation-element-object-fit.html
fast/images/exif-orientation-element.html
fast/images/exif-orientation-image-object.html
fast/images/exif-orientation-svg-feimage.html
fast/images/exif-orientation-svg-image.html
- html/canvas/CanvasRenderingContext2DBase.cpp:
(WebCore::CanvasRenderingContext2DBase::drawImage):
- loader/cache/CachedImage.cpp:
(WebCore::CachedImage::imageSizeForRenderer const):
- platform/graphics/BitmapImage.h:
- platform/graphics/CrossfadeGeneratedImage.h:
- platform/graphics/GeneratedImage.h:
- platform/graphics/GraphicsContext.h:
(WebCore::GraphicsContext::drawImage):
- platform/graphics/Image.h:
- platform/graphics/ImageFrame.h:
(WebCore::ImageFrame::sizeRespectingOrientation const): Deleted.
- platform/graphics/ImageSource.cpp:
(WebCore::ImageSource::ImageSource):
(WebCore::ImageSource::orientation):
(WebCore::ImageSource::size):
(WebCore::ImageSource::sizeRespectingOrientation): Deleted.
- platform/graphics/ImageSource.h:
- platform/graphics/cg/PDFDocumentImage.cpp:
(WebCore::PDFDocumentImage::size const):
- platform/graphics/cg/PDFDocumentImage.h:
- platform/mac/DragImageMac.mm:
(WebCore::createDragImageFromImage):
- rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::paintFillLayerExtended):
- rendering/RenderElement.cpp:
(WebCore::RenderElement::imageOrientation const):
- rendering/RenderImage.cpp:
(WebCore::RenderImage::paintIntoRect):
- svg/graphics/SVGImage.h:
- svg/graphics/SVGImageForContainer.cpp:
(WebCore::SVGImageForContainer::size const):
- svg/graphics/SVGImageForContainer.h:
LayoutTests:
EXIF orientation should be respected when rendering images
https://bugs.webkit.org/show_bug.cgi?id=201123
Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-08-31
Reviewed by Simon Fraser.
Existing tests are made ref-tests. New tests were added to cover more
cases for drawing images.
- fast/images/exif-orientation-background-expected.html: Added.
- fast/images/exif-orientation-background.html: Added.
- fast/images/exif-orientation-canvas-expected.html: Added.
- fast/images/exif-orientation-canvas.html: Added.
- fast/images/exif-orientation-composited-expected.html: Added.
- fast/images/exif-orientation-composited-expected.txt: Removed.
- fast/images/exif-orientation-composited.html:
- fast/images/exif-orientation-content-expected.html: Added.
- fast/images/exif-orientation-content.html: Added.
- fast/images/exif-orientation-css-expected.txt: Removed.
- fast/images/exif-orientation-css.html: Removed.
- fast/images/exif-orientation-element-expected.html: Added.
- fast/images/exif-orientation-element-object-fit-expected.html: Added.
- fast/images/exif-orientation-element-object-fit.html: Added.
- fast/images/exif-orientation-element.html: Added.
- fast/images/exif-orientation-expected.txt: Removed.
- fast/images/exif-orientation-image-document-expected.html: Added.
- fast/images/exif-orientation-image-document-expected.txt: Removed.
- fast/images/exif-orientation-image-document.html:
- fast/images/exif-orientation-image-object-expected.html: Added.
- fast/images/exif-orientation-image-object.html: Added.
- fast/images/exif-orientation-svg-feimage-expected.html: Added.
- fast/images/exif-orientation-svg-feimage.html: Added.
- fast/images/exif-orientation-svg-image-expected.html: Added.
- fast/images/exif-orientation-svg-image.html: Added.
- fast/images/exif-orientation.html: Removed.
- platform/gtk/TestExpectations:
- platform/mac/fast/images/exif-orientation-composited-expected.png: Removed.
- platform/win/TestExpectations:
- 4:02 PM Changeset in webkit [249363] by
-
- 1 edit2 adds in trunk/LayoutTests
[iOS] Add a test to ensure that a tap in editable content shows the callout bar if the selection did not change
https://bugs.webkit.org/show_bug.cgi?id=200082
Reviewed by Dean Jackson.
Adds a layout test to cover the UIKit change in <rdar://problem/53106460>.
- editing/selection/ios/show-callout-bar-after-tap-expected.txt: Added.
- editing/selection/ios/show-callout-bar-after-tap.html: Added.
- 4:31 AM Changeset in webkit [249362] by
-
- 2 edits in trunk/Source/JavaScriptCore
[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:16 AM Changeset in webkit [249361] by
-
- 7 edits in trunk
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:
- 2:05 AM Changeset in webkit [249360] by
-
- 10 edits10 adds in trunk
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.
- 12:52 AM Changeset in webkit [249359] by
-
- 8 edits in trunk/Source
DocumentStorageAccess::hasStorageAccess() / requestStorageAccess() don't need to know about pageID / frameID
https://bugs.webkit.org/show_bug.cgi?id=201364
Reviewed by John Wilander.
Source/WebCore:
DocumentStorageAccess::hasStorageAccess() / requestStorageAccess() don't need to know about pageID / frameID. pageID is
redundant since it is being ignored by the callee. For the frame, simply pass the frame object in.
- dom/DocumentStorageAccess.cpp:
(WebCore::DocumentStorageAccess::hasStorageAccess):
(WebCore::DocumentStorageAccess::requestStorageAccess):
- page/ChromeClient.h:
(WebCore::ChromeClient::hasStorageAccess):
(WebCore::ChromeClient::requestStorageAccess):
Source/WebKit:
- WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::hasStorageAccess):
(WebKit::WebChromeClient::requestStorageAccess):
- WebProcess/WebCoreSupport/WebChromeClient.h:
- WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::hasStorageAccess):
(WebKit::WebPage::requestStorageAccess):
- WebProcess/WebPage/WebPage.h:
