CVE-2025-14373
Overview
Background
- `BrowserControlsManager`
- the Android Chrome class (
chrome/android/java/.../fullscreen/BrowserControlsManager.java) that controls whether the top browser controls (the toolbar holding the URL/omnibox) are shown, hidden or scrollable, including on fullscreen entry and exit. - `BrowserControlsState`
- the constraint enum for the controls:
SHOWN(forced visible),HIDDEN(forced hidden) andBOTH(may scroll in and out). - `mForceRelayoutOnVisibilityChange`
- a flag that makes the next visibility update force an Android view relayout, so the toolbar is actually redrawn rather than just marked
View.VISIBLE. - `scheduleVisibilityUpdate`
- schedules an update that applies the computed visibility to the Android controls view.
Root Cause Analysis
In a lambda inside BrowserControlsManager that reacts to a change in controls constraints (the hunk does not name the enclosing method), the forced relayout for the earlier bug crbug.com/452885338 was set only under narrow conditions. It sat inside an inner block that the hunk shows only partly. It also required BrowserControlsUtils.doSyncMinHeightWithTotalHeightV2() and getAndroidControlsVisibility() != View.VISIBLE. The commit message says that without a relayout on fullscreen exit, the toolbar view does not redraw even though it is VISIBLE and correctly positioned, and that this “can occur even when transitioning to the BOTH state”. Paths that missed the old condition could therefore leave the browser controls (including the URL display) invisible after leaving fullscreen.
The fix removes the feature-flag-gated block and adds a check after the inner block. Whenever the new constraints are SHOWN or BOTH and the Android controls are not VISIBLE, it sets mForceRelayoutOnVisibilityChange = true and calls scheduleVisibilityUpdate(). This widens the set of cases that force the redraw.
SHOWN or BOTH while the controls are not visible.Attack Path
- Enter fullscreen a web page enters fullscreen (for example through the Fullscreen API, which normally needs a user gesture), so the browser controls are hidden on Android.
- Exit fullscreen
the page or user leaves fullscreen, and the controls constraints change to
SHOWNorBOTH. - Relayout skipped
before the fix, if the transition did not hit the old inner branch or
doSyncMinHeightWithTotalHeightV2()was off, no forced relayout happened, so the toolbar stayed undrawn even though it was logically visible. - Spoofed browser UI with the real toolbar and URL not shown, the page has the whole screen and could draw fake browser UI or a fake URL (inferred).
Impact Assessment
Files Changed
chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java
Audit Directions
- Security UI hidden after state transitionsreview fullscreen, picture-in-picture, keyboard, rotation and tab-switch transitions on Android for cases where the toolbar or URL bar is logically visible but never redrawn or laid out.
- Security-relevant fixes behind feature flagslook for redraw or visibility fixes that only apply when a feature such as
doSyncMinHeightWithTotalHeightV2is enabled, which leaves the default configuration exposed. - Visibility state vs. rendered stateaudit code that trusts
View.getVisibility()(or the controls’ offset) as proof that the UI is on screen, and confirm a relayout or invalidate follows each change.
Patch
From 044d94f7f47fe37c0fea4556f89d336307f33e0a Mon Sep 17 00:00:00 2001
From: Patrick Noland <pnoland@google.com>
Date: Fri, 21 Nov 2025 14:42:42 -0800
Subject: [PATCH] Force relayout when constraints change to SHOWN or BOTH
The linked bug occurs due to not doing a relayout when exiting
fullscreen. Without the relayout, the view does not redraw despite being
VISIBLE and positioned in the correct location. This can occur even when
transitioning to the BOTH state.
Bug: 461532432
Change-Id: I3112a3d05c8ddaee2538d5e17880604f4374046c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7186537
Reviewed-by: Peilin Wang <peilinwang@google.com>
Commit-Queue: Patrick Noland <pnoland@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1548734}
---
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java b/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java
index 243bc88..17554ad 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java
@@ -243,21 +243,23 @@
renderDrivenShowConstraint);
}
- // From https://crbug.com/452885338: Some devices when changing the top
- // controls visibility when exiting fullscreen, the visibility change might
- // not honor a redraw. We do this through forcing a relayout to avoid
- // the toolbar remains hidden.
- if (getAndroidControlsVisibility() != View.VISIBLE
- && BrowserControlsUtils.doSyncMinHeightWithTotalHeightV2()) {
- mForceRelayoutOnVisibilityChange = true;
- }
-
// If controls become locked, it's possible we've previously delayed
// actually setting visibility until a touch event is over. In this case, we
// need to trigger an update again now, which should go through due to
// constraints.
scheduleVisibilityUpdate();
}
+
+ // From https://crbug.com/452885338, https://crbug.com/461532432: When changing
+ // controls visibility when exiting fullscreen, the visibility change might not
+ // honor a redraw. We do this through forcing a relayout to avoid the toolbar
+ // remains hidden.
+ if ((constraints == BrowserControlsState.SHOWN
+ || constraints == BrowserControlsState.BOTH)
+ && getAndroidControlsVisibility() != View.VISIBLE) {
+ mForceRelayoutOnVisibilityChange = true;
+ scheduleVisibilityUpdate();
+ }
});
}
Original Bug Report
Bottom Minibar Fails to Display URL – Potential Phishing via Spoof Bar
Steps to reproduce the problem
- Go to https://lbstyle.github.io/testcase.html
- Tap inside the textarea field.
- Tap the button labeled “Go to google.com”.
Problem Description
Observed behavior: The spoof bar minibar does not display the current URL. This could allow a malicious page to overlay a fake minibar with a fake URL, potentially tricking users into entering sensitive information.
Summary
Bottom Minibar Fails to Display URL – Potential Phishing via Spoof Bar
Additional Data
Category: Security
Chrome Channel: Not sure
Regression: N/A \