Status Update
No update yet.
Comments
24...@project.gserviceaccount.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Radha Nakade <
Link:
Migrate traffic from pixel2 to mediumphone on FTL emulators.
Expand for full commit details
Migrate traffic from pixel2 to mediumphone on FTL emulators.
Bug: 396715333
Test: ./gradlew emoji2:emoji2-emojipicker:ftlmediumphoneapi33
Change-Id: If5555443ca1a91479128e1bd6f4f909154c40ba2
Files:
- M
buildSrc/private/src/main/kotlin/androidx/build/FtlRunner.kt
Hash: c76f8094154101867327912e659ae47509755957
Date: Wed Feb 26 11:27:46 2025
24...@project.gserviceaccount.com
Revert "Add some debugging to understand why an assert fails"
This reverts commit 62df30bddc09ab787d58ce389615dea19cc9b2fd.
Reason for revert: The debug message found some issues in
Original change's description:
Bug: 379034423,394394717
Change-Id: I84c9ec08e9a0db87975333ea706774e23c95e0ee
Reviewed-on:
Reviewed-by: Calder Kitagawa <ckitagawa@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Min Qin <qinmin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1422793}
by qinmin@chromium.org -
[PWA/NavCapture]: ifdef out user_link_capturing_preference on CrOS
This CL removes some user link capturing behaviors from compiling on
ChromeOS. Link capturing preferences & overlapping scopes have custom
behavior on ChromeOS that use a different system separate from
web_app_registrar.
if-defing CapturesLinksInScope to prevent use in ChromeOS. This should
be sufficient while assuming that the WebApp API itself is hidden away
enough. There are files that do not build on CrOS so changes have not
been done to them.
Bug: 393418888
Change-Id: Ibfb38c67515d212422a7e9f45cc98f621f418f90
Reviewed-on:
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Commit-Queue: May Siem <msiem@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1422788}
by msiem@chromium.org -
If this is incorrect, please let us know why and apply the hotlistid:5433122.
na...@chromium.org
Using Code Search for the file, “file_select_helper.cc” suspecting the below Cl might have caused this issue
Suspect CL :
@Lily Chen -- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Thanks!
ch...@chromium.org
I think this is not a recent regression. It looks like the fuzzer itself was added in the regression range by crrev.com/c/6282148 and found this issue, which seems like a real, pre-existing bug.
My CL is unlikely to have caused it, because I didn't change any of the code that calls into file_select_helper.cc or the logic therein.
The
Seems like this is renderer-exposed via blink::mojom::FileChooser, via
cc joelhockey who somewhat recently added the kOpenDirectory value of Mode.
jo...@chromium.org
I think NOTREACHED() is the right thing for this code to do.
I added kOpenDirectory to file_chooser.mojom to be used by the File System Access code, but it is not expected to be used by FileSelectHelper::RunFileChooser() so I didn't change the switch in FileSelectHelper::RunFileChooserOnUIThread() to consider the new value, but left it to hit NOTREACHED().
We could update the switch to simply return for kOpenDirectory, but I've always understood that crashing the browser is a good thing to do if we get unexpected state from a renderer since it likely represents a security breach.
I guess this makes fuzzing a little more challenging. Ali, are you able to configure the fuzzer to avoid this case?
Description
Fuzzing Engine: libFuzzer
Fuzz Target: mojo_js_in_process_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux
Crash Type: CHECK failure
Crash Address:
Crash State:
in file_select_helper.cc
FileSelectHelper::RunFileChooserOnUIThread
FileSelectHelper::GetSanitizedFilenameOnUIThread
Sanitizer: address (ASAN)
Regressed:
Reproducer Testcase:
Issue filed automatically.
See