IssueTracker

The new ContextAware API will be available in Activity 1.2.0-alpha08 and is used by Fragment 1.3.0-alpha08 and AppCompat 1.3.0-alpha02 to implement FragmentManager's and AppCompatDelegate's pre-onCreate() logic.

Wait, this can't work as advertised.

FragmentActivity extends ComponentActivity

public FragmentActivity(@LayoutRes int contentLayoutId) {
    super(contentLayoutId);
    init();
}

private void init() {
    addOnContextAvailableListener(new OnContextAvailableListener() {
        // ...
    }
}

ComponentActivity

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
    // ...
    mContextAwareHelper.dispatchOnContextAvailable(this);
    super.onCreate(savedInstanceState);
    //...
}

1. Call FragmentActivity constructor,
2. which calls ComponentActivity super constructor,
3. which dispatches context available... to noone,
4. and calls platform Activity.onCreate.
5. Bubble up to FragmentActivity constructor and register context listener,
6. which is invoked synchronously but only after platform Activity.onCreate has already been called.

Did I miss something? I'm confused.

Never mind, constructor vs onCreate. :facepalm: Sorry.

Re #8 - the fact that these are different things is indeed exactly why this API exists :)

https://docs.google.com/document/d/1hyftTRyqV7ZJ5s2b_-Q9K6RJdpgedgvKP4vYoTK7i1A/edit?usp=drive_web ([Feedback] Bass Booster)

https://docs.google.com/document/d/1hyftTRyqV7ZJ5s2b_-Q9K6RJdpgedgvKP4vYoTK7i1A/edit?usp=drive_web ([Feedback] Bass Booster)

If this is a bypass of crbug.com/333708039 it would have been introduced much earlier than M130 or at least by the fix for that issue (https://crrev.com/c5540331); setting to M128 according (as that is the current oldest active release channel)

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security Impact hotlist or the Severity field, and remove the ReleaseBlock hotlist.

szager: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add Disable-Nags (case sensitive) to the Chromium Labels custom field.

I'm not able to reproduce any actual exploit from this. When I click on the button multiple times, eventually I get a "Sign in with Google" popup window asking for confirmation. As long as I "cancel" that, the login fails. I believe the popup window is evidence of the fact that the iframe detected that it was not visible; otherwise it would have permitted the authentication without showing a popup.

I'll leave this open for another week to gather feedback, in case I'm missing something.

I was able to reproduce this by using a longer setTimeout delay; I have a fix in review.

Project: chromium/src
Branch: main
Author: Stefan Zager <szager@chromium.org>
Link:      https://chromium-review.googlesource.com/5950965

IntersectionObserver -- properly handle "unknown" occlusion state

IntersectionObserver -- properly handle "unknown" occlusion state 
 
If we most recently reported a target as "guaranteed visible", then in 
the interest of avoiding false positives we must transition to "not 
guaranteed visible" if the frame occlusion state becomes "unknown". 
 
This CL also makes a child frame inherit its parent's "not visible" 
occlusion state rather than calling it "unknown", which is technically 
more correct. 
 
Bug: chromium:371247941 
Change-Id: I4d721dd252d013deac14a12f1f2922830ef2a8a4 
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5950965 
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> 
Commit-Queue: Stefan Zager <szager@chromium.org> 
Cr-Commit-Position: refs/heads/main@{#1373093}

It should be fixed in current Canary channel Chrome; it will reach Dev channel in about a week.

The NextAction date has arrived: 2024-10-28 To opt-out from this automation rule, please add Optout-Blintz-Nextaction-Alert to the "Chromium Labels" custom field.

Hello, this is in our queue, but there have been a number of high severity issues for us to assess in the last few weeks. This issue should be assessed this week or next. As always, when assessment has taken place a reward decision will be provided here. Thank you for you patience in the meantime.

Congratulations Hafiizh! Thank you for your efforts and reporting this issue to us.

the original content of this report was set as restricted content; which should not be a setting used for the information in a Chrome security bug report, the following is the content from the original report:

===================== VULNERABILITY DETAILS============

This vulnerability is similar to https://issues.chromium.org/issues/333708039, in this bug when the cursor focus on google one tap button after that the opacity the frame set 0 (obscured by "click me see funny cats" button) the focus still to google tap button lead to click jacking

VERSION Chrome Version 131.0.6755.0 (Official Build) canary (64-bit) Operating System: Windows 10

REPRODUCTION CASE

1. open https://thundering-unruly-windflower.glitch.me/spoofh.html
2. click on "click me see funny cats" button

This bug has been closed for more than 14 weeks. Removing issue access restrictions.