Root cause: 
infobar_delegate.cc#ShouldExpire will determine if infobar(s) need to be removed when navigating webpage.
In case it is navigating the same page (nav_entry_id_ == details.entry_id), it will return false and infobar(s) will persist.

However, in some case, when we navigate back and forth too quickly.
nav_entry_id_ will be updated too early before the checking (it is
supposed to be updated after the checking).
And this makes infobar_delegate.cc#ShouldExpire misunderstand that
it is navigating the same page and won't remove infobar(s).

I am still working on the solution.

This bug also happens in the old translate info bar.

Hi Peter,

This bug is about the translation infobar (which is expected to dismiss) persists when navigating to a new URL.
This happens when user trying to navigate to another URL while the old navigation is still undergoing.
This bug will be gone when I removed the following condition:
((nav_entry_id_ != details.entry_id) || details.is_reload);
from InfoBarDelegate::ShouldExpire().

But that line is added by crrev.com/1215053007/ which is
for fixing a desktop bug  crbug.com/492610 / and this is out of my reach.

Could you please take a look to this bug or assign this to the best person?
Thank you!

What do you mean by "when we navigate back and forth too quickly. nav_entry_id_ will be updated too early before the checking (it is supposed to be updated after the checking)"?

Is this happening because the translate infobar is being added (by something) after a new load is pending?  If that's the case maybe we could somehow annotate attempts to load infobars for pending navigations to note that those shouldn't be dismissed; not sure.

->martiw to clarify more what comment 6 means.

Issue 703786 has been merged into this issue.

Hi Peter,

The variable nav_entry_id_ in infobar_delegate.cc is used to prevent the dismiss of infobar(s) which is added while the navigation was already in process.

And nav_entry_id is the cause of this bug.
On a slow android device, when TranslateHelper finished capturing the webpage and starting to create the translate infobar.
The navigation of new webpage could be already in process (if user tries to navigate another page when loading).
And this will cause the translate infobar of the previous page persists on the current page.

After some digging, it seems nav_entry_id_ is only used for preventing the disappearance of session_crashed_infobar ( crbug.com/492610 ).
As Android version doesn't have session_crashed_infobar, the most simple and safe fix for this bug could be disabling nav_entry_id_ (see crrev.com/2960833002) on Android version.

What do you think?

That sounds like a fragile solution, since in the future someone could easily change things elsewhere and break you.

It also sounds incomplete, since this can happen on desktop too if the desktop device is slow.

It's also not clear to me that the session crashed infobar is the only infobar that cares about this.

It seems like the real issue is that sometimes we want infobars added during a pending navigation to apply to the navigated-from page, and sometimes to the navigated-to page.  I think the solution is to indicate this somehow when adding the infobar.

Another possibility is that infobars added during a pending load should really be waiting until the load commits, as we do for e.g. the accidental search infobar.  That would let us remove this check.

Another possibility is that infobars that want to apply to "the next page" are really infobars that don't ever want to auto-dismiss.

In all these cases, we'd want to see if we can tell from code observation whether a particular infobar can be intentionally added during a pending load and want to apply to the upcoming page.  If yes, then we can audit to figure out the answer to the possibilities above.  If no, then we're going to have to hand-wave about what infobars this could apply to.

 Issue 246864  has been merged into this issue.

Thanks Peter,
It seems crrev.com/2960833002 is not a good solution.

I am thinking to fix this bug by overriding ShouldExpire() on translate_infobar_delegate without touching other infobars.

Because there are 70 infobar_delegates across all the platforms.  It seems quite scary and risky to affect them.
I want to be more conservative and do the change on translate infobar only.

I just skimmed through all the open issues (~500) with keyword 'infobar'.
It seems "infobar persists at new page" issue only happens on translate infobar but not other infobars.

PTAL crrev.com/2956173003/ to see if it is okay.

By the way, this bug could be reproduced on desktop.
But it is quite difficult to.
I tried 30+ times going backward and forward in order to reproduce this successfully on linux.

I understand why making larger-scale changes would worry you, but that's the route you should go.

Chromium is a huge project that will persist for decades.  The cost of doing a change right now is dwarfed by the cost we would pay if we always made conservative local fixes that didn't address problems systematically.

Accordingly, in 99.99% of cases, the rule in Chromium is "do the correct fix without regard to how scary it is".

In this case, I don't see any reason to believe the problem is translate-specific.  Merely noticing it only on the translate infobar does not seem to indict anything about the translate infobar.  It's just more likely to occur there, where we add an infobar on a delay after loading a page.  But if someone wrote code in the future for a similar feature that was also on a delay after loading a page, they'd see the same problem.

So I don't think fixing this only in translate is correct.  I proposed a couple of possibilities in comment 12.  You should proceed down those routes.

Thanks Peter for your prompt reply!
I will work on another CL for a larger change. :)

Hi Peter, like you said:
Infobar(s) added *during a pending navigation* might apply to:
(A) The navigate-to page. (persist when page loaded)
(B) The navigate-away page. (auto-dismiss when page loaded)

Please see if crrev.com/2963923002 is good.
It created a method for specifying (B)’s infobars and let them auto-dismiss.

After skimming all of the infobar_delegates, it seems there are about 20 infobars belong to (B).
And 3 infobars belong to (A).  (For others, we might keep them as is.)
If the CL is good, I will ask other infobar owners and do the follow-up CLs for those infobar_delegates accordingly.

Hey Marti - what's the status on this bug? I saw Peter's comment in the code review that we should move the CL to Gerritt if the work is still applicable/valuable.

Hi Yana,  this bug is quite difficult and I spent a while but still not success in fixing it in a proper way.  I think I will keep busy with other UI stuff for a while before I can continue to work on this again.

No worries. Just wanted to make sure you didn't lose your CL.

Marti - is this something that you're still tackling in Q4?

Hi Yana, I think I don't have the bandwidth for working on this bug at Q4.