Timeline

Mar 31, 2018:

10:37 PM Changeset in webkit [230141] by Alan Bujtas

• 5 edits
  1 add in trunk/Tools

[LayoutReloaded] Floating box reduces line with in inline formatting context
​https://bugs.webkit.org/show_bug.cgi?id=184223

Reviewed by Antti Koivisto.

• LayoutReloaded/FormattingContext/FloatingContext.js:

(FloatingContext.prototype.left):
(FloatingContext.prototype.right):
(FloatingContext.prototype._mapDisplayMarginBoxToFormattingRoot):
(FloatingContext.prototype._mapBorderBoxToFormattingRoot):
(FloatingContext.prototype._mapContentBoxToFormattingRoot):
(FloatingContext.prototype.formattingRoot):
(FloatingContext.prototype._floatingState):
(FloatingContext.prototype._formattingRoot): Deleted.

• LayoutReloaded/FormattingContext/InlineFormatting/InlineFormattingContext.js:

(InlineFormattingContext.prototype._createNewLine):
(InlineFormattingContext.prototype._mapFloatingPosition):
(InlineFormattingContext):

• LayoutReloaded/FormattingState/FormattingState.js:

(FormattingState.prototype.displayBox):
(FormattingState):

• LayoutReloaded/test/index.html:
• LayoutReloaded/test/inline-formatting-context-with-floats.html: Added.

8:07 PM Changeset in webkit [230140] by Alan Bujtas

• 5 edits in trunk/Tools

[LayoutReloaded] InlineFormattingState should inherit the floating state from its parent formatting state
​https://bugs.webkit.org/show_bug.cgi?id=184220

Reviewed by Antti Koivisto.

If the block container box that initiates an inline formatting context also establishes a block context,
create a new float state, otherwise use the existing one.

• LayoutReloaded/FormattingContext/BlockFormatting/BlockFormattingContext.js:

(BlockFormattingContext.prototype._contentHeight):

• LayoutReloaded/FormattingState/InlineFormattingState.js:

(InlineFormattingState):

• LayoutReloaded/LayoutState.js:

(LayoutState.prototype.establishedFormattingState):
(LayoutState.prototype.formattingStateForBox):
(LayoutState.prototype.formattingState): Deleted.

• LayoutReloaded/Utils.js:

7:44 PM Changeset in webkit [230139] by Alan Bujtas

• 3 edits in trunk/Tools

[LayoutReloaded] FloatingContext does not need a parent formatting context.
​https://bugs.webkit.org/show_bug.cgi?id=184219

Reviewed by Antti Koivisto.

We don't need the formatting context in the FloatingContext now that margins are moved over to Display.Box.
This is in preparation for being able to create a FloatingContext for an inline formatting context,
when the inline context actually inherits the floating state from its formatting root.

• LayoutReloaded/FormattingContext/FloatingContext.js:

(FloatingContext):
(FloatingContext.prototype._availableSpace):
(FloatingContext.prototype._adjustedFloatingPosition):
(FloatingContext.prototype._addFloatingBox):
(FloatingContext.prototype._formattingContext): Deleted.

• LayoutReloaded/FormattingContext/FormattingContext.js:

(FormattingContext):

7:24 PM Changeset in webkit [230138] by Alan Bujtas

• 4 edits in trunk/Tools

[LayoutReloaded] Do not clone Display.Box for FloatingState stacks.
​https://bugs.webkit.org/show_bug.cgi?id=184218

Reviewed by Antti Koivisto.

Now that Display.Box is in a tree context, we can't just clone it for the purpose of caching its absolute position.

• LayoutReloaded/DisplayTree/Box.js:

(Display.Box.prototype.clone): Deleted.

• LayoutReloaded/FormattingContext/FloatingContext.js:

(FloatingContext.prototype._positionForFloating):
(FloatingContext.prototype._moveToNextVerticalPosition):
(FloatingContext.prototype._availableSpace):
(FloatingContext.prototype._findFloatingAtVerticalPosition):
(FloatingContext.prototype._adjustedFloatingPosition):
(FloatingContext.prototype._bottom):
(FloatingContext.prototype._addFloatingBox):
(FloatingContext.prototype._mapMarginBoxToFormattingRoot):
(FloatingContext.prototype._mapDisplayMarginBoxToFormattingRoot):

• LayoutReloaded/FormattingState/FloatingState.js:

(FloatingState.prototype.addFloating):

7:07 PM Changeset in webkit [230137] by Alan Bujtas

• 5 edits in trunk/Tools

[LayoutReloaded] Remove all FormattingContext::absolute*Box functions.
​https://bugs.webkit.org/show_bug.cgi?id=184215

Reviewed by Antti Koivisto.

Use Display.Box instead.

• LayoutReloaded/FormattingContext/BlockFormatting/BlockFormattingContext.js:

(BlockFormattingContext.prototype._computeOutOfFlowPosition):

• LayoutReloaded/FormattingContext/FloatingContext.js:

(FloatingContext.prototype._availableSpace):
(FloatingContext.prototype._adjustedFloatingPosition):
(FloatingContext.prototype._mapBorderBoxToFormattingRoot):
(FloatingContext.prototype._mapContentBoxToFormattingRoot):

• LayoutReloaded/FormattingContext/FormattingContext.js:

(FormattingContext.prototype.absoluteBorderBox): Deleted.
(FormattingContext.prototype.absolutePaddingBox): Deleted.
(FormattingContext.prototype.absoluteContentBox): Deleted.
(FormattingContext.prototype._toAbsolutePosition): Deleted.
(FormattingContext.prototype._toRootAbsolutePosition): Deleted.

• LayoutReloaded/Utils.js:

(Utils.mapPosition):
(Utils.marginBox):
(Utils.borderBox):
(Utils.contentBox):

6:12 PM Changeset in webkit [230136] by Alan Bujtas

• 4 edits in trunk/Tools

[LayoutReloaded] Remove FormattingContext::absoluteMarginBox
​https://bugs.webkit.org/show_bug.cgi?id=184213

Reviewed by Antti Koivisto.

Display.Box already has the margin values.

• LayoutReloaded/FormattingContext/FloatingContext.js:

(FloatingContext.prototype._positionForFloating):
(FloatingContext.prototype._addFloatingBox):
(FloatingContext.prototype._mapMarginBoxToFormattingRoot):
(FloatingContext.prototype._formattingRoot):

• LayoutReloaded/FormattingContext/FormattingContext.js:

(FormattingContext.prototype.absoluteMarginBox): Deleted.

• LayoutReloaded/Utils.js:

(Utils.marginBox):

5:50 PM Changeset in webkit [230135] by Alan Bujtas

• 4 edits in trunk/Tools

