Richard Pospesel pushed to branch tor-browser-102.9.0esr-12.5-1 at The Tor Project / Applications / Tor Browser
Commits:
03f8127e by Rob Wu at 2023-03-15T12:03:27+00:00
Bug 1802385 - Use NS_GetFinalChannelURI in FetchDriver r=rpl,valentin
Depends on D164656
Differential Revision: https://phabricator.services.mozilla.com/D166108
- - - - -
7ed39eac by Kash Shampur at 2023-03-15T12:03:27+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/9f4e31…
--
View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/compare/9f4e31…
You're receiving this email because of your account on gitlab.torproject.org.
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/77304e…
--
View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/compare/77304e…
You're receiving this email because of your account on gitlab.torproject.org.
Richard Pospesel pushed to branch tor-browser-102.9.0esr-12.0-1 at The Tor Project / Applications / Tor Browser
Commits:
3f1f2044 by Rob Wu at 2023-03-14T17:33:20+00:00
Bug 1802385 - Use NS_GetFinalChannelURI in FetchDriver r=rpl,valentin
Depends on D164656
Differential Revision: https://phabricator.services.mozilla.com/D166108
- - - - -
0553bfb9 by Kash Shampur at 2023-03-14T17:34:35+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/1d8c7c…
--
View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/compare/1d8c7c…
You're receiving this email because of your account on gitlab.torproject.org.
Richard Pospesel pushed to branch base-browser-102.9.0esr-12.5-1 at The Tor Project / Applications / Tor Browser
Commits:
45a8e3b9 by Pier Angelo Vendrame at 2023-03-14T17:34:26+01:00
fixup! Bug 41459: WebRTC fails to build under mingw (Part 3)
Fix build error
- - - - -
1 changed file:
- third_party/sipcc/cpr_win_types.h
Changes:
=====================================
third_party/sipcc/cpr_win_types.h
=====================================
@@ -48,6 +48,7 @@ typedef int32_t ssize_t;
#else
typedef int64_t ssize_t;
#endif
+#endif
/*
* Define pid_t for MSVC builds
View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/45a8e3b…
--
View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/45a8e3b…
You're receiving this email because of your account on gitlab.torproject.org.
Richard Pospesel pushed to branch base-browser-102.9.0esr-12.5-1 at The Tor Project / Applications / Tor Browser
Commits:
0a233469 by Richard Pospesel at 2023-03-13T19:01:26+00:00
fixup! Bug 41459: WebRTC fails to build under mingw (Part 2)
- - - - -
e247c93c by Richard Pospesel at 2023-03-13T19:01:31+00:00
fixup! Bug 41459: WebRTC fails to build under mingw (Part 3)
- - - - -
3 changed files:
- third_party/libwebrtc/modules/desktop_capture/desktop_capture_types.h
- third_party/libwebrtc/modules/video_capture/video_capture_defines.h
- third_party/sipcc/cpr_win_types.h
Changes:
=====================================
third_party/libwebrtc/modules/desktop_capture/desktop_capture_types.h
=====================================
@@ -11,22 +11,15 @@
#ifndef MODULES_DESKTOP_CAPTURE_DESKTOP_CAPTURE_TYPES_H_
#define MODULES_DESKTOP_CAPTURE_DESKTOP_CAPTURE_TYPES_H_
-#ifndef XP_WIN
-#include <sys/types.h> // pid_t
-#endif
-#include <stdint.h>
-
-// Use int on all clang-cl builds and x86 mingw builds.
-// Use long long on Windows x64 building under MinGW
-// Must be consistent with the same typedefs in video_capture_defines.h
-#if defined(XP_WIN)
-#if defined(_MSC_VER) || !defined(_WIN64)
-typedef int pid_t;
+// pid_t
+#if !defined(XP_WIN) || defined(__MINGW32__)
+#include <sys/types.h>
#else
-typedef long long pid_t;
-#endif
+typedef int pid_t;
#endif
+#include <stdint.h>
+
namespace webrtc {
// Type used to identify windows on the desktop. Values are platform-specific:
=====================================
third_party/libwebrtc/modules/video_capture/video_capture_defines.h
=====================================
@@ -14,17 +14,6 @@
#include "api/video/video_frame.h"
#include "common_video/libyuv/include/webrtc_libyuv.h"
-// Use int on all clang-cl builds and x86 mingw builds.
-// Use long long on Windows x64 building under MinGW
-// Must be consistent with the same typedefs in desktop_capture_types.h
-#if defined(XP_WIN)
-#if defined(_MSC_VER) || !defined(_WIN64)
-typedef int pid_t;
-#else
-typedef long long pid_t;
-#endif
-#endif
-
namespace webrtc {
enum {
=====================================
third_party/sipcc/cpr_win_types.h
=====================================
@@ -50,14 +50,10 @@ typedef int64_t ssize_t;
#endif
/*
- * Define pid_t.
+ * Define pid_t for MSVC builds
*/
-#if defined(_WIN32)
-#if defined(_MSC_VER) || !defined(_WIN64)
+#if defined(_WIN32) && defined (_MSC_VER)
typedef int pid_t;
-#else
-typedef long long pid_t;
-#endif
#endif
/*
View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/compare/1d8ac6…
--
View it on GitLab: https://gitlab.torproject.org/tpo/applications/tor-browser/-/compare/1d8ac6…
You're receiving this email because of your account on gitlab.torproject.org.