Remove [NoInterfaceObject] extended attribute from several interfaces

Remove [NoInterfaceObject] extended attribute from several interfaces

Remove [NoInterfaceObject] extended attribute from the following Web IDL
interfaces: SecurityPolicy, History, Location, Navigator, Performance,
PerformanceEntry, PerformanceMark, PerformanceMeasure, PerformanceNavigation,
PerformanceResourceTiming, PerformanceTiming and Screen.

These interfaces should not have the [NoInterfaceObject] extended attribute
according to their respective specifications:
http://www.w3.org/html/wg/drafts/html/master/browsers.html#the-history-interface
http://www.w3.org/html/wg/drafts/html/master/browsers.html#the-location-interface
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#securitypolicy
http://www.w3.org/html/wg/drafts/html/master/webappapis.html#the-navigator-object
http://www.w3.org/TR/navigation-timing/#performance
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PerformanceTimeline/Overview.html#sec-PerformanceEntry-interface
http://www.w3.org/TR/navigation-timing/#performancenavigation
http://www.w3.org/TR/navigation-timing/#performancetiming
http://www.w3.org/TR/user-timing/#performancemark
http://www.w3.org/TR/user-timing/#performancemeasure
http://www.w3c-test.org/webperf/specs/ResourceTiming/#performanceresourcetiming
http://dev.w3.org/csswg/cssom-view/#the-screen-interface

R=abarth@chromium.org, arv@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=150042

[abarth-chromium, 2013-05-09 08:48:59]

How do other browsers behave?

[eseidel, 2013-05-09 08:50:53]

Seems reasonable.  Arv is a great reviewer for this sort of thing as he's more
current on the various specs than I am.

[do-not-use, 2013-05-09 08:52:53]

On 2013/05/09 08:50:53, Eric Seidel wrote:
> Seems reasonable.  Arv is a great reviewer for this sort of thing as he's more
> current on the various specs than I am.

Firefox exposes all of them except:
SecurityPolicy, PerformanceEntry, PerformanceMark, PerformanceMeasure,
PerformanceResourceTiming

Of course, this may be that they are unimplemented.

[do-not-use, 2013-05-09 09:09:17]

On 2013/05/09 08:52:53, Christophe Dumez wrote:
> On 2013/05/09 08:50:53, Eric Seidel wrote:
> > Seems reasonable.  Arv is a great reviewer for this sort of thing as he's
more
> > current on the various specs than I am.
> 
> Firefox exposes all of them except:
> SecurityPolicy, PerformanceEntry, PerformanceMark, PerformanceMeasure,
> PerformanceResourceTiming
> 
> Of course, this may be that they are unimplemented.

Yes, I confirmed that Firefox does not implement the following specs:
-
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PerformanceTimeline/Overvie...
(PerformanceEntry)
- http://www.w3.org/TR/user-timing/ (PerformanceMark, PerformanceMeasure)
- https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html
(PerformanceResourceTiming)

Firefox does not expose a securityPolicy property either on window.document
(SecurityPolicy interface).

WebKit based browser have the same behavior as Blink/Chromium but I'm going to
propose the same patch there.

[do-not-use, 2013-05-09 11:39:52]

Note that this patch made visible a bug in a few webperf layout tests:
"stack: ReferenceError: assert_class_string is not defined"

Test cases should probably include "testharness.js" as well.

I don't mind fixing it in this patch if requested but IMHO this may be better to
address it in a separate patch.

[do-not-use, 2013-05-09 11:42:18]

On 2013/05/09 11:39:52, Christophe Dumez wrote:
> Note that this patch made visible a bug in a few webperf layout tests:
> "stack: ReferenceError: assert_class_string is not defined"
> 
> Test cases should probably include "testharness.js" as well.
> 
> I don't mind fixing it in this patch if requested but IMHO this may be better
to
> address it in a separate patch.

ERRATA: Those tests already include testharness.js. However, our version of this
file is outdated and does not contain assert_class_string() function.

[arv (Not doing code reviews), 2013-05-09 13:39:00]

LGTM

Do you want to pull in a never version of the test harness? It will give us
cleaner expectations.

[do-not-use, 2013-05-09 13:44:45]