[layoutReloaded] Introduce margin to Display.Box
​https://bugs.webkit.org/show_bug.cgi?id=184212

Reviewed by Antti Koivisto.

This is in preparation for moving margin box out of formatting context to Display.Box.

• LayoutReloaded/DisplayTree/Box.js:

(Display.Box):
(Display.Box.prototype.setRect):
(Display.Box.prototype.setTopLeft):
(Display.Box.prototype.setTop):
(Display.Box.prototype.setLeft):
(Display.Box.prototype.setSize):
(Display.Box.prototype.setWidth):
(Display.Box.prototype.setHeight):
(Display.Box.prototype.width):
(Display.Box.prototype.setMarginTop):
(Display.Box.prototype.setMarginLeft):
(Display.Box.prototype.setMarginBottom):
(Display.Box.prototype.setMarginRight):
(Display.Box.prototype.marginTop):
(Display.Box.prototype.marginLeft):
(Display.Box.prototype.marginBottom):
(Display.Box.prototype.marginRight):
(Display.Box.prototype.marginBox):

• LayoutReloaded/FormattingContext/FormattingContext.js:

(FormattingContext.prototype.absoluteMarginBox):
(FormattingContext.prototype._addToLayoutQueue):

• LayoutReloaded/FormattingState/FormattingState.js:

(FormattingState.prototype.createDisplayBox):

4:39 PM Changeset in webkit [230134] by Alan Bujtas

• 3 edits in trunk/Tools

[LayoutReloaded] Add tree context to Display.Box
​https://bugs.webkit.org/show_bug.cgi?id=184211

Reviewed by Antti Koivisto.

This is preparation for using the Display.Box tree to resolve absolute coordinates.

• LayoutReloaded/DisplayTree/Box.js:

(Display.Box):
(Display.Box.prototype.setParent):
(Display.Box.prototype.setNextSibling):
(Display.Box.prototype.setPreviousSibling):
(Display.Box.prototype.setFirstChild):
(Display.Box.prototype.setLastChild):
(Display.Box.prototype.parent):
(Display.Box.prototype.nextSibling):
(Display.Box.prototype.previousSibling):
(Display.Box.prototype.firstChild):
(Display.Box.prototype.lastChild):

• LayoutReloaded/FormattingState/FormattingState.js:

(FormattingState.prototype.createDisplayBox):

10:32 AM Changeset in webkit [230133] by jmarcell@apple.com

• 5 edits in tags/Safari-606.1.11.2/Source

Cherry-pick r230128. rdar://problem/39057006

REGRESSION (r229828): Facebook login popup is blank
​https://bugs.webkit.org/show_bug.cgi?id=184206
<rdar://problem/39057006>

Reviewed by Wenson Hsieh.

Source/WebCore:

Since r229828, we freeze the layer tree during the navigation policy check.
We freeze in WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction()
and unfreeze in WebFrameLoaderClient::didDecidePolicyForNavigationAction().

WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction() gets called
from PolicyChecker::checkNavigationPolicy() which has 3 call sites in
FrameLoader and one in DocumentLoader for redirects. The call sites in
FrameLoader were taking care of calling didDecidePolicyForNavigationAction()
on the FrameLoaderClient in their completion handler, but the DocumentLoader
call site was failing to do so. As a result, the layer tree would stay frozen.

To make this a lot less error prone, I moved the call to
WebFrameLoaderClient::didDecidePolicyForNavigationAction() to
PolicyChecker::checkNavigationPolicy(), inside the completion handler passed
to WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction(). This way,
even if new code starts calling PolicyChecker::checkNavigationPolicy(), we
do not need to worry about letting the client know when the policy decision
is made.

No new tests, covered by existing redirection tests with the
new assertion I added.

• loader/FrameLoader.cpp: (WebCore::FrameLoader::continueFragmentScrollAfterNavigationPolicy): (WebCore::FrameLoader::continueLoadAfterNavigationPolicy):
• loader/PolicyChecker.cpp: (WebCore::PolicyChecker::checkNavigationPolicy):

Source/WebKit:

Add assertion to make sure we never try to do a policy check to
a resource response while a policy check for a navigation is
pending. This assertion was being hit by several of our redirection
tests without my fix.

• WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForResponse):

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@230128 268f45cc-cd09-0410-ab3c-d52691b4dbfc

10:26 AM Changeset in webkit [230132] by jmarcell@apple.com

• 7 edits in tags/Safari-606.1.11.2/Source

Versioning.

10:22 AM Changeset in webkit [230131] by jmarcell@apple.com

• 1 copy in tags/Safari-606.1.11.2

New tag.

8:55 AM Changeset in webkit [230130] by fpizlo@apple.com

• 12 edits in trunk/Source

Strings and Vectors shouldn't do index masking
​https://bugs.webkit.org/show_bug.cgi?id=184193

Reviewed by Mark Lam.

Source/JavaScriptCore:

• dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):

• ftl/FTLAbstractHeapRepository.h:
• ftl/FTLLowerDFGToB3.cpp:

(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):

• jit/ThunkGenerators.cpp:

(JSC::stringCharLoad):

Source/WTF:

• wtf/SizeLimits.cpp:
• wtf/Vector.h:

(WTF::VectorBufferBase::allocateBuffer):
(WTF::VectorBufferBase::tryAllocateBuffer):
(WTF::VectorBufferBase::reallocateBuffer):
(WTF::VectorBufferBase::deallocateBuffer):
(WTF::VectorBufferBase::releaseBuffer):
(WTF::VectorBufferBase::VectorBufferBase):
(WTF::VectorBuffer::allocateBuffer):
(WTF::VectorBuffer::tryAllocateBuffer):
(WTF::VectorBuffer::swap):
(WTF::VectorBuffer::restoreInlineBufferIfNeeded):
(WTF::Vector::at):
(WTF::Vector::at const):
(WTF::VectorBufferBase::updateMask): Deleted.

• wtf/text/StringImpl.h:

(WTF::StringImpl::flagIsSymbol):
(WTF::StringImpl::length const):
(WTF::StringImplShape::StringImplShape):
(WTF::StringImpl::at const):
(WTF::StringImpl::tailOffset):
(WTF::StringImpl::maskOffset): Deleted.
(WTF::StringImpl::mask const): Deleted.

• wtf/text/StringView.h:

(WTF::StringView::StringView):
(WTF::StringView::operator=):
(WTF::StringView::initialize):
(WTF::StringView::clear):
(WTF::StringView::operator[] const):

• wtf/text/WTFString.h:

(WTF::String::length const):
(WTF::String::mask const): Deleted.

12:04 AM Changeset in webkit [230129] by mark.lam@apple.com

• 58 edits in trunk/Source

