New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 787835 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Infobars do not always get cleared on navigation

Project Member Reported by dgn@chromium.org, Nov 22 2017

Issue description

There is some race condition between adding new infobars and navigations that causes infobars from one page to persist after the user navigated to another page. The sequence looks like:

InfoBarService - DidStartNavigation
InfoBarManager - AddInfoBar
InfoBarService - NavigationEntryCommitted
InfoBarDelegate - ShouldExpire => returns false

The infobar assumes it belongs to the page we started navigating to, so when the entry is committed and the clear the infobars belonging to the previous page, the new infobar is not cleared.

- Not sure if the same type of issue affects other systems than the infobar service
- I don't know how often this bug can be triggered
- I don't know if it's important to fix considering I heard of plans to update Android infobars to be more independent of the current desktop based infrastructure

mdjones@ thoughts?

 
I'd be curious to know if there are any infobars that appear before a page has completed navigation. If there aren't, we could block or immediately dismiss any infobars that are triggered during a navigation. Though, ideally the controller of the infobar is watching for this and wouldn't event trigger.

This seems like a problem that would persist into the new infrastructure; I'm not convinced this is necessarily tied to native/desktop code. In any case we should discuss possible solutions now so that changes we make going forward account for this.
Issue 816603 has been merged into this issue.
I suspect there is another bug on this.

We can indeed show infobars while a load is pending.  In general, the solution is probably that at the time of an infobar's creation, instead of auto-fetching the ID the infobar should be associated with, it should explicitly specify which navigation it should be associated with.
This is easy to repro if using the experiment ConsumeGestureOnNavigation and the popup blocker:

document.getElementById('link').click();
window.open();

The experiment will cause the popup to be blocked, and the infobar will persist into whatever #link points to.

As an aside: I think it makes more sense to dismiss open infobars (if appropriate) when the navigation commits than to avoid showing them if there is an ongoing navigation. Javascript can do complicated things like start and stop navigations at will and I'd be nervous about having untrusted JS (potentially) in control of when infobars can appear.
Labels: android-fe-triaged
Status: Available (was: Untriaged)

Sign in to add a comment