Bug 130353

Marked tests as failing in https://trac.webkit.org/r165747.

Is there a crash log seen anywhere? On bots I checked, it looks like a timeout misreported as crash.

In http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20%28Tests%29/r165745%20%2816869%29/mathml/wbr-in-mroot-crash-sample.txt the crash seems to happen in RenderMathMLOperator, however no <mo>s are involved in the test so something is probably doing a wrong cast into a RenderMathMLOperator. I guess we can remove htmlElement.hasTagName(HTMLNames::wbrTag) from isPhrasingContent to workaround the crash, but I'd like to find what the problem is exactly.

I just tried again this morning and was not able to reproduce the crash on Linux. I'm no longer able to build a debug on my laptop and adding printf on RenderMathMLOperator does print anything so I'm not sure why they appear in the crash log. Does it happen only on Mac? @Brent: I think you worked on the security issue with HTML content badly cast to MathML. Do you know if that could happen again after bug 124128? Especially, this change allows <wbr> as child of token elements. (BTW, the change in bug 128907 might also be involved here)

(In reply to comment #2) > Is there a crash log seen anywhere? On bots I checked, it looks like a timeout misreported as crash. This seems to be random: r165702 has crash log but not http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20%28Tests%29/r165702%20%2816840%29/mathml/wbr-in-mroot-crash-sample.txt http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20%28Tests%29/r165703%20%2816841%29/mathml/ (In reply to comment #4) > Does it happen only on Mac? Apparently it was disabled on EFL too, so I'll try to build that port and see if I can reproduce the crash.

(In reply to comment #5) > (In reply to comment #4) > > Does it happen only on Mac? > > Apparently it was disabled on EFL too, so I'll try to build that port and see if I can reproduce the crash. I have not been able to reproduce any crash or hang...

Looking at the results for revision r170050-r170094, I know only see at worse time out. So let's say bug 119038 improved the situation here, and mark the test as "Timeout". I'm also renaming the bug entry.

Committed r170099: <http://trac.webkit.org/changeset/170099>

Reopening, since the timeout is not actually fixed.

*** Bug 132267 has been marked as a duplicate of this bug. ***

Per bug 157990 comment 4 and below, the problem actually seemed to be related to the previous test mathml/very-large-stretchy-operators.html. I can not reproduce the timeout on GTK with the command proposed there and the test expectation was removed for mac. So I assumed this has been fixed by the patch for bug 155434.

Created attachment 282222 [details] Patch

Committed r202564: <http://trac.webkit.org/changeset/202564>

On Efl, the flakiness was "Crash Pass", which I don't think can be explained by this. But it's not happening any more, according to the flakiness dashboard, so it's fine to remove the expectation.