Add pointer profiling support in baseline JIT and supporting files.
​https://bugs.webkit.org/show_bug.cgi?id=184200
<rdar://problem/39057300>

Reviewed by Filip Pizlo.

Source/JavaScriptCore:

1. To simplify pointer profiling support, vmEntryToJavaScript() now always enters the code via the arity check entry.
2. To accommodate (1), all JITCode must now populate their arity check entry code pointers as well. For native code, programs, evals, and modules that don't do arity check, we set the normal entry as the arity check entry (though with the CodeEntryWithArityCheckPtrTag profile instead).

• assembler/AbstractMacroAssembler.h:
• assembler/LinkBuffer.h:

(JSC::LinkBuffer::locationOfNearCall):

• assembler/MacroAssemblerARM64.h:

(JSC::MacroAssemblerARM64::readCallTarget):
(JSC::MacroAssemblerARM64::linkCall):

• bytecode/AccessCase.cpp:

(JSC::AccessCase::generateImpl):

• bytecode/AccessCaseSnippetParams.cpp:

(JSC::SlowPathCallGeneratorWithArguments::generateImpl):

• bytecode/CodeBlock.cpp:

(JSC::CodeBlock::addJITAddIC):
(JSC::CodeBlock::addJITMulIC):
(JSC::CodeBlock::addJITSubIC):
(JSC::CodeBlock::addJITNegIC):

• bytecode/CodeBlock.h:

(JSC::CodeBlock::addMathIC):

• bytecode/InlineAccess.cpp:

(JSC::InlineAccess::rewireStubAsJump):

• bytecode/LLIntCallLinkInfo.h:

(JSC::LLIntCallLinkInfo::unlink):
(): Deleted.

• bytecode/PolymorphicAccess.cpp:

(JSC::AccessGenerationState::emitExplicitExceptionHandler):
(JSC::PolymorphicAccess::regenerate):

• dfg/DFGJITFinalizer.cpp:

(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):

• dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileArithSub):
(JSC::DFG::SpeculativeJIT::compileArithNegate):
(JSC::DFG::SpeculativeJIT::compileArithMul):
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):

• disassembler/ARM64Disassembler.cpp:

(JSC::tryToDisassemble):

• ftl/FTLJITFinalizer.cpp:

(JSC::FTL::JITFinalizer::finalizeCommon):

• ftl/FTLLowerDFGToB3.cpp:

(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
(JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):

• heap/JITStubRoutineSet.h:

(JSC::JITStubRoutineSet::mark):

• jit/AssemblyHelpers.cpp:

(JSC::AssemblyHelpers::callExceptionFuzz):
(JSC::AssemblyHelpers::debugCall):

• jit/AssemblyHelpers.h:

(JSC::AssemblyHelpers::emitFunctionPrologue):

• jit/CCallHelpers.cpp:

(JSC::CCallHelpers::ensureShadowChickenPacket):

• jit/CCallHelpers.h:

(JSC::CCallHelpers::prepareForTailCallSlow):

• jit/CallFrameShuffler.cpp:

(JSC::CallFrameShuffler::prepareForTailCall):

• jit/ExecutableAllocator.cpp:

(JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):

• jit/ExecutableAllocator.h:

(JSC::performJITMemcpy):

• jit/JIT.cpp:

(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):

• jit/JITArithmetic.cpp:

(JSC::JIT::emit_op_negate):
(JSC::JIT::emit_op_add):
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
(JSC::JIT::emit_op_mul):
(JSC::JIT::emit_op_sub):

• jit/JITCode.cpp:

(JSC::JITCode::execute):
(JSC::JITCodeWithCodeRef::executableAddressAtOffset):
(JSC::DirectJITCode::DirectJITCode):
(JSC::DirectJITCode::initializeCodeRef):
(JSC::NativeJITCode::addressForCall):

• jit/JITExceptions.cpp:

(JSC::genericUnwind):

• jit/JITMathIC.h:

(JSC::isProfileEmpty):
(JSC::JITBinaryMathIC::JITBinaryMathIC):
(JSC::JITUnaryMathIC::JITUnaryMathIC):

• jit/JITOpcodes.cpp:

(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emitSlow_op_has_indexed_property):

• jit/JITOpcodes32_64.cpp:

(JSC::JIT::privateCompileHasIndexedProperty):

• jit/JITOperations.cpp:

(JSC::getByVal):
(JSC::tryGetByValOptimize):

• jit/JITPropertyAccess.cpp:

(JSC::JIT::stringGetByValStubGenerator):
(JSC::JIT::emitGetByValWithCachedId):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emitSlow_op_try_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_put_by_id):
(JSC::JIT::privateCompileGetByVal):
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutByValWithCachedId):

• jit/JITThunks.cpp:

(JSC::JITThunks::hostFunctionStub):

• jit/Repatch.cpp:

(JSC::tryCacheGetByID):
(JSC::repatchGetByID):
(JSC::appropriateOptimizingPutByIdFunction):
(JSC::tryCachePutByID):
(JSC::repatchPutByID):
(JSC::linkFor):
(JSC::revertCall):
(JSC::linkPolymorphicCall):
(JSC::resetGetByID):
(JSC::resetPutByID):

• jit/Repatch.h:
• jit/SpecializedThunkJIT.h:

(JSC::SpecializedThunkJIT::finalize):
(JSC::SpecializedThunkJIT::callDoubleToDouble):

• jit/ThunkGenerators.cpp:

(JSC::emitPointerValidation):
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::slowPathFor):
(JSC::linkCallThunkGenerator): Deleted.
(JSC::linkPolymorphicCallThunkGenerator): Deleted.
(JSC::virtualThunkFor): Deleted.
(JSC::nativeForGenerator): Deleted.
(JSC::nativeCallGenerator): Deleted.
(JSC::nativeTailCallGenerator): Deleted.
(JSC::nativeTailCallWithoutSavedTagsGenerator): Deleted.
(JSC::nativeConstructGenerator): Deleted.
(JSC::internalFunctionCallGenerator): Deleted.
(JSC::internalFunctionConstructGenerator): Deleted.
(JSC::arityFixupGenerator): Deleted.
(JSC::unreachableGenerator): Deleted.
(JSC::stringCharLoad): Deleted.
(JSC::charToString): Deleted.
(JSC::charCodeAtThunkGenerator): Deleted.
(JSC::charAtThunkGenerator): Deleted.
(JSC::fromCharCodeThunkGenerator): Deleted.
(JSC::clz32ThunkGenerator): Deleted.
(JSC::sqrtThunkGenerator): Deleted.
(JSC::floorThunkGenerator): Deleted.
(JSC::ceilThunkGenerator): Deleted.
(JSC::truncThunkGenerator): Deleted.
(JSC::roundThunkGenerator): Deleted.
(JSC::expThunkGenerator): Deleted.
(JSC::logThunkGenerator): Deleted.
(JSC::absThunkGenerator): Deleted.
(JSC::imulThunkGenerator): Deleted.
(JSC::randomThunkGenerator): Deleted.
(JSC::boundThisNoArgsFunctionCallGenerator): Deleted.

