Shared security patch analysis results
AI Used: DEEPSEEK deepseek-chat--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.put.basic.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.put.basic.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 100, 50)@@ -22,7 +22,7 @@ ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50) ctx.putImageData(imgdata, 0, 0);-_assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2);+_assertPixelApprox(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2); t.done(); });
Based on the provided diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and don't involve any security-related modifications.
Here's the analysis following your requested format:
Vulnerability Existed: no
No security vulnerability found [File] [Lines 13-14, 22]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2);
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixelApprox(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2);
The changes are purely cosmetic/refactoring in nature and don't address any security issues. The functionality remains exactly the same, just with a different variable name.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/selectors/old-tests/css3-modsel-44d.xml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/selectors/old-tests/css3-modsel-44d.xml@@ -8,7 +8,6 @@ ]]></style> <link rel="author" title="Ian Hickson" href="mailto:[email protected]"/> <link rel="help" href="https://www.w3.org/TR/css3-selectors/#selectors"/> <!-- bogus link to make sure it gets found -->- <meta name="flags" content="" /> </head> <body> <div> This should be unstyled. </div>
Based on the provided diff, here's the analysis following the required format: Vulnerability Existed: no No specific vulnerability found [File] [Lines 8] [Old Code] <meta name="flags" content="" /> [Fixed Code] (removed line) Additional Details: - The change simply removes an empty meta tag with a "flags" attribute, which doesn't appear to have any security implications - This appears to be a test file cleanup rather than a security fix - No known vulnerability patterns (XSS, injection, etc.) are present in this change - The modification doesn't affect any security-related functionality The change seems to be removing an unused or unnecessary meta tag from a test file, which doesn't indicate any security vulnerability being fixed.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/resources/chromium/README.md+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/resources/chromium/README.md@@ -1,7 +1,7 @@ This directory contains Chromium-specific test resources, including mocks for test-only APIs implemented with-[MojoJS](https://chromium.googlesource.com/chromium/src/+/master/mojo/public/js/README.md).+[MojoJS](https://chromium.googlesource.com/chromium/src/+/main/mojo/public/js/README.md). Please do **not** copy `*.mojom.m.js` into this directory. Follow this doc if you want to add new MojoJS-backed mocks:-https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md#mojojs+https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md#mojojs
Based on the provided diff, this appears to be a documentation update rather than a security fix. Here's the analysis following your requested format: Vulnerability Existed: no [Documentation URL Update] [testing/web-platform/tests/resources/chromium/README.md] [Lines 1,5] [Old Code] [MojoJS](https://chromium.googlesource.com/chromium/src/+/master/mojo/public/js/README.md) [Fixed Code] [MojoJS](https://chromium.googlesource.com/chromium/src/+/main/mojo/public/js/README.md) Vulnerability Existed: no [Documentation URL Update] [testing/web-platform/tests/resources/chromium/README.md] [Lines 5] [Old Code] https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md#mojojs [Fixed Code] https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md#mojojs The changes simply update documentation URLs from "master" branch references to "main" branch references, which is part of the industry-wide shift in terminology. No security vulnerabilities are being addressed in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/js/src/vm/TupleType.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/vm/TupleType.h@@ -25,8 +25,12 @@ const Value* elements); static TupleType* createUninitialized(JSContext* cx, uint32_t initialLength);++ static TupleType* createUnchecked(JSContext* cx, js::HandleArrayObject aObj);+ bool initializeNextElement(JSContext* cx, HandleValue elt); void finishInitialization(JSContext* cx);+ static js::Shape* getInitialShape(JSContext* cx); bool getOwnProperty(HandleId id, MutableHandleValue vp) const; inline uint32_t length() const { return getElementsHeader()->length; }@@ -50,6 +54,8 @@ // This can be used to compare atomized tuples. static bool sameValueZero(TupleType* lhs, TupleType* rhs);+ static TupleType& thisTupleValue(const Value& val);+ private: template <bool Comparator(JSContext*, HandleValue, HandleValue, bool*)> static bool sameValueWith(JSContext* cx, TupleType* lhs, TupleType* rhs,@@ -60,7 +66,18 @@ namespace js {-extern JSString* TupleToSource(JSContext* cx, TupleType* tup);-}+extern JSString* TupleToSource(JSContext* cx, Handle<TupleType*> tup);++bool IsTuple(const Value& v);++extern bool tuple_toReversed(JSContext* cx, unsigned argc, Value* vp);+extern bool tuple_with(JSContext* cx, unsigned argc, Value* vp);+extern bool tuple_slice(JSContext* cx, unsigned argc, Value* vp);+extern bool tuple_is_tuple(JSContext* cx, unsigned argc, Value* vp);+extern bool tuple_value_of(JSContext* cx, unsigned argc, Value* vp);+extern bool tuple_of(JSContext* cx, unsigned argc, Value* vp);+extern bool tuple_construct(JSContext* cx, unsigned argc, Value* vp);++} // namespace js #endif
After analyzing the provided code diff, I don't see any obvious security vulnerabilities being fixed. The changes appear to be primarily adding new functionality and improving the API rather than addressing security issues. Here's the analysis following your requested format: 1. Vulnerability Existed: no No security vulnerability found in diff The changes are adding new methods and functionality to TupleType.h Added methods include createUnchecked, getInitialShape, thisTupleValue, and several tuple operation functions 2. Vulnerability Existed: no No security vulnerability found in diff The change from TupleType* to Handle<TupleType*> in TupleToSource is a safety improvement but not fixing a known vulnerability Old code: extern JSString* TupleToSource(JSContext* cx, TupleType* tup); Fixed code: extern JSString* TupleToSource(JSContext* cx, Handle<TupleType*> tup); The changes appear to be: 1. Adding new API methods for tuple operations 2. Improving type safety by using Handle<T> 3. Adding new utility functions for tuple manipulation 4. No obvious security fixes or vulnerability patches are present in this diff
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/security/sandbox/common/test/SandboxTestingChild.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/security/sandbox/common/test/SandboxTestingChild.h@@ -8,6 +8,7 @@ #define mozilla_SandboxTestingChild_h #include "mozilla/PSandboxTestingChild.h"+#include "mozilla/Maybe.h" #include "mozilla/Monitor.h" #include "mozilla/UniquePtr.h"@@ -45,9 +46,12 @@ // absence of test report as a failure. inline void ReportNoTests();-#ifdef XP_UNIX- // For test cases that return an error number or 0, like newer POSIX APIs.- void PosixTest(const nsCString& aName, bool aExpectSuccess, int aStatus);+ // For test cases that return an error number or 0, like newer POSIX+ // APIs. If `aExpectSuccess` is true, the test passes if the status is+ // 0; otherwise, the test requires a specific error if `aExpectedError`+ // is `Some(n)` or any nonzero status if it's `Nothing()`.+ void PosixTest(const nsCString& aName, bool aExpectSuccess, int aStatus,+ Maybe<int> aExpectedError = Nothing()); // For test cases that return a negative number and set `errno` to // indicate error, like classical Unix APIs; takes a callable, which@@ -56,11 +60,10 @@ void ErrnoTest(const nsCString& aName, bool aExpectSuccess, F&& aFunction); // Similar to ErrnoTest, except that we want to compare a specific `errno`- // being returned (or not).+ // being returned. template <typename F>- void ErrnoValueTest(const nsCString& aName, bool aExpectEquals,- int aExpectedErrno, F&& aFunction);-#endif+ void ErrnoValueTest(const nsCString& aName, int aExpectedErrno,+ F&& aFunction); private: explicit SandboxTestingChild(SandboxTestingThread* aThread,
I'll analyze the code diff and provide the security findings according to the specified format.
1. Vulnerability Existed: not sure
[Potential Error Handling Improvement] [security/sandbox/common/test/SandboxTestingChild.h] [Lines 45-60]
[Old Code]
#ifdef XP_UNIX
// For test cases that return an error number or 0, like newer POSIX APIs.
void PosixTest(const nsCString& aName, bool aExpectSuccess, int aStatus);
// For test cases that return a negative number and set `errno` to
// indicate error, like classical Unix APIs; takes a callable, which
// should return the syscall's return value.
template <typename F>
void ErrnoTest(const nsCString& aName, bool aExpectSuccess, F&& aFunction);
// Similar to ErrnoTest, except that we want to compare a specific `errno`
// being returned (or not).
template <typename F>
void ErrnoValueTest(const nsCString& aName, bool aExpectEquals,
int aExpectedErrno, F&& aFunction);
#endif
[Fixed Code]
// For test cases that return an error number or 0, like newer POSIX
// APIs. If `aExpectSuccess` is true, the test passes if the status is
// 0; otherwise, the test requires a specific error if `aExpectedError`
// is `Some(n)` or any nonzero status if it's `Nothing()`.
void PosixTest(const nsCString& aName, bool aExpectSuccess, int aStatus,
Maybe<int> aExpectedError = Nothing());
// For test cases that return a negative number and set `errno` to
// indicate error, like classical Unix APIs; takes a callable, which
// should return the syscall's return value.
template <typename F>
void ErrnoTest(const nsCString& aName, bool aExpectSuccess, F&& aFunction);
// Similar to ErrnoTest, except that we want to compare a specific `errno`
// being returned.
template <typename F>
void ErrnoValueTest(const nsCString& aName, int aExpectedErrno,
F&& aFunction);
The changes appear to improve error handling in the sandbox testing framework by:
1. Adding more precise error expectation handling in PosixTest
2. Simplifying ErrnoValueTest by removing the boolean comparison flag
3. Making the code platform-independent by removing the XP_UNIX conditional
While these changes improve robustness, I can't identify a specific security vulnerability that was fixed. The changes seem more focused on improving test accuracy and maintainability.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/initial.reset.path.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/initial.reset.path.worker.js@@ -13,15 +13,15 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d');-offscreenCanvas.width = 100;+canvas.width = 100; ctx.rect(0, 0, 100, 50);-offscreenCanvas.width = 100;+canvas.width = 100; ctx.fillStyle = '#f00'; ctx.fill();-_assertPixel(offscreenCanvas, 20,20, 0,0,0,0, "20,20", "0,0,0,0");+_assertPixel(canvas, 20,20, 0,0,0,0, "20,20", "0,0,0,0"); t.done(); });
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming and don't affect security. Here's the analysis following your requested format:
Vulnerability Existed: no
[No security vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/initial.reset.path.worker.js] [Lines 13-23]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
offscreenCanvas.width = 100;
ctx.rect(0, 0, 100, 50);
offscreenCanvas.width = 100;
ctx.fillStyle = '#f00';
ctx.fill();
_assertPixel(offscreenCanvas, 20,20, 0,0,0,0, "20,20", "0,0,0,0");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
canvas.width = 100;
ctx.rect(0, 0, 100, 50);
canvas.width = 100;
ctx.fillStyle = '#f00';
ctx.fill();
_assertPixel(canvas, 20,20, 0,0,0,0, "20,20", "0,0,0,0");
The changes simply rename the variable from `offscreenCanvas` to `canvas` throughout the code, which doesn't appear to address any security issues. The functionality remains identical.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.clip.copy.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.clip.copy.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0';@@ -28,8 +28,8 @@ ctx.clip(); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 50, 50);-_assertPixel(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");+_assertPixel(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");+_assertPixel(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming and don't involve any security-related modifications. Here's the analysis:
1. Vulnerability Existed: no
Variable Renaming [testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.clip.copy.html] [Lines 17-18, 28-29]
Old Code:
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");
_assertPixel(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");
Fixed Code:
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");
_assertPixel(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");
The changes simply rename the variable `offscreenCanvas` to `canvas` throughout the file, which doesn't appear to address any security issues. The functionality remains exactly the same, only the variable name has changed.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.transform.1.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.transform.1.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -26,7 +26,7 @@ ctx.shadowColor = '#0f0'; ctx.translate(100, 100); ctx.fillRect(-100, -150, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring, renaming a variable from `offscreenCanvas` to `canvas` for consistency or clarity. Here's the analysis:
1. Vulnerability Existed: no
No security vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.transform.1.html [Lines] 17-26
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes don't affect any security-related functionality, just variable naming. No CVE or specific vulnerability is being addressed here.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.isPointInPath.transform.1.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.isPointInPath.transform.1.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.translate(50, 0); ctx.rect(0, 0, 20, 20);
Analysis of the code diff:
1. Vulnerability Existed: no
No specific vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.isPointInPath.transform.1.html [Lines] 17-18
[Old Code]
`var offscreenCanvas = new OffscreenCanvas(100, 50);`
`var ctx = offscreenCanvas.getContext('2d');`
[Fixed Code]
`var canvas = new OffscreenCanvas(100, 50);`
`var ctx = canvas.getContext('2d');`
Additional Details:
The changes appear to be purely variable name refactoring (from `offscreenCanvas` to `canvas`), with no security implications. No known vulnerabilities are addressed by this change. The functionality remains identical, only the variable naming convention was improved.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/size.attributes.parse.octal.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/size.attributes.parse.octal.html@@ -17,13 +17,13 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d');-offscreenCanvas.width = '0100';-offscreenCanvas.height = '0100';-_assertSame(offscreenCanvas.width, 100, "offscreenCanvas.width", "100");-_assertSame(offscreenCanvas.height, 100, "offscreenCanvas.height", "100");+canvas.width = '0100';+canvas.height = '0100';+_assertSame(canvas.width, 100, "canvas.width", "100");+_assertSame(canvas.height, 100, "canvas.height", "100"); t.done(); });
Here's the analysis following the required format:
Vulnerability Existed: not sure
[Potential Octal Parsing Issue] [testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/size.attributes.parse.octal.html] [Lines 17-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
offscreenCanvas.width = '0100';
offscreenCanvas.height = '0100';
_assertSame(offscreenCanvas.width, 100, "offscreenCanvas.width", "100");
_assertSame(offscreenCanvas.height, 100, "offscreenCanvas.height", "100");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
canvas.width = '0100';
canvas.height = '0100';
_assertSame(canvas.width, 100, "canvas.width", "100");
_assertSame(canvas.height, 100, "canvas.height", "100");
Additional Details:
The main change appears to be variable renaming from `offscreenCanvas` to `canvas`. The test is checking how octal string values ('0100') are parsed when assigned to canvas dimensions. While this could potentially relate to security issues with octal parsing (which has caused vulnerabilities in other contexts), in this case it appears to be just a test case verifying correct behavior rather than fixing a vulnerability. The variable name change doesn't appear to be security-related.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/base/nsGlobalWindowOuter.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/base/nsGlobalWindowOuter.cpp@@ -4286,12 +4286,10 @@ public: FullscreenTransitionTask(const FullscreenTransitionDuration& aDuration, nsGlobalWindowOuter* aWindow, bool aFullscreen,- nsIWidget* aWidget, nsIScreen* aScreen,- nsISupports* aTransitionData)+ nsIWidget* aWidget, nsISupports* aTransitionData) : mozilla::Runnable("FullscreenTransitionTask"), mWindow(aWindow), mWidget(aWidget),- mScreen(aScreen), mTransitionData(aTransitionData), mDuration(aDuration), mStage(eBeforeToggle),@@ -4357,7 +4355,6 @@ RefPtr<nsGlobalWindowOuter> mWindow; nsCOMPtr<nsIWidget> mWidget;- nsCOMPtr<nsIScreen> mScreen; nsCOMPtr<nsITimer> mTimer; nsCOMPtr<nsISupports> mTransitionData;@@ -4399,7 +4396,7 @@ } // Toggle the fullscreen state on the widget if (!mWindow->SetWidgetFullscreen(FullscreenReason::ForFullscreenAPI,- mFullscreen, mWidget, mScreen)) {+ mFullscreen, mWidget)) { // Fail to setup the widget, call FinishFullscreenChange to // complete fullscreen change directly. mWindow->FinishFullscreenChange(mFullscreen);@@ -4496,15 +4493,13 @@ getter_AddRefs(transitionData)); } }- // We pass nullptr as the screen to SetWidgetFullscreen- // and FullscreenTransitionTask, as we do not wish to override- // the default screen selection behavior. The screen containing- // most of the widget will be selected.+ if (!performTransition) {- return aWindow->SetWidgetFullscreen(aReason, aFullscreen, widget, nullptr);- }+ return aWindow->SetWidgetFullscreen(aReason, aFullscreen, widget);+ }+ nsCOMPtr<nsIRunnable> task = new FullscreenTransitionTask(- duration, aWindow, aFullscreen, widget, nullptr, transitionData);+ duration, aWindow, aFullscreen, widget, transitionData); task->Run(); return true; }@@ -4621,8 +4616,7 @@ bool nsGlobalWindowOuter::SetWidgetFullscreen(FullscreenReason aReason, bool aIsFullscreen,- nsIWidget* aWidget,- nsIScreen* aScreen) {+ nsIWidget* aWidget) { MOZ_ASSERT(this == GetInProcessTopInternal(), "Only topmost window should call this"); MOZ_ASSERT(!GetFrameElementInternal(), "Content window should not call this");@@ -4640,13 +4634,12 @@ } } }- nsresult rv =- aReason == FullscreenReason::ForFullscreenMode- ?- // If we enter fullscreen for fullscreen mode, we want- // the native system behavior.- aWidget->MakeFullScreenWithNativeTransition(aIsFullscreen, aScreen)- : aWidget->MakeFullScreen(aIsFullscreen, aScreen);+ nsresult rv = aReason == FullscreenReason::ForFullscreenMode+ ?+ // If we enter fullscreen for fullscreen mode, we want+ // the native system behavior.+ aWidget->MakeFullScreenWithNativeTransition(aIsFullscreen)+ : aWidget->MakeFullScreen(aIsFullscreen); return NS_SUCCEEDED(rv); }@@ -5201,12 +5194,6 @@ return; }- bool print_tab_modal_enabled = true;- if (!print_tab_modal_enabled && ShouldPromptToBlockDialogs() &&- !ConfirmDialogIfNeeded()) {- return aError.ThrowNotAllowedError("Prompt was canceled by the user");- }- // If we're loading, queue the print for later. This is a special-case that // only applies to the window.print() call, for compat with other engines and // pre-existing behavior.@@ -5233,9 +5220,8 @@ } });- const bool isPreview =- print_tab_modal_enabled && !StaticPrefs::print_always_print_silent();- Print(nullptr, nullptr, nullptr, IsPreview(isPreview),+ const bool forPreview = !StaticPrefs::print_always_print_silent();+ Print(nullptr, nullptr, nullptr, IsPreview(forPreview), IsForWindowDotPrint::Yes, nullptr, aError); #endif }@@ -5293,9 +5279,7 @@ nsCOMPtr<nsIContentViewer> cv; RefPtr<BrowsingContext> bc; bool hasPrintCallbacks = false;- bool print_tab_modal_enabled = true;- if (docToPrint->IsStaticDocument() &&- (aIsPreview == IsPreview::Yes || print_tab_modal_enabled)) {+ if (docToPrint->IsStaticDocument()) { if (aForWindowDotPrint == IsForWindowDotPrint::Yes) { aError.ThrowNotSupportedError( "Calling print() from a print preview is unsupported, did you intend "
Here's the analysis of the provided code diff following the specified format:
1. First vulnerability/change:
Vulnerability Existed: not sure
[Removed nsIScreen parameter] [dom/base/nsGlobalWindowOuter.cpp] [Lines 4286-4355, 4399, 4496, 4621]
[Old Code]
FullscreenTransitionTask constructor and related functions included nsIScreen* parameter
[Fixed Code]
Removed nsIScreen* parameter from FullscreenTransitionTask and related functions
2. Second vulnerability/change:
Vulnerability Existed: not sure
[Removed print_tab_modal_enabled flag] [dom/base/nsGlobalWindowOuter.cpp] [Lines 5201-5233]
[Old Code]
Had print_tab_modal_enabled flag check and conditional behavior
[Fixed Code]
Removed print_tab_modal_enabled flag and related conditional checks
3. Third vulnerability/change:
Vulnerability Existed: not sure
[Simplified print preview logic] [dom/base/nsGlobalWindowOuter.cpp] [Lines 5293-5280]
[Old Code]
Had complex print preview logic with print_tab_modal_enabled flag
[Fixed Code]
Simplified print preview logic without the flag
Note: While these changes appear to be security-related (removing potentially unsafe parameters and simplifying complex logic), I cannot definitively identify specific vulnerabilities without more context about the threat model or vulnerability reports. The changes seem to focus on:
1. Removing unnecessary screen parameter handling in fullscreen transitions
2. Simplifying print dialog/preview logic by removing conditional flags
3. Cleaning up the codebase by removing unused parameters and variables
The changes appear to be defensive programming improvements rather than fixes for specific known vulnerabilities.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/tools/yaml/element/path-objects.yaml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/tools/yaml/element/path-objects.yaml@@ -2319,8 +2319,21 @@ @assert pixel 98,48 == 255,0,0,255; @assert pixel 1,48 == 255,0,0,255;+- name: 2d.path.roundrect.1.radius.double.single.argument+ desc: Verify that when one radius is given to roundRect() as a non-array argument, specified as a double, it applies to all corners.+ code: |+ ctx.fillStyle = '#f00';+ ctx.fillRect(0, 0, 100, 50);+ ctx.roundRect(0, 0, 100, 50, 20);+ ctx.fillStyle = '#0f0';+ ctx.fill();+ @assert pixel 1,1 == 255,0,0,255;+ @assert pixel 98,1 == 255,0,0,255;+ @assert pixel 98,48 == 255,0,0,255;+ @assert pixel 1,48 == 255,0,0,255;+ - name: 2d.path.roundrect.1.radius.dompoint- desc: Verify that when two radii are given to roundRect(), the first radius, specified as a DOMPoint, applies to the top-left and bottom-left corners.+ desc: Verify that when one radius is given to roundRect(), specified as a DOMPoint, it applies to all corners. code: | ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -2352,12 +2365,78 @@ @assert pixel 1,39 == 255,0,0,255; @assert pixel 1,28 == 0,255,0,255;+- name: 2d.path.roundrect.1.radius.dompoint.single argument+ desc: Verify that when one radius is given to roundRect() as a non-array argument, specified as a DOMPoint, it applies to all corners.+ code: |+ ctx.fillStyle = '#f00';+ ctx.fillRect(0, 0, 100, 50);+ ctx.roundRect(0, 0, 100, 50, new DOMPoint(40, 20));+ ctx.fillStyle = '#0f0';+ ctx.fill();++ // top-left corner+ @assert pixel 20,1 == 255,0,0,255;+ @assert pixel 41,1 == 0,255,0,255;+ @assert pixel 1,10 == 255,0,0,255;+ @assert pixel 1,21 == 0,255,0,255;++ // top-right corner+ @assert pixel 79,1 == 255,0,0,255;+ @assert pixel 58,1 == 0,255,0,255;+ @assert pixel 98,10 == 255,0,0,255;+ @assert pixel 98,21 == 0,255,0,255;++ // bottom-right corner+ @assert pixel 79,48 == 255,0,0,255;+ @assert pixel 58,48 == 0,255,0,255;+ @assert pixel 98,39 == 255,0,0,255;+ @assert pixel 98,28 == 0,255,0,255;++ // bottom-left corner+ @assert pixel 20,48 == 255,0,0,255;+ @assert pixel 41,48 == 0,255,0,255;+ @assert pixel 1,39 == 255,0,0,255;+ @assert pixel 1,28 == 0,255,0,255;+ - name: 2d.path.roundrect.1.radius.dompointinit- desc: Verify that when two radii are given to roundRect(), the first radius, specified as a DOMPointInit, applies to the top-left and bottom-left corners.+ desc: Verify that when one radius is given to roundRect(), specified as a DOMPointInit, applies to all corners. code: | ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50); ctx.roundRect(0, 0, 100, 50, [{x: 40, y: 20}]);+ ctx.fillStyle = '#0f0';+ ctx.fill();++ // top-left corner+ @assert pixel 20,1 == 255,0,0,255;+ @assert pixel 41,1 == 0,255,0,255;+ @assert pixel 1,10 == 255,0,0,255;+ @assert pixel 1,21 == 0,255,0,255;++ // top-right corner+ @assert pixel 79,1 == 255,0,0,255;+ @assert pixel 58,1 == 0,255,0,255;+ @assert pixel 98,10 == 255,0,0,255;+ @assert pixel 98,21 == 0,255,0,255;++ // bottom-right corner+ @assert pixel 79,48 == 255,0,0,255;+ @assert pixel 58,48 == 0,255,0,255;+ @assert pixel 98,39 == 255,0,0,255;+ @assert pixel 98,28 == 0,255,0,255;++ // bottom-left corner+ @assert pixel 20,48 == 255,0,0,255;+ @assert pixel 41,48 == 0,255,0,255;+ @assert pixel 1,39 == 255,0,0,255;+ @assert pixel 1,28 == 0,255,0,255;++- name: 2d.path.roundrect.1.radius.dompointinit.single.argument+ desc: Verify that when one radius is given to roundRect() as a non-array argument, specified as a DOMPointInit, applies to all corners.+ code: |+ ctx.fillStyle = '#f00';+ ctx.fillRect(0, 0, 100, 50);+ ctx.roundRect(0, 0, 100, 50, {x: 40, y: 20}); ctx.fillStyle = '#0f0'; ctx.fill();
After analyzing the provided code diff, I don't identify any security vulnerabilities. The changes appear to be test case additions and modifications for canvas path functionality, specifically for the `roundRect()` method with different parameter types. Here's the analysis: 1. Vulnerability Existed: no No security vulnerability found File: testing/web-platform/tests/html/canvas/tools/yaml/element/path-objects.yaml The changes consist of: - Adding new test cases for `roundRect()` with single argument radius - Modifying descriptions of existing test cases - Adding assertions for different corner cases The diff shows test improvements rather than security fixes. The modifications are focused on verifying correct behavior of the canvas API rather than addressing security issues. If you'd like me to analyze any specific aspect of these changes further, please provide additional context or concerns.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.strokeRect.clip.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.strokeRect.clip.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 100, 50);@@ -26,7 +26,7 @@ ctx.strokeRect(0, 0, 100, 50); ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 16, 16);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and don't involve any security-related modifications.
Here's the analysis following your requested format:
Vulnerability Existed: no
No security vulnerability found [File] [Lines 13-14, 26]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes are purely cosmetic/refactoring in nature and don't address any security issues. The functionality remains exactly the same, only the variable name has been changed for consistency or clarity.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/media/webrtc/jsep/JsepSessionImpl.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/media/webrtc/jsep/JsepSessionImpl.h@@ -180,11 +180,12 @@ nsresult ValidateOffer(const Sdp& offer); nsresult ValidateAnswer(const Sdp& offer, const Sdp& answer); nsresult UpdateTransceiversFromRemoteDescription(const Sdp& remote);- JsepTransceiver* GetTransceiverForLevel(size_t level);- JsepTransceiver* GetTransceiverForMid(const std::string& mid);+ JsepTransceiver* GetTransceiverForLevel(size_t level) const;+ JsepTransceiver* GetTransceiverForMid(const std::string& mid) const; JsepTransceiver* GetTransceiverForLocal(size_t level); JsepTransceiver* GetTransceiverForRemote(const SdpMediaSection& msection);- JsepTransceiver* GetTransceiverWithTransport(const std::string& transportId);+ JsepTransceiver* GetTransceiverWithTransport(+ const std::string& transportId) const; // The w3c and IETF specs have a lot of "magical" behavior that happens when // addTrack is used. This was a deliberate design choice. Sadface. JsepTransceiver* FindUnassociatedTransceiver(SdpMediaSection::MediaType type,
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Const-Correctness Issue] [dom/media/webrtc/jsep/JsepSessionImpl.h] [Lines 180-186]
[Old Code]
JsepTransceiver* GetTransceiverForLevel(size_t level);
JsepTransceiver* GetTransceiverForMid(const std::string& mid);
JsepTransceiver* GetTransceiverWithTransport(const std::string& transportId);
[Fixed Code]
JsepTransceiver* GetTransceiverForLevel(size_t level) const;
JsepTransceiver* GetTransceiverForMid(const std::string& mid) const;
JsepTransceiver* GetTransceiverWithTransport(const std::string& transportId) const;
Additional Details:
- The changes add 'const' qualifiers to several member functions, suggesting they don't modify object state
- While not a direct security vulnerability, this improves code safety by preventing accidental modifications
- The change could potentially prevent certain types of programming errors that might lead to security issues
- Without more context about how these functions are used, we can't be certain if this fixed an actual vulnerability
No other obvious security vulnerabilities are apparent in this diff. The changes appear to be primarily about improving code quality and const-correctness rather than fixing specific security issues.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/syn/src/parse_quote.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/syn/src/parse_quote.rs@@ -58,7 +58,6 @@ /// `P` with optional trailing punctuation /// - [`Vec<Stmt>`] — parses the same as `Block::parse_within` ///-/// [`Punctuated<T, P>`]: crate::punctuated::Punctuated /// [`Vec<Stmt>`]: Block::parse_within /// /// # Panics@@ -66,14 +65,43 @@ /// Panics if the tokens fail to parse as the expected syntax tree type. The /// caller is responsible for ensuring that the input tokens are syntactically /// valid.-//-// TODO: allow Punctuated to be inferred as intra doc link, currently blocked on-// https://github.com/rust-lang/rust/issues/62834 #[cfg_attr(doc_cfg, doc(cfg(all(feature = "parsing", feature = "printing"))))] #[macro_export] macro_rules! parse_quote { ($($tt:tt)*) => { $crate::parse_quote::parse($crate::__private::quote::quote!($($tt)*))+ };+}++/// This macro is [`parse_quote!`] + [`quote_spanned!`][quote::quote_spanned].+///+/// Please refer to each of their documentation.+///+/// # Example+///+/// ```+/// use quote::{quote, quote_spanned};+/// use syn::spanned::Spanned;+/// use syn::{parse_quote_spanned, ReturnType, Signature};+///+/// // Changes `fn()` to `fn() -> Pin<Box<dyn Future<Output = ()>>>`,+/// // and `fn() -> T` to `fn() -> Pin<Box<dyn Future<Output = T>>>`,+/// // without introducing any call_site() spans.+/// fn make_ret_pinned_future(sig: &mut Signature) {+/// let ret = match &sig.output {+/// ReturnType::Default => quote_spanned!(sig.paren_token.span=> ()),+/// ReturnType::Type(_, ret) => quote!(#ret),+/// };+/// sig.output = parse_quote_spanned! {ret.span()=>+/// -> ::std::pin::Pin<::std::boxed::Box<dyn ::std::future::Future<Output = #ret>>>+/// };+/// }+/// ```+#[cfg_attr(doc_cfg, doc(cfg(all(feature = "parsing", feature = "printing"))))]+#[macro_export]+macro_rules! parse_quote_spanned {+ ($span:expr=> $($tt:tt)*) => {+ $crate::parse_quote::parse($crate::__private::quote::quote_spanned!($span=> $($tt)*)) }; }
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be documentation improvements and the addition of a new macro (`parse_quote_spanned`) rather than security fixes. Here's the analysis following your requested format: 1. Vulnerability Existed: no No security vulnerability found in the diff. The changes are: - Documentation comment cleanup (removing a TODO note and improving docs) - Adding a new `parse_quote_spanned` macro that combines `parse_quote` and `quote_spanned` functionality The diff shows: 1. Removal of documentation comments about Punctuated inference (which was a TODO note) 2. Addition of a new macro `parse_quote_spanned` that provides spanned quoting functionality 3. General documentation improvements None of these changes appear to be security-related fixes - they're either documentation improvements or feature additions. The code doesn't show any patterns that would indicate security vulnerabilities being addressed (no changes to input validation, no fixes for injection vulnerabilities, no memory safety issues, etc.).
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/browser/components/newtab/css/activity-stream-linux.css+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/components/newtab/css/activity-stream-linux.css@@ -2740,89 +2740,214 @@ .ds-card-grid.empty { grid-template-columns: auto; }-.ds-column-9 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-10 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-11 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-12 .ds-card-grid.ds-card-grid-compact-variant {+.ds-column-9 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-10 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-11 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-12 .ds-card-grid.ds-card-grid-four-card-variant { grid-template-columns: repeat(1, 1fr); } @media (min-width: 610px) {- .ds-column-9 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-10 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-11 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-12 .ds-card-grid.ds-card-grid-compact-variant {+ .ds-column-9 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-10 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-11 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-12 .ds-card-grid.ds-card-grid-four-card-variant { grid-template-columns: repeat(2, 1fr); } } @media (min-width: 866px) {- .ds-column-9 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-10 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-11 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-12 .ds-card-grid.ds-card-grid-compact-variant {+ .ds-column-9 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-10 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-11 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-12 .ds-card-grid.ds-card-grid-four-card-variant { grid-template-columns: repeat(3, 1fr); } } @media (min-width: 1122px) {- .ds-column-9 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-10 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-11 .ds-card-grid.ds-card-grid-compact-variant, .ds-column-12 .ds-card-grid.ds-card-grid-compact-variant {+ .ds-column-9 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-10 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-11 .ds-card-grid.ds-card-grid-four-card-variant, .ds-column-12 .ds-card-grid.ds-card-grid-four-card-variant { grid-template-columns: repeat(4, 1fr); } }-.ds-card-grid.ds-card-grid-compact-variant .ds-card.placeholder {+.ds-card-grid.ds-card-grid-four-card-variant .ds-card.placeholder { min-height: 247px; }-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta {- padding: 12px 0 0;-}-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .story-footer {+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .story-footer { margin-top: 8px; }-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .source,-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .ds-last-card-desc,-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .story-sponsored-label,-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .status-message .story-context-label {+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .source,+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .ds-last-card-desc,+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .story-sponsored-label,+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .status-message .story-context-label { color: var(--newtab-text-secondary-color); -webkit-line-clamp: 2; }-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .source,-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .ds-last-card-desc,-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .story-sponsored-label {+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .source,+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .ds-last-card-desc,+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .story-sponsored-label { font-size: 13px; }-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .status-message .story-context-label {+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .status-message .story-context-label { font-size: 11.7px; }-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .story-badge-icon {+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .story-badge-icon { margin-inline-end: 2px; margin-bottom: 2px; height: 14px; width: 14px; background-size: 14px; }-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .title {+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .title { font-size: 14px;- -webkit-line-clamp: 3; line-height: 20px; }-.ds-card-grid.ds-card-grid-compact-variant .ds-card .meta .info-wrap {+.ds-card-grid.ds-card-grid-four-card-variant .ds-card .meta .info-wrap { flex-grow: 0; }--.outer-wrapper .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder),-.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder) {+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout {+ grid-template-columns: repeat(1, 1fr);+}+@media (min-width: 610px) {+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout {+ grid-template-columns: repeat(2, 1fr);+ }+}+@media (min-width: 866px) {+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout {+ grid-template-columns: repeat(3, 1fr);+ }+}+@media (max-height: 1065px) {+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .excerpt, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .excerpt, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .excerpt, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .excerpt {+ display: none;+ }+}+@media (max-width: 1122px) {+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card.placeholder, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card.placeholder, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card.placeholder, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card.placeholder {+ min-height: 247px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-footer, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-footer, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-footer, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-footer {+ margin-top: 8px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label {+ color: var(--newtab-text-secondary-color);+ -webkit-line-clamp: 2;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label {+ font-size: 13px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label {+ font-size: 11.7px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-badge-icon, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-badge-icon, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-badge-icon, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-badge-icon {+ margin-inline-end: 2px;+ margin-bottom: 2px;+ height: 14px;+ width: 14px;+ background-size: 14px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .title, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .title, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .title, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .title {+ font-size: 14px;+ line-height: 20px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .info-wrap, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .info-wrap, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .info-wrap, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .info-wrap {+ flex-grow: 0;+ }+}+@media (min-width: 1122px) and (max-height: 964px) {+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout {+ grid-template-columns: repeat(4, 1fr);+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card.placeholder, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card.placeholder, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card.placeholder, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card.placeholder {+ min-height: 247px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-footer, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-footer, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-footer, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-footer {+ margin-top: 8px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label {+ color: var(--newtab-text-secondary-color);+ -webkit-line-clamp: 2;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .source,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .ds-last-card-desc,+.ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-sponsored-label {+ font-size: 13px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .status-message .story-context-label {+ font-size: 11.7px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-badge-icon, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-badge-icon, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-badge-icon, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .story-badge-icon {+ margin-inline-end: 2px;+ margin-bottom: 2px;+ height: 14px;+ width: 14px;+ background-size: 14px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .title, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .title, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .title, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .title {+ font-size: 14px;+ line-height: 20px;+ }+ .ds-column-9 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .info-wrap, .ds-column-10 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .info-wrap, .ds-column-11 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .info-wrap, .ds-column-12 .ds-card-grid.ds-card-grid-hybrid-layout .ds-card .meta .info-wrap {+ flex-grow: 0;+ }+}++.outer-wrapper .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder),+.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) { box-shadow: none; background: none; }-.outer-wrapper .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder) .ds-card-link:focus,-.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder) .ds-card-link:focus {+.outer-wrapper .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .ds-card-link:focus,+.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .ds-card-link:focus { box-shadow: none; }-.outer-wrapper .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder) .ds-card-link:focus .img-wrapper .img img,-.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder) .ds-card-link:focus .img-wrapper .img img {+.outer-wrapper .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .ds-card-link:focus .img-wrapper .img img,+.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .ds-card-link:focus .img-wrapper .img img { border: 0; outline: 0; box-shadow: 0 0 0 3px var(--newtab-primary-action-background-dimmed), 0 0 0 1px var(--newtab-primary-action-background); }-.outer-wrapper .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder) .img-wrapper .img img,-.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder) .img-wrapper .img img {+.outer-wrapper .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .img-wrapper .img img,+.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .img-wrapper .img img { border-radius: 8px; box-shadow: 0 2px 6px rgba(0, 0, 0, 0.15); }-.outer-wrapper .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder) .img-wrapper .img img.last-card-message-image,-.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-compact-variant.ds-card-grid-border .ds-card:not(.placeholder) .img-wrapper .img img.last-card-message-image {+.outer-wrapper .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .img-wrapper .img img.last-card-message-image,+.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .img-wrapper .img img.last-card-message-image { background: transparent; box-shadow: none; object-fit: contain;+}+.outer-wrapper .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .meta,+.outer-wrapper.newtab-experience .ds-card-grid.ds-card-grid-hide-background.ds-card-grid-border .ds-card:not(.placeholder) .meta {+ padding: 12px 0 0; } .ds-layout .ds-card-grid-load-more-button {
Based on the provided CSS diff, I don't see any security-related changes. The changes appear to be purely stylistic and layout-related, with class name changes and responsive design adjustments. Here's the analysis:
Vulnerability Existed: no
No security vulnerability found [File] browser/components/newtab/css/activity-stream-linux.css
The changes involve renaming classes from "ds-card-grid-compact-variant" to "ds-card-grid-four-card-variant" and adding new layout variants ("ds-card-grid-hybrid-layout" and "ds-card-grid-hide-background"). These are purely CSS styling changes with no security implications.
The diff shows:
1. Class name changes for styling variants
2. Addition of new responsive layout rules
3. Adjustments to padding, margins, and visual properties
4. Media query additions for different screen sizes
None of these changes relate to security fixes or introduce security vulnerabilities. The modifications are focused on improving the visual presentation and responsive behavior of the activity stream cards in Firefox's new tab page.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.canvas.source-over.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.canvas.source-over.worker.js@@ -13,11 +13,11 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d');-var offscreenCanvas2 = new OffscreenCanvas(offscreenCanvas.width, offscreenCanvas.height);+var offscreenCanvas2 = new OffscreenCanvas(canvas.width, canvas.height); var ctx2 = offscreenCanvas2.getContext('2d'); var promise = new Promise(function(resolve, reject) { var xhr = new XMLHttpRequest();@@ -35,7 +35,7 @@ ctx.fillRect(0, 0, 100, 50); ctx.globalCompositeOperation = 'source-over'; ctx.drawImage(offscreenCanvas2, 0, 0);- _assertPixelApprox(offscreenCanvas, 50,25, 219,255,36,223, "50,25", "219,255,36,223", 5);+ _assertPixelApprox(canvas, 50,25, 219,255,36,223, "50,25", "219,255,36,223", 5); }, t_fail); }).then(t_pass, t_fail);
Based on the provided code diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.canvas.source-over.worker.js [Lines] 13-35
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
var offscreenCanvas2 = new OffscreenCanvas(offscreenCanvas.width, offscreenCanvas.height);
_assertPixelApprox(offscreenCanvas, 50,25, 219,255,36,223, "50,25", "219,255,36,223", 5);
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
var offscreenCanvas2 = new OffscreenCanvas(canvas.width, canvas.height);
_assertPixelApprox(canvas, 50,25, 219,255,36,223, "50,25", "219,255,36,223", 5);
Additional Details:
- The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and don't involve any security fixes
- The functionality remains identical, just with different variable names
- No security-related patterns (like input validation, security headers, etc.) were modified
- The test case continues to perform the same canvas operations and assertions
This appears to be a code style/readability change rather than a security fix.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.beginPath.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.beginPath.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 100, 50);@@ -26,7 +26,7 @@ ctx.beginPath(); ctx.fillStyle = '#f00'; ctx.fill();-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and don't involve any security-related modifications. Here's the analysis following your requested format:
Vulnerability Existed: no
No security vulnerability found [File] [Lines 17-18, 26]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes are purely cosmetic/refactoring in nature and don't address any security issues. The functionality remains exactly the same, only the variable name has been changed for consistency or clarity.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.pattern.alpha.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.pattern.alpha.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); var promise = new Promise(function(resolve, reject) { var xhr = new XMLHttpRequest();
Analysis of the provided code diff:
1. Vulnerability Existed: no
No specific vulnerability found [File] [Lines 17-18]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
Additional Details:
- The change appears to be a simple variable renaming from `offscreenCanvas` to `canvas`, which doesn't indicate any security vulnerability fix.
- The rest of the diff shows standard test code for canvas functionality, particularly testing shadow patterns with alpha transparency.
- No security-related changes or vulnerability fixes are evident in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.3.radii.1.dompointinit.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.3.radii.1.dompointinit.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -23,15 +23,15 @@ ctx.fill(); // top-left corner-_assertPixel(offscreenCanvas, 20,1, 255,0,0,255, "20,1", "255,0,0,255");-_assertPixel(offscreenCanvas, 41,1, 0,255,0,255, "41,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 1,10, 255,0,0,255, "1,10", "255,0,0,255");-_assertPixel(offscreenCanvas, 1,21, 0,255,0,255, "1,21", "0,255,0,255");+_assertPixel(canvas, 20,1, 255,0,0,255, "20,1", "255,0,0,255");+_assertPixel(canvas, 41,1, 0,255,0,255, "41,1", "0,255,0,255");+_assertPixel(canvas, 1,10, 255,0,0,255, "1,10", "255,0,0,255");+_assertPixel(canvas, 1,21, 0,255,0,255, "1,21", "0,255,0,255"); // other corners-_assertPixel(offscreenCanvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");-_assertPixel(offscreenCanvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");+_assertPixel(canvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");+_assertPixel(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");+_assertPixel(canvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, I don't see any security-related fixes. The changes appear to be purely cosmetic, renaming a variable from `offscreenCanvas` to `canvas` for consistency or readability purposes. Here's the analysis following your requested format:
Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.3.radii.1.dompointinit.worker.js
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 20,1, 255,0,0,255, "20,1", "255,0,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 20,1, 255,0,0,255, "20,1", "255,0,0,255");
The changes are purely variable name changes without any security implications. The functionality remains exactly the same, just with a different variable name.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.