ProgressEvent should have a constructor (Spec: http://www.w3.org/TR/progress-events/#interface-progressevent).
Created attachment 106781 [details] Patch
Comment on attachment 106781 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=106781&action=review > Source/WebCore/bindings/v8/OptionsObject.h:38 > +static const double UnsignedLongLongMax = 18446744073709551616.0; // 2^64 Why don't we get this from limits.h?
Created attachment 106786 [details] Patch
Comment on attachment 106781 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=106781&action=review >> Source/WebCore/bindings/v8/OptionsObject.h:38 >> +static const double UnsignedLongLongMax = 18446744073709551616.0; // 2^64 > > Why don't we get this from limits.h? Done.
Comment on attachment 106786 [details] Patch Attachment 106786 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/9622650
Created attachment 106880 [details] Patch
Comment on attachment 106880 [details] Patch It seems this breaks windows. If you fix that, r=me.
(In reply to comment #7) > (From update of attachment 106880 [details]) > It seems this breaks windows. If you fix that, r=me. Sam: Thank you very much for reviews. By the way, the windows problem seems not to be related to this patch. We can find similar failures in the waterfall (http://build.webkit.org/builders/WinCairo%20Debug%20%28Build%29/builds/10647/steps/compile-webkit/logs/stdio). I will wait for this failure to be fixed, and then commit my patch.
Created attachment 106918 [details] Just to see if the patch passes win EWS I will postpone committing the patch until windows build problem is fixed.
Created attachment 106930 [details] Just see if this patch passes win EWS Replaced ULONG_LONG_MAX with std::numeric_limits<unsigned long long>::max().
Created attachment 107018 [details] Just see if the patch passes win EWS Just rebased the patch.
Committed r94946: <http://trac.webkit.org/changeset/94946>