Bug 178116 – El Capitan: Assertion failure inside RenderBlockFlow::ensureLineBoxes()

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Layout and Rendering

[Ryosuke Niwa]

stderr:
ASSERTION FAILED: didNeedLayout || logicalHeight() == oldHeight
/Volumes/Data/git-webkit/Source/WebCore/rendering/RenderBlockFlow.cpp(3661) : void WebCore::RenderBlockFlow::ensureLineBoxes()
1   0x120978ecd WTFCrash
2   0x1144cf8bd WebCore::RenderBlockFlow::ensureLineBoxes()
3   0x11479b4c0 WebCore::RenderText::ensureLineBoxes()
4   0x114405a0a WebCore::ensureLineBoxesIfNeeded(WebCore::RenderObject&)
5   0x114403bcf WebCore::Position::downstream(WebCore::EditingBoundaryCrossingRule) const
6   0x112a71d36 WebCore::previousVisuallyDistinctCandidate(WebCore::Position const&)
7   0x114ef5e6a WebCore::VisiblePosition::previous(WebCore::EditingBoundaryCrossingRule, bool*) const
8   0x114f02ff0 WebCore::isStartOfDocument(WebCore::VisiblePosition const&)
9   0x112cf5960 WebCore::FrameSelection::selectFrameElementInParentIfFullySelected()
10  0x112cf5507 WebCore::FrameSelection::setSelectionWithoutUpdatingAppearance(WebCore::VisibleSelection const&, unsigned int, WebCore::FrameSelection::CursorAlignOnScroll, WebCore::TextGranularity)
11  0x112cf3b34 WebCore::FrameSelection::setSelection(WebCore::VisibleSelection const&, unsigned int, WebCore::AXTextStateChangeIntent, WebCore::FrameSelection::CursorAlignOnScroll, WebCore::TextGranularity)
12  0x112cfe603 WebCore::FrameSelection::selectAll()
13  0x112aa7cf8 WebCore::executeSelectAll(WebCore::Frame&, WebCore::Event*, WebCore::EditorCommandSource, WTF::String const&)
14  0x112aa3993 WebCore::Editor::Command::execute(WTF::String const&, WebCore::Event*) const
15  0x1128f0819 WebCore::Document::execCommand(WTF::String const&, bool, WTF::String const&)
16  0x1134d1339 WebCore::jsDocumentPrototypeFunctionExecCommandBody(JSC::ExecState*, WebCore::JSDocument*, JSC::ThrowScope&)
17  0x1134bb3de long long WebCore::IDLOperation<WebCore::JSDocument>::call<&(WebCore::jsDocumentPrototypeFunctionExecCommandBody(JSC::ExecState*, WebCore::JSDocument*, JSC::ThrowScope&)), (WebCore::CastedThisErrorBehavior)0>(JSC::ExecState&, char const*)
18  0x1134bb16c WebCore::jsDocumentPrototypeFunctionExecCommand(JSC::ExecState*)
19  0x2983fee01028
20  0x11f554081 llint_entry
21  0x11f554081 llint_entry
22  0x11f54c447 vmEntryToJavaScript
23  0x12025fb6e JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*)
24  0x1202070eb JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::ExecState*, JSC::JSObject*)
25  0x1204804b7 JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)
26  0x120480650 JSC::profiledEvaluate(JSC::ExecState*, JSC::ProfilingReason, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)
27  0x1148b0d2b WebCore::JSMainThreadExecState::profiledEvaluate(JSC::ExecState*, JSC::ProfilingReason, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)
28  0x1148b0b18 WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld&, WebCore::ExceptionDetails*)
29  0x1148b0e0d WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&, WebCore::ExceptionDetails*)
30  0x1148c6032 WebCore::ScriptElement::executeClassicScript(WebCore::ScriptSourceCode const&)
31  0x1148c463f WebCore::ScriptElement::prepareScript(WTF::TextPosition const&, WebCore::ScriptElement::LegacyTypeSupport)

[Ryosuke Niwa]

Created attachment 323286 [details]
crash.html

Place this file inside LayoutTests and run:
./Tools/Scripts/run-webkit-tests --debug --no-retry --no-new-test-results crash.html

As far as I've tested, you can only reproduce this on OS X El Capitan (10.11). e.g. 15G31 / 10.11.6.

[Alexey Proskuryakov]

Weird that this appears to be OS version dependent. I tried, and couldn't reproduce on High Sierra indeed.

We should probably at least land the test case skipped on 10.11.

[Ryosuke Niwa]

(In reply to Alexey Proskuryakov from comment #2)
> Weird that this appears to be OS version dependent. I tried, and couldn't
> reproduce on High Sierra indeed.
> 
> We should probably at least land the test case skipped on 10.11.

Yeah, it's super weird. I had to install El Capitan in order to reproduce this.

[Ryosuke Niwa]

My guess is that it's something to do with the render theme of buttons because it's asserting as the editing code traverses into the button. If I add another div between the editable element and the button, the assertion goes away. In fact, that's how I worked around this in https://trac.webkit.org/r223195.

[Antti Koivisto]

That assert is saying that results from the simple line layout path and the line box path don't match. This may be due to a bug on either path or it may be some rare case where we should not be using simple lines but are. On release something would be misrendered as a result.

[Ahmad Saleem]

I know it might not be direct assertion link but 'FrameSelection::selectAll', Blink fixed this potential assertion: https://chromium.googlesource.com/chromium/src.git/+/526d14e61982c269e32bb2dd9869cd9185ab3da0

https://searchfox.org/wubkat/source/Source/WebCore/editing/FrameSelection.cpp#2128

[zalan]

This is certainly not valid anymore.