• llint/LLIntData.cpp:

(JSC::LLInt::initialize):

• llint/LLIntData.h:

(JSC::LLInt::getCodePtr):

• llint/LLIntEntrypoint.cpp:

(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):

• llint/LLIntSlowPaths.cpp:

(JSC::LLInt::setUpCall):

• llint/LLIntThunks.cpp:

(JSC::LLInt::generateThunkWithJumpTo):

• llint/LowLevelInterpreter.asm:
• llint/LowLevelInterpreter32_64.asm:
• llint/LowLevelInterpreter64.asm:
• runtime/ExecutableBase.h:
• runtime/NativeExecutable.cpp:

(JSC::NativeExecutable::finishCreation):

• runtime/NativeFunction.h:

(JSC::TaggedNativeFunction::TaggedNativeFunction):
(JSC::TaggedNativeFunction::operator NativeFunction):

• runtime/PropertySlot.h:

(JSC::PropertySlot::setCustom):
(JSC::PropertySlot::setCacheableCustom):

• runtime/PtrTag.h:
• runtime/PutPropertySlot.h:

(JSC::PutPropertySlot::setCustomValue):
(JSC::PutPropertySlot::setCustomAccessor):

• runtime/SamplingProfiler.cpp:

(JSC::SamplingProfiler::takeSample):

• runtime/VMTraps.cpp:

(JSC::SignalContext::SignalContext):
(JSC::VMTraps::tryInstallTrapBreakpoints):

• tools/SigillCrashAnalyzer.cpp:

(JSC::installCrashHandler):

• yarr/YarrJIT.cpp:

(JSC::Yarr::YarrGenerator::generateTryReadUnicodeCharacterHelper):
(JSC::Yarr::YarrGenerator::generateEnter):

Source/WTF:

• wtf/PointerPreparations.h:
• Remove WTF_PREPARE_FUNCTION_POINTER_FOR_EXECUTION. It is no longer needed.

Mar 30, 2018:

11:44 PM Changeset in webkit [230128] by Chris Dumez

• 5 edits in trunk/Source

REGRESSION (r229828): Facebook login popup is blank
​https://bugs.webkit.org/show_bug.cgi?id=184206
<rdar://problem/39057006>

Reviewed by Wenson Hsieh.

Source/WebCore:

Since r229828, we freeze the layer tree during the navigation policy check.
We freeze in WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction()
and unfreeze in WebFrameLoaderClient::didDecidePolicyForNavigationAction().

WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction() gets called
from PolicyChecker::checkNavigationPolicy() which has 3 call sites in
FrameLoader and one in DocumentLoader for redirects. The call sites in
FrameLoader were taking care of calling didDecidePolicyForNavigationAction()
on the FrameLoaderClient in their completion handler, but the DocumentLoader
call site was failing to do so. As a result, the layer tree would stay frozen.

To make this a lot less error prone, I moved the call to
WebFrameLoaderClient::didDecidePolicyForNavigationAction() to
PolicyChecker::checkNavigationPolicy(), inside the completion handler passed
to WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction(). This way,
even if new code starts calling PolicyChecker::checkNavigationPolicy(), we
do not need to worry about letting the client know when the policy decision
is made.

No new tests, covered by existing redirection tests with the
new assertion I added.

• loader/FrameLoader.cpp:

(WebCore::FrameLoader::continueFragmentScrollAfterNavigationPolicy):
(WebCore::FrameLoader::continueLoadAfterNavigationPolicy):

• loader/PolicyChecker.cpp:

(WebCore::PolicyChecker::checkNavigationPolicy):

Source/WebKit:

Add assertion to make sure we never try to do a policy check to
a resource response while a policy check for a navigation is
pending. This assertion was being hit by several of our redirection
tests without my fix.

• WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:

(WebKit::WebFrameLoaderClient::dispatchDecidePolicyForResponse):

10:14 PM Changeset in webkit [230127] by webkit@devinrousso.com

• 13 edits
  2 adds in trunk

Web Inspector: tint all pixels drawn by shader program when hovering ShaderProgramTreeElement
​https://bugs.webkit.org/show_bug.cgi?id=175223

Reviewed by Matt Baker.

Source/JavaScriptCore:

• inspector/protocol/Canvas.json:

Add setShaderProgramHighlighted command that will cause a blend to be applied to the
canvas if the given shader program is active immediately before drawArrays or drawElements
is called. The blend is removed and the previous value is applied once the draw is complete.

Source/WebCore:

Test: inspector/canvas/setShaderProgramHighlighted.html

• html/canvas/InspectorShaderProgram.h:

(WebCore::InspectorShaderProgram::highlighted):
(WebCore::InspectorShaderProgram::setHighlighted):

• html/canvas/WebGLRenderingContextBase.cpp:

(WebCore::InspectorScopedShaderProgramHighlight::InspectorScopedShaderProgramHighlight):
(WebCore::InspectorScopedShaderProgramHighlight::~InspectorScopedShaderProgramHighlight):
(WebCore::InspectorScopedShaderProgramHighlight::showHighlight):
(WebCore::InspectorScopedShaderProgramHighlight::hideHighlight):
(WebCore::InspectorScopedShaderProgramHighlight::saveBlendValue):
(WebCore::InspectorScopedShaderProgramHighlight::hasBufferBinding):
(WebCore::InspectorScopedShaderProgramHighlight::hasFramebufferParameterAttachment):
(WebCore::WebGLRenderingContextBase::drawArrays):
(WebCore::WebGLRenderingContextBase::drawElements):
If the current shader program has been marked as highlighted, apply a blend right before
drawArrays and drawElements is called, tinting the resulting pixels so that they are
visually distinguished from pixels drawn by other shader programs.

• inspector/InspectorCanvasAgent.h:
• inspector/InspectorCanvasAgent.cpp:

(WebCore::InspectorCanvasAgent::setShaderProgramHighlighted):
(WebCore::InspectorCanvasAgent::isShaderProgramHighlighted):

• inspector/InspectorInstrumentation.h:
• inspector/InspectorInstrumentation.cpp:

(WebCore::InspectorInstrumentation::isShaderProgramHighlighted):
(WebCore::InspectorInstrumentation::isShaderProgramHighlightedImpl):

Source/WebInspectorUI:

• UserInterface/Models/ShaderProgram.js:

(WI.ShaderProgram):
(WI.ShaderProgram.prototype.showHighlight):
(WI.ShaderProgram.prototype.hideHighlight):

