Infobars do not always get cleared on navigation |
||
Issue descriptionThere 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?
,
Feb 26 2018
Issue 816603 has been merged into this issue.
,
Feb 26 2018
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.
,
Feb 26 2018
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.
,
Mar 6 2018
|
||
►
Sign in to add a comment |
||
Comment 1 by mdjones@chromium.org
, Nov 22 2017