Is the tab crashing or just closing?

Can you narrow down the regression window? It would be a great help in figuring out who 
caused this. Thanks.

Not a crash. 
Works fine in r19748, but broken in r19792.

The only cls that look likely in that range are 

r19766: meelapshah: Moved typedef of RedirectList from HistoryService class to history 
namespace.

r19752: rafaelw: Fix to allow browser close after download initiated from chrome:// 
url.

To elaborate on the behavior, took a screen capture of the behavior, which is 
attached.  Notice in the screen cast that the url in the omnibox goes from (actions 
in <>):

cnn.com (appears to be loading)
<click on yahoo.com link>
yahoo.com (appears to be loading)
ads.cnn.com... (flashes in the bar)
<tab closes>

Tab Closing.7z 377 KB   Download

I don't think this is from my patch.

It started happening between 19751 (works) and 19757 (stops working)

I've commented out the relevant lines of my r19752 change in a local build and I still 
see the closing behavior.

I'll debug further to see if I can track down the issue.

This still seems really close to my change, so I'm a bit uneasy about saying it's not 
my fault, but I did go as far as completely reverting my change in my local trunk 
build and I'm still see the closing behavior.

I put a bunch of debugging code to try to understand what's going on. Unfortunately, 
this code is fairly complicated, and I have seen a few varieties of it failing.

However, one thing I am definitely seeing is a race condition with 
RenderViewHostManager::Navigate().

Here's how it goes:

1) Navigation one (google.com) comes in: RVHM::Navigate sends a ShouldClose to RV.
2) Navigation two (yaoo.com) comes in: RVHM::Navgiate calls CancelPending() which 
clears the pending_rvh_.
3) RV responds to ShouldClose from (1) and sends ShouldClose_ACK back.
4) RVHM receives ShouldClose_ACK, observes that it has no pending_rvh_ and assumes 
the tab is being closed, so it proceeds with firing the FirePageUnload() which 
ultimately closes the contents.

My problem is that, from where I sit, it's not clear to me how this ever worked. I 
suspect theres something that I'm not understanding about the code paths.

In any case, I'm cc'ing brettw in the hope he'll have a deeper understanding.

Ok, no, the other thing: this is my fault. I think there is something very similar 
going on that exists even without my change, but it only happens to me in debug, not in 
release.

I'm going to revert my change.

r19752 reverted in: http://src.chromium.org/viewvc/chrome?view=rev&revision=20081

Marking fixed

I'm not 100% sure it's relevant, but since upgrading to 3.0.192.1 (worked fine on 
prev. dev release) Google Reader opens and closes tabs in a way similar to this bug.
The bug recreates every time but only on one feed - the google chrome feed :)

1. Go to google reader
2. If not exist - add feed: http://googlechromereleases.blogspot.com/atom.xml
3. Click on any post title to open it in a new tab

Expected: new tab opens with the post
Actual: new tab open briefly with "loading...", then "about:blank" and closes.

Is this the same bug, or should I open a new one?

Also noticed that right clicking the link and either "open in a new tab" or "open in a 
new window" works fine, only left-click fails.

Don't know if it helps, but middle clicking also fails.

The fix in r20081 is not in 3.0.192.1.  Wait a week.

couldn't you merge it? it really sucks

Was able to reproduce it once on ToT(r 20262), but no luck after that. will reopen it, 
If I could be able to reproduce it consistently.

 Issue 16420  has been merged into this issue.

 Issue 16458  has been merged into this issue.

 Issue 15831  has been merged into this issue.

 Issue 16316  has been merged into this issue.

Still happens to me from time to time on 3.0.193.1 (Official Build 20697).
It takes a minute (at maximum) for me to reproduce by typing gm(enter) (for gmail.com) 
and sp(enter) (for spiegel.de) one after another fast enough into the same omnibox. I 
guess a slower computer and/or a slower internet connection could help in reproducing 
it.

I noticed that when doing this, sometimes the contents to the omnibox switches to the 
URL of an element of the page that is currently loading. So, when typing 
gmail.com(enter) while loading spiegel.de, spiegel.de load process gets canceled and I 
sometime see an url like this one for a short time:
http://www.spiegel.de/static/sys/pixel.gif

Then of course, navigation to gmail.com overwrites this entry. Hope that helps.

I believe your are now observing  bug 16147 . Perhaps this issue should now be merged 
into that one?

(No comment was entered for this change.)