• UserInterface/Views/ShaderProgramTreeElement.js:

(WI.ShaderProgramTreeElement.prototype.onattach):
(WI.ShaderProgramTreeElement.prototype._handleMouseOver):
(WI.ShaderProgramTreeElement.prototype._handleMouseOut):
Whenever a ShaderProgramTreeElement is hovered, highlight the corresponding shader program
by tinting the pixels it draws via a blend.

LayoutTests:

• inspector/canvas/setShaderProgramHighlighted-expected.txt: Added.
• inspector/canvas/setShaderProgramHighlighted.html: Added.

8:09 PM Changeset in webkit [230126] by Ryan Haddad

• 2 edits in trunk/Source/WebKit

Unreviewed, rolling out r230125.

Build fix broke more builds.

Reverted changeset:

"Unreviewed build fix, remove unused lambda capture."
​https://trac.webkit.org/changeset/230125

7:54 PM Changeset in webkit [230125] by Ryan Haddad

• 2 edits in trunk/Source/WebKit

Unreviewed build fix, remove unused lambda capture.

• NetworkProcess/NetworkResourceLoader.cpp:

(WebKit::NetworkResourceLoader::retrieveCacheEntry):

5:13 PM Changeset in webkit [230124] by Ryan Haddad

• 2 edits in trunk/LayoutTests

Skip http/tests/resourceLoadStatistics/prevalent-resource-with-user-interaction-timeout.html
​https://bugs.webkit.org/show_bug.cgi?id=178472

Unreviewed test gardening.

• platform/mac-wk2/TestExpectations:

5:13 PM Changeset in webkit [230123] by Ryan Haddad

• 2 edits in trunk/LayoutTests

Mark imported/w3c/web-platform-tests/html/browsers/offline/appcache/workers/appcache-worker.html as flaky.
​https://bugs.webkit.org/show_bug.cgi?id=184198

Unreviewed test gardening.

• TestExpectations:

5:12 PM Changeset in webkit [230122] by Wenson Hsieh

• 7 edits in trunk/Source

[Extra zoom mode] Adopt list view controller UI for numeric input types
​https://bugs.webkit.org/show_bug.cgi?id=184184
<rdar://problem/37238916>

Reviewed by Timothy Hatcher.

Source/WebCore:

Add a localized string for the OK button shown on number pads in extra zoomed form controls.

• English.lproj/Localizable.strings:
• platform/LocalizedStrings.cpp:

(WebCore::numberPadOKButtonTitle):

• platform/LocalizedStrings.h:

Source/WebKit:

Remove existing logic for presenting a number pad view controller, since number pads will now be handled as a
special case of general text form controls in extra zoom mode.

• UIProcess/ios/WKContentViewInteraction.h:
• UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView presentViewControllerForCurrentAssistedNode]):
(-[WKContentView dismissAllInputViewControllers]):
(-[WKContentView _wheelChangedWithEvent:]):

5:09 PM Changeset in webkit [230121] by mitz@apple.com

• 28 edits in trunk/Source/WebKit

Update availability annotations to match the macOS 10.13.4 and iOS 11.3 GM SDKs
​https://bugs.webkit.org/show_bug.cgi?id=184173

Reviewed by Alex Christensen.

Changed WK_MAC_TBA and WK_IOS_TBA to 10.13.4 and 11.3, respectively, in all declarations that
appear in the GM SDKs.

• Shared/API/Cocoa/_WKNSWindowExtras.h:
• UIProcess/API/Cocoa/WKNavigationDelegatePrivate.h:
• UIProcess/API/Cocoa/WKOpenPanelParameters.h:
• UIProcess/API/Cocoa/WKOpenPanelParametersPrivate.h:
• UIProcess/API/Cocoa/WKPreferencesPrivate.h:
• UIProcess/API/Cocoa/WKProcessPoolPrivate.h:
• UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
• UIProcess/API/Cocoa/WKViewPrivate.h:
• UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h:
• UIProcess/API/Cocoa/WKWebViewPrivate.h:
• UIProcess/API/Cocoa/WKWebsiteDataRecord.h:
• UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:
• UIProcess/API/Cocoa/_WKApplicationManifest.h:
• UIProcess/API/Cocoa/_WKAttachment.h:
• UIProcess/API/Cocoa/_WKAutomationSession.h:
• UIProcess/API/Cocoa/_WKAutomationSessionConfiguration.h:
• UIProcess/API/Cocoa/_WKDownload.h:
• UIProcess/API/Cocoa/_WKDownloadDelegate.h:
• UIProcess/API/Cocoa/_WKFocusedElementInfo.h:
• UIProcess/API/Cocoa/_WKFullscreenDelegate.h:
• UIProcess/API/Cocoa/_WKProcessPoolConfiguration.h:
• UIProcess/API/Cocoa/_WKRemoteWebInspectorViewController.h:
• UIProcess/API/Cocoa/_WKVisitedLinkStore.h:
• UIProcess/API/Cocoa/_WKWebsiteDataStoreConfiguration.h:
• UIProcess/API/Cocoa/_WKWebsitePolicies.h:
• WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInNodeHandlePrivate.h:
• WebProcess/InjectedBundle/API/mac/WKDOMDocument.h:

4:57 PM Changeset in webkit [230120] by rniwa@webkit.org

• 5 edits in trunk

Copying a list from Microsoft Word to TinyMCE fails when mso-list is the first property
​https://bugs.webkit.org/show_bug.cgi?id=182938
<rdar://problem/37683007>

Reviewed by Wenson Hsieh.

Source/WebCore:

Made the logic to detect Microsoft Word's mso-list CSS property more generic by detecting
inline styles which start with "mso-list:" and one which line-break right before it: "\nmso-list:"

Tests: PasteHTML.PreservesMSOList

• editing/markup.cpp:

(WebCore::StyledMarkupAccumulator::shouldPreserveMSOListStyleForElement):

Tools:

Added more assertions to PasteHTML.PreservesMSOList for preserving an inline style which starts with mso-list
or the one which line-breaks right before it.

• TestWebKitAPI/Tests/WebKitCocoa/PasteHTML.mm:
• TestWebKitAPI/Tests/WebKitCocoa/mso-list.html:

4:12 PM Changeset in webkit [230119] by jfbastien@apple.com

• 5 edits
  1 add in trunk

WebAssembly compilation from DataView

2:50 PM Changeset in webkit [230118] by youenn@apple.com

• 5 edits
  5 adds in trunk

NetworkLoadChecker should upgrade redirects if needed
​https://bugs.webkit.org/show_bug.cgi?id=184098

Reviewed by Chris Dumez.

LayoutTests/imported/w3c:

