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

Issue metadata

Status: Verified
Owner:
Email to this user bounced
Closed: Jul 2009
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Tab closes, if a new url is navigated on page loading

Reported by venkataramana@chromium.org, Jul 6 2009

Issue description

ToT(r19942)

-Navigate to a page which takes longer time to load. While page is loading, 
navigate to different page.

Before the 2nd page rendering is committed, the tab closes. If you have 
single tab opened, then browser window closes in this case.

Marking this as DEV release blocker.

PS: this happens to me consistently. 
 
Labels: -Area-BrowserUI Area-BrowserBackend
Status: Assigned
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.
Status: Fixed
r19752 reverted in: http://src.chromium.org/viewvc/chrome?view=rev&revision=20081

Marking fixed

Comment 11 by gaz...@gmail.com, Jul 9 2009

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?

Comment 12 by gaz...@gmail.com, Jul 9 2009

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.

Comment 14 by jon@chromium.org, Jul 9 2009

The fix in r20081 is not in 3.0.192.1.  Wait a week.
couldn't you merge it? it really sucks
Status: Verified
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.

Comment 19 by tony@chromium.org, Jul 11 2009

 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?
Labels: -Area-BrowserBackend Area-Internals
Labels: -Regression bulkmove Type-Regression
Project Member

Comment 26 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 27 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Type-Regression Cr-Internals Type-Bug-Regression

Sign in to add a comment