Created attachment 101699 [details] HTML source which demonstrates problem For audio/video tag fallback, W3C recommends an onerror which, among other things, tests child nodes of the element to see if they are instanceof HTMLElementSource. This test works (on windows 7) in Firefox, Opera, and IE9; it fails in Safari and Chrome (Uncaught ReferenceError: HTMLSourceElement is not defined). HTML to demonstrate this problem is attached.
There is no HTMLSourceElement in DOMWindow.idl; there should be.
Just to throw it out there, I think the fix to get this working is simple but there's a wrinkle. The interface is statically conditional on video. So if the build isn't built with video enabled, you'll still get this exception.
(In reply to comment #2) > Just to throw it out there, I think the fix to get this working is simple but there's a wrinkle. The interface is statically conditional on video. So if the build isn't built with video enabled, you'll still get this exception. I was wrong. The "source" tag (as an HTMLUnknownElement) handles it correctly by not executing the onerror method. The continued exception was because the "run separate instance" link is calling instanceof HTMLSourceElement unconditionally. That's not ok. I'll upload the code patch and test-results update shortly.
Created attachment 104555 [details] Patch
Comment on attachment 104555 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=104555&action=review > Source/WebCore/page/DOMWindow.idl:472 > + attribute [Conditional=VIDEO] HTMLSourceElementConstructor HTMLSourceElement; Should this be EnabledAtRuntime, like HTMLVideoElement?
Comment on attachment 104555 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=104555&action=review > Source/WebCore/ChangeLog:7 > + There's no description was to why we're adding this property nor what it does. We should definitely add such a description and refer to the relevant part of whatever spec that mandantes this behavior. r- for the lack of documentation.
I don't think that this warrants a lot of discussion - constructors for all elements should be available on DOIMWindow. The missing EnabledAtRuntime should be almost certainly added though.
I agree about the EnabledAtRuntime, and have re-built and verified the effect. I was just sitting here toiling with how to describe the necessity for putting this is, other than to say "for consistency with all the other elements". I guess that will be the note then. Will upload the patch shortly.
Created attachment 104589 [details] Patch - per reviewer feedback
Comment on attachment 104589 [details] Patch - per reviewer feedback View in context: https://bugs.webkit.org/attachment.cgi?id=104589&action=review This patch is not marked for review. > Source/WebCore/ChangeLog:4 > + Add HTMLSourceElement to DOMWindow.idl for consistency. Constructors for > + all elements should be available on DOMWindow. This is not how we usually do this. Bug title goes above the bug URL, and explanations go to the lines generated by the script (like "* page/DOMWindow.idl:" line below), or a general overview could go above those lines.
Comment on attachment 104589 [details] Patch - per reviewer feedback Per IRC discussion, this was meant for review, and I think that this is fine to land.
Comment on attachment 104589 [details] Patch - per reviewer feedback Attachment 104589 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/9438511
Created attachment 104617 [details] Patch Fixed V8 bindings.
Comment on attachment 104617 [details] Patch Clearing flags on attachment: 104617 Committed r93482: <http://trac.webkit.org/changeset/93482>
All reviewed patches have been landed. Closing bug.
Comment on attachment 104617 [details] Patch This patch missed many affected tests!
Adam, Eric, do you know why the commit queue landed the patch if it didn't pass some tests? /me recalls his unsuccessful argument that mega-tests dumping every property of the global object are evil, as maintaining them is a significant ongoing cost, and benefit is trivial.
The commily tests chromium-linux. Did any of the tests fail there? I'd recommend setting up a Mac EWS bot if you'd like folks not to breaks tests on Mac.
(I agree with Alexey that the tests that dump the global object are more work to maintain than they're worth.)
They should all just work from some snapshot of objects accessible from the global object. :)