• web-platform-tests/beacon/resources/beacon-preflight.py: Added.
• web-platform-tests/beacon/resources/redirect.py: Added.
• web-platform-tests/beacon/resources/upgrade-iframe.html: Added.
• web-platform-tests/beacon/resources/upgrade-redirect-iframe.html: Added.
• web-platform-tests/beacon/upgrade-beacon.https-expected.txt: Added.
• web-platform-tests/beacon/upgrade-beacon.https.html: Added.

Source/WebCore:

Test: imported/w3c/web-platform-tests/beacon/upgrade-beacon.https.html

• page/csp/ContentSecurityPolicy.h:

Source/WebKit:

In case of redirections, upgrade URL according CSP.

• NetworkProcess/NetworkLoadChecker.cpp:

(WebKit::NetworkLoadChecker::checkRequest):
(WebKit::NetworkLoadChecker::contentSecurityPolicy const):

2:01 PM Changeset in webkit [230117] by dbates@webkit.org

• 5 edits
  2 adds in trunk

ASSERTION FAILED: ASSERT(!containsImage

MIMETypeRegistry::isSupportedImageResourceMIMEType([resource MIMEType])) in -[NSPasteboard(WebExtras) _web_writePromisedRTFDFromArchive:containsImage:]

​https://bugs.webkit.org/show_bug.cgi?id=184161

Reviewed by Per Arne Vollan.

.:

• ManualTests/DragInlinePDFImageDocument.html: Added.
• ManualTests/resources/simple.pdf: Added.

Source/WebCore:

Fixes an assertion failure when quiting an app that uses a Legacy WebKit web view
after dragging-and-dropping a PDF embedded using an HTML image element into the
same web view.

When performing a drag-and-drop of a PDF document image (WebCore::PDFDocumentImage) we create a WebArchive
from the main frame's WebHTMLView and promise AppKit that will provide a Rich Text Format (RTF) document
from this archive if needed. For some reason, on app termination AppKit requests that the WebHTMLView
fullfill its RTF document promise for the WebArchive created at the start of the drag operation. WebKit
expects that the created WebArchive is either for an inline image (e.g. <img>) or an image document that
has a supported image resource MIME type (by querying MIMETypeRegistry::isSupportedImageResourceMIMEType())
and checks for these cases in this order. PDF/PostScript are not listed in the set of supported image
resource MIME types. So, the first check fails and WebKit assumes that the WebArchive was created from
an image document of a supported image resource MIME type. However, the WebArchive was created from a
WebHTMLView and has MIME type text/html. Therefore the assertion fails. We need to add PDF and PostScript
to the set of supported image resource MIME types so that WebKit does not fall back to the WebHTMLView
code path. Historically, PDF and PostScript were in the set supported image resource MIME types. Over time
the set of MIME types for image resouces (images loaded as a document) became identical to the set of MIME
types for images loaded inline (e.g. <img>) and this set omitted the MIME types for PDF and PostScript.

Additionally it is sufficient to implement MIMETypeRegistry::isSupportedImageResourceMIMEType() in terms
of MIMETypeRegistry::isSupportedImageMIMEType() and MIMETypeRegistry::isPDFOrPostScriptMIMEType() instead
of allocating a dedicated HashSet for the supported image resource MIME types (as we currently do).

• dom/DOMImplementation.cpp:

(WebCore::DOMImplementation::createDocument): Assert that PDF is a supported image MIME type before
instantiating an ImageDocument.

• platform/MIMETypeRegistry.cpp:

(WebCore::initializeSupportedImageMIMETypes): Remove unnecessary allocation of a HashSet for the support
image resource MIME types.
(WebCore::MIMETypeRegistry::isSupportedImageResourceMIMEType): Write in terms of MIMETypeRegistry::isSupportedImageMIMEType()
and MIMETypeRegistry::isPDFOrPostScriptMIMEType().
(WebCore::MIMETypeRegistry::getSupportedImageResourceMIMETypes): Deleted.

• platform/MIMETypeRegistry.h:

1:46 PM Changeset in webkit [230116] by jfbastien@apple.com

• 2 edits in trunk/Source/WTF

WorkQueueWin: don't move rvalues
​https://bugs.webkit.org/show_bug.cgi?id=184190
<rdar://problem/39049850>

Reviewed by Mark Lam.

As part of #184167 optional is now more frequently an rvalue
reference, and moving its .value() is not a thing that should be
done anymore.

• wtf/win/WorkQueueWin.cpp:

(WTF::WorkQueue::unregisterAndCloseHandle):

1:31 PM Changeset in webkit [230115] by fpizlo@apple.com

• 3 edits
  1 add in trunk

Bytecode generator should not get_from_scope something that may be a hole into a variable that is already live
​https://bugs.webkit.org/show_bug.cgi?id=184189

Reviewed by JF Bastien.

JSTests:

• stress/load-hole-from-scope-into-live-var.js: Added.

(result.eval.try.switch):
(catch):

Source/JavaScriptCore:

• bytecompiler/NodesCodegen.cpp:

(JSC::ResolveNode::emitBytecode):

1:25 PM Changeset in webkit [230114] by Ryan Haddad

• 2 edits in trunk/LayoutTests

Mark inspector/unit-tests/debounce.html as flaky.
​https://bugs.webkit.org/show_bug.cgi?id=184057

Unreviewed test gardening.

• platform/mac/TestExpectations:

12:16 PM Changeset in webkit [230113] by jfbastien@apple.com

• 8 edits in trunk/Source

Remove CXX_REFERENCE_QUALIFIED_FUNCTIONS and optional's equivalent
​https://bugs.webkit.org/show_bug.cgi?id=184167
<rdar://problem/39023130>

Reviewed by Yusuke Suzuki.

Remove COMPILER_SUPPORTS(CXX_REFERENCE_QUALIFIED_FUNCTIONS), it's
supported by all compilers WebKit supports (it's a C++11 feature,
*detection* of it with has_extension was added to clang on May
13th 2011, and VS2015 / GCC support it).

Optional.h had a similar thing, ditch it too.

• wtf/Compiler.h:
• wtf/Optional.h:

(std::optional::contained_val const):
(std::optional::contained_val):

• wtf/Ref.h:
• wtf/RefPtr.h:
• wtf/text/WTFString.cpp:
• wtf/text/WTFString.h:

11:45 AM Changeset in webkit [230112] by graouts@webkit.org

• 7 edits in trunk

[Web Animations] CSSTransition objects should have fill: backwards to allow seeking prior to start time
​https://bugs.webkit.org/show_bug.cgi?id=184129

Reviewed by Dean Jackson.

Source/WebCore:

