Bug 42776 – Pull HTML5lib test suite from upstream

• Component: New Bugs
• Status: RESOLVED FIXED

[Adam Barth]

Pull HTML5lib test suite from upstream

[Adam Barth]

Created attachment 62221 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 62221 [details]
Patch

rs=me.  We should hash out with James if these are all correct or not.  Regardless our test set should agree 100% with his.

Did you do this manually?  Or can we build a scriopt to show us the diff?

[Adam Barth]

I did it manually, but it would be easy to write a script.

[WebKit Commit Bot]

Comment on attachment 62221 [details]
Patch

Clearing flags on attachment: 62221

Committed r63858: <http://trac.webkit.org/changeset/63858>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[WebKit Review Bot]

http://trac.webkit.org/changeset/63858 might have broken GTK Linux 32-bit Release and Qt Linux Release

[Eric Seidel (no email)]

It looks like our <keygen> support is platform specific?  That seems strange.  Gtk is failing to generate the same <keygen> DOM as the other ports.

[Eric Seidel (no email)]

I should note, the correct fix is NOT to skip this test on Gtk.  But we could remove this keygen part of the test suite.  If we do that, we may need to regen both HTML5 and non-html test results for runner.html.

[Adam Barth]

I already skipped the test before reading your message.  I don't see another feasible solution in the short term.

[Eric Seidel (no email)]

This is the code causing the failures:
http://trac.webkit.org/browser/trunk/WebCore/html/HTMLKeygenElement.cpp#L43

Due to Qt/Gtk lacking support:
http://trac.webkit.org/browser/trunk/WebCore/platform/qt/TemporaryLinkStubsQt.cpp#L94
http://trac.webkit.org/browser/trunk/WebCore/platform/gtk/TemporaryLinkStubs.cpp#L46

The fix would be to make the <keygen> kids a shadow DOM or similar.

[Eric Seidel (no email)]

I think I will need to talk to a rendering expert more to better understand what needs to be done here to make these Shadow Nodes.

I suspect that either RenderMenuList will need to learn how to have shadow kids, or we'll need a custom renderer for HTMLKeygenElement?

[Eric Seidel (no email)]

Looks like it already has a shadow dom:

void RenderMenuList::createInnerBlock()