Bug 115724

Created attachment 200901 [details] WIP Patch Using ews to get mac results.

Comment on attachment 200901 [details] WIP Patch Attachment 200901 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/338068 New failing tests: fast/dom/global-constructors-listing.html

Created attachment 200904 [details] Archive of layout-test-results from webkit-ews-04 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-04 Port: mac-mountainlion Platform: Mac OS X 10.8.2

Created attachment 200905 [details] Patch

Comment on attachment 200905 [details] Patch Adding these tests looks reasonable. Would you remove (a part of) LayoutTests/fast/dom/constructed-objects-prototypes.html ? We don't want to manage two tests for this.

Created attachment 200912 [details] WIP Patch

I thought we already had a test for this.

(In reply to comment #7) > I thought we already had a test for this. It was removed when the global constructors were made not enumerable (as it broke the test). However, we can use Object.getOwnPropertyNames(window) to work around this.

Comment on attachment 200912 [details] WIP Patch Attachment 200912 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/335148 New failing tests: fast/js/global-constructors-attributes.html

Created attachment 200930 [details] Archive of layout-test-results from webkit-ews-05 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.2

Created attachment 200933 [details] Patch Improve existing test case instead of introducing a new one.

Comment on attachment 200933 [details] Patch The test is a great idea. But the results have zero readability. If one line fail, you would have no idea which constructor is failing the test. The output needs to serialize the value of constructorName.

Created attachment 201032 [details] WIP Patch Using ews to get mac results.

Created attachment 201056 [details] Patch

Comment on attachment 201056 [details] Patch Looks good.

Comment on attachment 201056 [details] Patch Clearing flags on attachment: 201056 Committed r149758: <http://trac.webkit.org/changeset/149758>

All reviewed patches have been landed. Closing bug.

Test fails on mac-lion: http://build.webkit.org/results/Apple%20Lion%20Release%20WK1%20(Tests)/r149820%20(12294)/fast/js/global-constructors-attributes-pretty-diff.html Is this to be expected?

(In reply to comment #18) > Test fails on mac-lion: > http://build.webkit.org/results/Apple%20Lion%20Release%20WK1%20(Tests)/r149820%20(12294)/fast/js/global-constructors-attributes-pretty-diff.html > > Is this to be expected? If you don't have NOTIFICATIONS|LEGACY_NOTIFICATIONS enabled, yes. You likely need a platform-specific baseline.

(In reply to comment #19) > (In reply to comment #18) > > Test fails on mac-lion: > > http://build.webkit.org/results/Apple%20Lion%20Release%20WK1%20(Tests)/r149820%20(12294)/fast/js/global-constructors-attributes-pretty-diff.html > > > > Is this to be expected? > > If you don't have NOTIFICATIONS|LEGACY_NOTIFICATIONS enabled, yes. You likely need a platform-specific baseline. FYI, the global baseline is the one from mac-ews. However, it seems the mac port may be enabled NOTIFICATIONS depending on the Mac OS version: Source/WebCore/Configurations/FeatureDefines.xcconfig:ENABLE_NOTIFICATIONS_macosx_1070 = ; Source/WebCore/Configurations/FeatureDefines.xcconfig:ENABLE_NOTIFICATIONS_macosx_1080 = ENABLE_NOTIFICATIONS; Source/WebCore/Configurations/FeatureDefines.xcconfig:ENABLE_NOTIFICATIONS_macosx_1090 = ENABLE_NOTIFICATIONS;

okay, i'll go ahead and rebaseline then, thanks!

Late to the party but LGTM too :) The results look good now.