|Summary:||Pull HTML5lib test suite from upstream|
|Product:||WebKit||Reporter:||Adam Barth <abarth>|
|Component:||New Bugs||Assignee:||Adam Barth <abarth>|
|Severity:||Normal||CC:||abarth, adele, commit-queue, dglazkov, eric, jamesr, mrobinson, webkit.review.bot, xan.lopez|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.5|
|Bug Depends on:|
Description Adam Barth 2010-07-21 12:44:06 PDT
Pull HTML5lib test suite from upstream
Comment 2 Eric Seidel (no email) 2010-07-21 12:51:38 PDT
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?
Comment 3 Adam Barth 2010-07-21 12:54:17 PDT
I did it manually, but it would be easy to write a script.
Comment 4 WebKit Commit Bot 2010-07-21 14:41:48 PDT
Comment on attachment 62221 [details] Patch Clearing flags on attachment: 62221 Committed r63858: <http://trac.webkit.org/changeset/63858>
Comment 5 WebKit Commit Bot 2010-07-21 14:41:54 PDT
All reviewed patches have been landed. Closing bug.
Comment 6 WebKit Review Bot 2010-07-21 15:01:18 PDT
http://trac.webkit.org/changeset/63858 might have broken GTK Linux 32-bit Release and Qt Linux Release
Comment 7 Eric Seidel (no email) 2010-07-21 15:49:01 PDT
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.
Comment 8 Eric Seidel (no email) 2010-07-21 15:49:52 PDT
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.
Comment 9 Adam Barth 2010-07-21 15:52:27 PDT
I already skipped the test before reading your message. I don't see another feasible solution in the short term.
Comment 10 Eric Seidel (no email) 2010-07-21 15:59:09 PDT
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.
Comment 11 Eric Seidel (no email) 2010-07-21 16:13:36 PDT
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?
Comment 12 Eric Seidel (no email) 2010-07-21 16:14:50 PDT
Looks like it already has a shadow dom: void RenderMenuList::createInnerBlock()