Timeline



Jan 1, 2018:

8:27 PM Changeset in webkit [226320] by Michael Catanzaro
  • 10 edits
    10 copies in trunk

Rolled over to ChangeLog-2018-01-01

8:18 PM Changeset in webkit [226319] by Michael Catanzaro
  • 2 edits in trunk/LayoutTests

Unreviewed, add some more GTK crash expectations

  • platform/gtk/TestExpectations:
3:42 PM Changeset in webkit [226318] by jeffm@apple.com
  • 16 edits in trunk

Source/JavaScriptCore:
Update user-visible copyright strings to include 2018
​https://bugs.webkit.org/show_bug.cgi?id=181141

Reviewed by Dan Bernstein.

  • Info.plist:

Source/WebCore:
Update user-visible copyright strings to include 2018
​https://bugs.webkit.org/show_bug.cgi?id=181141

Reviewed by Dan Bernstein.

  • Info.plist:

Source/WebKit:
[Attachment Support] Remove current macOS support for dragging file-backed attachments
​https://bugs.webkit.org/show_bug.cgi?id=181188

Patch by Wenson Hsieh <Wenson Hsieh> on 2017-12-30
Reviewed by Dan Bernstein.

See WebCore/ChangeLog for more detail.

  • UIProcess/Cocoa/WebPageProxyCocoa.mm:

(WebKit::WebPageProxy::setPromisedDataForAttachment): Deleted.

  • UIProcess/Cocoa/WebViewImpl.h:
  • UIProcess/Cocoa/WebViewImpl.mm:

(WebKit::WebViewImpl::setPromisedDataForAttachment): Deleted.

  • UIProcess/PageClient.h:
  • UIProcess/WebPageProxy.h:
  • UIProcess/WebPageProxy.messages.in:
  • UIProcess/mac/PageClientImplMac.h:
  • UIProcess/mac/PageClientImplMac.mm:

(WebKit::PageClientImpl::setPromisedDataForAttachment): Deleted.

  • UIProcess/mac/WebPageProxyMac.mm:

(WebKit::WebPageProxy::setPromisedDataForAttachment): Deleted.

  • WebProcess/WebCoreSupport/WebDragClient.h:
  • WebProcess/WebCoreSupport/mac/WebDragClientMac.mm:

(WebKit::WebDragClient::declareAndWriteAttachment): Deleted.

Source/WebKitLegacy/mac:
Update user-visible copyright strings to include 2018
​https://bugs.webkit.org/show_bug.cgi?id=181141

Reviewed by Dan Bernstein.

  • Info.plist:

WebKitLibraries:
Update user-visible copyright strings to include 2018
​https://bugs.webkit.org/show_bug.cgi?id=181141

Reviewed by Dan Bernstein.

  • win/tools/scripts/COPYRIGHT-END-YEAR:
12:32 PM Changeset in webkit [226317] by Simon Fraser
  • 7 edits
    2 adds in trunk

REGRESSION (r225122): fePointLights don't work
​https://bugs.webkit.org/show_bug.cgi?id=181142

Reviewed by Dan Bates.

Source/WebCore:

r225122 refactored the initialLightingData code, but failed to set the lighting
color in the return value of PointLightSource::computePixelLightingData, so fePointLights
always used black.

Also fix a spelling error in initialLightingData.

Tests: svg/filters/fePointLight-color.svg

  • platform/graphics/filters/DistantLightSource.cpp:

(WebCore::DistantLightSource::initPaintingData):
(WebCore::DistantLightSource::computePixelLightingData const):

  • platform/graphics/filters/FELighting.cpp:

(WebCore::FELighting::drawLighting):

  • platform/graphics/filters/LightSource.h:
  • platform/graphics/filters/PointLightSource.cpp:

(WebCore::PointLightSource::computePixelLightingData const):

  • platform/graphics/filters/SpotLightSource.cpp:

