Created attachment 62221 [details] Patch

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?

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

Comment on attachment 62221 [details] Patch Clearing flags on attachment: 62221 Committed r63858: <http://trac.webkit.org/changeset/63858>

All reviewed patches have been landed. Closing bug.

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

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.

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.

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

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.

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?

Looks like it already has a shadow dom: void RenderMenuList::createInnerBlock()