CREDENTIAL: Teach Fetch to handle PasswordCredential objects.

CREDENTIAL: Teach Fetch to handle PasswordCredential objects.

As defined at [1], Fetch ought to be able to submit PasswordCredential
objects directly to an endpoint rather than walking through a FormData
intermediary. This patch implements that integration with 'RequestInit'
by teaching 'PasswordCredential' how to serialize itself as an
'EncodedFormData' object.

This patch also kills off the 'toFormData()' method of
'PasswordCredential', bringing it into line with the specification
changes at [2].

(TBRing myself because the presubmit script doesn't understand that
I own the new DEPS target)

[1]: http://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-1
[2]: http://w3c.github.io/webappsec-credential-management/#passwordcredential

BUG=556431
TBR=mkwst@chromium.org

Committed: https://crrev.com/fa8fab55d02ac6bbffc82550c1c0ef9e6f0d8500
Cr-Commit-Position: refs/heads/master@{#360427}

[Mike West, 2015-11-17 14:40:59]

Description was changed from

==========
CREDENTIAL: Teach Fetch to handle PasswordCredential objects.

As defined at [1], Fetch ought to be able to submit PasswordCredential
objects directly to an endpoint rather than walking through a FormData
intermediary. This is the first step towards that goal, implementing
the 'FormData' based integration. Once 'URLSearchParams' lands and is
itself integrated with Fetch, I'll add support for it as
'additionalData'.

BUG=556431
==========

to

==========
CREDENTIAL: Teach Fetch to handle PasswordCredential objects.

As defined at [1], Fetch ought to be able to submit PasswordCredential
objects directly to an endpoint rather than walking through a FormData
intermediary. This patch implements that integration with 'RequestInit'
by teaching 'PasswordCredential' how to serialize itself as an
'EncodedFormData' object.

[1]:
http://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-1

BUG=556431
==========

[Mike West, 2015-11-17 14:42:57]

mkwst@chromium.org changed reviewers:
+ horo@chromium.org, philipj@opera.com, tyoshino@chromium.org

[Mike West, 2015-11-17 14:42:57]

horo@, tyoshino@, would you mind taking a look at the Fetch integration? (Note
that this patch is based on https://codereview.chromium.org/1456553002, which I
hope you'll also be reviewing. :) )

philipj@: Since you reviewed the URLSearchParams bits of this already, would you
be interested in reviewing the integration with PasswordCredential? :)

[Mike West, 2015-11-17 14:44:18]

Description was changed from

==========
CREDENTIAL: Teach Fetch to handle PasswordCredential objects.

As defined at [1], Fetch ought to be able to submit PasswordCredential
objects directly to an endpoint rather than walking through a FormData
intermediary. This patch implements that integration with 'RequestInit'
by teaching 'PasswordCredential' how to serialize itself as an
'EncodedFormData' object.

[1]:
http://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-1

BUG=556431
==========

to

==========
CREDENTIAL: Teach Fetch to handle PasswordCredential objects.

As defined at [1], Fetch ought to be able to submit PasswordCredential
objects directly to an endpoint rather than walking through a FormData
intermediary. This patch implements that integration with 'RequestInit'
by teaching 'PasswordCredential' how to serialize itself as an
'EncodedFormData' object.

This patch also kills off the 'toFormData()' method of
'PasswordCredential', bringing it into line with the specification
changes at [2].


[1]:
http://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-1
[2]: http://w3c.github.io/webappsec-credential-management/#passwordcredential

BUG=556431
==========

[philipj_slow, 2015-11-17 15:53:59]

lgtm % nits for everything outside modules/fetch/, but I wouldn't mind taking a
second look if the changes are not tiny.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/credentialmanager/credentialscontainer-get-basics.html
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/credentialscontainer-get-basics.html:97:
assert_equals(c.additionalData, null);
The CredentialBodyType type isn't nullable, so how can this be?

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-basics.html
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-basics.html:87:
assert_true(credential.additionalData instanceof FormData);
Maybe assert that it is the same object that was assigned? More explicit and it
would fail if there was a copy involved.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-basics.html:88:
}, 'Poke at the Fetch-related bits');
An honest name, but maybe "something something basic"? :)

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:7:
async_test(function(t) {
I don't know if it will simplify or not, but there's a promise_test() helper
that's used for some other tests involving fetch(), and it saves the trouble of
explicitly handling rejections.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:17:
r.json().then(
I think you could also flatten this kind of structure a bit, to something more
like

return fetch("./resources/echo-post.php", { body: credential, method: "POST" }))
  .then(r => r.json())
  .then(function(j) { assert_equals ... });

I'm not a Promise guru though, so I'm not sure what the coolest way is, that's
just what I've done before. If you try, you might want to ensure that a failing
assert gives a sensible message and doesn't just end up in the unhandled promise
rejection bucket, i.e. will you need wrap assertions in t.step_func?

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:104:
}, "'additionalData': FormData properties are properly injected.");
The spec requires a specific order (idName+passwordName last?) as well, can you
find a way to check that?

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:156:
}, "'additionalData': URLSearchParams properties are properly injected.");
Same question about order.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/credentialmanager/Credential.h (right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/Credential.h:17: class
Credential : public GarbageCollectedFinalized<Credential>, public
ScriptWrappable {
Why was this change needed? I can't see a member that has changed, or anything
obvious of that kind.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.cpp
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.cpp:60:
return params->encodeFormData();
Here and below I assume that idName() and passwordName() could be invalid
UTF-16, does the spec say what should happen, or should they be turned into
USVString in the IDL?

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.cpp:69:
formData->append(formData->decode(entry->name()), entry->blob(),
entry->filename());
Should this algorithm match the FormData branch of
http://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-1 ?

I think this is right, but can you confirm that the 'with "utf-8" as the
explicit character encoding' bit in the spec is only for the actual encoding
step at the end of this function, and has nothing to do with how to intepret the
FormData object? Also, isn't there an existing implementation of
"multipart/form-data encoding algorithm" to use? It's nice when the structure of
spec and implementation is similar :)

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.idl
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.idl:8:
RuntimeEnabled=CredentialManager,
Can you add TypeChecking=Interface to this interface, and indeed for anything
that's still behind this flag? It ought to change the generated code at least
somewhat.

[horo, 2015-11-18 05:14:10]

lgtm with nits

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/fetch/Body.h (right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/fetch/Body.h:11: #include
"core/dom/DOMException.h"
remove

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/fetch/Request.cpp (right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/fetch/Request.cpp:320: // "34. If |init|'s
body member is a 'Credential' object:
These numbers match the numbers in Fetch spec.
So please don't use "34" here.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/fetch/RequestInit.cpp (right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/fetch/RequestInit.cpp:23: #include
"platform/NotImplemented.h"
remove

[Mike West, 2015-11-18 09:12:51]

Thanks to you both.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/credentialmanager/credentialscontainer-get-basics.html
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/credentialscontainer-get-basics.html:97:
assert_equals(c.additionalData, null);
On 2015/11/17 at 15:53:58, philipj wrote:
> The CredentialBodyType type isn't nullable, so how can this be?

Hey, look at that! The `additionalData` attribute is nullable now! :)

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-basics.html
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-basics.html:87:
assert_true(credential.additionalData instanceof FormData);
On 2015/11/17 at 15:53:59, philipj wrote:
> Maybe assert that it is the same object that was assigned? More explicit and
it would fail if there was a copy involved.

Sounds good.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-basics.html:88:
}, 'Poke at the Fetch-related bits');
On 2015/11/17 at 15:53:59, philipj wrote:
> An honest name, but maybe "something something basic"? :)

