Timeline
Aug 26, 2018:
- 11:57 PM Changeset in webkit [235353] by
-
- 2 edits1221 adds in trunk/LayoutTests
Unreviewed WPE gardening. Enabling more tests under the fast/ directory.
- platform/wpe/TestExpectations:
- platform/wpe/fast/backgrounds: Added 28 baselines.
- platform/wpe/fast/block: Added 267 baselines.
- platform/wpe/fast/body-propagation: Added 65 baselines.
- platform/wpe/fast/borders: Added 69 baselines.
- platform/wpe/fast/css: Added 193 baselines.
- platform/wpe/fast/css3-text: Added 2 baselines.
- platform/wpe/fast/frames: Added 27 baselines.
- platform/wpe/fast/hidpi: Added 20 baselines.
- platform/wpe/fast/html: Added 64 baselines.
- platform/wpe/fast/images: Added 14 baselines.
- platform/wpe/fast/layers: Added 12 baselines.
- platform/wpe/fast/multicol: Added 98 baselines.
- platform/wpe/fast/overflow: Added 43 baselines.
- platform/wpe/fast/reflections: Added 9 baselines.
- platform/wpe/fast/selectors: Added 101 baselines.
- platform/wpe/fast/sub-pixel: Added 6 baselines.
- platform/wpe/fast/table: Added 162 baselines.
- platform/wpe/fast/visual-viewport: Added 1 baseline.
- 10:01 PM Changeset in webkit [235352] by
-
- 6 edits2 moves in trunk/Source/WebCore
[LFC][Floating] FloatBox -> FloatAvoider
https://bugs.webkit.org/show_bug.cgi?id=188941
Reviewed by Antti Koivisto.
This is in preparation for the float avoidance feature where formatting context root boxes avoid existing floats.
- Sources.txt:
- WebCore.xcodeproj/project.pbxproj:
- layout/displaytree/DisplayBox.h:
- layout/floats/FloatAvoider.cpp: Renamed from Source/WebCore/layout/floats/FloatBox.cpp.
(WebCore::Layout::FloatAvoider::FloatAvoider):
(WebCore::Layout::FloatAvoider::initializePosition):
(WebCore::Layout::FloatAvoider::isLeftAligned const):
(WebCore::Layout::FloatAvoider::setLeft):
(WebCore::Layout::FloatAvoider::setTopLeft):
(WebCore::Layout::FloatAvoider::resetVertically):
(WebCore::Layout::FloatAvoider::resetHorizontally):
(WebCore::Layout::FloatAvoider::topLeftInContainingBlock const):
- layout/floats/FloatAvoider.h: Renamed from Source/WebCore/layout/floats/FloatBox.h.
(WebCore::Layout::FloatAvoider::top const):
(WebCore::Layout::FloatAvoider::left const):
(WebCore::Layout::FloatAvoider::marginTop const):
(WebCore::Layout::FloatAvoider::marginLeft const):
(WebCore::Layout::FloatAvoider::marginBottom const):
(WebCore::Layout::FloatAvoider::marginRight const):
(WebCore::Layout::FloatAvoider::rectWithMargin const):
(WebCore::Layout::FloatAvoider::setTop):
- layout/floats/FloatingContext.cpp:
(WebCore::Layout::FloatingContext::positionForFloat const):
(WebCore::Layout::FloatingContext::floatingPosition const):
- layout/floats/FloatingContext.h:
- 9:55 PM Changeset in webkit [235351] by
-
- 2 edits in trunk/Source/WebCore
[Curl] Implement deleteCookie()
https://bugs.webkit.org/show_bug.cgi?id=188908
Reviewed by Fujii Hironori.
Support deleting cookies from the web inspector
Tested from the web inspector.
- platform/network/curl/CookieJarCurlDatabase.cpp:
(WebCore::CookieJarCurlDatabase::deleteCookie const):
- 9:03 PM Changeset in webkit [235350] by
-
- 5 edits in trunk/Source/WebCore
[LFC][Floating] Simplify FloatingState::FloatItem class
https://bugs.webkit.org/show_bug.cgi?id=188912
Reviewed by Antti Koivisto.
Let's remove some redundant code now that FloatingState::FloatItem is not used for incoming floats anymore.
- layout/Verification.cpp:
(WebCore::Layout::LayoutContext::verifyAndOutputMismatchingLayoutTree const):
- layout/floats/FloatBox.cpp:
(WebCore::Layout::FloatBox::resetVertically):
- layout/floats/FloatingContext.cpp:
(WebCore::Layout::FloatingPair::left const):
(WebCore::Layout::FloatingPair::right const):
(WebCore::Layout::FloatingPair::intersects const):
(WebCore::Layout::previousFloatingIndex):
(WebCore::Layout::Iterator::operator++):
(WebCore::Layout::Iterator::set):
- layout/floats/FloatingState.cpp:
(WebCore::Layout::FloatingState::FloatItem::FloatItem):
(WebCore::Layout::FloatingState::remove):
(WebCore::Layout::FloatingState::bottom const):
- layout/floats/FloatingState.h:
(WebCore::Layout::FloatingState::FloatItem::operator== const):
(WebCore::Layout::FloatingState::FloatItem::isLeftPositioned const):
(WebCore::Layout::FloatingState::FloatItem::rectWithMargin const):
(WebCore::Layout::FloatingState::FloatItem::bottom const):
(WebCore::Layout::FloatingState::leftBottom const):
(WebCore::Layout::FloatingState::rightBottom const):
(WebCore::Layout::FloatingState::bottom const):
(WebCore::Layout::FloatingState::FloatItem::inFormattingContext const):
(WebCore::Layout::FloatingState::FloatItem::layoutBox const): Deleted.
(WebCore::Layout::FloatingState::FloatItem::containingBlock const): Deleted.
(WebCore::Layout::FloatingState::FloatItem::displayBox const): Deleted.
(WebCore::Layout::FloatingState::FloatItem::containingBlockDisplayBox const): Deleted.
- 8:32 PM Changeset in webkit [235349] by
-
- 15 edits2 copies1 add in trunk
[Apple Pay] Introduce new values for -apple-pay-button-type
https://bugs.webkit.org/show_bug.cgi?id=188949
<rdar://problem/39992228>
Reviewed by Anders Carlsson.
Source/WebCore:
Added "in-store", "checkout", "book", and "subscribe" keywords for -apple-pay-button-type,
and mapped those values to their equivalent PKPaymentButtonTypes.
Tests: http/tests/ssl/applepay/ApplePayButton.html
http/tests/ssl/applepay/ApplePayButtonV4.html
- css/CSSPrimitiveValueMappings.h:
(WebCore::CSSPrimitiveValue::CSSPrimitiveValue):
(WebCore::CSSPrimitiveValue::operator ApplePayButtonType const):
- css/CSSValueKeywords.in:
- css/parser/CSSParserFastPaths.cpp:
(WebCore::CSSParserFastPaths::isValidKeywordPropertyAndValue):
- rendering/RenderThemeCocoa.mm:
(WebCore::toPKPaymentButtonType):
- rendering/style/RenderStyleConstants.h:
Source/WebCore/PAL:
- pal/spi/cocoa/PassKitSPI.h:
LayoutTests:
- http/tests/ssl/applepay/ApplePayButton.html: Added.
- http/tests/ssl/applepay/ApplePayButtonV4.html: Added.
- platform/mac-highsierra/http/tests/ssl/applepay/ApplePayButton-expected.png:
- platform/mac-highsierra/http/tests/ssl/applepay/ApplePayButton-expected.txt:
- platform/mac/http/tests/ssl/applepay/ApplePayButton-expected.png: Added.
- platform/mac/http/tests/ssl/applepay/ApplePayButton-expected.txt: Added.
- platform/mac/http/tests/ssl/applepay/ApplePayButtonV4-expected.png: Added.
- platform/mac/http/tests/ssl/applepay/ApplePayButtonV4-expected.txt: Added.
- platform/mac-wk2/TestExpectations:
- 7:54 PM Changeset in webkit [235348] by
-
- 2 edits in trunk
[CMake] Remove stale comment from WebKitFeatures.cmake
https://bugs.webkit.org/show_bug.cgi?id=188918
Reviewed by Fujii Hironori.
This comment at the top of WebKitFeatures.cmake is no longer accurate because feature defaults are no longer defined in FeatureList.pm (thank goodness!)
- Source/cmake/WebKitFeatures.cmake:
- 7:48 PM Changeset in webkit [235347] by
-
- 1 edit2 moves2 adds in trunk/LayoutTests
Update test expectations for http/tests/ssl/applepay/ApplePayButton.html on macOS High Sierra.
- platform/mac-highsierra/http/tests/ssl/applepay/ApplePayButton-expected.png: Renamed from LayoutTests/platform/mac-sierra/http/tests/ssl/applepay/ApplePayButton-expected.png.
- platform/mac-highsierra/http/tests/ssl/applepay/ApplePayButton-expected.txt: Renamed from LayoutTests/platform/mac-sierra/http/tests/ssl/applepay/ApplePayButton-expected.txt.
- 7:45 PM Changeset in webkit [235346] by
-
- 4 edits in trunk
Using _WKRemoteObjectInterface with a protocol that inherits from a non-NSObject protocol crashes
https://bugs.webkit.org/show_bug.cgi?id=188958
Patch by Sam Weinig <sam@webkit.org> on 2018-08-26
Reviewed by Anders Carlsson.
Source/WebKit:
- Shared/API/Cocoa/_WKRemoteObjectInterface.mm:
(initializeMethods):
Fix infinite recursion by using the passed in protocol rather
than always using the one from the initial interface.
Tools:
- TestWebKitAPI/Tests/WebKitCocoa/RemoteObjectRegistry.h:
Update test protocol to have inheritance.
- 7:44 PM Changeset in webkit [235345] by
-
- 4 edits in trunk/Source/WebCore
Make IDBCursor::m_request a WeakPtr
https://bugs.webkit.org/show_bug.cgi?id=188938
Reviewed by Alex Christensen.
Make m_request a WeakPtr so that if m_request is destroyed, the related cursor will not use the invalid pointer.
Covered by existing tests.
- Modules/indexeddb/IDBCursor.cpp:
(WebCore::IDBCursor::continuePrimaryKey): Other continue and advance methods that are calling uncheckedIterateCursor do check for m_request.
Apply the same check for continuePrimaryKey.
(WebCore::IDBCursor::uncheckedIterateCursor):
- Modules/indexeddb/IDBCursor.h:
(WebCore::IDBCursor::setRequest):
(WebCore::IDBCursor::clearRequest):
(WebCore::IDBCursor::request):
- Modules/indexeddb/IDBRequest.h:
- 7:43 PM Changeset in webkit [235344] by
-
- 10 edits in trunk/Source/WebCore
IDBCursor does not need to be an ActiveDOMObject
https://bugs.webkit.org/show_bug.cgi?id=188937
Reviewed by Alex Christensen.
Remove ActiveDOMObject from IDBCursor IDL.
Update constructors and call sites accordingly.
This allows removing m_outstandingRequestCount and related code in IDBRequest.
Covered by existing tests.
- Modules/indexeddb/IDBCursor.cpp:
(WebCore::IDBCursor::create):
(WebCore::IDBCursor::IDBCursor):
(WebCore::IDBCursor::update):
(WebCore::IDBCursor::uncheckedIterateCursor):
(WebCore::IDBCursor::deleteFunction):
(WebCore::IDBCursor::activeDOMObjectName const): Deleted.
(WebCore::IDBCursor::canSuspendForDocumentSuspension const): Deleted.
(WebCore::IDBCursor::hasPendingActivity const): Deleted.
(WebCore::IDBCursor::decrementOutstandingRequestCount): Deleted.
- Modules/indexeddb/IDBCursor.h:
- Modules/indexeddb/IDBCursor.idl:
- Modules/indexeddb/IDBCursorWithValue.cpp:
(WebCore::IDBCursorWithValue::create):
(WebCore::IDBCursorWithValue::IDBCursorWithValue):
- Modules/indexeddb/IDBCursorWithValue.h:
- Modules/indexeddb/IDBCursorWithValue.idl:
- Modules/indexeddb/IDBRequest.cpp:
(WebCore::IDBRequest::setSource):
(WebCore::IDBRequest::dispatchEvent):
(WebCore::IDBRequest::willIterateCursor):
(WebCore::IDBRequest::didOpenOrIterateCursor):
- Modules/indexeddb/IDBRequest.h:
- Modules/indexeddb/IDBTransaction.cpp:
(WebCore::IDBTransaction::requestOpenCursor):
- WebCore.xcodeproj/project.pbxproj:
- 7:37 PM Changeset in webkit [235343] by
-
- 38 edits1 add in trunk
[Attachment Support] Dropping and pasting images should insert inline image elements with _WKAttachments
https://bugs.webkit.org/show_bug.cgi?id=188933
<rdar://problem/43699724>
Reviewed by Darin Adler.
Source/WebCore:
Support the ability to drop and paste images as image elements, with attachment elements, only if attachment
elements are enabled. See changes below for more detail.
Tests: WKAttachmentTests.CutAndPastePastedImage
WKAttachmentTests.MovePastedImageByDragging
WKAttachmentTests.RemoveNewlinesBeforePastedImage
- editing/Editor.h:
- editing/cocoa/EditorCocoa.mm:
(WebCore::Editor::getPasteboardTypesAndDataForAttachment):
Adjust this helper to take an Element& rather than an HTMLAttachmentElement&, and address a FIXME by writing the
document origin identifier to the pasteboard via custom pasteboard data when dragging an attachment. This allows
us to avoid creating extra image and attachment elements when dragging an image backed by an attachment within
the same document.
- editing/cocoa/WebContentReaderCocoa.mm:
(WebCore::contentTypeIsSuitableForInlineImageRepresentation):
Add a helper to determine whether a content type (UTI or MIME type) should be read as an inline image.
(WebCore::createFragmentForImageAttachment):
(WebCore::replaceRichContentWithAttachments):
(WebCore::WebContentReader::readFilePaths):
Teach codepaths where we currently create attachment elements to instead create image elements if the MIME type,
is something suitable for display via an inline image element; add the attachment element under the shadow root
of the image element.
- editing/markup.cpp:
(WebCore::StyledMarkupAccumulator::appendCustomAttributes):
(WebCore::restoreAttachmentElementsInFragment):
When dragging or copying an image element, we need to make sure that any attachment element backing the image
is preserved in the pasted or dropped fragment. To do this, we use a technique similar to what was done for
r180785 and r224593 and write a temporary "webkitattachmentid" attribute to the serialized markup on copy. Upon
deserializing the markup back to a fragment, we then create an attachment element with the same identifier under
the image.
(WebCore::createFragmentFromMarkup):
- html/HTMLAttachmentElement.h:
- html/HTMLImageElement.cpp:
(WebCore::HTMLImageElement::setAttachmentElement):
(WebCore::HTMLImageElement::attachmentElement const):
Helper methods to get and set an attachment element under an image element. Setting an image's attachment
element puts that attachment element under the shadow root of the image, and also hides the attachment element.
(WebCore::HTMLImageElement::attachmentIdentifier const):
Returns the identifier of an attachment element associated with the image element, or null.
- html/HTMLImageElement.h:
- html/HTMLImageElement.idl:
Add HTMLImageElement.webkitAttachmentIdentifier, a readonly attribute guarded by runtime-enabled attachment
element feature.
- page/DragController.cpp:
(WebCore::DragController::startDrag):
In the case of dragging an image, if that image element is backed by an attachment element, don't bother writing
the image data to the clipboard; instead, write the attachment data as a promise.
(WebCore::DragController::doImageDrag):
Plumb promised attachment information to DragController::doSystemDrag.
(WebCore::DragController::promisedAttachmentInfo):
Teach this to handle attachment elements as well as image elements that are backed by attachment elements.
- page/DragController.h:
- platform/PromisedAttachmentInfo.h:
(WebCore::PromisedAttachmentInfo::operator bool const):
A valid PromisedAttachmentInfo no longer requires a contentType to be set; instead, an attachment identifier
alone is sufficient, since an up-to-date content type can be requested in the UI process from the API attachment
object.
Source/WebKit:
Support the ability to drop and paste images as image elements, with attachment elements, only if attachment
elements are enabled. See changes below for more detail.
- Shared/WebCoreArgumentCoders.cpp:
(IPC::ArgumentCoder<PromisedAttachmentInfo>::encode):
(IPC::ArgumentCoder<PromisedAttachmentInfo>::decode):
Rename "filename" to "fileName", for consistency with WKContentView and WebViewImpl.
- UIProcess/API/APIAttachment.cpp:
(API::Attachment::mimeType const):
(API::Attachment::fileName const):
- UIProcess/API/APIAttachment.h:
Push getters for MIME type, UTI, and the file name down from _WKAttachment to API::Attachment. This allows
WKContentView and WebViewImpl to ask an API::Attachment questions about its UTI and file name without
additionally creating a wrapper object.
- UIProcess/API/Cocoa/APIAttachmentCocoa.mm: Added.
(API::mimeTypeInferredFromFileExtension):
(API::isDeclaredOrDynamicTypeIdentifier):
(API::Attachment::mimeType const):
(API::Attachment::utiType const):
(API::Attachment::fileName const):
- UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
Add a private delegate hook to notify the UI delegate when a drop has been performed. This is used by tests to
know when a drop with file promises has been processed by the page.
- UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _web_didPerformDragOperation:]):
- UIProcess/API/Cocoa/_WKAttachment.mm:
(-[_WKAttachmentInfo initWithFileWrapper:filePath:mimeType:utiType:]):
(-[_WKAttachmentInfo fileWrapper]):
(-[_WKAttachmentInfo contentType]):
(-[_WKAttachment info]):
(-[_WKAttachmentInfo initWithFileWrapper:filePath:contentType:]): Deleted.
(isDeclaredOrDynamicTypeIdentifier): Deleted.
(-[_WKAttachmentInfo _typeIdentifierFromPathExtension]): Deleted.
(-[_WKAttachmentInfo mimeType]): Deleted.
(-[_WKAttachmentInfo utiType]): Deleted.
Moved to APIAttachmentCocoa.mm.
- UIProcess/API/mac/WKView.mm:
(-[WKView _web_didPerformDragOperation:]):
- UIProcess/Cocoa/WebViewImpl.h:
- UIProcess/Cocoa/WebViewImpl.mm:
(-[WKPromisedAttachmentContext initWithIdentifier:blobURL:fileName:]):
Adjust this constructor to take each piece of data separately. This is because, in the case where our
PromisedAttachmentInfo contains an attachment identifier, we determine the UTI and file name from the associated
file wrapper.
(-[WKPromisedAttachmentContext fileName]):
(WebKit::WebViewImpl::fileNameForFilePromiseProvider):
(WebKit::WebViewImpl::didPerformDragOperation):
(WebKit::WebViewImpl::startDrag):
Determine UTI and file name from the attachment element corresponding to the attachment identifier when
dragging. This is because the attachment element in the web process shouldn't need to have type and title
attributes set when starting a drag if it already has an identifier that maps to attachment data in the UI
process. An example of this is in inline images backed by attachments, for which we don't need to bother keeping
specifying display attributes, since they are never visible.
(-[WKPromisedAttachmentContext initWithAttachmentInfo:]): Deleted.
(-[WKPromisedAttachmentContext filename]): Deleted.
- UIProcess/PageClient.h:
(WebKit::PageClient::didPerformDragOperation):
- UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didPerformDragOperation):
- UIProcess/WebPageProxy.h:
- UIProcess/WebPageProxy.messages.in:
Rename DidPerformDataInteractionControllerOperation to DidPerformDragOperation, and make it cross-platform (this
was previously only sent on iOS). Add plumbing through PageClient and friends on macOS to notify the UI
delegate when a drop is handled by the web process.
- UIProcess/ios/PageClientImplIOS.h:
- UIProcess/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::didPerformDragOperation):
(WebKit::PageClientImpl::didPerformDataInteractionControllerOperation): Deleted.
- UIProcess/ios/WKContentViewInteraction.h:
- UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _didPerformDragOperation:]):
(-[WKContentView _prepareToDragPromisedAttachment:]):
Just like in WebViewImpl::startDrag, infer content type and file name from the API attachment object.
(-[WKContentView _didPerformDataInteractionControllerOperation:]): Deleted.
- UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::didPerformDataInteractionControllerOperation): Deleted.
- UIProcess/mac/PageClientImplMac.h:
- UIProcess/mac/PageClientImplMac.mm:
(WebKit::PageClientImpl::didPerformDragOperation):
- WebKit.xcodeproj/project.pbxproj:
- WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::performDragControllerAction):
Tools:
Rebaseline existing API tests that involve dropping or pasting image files, and additionally write some new
tests. These new tests exercise the following cases:
- Inserting and removing newlines before an inline image with an attachment element does not cause new
_WKAttachments to be created and destroyed.
- Pasting an image, cutting it, and then pasting it again propagates an attachment update to the UI
process with the original _WKAttachment.
- A pasted attachment in the document can be moved around by dragging, and doing so does not cause us to
lose a _WKAttachment.
- TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:
(-[TestWKWebView expectElementCount:tagName:]):
(TestWebKitAPI::TEST):
Add the new tests described above, and also adjust existing tests to check that images are dropped or pasted
as image elements, but still have associated attachment elements whose attachment identifiers (observed via
script) match that of the corresponding _WKAttachment's uniqueIdentifier in the UI process.
- TestWebKitAPI/mac/DragAndDropSimulatorMac.mm:
(-[DragAndDropSimulator runFrom:to:]):
(-[DragAndDropSimulator continueDragSession]):
(-[DragAndDropSimulator performDragInWebView:atLocation:withImage:pasteboard:source:]):
Teach DragAndDropSimulator on macOS to wait until the drop has been handled by the web process before returning
execution to the caller. This ensures that tests which involve dropping promised files as attachments aren't
flaky, due to how the promised data is retrieved asynchronously when performing the drop.
(-[DragAndDropSimulator _webView:didPerformDragOperation:]):
- 6:39 PM Changeset in webkit [235342] by
-
- 6 edits in trunk
[Apple Pay] PaymentRequest.show() should reject when an unsupported ApplePayRequest version is specified
https://bugs.webkit.org/show_bug.cgi?id=188954
Reviewed by Darin Adler.
Source/WebCore:
In Apple Pay JS, calling the ApplePaySession constructor with an unsupported version results
in an exception being thrown. We need to do something similar for Payment Request.
This patch moves the logic for validating the version from ApplePaySession to a common
routine in ApplePayRequestBase that both APIs call to convert requests into a common format.
In Apple Pay JS, an exception will still be thrown when constructing an ApplePaySession. In
Payment Request, the promise returned by show() will be rejected.
Added test cases to http/tests/ssl/applepay/PaymentRequest.https.html.
- Modules/applepay/ApplePayRequestBase.cpp:
(WebCore::convertAndValidate):
- Modules/applepay/ApplePaySession.cpp:
(WebCore::ApplePaySession::create):
LayoutTests:
- http/tests/ssl/applepay/PaymentRequest.https-expected.txt:
- http/tests/ssl/applepay/PaymentRequest.https.html:
- 6:27 PM Changeset in webkit [235341] by
-
- 1 edit9 adds in trunk/LayoutTests
[Apple Pay] Add a test for rendering Apple Pay buttons
https://bugs.webkit.org/show_bug.cgi?id=188947
Reviewed by Sam Weinig.
- http/tests/ssl/applepay/ApplePayButton.html: Added.
- platform/mac-sierra/http/tests/ssl/applepay/ApplePayButton-expected.png: Added.
- platform/mac-sierra/http/tests/ssl/applepay/ApplePayButton-expected.txt: Added.
- platform/mac/http/tests/ssl/applepay/ApplePayButton-expected.png: Added.
- platform/mac/http/tests/ssl/applepay/ApplePayButton-expected.txt: Added.
- 6:00 PM Changeset in webkit [235340] by
-
- 2 edits in trunk/Source/WebKitLegacy
[Xcode] Don’t make unnecessary, broken WebKitPluginAgent symlink when WK_USE_OVERRIDE_FRAMEWORKS_DIR=YES
https://bugs.webkit.org/show_bug.cgi?id=188956
<rdar://problem/43253221>
Reviewed by Darin Adler.
- WebKitLegacy.xcodeproj/project.pbxproj: Updated the Symlink WebKitPluginHost build phase.
- 5:48 PM Changeset in webkit [235339] by
-
- 1 edit in trunk/Tools/ChangeLog
Open for business.