[tbb-commits] [Git][tpo/applications/tor-browser][base-browser-102.9.0esr-12.0-1] 2 commits: Bug 1802385 - Use NS_GetFinalChannelURI in FetchDriver r=rpl, valentin

Richard Pospesel (@richard) git at gitlab.torproject.org
Wed Mar 15 11:59:37 UTC 2023



Richard Pospesel pushed to branch base-browser-102.9.0esr-12.0-1 at The Tor Project / Applications / Tor Browser


Commits:
6b886676 by Rob Wu at 2023-03-15T11:59:23+00:00
Bug 1802385 - Use NS_GetFinalChannelURI in FetchDriver r=rpl,valentin

Depends on D164656

Differential Revision: https://phabricator.services.mozilla.com/D166108

- - - - -
42680350 by Kash Shampur at 2023-03-15T11:59:23+00:00
Bug 1803109 - Discard blocks of data that are too big for two chunks. r=canaltinova

Currently, `ReserveAndPutRaw` allocates a second span even if the data would be too big for the chunk.
Here a second conditional is added to check if the block of data is too big in this scenario and silently discard the data if so.

Differential Revision: https://phabricator.services.mozilla.com/D167167
- - - - -


2 changed files:

- dom/fetch/FetchDriver.cpp
- mozglue/baseprofiler/public/ProfileChunkedBuffer.h


Changes:

=====================================
dom/fetch/FetchDriver.cpp
=====================================
@@ -1178,14 +1178,6 @@ FetchDriver::OnStartRequest(nsIRequest* aRequest) {
 
   response->InitChannelInfo(channel);
 
-  nsCOMPtr<nsIURI> channelURI;
-  rv = channel->GetURI(getter_AddRefs(channelURI));
-  if (NS_WARN_IF(NS_FAILED(rv))) {
-    FailWithNetworkError(rv);
-    // Cancel request.
-    return rv;
-  }
-
   nsCOMPtr<nsILoadInfo> loadInfo = channel->LoadInfo();
   // Propagate any tainting from the channel back to our response here.  This
   // step is not reflected in the spec because the spec is written such that
@@ -1501,7 +1493,7 @@ FetchDriver::AsyncOnChannelRedirect(nsIChannel* aOldChannel,
   // Response.redirected to true if an internal redirect occurs.  These
   // should be transparent to script.
   nsCOMPtr<nsIURI> uri;
-  MOZ_ALWAYS_SUCCEEDS(aNewChannel->GetURI(getter_AddRefs(uri)));
+  MOZ_ALWAYS_SUCCEEDS(NS_GetFinalChannelURI(aNewChannel, getter_AddRefs(uri)));
 
   nsCOMPtr<nsIURI> uriClone;
   nsresult rv = NS_GetURIWithoutRef(uri, getter_AddRefs(uriClone));


=====================================
mozglue/baseprofiler/public/ProfileChunkedBuffer.h
=====================================
@@ -1088,6 +1088,12 @@ class ProfileChunkedBuffer {
           MOZ_ASSERT(maybeEntryWriter->RemainingBytes() == blockBytes);
           mRangeEnd += blockBytes;
           mPushedBlockCount += aBlockCount;
+        } else if (blockBytes >= current->BufferBytes()) {
+          // Currently only two buffer chunks are held at a time and it is not
+          // possible to write an object that takes up more space than this. In
+          // this scenario, silently discard this block of data if it is unable
+          // to fit into the two reserved profiler chunks.
+          mFailedPutBytes += blockBytes;
         } else {
           // Block doesn't fit fully in current chunk, it needs to overflow into
           // the next one.



View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/compare/77304e7fcd0946e62332afbbf7c8fb6340dd2e42...426803509060933328b040c3304e684d041905fe

-- 
View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/compare/77304e7fcd0946e62332afbbf7c8fb6340dd2e42...426803509060933328b040c3304e684d041905fe
You're receiving this email because of your account on gitlab.torproject.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tbb-commits/attachments/20230315/1ba240b3/attachment-0001.htm>


More information about the tbb-commits mailing list