(WebCore::SpotLightSource::computePixelLightingData const):

LayoutTests:

Ref test that compares a point light with a flood color.

  • svg/filters/fePointLight-color-expected.svg: Added.
  • svg/filters/fePointLight-color.svg: Added.
12:28 PM Changeset in webkit [226316] by Simon Fraser
  • 5 edits
    3 adds in trunk

Bottom right pixel of feDiffuseLighting has the wrong color
​https://bugs.webkit.org/show_bug.cgi?id=181203

Reviewed by Antti Koivisto.

Source/WebCore:

The lower right pixel of a feDiffuseLighting was the wrong color, because the kernel
values didn't match the spec for the bottom right Y values.

Test: svg/filters/feDiffuseLighting-bottomRightPixel.html

  • platform/graphics/filters/FELighting.cpp:

(WebCore::FELighting::LightingData::bottomRightNormal const):

LayoutTests:

Test that draws an SVG image into a canvas, and scales it up without interpolation.

  • svg/filters/feDiffuseLighting-bottomRightPixel-expected.html: Added.
  • svg/filters/feDiffuseLighting-bottomRightPixel.html: Added.
  • svg/filters/resources/feDiffuseLighting-rect.svg: Added.
11:53 AM Changeset in webkit [226315] by Simon Fraser
  • 6 edits
    2 adds in trunk

SVG lighting colors need to be converted into linearSRGB
​https://bugs.webkit.org/show_bug.cgi?id=181196

Reviewed by Dan Bates.

Source/WebCore:

SVG filters, like feLighting, that poke values directly into buffers rather than going
through CG like feFlood, need to convert colors into the operating color space. So add
conversion functions to go between linear and sRGB colors, and use these in feLighting,
and in ImageBuffer (which is only used for non-CG platforms).

Tests: svg/filters/feSpotLight-color.svg

  • platform/graphics/ColorUtilities.cpp:

(WebCore::linearToSRGBColorComponent):
(WebCore::sRGBToLinearColorComponent):
(WebCore::linearToSRGBColor):
(WebCore::sRGBToLinearColor):

  • platform/graphics/ColorUtilities.h:
  • platform/graphics/ImageBuffer.cpp:

(WebCore::ImageBuffer::transformColorSpace):

  • platform/graphics/filters/FELighting.cpp:

(WebCore::FELighting::drawLighting):

LayoutTests:

Compare a far-away green spotlight with a green flood. The bottom right pixel always
has the wrong color (webkit.org/b/181203), so mask it out.

  • svg/filters/feSpotLight-color-expected.svg: Added.
  • svg/filters/feSpotLight-color.svg: Added.

Dec 31, 2017:

1:25 AM Changeset in webkit [226314] by jiewen_tan@apple.com
  • 3 edits in trunk/Source/WebCore

[WebCrypto] Avoid promises being destroyed in secondary threads
​https://bugs.webkit.org/show_bug.cgi?id=180499
<rdar://problem/35890680>

Reviewed by Youenn Fablet.

This patch adds pending promise queue to SubtleCrypto such that it no longer
passes promises around different threads, which could cause crashes when
promises are destroyed in secondary threads.

Covered by existing tests.

  • crypto/SubtleCrypto.cpp:

(WebCore::getPromise):
(WebCore::SubtleCrypto::encrypt):
(WebCore::SubtleCrypto::decrypt):
(WebCore::SubtleCrypto::sign):
(WebCore::SubtleCrypto::verify):
(WebCore::SubtleCrypto::digest):
(WebCore::SubtleCrypto::generateKey):
(WebCore::SubtleCrypto::deriveKey):
(WebCore::SubtleCrypto::deriveBits):
(WebCore::SubtleCrypto::importKey):
(WebCore::SubtleCrypto::exportKey):
(WebCore::SubtleCrypto::wrapKey):
(WebCore::SubtleCrypto::unwrapKey):

  • crypto/SubtleCrypto.h:

