This is a basic adaption of the current WebKit to make use of
BUrlSession. It's done enough for HaikuLauncher to compile, however I've
not managed to throughly test it due as my VM died.
Main changes in this commit:
- BUrlProtocolHandler is splitted into two classes:
- BUrlProtocolHandler for managing the request lifetime.
- BUrlRequestWrapper for handling events from requests spawned by
BUrlProtocolHandler.
The separation allow the events handling code to be greatly
simplified, and code for handling events and managing request
are now properly separated.
In the future this enables BUrlProtocolHandler to be the
synchronization/serialization point, allowing BUrlRequestWrapper to
interface with BUrlRequest directly instead of going through
BUrlProtocolAsynchronousRequest, which should allow for better
performance.
- Redirection and authentication are now handled manually by the backend
instead of delegating to BUrlRequest.
- Code style has been adjusted to match WebKit official style guideline.
Fix the build with IOS_TOUCH_EVENTS enabled.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::handleTouchEvent): Deleted.
(WebCore::RenderLayer::registerAsTouchEventListenerForScrolling): Deleted.
(WebCore::RenderLayer::unregisterAsTouchEventListenerForScrolling): Deleted.
Remove a few undeclared method definitions. These methods were relocated to `RenderLayerScrollableArea`.
* rendering/RenderLayerScrollableArea.cpp:
Remove several methods that have duplicate implementations.
Canonical link: https://commits.webkit.org/233100@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271564 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220615
Reviewed by Don Olmstead.
non-Cocoa ports auxiliary processes are using AuxiliaryProcessMain
as the entry points. AuxiliaryProcessMain supports both kinds of
auxiliary processes with and without singleton() method by using
initializeAuxiliaryProcess template function. However, all
initializeAuxiliaryProcess look similar code. They can share more
code.
Added a AuxiliaryProcessMainBaseNoSingleton template class for
auxiliary processes without singleton().
Moved the code that was in AuxiliaryProcessMain to
AuxiliaryProcessMainBase::run() to remove
takeInitializationParameters().
* GPUProcess/gstreamer/GPUProcessMainGStreamer.cpp:
(WebKit::GPUProcessMain):
(WebKit::initializeAuxiliaryProcess<GPUProcess>): Deleted.
* GPUProcess/playstation/GPUProcessMainPlayStation.cpp:
(WebKit::GPUProcessMain):
(WebKit::initializeAuxiliaryProcess<GPUProcess>): Deleted.
* GPUProcess/win/GPUProcessMainWin.cpp:
(WebKit::GPUProcessMain):
(WebKit::initializeAuxiliaryProcess<GPUProcess>): Deleted.
* NetworkProcess/curl/NetworkProcessMainCurl.cpp:
(WebKit::NetworkProcessMain):
(WebKit::initializeAuxiliaryProcess<NetworkProcess>): Deleted.
* NetworkProcess/soup/NetworkProcessMainSoup.cpp:
(WebKit::NetworkProcessMain):
(WebKit::initializeAuxiliaryProcess<NetworkProcess>): Deleted.
* Shared/AuxiliaryProcessMain.h:
(WebKit::AuxiliaryProcessMainBase::platformInitialize):
(WebKit::AuxiliaryProcessMainBase::platformFinalize):
(WebKit::AuxiliaryProcessMainBase::initializeAuxiliaryProcess):
(WebKit::AuxiliaryProcessMainBase::run):
(WebKit::AuxiliaryProcessMainBaseNoSingleton::process):
(WebKit::AuxiliaryProcessMain):
(WebKit::AuxiliaryProcessMainBase::initializationParameters): Deleted.
(WebKit::AuxiliaryProcessMainBase::takeInitializationParameters): Deleted.
(WebKit::initializeAuxiliaryProcess): Deleted.
* Shared/unix/AuxiliaryProcessMain.cpp:
(WebKit::AuxiliaryProcessMainCommon::parseCommandLine):
(WebKit::AuxiliaryProcessMainBase::parseCommandLine): Deleted.
* Shared/win/AuxiliaryProcessMainWin.cpp:
(WebKit::AuxiliaryProcessMainCommon::parseCommandLine):
(WebKit::AuxiliaryProcessMainBase::parseCommandLine): Deleted.
* WebProcess/gtk/WebProcessMainGtk.cpp:
(WebKit::WebProcessMain):
* WebProcess/playstation/WebProcessMainPlayStation.cpp:
(WebKit::WebProcessMain):
* WebProcess/win/WebProcessMainWin.cpp:
(WebKit::WebProcessMain):
* WebProcess/wpe/WebProcessMainWPE.cpp:
(WebKit::WebProcessMain):
Canonical link: https://commits.webkit.org/233099@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271563 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220228
Reviewed by Antti Koivisto.
Now that isConsideredEmpty() bit is only used as input to line breaking, let's change it to a more
focused check and remove the concept of "is considered empty" completely.
* layout/inlineformatting/InlineContentBreaker.cpp:
(WebCore::Layout::InlineContentBreaker::processInlineContent):
(WebCore::Layout::InlineContentBreaker::processOverflowingContent const):
* layout/inlineformatting/InlineContentBreaker.h:
* layout/inlineformatting/InlineLine.cpp:
(WebCore::Layout::Line::initialize):
(WebCore::Layout::Line::removeTrailingTrimmableContent):
(WebCore::Layout::Line::append):
(WebCore::Layout::Line::appendTextContent):
* layout/inlineformatting/InlineLine.h:
(WebCore::Layout::Line::isConsideredEmpty const): Deleted.
* layout/inlineformatting/InlineLineBuilder.cpp:
(WebCore::Layout::LineBuilder::close):
(WebCore::Layout::LineBuilder::handleInlineContent):
Canonical link: https://commits.webkit.org/233098@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271562 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220641
Reviewed by Mark Lam.
Source/JavaScriptCore:
Add JSConfigureSignalForGC function for Linux and FreeBSD (non Apple, non Windows platforms).
* API/JSBase.cpp:
(JSConfigureSignalForGC):
* API/JSBasePrivate.h:
Source/WTF:
In Linux and FreeBSD, we need to use signals to suspend and resume threads.
By default, we are using SIGUSR1, but it is possible that some embedders want to use
the other signals since they are using SIGUSR1 already. To work-around that, this
patch offers the way for embedders to configure signals.
* wtf/Threading.h:
* wtf/WTFConfig.h:
* wtf/posix/ThreadingPOSIX.cpp:
(WTF::Thread::signalHandlerSuspendResume):
(WTF::Thread::initializePlatformThreading):
(WTF::Thread::initializeCurrentThreadEvenIfNonWTFCreated):
(WTF::Thread::initializeCurrentTLS):
(WTF::Thread::suspend):
(WTF::Thread::resume):
* wtf/threads/Signals.cpp:
(WTF::addSignalHandler):
* wtf/win/ThreadingWin.cpp:
(WTF::Thread::initializeCurrentTLS):
Canonical link: https://commits.webkit.org/233096@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271560 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220259
Reviewed by Antti Koivisto.
1. Inline box always have a strut in standards mode and it stretches the line box even when the inline box itself has no content.
<!DOCTYPE html><div>this is a ~100px tall line<span style="font-size: 100px;"></span></div>
2. except when the line is completely empty (the inline box still has a strut but it does not affect the line box).
<!DOCTYPE html><div><span style="font-size: 100px;"></span><span style="font-size: 200px;"></span></div>
3. but not empty like this:
<!DOCTYPE html><div><span style="font-size: 100px;"></span><br></div>
4. or this:
<!DOCTYPE html><div><span style="font-size: 100px;"></span><img src="foo" style="width: 0px; height: 0px;"></div>
While #2 produces a 0px tall line box, #1, #3 and #4 produce ~100px tall lines.
This change also enables us to remove LineBox:isConsideredEmpty().
* layout/inlineformatting/InlineFormattingContext.h:
* layout/inlineformatting/InlineFormattingContextGeometry.cpp:
(WebCore::Layout::LineBoxBuilder::build):
(WebCore::Layout::LineBoxBuilder::computeLineBoxHeightAndAlignInlineLevelBoxesVertically):
* layout/inlineformatting/InlineFormattingContextQuirks.cpp:
(WebCore::Layout::InlineFormattingContext::Quirks::inlineLevelBoxAffectsLineBox const):
* layout/inlineformatting/InlineLineBox.cpp:
(WebCore::Layout::LineBox::LineBox):
(WebCore::Layout::m_isConsideredEmpty): Deleted.
* layout/inlineformatting/InlineLineBox.h:
(WebCore::Layout::LineBox::horizontalAlignmentOffset const):
(WebCore::Layout::LineBox::isConsideredEmpty const): Deleted.
* layout/inlineformatting/InlineLineBuilder.cpp:
(WebCore::Layout::LineBuilder::layoutInlineContent):
* layout/inlineformatting/InlineLineBuilder.h:
Canonical link: https://commits.webkit.org/233094@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271555 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Support transferred min/max block size for aspect-ratio
Patch by Rob Buis <rbuis@igalia.com> on 2021-01-15
Reviewed by Darin Adler.
Source/WebCore:
Add logic to transfer min-height/max-height for minmax logical width
calculation in case aspect-ratio should be applied [1]. Both absolute
and normally positioned elements are handled.
[1] https://drafts.csswg.org/css-sizing-4/#aspect-ratio-size-transfers
* rendering/RenderBox.cpp:
(WebCore::RenderBox::constrainLogicalWidthInFragmentByMinMax const):
(WebCore::RenderBox::computePositionedLogicalWidth const):
(WebCore::RenderBox::computeMinMaxLogicalWidthFromAspectRatio const):
* rendering/RenderBox.h:
LayoutTests:
Enable some tests that pass now.
* TestExpectations:
Canonical link: https://commits.webkit.org/233093@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271554 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220676
Reviewed by Tim Horton.
When homing out on iOS, UIKit snapshotting causes multiple web view resizes, which runs
the dynamicViewportSizeUpdate() logic. This can trigger programmatic scrolls via
FrameView::setContentsSize(), which get stored in the scrolling state tree. When
that tree is committed on resume, we then erroneously apply the programmatic
scrolls.
Fix by ignoring requested scroll positions updates when snapshotting, as we do when
we're in the page cache.
* page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::requestScrollPositionUpdate):
Canonical link: https://commits.webkit.org/233090@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271551 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220664
<rdar://problem/68400471>
Reviewed by Devin Rousso.
Source/WebKit:
After iOS 14, the emoji software keyboard layout now includes a search field that can be used to filter for
specific emojis. This slightly increases the overall height of the software keyboard when the emoji keyplane is
active; in turn, this means that if the selection or caret is positioned right above the top of the software
keyboard when the normal (alphabetic) keyplane is active, switching to the emoji keyplane will cause the
keyboard to overlap the selection, making it difficult to see inserted text.
To address this, add a mechanism to detect when a change in the bounds of the software keyboard causes a visible
selection or caret rect to become overlapped, and react by scrolling to keep the selection visible. This has the
effect of fixing this bug by scrolling to reveal the text field after switching to the emoji keyboard, but it
also has the effect of scrolling to keep the selection visible after detaching a connected hardware keyboard,
in the case where it would've otherwise been overlapped by the (much taller) software keyboard that appears.
Test: editing/selection/ios/scroll-to-reveal-selection-when-showing-software-keyboard.html
* UIProcess/API/ios/WKWebViewIOS.h:
* UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _selectionRectIsFullyVisibleAndNonEmpty]):
Add an internal helper to check whether the selection bounds are fully visible.
(-[WKWebView _scrollToRevealSelectionIfNeeded]):
(-[WKWebView _zoomToFocusRect:selectionRect:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]):
(-[WKWebView _keyboardChangedWithInfo:adjustScrollView:]):
In the case where changing input view bounds causes a previously visible selection to become overlapped, call
`-_scrollToRevealSelectionIfNeeded` to make the selection visible again.
(-[WKWebView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]): Deleted.
* UIProcess/WebPageProxy.h:
* UIProcess/ios/WKContentView.h:
* UIProcess/ios/WKContentView.mm:
(-[WKContentView _zoomToFocusRect:selectionRect:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]):
(-[WKContentView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]): Deleted.
Drive-by fix: remove the unused `insideFixed:` parameter from this adjacent method.
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView rectToRevealWhenZoomingToFocusedElement]):
(-[WKContentView _zoomToRevealFocusedElement]):
(rectToRevealWhenZoomingToFocusedElement): Deleted.
Pull this into the `-rectToRevealWhenZoomingToFocusedElement` internal helper method instead, and use the new
`selectionBoundingRectInRootViewCoordinates` method below.
* UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::selectionBoundingRectInRootViewCoordinates const):
Pull out code to compute the selection bounding rect (for both ranged and caret selections) into a method on
`WebPageProxy`, so that it can be used in `WKContentView` and `WKWebView`.
LayoutTests:
Add a test to verify that after disconnecting a hardware keyboard and showing the software keyboard, we scroll
up to reveal the caret in a focused text field.
* editing/selection/ios/scroll-to-reveal-selection-when-showing-software-keyboard-expected.txt: Added.
* editing/selection/ios/scroll-to-reveal-selection-when-showing-software-keyboard.html: Added.
Canonical link: https://commits.webkit.org/233086@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271543 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220669
Reviewed by Jer Noble.
Add a quirk to disable the "webkitendfullscreen" event when a video enters picture-in-picture
from fullscreen for the sites which cannot handle the event properly.
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::enterFullscreen):
* page/Quirks.cpp:
(WebCore::Quirks::shouldDisableEndFullscreenEventWhenEnteringPictureInPictureFromFullscreenQuirk const):
* page/Quirks.h:
Canonical link: https://commits.webkit.org/233085@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271542 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220666
<rdar://problem/72940505>
Patch by Alex Christensen <achristensen@webkit.org> on 2021-01-15
Reviewed by Geoffrey Garen.
r267763 removed indexedDatabaseTempBlobDirectoryExtensionHandle with no replacement, which used to give the network process
read/write access to /tmp inside the parent process's container. This seems to have been unused for IndexedDB, but it was used
by createTemporaryZipArchive when uploading directories, such as Pages, Numbers, and Keynote documents.
Unfortunately the unit test added by r248139 is macOS-only because WKOpenPanelParameters is only available on macOS and it would
require a large and risky amount of refactoring to add SPI on iOS to test this because iOS uses WKFileUploadPanel instead.
I did manually verify that the bug is fixed using my phone, though.
* NetworkProcess/NetworkProcessCreationParameters.cpp:
(WebKit::NetworkProcessCreationParameters::encode const):
(WebKit::NetworkProcessCreationParameters::decode):
* NetworkProcess/NetworkProcessCreationParameters.h:
* NetworkProcess/cocoa/NetworkProcessCocoa.mm:
(WebKit::NetworkProcess::platformInitializeNetworkProcessCocoa):
* UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::sendCreationParametersToNewProcess):
Canonical link: https://commits.webkit.org/233083@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271537 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220626
<rdar://problem/73228924>
Reviewed by Zalan Bujtas.
Source/WebCore:
keyCode is still expected to be filled in with standard codes for arrow keys.
Updated test: accessibility/keyevents-posted-for-increment-actions.html
* accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::postKeyboardKeysForValueChange):
LayoutTests:
* accessibility/keyevents-posted-for-increment-actions-expected.txt:
* accessibility/keyevents-posted-for-increment-actions.html:
Canonical link: https://commits.webkit.org/233082@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271536 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220476
Reviewed by Simon Fraser.
Source/WebCore:
Make some caches thread-safe now that we do rendering off the main thread in
the GPUProcess.
No new tests, covered by existing tests.
* platform/graphics/ImageBuffer.h:
* platform/graphics/MediaPlayer.h:
* platform/graphics/ShadowBlur.cpp:
(WebCore::ScratchBuffer::ScratchBuffer):
(WebCore::ScratchBuffer::getScratchBuffer):
(WebCore::ScratchBuffer::setCachedShadowValues):
(WebCore::ScratchBuffer::setCachedInsetShadowValues):
(WebCore::ScratchBuffer::scheduleScratchBufferPurge):
(WebCore::ScratchBuffer::purgeTimerFired):
(WebCore::ScratchBuffer::clearScratchBuffer):
(WebCore::ScratchBuffer::singleton):
(WebCore::ScratchBuffer::lock):
(WebCore::ShadowBlur::drawRectShadowWithTiling):
(WebCore::ShadowBlur::drawInsetShadowWithTiling):
* platform/graphics/cg/ImageBufferUtilitiesCG.cpp:
(WebCore::utiFromImageBufferMIMEType):
* platform/graphics/cg/SubimageCacheWithTimer.cpp:
(WebCore::SubimageCacheWithTimer::SubimageCacheWithTimer):
(WebCore::SubimageCacheWithTimer::pruneCacheTimerFired):
(WebCore::SubimageCacheWithTimer::subimage):
(WebCore::SubimageCacheWithTimer::clearImageAndSubimages):
(WebCore::SubimageCacheWithTimer::clearAll):
(WebCore::SubimageCacheWithTimer::subimageCache):
* platform/graphics/cg/SubimageCacheWithTimer.h:
* platform/network/mac/UTIUtilities.mm:
(WebCore::UTIFromUnknownMIMEType):
(WebCore::UTIFromMIMETypeCachePolicy::createValueForKey):
(WebCore::UTIFromMIMETypeCachePolicy::createKeyForStorage):
(WebCore::cacheUTIFromMimeType):
(WebCore::UTIFromMIMEType):
* platform/text/cf/HyphenationCF.cpp:
* platform/text/hyphen/HyphenationLibHyphen.cpp:
https://bugs.webkit.org/show_bug.cgi?id=220476
Source/WebKit:
Move DOM / Canvas rendering off the main thread (and on a high-priority serial WorkQueue) in the
GPUProcess by making RemoteRenderingBackend a WorkQueueMessageReceiver. There is a serial WorkQueue
per RemoteRenderingBackend, which means each WebPage gets its own WorkQueue.
A/B testing shows this mostly perf-neutral (could be a slight progression on some hardware). I believe
this new architecture should also give us more optimization opportunities in the future. For example,
we may be able to more aggressively wait on the cross-process semaphore when waiting for new DisplayList
entries without worrying about blocking the main thread.
I have run layout tests in Debug on both macOS & iOS with the GPUProcess enabled and I believe I
have fixed all the crashes that were discovered.
* GPUProcess/GPUConnectionToWebProcess.cpp:
(WebKit::GPUConnectionToWebProcess::GPUConnectionToWebProcess):
(WebKit::GPUConnectionToWebProcess::didClose):
(WebKit::GPUConnectionToWebProcess::createRenderingBackend):
(WebKit::GPUConnectionToWebProcess::RemoteRenderingBackendWrapper::RemoteRenderingBackendWrapper):
(WebKit::GPUConnectionToWebProcess::RemoteRenderingBackendWrapper::~RemoteRenderingBackendWrapper):
* GPUProcess/GPUConnectionToWebProcess.h:
(WebKit::GPUConnectionToWebProcess::remoteMediaPlayerManagerProxy):
* GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::RemoteRenderingBackend::create):
(WebKit::RemoteRenderingBackend::RemoteRenderingBackend):
(WebKit::RemoteRenderingBackend::~RemoteRenderingBackend):
(WebKit::RemoteRenderingBackend::disconnect):
(WebKit::RemoteRenderingBackend::messageSenderConnection const):
(WebKit::RemoteRenderingBackend::applyMediaItem):
(WebKit::RemoteRenderingBackend::createImageBuffer):
(WebKit::RemoteRenderingBackend::wakeUpAndApplyDisplayList):
(WebKit::RemoteRenderingBackend::getImageData):
(WebKit::RemoteRenderingBackend::getDataURLForImageBuffer):
(WebKit::RemoteRenderingBackend::getDataForImageBuffer):
(WebKit::RemoteRenderingBackend::getBGRADataForImageBuffer):
(WebKit::RemoteRenderingBackend::cacheNativeImage):
(WebKit::RemoteRenderingBackend::cacheFont):
(WebKit::RemoteRenderingBackend::deleteAllFonts):
(WebKit::RemoteRenderingBackend::releaseRemoteResource):
(WebKit::RemoteRenderingBackend::didCreateSharedDisplayListHandle):
* GPUProcess/graphics/RemoteRenderingBackend.h:
* GPUProcess/graphics/RemoteRenderingBackend.messages.in:
* GPUProcess/media/RemoteLegacyCDMProxy.cpp:
(WebKit::RemoteLegacyCDMProxy::cdmMediaPlayer const):
* GPUProcess/media/RemoteMediaPlayerManagerProxy.cpp:
(WebKit::RemoteMediaPlayerManagerProxy::createMediaPlayer):
(WebKit::RemoteMediaPlayerManagerProxy::deleteMediaPlayer):
(WebKit::RemoteMediaPlayerManagerProxy::didReceivePlayerMessage):
(WebKit::RemoteMediaPlayerManagerProxy::didReceiveSyncPlayerMessage):
(WebKit::RemoteMediaPlayerManagerProxy::mediaPlayer):
* GPUProcess/media/RemoteMediaPlayerManagerProxy.h:
* Platform/SharedMemory.h:
* Shared/ShareableBitmap.cpp:
(WebKit::ShareableBitmap::ShareableBitmap):
(WebKit::ShareableBitmap::~ShareableBitmap):
* Shared/ShareableBitmap.h:
* Shared/cg/ShareableBitmapCG.cpp:
(WebKit::ShareableBitmap::createGraphicsContext):
(WebKit::ShareableBitmap::releaseBitmapContextData):
(WebKit::ShareableBitmap::releaseDataProviderData):
Source/WTF:
Add trait function that gets called TinyLRUCache to convert the key before storing
it. It is useful for clients that need to call isolatedCopy() on the key String before
storing it.
* wtf/TinyLRUCache.h:
(WTF::TinyLRUCachePolicy::createKeyForStorage):
(WTF::TinyLRUCache::get):
Canonical link: https://commits.webkit.org/233081@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271533 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220646
<rdar://72950166>
Reviewed by Xabier Rodriguez-Calvar.
Source/WebCore:
Test: media/media-play-promise-reject-play-notallowed-audio.html
When audio playback is blocked by settings, the HTMLMediaElement must load its source
media's metadata in order to determine whether the media should be allowed to play without a
user gesture. If a play promise is pending, the expectation is that those promises will
reject with a NotAllowedError to indicate that a user gesture is needed. However, by calling
pauseInternal() to block (possibly) existing playback, this causes those promises to be
rejected with an AbortError, as if the pause() method had been called. Call
scheduleRejectPendingPlayPromises() with NotAllowedError to ensure the correct error is used
to reject.
Drive-by fix: no reason to dispatch and call rejectPendingPlayPromises() or
resolvePendingPlayPromises() if there are no promises to reject or resolve, and not calling
these methods makes the logs less noisy.
* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::scheduleResolvePendingPlayPromises):
(WebCore::HTMLMediaElement::scheduleRejectPendingPlayPromises):
(WebCore::HTMLMediaElement::setVolume):
(WebCore::HTMLMediaElement::mediaPlayerDidAddAudioTrack):
(WebCore::HTMLMediaElement::mediaPlayerCharacteristicChanged):
(WebCore::HTMLMediaElement::updateShouldPlay):
LayoutTests:
* media/media-play-promise-reject-play-notallowed-audio-expected.txt: Added.
* media/media-play-promise-reject-play-notallowed-audio.html: Added.
Canonical link: https://commits.webkit.org/233079@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271531 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220647
<rdar://73173684>
Reviewed by Darin Adler.
In exceptional circumstances, the MediaPlayerPrivateMediaSourceAVFObjC can be destroyed before
MediaSourcePrivateAVFObjC, which leaves behind a null WeakPtr. Null check m_player before
using everywhere in MediaSourcePrivateAVFObjC.
Drive-by fix: it would be invalid to pass in a null player to MediaSourcePrivateAVFObjC::create(),
so modify that method to take a reference rather than a pointer.
* platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::load):
* platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.h:
* platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.mm:
(WebCore::MediaSourcePrivateAVFObjC::create):
(WebCore::MediaSourcePrivateAVFObjC::MediaSourcePrivateAVFObjC):
(WebCore::MediaSourcePrivateAVFObjC::removeSourceBuffer):
(WebCore::MediaSourcePrivateAVFObjC::durationChanged):
(WebCore::MediaSourcePrivateAVFObjC::markEndOfStream):
(WebCore::MediaSourcePrivateAVFObjC::readyState const):
(WebCore::MediaSourcePrivateAVFObjC::setReadyState):
(WebCore::MediaSourcePrivateAVFObjC::waitForSeekCompleted):
(WebCore::MediaSourcePrivateAVFObjC::seekCompleted):
(WebCore::MediaSourcePrivateAVFObjC::currentMediaTime const):
(WebCore::MediaSourcePrivateAVFObjC::sourceBufferPrivateDidChangeActiveState):
(WebCore::MediaSourcePrivateAVFObjC::sourceBufferKeyNeeded):
(WebCore::MediaSourcePrivateAVFObjC::setSourceBufferWithSelectedVideo):
Canonical link: https://commits.webkit.org/233078@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271530 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220604
Patch by Alex Christensen <achristensen@webkit.org> on 2021-01-15
Reviewed by Anders Carlsson.
Once rdar://problem/73167624 has been integrated, we can remove the old SPI, which has been replaced in r263099
* UIProcess/API/Cocoa/WKBrowsingContextGroup.h:
* UIProcess/API/Cocoa/WKBrowsingContextGroup.mm:
(-[WKBrowsingContextGroup addUserStyleSheet:baseURL:whitelistedURLPatterns:blacklistedURLPatterns:mainFrameOnly:]): Deleted.
(-[WKBrowsingContextGroup addUserScript:baseURL:whitelistedURLPatterns:blacklistedURLPatterns:injectionTime:mainFrameOnly:]): Deleted.
Canonical link: https://commits.webkit.org/233077@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271529 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=219997
Reviewed by Devin Rousso.
Adjust the width of the title in each row to 105px, which provides space for both `Historical Figures` which is
an always-present row and `Optical Size (opsz)` which is a registed variation axis and is used in numerous
fonts including San Francisco. This overrides the normal fixed width of these titles of 85px, which causes these
and numerous other unregistered axis names and tags to wrap their title more aggresively than is stricly
necessary.
* UserInterface/Views/FontDetailsPanel.css:
(.sidebar > .panel.details.style-font > .content .details-section > .content > .group > .row.simple > .label):
Canonical link: https://commits.webkit.org/233076@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271528 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220659
Reviewed by Simon Fraser.
Improve the GPUProcess' memory pressure handler to clear things like the IOSurfacePool
and the SubimageCacheWithTimer.
Source/WebCore:
* page/MemoryRelease.cpp:
(WebCore::releaseGraphicsMemory):
(WebCore::platformReleaseGraphicsMemory):
* page/MemoryRelease.h:
* page/cocoa/MemoryReleaseCocoa.mm:
(WebCore::platformReleaseGraphicsMemory):
Source/WebKit:
* GPUProcess/GPUProcess.cpp:
(WebKit::GPUProcess::lowMemoryHandler):
(WebKit::GPUProcess::initializeGPUProcess):
(WebKit::GPUProcess::prepareToSuspend):
* GPUProcess/GPUProcess.h:
Canonical link: https://commits.webkit.org/233075@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271526 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=218655
<rdar://problem/71116284>
Reviewed by Simon Fraser.
Source/WebCore:
Tests: webanimations/combining-transform-animations-with-different-acceleration-capabilities-2.html
webanimations/combining-transform-animations-with-different-acceleration-capabilities-3.html
webanimations/combining-transform-animations-with-different-acceleration-capabilities.html
While, in theory, animations for a transform-related CSS property (translate, rotate, scale and transform)
can be accelerated, there are various reasons why it might not, in fact, run accelerated.
One example is that the timing function is not something we can translate in terms Core Animation can
understand, such as the steps() timing function. In this case, the KeyframeEffect itself is aware of
the limitation and the method KeyframeEffect::canBeAccelerated() returns false.
Another example is that the playback rate of the animation is not 1, which we currently don't support for
Core Animation animations (see bug 211839). In this case, GraphicsLayerCA is where the impossibility to
run an animation accelerated is determined.
While we support running transform-related animations with or without acceleration, one thing we cannot
support is, for the same element, running some transform-related animations with acceleration, and some
without.
Thus, regardless of where we determine that a transform-related animation cannot be accelerated, we need
to send this information up to the KeyframeEffectStack in which this animation's effect belongs to make
sure that any other transform-related animation that may already be running accelerated no longer does
and continues running without acceleration.
There are two locations where we determine that a transform-related animation cannot be accelerated:
1. in DocumentTimeline::applyPendingAcceleratedAnimations() under which we start, update or stop
accelerated animations that have been invalidated since the last page rendering,
2. in KeyframeEffect::updateAcceleratedActions() which is called for each page rendering, including
animations that cannot be accelerated.
In the first case, we catch situations where an animation that could have been accelerated but failed
to be started due to the internal logic of GraphicsLayerCA. We use the new KeyframeEffect method
applyPendingAcceleratedActions() return value to determine this, and for each effect where the result
indicates that a transform-related animation could not be accelerated, we add the KeyframeEffectStack
to which it belongs and, once we're done with updating all effects, call the new
stopAcceleratingTransformRelatedProperties() method on the keyframe effect stack.
In the second case, we catch situations where an animation is known to not be able to run accelerated
even without involving GraphicsLayerCA. We check whether the animation targets a transform-related
property and if it is active, and if so call stopAcceleratingTransformRelatedProperties()
on the keyframe effect stack there as well.
When KeyframeEffectStack::stopAcceleratingTransformRelatedProperties() is called, we go
through all the registered effects and call stopAcceleratingTransformRelatedProperties(). This new
KeyframeEffect method will either add a pending accelerated action to stop the accelerated animation,
or if we're currently apply accelerated actions (ie. during DocumentTimeline::applyPendingAcceleratedAnimations()),
we stop the accelerated animation right away.
In both cases we know not to try running this animation again with acceleration by setting m_runningAccelerated
to RunningAccelerated::No.
* animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::applyPendingAcceleratedAnimations):
* animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::isTargetingTransformRelatedProperty const):
(WebCore::KeyframeEffect::isRunningAcceleratedTransformRelatedAnimation const):
(WebCore::KeyframeEffect::updateAcceleratedActions):
(WebCore::KeyframeEffect::applyPendingAcceleratedActions):
(WebCore::KeyframeEffect::stopAcceleratingTransformRelatedProperties):
* animation/KeyframeEffect.h:
* animation/KeyframeEffectStack.cpp:
(WebCore::KeyframeEffectStack::stopAcceleratingTransformRelatedProperties):
* animation/KeyframeEffectStack.h:
* animation/WebAnimation.cpp:
(WebCore::WebAnimation::applyPendingAcceleratedActions): Deleted.
* animation/WebAnimation.h:
* animation/WebAnimationTypes.h:
LayoutTests:
Add new tests that start a transform-related animation that runs accelerated, then add another
transform-related animation that either initially or eventually is not accelerated. In all cases,
we check that once the second animation is no longer accelerated that the first animation is also
no longer accelerated.
* platform/win/TestExpectations:
* webanimations/combining-transform-animations-with-different-acceleration-capabilities-2-expected.txt: Added.
* webanimations/combining-transform-animations-with-different-acceleration-capabilities-2.html: Added.
* webanimations/combining-transform-animations-with-different-acceleration-capabilities-3-expected.txt: Added.
* webanimations/combining-transform-animations-with-different-acceleration-capabilities-3.html: Added.
* webanimations/combining-transform-animations-with-different-acceleration-capabilities-expected.txt: Added.
* webanimations/combining-transform-animations-with-different-acceleration-capabilities.html: Added.
Canonical link: https://commits.webkit.org/233074@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271524 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220648
Reviewed by Antti Koivisto.
Source/WebCore:
When non-integer tabindex is specified, the element should behave the same way as the tabindex is omitted.
https://html.spec.whatwg.org/multipage/interaction.html#attr-tabindex
WebKit didn't overwrite the internal tabindex value when the new value is non-integer.
Test: LayoutTests\fast\html\tabindex-overwrite-with-non-integer.html
* html/HTMLElement.cpp:
(WebCore::HTMLElement::parseAttribute): If the new value cannot be parsed as the integer, clear the existing tabindex.
LayoutTests:
Add LayoutTest case for tabindex which is overwritten by non-integers.
When non-integer tabindex is specified, the element should behave the same way as the tabindex is omitted.
https://html.spec.whatwg.org/multipage/interaction.html#attr-tabindex
* fast/html/tabindex-overwrite-with-non-integer-expected.txt: Added.
* fast/html/tabindex-overwrite-with-non-integer.html: Added.
Canonical link: https://commits.webkit.org/233073@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220237
Reviewed by Adrian Perez de Castro.
This patch updates several SDK components:
- GStreamer 1.18.0 -> 1.18.2
- Mesa 20.1.10 -> 20.3.2
Additionally some libdrm-related cleanups are included, since we have our own version of
this component, it is better to use it everywhere instead of the upstream SDK version, to
avoid collisions.
This patch also updates the pipenv dependencies used by Buildstream.
* Pipfile.lock:
* elements/freedesktop-sdk.bst:
* elements/qt5/qtbase.bst:
* elements/qt5/qtwayland.bst:
* elements/sdk/gst-libav.bst:
* elements/sdk/gst-plugins-bad.bst:
* elements/sdk/gst-plugins-base.bst:
* elements/sdk/gst-plugins-good.bst:
* elements/sdk/gst-plugins-ugly.bst:
* elements/sdk/gstreamer.bst:
* elements/sdk/mesa.bst:
* elements/sdk/xorg-server.bst:
* patches/mesa/0004-mesa-clear-texture-s-views-when-texture-is-remove.patch: Removed.
* patches/mesa/mesa_libdrm_deps.patch:
Canonical link: https://commits.webkit.org/233069@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271519 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220418
Reviewed by Adrian Perez de Castro.
This patch:
- bumps from Meson 0.55.3 to Meson 0.56.1 in the FDO junction
- includes cargo-c in the SDK, this is a new dependency for gst-build (only if
gst-plugins-rs is enabled though)
- includes the latest release of the rsclosedcaption GStreamer plugin in the SDK. This
plugin includes several elements (ccconverter, cea608tott) that will be useful in order to
support CEA608 rendering in WebKit GStreamer ports.
* elements/freedesktop-sdk.bst:
* elements/sdk-platform.bst:
* elements/sdk/cargo-c.bst: Added.
* elements/sdk/gst-plugin-closedcaption.bst: Added.
* files/gst-plugin-closedcaption/Cargo.lock: Added.
* patches/fdo-0001-meson-Bump-to-0.56.1.patch: Added.
Canonical link: https://commits.webkit.org/233068@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271518 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220651
Reviewed by Xabier Rodriguez-Calvar.
Source/WebCore:
The GStreamer sink used to collect WebVTT cues is now more self-contained and uses the
player only to hand-off samples to the corresponding TextTrack implementation for further
processing. This is only a refactoring, existing tests in media/track cover this change.
* platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::handleTextSample):
(WebCore::MediaPlayerPrivateGStreamer::createGSTPlayBin):
* platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
* platform/graphics/gstreamer/TextSinkGStreamer.cpp:
(webkitTextSinkHandleSample):
(webkitTextSinkConstructed):
(webkitTextSinkQuery):
(webkit_text_sink_class_init):
(webkitTextSinkNew):
* platform/graphics/gstreamer/TextSinkGStreamer.h:
Tools:
* Scripts/webkitpy/style/checker.py: Add GStreamer TextSink implementation to GObject
classes allow-list.
Canonical link: https://commits.webkit.org/233067@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271517 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220638
<rdar://problem/73175259>
Reviewed by Simon Fraser.
Source/WebCore:
This patch fixes incorrect hittest results when the hittest target
1. participates in the modern line layout and
2. prior to the hittesting its style changes in a way that it does not trigger layout.
e.g.
<div><div id=inner style="display: inline-block; visibility: hidden"><div></div>
<script>inner.style.visibility = "visible"</script>
Any subsequent hittest will miss the inner <div> as the loop in LineLayout::hitTest() early returns due to stale style information.
The reason why we end up with stale style is because we only update the layout box's style when the style diff >= StyleDifference::Layout () in RenderBox::styleDidChange.
Test: fast/inline-block/hittest-fails-on-inline-block-with-visibility-change.html
* rendering/RenderBox.cpp:
(WebCore::RenderBox::styleDidChange):
LayoutTests:
* fast/inline-block/hittest-fails-on-inline-block-with-visibility-change-expected.txt: Added.
* fast/inline-block/hittest-fails-on-inline-block-with-visibility-change.html: Added.
Canonical link: https://commits.webkit.org/233066@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271516 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220652
<rdar://problem/71517335>
Reviewed by Antti Koivisto.
In r269813 we added support for animating more pseudo-elements besides ::after and ::before. However, the only other
pseudo-element we realistically should be supporting animations for at this juncture is ::marker. So instead of
calling Style::TreeResolver::resolvePseudoStyle() for all public pseudo-elements, we call it for ::after, ::before
and ::marker alone.
* style/StyleTreeResolver.cpp:
(WebCore::Style::TreeResolver::resolveElement):
Canonical link: https://commits.webkit.org/233065@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=218496
Patch by Rob Buis <rbuis@igalia.com> on 2021-01-15
Reviewed by Ryosuke Niwa.
Source/WebCore:
Use event loop to set title to avoid calling WebFrameLoaderClient
within HTMLTitleElement::insertedIntoAncestor.
* dom/Document.cpp:
(WebCore::Document::updateTitle):
* dom/Document.h:
Tools:
Adapt unit tests to wait for title change tasks
to be processed.
* TestWebKitAPI/Tests/WebKit/PageLoadState.cpp:
(TestWebKitAPI::didChangeTitle):
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm:
(TEST):
LayoutTests:
Adapt tests to make sure pending title change tasks
are processed before the test is done.
* fast/dom/title-text-property-2.html:
* fast/dom/title-text-property-assigning-empty-string.html:
* fast/dom/title-text-property.html:
* http/tests/globalhistory/history-delegate-basic-title-expected.txt:
* http/tests/globalhistory/history-delegate-basic-title.html:
* http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt:
* http/tests/loading/basic-auth-load-URL-with-consecutive-slashes.html:
* http/tests/loading/redirect-with-no-location-crash-expected.txt:
* http/tests/loading/redirect-with-no-location-crash.html:
* platform/mac-wk2/TestExpectations:
* platform/win/http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt: Copied from LayoutTests/http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt.
* platform/wk2/http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt:
* platform/wk2/http/tests/loading/redirect-with-no-location-crash-expected.txt:
Canonical link: https://commits.webkit.org/233064@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271514 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220542
Reviewed by Eric Carlson.
Source/WebCore:
* platform/graphics/gstreamer/GStreamerCommon.cpp:
(WebCore::ensureGStreamerInitialized): Re-instate release assert ensuring this code path is
not hit from the UIProcess.
Source/WebKit:
For GLib ports the UIProcess will now send a message to the WebProcess to retrieve the
MediaStream devices. This is required because we want to avoid initializing GStreamer in the
UIProcess as much as possible.
* UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
(WebKit::UserMediaPermissionRequestManagerProxy::platformGetMediaStreamDevices):
(WebKit::UserMediaPermissionRequestManagerProxy::computeFilteredDeviceList):
* UIProcess/UserMediaPermissionRequestManagerProxy.h:
* UIProcess/glib/UserMediaPermissionRequestManagerProxyGLib.cpp:
(WebKit::UserMediaPermissionRequestManagerProxy::platformGetMediaStreamDevices):
* WebProcess/glib/UserMediaCaptureManager.cpp:
(WebKit::UserMediaCaptureManager::validateUserMediaRequestConstraints):
(WebKit::UserMediaCaptureManager::getMediaStreamDevices):
* WebProcess/glib/UserMediaCaptureManager.h:
* WebProcess/glib/UserMediaCaptureManager.messages.in:
Canonical link: https://commits.webkit.org/233063@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271513 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220463
Reviewed by Xabier Rodriguez-Calvar.
Source/WebCore:
The code style now conforms WebKit's. The GhostPad subclass moved to its own code unit,
because the WEBKIT_DEFINE_TYPE cannot be used multiple times in the same file (it defines a
parent_class symbol). The GhostPad was also decoupled as much as possible from the Combiner.
Most mentions of the funnel GStreamer element were made more generic because we might need
to use a different element in situations where the pipeline is playbin3-based, which requires
the concat element.
No new tests, existing tests cover this patch.
* platform/GStreamer.cmake:
* platform/graphics/gstreamer/GStreamerCommon.cpp:
(WebCore::gstElementFactoryEquals):
* platform/graphics/gstreamer/GStreamerCommon.h:
* platform/graphics/gstreamer/TextCombinerGStreamer.cpp:
(webKitTextCombinerHandleCapsEvent):
(webkitTextCombinerRequestNewPad):
(webkitTextCombinerReleasePad):
(webKitTextCombinerConstructed):
(webkit_text_combiner_class_init):
(webkitTextCombinerNew):
* platform/graphics/gstreamer/TextCombinerGStreamer.h:
* platform/graphics/gstreamer/TextCombinerPadGStreamer.cpp: Added.
(webkitTextCombinerPadEvent):
(webkitTextCombinerPadGetProperty):
(webkitTextCombinerPadSetProperty):
(webkitTextCombinerPadConstructed):
(webkit_text_combiner_pad_class_init):
(webKitTextCombinerPadLeakInternalPadRef):
* platform/graphics/gstreamer/TextCombinerPadGStreamer.h: Copied from Source/WebCore/platform/graphics/gstreamer/TextCombinerGStreamer.h.
Tools:
* Scripts/webkitpy/style/checker.py: Add GStreamer TextCombiner implementation to GObject
classes allow-list.
Canonical link: https://commits.webkit.org/233062@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271512 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220630
Patch by Julian Gonzalez <julian_a_gonzalez@apple.com> on 2021-01-14
Reviewed by Ryosuke Niwa.
Source/WebCore:
If the start or end VisiblePositions inside InsertListCommand::unlistifyParagraph()
are null VisiblePositions (even if they are not null Positions), passing them to the
call to moveParagraphs() at the end of the function isn't meaningful and will result
in a crash - so return early in this case.
Test: editing/inserting/paragraph-outdent-crash.html
* editing/InsertListCommand.cpp:
(WebCore::InsertListCommand::unlistifyParagraph):
LayoutTests:
Add a test to verify that the crash here is resolved, and also remove a newline
from another related test that now renders one fewer newline
(in that case, the ultimate bug is similar, so the result should be similar).
* editing/inserting/insert-list-in-iframe-in-list-expected.txt:
* editing/inserting/paragraph-outdent-crash-expected.txt: Added.
* editing/inserting/paragraph-outdent-crash.html: Added.
Canonical link: https://commits.webkit.org/233060@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271510 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220634
Reviewed by Yusuke Suzuki.
JSTests:
* stress/escaped-keyword-identifiers.js: Added.
* test262/expectations.yaml: Mark 16 test cases as passing.
Source/JavaScriptCore:
When `let`, `await`, and `yield` are accepted as identifiers, they should be accepted even in escaped form.
This patch ensures this behavior for variable, parameter, and label names.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::isArrowFunctionParameters):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parsePrimaryExpression):
Make use of new parser functions.
* parser/Parser.h:
(JSC::isContextualKeyword): Renamed from isAnyContextualKeyword.
(JSC::Parser::matchSpecIdentifier): Allow escaped contextual keywords.
(JSC::Parser::matchIdentifierOrPossiblyEscapedContextualKeyword): Added.
(JSC::Parser::isAllowedIdentifierLet): Renamed from isLETMaskedAsIDENT.
(JSC::Parser::isPossiblyEscapedLet): Added.
(JSC::Parser::isDisallowedIdentifierAwait): Added.
(JSC::Parser::isAllowedIdentifierAwait): Added.
(JSC::Parser::isPossiblyEscapedAwait): Added.
(JSC::Parser::canUseIdentifierAwait): Added.
(JSC::Parser::isDisallowedIdentifierYield): Added.
(JSC::Parser::isAllowedIdentifierYield): Renamed from isYIELDMaskedAsIDENT.
(JSC::Parser::isPossiblyEscapedYield): Added.
(JSC::Parser::canUseIdentifierYield): Added.
(JSC::Parser::matchAllowedEscapedContextualKeyword): Added.
(JSC::Parser::disallowedIdentifierAwaitReason): Fix mistake (left over from previous patch).
(JSC::isIdentifierOrAnyContextualKeyword): Deleted.
(JSC::isSafeContextualKeyword): Deleted.
(JSC::Parser::isDisallowedIdentifierLet): Deleted.
* parser/ParserTokens.h:
Remove obsolete notion of "safe contextual keyword".
Canonical link: https://commits.webkit.org/233059@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271509 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220635
Reviewed by Tim Horton.
Source/WebCore:
We should be able to do fast scrolling of the main frame when a subframe has background-attachment:fixed
content in it, but currently we propagate the "slow scrolling reasons" up to the root of
the scrolling tree, which crosses frame boundaries.
This is a partial fix for the problem; ThreadedScrollingTree::canUpdateLayersOnScrollingThread()
is still consulting tree-wide state.
Test: scrollingcoordinator/mac/fixed-backgrounds/fixed-background-in-overflow-in-iframe.html
* page/scrolling/ScrollingStateFrameScrollingNode.cpp:
(WebCore::ScrollingStateFrameScrollingNode::dumpProperties const):
* page/scrolling/ThreadedScrollingTree.cpp:
(WebCore::ThreadedScrollingTree::propagateSynchronousScrollingReasons):
(WebCore::ThreadedScrollingTree::canUpdateLayersOnScrollingThread const):
* page/scrolling/ThreadedScrollingTree.h:
LayoutTests:
* scrollingcoordinator/mac/fixed-backgrounds/fixed-background-in-overflow-in-iframe-expected.txt: Added.
* scrollingcoordinator/mac/fixed-backgrounds/fixed-background-in-overflow-in-iframe.html: Added.
Canonical link: https://commits.webkit.org/233058@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271508 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=220526
<rdar://problem/71045590>
Reviewed by Ryosuke Niwa.
Source/WebCore:
Currently, when DataDetectors links are written to the pasteboard when
copied. This is problematic, since clicking on a DataDetector link
outside of a valid context results in an attempt to open an invalid
URL. Instead, DataDetectors links should be stripped when copied.
To remove the link, while preserving any custom styles, the <a> element
created by Data Detection is replaced with a <span> element. Any
attributes and styles added by WebKit are removed as a part of this
transformation.
Tests: editing/pasteboard/copy-paste-data-detected-links.html
CopyRTF.StripsDataDetectedLinks
PasteWebArchive.StripsDataDetectedLinks
* editing/cocoa/DataDetection.h:
* editing/cocoa/DataDetection.mm:
(WebCore::DataDetection::isDataDetectorElement):
Add a helper to check if an element was created through Data Detection.
* editing/cocoa/HTMLConverter.mm:
(HTMLConverter::_addLinkForElement):
Do not add NSLinkAttributeName for DataDetectors links.
(HTMLConverter::_exitElement):
Factor out link creation logic.
* editing/markup.cpp:
(WebCore::StyledMarkupAccumulator::spanReplacementForElement):
Centralize the logic that determines whether or not an element should
be replaced by a <span>. Previously, this only applied to <slot>
elements. Now, it applies to <slot> and DataDetectors links.
(WebCore::StyledMarkupAccumulator::appendStartTag):
If the element was created through DataDetection, append a <span>
rather than an <a>, to drop the link. The DataDetectors and href
attributes are also dropped from the markup string. Finally, remove
the text decoration style that was added by WebKit to style the
DataDetectors link.
(WebCore::StyledMarkupAccumulator::appendEndTag):
Consult shouldReplaceElementWithSpan when appending the end tag.
Tools:
Added API tests to verify DataDetectors links are not preserved when
copying/pasting WebArchives and rich text.
* TestWebKitAPI/Tests/WebKitCocoa/CopyRTF.mm:
(StripsDataDetectorsLinks):
* TestWebKitAPI/Tests/WebKitCocoa/PasteWebArchive.mm:
(StripsDataDetectorsLinks):
LayoutTests:
Added a test which copies content containing two data detected links
and verifies that the links are removed.
* editing/pasteboard/copy-paste-data-detected-links-expected.txt: Added.
* editing/pasteboard/copy-paste-data-detected-links.html: Added.
Canonical link: https://commits.webkit.org/233057@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271507 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Leorize