The result of fast/dom/DOMException/stack-trace.html depends on the path from where your WebKit repository is. Because of this bug, this test fail where the WebKit isn't in /src/WebKit. For example the Qt bot: --- /ramdisk/qt-linux-64-release/build/layout-test-results/fast/dom/DOMException/stack-trace-expected.txt +++ /ramdisk/qt-linux-64-release/build/layout-test-results/fast/dom/DOMException/stack-trace-actual.txt @@ -7,9 +7,9 @@ PASS e.message is "HIERARCHY_REQUEST_ERR: DOM Exception 3" PASS e.code is 3 FAIL e.stack should be 42 (of type number). Was appendChild@[native code] -innerFunction@file:///src/WebKit/LayoutTests/fast/dom/DOMException/stack-trace.html:17 -outerFunction@file:///src/WebKit/LayoutTests/fast/dom/DOMException/stack-trace.html:21 -global code@file:///src/WebKit/LayoutTests/fast/dom/DOMException/stack-trace.html:27 (of type string). +innerFunction@file:///ramdisk/qt-linux-64-release/build/LayoutTests/fast/dom/DOMException/stack-trace.html:17 +outerFunction@file:///ramdisk/qt-linux-64-release/build/LayoutTests/fast/dom/DOMException/stack-trace.html:21 +global code@file:///ramdisk/qt-linux-64-release/build/LayoutTests/fast/dom/DOMException/stack-trace.html:27 (of type string). PASS successfullyParsed is true TEST COMPLETE It should be refactored not to be path dependent.
I skipped it on Qt - https://trac.webkit.org/changeset/117031/trunk/LayoutTests/platform/qt/Skipped Please unskip it with the proper fix.
*** Bug 86453 has been marked as a duplicate of this bug. ***
The stack property of DOMException is currently only implemented in V8, meaning the test fails (unfortunately with builder-specific failures).
Marked as failures for GTK in http://trac.webkit.org/changeset/117042.
(In reply to comment #3) > The stack property of DOMException is currently only implemented in V8, meaning the test fails (unfortunately with builder-specific failures). Not correct. JSC also supports the stack property on DOMExceptions. However, JSC has a bug where the stack property is read only. I could change the read only test so that the result does not print the actual stack trace when it fails the read only test. That will improve the testability while JSC is broken.
Created attachment 142016 [details] Patch
Do we have a bugzilla tracking the JSC failure?
(In reply to comment #7) > Do we have a bugzilla tracking the JSC failure? There is now https://bugs.webkit.org/show_bug.cgi?id=86523
Comment on attachment 142016 [details] Patch Attachment 142016 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12684947 New failing tests: fast/xpath/attr-namespace.html
Created attachment 142057 [details] Archive of layout-test-results from ec2-cr-linux-02 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-02 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
(In reply to comment #9) > (From update of attachment 142016 [details]) > Attachment 142016 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/12684947 > > New failing tests: > fast/xpath/attr-namespace.html It seems dubious that any of these were caused by this patch
Comment on attachment 142016 [details] Patch Clearing flags on attachment: 142016 Committed r117169: <http://trac.webkit.org/changeset/117169>
All reviewed patches have been landed. Closing bug.