Dec 30, 2017:

8:38 PM Changeset in webkit [226313] by mitz@apple.com
  • 2 edits in trunk/Source/WebCore

REGRESSION (r225494): Mouse pointer reappears shortly after hiding when scrolling using arrow keys
​https://bugs.webkit.org/show_bug.cgi?id=181193

Reviewed by Alexey Proskuryakov.

  • page/EventHandler.cpp:

(WebCore::EventHandler::cancelAutoHideCursorTimer): Removed a call to unhide the cursor

here.

11:30 AM Changeset in webkit [226312] by Wenson Hsieh
  • 25 edits in trunk/Source

[Attachment Support] Remove current macOS support for dragging file-backed attachments
​https://bugs.webkit.org/show_bug.cgi?id=181188

Reviewed by Dan Bernstein.

Source/WebCore:

Support for dragging attachments out as files on the NSPasteboard was introduced in r181760. However, this is
(1) a macOS-specific implementation, and (2) does not support attachments whose files are backed by inline data
rather than a filepath. As part of adding further WebKit attachment element support, subsequent patches will
reimplement support for dragging attachment elements in a cross-Cocoa-platform way that also allows for either
data- or file-backed blobs to be written to the pasteboard.

No new functionality; no new tests. All existing layout and API tests still pass.

  • page/DragClient.h:

(WebCore::DragClient::declareAndWriteDragImage):
(WebCore::DragClient::declareAndWriteAttachment): Deleted.

  • page/DragController.cpp:

(WebCore::DragController::startDrag):

  • page/DragController.h:

(WebCore::DragController::draggingImageURL const):
(WebCore::DragController::draggingAttachmentURL const): Deleted.

  • page/gtk/DragControllerGtk.cpp:

(WebCore::DragController::declareAndWriteAttachment): Deleted.

  • page/mac/DragControllerMac.mm:

(WebCore::DragController::declareAndWriteAttachment): Deleted.

  • page/win/DragControllerWin.cpp:

(WebCore::DragController::declareAndWriteAttachment): Deleted.

  • rendering/HitTestResult.cpp:

(WebCore::HitTestResult::absoluteAttachmentURL const): Deleted.

  • rendering/HitTestResult.h:

Source/WebKit:

See WebCore/ChangeLog for more detail.

  • UIProcess/Cocoa/WebPageProxyCocoa.mm:

(WebKit::WebPageProxy::setPromisedDataForAttachment): Deleted.

  • UIProcess/Cocoa/WebViewImpl.h:
  • UIProcess/Cocoa/WebViewImpl.mm:

(WebKit::WebViewImpl::setPromisedDataForAttachment): Deleted.

  • UIProcess/PageClient.h:
  • UIProcess/WebPageProxy.h:
  • UIProcess/WebPageProxy.messages.in:
  • UIProcess/mac/PageClientImplMac.h:
  • UIProcess/mac/PageClientImplMac.mm:

(WebKit::PageClientImpl::setPromisedDataForAttachment): Deleted.

  • UIProcess/mac/WebPageProxyMac.mm:

(WebKit::WebPageProxy::setPromisedDataForAttachment): Deleted.

  • WebProcess/WebCoreSupport/WebDragClient.h:
  • WebProcess/WebCoreSupport/mac/WebDragClientMac.mm:

(WebKit::WebDragClient::declareAndWriteAttachment): Deleted.

Source/WebKitLegacy/mac:

See WebCore/ChangeLog for more detail.

  • WebCoreSupport/WebDragClient.h:
  • WebCoreSupport/WebDragClient.mm:

(WebDragClient::declareAndWriteAttachment): Deleted.

  • WebView/WebHTMLView.mm:

(-[WebHTMLView namesOfPromisedFilesDroppedAtDestination:]):

11:05 AM Changeset in webkit [226311] by Yusuke Suzuki
  • 3 edits in trunk/Source/JavaScriptCore

