47745 2010-10-15 15:46:30 -0700 Focus on MathML in page causes crash 2013-07-22 23:38:06 -0700 1 1 1 Unclassified WebKit MathML 528+ (Nightly build) PC OS X 10.5 RESOLVED WORKSFORME P1 Normal --- 1 alex alex cfleizach darin donggwan.kim fred.wang sausset oldest_to_newest 294970 0 alex 2010-10-15 15:46:30 -0700 After waiting quite awhile for this page to render: https://eyeasme.com/Joe/MathML/MathML_browser_test right click on any MathML content piece to attempt to get the web inspector and an assertion fails: ASSERTION FAILED: !renderer()->needsLayout() (/Users/alex/workspace/WebKit/WebCore/dom/Node.cpp:793 virtual bool WebCore::Node::isFocusable() const) I assume this means the MathML is still rendering somehow. While the MathML should not take this long to render, I'm not certain that we should get a crash from the focus check. 295016 1 70920 alex 2010-10-15 16:51:52 -0700 Created attachment 70920 Smallest Example of Crash 295017 2 alex 2010-10-15 16:52:52 -0700 This crash is caused by an anchor wrapping the MathML. 295164 3 alex 2010-10-16 14:28:09 -0700 After a bit of testing and debugging, the crash is coming from the anchor element (a) being marked for layout. When the focus event happens, the crash asserts that the element shouldn't need layout. I'm not sure why the anchor element needs layout but it is probably due to something from the child MathML element. 295250 4 alex 2010-10-17 11:48:45 -0700 Digging a bit further I find that the inline renderer for anchor has m_normalChildNeedsLayout set to true but none of the children are marked as needing layout. 295263 5 alex 2010-10-17 12:35:43 -0700 Bug 47781 may be related to this. In that case, the MathML overflows the table cell so the table cell may also have unfinished layouts. 295462 6 sausset 2010-10-18 05:44:05 -0700 I just tried with r69946 and no crash occurs on the mentioned webpage or with the test case, even when using the Web Inspector. 295688 7 alex 2010-10-18 12:28:14 -0700 (In reply to comment #6) > I just tried with r69946 and no crash occurs on the mentioned webpage or with the test case, even when using the Web Inspector. The crash only happens in the debug build. 295703 8 darin 2010-10-18 12:45:04 -0700 This “crash” is an assertion. Assertions are in debug builds only. Some assertions detect theoretical inconsistencies that are not always practical problems. One possibility is that there is a different approach to layout here, and we just have to teach the assertion about the special objects that will always think they need layout. Another possibility is that we can make some simple adjustment so these objects will be marked as not needing layout. 295707 9 alex 2010-10-18 12:52:15 -0700 (In reply to comment #8) > This “crash” is an assertion. Assertions are in debug builds only. Some assertions detect theoretical inconsistencies that are not always practical problems. > > One possibility is that there is a different approach to layout here, and we just have to teach the assertion about the special objects that will always think they need layout. > > Another possibility is that we can make some simple adjustment so these objects will be marked as not needing layout. OK. That makes sense. Somehow I thought assertions were always on. Nevertheless, what doesn't make sense is all the children are marked as not needing layout but the parent thinks that a child needs layout. That is, m_normalChildNeedsLayout is true. If you change the wrapping anchor to a block (i.e. a { display: block }) in the test, everything works as expected. There is something odd going on. 295712 10 71074 alex 2010-10-18 13:02:47 -0700 Created attachment 71074 Another example with a second non-mathml child in the anchor Clicking on 'bingo' also crashs in debug builds. 295713 11 alex 2010-10-18 13:04:37 -0700 As expected, if you remove the MathML math element, the assertion doesn't fail. Somehow MathML rendering must be notifying its parent that it needs to relayout its children yet the layout is never scheduled. 830958 12 alex 2013-02-12 08:13:14 -0800 I don't think this crash exists anymore. I cannot reproduce it in the latest version. What's the process for closing this? 910914 13 cfleizach 2013-07-22 23:38:06 -0700 Moving to resolved based on Alex's comments 70920 2010-10-15 16:51:52 -0700 2010-10-15 16:51:52 -0700 Smallest Example of Crash mathml-focus-crash-3.xhtml application/xhtml+xml 205 alex PGh0bWwgeG1sbnM9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwnPgo8aGVhZD4KPHRpdGxl Pk1yb3cgYW5kIFN1YnN1cCB0ZXN0PC90aXRsZT4KPC9oZWFkPgo8Ym9keT4KPGEgaHJlZj0iIyI+ CjxtYXRoIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk4L01hdGgvTWF0aE1MIj4KPG1pPng8 L21pPgo8L21hdGg+CjwvYT4KPC9ib2R5Pgo8L2h0bWw+Cg== 71074 2010-10-18 13:02:47 -0700 2010-10-18 13:02:47 -0700 Another example with a second non-mathml child in the anchor mathml-focus-crash-4.xhtml application/xhtml+xml 241 alex PGh0bWwgeG1sbnM9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwnPgo8aGVhZD4KPHRpdGxl PmlzRm9jdXNhYmxlIENyYXNoPC90aXRsZT4KPC9oZWFkPgo8Ym9keT4KPGRpdj4KPGEgaHJlZj0i IyI+PG1hdGggeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTgvTWF0aC9NYXRoTUwiPjxtaT54 PC9taT48L21hdGg+IDxzcGFuIGlkPSdiaW5nbyc+YmluZ288L3NwYW4+PC9hPgo8L2Rpdj4KPC9i b2R5Pgo8L2h0bWw+Cg==