:)

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:7:
async_test(function(t) {
On 2015/11/17 at 15:53:59, philipj wrote:
> I don't know if it will simplify or not, but there's a promise_test() helper
that's used for some other tests involving fetch(), and it saves the trouble of
explicitly handling rejections.

Looks like a pretty reasonable simplification.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:17:
r.json().then(
On 2015/11/17 at 15:53:59, philipj wrote:
> I think you could also flatten this kind of structure a bit, to something more
like
> 
> return fetch("./resources/echo-post.php", { body: credential, method: "POST"
}))
>   .then(r => r.json())
>   .then(function(j) { assert_equals ... });
> 
> I'm not a Promise guru though, so I'm not sure what the coolest way is, that's
just what I've done before.

This looks pretty cool to me!

> If you try, you might want to ensure that a failing assert gives a sensible
message and doesn't just end up in the unhandled promise rejection bucket, i.e.
will you need wrap assertions in t.step_func?

I'd think that splitting things up into multiple `promise_test`s, and giving
each test a reasonable messages would be enough. Why don't I try that rather
than wrapping everything in more functions?

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:104:
}, "'additionalData': FormData properties are properly injected.");
On 2015/11/17 at 15:53:59, philipj wrote:
> The spec requires a specific order (idName+passwordName last?) as well, can
you find a way to check that?