On 2013/05/09 13:39:00, arv wrote:
> LGTM
> 
> Do you want to pull in a never version of the test harness? It will give us
> cleaner expectations.

Ok. I was planning to do that in a follow-up patch but I can update this one as
well.

[arv (Not doing code reviews), 2013-05-09 13:56:54]

Either way. Whichever is less work for you.


On Thu, May 9, 2013 at 9:44 AM, <ch.dumez@sisa.samsung.com> wrote:

> On 2013/05/09 13:39:00, arv wrote:
>
>> LGTM
>>
>
>  Do you want to pull in a never version of the test harness? It will give
>> us
>> cleaner expectations.
>>
>
> Ok. I was planning to do that in a follow-up patch but I can update this
> one as
> well.
>
>
https://codereview.chromium.**org/14672011/<https://codereview.chromium.org/1...
>



-- 
erik

[do-not-use, 2013-05-09 14:54:07]

Ok, I have updated testharness.js and rebaselined the 3 webperf tests. the
output looks much better indeed.

I get a few presubmit warnings about spaces and tabs in testharness.js. I'm
really supposed to clean it up or should we land it as it is?

The try bots will likely complain.

[arv (Not doing code reviews), 2013-05-09 16:56:32]

LGTM

No, don't clean up the test harness. We want it to stay in sync as much as
possible.

[abarth-chromium, 2013-05-09 16:58:16]

LGTM2

