Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2566943002:
Dispatch transfer size update notification on mojo-loading (Closed)
|
Created:
4 years ago by yhirano Modified:
4 years ago CC:
chromium-reviews, qsr+mojo_chromium.org, viettrungluu+watch_chromium.org, yzshen+watch_chromium.org, kinuko+watch, jsbell+serviceworker_chromium.org, tzik, jam, abarth-chromium, darin-cc_chromium.org, loading-reviews_chromium.org, blink-worker-reviews_chromium.org, mlamouri+watch-content_chromium.org, Randy Smith (Not in Mondays), nhiroki, blink-reviews, michaeln, shimazu+serviceworker_chromium.org, serviceworker-reviews, Aaron Boodman, kinuko+serviceworker, horo+watch_chromium.org, darin (slow to review), mmenke Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionDispatch transfer size update notification on mojo-loading
With this CL, MojoAsyncResourceHandler dispatches OnTransferSizeUpdated messages
when report_raw_headers is set in the request. This is for devtools which needs
transfer size update events.
BUG=603396
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester
Committed: https://crrev.com/a275b3ccec68e3e75a81bd6b51fd937fabf97416
Cr-Commit-Position: refs/heads/master@{#439697}
Patch Set 1 #Patch Set 2 : fix #
Total comments: 16
Patch Set 3 : fix #Patch Set 4 : fix #Patch Set 5 : fix #Patch Set 6 : fix #
Total comments: 12
Patch Set 7 : fix #Patch Set 8 : rebase #Patch Set 9 : fix #Messages
Total messages: 65 (48 generated)
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Patchset #2 (id:20001) has been deleted
Patchset #2 (id:40001) has been deleted
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Dispatch transfer size update notification on mojo-loading BUG=603396 ========== to ========== Dispatch transfer size update notification on mojo-loading With this CL, MojoAsyncResourceHandler dispatched OnTransferSizeUpdated messages when report_raw_headers is set in the request. This is for devtools which needs transfer size update events. BUG=603396 ==========
yhirano@chromium.org changed reviewers: + dcheng@chromium.org, jam@chromium.org, mmenke@chromium.org, tzik@chromium.org
yhirano@chromium.org changed reviewers: - dcheng@chromium.org, jam@chromium.org, mmenke@chromium.org
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
yhirano@chromium.org changed reviewers: + mmenke@chromium.org
+mmenke@
lgtm
Just looked at content/browser and content/common (Don't really know the rest). https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... File content/browser/loader/mojo_async_resource_handler.cc (right): https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/mojo_async_resource_handler.cc:147: reported_total_received_bytes_ = 0; This isn't doing anything - we don't call OnResponseStarted until after all redirects. https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/mojo_async_resource_handler.cc:169: reported_total_received_bytes_ = response->head.encoded_data_length; Looks like the old API didn't filter these out. Is this a bug fix, or just a modified API? https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... File content/browser/loader/mojo_async_resource_handler.h (right): https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/mojo_async_resource_handler.h:94: int64_t CalculateTransferSizeDiff(); Mind adding a description to what this does? Not clear that it reports extra bytes read since the last call to this method. Also maybe rename it. CalculateRecentlyReceivedBytes? (Received is clearer than transfer, recently at least gives some implication that there's a time window involved, though isn't completely on clear on what that is). Or GetBytesReceivedSinceLastCall? https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... File content/browser/loader/test_url_loader_client.cc (right): https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/test_url_loader_client.cc:48: void TestURLLoaderClient::OnTransferSizeUpdated(int64_t transfer_size_diff) { EXPECT_GT(transfer_size_diff, 0);? https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... File content/browser/loader/url_loader_factory_impl_unittest.cc (right): https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/url_loader_factory_impl_unittest.cc:93: ChildProcessSecurityPolicyImpl::GetInstance()->Add(kChildId); Why is this now needed? https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/url_loader_factory_impl_unittest.cc:215: EXPECT_EQ(0, client.body_transfer_size()); Is this any different from client.completion_status().encoded_data_length - client.completion_status().encoded_body_length? I guess it's just available earlier? https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/url_loader_factory_impl_unittest.cc:215: EXPECT_EQ(0, client.body_transfer_size()); Maybe check head.encoded_data_length in this test, and the one below? https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/url_loader_factory_impl_unittest.cc:488: client.completion_status().encoded_data_length); URLRequestMockHTTPJob doesn't claim to receive any header bytes, so maybe change that? Also, URLRequestMockHTTPJob reports encoded_data_length as being the same as the body length. To be sure we're recording the right things, could we do a test with an actual compressed response, and make sure the encoded body size is less than the actual body size? You can just use "download/gzip-content.gz", I believe.
Description was changed from ========== Dispatch transfer size update notification on mojo-loading With this CL, MojoAsyncResourceHandler dispatched OnTransferSizeUpdated messages when report_raw_headers is set in the request. This is for devtools which needs transfer size update events. BUG=603396 ========== to ========== Dispatch transfer size update notification on mojo-loading With this CL, MojoAsyncResourceHandler dispatched OnTransferSizeUpdated messages when report_raw_headers is set in the request. This is for devtools which needs transfer size update events. BUG=603396 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester ==========
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... File content/browser/loader/mojo_async_resource_handler.cc (right): https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/mojo_async_resource_handler.cc:147: reported_total_received_bytes_ = 0; On 2016/12/13 20:01:25, mmenke wrote: > This isn't doing anything - we don't call OnResponseStarted until after all > redirects. Done. https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/mojo_async_resource_handler.cc:169: reported_total_received_bytes_ = response->head.encoded_data_length; On 2016/12/13 20:01:25, mmenke wrote: > Looks like the old API didn't filter these out. Is this a bug fix, or just a > modified API? AsyncResourceHandler has a special handling in OnReadCompleted: if (!first_chunk_read_) encoded_data_length -= request()->raw_header_size(); But OnDataDownloaded doesn't have it and notifies a wrong value. Yes, I think it's a bug and this is a bug-fix. https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... File content/browser/loader/mojo_async_resource_handler.h (right): https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/mojo_async_resource_handler.h:94: int64_t CalculateTransferSizeDiff(); On 2016/12/13 20:01:25, mmenke wrote: > Mind adding a description to what this does? Not clear that it reports extra > bytes read since the last call to this method. > > Also maybe rename it. CalculateRecentlyReceivedBytes? (Received is clearer > than transfer, recently at least gives some implication that there's a time > window involved, though isn't completely on clear on what that is). Or > GetBytesReceivedSinceLastCall? Done. https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... File content/browser/loader/test_url_loader_client.cc (right): https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/test_url_loader_client.cc:48: void TestURLLoaderClient::OnTransferSizeUpdated(int64_t transfer_size_diff) { On 2016/12/13 20:01:25, mmenke wrote: > EXPECT_GT(transfer_size_diff, 0);? Done. https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... File content/browser/loader/url_loader_factory_impl_unittest.cc (right): https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/url_loader_factory_impl_unittest.cc:93: ChildProcessSecurityPolicyImpl::GetInstance()->Add(kChildId); On 2016/12/13 20:01:25, mmenke wrote: > Why is this now needed? Added comments. https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/url_loader_factory_impl_unittest.cc:215: EXPECT_EQ(0, client.body_transfer_size()); On 2016/12/13 20:01:25, mmenke wrote: > Is this any different from client.completion_status().encoded_data_length - > client.completion_status().encoded_body_length? I guess it's just available > earlier? Yes, it's different. OnTransferSizeUpdated is notified only when report_raw_headers is specified, and this test checks it is not notified. https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/url_loader_factory_impl_unittest.cc:215: EXPECT_EQ(0, client.body_transfer_size()); On 2016/12/13 20:01:25, mmenke wrote: > Maybe check head.encoded_data_length in this test, and the one below? Done. https://codereview.chromium.org/2566943002/diff/60001/content/browser/loader/... content/browser/loader/url_loader_factory_impl_unittest.cc:488: client.completion_status().encoded_data_length); On 2016/12/13 20:01:25, mmenke wrote: > URLRequestMockHTTPJob doesn't claim to receive any header bytes, so maybe change > that? > > Also, URLRequestMockHTTPJob reports encoded_data_length as being the same as the > body length. To be sure we're recording the right things, could we do a test > with an actual compressed response, and make sure the encoded body size is less > than the actual body size? You can just use "download/gzip-content.gz", I > believe. Done.
yhirano@chromium.org changed reviewers: + dcheng@chromium.org, jam@chromium.org
+jam@ for content/ +dcheng@ for content/common/url_loader.mojom
content/browser/loader LGTM! https://codereview.chromium.org/2566943002/diff/140001/content/browser/loader... File content/browser/loader/url_loader_factory_impl_unittest.cc (right): https://codereview.chromium.org/2566943002/diff/140001/content/browser/loader... content/browser/loader/url_loader_factory_impl_unittest.cc:507: EXPECT_GT(client.completion_status().encoded_data_length, 0); Optional: Could use EXPECT_EQ and GetFileSize on the resource, though have to figure out the right full path. The headers are also in a separate file and could do the same for then. Not going to insist on doing that, though, I'm just paranoid.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Description was changed from ========== Dispatch transfer size update notification on mojo-loading With this CL, MojoAsyncResourceHandler dispatched OnTransferSizeUpdated messages when report_raw_headers is set in the request. This is for devtools which needs transfer size update events. BUG=603396 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester ========== to ========== Dispatch transfer size update notification on mojo-loading With this CL, MojoAsyncResourceHandler dispatches OnTransferSizeUpdated messages when report_raw_headers is set in the request. This is for devtools which needs transfer size update events. BUG=603396 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester ==========
https://codereview.chromium.org/2566943002/diff/140001/content/child/resource... File content/child/resource_dispatcher.cc (right): https://codereview.chromium.org/2566943002/diff/140001/content/child/resource... content/child/resource_dispatcher.cc:585: int transfer_size_diff) { Can we use int64_t or int uniformly? It seems like the current code mostly send this as an int, but I'm not familiar enough with the loading machinery to say what we want long-term here. https://codereview.chromium.org/2566943002/diff/140001/content/child/resource... content/child/resource_dispatcher.cc:587: PendingRequestInfo* request_info = GetPendingRequestInfo(request_id); Unrelated, but I wish this class used GetPendingRequestInfo() or pending_requests_.find() more uniformly. https://codereview.chromium.org/2566943002/diff/140001/content/common/url_loa... File content/common/url_loader.mojom (right): https://codereview.chromium.org/2566943002/diff/140001/content/common/url_loa... content/common/url_loader.mojom:56: // and OnReceiveRedirect). It must be positive. Nit: usually we use unsigned to express that "it must be positive". I guess that would be a lot of trouble to change now... but it might be worth fixing eventually? https://codereview.chromium.org/2566943002/diff/140001/content/renderer/servi... File content/renderer/service_worker/service_worker_context_client.cc (right): https://codereview.chromium.org/2566943002/diff/140001/content/renderer/servi... content/renderer/service_worker/service_worker_context_client.cc:292: void OnTransferSizeUpdated(int64_t transfer_size_diff) override {} Is this a NOTIMPLEMENTED() (yet) or NOTREACHED()?
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: ios-device on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...) ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...) ios-simulator on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...) ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2566943002/diff/140001/content/browser/loader... File content/browser/loader/url_loader_factory_impl_unittest.cc (right): https://codereview.chromium.org/2566943002/diff/140001/content/browser/loader... content/browser/loader/url_loader_factory_impl_unittest.cc:507: EXPECT_GT(client.completion_status().encoded_data_length, 0); On 2016/12/14 18:18:55, mmenke (Out Dec 17 to Jan 2) wrote: > Optional: Could use EXPECT_EQ and GetFileSize on the resource, though have to > figure out the right full path. The headers are also in a separate file and > could do the same for then. Not going to insist on doing that, though, I'm just > paranoid. Replaced EXPECT_GT with EXPECT_EQ (for the encoded_body_size only). https://codereview.chromium.org/2566943002/diff/140001/content/child/resource... File content/child/resource_dispatcher.cc (right): https://codereview.chromium.org/2566943002/diff/140001/content/child/resource... content/child/resource_dispatcher.cc:585: int transfer_size_diff) { On 2016/12/15 06:29:02, dcheng wrote: > Can we use int64_t or int uniformly? It seems like the current code mostly send > this as an int, but I'm not familiar enough with the loading machinery to say > what we want long-term here. I added a TODO comment. https://codereview.chromium.org/2566943002/diff/140001/content/child/resource... content/child/resource_dispatcher.cc:587: PendingRequestInfo* request_info = GetPendingRequestInfo(request_id); On 2016/12/15 06:29:02, dcheng wrote: > Unrelated, but I wish this class used GetPendingRequestInfo() or > pending_requests_.find() more uniformly. There are four pending_request_.find() in this file and SetDefersLoading in the only call that can be replaced with GetPendingRequestInfo(). Done. https://codereview.chromium.org/2566943002/diff/140001/content/common/url_loa... File content/common/url_loader.mojom (right): https://codereview.chromium.org/2566943002/diff/140001/content/common/url_loa... content/common/url_loader.mojom:56: // and OnReceiveRedirect). It must be positive. On 2016/12/15 06:29:02, dcheng wrote: > Nit: usually we use unsigned to express that "it must be positive". I guess that > would be a lot of trouble to change now... but it might be worth fixing > eventually? Google c++ style guide says " You should not use the unsigned integer types such as uint32_t, unless there is a valid reason such as representing a bit pattern rather than a number, or you need defined overflow modulo 2^N. In particular, do not use unsigned types to say a number will never be negative. Instead, use assertions for this. " https://google.github.io/styleguide/cppguide.html#Integer_Types so I am using signed int. https://codereview.chromium.org/2566943002/diff/140001/content/renderer/servi... File content/renderer/service_worker/service_worker_context_client.cc (right): https://codereview.chromium.org/2566943002/diff/140001/content/renderer/servi... content/renderer/service_worker/service_worker_context_client.cc:292: void OnTransferSizeUpdated(int64_t transfer_size_diff) override {} On 2016/12/15 06:29:02, dcheng wrote: > Is this a NOTIMPLEMENTED() (yet) or NOTREACHED()? Done.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/2566943002/diff/140001/content/common/url_loa... File content/common/url_loader.mojom (right): https://codereview.chromium.org/2566943002/diff/140001/content/common/url_loa... content/common/url_loader.mojom:56: // and OnReceiveRedirect). It must be positive. On 2016/12/15 11:28:00, yhirano wrote: > On 2016/12/15 06:29:02, dcheng wrote: > > Nit: usually we use unsigned to express that "it must be positive". I guess > that > > would be a lot of trouble to change now... but it might be worth fixing > > eventually? > > Google c++ style guide says > > " > You should not use the unsigned integer types such as uint32_t, unless there is > a valid reason such as representing a bit pattern rather than a number, or you > need defined overflow modulo 2^N. In particular, do not use unsigned types to > say a number will never be negative. Instead, use assertions for this. > " > > https://google.github.io/styleguide/cppguide.html#Integer_Types > > so I am using signed int. google style really dislikes unsigned. However, for IPC, we do explicitly recommend using unsigned: https://www.chromium.org/Home/chromium-security/education/security-tips-for-i.... I think it's OK to add a TODO for that (since that matches legacy ipc). However, for the integer size issue, is it OK to just use int32 for now? We can change this to int64 if/when we decide to change the integer types throughout the rest of the system.
The CQ bit was checked by yhirano@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2566943002/diff/140001/content/common/url_loa... File content/common/url_loader.mojom (right): https://codereview.chromium.org/2566943002/diff/140001/content/common/url_loa... content/common/url_loader.mojom:56: // and OnReceiveRedirect). It must be positive. On 2016/12/15 16:23:59, dcheng wrote: > On 2016/12/15 11:28:00, yhirano wrote: > > On 2016/12/15 06:29:02, dcheng wrote: > > > Nit: usually we use unsigned to express that "it must be positive". I guess > > that > > > would be a lot of trouble to change now... but it might be worth fixing > > > eventually? > > > > Google c++ style guide says > > > > " > > You should not use the unsigned integer types such as uint32_t, unless there > is > > a valid reason such as representing a bit pattern rather than a number, or you > > need defined overflow modulo 2^N. In particular, do not use unsigned types to > > say a number will never be negative. Instead, use assertions for this. > > " > > > > https://google.github.io/styleguide/cppguide.html#Integer_Types > > > > so I am using signed int. > > google style really dislikes unsigned. However, for IPC, we do explicitly > recommend using unsigned: > https://www.chromium.org/Home/chromium-security/education/security-tips-for-i.... > > I think it's OK to add a TODO for that (since that matches legacy ipc). However, > for the integer size issue, is it OK to just use int32 for now? We can change > this to int64 if/when we decide to change the integer types throughout the rest > of the system. Done.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm
jam@: can you take a look at this change?
lgtm
The CQ bit was checked by yhirano@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from tzik@chromium.org, mmenke@chromium.org Link to the patchset: https://codereview.chromium.org/2566943002/#ps200001 (title: "fix")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 200001, "attempt_start_ts": 1482201126307650,
"parent_rev": "199882427bf82179c6c4e296f13f8cc7787cfd0c", "commit_rev":
"c15f4e860cffaa4425beb527c6ebd6a5b27ceb04"}
Message was sent while issue was closed.
Description was changed from ========== Dispatch transfer size update notification on mojo-loading With this CL, MojoAsyncResourceHandler dispatches OnTransferSizeUpdated messages when report_raw_headers is set in the request. This is for devtools which needs transfer size update events. BUG=603396 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester ========== to ========== Dispatch transfer size update notification on mojo-loading With this CL, MojoAsyncResourceHandler dispatches OnTransferSizeUpdated messages when report_raw_headers is set in the request. This is for devtools which needs transfer size update events. BUG=603396 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester Review-Url: https://codereview.chromium.org/2566943002 ==========
Message was sent while issue was closed.
Committed patchset #9 (id:200001)
Message was sent while issue was closed.
Description was changed from ========== Dispatch transfer size update notification on mojo-loading With this CL, MojoAsyncResourceHandler dispatches OnTransferSizeUpdated messages when report_raw_headers is set in the request. This is for devtools which needs transfer size update events. BUG=603396 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester Review-Url: https://codereview.chromium.org/2566943002 ========== to ========== Dispatch transfer size update notification on mojo-loading With this CL, MojoAsyncResourceHandler dispatches OnTransferSizeUpdated messages when report_raw_headers is set in the request. This is for devtools which needs transfer size update events. BUG=603396 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester Committed: https://crrev.com/a275b3ccec68e3e75a81bd6b51fd937fabf97416 Cr-Commit-Position: refs/heads/master@{#439697} ==========
Message was sent while issue was closed.
Patchset 9 (id:??) landed as https://crrev.com/a275b3ccec68e3e75a81bd6b51fd937fabf97416 Cr-Commit-Position: refs/heads/master@{#439697} |
