This is of no consequence to brave, as our uses do not make anything
with the quiet zone area.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/9106cb50e3f0c2d6fc20845c424727c1f9579130
commit 9106cb50e3f0c2d6fc20845c424727c1f9579130
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Tue Feb 27 22:44:12 2024 +0000
QR code: Paint quiet zone underneath `//components/qr_code_generator`.
This CL moves painting of the "quiet zone" from
`//chrome/browser/ui/views/qrcode_generator/qrcode_generator_bubble.cc`
into `//components/qr_code_generator/bitmap_generator.cc`. This helps
to ensure that all clients of `qr_code_generator` make an explicit
decision about who is responsible for generating the quiet zone.
The CL tweaks the code underneath `//components/qr_code_generator`
instead of reusing/copying the code from `qrcode_generator_bubble.cc`.
This results in a somewhat simpler code, and avoids creating additional
images (and additional memory copies). The end-to-end behavior of
`qrcode_generator_bubble.cc` shouldn't change - it should include the
exact same quiet zone before and after this CL (except for the colors -
see the next paragraph).
The old code would use
`GetColorProvider()->GetColor(kColorQrCodeBackground)` as the color of
the "quiet zone". The new code always uses white. The new behavior is
desirable because the quiet zone should have the same color as the
light-colored QR pixels (and currently `bitmap_generator.cc` always
paints black pixels on white background). In the future we may want to
make the exact colors configurable (e.g. theme-based).
Other than the color change described above, the CL should preserve the
old behavior (using `kWillBeAddedByClient` everywhere except the pixel
tests and `qrcode_generator_bubble.cc`). In particular, after this CL
most QR code clients continue to not include the quiet zone within the
image of the QR code (although surrounding UI elements may accidentally
provide such quiet zone).
Manual tests:
* Manually navigated to https://example.com and
used Chrome menu => Save and share => Create QR Code and
verified that the generated code works with Google Lens on an Android
device
* Manually tested whether the new pixel test goldens decode successfully
with Google Lens on an Android device (see
https://crbug.com/325664342#comment6 and #comment8 and #comment9):
- `DinoWithRoundQrPixelsAndLocators`,
`PassKeyWithSquareQrPixelsAndLocators`, and `BigUrl` tests worked
fine after this CL (an improvement, because their goldens didn't
decode before this CL)
- `HugeUrl` test didn't decode before and after this CL
Bug: 325664342
`GenerateBitmap` has been simplified further, doing away with the use of
`QRImage`, and just returning a `SkBitmap`.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/b8e0b24449b46049ec74aef53fdeb537e5ab6211
commit b8e0b24449b46049ec74aef53fdeb537e5ab6211
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Tue Feb 20 18:01:37 2024 +0000
QR code: Only return `SkBitmap` (no `gfx::Size`) from `GenerateBitmap`.
This CL simplifies the return type of
`qr_code_generator::GenerateBitmap` to stop returning the size (in QR
modules) of the generate QR code. The size was only used in one place
(in `QRCodeGeneratorBubble::AddQRCodeQuietZone`). This CL modifies that
code, so that the quiet zone can be added without knowing the size of
the generated QR code.
I treat this CL as part of the post-launch cleanup related to
go/rusty-qr-code-generator. OTOH, I plan to handle the rest of the
"quiet zone" follow-up as a separate bug: https://crbug.com/325664342
This CL should not result in any changes in the end-to-end behavior.
OTOH, the test coverage via
//chrome/browser/share/qr_code_generator_pixeltest.cc doesn't extend to
the `QRCodeGeneratorBubble::AddQRCodeQuietZone` method, so this CL has
also been manually tested to verify if the QR code generated for
https://example.com still works fine when scanned with an Android phone.
Bug: 40263739, 325664342
Chromium change:
https://chromium.googlesource.com/chromium/src/+/a2be834619701017dfcb830cc5b0b6522f4d52cf
commit a2be834619701017dfcb830cc5b0b6522f4d52cf
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Thu Feb 15 20:49:12 2024 +0000
Delete `//chrome/services/qrcode_generator`.
After go/rusty-qr-code-generator we no longer need a separate service
that delegates QR code generation to a separate process. Therefore this
CL deletes the `//chrome/services/qrcode_generator` directory.
* `qr_code_generator_pixeltest.cc` has been moved to
`//chrome/browser/sharing` (as I am not sure if pixel tests are
supported for `components_browsertests` - this has been discussed in
https://crrev.com/c/5278872/8#message-5b43795fe4019875ebb87e19e95b49e08947133b).
* Code that draws a QR code into a `SkBitmap` has been moved from
`//chrome/services/qrcode_generator/qrcode_generator_service_impl.*`
to `//components/qr_code_generator/bitmap_generator.*`.
* `qrcode_generator.mojom` has been deleted:
* Bitmap style enums (e.g. `LocatorStyle`) have been moved into
`//components/qr_code_generator/bitmap_generator.h`
* Error codes have been moved into
`//components/qr_code_generator/qr_code_generator.h`
* Fields of `GenerateQRCodeRequest` have been "splat" into
parameters of the new `GenerateBitmap` function
* `GenerateQRCodeResponse` has been replaced with a new
`QRImage` struct plus `base::expected<QRImage, Error>`
* `QRImageGenerator` class has been deleted and its method
has been refectored:
* The method became a free function
* The result is now returned directly instead of via a callback
This CL is quite big - I appologize. Splitting this CL into smaller
pieces is a bit difficult, mostly because it seems hard to defining some
types in `.mojom` and some in `.h`.
Bug: 40263739
Upstream has enabled ARC by default for apple code. This change removes
the individual setting of it across targets.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/8485b150e05e24548ec98413ced34994ab9ef622
commit 8485b150e05e24548ec98413ced34994ab9ef622
Author: Avi Drissman <avi@chromium.org>
Date: Mon Jul 31 18:07:39 2023 +0000
Rename "enable_arc2" to "enable_arc"
Remove uses of "enable_arc" that snuck in, and rename "enable_arc2" to
"enable_arc".
Bug: 733237