This is going to be difficult to do with FormData. Both Perl's CGI module's
`params('POSTDATA')` and PHP's `php://input` return "" when faced with multipart
POSTs.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:156:
}, "'additionalData': URLSearchParams properties are properly injected.");
On 2015/11/17 at 15:53:59, philipj wrote:
> Same question about order.

This will be simpler. :)

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/credentialmanager/Credential.h (right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/Credential.h:17: class
Credential : public GarbageCollectedFinalized<Credential>, public
ScriptWrappable {
On 2015/11/17 at 15:53:59, philipj wrote:
> Why was this change needed? I can't see a member that has changed, or anything
obvious of that kind.

I added `String` members to `PasswordCredential`, which subclasses `Credential`.
Assuming I've understood the error messages correctly, those need to be
finalized, so `Credential` needs to be finalized.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.cpp
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.cpp:60:
return params->encodeFormData();
On 2015/11/17 at 15:53:59, philipj wrote:
> Here and below I assume that idName() and passwordName() could be invalid
UTF-16, does the spec say what should happen, or should they be turned into
USVString in the IDL?

They should be turned into USVString to match the interfaces for FormData and
URLSearchParams. Good eye!

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.cpp:69:
formData->append(formData->decode(entry->name()), entry->blob(),
entry->filename());
On 2015/11/17 at 15:53:59, philipj wrote:
> Should this algorithm match the FormData branch of
http://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-1 ?

We would more accurately follow the spec if we moved all of this code into
`RequestInit`. I don't really want to do that, as I'd prefer to keep
`PasswordCredential` in charge of its own encoding. Perhaps that means the spec
changes could be restructured to call out to something that the Credential
Management spec defines. Now that I think about it, that sounds like a pretty
reasonable change, and pretty much in line with what we've done in other specs
to provide Fetch hooks.

> I think this is right, but can you confirm that the 'with "utf-8" as the
explicit character encoding' bit in the spec is only for the actual encoding
step at the end of this function, and has nothing to do with how to intepret the
FormData object?

Right. The `FormData` object itself just puts `Entries` (USVString pairs,
key/blob pairs) into a list. The encoding piece at the end is what needs to
worry about the text encoding of those values.

> Also, isn't there an existing implementation of "multipart/form-data encoding
algorithm" to use? It's nice when the structure of spec and implementation is
similar :)

Chromium's basically implemented that algorithm as part of the FormData object
(see
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...),
which we call at #77 to produce the EncodedFormData. I don't think it's worth
trying to extract that code to match the spec language, as we only ever use it
in cases where we actually have a FormData object.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/fetch/RequestInit.cpp (right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/fetch/RequestInit.cpp:23: #include
"platform/NotImplemented.h"
On 2015/11/18 at 05:14:09, horo wrote:
> remove

Done.

[philipj_slow, 2015-11-18 10:00:05]

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/credentialmanager/credentialscontainer-get-basics.html
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/credentialscontainer-get-basics.html:97:
assert_equals(c.additionalData, null);
On 2015/11/18 09:12:50, Mike West wrote:
> On 2015/11/17 at 15:53:58, philipj wrote:
> > The CredentialBodyType type isn't nullable, so how can this be?
> 
> Hey, look at that! The `additionalData` attribute is nullable now! :)

Where? I don't see the nullable change in implementation or spec.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:7:
async_test(function(t) {
On 2015/11/18 09:12:51, Mike West wrote:
> On 2015/11/17 at 15:53:59, philipj wrote:
> > I don't know if it will simplify or not, but there's a promise_test() helper
> that's used for some other tests involving fetch(), and it saves the trouble
of
> explicitly handling rejections.
> 
> Looks like a pretty reasonable simplification.

Yep, it turned out pretty nice!

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:104:
}, "'additionalData': FormData properties are properly injected.");
On 2015/11/18 09:12:51, Mike West wrote:
> On 2015/11/17 at 15:53:59, philipj wrote:
> > The spec requires a specific order (idName+passwordName last?) as well, can
> you find a way to check that?
> 
> This is going to be difficult to do with FormData. Both Perl's CGI module's
> `params('POSTDATA')` and PHP's `php://input` return "" when faced with
multipart
> POSTs.

Fair enough :)

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/credentialmanager/Credential.h (right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/Credential.h:17: class
Credential : public GarbageCollectedFinalized<Credential>, public
ScriptWrappable {
On 2015/11/18 09:12:51, Mike West wrote:
> On 2015/11/17 at 15:53:59, philipj wrote:
> > Why was this change needed? I can't see a member that has changed, or
anything
> obvious of that kind.
> 
> I added `String` members to `PasswordCredential`, which subclasses
`Credential`.
> Assuming I've understood the error messages correctly, those need to be
> finalized, so `Credential` needs to be finalized.

Ah, a subclass, thanks!

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.cpp
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.cpp:69:
formData->append(formData->decode(entry->name()), entry->blob(),
entry->filename());
On 2015/11/18 09:12:51, Mike West wrote:
> On 2015/11/17 at 15:53:59, philipj wrote:
> > Should this algorithm match the FormData branch of
> http://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-1
?
> 
> We would more accurately follow the spec if we moved all of this code into
> `RequestInit`. I don't really want to do that, as I'd prefer to keep
> `PasswordCredential` in charge of its own encoding. Perhaps that means the
spec
> changes could be restructured to call out to something that the Credential
> Management spec defines. Now that I think about it, that sounds like a pretty
> reasonable change, and pretty much in line with what we've done in other specs
> to provide Fetch hooks.

OK, possible future spec refactoring it is!

> > I think this is right, but can you confirm that the 'with "utf-8" as the
> explicit character encoding' bit in the spec is only for the actual encoding
> step at the end of this function, and has nothing to do with how to intepret
the
> FormData object?
> 
> Right. The `FormData` object itself just puts `Entries` (USVString pairs,
> key/blob pairs) into a list. The encoding piece at the end is what needs to
> worry about the text encoding of those values.

Ack.

> > Also, isn't there an existing implementation of "multipart/form-data
encoding
> algorithm" to use? It's nice when the structure of spec and implementation is
> similar :)
> 
> Chromium's basically implemented that algorithm as part of the FormData object
> (see
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...),
> which we call at #77 to produce the EncodedFormData. I don't think it's worth
> trying to extract that code to match the spec language, as we only ever use it
> in cases where we actually have a FormData object.

I see, it was close by all along. Makes sense the way it is.

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.idl
(right):

https://codereview.chromium.org/1446963002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/credentialmanager/PasswordCredential.idl:8:
RuntimeEnabled=CredentialManager,
On 2015/11/17 15:53:59, philipj wrote:
> Can you add TypeChecking=Interface to this interface, and indeed for anything
> that's still behind this flag? It ought to change the generated code at least
> somewhat.

Ping.

https://codereview.chromium.org/1446963002/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html
(right):

https://codereview.chromium.org/1446963002/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/http/tests/credentialmanager/passwordcredential-fetch.html:158:
.then(function (t) {
Maybe expand this to text since t is also the test in the outer function? (If
that's unused, you could drop it too.)

Also, yay for this test!

[Mike West, 2015-11-18 13:45:52]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-11-18 13:46:24]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1446963002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1446963002/60001

[commit-bot: I haz the power, 2015-11-18 13:54:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-18 13:54:25]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Mike West, 2015-11-18 14:52:33]

The CQ bit was checked by mkwst@chromium.org

[Mike West, 2015-11-18 14:52:33]

The patchset sent to the CQ was uploaded after l-g-t-m from philipj@opera.com,
horo@chromium.org
Link to the patchset: https://codereview.chromium.org/1446963002/#ps80001
(title: "Ugh.")

[Mike West, 2015-11-18 14:52:37]

The CQ bit was unchecked by mkwst@chromium.org

[Mike West, 2015-11-18 15:04:21]

The CQ bit was checked by mkwst@chromium.org

[Mike West, 2015-11-18 15:04:21]

The patchset sent to the CQ was uploaded after l-g-t-m from philipj@opera.com,
horo@chromium.org
Link to the patchset: https://codereview.chromium.org/1446963002/#ps100001
(title: "webexposed")

[commit-bot: I haz the power, 2015-11-18 15:04:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1446963002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1446963002/100001

[commit-bot: I haz the power, 2015-11-18 15:13:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-18 15:13:53]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Mike West, 2015-11-18 16:08:03]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[Mike West, 2015-11-18 16:08:41]

Description was changed from

==========
CREDENTIAL: Teach Fetch to handle PasswordCredential objects.

As defined at [1], Fetch ought to be able to submit PasswordCredential
objects directly to an endpoint rather than walking through a FormData
intermediary. This patch implements that integration with 'RequestInit'
by teaching 'PasswordCredential' how to serialize itself as an
'EncodedFormData' object.

This patch also kills off the 'toFormData()' method of
'PasswordCredential', bringing it into line with the specification
changes at [2].


[1]:
http://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-1
[2]: http://w3c.github.io/webappsec-credential-management/#passwordcredential

BUG=556431
==========

to

==========
CREDENTIAL: Teach Fetch to handle PasswordCredential objects.

As defined at [1], Fetch ought to be able to submit PasswordCredential
objects directly to an endpoint rather than walking through a FormData
intermediary. This patch implements that integration with 'RequestInit'
by teaching 'PasswordCredential' how to serialize itself as an
'EncodedFormData' object.

This patch also kills off the 'toFormData()' method of
'PasswordCredential', bringing it into line with the specification
changes at [2].

(TBRing myself because the presubmit script doesn't understand that
I own the new DEPS target)

[1]:
http://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-1
[2]: http://w3c.github.io/webappsec-credential-management/#passwordcredential

BUG=556431
TBR=mkwst@chromium.org
==========

[commit-bot: I haz the power, 2015-11-18 16:09:31]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1446963002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1446963002/100001

[commit-bot: I haz the power, 2015-11-18 19:15:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-18 19:15:56]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Mike West, 2015-11-18 20:46:08]

The CQ bit was checked by mkwst@chromium.org

[commit-bot: I haz the power, 2015-11-18 20:46:34]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1446963002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1446963002/100001

[commit-bot: I haz the power, 2015-11-18 22:06:18]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-11-18 22:07:55]

Patchset 6 (id:??) landed as
https://crrev.com/fa8fab55d02ac6bbffc82550c1c0ef9e6f0d8500
Cr-Commit-Position: refs/heads/master@{#360427}

[tyoshino (SeeGerritForStatus), 2015-11-24 14:53:34]

Sorry for delay. Found some issues. I'll send a follow up CL tomorrow instead of
making comments here.

[tyoshino (SeeGerritForStatus), 2015-11-25 14:44:49]

On 2015/11/24 14:53:34, tyoshino wrote:
> Sorry for delay. Found some issues. I'll send a follow up CL tomorrow instead
of
> making comments here.

Done
- https://codereview.chromium.org/1476003002/
- https://codereview.chromium.org/1472143003/