[commit-bot: I haz the power, 2013-05-09 16:58:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@sisa.samsung.com/14672011/11001

[commit-bot: I haz the power, 2013-05-09 16:58:27]

Failed to apply patch for LayoutTests/http/tests/w3c/resources/testharness.js:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file LayoutTests/http/tests/w3c/resources/testharness.js
  Hunk #1 FAILED at 1.
  1 out of 1 hunk FAILED -- saving rejects to file
LayoutTests/http/tests/w3c/resources/testharness.js.rej

Patch:       LayoutTests/http/tests/w3c/resources/testharness.js
Index: LayoutTests/http/tests/w3c/resources/testharness.js
diff --git a/LayoutTests/http/tests/w3c/resources/testharness.js
b/LayoutTests/http/tests/w3c/resources/testharness.js
index
5f78a5d0a7d9a78aa2726a186e79ada74028a0f6..800ac2aeb236fe1d0aeffa8ac1fe0199ea9675ad
100644
--- a/LayoutTests/http/tests/w3c/resources/testharness.js
+++ b/LayoutTests/http/tests/w3c/resources/testharness.js
@@ -1,1761 +1,2233 @@
-/*
-Distributed under both the W3C Test Suite License [1] and the W3C
-3-clause BSD License [2]. To contribute to a W3C Test Suite, see the
-policies and contribution forms [3].
-
-[1] http://www.w3.org/Consortium/Legal/2008/04-testsuite-license
-[2] http://www.w3.org/Consortium/Legal/2008/03-bsd-license
-[3] http://www.w3.org/2004/10/27-testcases
-*/
-
-/*
- * == Introduction ==
- *
- * This file provides a framework for writing testcases. It is intended to
- * provide a convenient API for making common assertions, and to work both
- * for testing synchronous and asynchronous DOM features in a way that
- * promotes clear, robust, tests.
- *
- * == Basic Usage ==
- *
- * To use this file, import the script and the testharnessreport script into
- * the test document:
- * <script src="/resources/testharness.js"></script>
- * <script src="/resources/testharnessreport.js"></script>
- *
- * Within each file one may define one or more tests. Each test is atomic
- * in the sense that a single test has a single result (pass/fail/timeout).
- * Within each test one may have a number of asserts. The test fails at the
- * first failing assert, and the remainder of the test is (typically) not run.
- *
- * If the file containing the tests is a HTML file with an element of id "log"
- * this will be populated with a table containing the test results after all
- * the tests have run.
- *
- * NOTE: By default tests must be created before the load event fires. For ways
- *       to create tests after the load event, see "Determining when all tests
are
- *       complete", below
- *
- * == Synchronous Tests ==
- *
- * To create a synchronous test use the test() function:
- *
- * test(test_function, name, properties)
- *
- * test_function is a function that contains the code to test. For example a
- * trivial passing test would be:
- *
- * test(function() {assert_true(true)}, "assert_true with true")
- *
- * The function passed in is run in the test() call.
- *
- * properties is an object that overrides default test properties. The
recognised properties
- * are:
- *    timeout - the test timeout in ms
- *
- * e.g.
- * test(test_function, "Sample test", {timeout:1000})
- *
- * would run test_function with a timeout of 1s.
- *
- * == Asynchronous Tests ==
- *
- * Testing asynchronous features is somewhat more complex since the result of
- * a test may depend on one or more events or other callbacks. The API provided
- * for testing these features is indended to be rather low-level but hopefully
- * applicable to many situations.
- *
- * To create a test, one starts by getting a Test object using async_test:
- *
- * async_test(name, properties)
- *
- * e.g.
- * var t = async_test("Simple async test")
- *
- * Assertions can be added to the test by calling the step method of the test
- * object with a function containing the test assertions:
- *
- * t.step(function() {assert_true(true)});
- *
- * When all the steps are complete, the done() method must be called:
- *
- * t.done();
- *
- * The properties argument is identical to that for test().
- *
- * In many cases it is convenient to run a step in response to an event or a
- * callback. A convenient method of doing this is through the step_func method
- * which returns a function that, when called runs a test step. For example
- *
- * object.some_event = t.step_func(function(e) {assert_true(e.a)});
- *
- * == Making assertions ==
- *
- * Functions for making assertions start assert_
- * The best way to get a list is to look in this file for functions names
- * matching that pattern. The general signature is
- *
- * assert_something(actual, expected, description)
- *
- * although not all assertions precisely match this pattern e.g. assert_true
- * only takes actual and description as arguments.
- *
- * The description parameter is used to present more useful error messages when
- * a test fails
- *
- * NOTE: All asserts must be located in a test() or a step of an async_test().
- *       asserts outside these places won't be detected correctly by the
harness
- *       and may cause a file to stop testing.
- *
- * == Setup ==
- *
- * Sometimes tests require non-trivial setup that may fail. For this purpose
- * there is a setup() function, that may be called with one or two arguments.
- * The two argument version is:
- *
- * setup(func, properties)
- *
- * The one argument versions may omit either argument.
- * func is a function to be run synchronously. setup() becomes a no-op once
- * any tests have returned results. Properties are global properties of the
test
- * harness. Currently recognised properties are:
- *
- * timeout - The time in ms after which the harness should stop waiting for
- *           tests to complete (this is different to the per-test timeout
- *           because async tests do not start their timer until .step is
called)
- *
- * explicit_done - Wait for an explicit call to done() before declaring all
tests
- *                 complete (see below)
- *
- * output_document - The document to which results should be logged. By default
this is
- *                   the current document but could be an ancestor document in
some cases
- *                   e.g. a SVG test loaded in an HTML wrapper
- *
- * == Determining when all tests are complete ==
- *
- * By default the test harness will assume there are no more results to come
- * when:
- * 1) There are no Test objects that have been created but not completed
- * 2) The load event on the document has fired
- *
- * This behaviour can be overridden by setting the explicit_done property to
true
- * in a call to setup(). If explicit_done is true, the test harness will not
assume
- * it is done until the global done() function is called. Once done() is
called, the
- * two conditions above apply like normal.
- *
- * == Generating tests ==
- *
- * NOTE: this functionality may be removed
- *
- * There are scenarios in which is is desirable to create a large number of
- * (synchronous) tests that are internally similar but vary in the parameters
- * used. To make this easier, the generate_tests function allows a single
- * function to be called with each set of parameters in a list:
- *
- * generate_tests(test_function, parameter_lists)
- *
- * For example:
- *
- * generate_tests(assert_equals, [
- *     ["Sum one and one", 1+1, 2],
- *     ["Sum one and zero", 1+0, 1]
- *     ])
- *
- * Is equivalent to:
- *
- * test(function() {assert_equals(1+1, 2)}, "Sum one and one")
- * test(function() {assert_equals(1+0, 1)}, "Sum one and zero")
- *
- * Note that the first item in each parameter list corresponds to the name of
- * the test.
- *
- * == Callback API ==
- *
- * The framework provides callbacks corresponding to 3 events:
- *
- * start - happens when the first Test is created
- * result - happens when a test result is recieved
- * complete - happens when all results are recieved
- *
- * The page defining the tests may add callbacks for these events by calling
- * the following methods:
- *
- *   add_start_callback(callback) - callback called with no arguments
- *   add_result_callback(callback) - callback called with a test argument
- *   add_completion_callback(callback) - callback called with an array of tests
- *                                       and an status object
- *
- * tests have the following properties:
- *   status: A status code. This can be compared to the PASS, FAIL, TIMEOUT and
- *           NOTRUN properties on the test object
- *   message: A message indicating the reason for failure. In the future this
- *            will always be a string
- *
- *  The status object gives the overall status of the harness. It has the
- *  following properties:
- *    status: Can be compared to the OK, ERROR and TIMEOUT properties
- *    message: An error message set when the status is ERROR
- *
- * == External API ==
- *
- * In order to collect the results of multiple pages containing tests, the test
- * harness will, when loaded in a nested browsing context, attempt to call
- * certain functions in each ancestor browsing context:
- *
- * start - start_callback
- * result - result_callback
- * complete - completion_callback
- *
- * These are given the same arguments as the corresponding internal callbacks
- * described above.
- *
- * == List of assertions ==
- *
- * assert_true(actual, description)
- *   asserts that /actual/ is strictly true
- *
- * assert_false(actual, description)
- *   asserts that /actual/ is strictly false
- *
- * assert_equals(actual, expected, description)
- *   asserts that /actual/ is the same value as /expected/
- *
- * assert_not_equals(actual, expected, description)
- *   asserts that /actual/ is a different value to /expected/. Yes, this means
- *   that "expected" is a misnomer
- *
- * assert_in_array(actual, expected, description)
- *   asserts that /expected/ is an Array, and /actual/ is equal to one of the
- *   members -- expected.indexOf(actual) != -1
- *
- * assert_array_equals(actual, expected, description)
- *   asserts that /actual/ and /expected/ have the same length and the value of
- *   each indexed property in /actual/ is the strictly equal t…
(message too large)

[commit-bot: I haz the power, 2013-05-09 17:03:12]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@sisa.samsung.com/14672011/15001

[commit-bot: I haz the power, 2013-05-09 17:03:15]

Failed to apply patch for LayoutTests/http/tests/w3c/resources/testharness.js:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file LayoutTests/http/tests/w3c/resources/testharness.js
  Hunk #1 FAILED at 1.
  1 out of 1 hunk FAILED -- saving rejects to file
LayoutTests/http/tests/w3c/resources/testharness.js.rej

Patch:       LayoutTests/http/tests/w3c/resources/testharness.js
Index: LayoutTests/http/tests/w3c/resources/testharness.js
diff --git a/LayoutTests/http/tests/w3c/resources/testharness.js
b/LayoutTests/http/tests/w3c/resources/testharness.js
index
5f78a5d0a7d9a78aa2726a186e79ada74028a0f6..800ac2aeb236fe1d0aeffa8ac1fe0199ea9675ad
100644
--- a/LayoutTests/http/tests/w3c/resources/testharness.js
+++ b/LayoutTests/http/tests/w3c/resources/testharness.js
@@ -1,1761 +1,2233 @@
-/*
-Distributed under both the W3C Test Suite License [1] and the W3C
-3-clause BSD License [2]. To contribute to a W3C Test Suite, see the
-policies and contribution forms [3].
-
-[1] http://www.w3.org/Consortium/Legal/2008/04-testsuite-license
-[2] http://www.w3.org/Consortium/Legal/2008/03-bsd-license
-[3] http://www.w3.org/2004/10/27-testcases
-*/
-
-/*
- * == Introduction ==
- *
- * This file provides a framework for writing testcases. It is intended to
- * provide a convenient API for making common assertions, and to work both
- * for testing synchronous and asynchronous DOM features in a way that
- * promotes clear, robust, tests.
- *
- * == Basic Usage ==
- *
- * To use this file, import the script and the testharnessreport script into
- * the test document:
- * <script src="/resources/testharness.js"></script>
- * <script src="/resources/testharnessreport.js"></script>
- *
- * Within each file one may define one or more tests. Each test is atomic
- * in the sense that a single test has a single result (pass/fail/timeout).
- * Within each test one may have a number of asserts. The test fails at the
- * first failing assert, and the remainder of the test is (typically) not run.
- *
- * If the file containing the tests is a HTML file with an element of id "log"
- * this will be populated with a table containing the test results after all
- * the tests have run.
- *
- * NOTE: By default tests must be created before the load event fires. For ways
- *       to create tests after the load event, see "Determining when all tests
are
- *       complete", below
- *
- * == Synchronous Tests ==
- *
- * To create a synchronous test use the test() function:
- *
- * test(test_function, name, properties)
- *
- * test_function is a function that contains the code to test. For example a
- * trivial passing test would be:
- *
- * test(function() {assert_true(true)}, "assert_true with true")
- *
- * The function passed in is run in the test() call.
- *
- * properties is an object that overrides default test properties. The
recognised properties
- * are:
- *    timeout - the test timeout in ms
- *
- * e.g.
- * test(test_function, "Sample test", {timeout:1000})
- *
- * would run test_function with a timeout of 1s.
- *
- * == Asynchronous Tests ==
- *
- * Testing asynchronous features is somewhat more complex since the result of
- * a test may depend on one or more events or other callbacks. The API provided
- * for testing these features is indended to be rather low-level but hopefully
- * applicable to many situations.
- *
- * To create a test, one starts by getting a Test object using async_test:
- *
- * async_test(name, properties)
- *
- * e.g.
- * var t = async_test("Simple async test")
- *
- * Assertions can be added to the test by calling the step method of the test
- * object with a function containing the test assertions:
- *
- * t.step(function() {assert_true(true)});
- *
- * When all the steps are complete, the done() method must be called:
- *
- * t.done();
- *
- * The properties argument is identical to that for test().
- *
- * In many cases it is convenient to run a step in response to an event or a
- * callback. A convenient method of doing this is through the step_func method
- * which returns a function that, when called runs a test step. For example
- *
- * object.some_event = t.step_func(function(e) {assert_true(e.a)});
- *
- * == Making assertions ==
- *
- * Functions for making assertions start assert_
- * The best way to get a list is to look in this file for functions names
- * matching that pattern. The general signature is
- *
- * assert_something(actual, expected, description)
- *
- * although not all assertions precisely match this pattern e.g. assert_true
- * only takes actual and description as arguments.
- *
- * The description parameter is used to present more useful error messages when
- * a test fails
- *
- * NOTE: All asserts must be located in a test() or a step of an async_test().
- *       asserts outside these places won't be detected correctly by the
harness
- *       and may cause a file to stop testing.
- *
- * == Setup ==
- *
- * Sometimes tests require non-trivial setup that may fail. For this purpose
- * there is a setup() function, that may be called with one or two arguments.
- * The two argument version is:
- *
- * setup(func, properties)
- *
- * The one argument versions may omit either argument.
- * func is a function to be run synchronously. setup() becomes a no-op once
- * any tests have returned results. Properties are global properties of the
test
- * harness. Currently recognised properties are:
- *
- * timeout - The time in ms after which the harness should stop waiting for
- *           tests to complete (this is different to the per-test timeout
- *           because async tests do not start their timer until .step is
called)
- *
- * explicit_done - Wait for an explicit call to done() before declaring all
tests
- *                 complete (see below)
- *
- * output_document - The document to which results should be logged. By default
this is
- *                   the current document but could be an ancestor document in
some cases
- *                   e.g. a SVG test loaded in an HTML wrapper
- *
- * == Determining when all tests are complete ==
- *
- * By default the test harness will assume there are no more results to come
- * when:
- * 1) There are no Test objects that have been created but not completed
- * 2) The load event on the document has fired
- *
- * This behaviour can be overridden by setting the explicit_done property to
true
- * in a call to setup(). If explicit_done is true, the test harness will not
assume
- * it is done until the global done() function is called. Once done() is
called, the
- * two conditions above apply like normal.
- *
- * == Generating tests ==
- *
- * NOTE: this functionality may be removed
- *
- * There are scenarios in which is is desirable to create a large number of
- * (synchronous) tests that are internally similar but vary in the parameters
- * used. To make this easier, the generate_tests function allows a single
- * function to be called with each set of parameters in a list:
- *
- * generate_tests(test_function, parameter_lists)
- *
- * For example:
- *
- * generate_tests(assert_equals, [
- *     ["Sum one and one", 1+1, 2],
- *     ["Sum one and zero", 1+0, 1]
- *     ])
- *
- * Is equivalent to:
- *
- * test(function() {assert_equals(1+1, 2)}, "Sum one and one")
- * test(function() {assert_equals(1+0, 1)}, "Sum one and zero")
- *
- * Note that the first item in each parameter list corresponds to the name of
- * the test.
- *
- * == Callback API ==
- *
- * The framework provides callbacks corresponding to 3 events:
- *
- * start - happens when the first Test is created
- * result - happens when a test result is recieved
- * complete - happens when all results are recieved
- *
- * The page defining the tests may add callbacks for these events by calling
- * the following methods:
- *
- *   add_start_callback(callback) - callback called with no arguments
- *   add_result_callback(callback) - callback called with a test argument
- *   add_completion_callback(callback) - callback called with an array of tests
- *                                       and an status object
- *
- * tests have the following properties:
- *   status: A status code. This can be compared to the PASS, FAIL, TIMEOUT and
- *           NOTRUN properties on the test object
- *   message: A message indicating the reason for failure. In the future this
- *            will always be a string
- *
- *  The status object gives the overall status of the harness. It has the
- *  following properties:
- *    status: Can be compared to the OK, ERROR and TIMEOUT properties
- *    message: An error message set when the status is ERROR
- *
- * == External API ==
- *
- * In order to collect the results of multiple pages containing tests, the test
- * harness will, when loaded in a nested browsing context, attempt to call
- * certain functions in each ancestor browsing context:
- *
- * start - start_callback
- * result - result_callback
- * complete - completion_callback
- *
- * These are given the same arguments as the corresponding internal callbacks
- * described above.
- *
- * == List of assertions ==
- *
- * assert_true(actual, description)
- *   asserts that /actual/ is strictly true
- *
- * assert_false(actual, description)
- *   asserts that /actual/ is strictly false
- *
- * assert_equals(actual, expected, description)
- *   asserts that /actual/ is the same value as /expected/
- *
- * assert_not_equals(actual, expected, description)
- *   asserts that /actual/ is a different value to /expected/. Yes, this means
- *   that "expected" is a misnomer
- *
- * assert_in_array(actual, expected, description)
- *   asserts that /expected/ is an Array, and /actual/ is equal to one of the
- *   members -- expected.indexOf(actual) != -1
- *
- * assert_array_equals(actual, expected, description)
- *   asserts that /actual/ and /expected/ have the same length and the value of
- *   each indexed property in /actual/ is the strictly equal t…
(message too large)

[do-not-use, 2013-05-09 18:02:38]

I'm not sure what is happening, there is no conflict when rebasing on master
here.

It may be related to line terminators? The old file has <CRLF> and the new file
has <LF>.

[abarth-chromium, 2013-05-09 18:25:18]

In testharness.js?  We should probably revert the changes to that file.

[do-not-use, 2013-05-09 18:31:19]

On 2013/05/09 18:25:18, abarth wrote:
> In testharness.js?  We should probably revert the changes to that file.

Yes, the CQ seems to have trouble patching testharness.js. The file in the repo
has CRLF line terminators. I overwrote the file with a new version from upstream
that using LF line terminators.
It may not be related to line terminators at all, just my assumption.

I would prefer not revert the changes to testharness.js as this is a new version
from W3C that contains changes we need for the webperf test cases. I got the new
version from:
http://w3c-test.org/resources/testharness.js

[abarth-chromium, 2013-05-09 18:32:10]

Ok, then let's land the CL manually.

[do-not-use, 2013-05-09 19:39:13]

Committed patchset #6 manually as r150042 (presubmit successful).