Chromium 121 porting findings #731

t-m-w · 2024-01-18T18:59:50Z

t-m-w
Jan 18, 2024

Hi @uazo! CalyxOS have been trying to independently port our current subset of Cromite's changes, and a few ones we hadn't included before, to 121.0.6167.71 (early stable). We often use patches from your next- branch for this when available, but we also like to try it on our own once in a while, too, to be sure it remains a manageable endeavor for us.

Wanted to share a few initial findings, in case it's useful to you at all during your own porting process. Note that since we don't use all the patches and are only (working to be) up-to-date as of Cromite v120.0.6099.144, this might not be entirely applicable for you, but still wanted to share.

It looks like Cromite does not currently use this, but the arg use_relative_vtables_abi=true is now leading to clang parser crashes that suggest uploading a crash report, so now may not be the best time to start! This was true for me even with vanilla 121. I currently haven't uploaded a report.
A new build bug (see added lines)
These changes (and possibly still others) rely on feature flags that have now been removed: Re-introduce-modal-dialog-flag-to-close-all-tabs.patch, Partition-MediaDeviceId-by-default.patch
Disable-all-predictors-code.patch also used a removed flag, SpeculationRulesPrefetchProxy, which was only part of that change. Brave didn't seem to think it is needed anymore.
ResourceItem (for Content settings infrastructure) now expects an accessibility string argument. I added accessibility strings to the site-setting patches, along with some minor other string changes. Feel free to use any of them if they sound right.

Our work-in-progress patches are here: https://review.calyxos.org/c/CalyxOS/platform_external_calyx_chromium/+/24149

Thanks as always for your continued work on Cromite!

uazo · 2024-01-19T08:44:30Z

uazo
Jan 19, 2024
Maintainer

i will definitely take a look at the result, a comparison never hurts, with carl we occasionally missed a few changes here and there (which were always a source of bugs).

It looks like Cromite does not currently use this, but the arg use_relative_vtables_abi=true is now leading to clang parser crashes that suggest uploading a crash report,

do you have the crash log?
I started yesterday with the rebase and haven't got around to trying the build yet. but if you tell me what the target is (I can tell from the log) I'll try that right away without having to redo the build twice!

Disable-all-predictors-code.patch ... which was only part of that change. Brave didn't seem to think it is needed anymore.

yes, I saw, I had arrived at this patch.
whether they simply overlooked it, I don't agree with brave though, we'll talk about that when I put the next- branch on.

Our work-in-progress patches are here

