Bromite: No adblock when a tab is reopened from "Recent tabs"?

It could be related to the subresource filter not being added in such situation.

Can the bug be reproduced with corresponding Chromium version?

N/A: Bromite adblock issue

The ad blocker is in fact present also in Chromium, so this could be tested also there - although it uses a very specific default set of ads to block.

The ad blocker is in fact present also in Chromium, so this could be tested also there - although it uses a very specific default set of ads to block.

I thought about that after I posed the issue. If you have any idea how to find a site to test with, I will. I poked around the Chromium source, but everything just said things like what is blocked are ads that violate the "Better Ads Standard", without any block list that I could locate.

I found that bug is related to the fact that the subframe (in ContentSubresourceFilterThrottleManager::MaybeCreateActivationStateComputingThrottle) does not have the ActivationState of the parent mainframe.

In fact, I found that the web_contents created in https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/sessions/session_restore_android.cc;l=35 did not have connect ChromeSubresourceFilterClient.

This - I think - is given by NavigationRequest::StartNavigation() launches navigation of a web_contents without the correct delegate (here https://source.chromium.org/chromium/chromium/src/+/master:content/browser/frame_host/navigation_throttle_runner.cc;l=99) and then generates NULL in https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/chrome_content_browser_client.cc;l=4041

it happens because (chrome/browser/android/tab_android.cc).AttachTabHelpers is not called before the SessionRestore::RestoreForeignSessionTab() and therefore the NavigationThrottleRunner::RegisterNavigationThrottles() doesn't have the ability to invoke ChromeSubresourceFilterClient::MaybeAppendNavigationThrottles (that insert the adblocker control).

Now, the definitive solution would be to try to generate a suitable web_contents_android, but I would have to replicate AttachTabHelpers() handling in RestoreForeignSessionTab, absurd to maintain. maybe there is some other cleaner way too, but I haven't found it.
I worked around the bug by making future maintenance easier, with only one edited file: restoring tab from recently closed tabs, java will create navigation in a new tab, closing the open one. from the point of view of the ui it is more or less identical.

I think that the bugs does not exist in upstream because some parts of code are called by the safe_browsing component, in bromite doesn't exits.

Very nice analysis, thanks @uazo. Is it possible that there are other bugs upstream because of this asymmetry? If you find a security bug - present upstream even with the safe browsing component - then you could submit it, claim a bounty and see it fixed relatively quickly. We could also check if GrapheneOS/Vanadium is affected.

For the time being the PR you made should suffice.

from what I've seen, all calls to SwapWebContents
https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/android/tab_android.h;l=101 could have that problem, today only restore and webportal (which I don't know still what it is).