Timeline
Apr 11, 2021:
- 11:02 PM Changeset in webkit [275814] by
-
- 4 edits in trunk/Tools
Unreviewed, reverting r275801.
https://bugs.webkit.org/show_bug.cgi?id=224423
run-jsc-stress-tests output includes a lot of texts
Reverted changeset:
"[JSC] detect infrastructure failure for remote stress tests"
https://bugs.webkit.org/show_bug.cgi?id=222601
https://trac.webkit.org/changeset/275801
- 8:02 PM Changeset in webkit [275813] by
-
- 8 edits in trunk/Source
Versioning.
WebKit-7612.1.12
- 8:00 PM Changeset in webkit [275812] by
-
- 1 copy in branches/safari-612.1.11-branch
New branch.
- 3:53 PM Changeset in webkit [275811] by
-
- 4 edits4 adds in trunk
Fix initial horizontal scrollbar position when vertical scrollbar is on the left.
https://bugs.webkit.org/show_bug.cgi?id=224409
Reviewed by Darin Adler.
Source/WebCore:
Scrollable elements that place their vertical scrollbar on the left
(e.g. when they'redirection: rtlor when the OS language is RTL and
the relevant setting to always follow OS scrollbar side is used) have
an incorrect scroll origin, which leads to creating a horizontal
scrollbar with an incorrect initial offset. This is because
RenderLayerScrollableArea::computeScrollDimensions runs prior to the
scrollbars being created. So whenever we start or stop having a
(non-overlay) vertical scrollbar on the left, we need to recompute
the scroll origin and fix up the horizontal scrollbar's offset.
Tests: fast/scrolling/rtl-scrollbars-initial-position-dynamic.html
fast/scrolling/rtl-scrollbars-initial-position.html
- rendering/RenderLayerScrollableArea.cpp:
(WebCore::RenderLayerScrollableArea::computeScrollDimensions):
(WebCore::RenderLayerScrollableArea::computeScrollOrigin): Split this
out of computeScrollDimensions so we can call it from
updateScrollbarsAfterLayout and updateScrollbarsAfterStyleChange, and
have it ask the horizontal scrollbar to update its offset. We could
condition this on the scroll origin actually having changed, but
that's going to be a similar check that Scrollbar::offsetDidChange
does to ensure the offset value did indeed change. We don't want to
condition this on shouldPlaceBlockDirectionScrollbarOnLeft(), since
that's dependent on the current style, and we may be reacting to a
style change removed the vertical scrollbar on the left.
(WebCore::RenderLayerScrollableArea::updateScrollbarsAfterLayout):
(WebCore::RenderLayerScrollableArea::updateScrollbarsAfterStyleChange):
- rendering/RenderLayerScrollableArea.h:
LayoutTests:
- fast/scrolling/rtl-scrollbars-initial-position-dynamic-expected.html: Added.
- fast/scrolling/rtl-scrollbars-initial-position-dynamic.html: Added.
- fast/scrolling/rtl-scrollbars-initial-position-expected.html: Added.
- fast/scrolling/rtl-scrollbars-initial-position.html: Added.
- 1:11 PM Changeset in webkit [275810] by
-
- 16 edits in trunk
Simplify WebKitTestRunner preference reset to be more like DRT
https://bugs.webkit.org/show_bug.cgi?id=224410
Reviewed by Darin Adler.
Source/WebKit:
Add WKPreferencesStartBatchingUpdates/WKPreferencesEndBatchingUpdates
to support batching preferences updates by clients.
- UIProcess/API/C/WKPreferences.cpp:
(WKPreferencesStartBatchingUpdates):
(WKPreferencesEndBatchingUpdates):
- UIProcess/API/C/WKPreferencesRefPrivate.h:
- UIProcess/WebPreferences.h:
Tools:
- Use boolWebPreferenceFeatures consistently for accessibilityIsolatedTreeMode
- Adopt new WKPreferencesStartBatchingUpdates/WKPreferencesEndBatchingUpdates to ensure all preferences updates are batched.
- Move all preference overrides that can be moved (two still require some specialized handling for now) to TestOptions defaults.
- Remove now unnecessary platformResetPreferencesToConsistentValues() platform configuration point.
- WebKitTestRunner/Options.cpp:
(WTR::handleOptionAccessibilityIsolatedTreeMode):
- WebKitTestRunner/Options.h:
- WebKitTestRunner/TestController.cpp:
(WTR::TestController::initialize):
(WTR::batchUpdatePreferences):
(WTR::TestController::resetPreferencesToConsistentValues):
(WTR::TestController::resetStateToConsistentValues):
- WebKitTestRunner/TestController.h:
(WTR::TestController::accessibilityIsolatedTreeMode const): Deleted.
- WebKitTestRunner/TestOptions.cpp:
(WTR::TestOptions::defaults):
- WebKitTestRunner/TestOptions.h:
(WTR::TestOptions::accessibilityIsolatedTreeMode const):
- WebKitTestRunner/gtk/TestControllerGtk.cpp:
(WTR::TestController::platformResetStateToConsistentValues):
(WTR::TestController::platformResetPreferencesToConsistentValues): Deleted.
- WebKitTestRunner/ios/TestControllerIOS.mm:
(WTR::TestController::platformResetStateToConsistentValues):
(WTR::TestController::platformResetPreferencesToConsistentValues): Deleted.
- WebKitTestRunner/mac/TestControllerMac.mm:
(WTR::TestController::platformResetPreferencesToConsistentValues): Deleted.
- WebKitTestRunner/win/TestControllerWin.cpp:
(WTR::TestController::platformResetPreferencesToConsistentValues): Deleted.
- WebKitTestRunner/wpe/TestControllerWPE.cpp:
(WTR::TestController::platformResetPreferencesToConsistentValues): Deleted.
- 12:33 PM Changeset in webkit [275809] by
-
- 3 edits in trunk/Source/WebCore
[Mac] Add a missing null check to slider thumb focus rendering
https://bugs.webkit.org/show_bug.cgi?id=224418
rdar://76450584
Reviewed by Sam Weinig.
- rendering/RenderThemeMac.h: Changed updateFocusedState to take a pointer.
- rendering/RenderThemeMac.mm:
(WebCore::RenderThemeMac::updateFocusedState): Check pointer for null. This was the
missing null check.
(WebCore::RenderThemeMac::paintSliderThumb): Pass delegate pointer instead of reference.
Also made sure we always update the focused state. Old code took the approach of just not
updating focus state when it encountered null for the focus delegate, but that's not a
good strategy. In future we may also want to change the focusDelegate function signature
to make it clear it will never return null, but that's not critical right now.
(WebCore::RenderThemeMac::setSearchCellState): Update since updateFocusedState now
takes a pointer.
- 10:06 AM Changeset in webkit [275808] by
-
- 26 edits2 moves1 add1 delete in trunk
Reduce compile time and binary size cost of enabling proper CSSStyleDeclaration property access behavior
https://bugs.webkit.org/show_bug.cgi?id=222518
<rdar://problem/75136887>
Reviewed by Darin Adler.
LayoutTests/imported/w3c:
- web-platform-tests/css/cssom/cssstyledeclaration-properties-expected.txt:
Update test result now that it is passing.
Source/WebCore:
Re-implement proper (not using named-getters) support for the CSSStyleDeclaration bindings
using a new DelegateToSharedSyntheticAttribute extended atttribute which allows IDL attributes
to share a custom getter / setter implementation and delegate their implementation to it. When
using this functionality, the synthetic attribute's implementation is passed the original property
name so it can implement functionality based on it.
We use this for CSSStyleDeclaration by breaking the huge list of generated properties into
four groups, each with their own synthetic attribute. The groups are based on the different
transformation rules in the spec.
- bindings/js/JSDOMAttribute.h:
(WebCore::IDLAttribute::setPassingPropertyName):
(WebCore::IDLAttribute::getPassingPropertyName):
Add overloads of get/set that pass the property name to the provided function. These can't
be simple overloads of get/set as MSVC does not allow overloading with only a non-type
template parameters differentiating.
- bindings/scripts/CodeGeneratorJS.pm:
(GenerateInterface):
Eagerly generate the any synthetic attributes before the rest of code generation,
matching the behavior of other synthetic constructions like map/set/stringifiers.
(GetAttributeGetterName):
(GetAttributeSetterName):
Add special cases to getter/setter name generation to forward to the generated
name of the synthetic attribute when delegating.
(GenerateImplementation):
Extract attribute function forward declaration genation into a new GenerateAttributeGetterAndSetterDeclaration
subroutine and use it for generation of both normal and synthetic attributes. Also adds
synthetic attributes to the list of attributes to generate function implementations for.
(GenerateAttributeGetterAndSetterDeclaration):
Extracted from GenerateImplementation. Adds extra condition to bail if DelegateToSharedSyntheticAttribute
is specified.
(GenerateAttributeGetterBodyDefinition):
Add support for the new CallWith=PropertyName extended attribute by adding a PropertyName
argument to the signature of getter body if it is present. Removes now unnecessary support
for the CSSProperty extended attribute.
(GenerateAttributeGetterTrampolineDefinition):
Switch function name from get to getPassingPropertyName if CallWith=PropertyName is specified.
(GenerateAttributeGetterDefinition):
Adds extra condition to bail if DelegateToSharedSyntheticAttribute is specified.
(GenerateAttributeSetterBodyDefinition):
Add support for the new CallWith=PropertyName extended attribute by adding a PropertyName
argument to the signature of getter body if it is present. Removes now unnecessary support
for the CSSProperty extended attribute.
(GenerateAttributeSetterTrampolineDefinition):
Switch function name from get to getPassingPropertyName if CallWith=PropertyName is specified.
(GenerateAttributeSetterDefinition):
Adds extra condition to bail if DelegateToSharedSyntheticAttribute is specified.
(GenerateCallWith):
Add support for the PropertyName value to CallWith.
(MakeSharedSyntheticAttribute):
Helper to generate the synthetic attribute from the base attribute with DelegateToSharedSyntheticAttribute
specefied. Maintains all existing extended attributes of the base attribute except
DelegateToSharedSyntheticAttribute is replaced with IsSharedSyntheticAttribute to avoid
infinite recursion.
(AddSharedSyntheticAttributesIfNeeded):
Helper to find all delegating attributes and generate / store the synthetic attributes.
(GetSharedSyntheticAttribute):
Helper to get the corresponding synthetic attribute given an attribute with
DelegateToSharedSyntheticAttribute specified on it.
- bindings/scripts/IDLAttributes.json:
Removes CSSProperty. Adds DelegateToSharedSyntheticAttribute. Adds PropertyName value to
CallWith and SetterCallWith.
- css/CSSStyleDeclaration.cpp:
(WebCore::lookupCSSPropertyFromIDLAttribute):
(WebCore::CSSStyleDeclaration::propertyValueForCamelCasedIDLAttribute):
(WebCore::CSSStyleDeclaration::setPropertyValueForCamelCasedIDLAttribute):
(WebCore::CSSStyleDeclaration::propertyValueForWebKitCasedIDLAttribute):
(WebCore::CSSStyleDeclaration::setPropertyValueForWebKitCasedIDLAttribute):
(WebCore::CSSStyleDeclaration::propertyValueForDashedIDLAttribute):
(WebCore::CSSStyleDeclaration::setPropertyValueForDashedIDLAttribute):
(WebCore::CSSStyleDeclaration::propertyValueForEpubCasedIDLAttribute):
(WebCore::CSSStyleDeclaration::setPropertyValueForEpubCasedIDLAttribute):
(WebCore::CSSStyleDeclaration::namedItem): Deleted.
(WebCore::CSSStyleDeclaration::setNamedItem): Deleted.
(WebCore::CSSStyleDeclaration::supportedPropertyNames const): Deleted.
- css/CSSStyleDeclaration.h:
Replace named-getter based implementation with helpers based on the definitions
in the CSSOM spec (plus one special set for 'epub' specializations we currently
maintain).
- css/CSSStyleDeclaration.idl:
Remove !ENABLE_ATTRIBUTE_BASED_PROPERTIES_FOR_CSS_STYLE_DECLARATION sections now that
we can fully support ENABLE_ATTRIBUTE_BASED_PROPERTIES_FOR_CSS_STYLE_DECLARATION.
- css/makeprop.pl:
Remove !ENABLE_ATTRIBUTE_BASED_PROPERTIES_FOR_CSS_STYLE_DECLARATION sections now that
we can fully support ENABLE_ATTRIBUTE_BASED_PROPERTIES_FOR_CSS_STYLE_DECLARATION.
Replaces CSSProperty extended attributes with DelegateToSharedSyntheticAttribute and
CallWith=PropertyName, which together allow us to implement all the attributes with just
8 implementation functions.
- bindings/scripts/test/BindingTestGlobalConstructors.idl:
- bindings/scripts/test/JS/JSTestCSSProperty.cpp: Removed.
- bindings/scripts/test/JS/JSTestCSSProperty.h: Removed.
- bindings/scripts/test/JS/JSTestDelegateToSharedSyntheticAttribute.cpp: Added.
- bindings/scripts/test/JS/JSTestDelegateToSharedSyntheticAttribute.h: Added.
- bindings/scripts/test/JS/JSTestGlobalObject.cpp:
- bindings/scripts/test/SupplementalDependencies.dep:
- bindings/scripts/test/TestCSSProperty.idl: Removed.
- bindings/scripts/test/TestDelegateToSharedSyntheticAttribute.idl: Added.
Replace CSSProperty tests with DelegateToSharedSyntheticAttribute tests and update results
all around for new generation.
Source/WTF:
- wtf/PlatformEnable.h:
Remove ENABLE_ATTRIBUTE_BASED_PROPERTIES_FOR_CSS_STYLE_DECLARATION, as it is now the default and on everwhere.
LayoutTests:
- fast/css/style-enumerate-properties-expected.txt:
- fast/css/style-enumerate-properties.html:
- fast/dom/domListEnumeration-expected.txt:
- fast/dom/domListEnumeration.html:
Remove existing tests for iteration order, which is not standardized, and not consistent among
browsers. Adds a new one that checks invariants of the 4 groupings of properties which we currently
expect to hold, at least in our implementation.
- fast/dom/CSSStyleDeclaration/cssstyledeclaration-properties-descriptor-expected.txt:
- fast/dom/CSSStyleDeclaration/cssstyledeclaration-properties-descriptor.html:
Update now that the properties are proper attributes on the prototype.
- js/dom/put-override-should-not-use-ic.html:
Switch to using a DOMStringList as the object that overrides put, since CSSStyleDeclaration no longer does.
- transitions/transitions-parsing-expected.txt:
- transitions/transitions-parsing.html:
Remove Object.keys() aspect of the test, which is no longer meaningful since the
properties should no longer exist in the result set.
- 7:35 AM Changeset in webkit [275807] by
-
- 2 edits in trunk/Source/WebCore
Store InputType in a Ref before calling setValueAsDecimal
https://bugs.webkit.org/show_bug.cgi?id=223535
Patch by Rob Buis <rbuis@igalia.com> on 2021-04-11
Reviewed by Ryosuke Niwa.
Store InputType in a Ref before calling setValueAsDecimal.
- html/InputType.cpp:
(WebCore::InputType::applyStep):
- 5:04 AM WebKitGTK/2.32.x edited by
- (diff)
Apr 10, 2021:
- 7:57 PM Changeset in webkit [275806] by
-
- 10 edits in trunk/Source/WebKit
Use WeakHashSet<WebProcessProxy> instead of HashSet<WebProcessProxy*>
https://bugs.webkit.org/show_bug.cgi?id=224393
Reviewed by Chris Dumez.
- UIProcess/Cocoa/WebProcessProxyCocoa.mm:
(WebKit::WebProcessProxy::requestHighPerformanceGPU):
(WebKit::WebProcessProxy::releaseHighPerformanceGPU):
- UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::~WebProcessPool):
(WebKit::WebProcessPool::enableProcessTermination):
(WebKit::WebProcessPool::shouldTerminate):
(WebKit::WebProcessPool::disconnectProcess):
(WebKit::WebProcessPool::startedUsingGamepads):
(WebKit::WebProcessPool::stoppedUsingGamepads):
(WebKit::WebProcessPool::processStoppedUsingGamepads):
(WebKit::WebProcessPool::gamepadConnected):
(WebKit::WebProcessPool::gamepadDisconnected):
- UIProcess/WebProcessPool.h:
- UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::~WebProcessProxy):
(WebKit::WebProcessProxy::shutDown):
(WebKit::WebProcessProxy::maybeShutDown):
(WebKit::WebProcessProxy::canTerminateAuxiliaryProcess):
- UIProcess/mac/HighPerformanceGPUManager.mm:
(WebKit::HighPerformanceGPUManager::addProcessRequiringHighPerformance):
(WebKit::HighPerformanceGPUManager::removeProcessRequiringHighPerformance):
(WebKit::HighPerformanceGPUManager::updateState):
- 5:48 PM Changeset in webkit [275805] by
-
- 8 edits in trunk/Source/WebKit
Crash under WebProcessProxy::shouldSendPendingMessage()
https://bugs.webkit.org/show_bug.cgi?id=224377
<rdar://75329251>
Reviewed by David Kilzer.
We are crashing with a null-dereference of pendingMessage.encoder inside WebProcessProxy::shouldSendPendingMessage().
However, pendingMessage.encoder is a UniqueRef<> and thus cannot be null. Also, we know that the WebProcessProxy
is alive because WebProcessProxy::didFinishLaunching() has a protector.
One thing that I believe could theoretically happen and would not be safe though is AuxiliaryProcessProxy::sendMessage()
being called on a non-main thread. Sending IPC off the main thread is safe in general and something we commonly do with
an IPC::Connection. To make this safe, IPC::Connection uses a Lock to protect its vector of messages. However, sending
IPC via an AuxiliaryProcessProxy is currently not thread safe as it relies on the process state (which gets updated on
the main thread) and access to the m_pendingMessages is not synchronized.
As a speculative fix, I have added logic in AuxiliaryProcessProxy::sendMessage() to dispatch to the main thread if
we're not already on it. I have also used WTF::DestructionThread::MainRunLoop to make sure all AuxiliaryProcessProxy
objects get destroyed on the main thread.
In a follow-up, I am planning to add a release assertion in AuxiliaryProcessProxy::sendMessage() to make sure we're
on a main thread. We'll then be able to drop the "dispatching the main thread" logic. For now though, I think we
should start with the "dispatch to main thread" logic, so that we have a patch that we can cherry-pick to a branch.
- UIProcess/AuxiliaryProcessProxy.cpp:
(WebKit::AuxiliaryProcessProxy::sendMessage):
(WebKit::AuxiliaryProcessProxy::didFinishLaunching):
(WebKit::AuxiliaryProcessProxy::replyToPendingMessages):
- UIProcess/AuxiliaryProcessProxy.h:
- UIProcess/GPU/GPUProcessProxy.h:
- UIProcess/Network/NetworkProcessProxy.h:
- UIProcess/Plugins/PluginProcessProxy.h:
- UIProcess/WebAuthentication/WebAuthnProcessProxy.cpp:
(WebKit::WebAuthnProcessProxy::singleton):
- UIProcess/WebProcessProxy.h:
- 3:41 PM Changeset in webkit [275804] by
-
- 3 edits2 adds in trunk
Regression(r275668) Potential null pointer deref in AudioParam::exponentialRampToValueAtTime(float, double)
https://bugs.webkit.org/show_bug.cgi?id=224400
<rdar://76450376>
Reviewed by Ryosuke Niwa.
Source/WebCore:
In r275668, I added null-checks for the AudioContext in AudioParam, now that it holds a WeakPtr to its
context. However, I missed a null-check in AudioParam::exponentialRampToValueAtTime(). This patch adds
the missing check.
Test: webaudio/AudioParam/audioparam-exponentialRampToValueAtTime-nocontext-crash.html
- Modules/webaudio/AudioParam.cpp:
LayoutTests:
Add layout test coverage.
- webaudio/AudioParam/audioparam-exponentialRampToValueAtTime-nocontext-crash-expected.txt: Added.
- webaudio/AudioParam/audioparam-exponentialRampToValueAtTime-nocontext-crash.html: Added.
- 3:37 PM Changeset in webkit [275803] by
-
- 4 edits in trunk/LayoutTests
[ macOS ] imported/w3c/web-platform-tests/webaudio/the-audio-api/the-analysernode-interface/realtimeanalyser-fft-scaling.html is a flakey text failure
https://bugs.webkit.org/show_bug.cgi?id=223966
<rdar://problem/76028345>
Reviewed by Darin Adler.
LayoutTests/imported/w3c:
Update test as per:
Make sure subtests are run one after another, not in parallel, so that PASS lines are printed out in a
consistent order.
- web-platform-tests/webaudio/the-audio-api/the-analysernode-interface/realtimeanalyser-fft-scaling.html:
LayoutTests:
Unskip test that should no longer be flaky.
- platform/mac/TestExpectations:
- 3:02 PM Changeset in webkit [275802] by
-
- 2 edits in trunk/Source/WebKit
Properly use CompletionHandler when USE_OPENGL_OR_ES is set to OFF
https://bugs.webkit.org/show_bug.cgi?id=224149
Patch by Charlène Wendling <julianaito@posteo.jp> on 2021-04-10
Reviewed by Fujii Hironori.
- WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.h:
(WebKit::LayerTreeHost::forceRepaintAsync):
- 1:14 PM Changeset in webkit [275801] by
-
- 4 edits in trunk/Tools
[JSC] detect infrastructure failure for remote stress tests
https://bugs.webkit.org/show_bug.cgi?id=222601
Reviewed by Yusuke Suzuki.
run-jsc-stress-tests currently detects failures by the absence of
a failure file (that is generated by each failing test). This is
fragile to begin with, as it assumes that tests that fail to run
(e.g. because of an error in the runner script) are successful by
default.
However, the main motivation for this patch is to make execution
more robust when using remote hosts. Currently,
--gnu-parallel-runner will transparently reschedule jobs on a
different host when a remote host goes away. But detectFailures
expects to be able to connect to all hosts and fetch the failure
files, which fails if a remote host is still down when the run
finishes.
Instead, this patch changes the runners to always generate a status
file with the exit code. detectFailures then fetches all status
files from all hosts that are live on exit. Tests that failed to
run are explicitly accounted for as 'noreport' and are set to
ERROR in the final report.
- Scripts/run-javascriptcore-tests:
(runJSCStressTests):
- Scripts/run-jsc-stress-tests:
- Scripts/webkitruby/jsc-stress-test-writer-default.rb:
- 12:00 PM Changeset in webkit [275800] by
-
- 9 edits in trunk/Source/JavaScriptCore
[JSC] B3 reduce-double-to-float should reduce only when constant double is canonical one to reduced float value
https://bugs.webkit.org/show_bug.cgi?id=224403
<rdar://problem/76259599>
Reviewed by Mark Lam.
When reducing double-constant value to float in B3, we should check whether the double value is a canonical one
which can be converted back from the reduced float value. For example, double 1.1 is not the one since it is truncated
into float 1.1 by removing some bits.
static_cast<double>(static_cast<float>(1.1)) != 1.1
Reducing such a double to float changes the semantics.
- b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::dumpMeta const):
- b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::dumpMeta const):
- b3/B3ReduceDoubleToFloat.cpp:
- b3/B3ReduceStrength.cpp:
- b3/testb3.h:
(populateWithInterestingValues):
- b3/testb3_1.cpp:
(run):
- b3/testb3_3.cpp:
(testConvertDoubleToFloatToDouble):
(testConvertDoubleToFloatEqual):
- ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::JSC_DEFINE_JIT_OPERATION_WITH_ATTRIBUTES):
(JSC::FTL::DFG::LowerDFGToB3::crash):
(JSC::FTL::DFG::ftlUnreachable): Deleted.
- 10:56 AM Changeset in webkit [275799] by
-
- 8 edits in trunk/Source/WebKit
Unreviewed, reverting r275794, r275784, r275779
r275779 caused bots to crash and r275794, r275784 didn't fully fix it; reverting the patches to investigate.
Reverted changeset:
"Create WebIDBServer only when it is needed"
https://bugs.webkit.org/show_bug.cgi?id=224305
https://commits.webkit.org/r275779
- 10:11 AM Changeset in webkit [275798] by
-
- 13 edits1 add in trunk
[ macOS ] 3 webaudio/OfflineAudioContext/ layout-tests are flakey text failures
https://bugs.webkit.org/show_bug.cgi?id=224387
<rdar://problem/76468058>
Reviewed by Eric Carlson.
Source/WebCore:
Replace internals.numberOfBaseAudioContexts() test infrastructure with
internals.baseAudioContextIdentifier() & internals.isBaseAudioContextAlive().
This allows tests to check if specific BaseAudioContext instances created by the
tests are actually alive. As a result, the tests are no longer impacted by tests
running before them (and potentially leaking, see Bug 224399) or in parallel to
them in the same process.
This is the same approach we used for leak testing Documents (internals.documentIdentifier()
& internals.isDocumentAlive()).
- Modules/webaudio/BaseAudioContext.cpp:
(WebCore::generateAudioContextID):
(WebCore::liveAudioContexts):
(WebCore::BaseAudioContext::BaseAudioContext):
(WebCore::BaseAudioContext::~BaseAudioContext):
(WebCore::BaseAudioContext::isContextAlive):
- Modules/webaudio/BaseAudioContext.h:
(WebCore::BaseAudioContext::contextID const):
- testing/Internals.cpp:
(WebCore::Internals::countMatchesForText):
(WebCore::Internals::baseAudioContextIdentifier):
(WebCore::Internals::isBaseAudioContextAlive):
- testing/Internals.h:
- testing/Internals.idl:
LayoutTests:
Update OfflineAudioContext leak tests to use the new test infrastructure. They are no longer impacted
by tests running before them or in parallel to them.
- webaudio/OfflineAudioContext/offlineaudiocontext-leak-after-rendering-expected.txt:
- webaudio/OfflineAudioContext/offlineaudiocontext-leak-after-rendering.html:
- webaudio/OfflineAudioContext/offlineaudiocontext-leak-expected.txt:
- webaudio/OfflineAudioContext/offlineaudiocontext-leak-while-suspended-expected.txt:
- webaudio/OfflineAudioContext/offlineaudiocontext-leak-while-suspended.html:
- webaudio/OfflineAudioContext/offlineaudiocontext-leak.html:
- webaudio/resources/audiocontext-leak-test.js: Added.
(didGCAtLeastOneContext):
(gcAndCheckForContextLeaks):
- 9:12 AM Changeset in webkit [275797] by
-
- 35 edits2 adds in trunk
Enable VMTraps checks in RETURN_IF_EXCEPTION.
https://bugs.webkit.org/show_bug.cgi?id=224078
rdar://75037057
Reviewed by Keith Miller.
JSTests:
- stress/watchdog-fire-while-in-forEachInIterable.js: Added.
Source/JavaScriptCore:
In pre-existing code, termination of a VM's execution can already be requested
asynchronously (with respect to the mutator thread). For example, sources of such
a request can be a watchdog timer firing, or a request to stop execution issued
from a main web thread to a worker thread.
This request is made by firing the VMTraps::NeedTermination event on VMTraps.
Firing the event here only means setting a flag to indicate the presence of the
request. We still have to wait till the mutator thread reaches one of the
pre-designated polling check points to call VMTraps::handleTraps() in order to
service the request. As a result of this need to wait for a polling check point,
if the mutator is executing in a long running C++ loop, then a termination request
may not be serviced for a long time.
However, we observed that a lot of our C++ loops already have RETURN_IF_EXCEPTION
checks. Hence, if we can check VMTraps::needHandling() there, we can service the
VMTraps events more frequently even in a lot of C++ loops, and get a better response.
Full details of what this patch changes:
- Shorten some type and methods names in the VMTraps class to make code easier to read e.g. EventType => Event, needTrapHandling => needHandling.
- Remove the VMTraps::Mask class. Mask was introduced so that we can express a concatenation of multiple VMTraps events to form a bit mask in a simple way. In the end, it isn't flexible enough but makes the code more complicated than necessary. It is now replaced by the simpler solution of using macros to define the Events as bit fields. Having Events as bit fields intrinsically make them easy to concatenate (bitwise or) or filter (bitwise and).
Also removed the unused VMTraps::Error class.
- Make VMTraps::BitField a uint32_t. There was always unused padding in VMTraps to allow for this. So, we'll just extend it to a full 32-bit to make it easier to add more events in the future for other uses.
- Add NeedExceptionHandling as a VMTrap::Event.
- Make VMTraps::m_trapBits Atomic. This makes it easier to set and clear the NeedExceptionHandling bit from the mutator without a lock.
- RETURN_IF_EXCEPTION now checks VMTraps::m_trapBits (via VMTraps::needHandling()) instead of checking VM::m_exception. If the VMTraps::m_trapBits is non-null, the macro will call VM:hasExceptionsAfterHandlingTraps() to service VMTraps events as appropriate before returning whether an exception is being thrown. The result of VM:hasExceptionsAfterHandlingTraps() will determine if RETURN_IF_EXCEPTION returns or not.
VM:hasExceptionsAfterHandlingTraps() is intentionally designed to take a minimum
of arguments (just the VM as this pointer). This is because RETURN_IF_EXCEPTION
is called from many places, and we would like to minimize code size bloating
from this change.
- Simplify paramaters of VMTraps::handleTraps().
NeedDebuggerBreak's callFrame argument was always vm.topCallFrame anyway.
So, the patch makes it explicit, and removes the callFrame parameter.
NeedWatchdogCheck's globalObject argument should have always been
vm.entryScope->globalObject(), and we can remove the globalObject parameter.
Before this, we pass in whichever globalObject was convenient to grab hold of.
However, the idea of the watchdog is to time out the current script executing
on the stack. Hence, it makes sense to identify thay script by the globalObject
in use at VM entry.
So far, the only clients that uses the watchdog mechanism only operates in
scenarios with only one globalObject anyway. So this formalization to use
VMEntryScope's globalObject does not change the expected behavior.
- Make the execution of termination more robust. Before reading this, please read the description of the Events in VMTraps.h first, especially the section on NeedTermination.
Here's the life cycle of a termination:
- a client requests termination of the current execution stack by calling VM::notifyNeedTermination(). notifyNeedTermination() does 2 things:
- fire the NeedTermination event on VMTraps.
- set the VM::m_terminationInProgress flag.
- Firing the NeedTermination event on VMTraps means setting the NeedTermination bit on VMTraps::m_trapBits. This bit will be polled by the mutator thread later at various designated points (including RETURN_IF_EXCEPTION, which we added in this patch).
Once the mutator sees the NeedTermination bit is set, it will clear the bit
and throw the TerminationException (see VMTraps::handleTraps()). This is
unless the mutator thread is currently in a DeferTermination scope (see (8)
below). If in a DeferTermination scope, then it will not throw the
TerminationException.
Since the NeedTermination bit is cleared, the VM will no longer call
VMTraps::handleTraps() to service the event. If the mutator thread is in
a DeferTermination scope, then on exiting the scope (at scope destruction),
the scope will see that VM::m_terminationInProgress is set, and throw the
deferred TerminationException then.
- The TerminationException will trigger unwinding out of the current stack until we get to the outermost VMEntryScope.
- At the the outermost VMEntryScope, we will clear VM::m_terminationInProgress if the NeedTermination bit in VMtraps::m_trapBits is cleared.
If the NeedTermination bit is set, then that means we haven't thrown the
TerminationException yet. Currently, clients expect that we must throw the
TerminationException if NeedTermination was requested (again, read comments
at the top of VMTraps.h).
If the NeedTermination bit is set, we'll leave VM::m_terminationInProgress
set until the next time we re-enter the VM and exit to the outermost
VMEntryScope.
- The purpose of VM::m_terminationInProgress is to provide a summary of the fact that the VM is in a state of trying to terminate the current stack.
Note that this state is first indicated by the NeedTermination bit being set
in VMTraps::m_trapBits. Then, in VMTraps::handleTraps(), the state is
handed of with the NeedTermination bit being cleared, and the
TerminationException being thrown.
While the VM is in this termination state, we need to prevent new DFG/FTL
JIT code from being compiled and run. The reason is the firing of the
NeedTermination event has invalidated DFG/FTL code on the stack, thereby
allowing their baseline / LLInt versions which have VMTraps polling checks
to run. We don't want to compile new DFG / FTL code and possibly get stuck
in loops in there before the termination is complete.
In operationOptimize(), we check if VM::m_terminationInProgress is set, and
prevent new DFG (and therefore FTL) code from being compiled if needed.
Note: it is easier to check a single flag, VM::m_terminationInProgress,
then to check both if the NeedTermination bit is set or if the
TerminationException is being being thrown.
- One complication of being able to service VMTraps in RETURN_IF_EXCEPTION checks is that some of our code (usually for lengthier initializations and bootstrapping) currently does not handle exceptions well, e.g. JSGlobalObject::init(). They rely on the code crashing if an exception is thrown while still initializing.
However, for a worker thread, a TerminationException (requested by the main
thread) may arrive before the initialization is complete. This can lead to
crashes because part of the initialization may be aborted in the presence of
an exception, while other parts still expect everything prior to have been
initialized correctly. For resource exhaustion cases (which is abnormal), it
is OK to crash. For the TerminationException (which can be part of normal
operation), we should not be crashing.
To work around this, we introduce a DeferTermination RAII scope object that we
deploy in this type of initialization code. With the scope in effect,
- if a TerminationException arrives but hasn't been thrown yet, it will be deferred till the scope ends before being thrown.
- if a TerminationException has already been thrown, the scope will stash the exception, clear it from the VM so that the initialization code can run to completion, and then re-throw the exception when the scope ends.
Currently, we only need to use the DeferTermination scope in a few places
where we know that initialization code will only run for a short period of time.
DeferTermination should not be used for code that can block waiting on an
external event for a long time. Obviously, doing so will prevent the VM
termination mechanism from working.
- Replaced llint_slow_path_check_if_exception_is_uncatchable_and_notify_profiler
and operationCheckIfExceptionIsUncatchableAndNotifyProfiler with
llint_slow_path_retrieve_and_clear_exception_if_catchable and
operationRetrieveAndClearExceptionIfCatchable.
The 2 runtime functions doesn't actually do anything to notify a profiler.
So, we drop that part of the name.
After returning from these runtime functions respectively, the previous LLInt
and JIT code, which calls these runtimes functions, would go on to load
VM::m_exception, and then store a nullptr there to clear it. This is wasteful.
This patch changes the runtime function to clear and return the Exception
instead. As a result, the calling LLInt and JIT code is simplified a bit.
Note also that clearing an exception now also entails clearing the
NeedExceptionHandling bit in VMTraps::m_trapBits in an atomic way. The above
change makes it easy to do this clearing with C++ code.
- Fix ScriptFunctionCall::call() to handle exceptions correctly. Previously,
it had one case where it propagates an exception, while another eats it.
Change this function to eat the exception in both cases. This is approproiate
because ScriptFunctionCall is only used to execute some Inspector instrumentation
calls. It doesn't make sense to propagate the exception back to user code.
- Fix the lazy initialization of JSGlobalObject::m_defaultCollator to be able to
handle the TerminationException.
- Not related to TerminationException, but this patch also fixes
MarkedArgumentBuffer::expandCapacity() to use Gigacage::tryMalloc() instead of
Gigacage::malloc(). This is needed as one of the fixes to make the
accompanying test case work.
This patch increases code size by 320K (144K for JSC, 176K for WebCore) measured
on x86_64.
- CMakeLists.txt:
- JavaScriptCore.xcodeproj/project.pbxproj:
- assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchTest32):
- assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::branchTest32):
- assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchTest32):
- assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchTest32):
- bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
- dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckTraps):
- ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps):
- interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeModuleProgram):
- interpreter/InterpreterInlines.h:
(JSC::Interpreter::execute):
- jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_check_traps):
- jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
- jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
- jit/JITOperations.h:
- llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
- llint/LLIntSlowPaths.h:
- llint/LowLevelInterpreter.asm:
- llint/LowLevelInterpreter32_64.asm:
- llint/LowLevelInterpreter64.asm:
- runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::expandCapacity):
- runtime/DeferTermination.h: Added.
(JSC::DeferTermination::DeferTermination):
(JSC::DeferTermination::~DeferTermination):
- runtime/ExceptionScope.h:
(JSC::ExceptionScope::exception const):
(JSC::ExceptionScope::exception): Deleted.
- runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::finishCreation):
- runtime/LazyPropertyInlines.h:
(JSC::ElementType>::callFunc):
- runtime/StringPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
- runtime/VM.cpp:
(JSC::VM::hasExceptionsAfterHandlingTraps):
(JSC::VM::clearException):
(JSC::VM::setException):
(JSC::VM::throwTerminationException):
(JSC::VM::throwException):
- runtime/VM.h:
(JSC::VM::terminationInProgress const):
(JSC::VM::setTerminationInProgress):
(JSC::VM::notifyNeedTermination):
(JSC::VM::DeferExceptionScope::DeferExceptionScope):
(JSC::VM::DeferExceptionScope::~DeferExceptionScope):
(JSC::VM::handleTraps): Deleted.
(JSC::VM::needTrapHandling): Deleted.
(JSC::VM::needTrapHandlingAddress): Deleted.
(JSC::VM::setException): Deleted.
(JSC::VM::clearException): Deleted.
- runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::~VMEntryScope):
- runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
(JSC::VMTraps::fireTrap):
(JSC::VMTraps::handleTraps):
(JSC::VMTraps::takeTopPriorityTrap):
(JSC::VMTraps::deferTermination):
(JSC::VMTraps::undoDeferTermination):
- runtime/VMTraps.h:
(JSC::VMTraps::onlyContainsAsyncEvents):
(JSC::VMTraps::needHandling const):
(JSC::VMTraps::trapBitsAddress):
(JSC::VMTraps::isDeferringTermination const):
(JSC::VMTraps::notifyGrabAllLocks):
(JSC::VMTraps::hasTrapBit):
(JSC::VMTraps::clearTrapBit):
(JSC::VMTraps::setTrapBit):
(JSC::VMTraps::Mask::Mask): Deleted.
(JSC::VMTraps::Mask::allEventTypes): Deleted.
(JSC::VMTraps::Mask::bits const): Deleted.
(JSC::VMTraps::Mask::init): Deleted.
(JSC::VMTraps::interruptingTraps): Deleted.
(JSC::VMTraps::needTrapHandling): Deleted.
(JSC::VMTraps::needTrapHandlingAddress): Deleted.
(JSC::VMTraps::hasTrapForEvent): Deleted.
(JSC::VMTraps::setTrapForEvent): Deleted.
(JSC::VMTraps::clearTrapForEvent): Deleted.
Source/WebCore:
- Add DeferTermination in WorkerOrWorkletScriptController::initScript(). This allows us to avoid having to make all exception checking in WorkerOrWorkletScriptController::initScript() very thorough and complete. Currently, they aren't.
- Fix WorkerOrWorkletScriptController::evaluate() to handle the TerminationException.
- Fix JSEventListener::handleEvent() to handle the TerminationException correctly. Previously, in one case, it was checking scope.exception() for the exception, but the exception has already been taken out of there.
- bindings/js/JSEventListener.cpp:
(WebCore::JSEventListener::handleEvent):
- workers/WorkerOrWorkletScriptController.cpp:
(WebCore::WorkerOrWorkletScriptController::evaluate):
(WebCore::WorkerOrWorkletScriptController::initScript):
- 5:31 AM Changeset in webkit [275796] by
-
- 3 edits in trunk/Source/WebCore
RenderFlexibleBox::m_hasDefiniteHeight should not need to be mutable
https://bugs.webkit.org/show_bug.cgi?id=224404
Reviewed by Antti Koivisto.
Let's just fix constness instead.
- rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::childIntrinsicLogicalWidth):
(WebCore::RenderFlexibleBox::crossAxisIntrinsicExtentForChild):
(WebCore::RenderFlexibleBox::useChildAspectRatio):
(WebCore::RenderFlexibleBox::childMainSizeIsDefinite):
(WebCore::RenderFlexibleBox::childCrossSizeIsDefinite):
(WebCore::RenderFlexibleBox::childHasIntrinsicMainAxisSize):
(WebCore::RenderFlexibleBox::childIntrinsicLogicalWidth const): Deleted.
(WebCore::RenderFlexibleBox::crossAxisIntrinsicExtentForChild const): Deleted.
(WebCore::RenderFlexibleBox::useChildAspectRatio const): Deleted.
(WebCore::RenderFlexibleBox::childMainSizeIsDefinite const): Deleted.
(WebCore::RenderFlexibleBox::childCrossSizeIsDefinite const): Deleted.
(WebCore::RenderFlexibleBox::childHasIntrinsicMainAxisSize const): Deleted.
- rendering/RenderFlexibleBox.h:
- 4:20 AM Changeset in webkit [275795] by
-
- 3 edits in trunk/Tools
Improve step description when compile-webkit step is skipped
https://bugs.webkit.org/show_bug.cgi?id=224373
Reviewed by Jonathan Bedard.
- CISupport/ews-build/steps.py:
(CompileWebKit.getResultSummary): Set custom summary when this step is skipped.
- CISupport/ews-build/steps_unittest.py: Updated unit-tests.
- 1:39 AM Changeset in webkit [275794] by
-
- 2 edits in trunk/Source/WebKit
Unreviewed, fix test crashes after r275779
https://bugs.webkit.org/show_bug.cgi?id=224305
rdar://71962196
- NetworkProcess/IndexedDB/WebIDBServer.cpp:
(WebKit::WebIDBServer::WebIDBServer): rolling back change on setting thread name as we see crash in
pthread_setname_np.