Apart from the result, I am also interested in the methodology you adopt.
this is what I do: from my build machine (see #617 (comment)), I launch:

export BROMITE_SHA=0b99765ab53aff3ae5f6e5cea6d57a4fa8263267
export VERSION=121.0.6167.75

# enable internet on container
sudo iptables -D INPUT -p tcp -s localhost --dport 8118 -j ACCEPT
sudo iptables -D INPUT -p tcp --dport 8118 -j DROP

docker create --name dev-wp --network dev-network \
 -e "BROMITE_SHA=$BROMITE_SHA" \
 -e "VERSION=$VERSION" \
 --entrypoint "tail" uazo/chromium:$VERSION "-f" "/dev/null"

docker start dev-wp
docker exec -ti dev-wp bash

in the container:

sudo chown lg /etc/apt/apt.conf.d/proxy.conf
sudo echo Acquire::http::Proxy \"http://172.18.0.1:8118\"\; >/etc/apt/apt.conf.d/proxy.conf
export HTTPS_PROXY=http://172.18.0.1:8118
export HTTP_PROXY=http://172.18.0.1:8118
export http_proxy=http://172.18.0.1:8118
export https_proxy=http://172.18.0.1:8118
sudo apt-get -y install wiggle dos2unix nano

mkdir cromite && \
    cd cromite && \
    git init && \
    git remote add origin https://github.com/uazo/cromite && \
    git fetch origin $BROMITE_SHA && \
    git reset --hard FETCH_HEAD && \
    cd ..
echo $VERSION >cromite/build/RELEASE
export HOME=/home/lg/working_dir
cd $HOME
cd chromium/src/
rm -rf build/toolchain/win/rc/hack/

# from https://github.com/uazo/cromite/blob/master/tools/images/cromite-source/apply-cromite-patches.sh#L10
rm -rf v8/.git 
cp -r v8 v8bis
git rm -rf v8 || true
git submodule deinit -f v8 || true
mv v8bis v8
git add -f v8 >/dev/null
git commit -m ":NOEXPORT: v8 repo" >/dev/null

rm -rf third_party/devtools-frontend/src/.git 
cp -r third_party/devtools-frontend third_party/devtools-frontend-bis
git rm -rf third_party/devtools-frontend || true
git submodule deinit -f third_party/devtools-frontend || true
rm -rf third_party/devtools-frontend
mv third_party/devtools-frontend-bis third_party/devtools-frontend
git add -f third_party/devtools-frontend >/dev/null
git commit -m ":NOEXPORT: third_party/devtools-frontend repo" >/dev/null

and finally

bash ~/cromite/tools/apply-all-patch.sh

this script helps me with the 'guided' rebase, telling me what and where to check. then it's my turn :)
the longest part is the verification of what wiggle does: for that I would like to create a specific tool but I have no time
my development environment is simply vscode on windows with the remote dev container and a couple of extensions

I would like to understand your method and possibly spend some time improving the flow

5 replies

t-m-w Jan 19, 2024
Author

It looks like Cromite does not currently use this, but the arg use_relative_vtables_abi=true is now leading to clang parser crashes that suggest uploading a crash report,

do you have the crash log?

Thanks, and yes, but don't worry about it unless you plan to enable the arg or are particularly curious. We're okay with matching Cromite's behavior on this. Otherwise, I have this snippet, and I have the crash files it references if needed.

Log snippet

[136/66344] CXX clang_x86_v8_arm/obj/buildtools/third_party/libc++/libc++/locale.o
FAILED: clang_x86_v8_arm/obj/buildtools/third_party/libc++/libc++/locale.o 
../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF clang_x86_v8_arm/obj/buildtools/third_party/libc++/libc++/locale.o.d -D_LIBCPP_OVERRIDABLE_FUNC_VIS=__attribute__\(\(__visibility__\(\"default\"\)\)\) -DLIBCXX_BUILDING_LIBCXXABI -DUSE_UDEV -DUSE_AURA=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE -DCR_CLANG_REVISION=\"llvmorg-18-init-12938-geb1d5065-1\" -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -DCR_LIBCXX_REVISION=caccdb0407e84357ca6490165e88dcad64e47d17 -DCR_SYSROOT_KEY=20230611T210420Z-2 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -D_LIBCPP_BUILDING_LIBRARY -I../../third_party/libc++/src/src -I../.. -Iclang_x86_v8_arm/gen -I../../buildtools/third_party/libc++ -fno-delete-null-pointer-checks -fno-ident -fno-strict-aliasing -fstack-protector -funwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -mllvm -instcombine-lower-dbg-declare=0 -mllvm -split-threshold-for-reg-with-hint=0 -ffp-contract=off -fcomplete-member-pointers -m32 -mfpmath=sse -msse3 -ffile-compilation-dir=. -no-canonical-prefixes -ftrivial-auto-var-init=pattern -O2 -fdata-sections -ffunction-sections -fno-unique-section-names -fno-math-errno -fno-omit-frame-pointer -momit-leaf-frame-pointer -gdwarf-4 -g1 -gdwarf-aranges -fvisibility=hidden -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang raw-ref-template-as-trivial-member -Xclang -plugin-arg-find-bad-constructs -Xclang check-stack-allocated -Xclang -plugin-arg-find-bad-constructs -Xclang check-raw-ptr-to-stack-allocated -Xclang -plugin-arg-find-bad-constructs -Xclang raw-ptr-fix-crbug-1449812 -Xclang -plugin-arg-find-bad-constructs -Xclang raw-ptr-exclude-path=/third_party/dawn/ -Xclang -plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -fstrict-aliasing -fPIC -Wall -Wno-unused-variable -Wno-c++11-narrowing -Wno-unused-but-set-variable -Wno-misleading-indentation -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -Wloop-analysis -Wno-unneeded-internal-declaration -Wenum-compare-conditional -Wno-ignored-pragma-optimize -Wno-deprecated-builtins -Wno-bitfield-constant-conversion -Wno-deprecated-this-capture -Wno-invalid-offsetof -Wno-vla-extension -Wno-thread-safety-reference-return -Werror -std=c++20 -Wno-trigraphs -fexperimental-relative-c++-abi-vtables -gsimple-template-names -nostdinc++ -isystem../../third_party/libc++/src/include -isystem../../third_party/libc++abi/src/include --sysroot=../../build/linux/debian_bullseye_i386-sysroot -fvisibility-inlines-hidden -std=c++20 -fexceptions -frtti -c ../../third_party/libc++/src/src/locale.cpp -o clang_x86_v8_arm/obj/buildtools/third_party/libc++/libc++/locale.o
PLEASE submit a bug report to https://crbug.com in the Tools>LLVM component, run tools/clang/scripts/process_crashreports.py (only if inside Google) to upload crash related files, and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF clang_x86_v8_arm/obj/buildtools/third_party/libc++/libc++/locale.o.d -D_LIBCPP_OVERRIDABLE_FUNC_VIS=__attribute__((__visibility__(\"default\"))) -DLIBCXX_BUILDING_LIBCXXABI -DUSE_UDEV -DUSE_AURA=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE -DCR_CLANG_REVISION=\"llvmorg-18-init-12938-geb1d5065-1\" -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -DCR_LIBCXX_REVISION=caccdb0407e84357ca6490165e88dcad64e47d17 -DCR_SYSROOT_KEY=20230611T210420Z-2 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -D_LIBCPP_BUILDING_LIBRARY -I../../third_party/libc++/src/src -I../.. -Iclang_x86_v8_arm/gen -I../../buildtools/third_party/libc++ -fno-delete-null-pointer-checks -fno-ident -fno-strict-aliasing -fstack-protector -funwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -mllvm -instcombine-lower-dbg-declare=0 -mllvm -split-threshold-for-reg-with-hint=0 -ffp-contract=off -fcomplete-member-pointers -m32 -mfpmath=sse -msse3 -ffile-compilation-dir=. -no-canonical-prefixes -ftrivial-auto-var-init=pattern -O2 -fdata-sections -ffunction-sections -fno-unique-section-names -fno-math-errno -fno-omit-frame-pointer -momit-leaf-frame-pointer -gdwarf-4 -g1 -gdwarf-aranges -fvisibility=hidden -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang raw-ref-template-as-trivial-member -Xclang -plugin-arg-find-bad-constructs -Xclang check-stack-allocated -Xclang -plugin-arg-find-bad-constructs -Xclang check-raw-ptr-to-stack-allocated -Xclang -plugin-arg-find-bad-constructs -Xclang raw-ptr-fix-crbug-1449812 -Xclang -plugin-arg-find-bad-constructs -Xclang raw-ptr-exclude-path=/third_party/dawn/ -Xclang -plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -fstrict-aliasing -fPIC -Wall -Wno-unused-variable -Wno-c++11-narrowing -Wno-unused-but-set-variable -Wno-misleading-indentation -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -Wloop-analysis -Wno-unneeded-internal-declaration -Wenum-compare-conditional -Wno-ignored-pragma-optimize -Wno-deprecated-builtins -Wno-bitfield-constant-conversion -Wno-deprecated-this-capture -Wno-invalid-offsetof -Wno-vla-extension -Wno-thread-safety-reference-return -Werror -std=c++20 -Wno-trigraphs -fexperimental-relative-c++-abi-vtables -gsimple-template-names -nostdinc++ -isystem../../third_party/libc++/src/include -isystem../../third_party/libc++abi/src/include --sysroot=../../build/linux/debian_bullseye_i386-sysroot -fvisibility-inlines-hidden -std=c++20 -fexceptions -frtti -c ../../third_party/libc++/src/src/locale.cpp -o clang_x86_v8_arm/obj/buildtools/third_party/libc++/libc++/locale.o
1.      <eof> parser at end of file
2.      Code generation
#0 0x000055f36bd2e97f (../../third_party/llvm-build/Release+Asserts/bin/clang+++0x452e97f)
clang++: error: clang frontend command failed with exit code 139 (use -v to see invocation)
clang version 18.0.0 (https://chromium.googlesource.com/a/external/github.com/llvm/llvm-project eb1d5065c560b3468fa0d34af3103359cd78c088)
Target: i386-unknown-linux-gnu
Thread model: posix
InstalledDir: ../../third_party/llvm-build/Release+Asserts/bin
clang++: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: ../../tools/clang/crashreports/locale-bec37f.cpp
clang++: note: diagnostic msg: ../../tools/clang/crashreports/locale-bec37f.sh

Apart from the result, I am also interested in the methodology you adopt. this is what I do

Ooh, lots of useful scripts and techniques here that I hadn't looked at, yet! I want to dive into this more soon.

I would like to understand your method and possibly spend some time improving the flow

I don't think I have anything helpful or flow-improving to share in that regard. Your workflow looks much more structured. Here, it's mostly manual and could be optimized and scripted.

I do almost everything on a remote server, including working through merge conflicts -- with nano! Prior patches are applied with git cherry-pick ${old_version}..${old_version_with_patches}, and I go from there. If a build is successful, I use a one-liner of multiple commands to rsync the APKs to a local CalyxOS checkout, clean and re-build the Chromium-related components, and adb sync them to test on an actual device.

There are a handful of basic things and web tests we often check (not formalized yet). We don't regularly examine Chromium's network traffic, at this time.

When everything appears to be okay (or sometimes sooner, as with the WIP patches), I copy and paste (not even scripted yet!) chunks of this at a time to generate patches to be uploaded to our Gerrit:

Generating patches

NUM_PATCHES=some_number   # set manually based on how many commits following the chromium version
git format-patch --full-index -N -k -P --zero-commit -${NUM_PATCHES}
LAST_BROMITE_PATCH=some_number   # set manually based on what appears to be the last cromite-specific commit in the listing generated above
ls -1 *.patch | cut -d - -f 2- | head -n${LAST_BROMITE_PATCH} > ../platform_external_calyx_chromium/build/bromite_patches_list.txt
ls -1 *.patch | cut -d - -f 2- | tail -n+$((${LAST_BROMITE_PATCH}+1)) > ../platform_external_calyx_chromium/build/calyx_patches_list.txt
mv ../platform_external_calyx_chromium/build/patches/FIRST-Add-git-review-configuration.patch{,.2}
rm ../platform_external_calyx_chromium/build/patches/*.patch
mv ../platform_external_calyx_chromium/build/patches/FIRST-Add-git-review-configuration.patch{.2,}
for i in 0*.patch; do mv ${i} $(echo $i | cut -d - -f 2-); done
sed -i '/From 0000000000000000000000000000000000000000/d' *.patch
sed -i -z -E 's/\nindex [a-f0-9]{40}\.\.[a-f0-9]{40}( [0-9]+)?\n---/\n---/g' *.patch
sed -i -E '/^[0-9]+\.[0-9]+\.[0-9]+$/d' *.patch
mv *.patch ../platform_external_calyx_chromium/build/patches/

uazo Jan 19, 2024
Maintainer

We're okay with matching Cromite's behavior on this.

But in cromite should be true.
see https://github.com/uazo/cromite/actions/runs/7555193136/job/20604428632#step:8:935
which abi are you trying to build?

Prior patches are applied with git cherry-pick ${old_version}..${old_version_with_patches}

you are not the first to tell me to use that method, never used.

with nano!

gee, try vscode (or one of its variants) with remote ssh! I will try to integrate it into my docker images at some point, so my dev container will be available directly from the browser.

If a build is successful, I use a one-liner of multiple commands to rsync the APKs to a local CalyxOS checkout, clean and re-build the Chromium-related components, and adb sync them to test on an actual device.

during rebase I use ninja with -k 0, I wait for all errors and then fix all them.
I find it convenient.

Your workflow looks much more structured. Here, it's mostly manual and could be optimized and scripted.

I think it is possible to do better.
let me know if we want to do something about it in the future.

Generating patches

Ops, forgotten, I use

rm ~/cromite/build/patches-new/* || \
     bash ~/cromite/tools/export-all-patch.sh && \
     bash ~/cromite/tools/export-patch-list.sh

always inside the container.

t-m-w Jan 19, 2024
Author

We're okay with matching Cromite's behavior on this.

But in cromite should be true. see https://github.com/uazo/cromite/actions/runs/7555193136/job/20604428632#step:8:935 which abi are you trying to build?

Ahh my mistake, I was judging based on this alone: https://github.com/uazo/cromite/blob/master/build/cromite.gn_args

We build for Android arm64 almost exclusively right now, with a command similar to:
OUT="$(pwd)/out/calyx-121.0.6167.71-arm64"; topdir="$(pwd)"; time autoninja -C "$OUT" trichrome_chrome_64_32_bundle trichrome_library_64_32_apk trichrome_webview_64_32_apk system_webview_shell_apk && pushd "$OUT/apks" && rm -f universal.apk && java -jar "$topdir/third_party/android_build_tools/bundletool/bundletool.jar" build-apks --mode universal --bundle TrichromeChrome6432.aab --output . --output-format DIRECTORY && popd

Rarely we will build for x64 to update emulator images.

gee, try vscode (or one of its variants) with remote ssh! I will try to integrate it into my docker images at some point, so my dev container will be available directly from the browser.

I haven't used VS Code yet, should give it a try.

during rebase I use ninja with -k 0, I wait for all errors and then fix all them. I find it convenient.

...Learn something new every day! That sounds very helpful, thank you.

I think it is possible to do better. let me know if we want to do something about it in the future.

Sounds good, baby steps here 😄

~/cromite/tools/export-all-patch.sh

Looks nice, so much simpler.

uazo Jan 22, 2024
Maintainer

PLEASE submit a bug report to https://crbug.com in the Tools

I do not detect that error. my build is successful.
this is the version of clang that is currently present and it looks the same as yours:

third_party/llvm-build/Release+Asserts/bin/clang++ --version
clang version 18.0.0 (https://chromium.googlesource.com/a/external/github.com/llvm/llvm-project eb1d5065c560b3468fa0d34af3103359cd78c088)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/lg/working_dir/chromium/src/third_party/llvm-build/Release+Asserts/bin

checking the command line, I think you got some gn arguments wrong.
for example you have --sysroot=../../build/linux/debian_bullseye_i386-sysroot but it should be --sysroot=../../third_party/android_toolchain/ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot and also you have -DUSE_AURA=1, maybe you forgot target_os = 'android'?

regarding patches, good job!
just two or three things to point out, then I'll write them down.

t-m-w Jan 22, 2024
Author

Hmm... We do have target_os = 'android'. I'm honestly not sure why USE_AURA is there since I don't set it; must be set by something else. I haven't intentionally done anything to mess with the sysroot path. I get the same failure even if I explicitly set use_sysroot=false (edit: although I still see the same --sysroot line after doing that; might need the output directory cleared or something?).

These are the exact build args I've been using when encountering the error (only without use_relative_vtables_abi=true commented out): https://review.calyxos.org/c/CalyxOS/platform_external_calyx_chromium/+/24149/6/build/patches/LAST-Add-build-args.patch

uazo · 2024-01-22T11:16:48Z

uazo
Jan 22, 2024
Maintainer

calyxos-chromium-commits-new-120.0.6099.144.txt

I like what you write (recommended, privacy, feature, also seen in brave etc.).
why don't you ask me about doubts? discussions about what I do is exactly what I am looking for.

I think I will include it somehow in the documentation I will have to do, as a table.

0 replies

t-m-w · 2024-01-23T17:07:36Z

t-m-w
Jan 23, 2024
Author

OK, here is a pretty minor question, but the Chromium code base can often take me a while to navigate to find a sure answer...

Instead of "Disable NTP remote suggestions by default", we have been using the NTPContentSuggestionsEnabled policy, which looks like it should act the same as registry->RegisterBooleanPref(kEnableSnippets, false);, but do you know if it is still important to also have registry->RegisterBooleanPref(kArticlesListVisible, false); for some reason?

Context (may need to scroll a bit, but the context is the highlighted comment): https://review.calyxos.org/c/CalyxOS/platform_external_calyx_chromium/+/24035/comments/a520b15d_9a387896

2 replies

uazo Jan 24, 2024
Maintainer

OK, here is a pretty minor question, but the Chromium code base can often take me a while to navigate to find a sure answer...

well, there is an official mailing list to ask about these things (https://groups.google.com/a/chromium.org/g/chromium-dev).
I can tell you what I know, or give you information about my patches, but if you want an answer that is absolutely true, I advise you to ask them, they always answer.

but do you know if it is still important to also have registry->RegisterBooleanPref(kArticlesListVisible, false); for some reason?

policies are applied immediately after reading the preferences from file, when initialising profiles.
the registration of defaults, therefore, may also be different.
otr profiles are derived from the standard profile, so even then, no problem.
I don't know how it behaves with the sync function, but for now it is not active, so I don't know.

there are some policies, however, that do not act on a single property and above all are managed by google, so, theoretically, it is better to use policies rather than chase changes.

Simple and small... Do we handle it via features or policies already, or should we pick it?

Unfortunately, some patches should be modified and removed, but, damn it, I have too many things to do.

t-m-w Jan 24, 2024
Author

well, there is an official mailing list to ask about these things (https://groups.google.com/a/chromium.org/g/chromium-dev). I can tell you what I know, or give you information about my patches, but if you want an answer that is absolutely true, I advise you to ask them, they always answer.

Awesome, nice to know they always answer.

Thanks for those details. For this change it sounds like it's likely fine to stick with the policy. (I've never seen any network traffic related to this stuff anyway... at least not yet.)

Unfortunately, some patches should be modified and removed, but, damn it, I have too many things to do.

No worries at all! Very relatable...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Chromium 121 porting findings #731

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 3 comments 7 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

Chromium 121 porting findings #731

t-m-w Jan 18, 2024

Replies: 3 comments · 7 replies

uazo Jan 19, 2024 Maintainer

t-m-w Jan 19, 2024 Author

uazo Jan 19, 2024 Maintainer

t-m-w Jan 19, 2024 Author

uazo Jan 22, 2024 Maintainer

t-m-w Jan 22, 2024 Author

uazo Jan 22, 2024 Maintainer

t-m-w Jan 23, 2024 Author

uazo Jan 24, 2024 Maintainer

t-m-w Jan 24, 2024 Author

t-m-w
Jan 18, 2024

Replies: 3 comments 7 replies

uazo
Jan 19, 2024
Maintainer

t-m-w Jan 19, 2024
Author

uazo Jan 19, 2024
Maintainer

t-m-w Jan 19, 2024
Author

uazo Jan 22, 2024
Maintainer

t-m-w Jan 22, 2024
Author

uazo
Jan 22, 2024
Maintainer

t-m-w
Jan 23, 2024
Author

uazo Jan 24, 2024
Maintainer

t-m-w Jan 24, 2024
Author