In order to allow a CSS Transition to be seeked prior to its start time, it needs to have its fill mode set
to backwards. Adding code to set the fill mode in CSSTransition::initialize() yields early timing model
invalidation and we could get in a situation where stylesWouldYieldNewCSSTransitionsBlendingKeyframes()
was called before we had a chance to create blending keyframes for a CSS transitions, since the call
to create blending keyframes is made after the call to initialize(), so we now cater for this case.

• animation/CSSTransition.cpp:

(WebCore::CSSTransition::initialize):

• animation/CSSTransition.h:
• animation/KeyframeEffectReadOnly.cpp:

(WebCore::KeyframeEffectReadOnly::stylesWouldYieldNewCSSTransitionsBlendingKeyframes const):

LayoutTests:

Make one test opt into CSS Animations and CSS Transitions as Web Animations and fix expectations for a CSSTransition
test which mistakenly assumes the fill to be "none".

• transitions/transition-in-delay-phase.html:
• webanimations/css-transitions.html:

10:46 AM Changeset in webkit [230111] by jmarcell@apple.com

• 7 edits in tags/Safari-606.1.11.1/Source

Versioning.

10:41 AM Changeset in webkit [230110] by jmarcell@apple.com

• 1 copy in tags/Safari-606.1.11.1

New tag.

10:36 AM Changeset in webkit [230109] by jfbastien@apple.com

• 2 edits in trunk/Source/WTF

Introduce WTF_LAZY_INSTANTIATE
​https://bugs.webkit.org/show_bug.cgi?id=184169
<rdar://problem/39023385>

Reviewed by Mark Lam.

As part of #184164 I'm adding some forwarding methods to
WTF::String. These need to forward RetainPtr and CString, and
usually that would require #include'ing RetainPtr.h and CString.h
to WTFString.h which isn't really something we should do.

Introduce WTF_LAZY_INSTANTIATE to forward-declare functions which
just pass parameters to another function, and return whatever that
other function returned, without having to include the return's /
parameters' type header.

Try it out here: godbolt.org/g/oV8G5Q

• wtf/Forward.h:

10:30 AM Changeset in webkit [230108] by jfbastien@apple.com

• 7 edits in trunk/Source/WebKit

Update messages.py codegen for String, fix tests
​https://bugs.webkit.org/show_bug.cgi?id=184179
<rdar://problem/39041352>

Reviewed by Mark Lam.

I updated some of the code in
​https://trac.webkit.org/changeset/230097 and auto-magically used a
script to update copyright headers... and that broke the tests
which checked for a particular date. Update all of the headers.

Part of this change updates the code generated by messages.py

• Scripts/webkit/LegacyMessageReceiver-expected.cpp:
• Scripts/webkit/MessageReceiver-expected.cpp:
• Scripts/webkit/MessageReceiverSuperclass-expected.cpp:
• Scripts/webkit/MessagesSuperclass-expected.h:
• Scripts/webkit/messages.py:
• Scripts/webkit/messages_unittest.py:

(GeneratedFileContentsTest.assertGeneratedFileContentsEqual):
generate a better error message

9:55 AM Changeset in webkit [230107] by dbates@webkit.org

• 3 edits in trunk/Source/WebCore

Remove unused MIMETypeRegistry::getSupportedImageMIMETypesForEncoding()
​https://bugs.webkit.org/show_bug.cgi?id=184154

Reviewed by Per Arne Vollan.

• platform/MIMETypeRegistry.cpp:

(WebCore::MIMETypeRegistry::getSupportedImageMIMETypesForEncoding): Deleted.

• platform/MIMETypeRegistry.h:

9:31 AM Changeset in webkit [230106] by mark.lam@apple.com

• 12 edits in trunk/Source/JavaScriptCore

Add pointer profiling support to Wasm.
​https://bugs.webkit.org/show_bug.cgi?id=184175
<rdar://problem/39027923>

Reviewed by JF Bastien.

• runtime/PtrTag.h:
• wasm/WasmB3IRGenerator.cpp:

(JSC::Wasm::B3IRGenerator::addGrowMemory):
(JSC::Wasm::B3IRGenerator::addCall):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I32Popcnt>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64Popcnt>):

• wasm/WasmBBQPlan.cpp:

(JSC::Wasm::BBQPlan::prepare):
(JSC::Wasm::BBQPlan::complete):

• wasm/WasmBinding.cpp:

(JSC::Wasm::wasmToWasm):

• wasm/WasmBinding.h:
• wasm/WasmFaultSignalHandler.cpp:

(JSC::Wasm::trapHandler):

• wasm/WasmOMGPlan.cpp:

(JSC::Wasm::OMGPlan::work):

• wasm/WasmThunks.cpp:

(JSC::Wasm::throwExceptionFromWasmThunkGenerator):
(JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
(JSC::Wasm::triggerOMGTierUpThunkGenerator):

• wasm/js/WasmToJS.cpp:

(JSC::Wasm::handleBadI64Use):
(JSC::Wasm::wasmToJS):

• wasm/js/WebAssemblyFunction.cpp:

(JSC::callWebAssemblyFunction):

• wasm/js/WebAssemblyFunction.h:

9:05 AM Changeset in webkit [230105] by Ryan Haddad

• 28 edits
  2 copies
  2 deletes in trunk

Unreviewed, rolling out r230102.

Caused assertion failures on JSC bots.

Reverted changeset:

"A stack overflow in the parsing of a builtin (called by
createExecutable) cause a crash instead of a catchable js
exception"
​https://bugs.webkit.org/show_bug.cgi?id=184074
​https://trac.webkit.org/changeset/230102

9:00 AM Changeset in webkit [230104] by Ryan Haddad

• 2 edits in trunk/LayoutTests

Mark imported/w3c/web-platform-tests/IndexedDB/idbobjectstore_createIndex7-event_order.htm as flaky.
​https://bugs.webkit.org/show_bug.cgi?id=184116

Unreviewed test gardening.

• platform/mac/TestExpectations:

7:03 AM Changeset in webkit [230103] by rmorisset@apple.com

• 3 edits
  1 add in trunk

Inlining of a function that ends in op_unreachable in a non-tail position triggers an ASSERT
​https://bugs.webkit.org/show_bug.cgi?id=183812

Reviewed by Keith Miller.

JSTests:

• stress/inlining-unreachable-non-tail.js: Added.

(foo.):
(foo):

Source/JavaScriptCore:

The fix I landed for ​https://bugs.webkit.org/show_bug.cgi?id=181027 was flawed: I tried setting the bytecodeIndex for the new block on line 1679 (at the end of inlineCall), but it is going to be reset on line 6612 (in parseCodeBlock).
The fix is simply to make the block untargetable by default, and let parseCodeBlock make it targetable afterwards if it is a jump target.

• dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::allocateTargetableBlock):
(JSC::DFG::ByteCodeParser::inlineCall):

5:39 AM Changeset in webkit [230102] by rmorisset@apple.com