[JSC] Remove unused JSTypes
​https://bugs.webkit.org/show_bug.cgi?id=181184

Reviewed by Saam Barati.

JSType includes some unused types such as NullType. They are for
primitive values in old days. But now JSType is only used for JSCells.

  • runtime/JSType.h:
  • runtime/TypedArrayType.cpp:

(JSC::typeForTypedArrayType):

Dec 28, 2017:

11:52 PM Changeset in webkit [226310] by sbarati@apple.com
  • 14 edits in trunk/Source/JavaScriptCore

Remove op_assert and make @assert in builtins a function call so we have DFG/FTL coverage for builtins that use @assert in debug builds
​https://bugs.webkit.org/show_bug.cgi?id=181176

Reviewed by Yusuke Suzuki.

Previously, op_assert was only implemented in the LLInt and baseline JIT. This
meant that any builtin that used @assert was not tiering up to the DFG/FTL
in debug builds. This patch changes @assert to just call a host function when
!ASSERT_DISABLED. It's a no-op when ASSERT_DISABLED. Now, builtins that use @assert
will tier up to the DFG/FTL on debug builds.

  • builtins/BuiltinNames.h:
  • bytecode/BytecodeDumper.cpp:

(JSC::BytecodeDumper<Block>::dumpBytecode):

  • bytecode/BytecodeIntrinsicRegistry.h:
  • bytecode/BytecodeList.json:
  • bytecode/BytecodeUseDef.h:

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

  • bytecompiler/BytecodeGenerator.cpp:

(JSC::BytecodeGenerator::emitAssert): Deleted.

  • bytecompiler/BytecodeGenerator.h:
  • bytecompiler/NodesCodegen.cpp:

(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_assert): Deleted.

  • jit/JIT.cpp:

(JSC::JIT::privateCompileMainPass):

  • llint/LowLevelInterpreter.asm:
  • runtime/CommonSlowPaths.cpp:
  • runtime/CommonSlowPaths.h:
  • runtime/JSGlobalObject.cpp:

(JSC::assertCall):
(JSC::JSGlobalObject::init):

10:18 PM Changeset in webkit [226309] by Alan Bujtas
  • 4 edits
    2 adds in trunk

RenderTreeUpdater::GeneratedContent should hold a weak reference to RenderQuote.
​https://bugs.webkit.org/show_bug.cgi?id=181185
<rdar://problem/36235307>

Reviewed by David Kilzer.

Source/WebCore:

Test: fast/css/content/content-quotes-crash-with-details.html

  • rendering/updating/RenderTreeUpdaterGeneratedContent.cpp:

(WebCore::RenderTreeUpdater::GeneratedContent::updateQuotesUpTo):

  • rendering/updating/RenderTreeUpdaterGeneratedContent.h:

(): Deleted.

LayoutTests:

  • fast/css/content/content-quotes-crash-with-details-expected.txt: Added.
  • fast/css/content/content-quotes-crash-with-details.html: Added.
9:56 PM Changeset in webkit [226308] by beidson@apple.com
  • 12 edits
    2 adds in trunk/Source

Add a ProcessIdentifier, vended from the UI process, to each child process
​https://bugs.webkit.org/show_bug.cgi?id=181155

Reviewed by Brent Fulgham.

Source/WebCore:

No new tests (Not yet testable)

More than once we've needed to create an identifier for an object that is unique across
all processes no matter which process it came from.

Sometimes we have an object or proxy object to the UI, Storage, or Network process
that allows us to augment a process-unique identifier to be globally unique. Due to multiple
sessions even this isn't good enough. Other times we have to create more hair-brained solutions.

