|
|
Created:
4 years, 7 months ago by please use gerrit instead Modified:
4 years, 7 months ago Reviewers:
haraken, palmer, Marijn Kruisselbrink, Alexei Svitkine (slow), gone CC:
Aaron Boodman, abarth-chromium, asvitkine+watch_chromium.org, ben+mojo_chromium.org, blink-reviews, blink-reviews-api_chromium.org, chromium-reviews, darin (slow to review), dglazkov+blink, haraken, qsr+mojo_chromium.org, viettrungluu+watch_chromium.org, yzshen+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@explicit-shipping Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionImplement PaymentRequestUpdateEvent
When onShippingAddressChange or onShippingOptionChange event fires, the
event type should be PaymentRequestUpdateEvent with an updateWith()
method.
- The updateWith() method lets the merchant update the shipping options
and the total price.
- The updateWith() method cannot be called twice for the same event.
- The updateWith() method can be called only when the event is being
dispatched.
- Dispatching a PaymentRequestUpdateEvent created in JavaScript is a
no-op.
https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-paymentrequestupdateevent
BUG=607705
Committed: https://crrev.com/84234b56d641a989f709976793cff331b5488684
Cr-Commit-Position: refs/heads/master@{#392002}
Patch Set 1 #
Total comments: 2
Patch Set 2 : Rebase 1 #
Total comments: 13
Patch Set 3 : Rebase 2 & address comments #Patch Set 4 : Rebase 3 #
Total comments: 8
Patch Set 5 : Address comments #Patch Set 6 : Rebase #Patch Set 7 : Rebase #
Created: 4 years, 7 months ago
Messages
Total messages: 56 (35 generated)
Patchset #1 (id:1) has been deleted
Description was changed from ========== Implement PaymentRequestUpdateEvent When PaymentRequest.onShippingAddressChange or PaymentRequest.onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with a method updateWith(). This method should allow the merchant to update the shipping options and the total price. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 ========== to ========== Implement PaymentRequestUpdateEvent When PaymentRequest.onShippingAddressChange or PaymentRequest.onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with a method updateWith(). This method should allow the merchant to update the shipping options and the total price. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... If the merchant provides NULL shipping options, the merchant needs a shipping address to calculate shipping costs. The UI requires the user to make an address selection and passes that information to the merchant. If the merchant provides non-NULL shipping options, the merchant does not need shipping address to calculate shipping costs. The UI selects the default shipping address, but does not send it to the merchant until the user clicks "Pay". BUG=607705 ==========
Patchset #1 (id:20001) has been deleted
Patchset #1 (id:40001) has been deleted
Patchset #1 (id:60001) has been deleted
Patchset #1 (id:80001) has been deleted
Patchset #1 (id:100001) has been deleted
Patchset #1 (id:120001) has been deleted
Patchset #1 (id:140001) has been deleted
Patchset #1 (id:160001) has been deleted
Patchset #1 (id:180001) has been deleted
Patchset #1 (id:200001) has been deleted
Patchset #1 (id:220001) has been deleted
Patchset #1 (id:240001) has been deleted
Patchset #1 (id:260001) has been deleted
Patchset #1 (id:280001) has been deleted
Description was changed from ========== Implement PaymentRequestUpdateEvent When PaymentRequest.onShippingAddressChange or PaymentRequest.onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with a method updateWith(). This method should allow the merchant to update the shipping options and the total price. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... If the merchant provides NULL shipping options, the merchant needs a shipping address to calculate shipping costs. The UI requires the user to make an address selection and passes that information to the merchant. If the merchant provides non-NULL shipping options, the merchant does not need shipping address to calculate shipping costs. The UI selects the default shipping address, but does not send it to the merchant until the user clicks "Pay". BUG=607705 ========== to ========== Implement PaymentRequestUpdateEvent When PaymentRequest.onShippingAddressChange or PaymentRequest.onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with a method updateWith(). This method should allow the merchant to update the shipping options and the total price. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 ==========
Description was changed from ========== Implement PaymentRequestUpdateEvent When PaymentRequest.onShippingAddressChange or PaymentRequest.onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with a method updateWith(). This method should allow the merchant to update the shipping options and the total price. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 ========== to ========== Implement PaymentRequestUpdateEvent When PaymentRequest.onShippingAddressChange or PaymentRequest.onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with a method updateWith(). This method should allow the merchant to update the shipping options and the total price. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 ==========
Patchset #1 (id:300001) has been deleted
Patchset #1 (id:320001) has been deleted
rouslan@chromium.org changed reviewers: + dfalcantara@chromium.org, mek@chromium.org
dfalcantara@, ptal chrome/android/. mek@, ptal third_party/WebKit/Source/modules/payments/. Please ignore the trybot failures. This patch has dependencies that trybots do not pick up.
rouslan@chromium.org changed reviewers: + palmer@chromium.org
palmer@, ptal payment_request.mojom.
lgtm
mek@ and dfalcantara@: I am rebasing on top of the landed patches and applying your general comments from other code reviews here.
Has the rebase happened yet? Didn't see it uploaded.
haraken@chromium.org changed reviewers: + haraken@chromium.org
Binding implementation in modules/ LGTM. https://codereview.chromium.org/1931233002/diff/340001/third_party/WebKit/Sou... File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right): https://codereview.chromium.org/1931233002/diff/340001/third_party/WebKit/Sou... third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:401: m_showResolver.clear(); Don't you want to call cleanUp()?
https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/... File chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/... chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java:85: clickPaymentUIView("option line", R.id.payments_selectable_option); Won't this break if you have multiple selectable options? Are you relying on only ever having one?
https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:368: ASSERT_UNUSED(success, success); According to the deprecation comments in wtf/Assertions.h you should be using "DCHECK() and ALLOW_UNUSED_LOCAL()" instead of ASSERT_UNUSED() https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequestTest.cpp (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestTest.cpp:239: ((mojom::blink::PaymentRequestClient*)request)->OnPaymentResponse(std::move(response)); static_cast (also in the rest of the file) https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:95: return new PaymentRequestUpdateEvent(type); You should probably pass the EventInit to the constructor so it can be passed to Event's constructor. https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:105: promise.then(UpdatePaymentDetailsFunction::createFunction(scriptState, m_updater), This seems to be missing the various checks from the spec that can result in an InvalidStateError, as well as setting the stop propagation flags. https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.h (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.h:26: static PaymentRequestUpdateEvent* create(const AtomicString& type); Do you actually need a create method that takes a type but no Init dictionary? Other events with similar constructor signature seem to be able to get away with only having a create() and a create(type, init) method.
Description was changed from ========== Implement PaymentRequestUpdateEvent When PaymentRequest.onShippingAddressChange or PaymentRequest.onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with a method updateWith(). This method should allow the merchant to update the shipping options and the total price. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 ========== to ========== Implement PaymentRequestUpdateEvent When onShippingAddressChange or onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with an updateWith() method. - The updateWith() method lets the merchant update the shipping options and the total price. - The updateWith() method cannot be called twice for the same event. - The updateWith() method can be called only when the event is being dispatched. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 ==========
dfalcantara@ & mek@, ptal patch 4. haraken@, see my answer to your question below. https://chromiumcodereview.appspot.com/1931233002/diff/340001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right): https://chromiumcodereview.appspot.com/1931233002/diff/340001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:401: m_showResolver.clear(); On 2016/05/03 12:34:35, haraken wrote: > > Don't you want to call cleanUp()? Should not call cleanUp() here, because the merchant website still needs to process the payment and call response.complete(true/false). This allows the payment UI to display either "Payment processed" or "Failed to process payment" message. I've added a comment to clarify this. https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/... File chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/... chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java:85: clickPaymentUIView("option line", R.id.payments_selectable_option); On 2016/05/03 17:28:20, dfalcantara wrote: > Won't this break if you have multiple selectable options? Are you relying on > only ever having one? I am indeed relying on having only one in the integration test. When I write more advanced tests, I will figure out how to click the first, second, or third option. Are you OK with this approach? https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequest.cpp (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequest.cpp:368: ASSERT_UNUSED(success, success); On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote: > According to the deprecation comments in wtf/Assertions.h you should be using > "DCHECK() and ALLOW_UNUSED_LOCAL()" instead of ASSERT_UNUSED() Done. https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequestTest.cpp (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestTest.cpp:239: ((mojom::blink::PaymentRequestClient*)request)->OnPaymentResponse(std::move(response)); On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote: > static_cast (also in the rest of the file) Done. https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:95: return new PaymentRequestUpdateEvent(type); On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote: > You should probably pass the EventInit to the constructor so it can be passed to > Event's constructor. Done. https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:105: promise.then(UpdatePaymentDetailsFunction::createFunction(scriptState, m_updater), On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote: > This seems to be missing the various checks from the spec that can result in an > InvalidStateError, Now checking: - The event is being fired. - updateWith() is called only once. > as well as setting the stop propagation flags. Done. https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.h (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.h:26: static PaymentRequestUpdateEvent* create(const AtomicString& type); On 2016/05/03 17:57:28, Marijn Kruisselbrink wrote: > Do you actually need a create method that takes a type but no Init dictionary? > Other events with similar constructor signature seem to be able to get away with > only having a create() and a create(type, init) method. Done.
https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp (right): https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:101: DCHECK(m_updater); This can't just be a DCHECK, you need to actually handle m_updater being null (a javascript created PaymentRequestUpdateEvent won't have an updater set). https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:113: stopPropagation(); I think calling just stopImmediatePropagation() is enough, as in blink that implies also stopPropagation. https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web... File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEventTest.cpp (right): https://chromiumcodereview.appspot.com/1931233002/diff/400001/third_party/Web... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEventTest.cpp:16: #include <utility> probably just my fault, but I don't see where this header is used?
Description was changed from ========== Implement PaymentRequestUpdateEvent When onShippingAddressChange or onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with an updateWith() method. - The updateWith() method lets the merchant update the shipping options and the total price. - The updateWith() method cannot be called twice for the same event. - The updateWith() method can be called only when the event is being dispatched. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 ========== to ========== Implement PaymentRequestUpdateEvent When onShippingAddressChange or onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with an updateWith() method. - The updateWith() method lets the merchant update the shipping options and the total price. - The updateWith() method cannot be called twice for the same event. - The updateWith() method can be called only when the event is being dispatched. - Dispatching a PaymentRequestUpdateEvent created in JavaScript is a no-op. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 ==========
java stuff lgtm https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/... File chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java (right): https://chromiumcodereview.appspot.com/1931233002/diff/360001/chrome/android/... chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestTestBase.java:85: clickPaymentUIView("option line", R.id.payments_selectable_option); On 2016/05/03 21:38:33, Rouslan wrote: > On 2016/05/03 17:28:20, dfalcantara wrote: > > Won't this break if you have multiple selectable options? Are you relying on > > only ever having one? > > I am indeed relying on having only one in the integration test. When I write > more advanced tests, I will figure out how to click the first, second, or third > option. Are you OK with this approach? Yeah, sounds good. https://chromiumcodereview.appspot.com/1931233002/diff/400001/chrome/test/dat... File chrome/test/data/android/payments/payment_request_need_address_test.html (right): https://chromiumcodereview.appspot.com/1931233002/diff/400001/chrome/test/dat... chrome/test/data/android/payments/payment_request_need_address_test.html:46: {'requestShipping' : true}); nit: indentation looks weird here
Patchset #5 (id:420001) has been deleted
rouslan@chromium.org changed reviewers: + asvitkine@chromium.org
mek@, ptal patch 5. asvitkine@, ptal histograms.xml in patch 5. dfalcantara@, fyi, the integration tests are removed from this patch due to the strict mode issue. https://codereview.chromium.org/1931233002/diff/400001/chrome/test/data/andro... File chrome/test/data/android/payments/payment_request_need_address_test.html (right): https://codereview.chromium.org/1931233002/diff/400001/chrome/test/data/andro... chrome/test/data/android/payments/payment_request_need_address_test.html:46: {'requestShipping' : true}); On 2016/05/04 02:01:03, dfalcantara wrote: > nit: indentation looks weird here Removed integration tests from this patch. https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou... File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp (right): https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:101: DCHECK(m_updater); On 2016/05/03 22:28:51, Marijn Kruisselbrink wrote: > This can't just be a DCHECK, you need to actually handle m_updater being null (a > javascript created PaymentRequestUpdateEvent won't have an updater set). Done. https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEvent.cpp:113: stopPropagation(); On 2016/05/03 22:28:51, Marijn Kruisselbrink wrote: > I think calling just stopImmediatePropagation() is enough, as in blink that > implies also stopPropagation. Done. https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou... File third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEventTest.cpp (right): https://codereview.chromium.org/1931233002/diff/400001/third_party/WebKit/Sou... third_party/WebKit/Source/modules/payments/PaymentRequestUpdateEventTest.cpp:16: #include <utility> On 2016/05/03 22:28:51, Marijn Kruisselbrink wrote: > probably just my fault, but I don't see where this header is used? You're right. It's not used in this file. It was an artifact of copying from PaymentRequest.cpp to bootstrap. Removed this include and verified the other includes are used in this file.
lgtm
lgtm
The CQ bit was checked by rouslan@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from palmer@chromium.org, haraken@chromium.org, dfalcantara@chromium.org, mek@chromium.org Link to the patchset: https://codereview.chromium.org/1931233002/#ps460001 (title: "Rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1931233002/460001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1931233002/460001
The CQ bit was unchecked by commit-bot@chromium.org
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_...)
The CQ bit was checked by rouslan@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1931233002/460001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1931233002/460001
The CQ bit was unchecked by commit-bot@chromium.org
Failed to apply patch for third_party/WebKit/Source/core/frame/UseCounter.h: While running git apply --index -3 -p1; error: patch failed: third_party/WebKit/Source/core/frame/UseCounter.h:1154 Falling back to three-way merge... Applied patch to 'third_party/WebKit/Source/core/frame/UseCounter.h' with conflicts. U third_party/WebKit/Source/core/frame/UseCounter.h Patch: third_party/WebKit/Source/core/frame/UseCounter.h Index: third_party/WebKit/Source/core/frame/UseCounter.h diff --git a/third_party/WebKit/Source/core/frame/UseCounter.h b/third_party/WebKit/Source/core/frame/UseCounter.h index 432275a9999d44379407a3ac9188b7dafadb46b5..fa941da4f79bf4b3d569b5c779e56078dde928ac 100644 --- a/third_party/WebKit/Source/core/frame/UseCounter.h +++ b/third_party/WebKit/Source/core/frame/UseCounter.h @@ -1154,6 +1154,7 @@ public: During_Microtask_Print = 1336, During_Microtask_Prompt = 1337, During_Microtask_SyncXHR = 1338, + DocumentCreateEventPaymentRequestUpdateEvent = 1339, // Add new features immediately above this line. Don't change assigned // numbers of any item, and don't reuse removed slots.
The CQ bit was checked by rouslan@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org, palmer@chromium.org, mek@chromium.org, asvitkine@chromium.org, dfalcantara@chromium.org Link to the patchset: https://codereview.chromium.org/1931233002/#ps480001 (title: "Rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1931233002/480001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1931233002/480001
Message was sent while issue was closed.
Committed patchset #7 (id:480001)
Message was sent while issue was closed.
Description was changed from ========== Implement PaymentRequestUpdateEvent When onShippingAddressChange or onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with an updateWith() method. - The updateWith() method lets the merchant update the shipping options and the total price. - The updateWith() method cannot be called twice for the same event. - The updateWith() method can be called only when the event is being dispatched. - Dispatching a PaymentRequestUpdateEvent created in JavaScript is a no-op. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 ========== to ========== Implement PaymentRequestUpdateEvent When onShippingAddressChange or onShippingOptionChange event fires, the event type should be PaymentRequestUpdateEvent with an updateWith() method. - The updateWith() method lets the merchant update the shipping options and the total price. - The updateWith() method cannot be called twice for the same event. - The updateWith() method can be called only when the event is being dispatched. - Dispatching a PaymentRequestUpdateEvent created in JavaScript is a no-op. https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#idl-def-p... BUG=607705 Committed: https://crrev.com/84234b56d641a989f709976793cff331b5488684 Cr-Commit-Position: refs/heads/master@{#392002} ==========
Message was sent while issue was closed.
Patchset 7 (id:??) landed as https://crrev.com/84234b56d641a989f709976793cff331b5488684 Cr-Commit-Position: refs/heads/master@{#392002} |