• 28 edits
  1 copy
  1 add
  2 deletes in trunk

A stack overflow in the parsing of a builtin (called by createExecutable) cause a crash instead of a catchable js exception
​https://bugs.webkit.org/show_bug.cgi?id=184074
<rdar://problem/37165897>

Reviewed by Keith Miller.

JSTests:

• stress/stack-overflow-while-parsing-builtin.js: Added.

(f):

Source/JavaScriptCore:

Fixing this requires getting the ParserError (with information about the failure) and an ExecState* (to throw an exception) in the same place.
It is surprisingly painful, with quite a long call stack between the last function with an access to an ExecState* and the first function with the ParserError.
Even worse, many of these functions are generated by macros, themselves generated by a maze of python scripts.
As a result, this patch is grotesquely large, while all it does is adding enough plumbing to throw a proper exception in this specific case.

There are now bare calls to '.value()' on several paths that may crash. It is not a problem in my opinion, since we previously crashed in every case regardless of the path that took us to createExecutable when encountering a stack overflow.
If we ever find an example that can cause these calls to fail, it should be doable to throw a proper exception there too.

Two other minor changes:

• I removed BuiltinExecutableCreator.{cpp, h} as it was nearly empty, and only used in one place. That place now includes BuiltinExecutables.h directly instead.
• I moved code from ParserError.h into a newly created ParserError.cpp, as I see no need to inline functions that are only used when encountering a parser error, and ParserError.h is now included in quite a few places.

• JavaScriptCore.xcodeproj/project.pbxproj:
• Scripts/builtins/builtins_generate_combined_header.py:

(BuiltinsCombinedHeaderGenerator.generate_forward_declarations):
(ParserError):
(generate_section_for_object): Deleted.
(generate_externs_for_object): Deleted.
(generate_macros_for_object): Deleted.
(generate_section_for_code_table_macro): Deleted.
(generate_section_for_code_name_macro): Deleted.
(generate_section_for_global_private_code_name_macro): Deleted.

• Scripts/builtins/builtins_generate_separate_header.py:

(generate_secondary_header_includes):

• Scripts/builtins/builtins_templates.py:
• Sources.txt:
• builtins/BuiltinExecutableCreator.cpp: Removed.
• builtins/BuiltinExecutableCreator.h: Removed.
• builtins/BuiltinExecutables.cpp:

(JSC::BuiltinExecutables::createDefaultConstructor):
(JSC::BuiltinExecutables::createBuiltinExecutable):
(JSC::createBuiltinExecutable):
(JSC::BuiltinExecutables::createExecutableOrCrash):
(JSC::BuiltinExecutables::createExecutable):

• builtins/BuiltinExecutables.h:
• bytecompiler/BytecodeGenerator.h:
• parser/ParserError.cpp: Added.

(JSC::ParserError::toErrorObject):
(JSC::ParserError::throwStackOverflowOrOutOfMemory):
(WTF::printInternal):

• parser/ParserError.h:

(JSC::ParserError::toErrorObject): Deleted.
(WTF::printInternal): Deleted.

• runtime/AsyncIteratorPrototype.cpp:

(JSC::AsyncIteratorPrototype::finishCreation):

• runtime/FunctionPrototype.cpp:

(JSC::FunctionPrototype::addFunctionProperties):

• runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::init):

• runtime/JSObject.cpp:

(JSC::JSObject::getOwnStaticPropertySlot):
(JSC::JSObject::reifyAllStaticProperties):

• runtime/JSObject.h:

(JSC::JSObject::getOwnNonIndexPropertySlot):
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::getPropertySlot):

• runtime/JSObjectInlines.h:

(JSC::JSObject::getNonIndexPropertySlot):

• runtime/JSTypedArrayViewPrototype.cpp:

(JSC::JSTypedArrayViewPrototype::finishCreation):

• runtime/Lookup.cpp:

(JSC::reifyStaticAccessor):
(JSC::setUpStaticFunctionSlot):

• runtime/Lookup.h:

(JSC::getStaticPropertySlotFromTable):
(JSC::reifyStaticProperty):

• runtime/MapPrototype.cpp:

(JSC::MapPrototype::finishCreation):

• runtime/SetPrototype.cpp:

(JSC::SetPrototype::finishCreation):

• tools/JSDollarVM.cpp:

(JSC::functionCreateBuiltin):

Source/WebCore:

I had to slightly change the type of some bindings between JSC and WebCore. No functional change intended on the WebCore side.

• bindings/js/JSReadableStreamPrivateConstructors.cpp:

(WebCore::JSBuiltinReadableStreamDefaultReaderPrivateConstructor::initializeExecutable):
(WebCore::JSBuiltinReadableStreamDefaultControllerPrivateConstructor::initializeExecutable):
(WebCore::JSBuiltinReadableByteStreamControllerPrivateConstructor::initializeExecutable):
(WebCore::JSBuiltinReadableStreamBYOBReaderPrivateConstructor::initializeExecutable):
(WebCore::JSBuiltinReadableStreamBYOBRequestPrivateConstructor::initializeExecutable):

• bindings/scripts/CodeGeneratorJS.pm:

(GenerateConstructorHelperMethods):

• bindings/scripts/test/JS/JSTestClassWithJSBuiltinConstructor.cpp:

(WebCore::JSTestClassWithJSBuiltinConstructorConstructor::initializeExecutable):

• bindings/scripts/test/JS/JSTestJSBuiltinConstructor.cpp:

(WebCore::JSTestJSBuiltinConstructorConstructor::initializeExecutable):

5:05 AM Changeset in webkit [230101] by rmorisset@apple.com

• 5 edits
  1 add in trunk

Out-of-bounds accesses due to a missing check for MAX_STORAGE_VECTOR_LENGTH in unshiftCountForAnyIndexingType
​https://bugs.webkit.org/show_bug.cgi?id=183657
JSTests:

Reviewed by Keith Miller.

• stress/large-unshift-splice.js: Added.

(make_contig_arr):

Source/JavaScriptCore:

<rdar://problem/38464399>

Reviewed by Keith Miller.

There was just a missing check in unshiftCountForIndexingType.
I've also replaced 'return false' by 'return true' in the case of an 'out-of-memory' exception, because 'return false' means 'please continue to the slow path',
and the slow path has an assert that there is no unhandled exception (line 360 of ArrayPrototype.cpp).
Finally, I made the assert in ensureLength a release assert as it would have caught this bug and prevented it from being a security risk.

• runtime/ArrayPrototype.cpp:

(JSC::unshift):

• runtime/JSArray.cpp:

(JSC::JSArray::unshiftCountWithAnyIndexingType):

• runtime/JSObject.h:

(JSC::JSObject::ensureLength):