In upcoming MessagePort work (Next step is ​https://bugs.webkit.org/show_bug.cgi?id=181172)
there was no truly workable solution for this.

By introducing a new ProcessIdentifier to each WK2 child processes that is guaranteed to be
unique over the run of a given UI process, we can easily create an object in any process and
identify it uniquely across all processes.

Obviously "process identifier" brings to mind a processes PID but that isn't good enough.
The number of PIDs on the system is fairly low and they are global across all
processes on the system. It is easy to see how a given UI process that runs for long enough
(such as a web browser that the user rarely quits) will start to run in to recycled PIDs,
therefore breaking the uniqueness guarantee that is required.

  • Sources.txt:
  • WebCore.xcodeproj/project.pbxproj:
  • platform/Process.cpp: Added.

(WebCore::Process::setIdentifier): Sets the process-wise identifier (to be used during WK2

child process initialization)

(WebCore::Process::identifier): Get the process-wide identifier.

  • platform/Process.h: Added.

Source/WebKit:

  • Shared/ChildProcess.cpp:

(WebKit::ChildProcess::initialize): Set the process-wide identifier if the initialization

parameters have it. Cocoa ASSERTS it exists; non-Cocoa platforms will have to figure this
out soon.

  • Shared/ChildProcess.h:
  • Shared/EntryPointUtilities/mac/XPCService/XPCServiceEntryPoint.h:

(WebKit::XPCServiceInitializer):

  • Shared/EntryPointUtilities/mac/XPCService/XPCServiceEntryPoint.mm:

(WebKit::XPCServiceInitializerDelegate::getProcessIdentifier):

  • UIProcess/ChildProcessProxy.cpp:

(WebKit::ChildProcessProxy::getLaunchOptions):

  • UIProcess/ChildProcessProxy.h:

(WebKit::ChildProcessProxy::coreProcessIdentifier const):

  • UIProcess/Launcher/ProcessLauncher.h:
  • UIProcess/Launcher/mac/ProcessLauncherMac.mm:

(WebKit::ProcessLauncher::launchProcess):

5:41 PM Changeset in webkit [226307] by Yusuke Suzuki
  • 19 edits in trunk/Source

Remove std::chrono if it is not used for ArgumentCoder or PersistentCoder
​https://bugs.webkit.org/show_bug.cgi?id=181174

Reviewed by Konstantin Tokarev.

Source/WebCore:

We would like to remove std::chrono as much as possible due to the danger of
its overflow unawareness. This patch removes std::chrono if it is not used
for ArgumentCoder or PersistentCoder.

No behavior change.

  • fileapi/FileReader.cpp:

(WebCore::FileReader::didReceiveData):

  • fileapi/FileReader.h:
  • inspector/InspectorOverlay.cpp:

(WebCore::InspectorOverlay::showPaintRect):
(WebCore::InspectorOverlay::updatePaintRectsTimerFired):

  • inspector/InspectorOverlay.h:
  • page/ResourceUsageThread.cpp:

(WebCore::ResourceUsageThread::threadBody):

  • page/cocoa/MemoryReleaseCocoa.mm:

(WebCore::jettisonExpensiveObjectsOnTopLevelNavigation):

  • platform/network/curl/SocketStreamHandleImpl.h:
  • platform/network/curl/SocketStreamHandleImplCurl.cpp:

(WebCore::SocketStreamHandleImpl::waitForAvailableData):
(WebCore::SocketStreamHandleImpl::startThread):

Source/WebKit:

  • NetworkProcess/cache/NetworkCache.cpp:

(WebKit::NetworkCache::Cache::retrieve):

  • NetworkProcess/cache/NetworkCacheStatistics.cpp:

(WebKit::NetworkCache::Statistics::initialize):

  • UIProcess/Cocoa/ViewGestureController.cpp:

(WebKit::ViewGestureController::SnapshotRemovalTracker::log const):
(WebKit::ViewGestureController::SnapshotRemovalTracker::start):

  • UIProcess/Cocoa/ViewGestureController.h:
  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::didCommitLoad):

  • WebProcess/WebPage/WebPage.h:

(WebKit::WebPage::loadCommitTime const):

  • WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::WebProcess::registerWithStateDumper):

Source/WTF:

Make WallTime more constexpr friendly. This change is already applied to MonoTonicTime.

We would like to move std::{isfinite,isinf,isnan} overloadings from std:: to each class scope in a separate patch[1].

[1]: ​https://bugs.webkit.org/show_bug.cgi?id=181183

  • wtf/WallTime.h:

(WTF::WallTime::WallTime):
(WTF::WallTime::fromRawSeconds):
(WTF::WallTime::infinity):
(WTF::WallTime::secondsSinceEpoch const):
(WTF::WallTime::operator bool const):
(WTF::WallTime::operator+ const):
(WTF::WallTime::operator- const):
(WTF::WallTime::operator== const):
(WTF::WallTime::operator!= const):
(WTF::WallTime::operator< const):
(WTF::WallTime::operator> const):
(WTF::WallTime::operator<= const):
(WTF::WallTime::operator>= const):

2:06 PM Changeset in webkit [226306] by commit-queue@webkit.org
  • 12 edits in trunk

[Win][CMake] Use add_custom_command to copy each forwarding header files
​https://bugs.webkit.org/show_bug.cgi?id=180921

Patch by Fujii Hironori <Fujii Hironori> on 2017-12-28
Reviewed by Brent Fulgham.

.:

Modifying WTF header files didn't trigger the recompilation of
TestWTF because Ninja doesn't know which command generates the
forwarding header.

Use add_custom_command to copy each forwarding header files.

  • Source/cmake/WebKitMacros.cmake: Added a new function WEBKIT_MAKE_FORWARDING_HEADERS.

Source/JavaScriptCore:

  • PlatformWin.cmake: Use WEBKIT_MAKE_FORWARDING_HEADERS.

Source/WebCore:

No new tests because there is no behavior change.

  • PlatformWin.cmake: Use WEBKIT_MAKE_FORWARDING_HEADERS.

Source/WebKitLegacy:

  • PlatformWin.cmake: Use WEBKIT_MAKE_FORWARDING_HEADERS.

Source/WTF:

  • wtf/PlatformWin.cmake: Use WEBKIT_MAKE_FORWARDING_HEADERS.

Tools:

TestWTFLib needs forwarding headers of WebCore. Use
add_dependencies instead of invoking the DerivedSources/WebCore/preBuild.cmd.

  • TestWebKitAPI/PlatformWin.cmake:
10:13 AM Changeset in webkit [226305] by sbarati@apple.com
  • 3 edits
    1 add in trunk

Assertion used to determine if something is an async generator is wrong
​https://bugs.webkit.org/show_bug.cgi?id=181168
<rdar://problem/35640560>

Reviewed by Yusuke Suzuki.

JSTests:

  • stress/async-generator-assertion.js: Added.

Source/JavaScriptCore:

Previous assertions were doing a get on the base value for @@asyncIterator.
This symbol is defined on AsyncGeneratorPrototype. The base value may change
its prototype, but it's still an async generator as far as our system is
concerned. This patch updates the assertion to check for a private property
on the base value.

  • builtins/AsyncGeneratorPrototype.js:

(globalPrivate.asyncGeneratorReject):
(globalPrivate.asyncGeneratorResolve):
(globalPrivate.asyncGeneratorResumeNext):

6:17 AM Changeset in webkit [226304] by Yusuke Suzuki
  • 2 edits in trunk/Source/WTF

[WTF] Add clock_gettime based monotonicallyIncreasingTime implementation for Linux and BSDs
​https://bugs.webkit.org/show_bug.cgi?id=181175

Reviewed by Michael Catanzaro.

Use platform-provided POSIX APIs to get monotonic time.

  • wtf/CurrentTime.cpp:

(WTF::monotonicallyIncreasingTime):

Note: See TracTimeline for information about the timeline view.