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

Issue 178415 link

Starred by 19 users

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2013
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 0
Type: Bug



Sign in to add a comment

GCF crashes when trying to process a target="_blank" link.

Reported by cmiller0...@gmail.com, Feb 26 2013

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22

Steps to reproduce the problem:
1. Run a simple website in IIS or VS Dev Server (sample code available here: https://github.com/christophermllr/gcfbug)
2. Click a link wiht target="_blank"
3. GCF properly opens a new tab.
4. Close the tab and click the link again.
5. The tab crashes.
6. Click the link again and the browser crashes.

What is the expected behavior?
All tabs should open.

What went wrong?
Screencast here: http://www.youtube.com/watch?v=QJB1EKyHbVs&hd=1

Crashed report ID: No, can't find in GCF.

How much crashed? Whole browser

Is it a problem with a plugin? Yes Google Chrome Frame

Did this work before? Yes Our production users only started complaining about this yesterday,.

Chrome version: 25.0.1364.97  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)

Code: https://github.com/christophermllr/gcfbug
Video: http://www.youtube.com/watch?v=QJB1EKyHbVs&hd=1
 
Also, this is GCF v25.0.1364.97 in IE9.
 Issue 179335  has been merged into this issue.
Cc: grt@chromium.org ananta@chromium.org kerz@chromium.org
Labels: -Pri-2 Pri-0 Feature-ChromeFrame Mstone-25 ReleaseBlock-Stable
Owner: robertshield@chromium.org
Status: Assigned
Cc: erikwright@chromium.org nyerramilli@chromium.org
 Issue 171877  has been merged into this issue.
The stack trace from the crash on M25 when opening a tab. The crash is not 100% reproducable, though it happens with high frequency. 

The stack looks like this:

0:019> kC

urlmon!CTransaction::UnlockRequest
npchrome_frame!Hook_UnlockRequest
urlmon!CTransData::{dtor}
urlmon!CTransData::Release
urlmon!CBinding::{dtor}
urlmon!CBinding::Release
urlmon!CUrlMon::StartBinding
urlmon!CUrlMon::BindToObject
ieframe!CDocObjectHost::_StartAsyncBinding
ieframe!CDocObjectHost::SetTarget
ieframe!CDocObjectView::CreateViewWindow2
ieframe!CDocObjectView::CreateViewWindow
ieframe!FileCabinet_CreateViewWindow2
ieframe!CBaseBrowser2::_CreateNewShellView
ieframe!CBaseBrowser2::_CreateNewShellViewPidl
ieframe!CBaseBrowser2::v_NavigateToPidl
ieframe!CShellBrowser2::_InitializeWindow
ieframe!CShellBrowser2::_Initialize
ieframe!CShellBrowser2_CreateInstance
ieframe!CTabWindow::_TabWindowThreadProc
ieframe!LCIETab_ThreadProc
iertutil!_IsoThreadProc_WrapperToReleaseScope
IEShims!NS_CreateThread::DesktopIE_ThreadProc
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart
Seeing the same exact issue in GCF v25.0.1364.97 in IE8 (v8.0.7601.17514).

Comment 7 by Deleted ...@, Mar 4 2013

Just wanted to say I am getting this issue too. Does anyone know of a workaround until we get a new version of ChromeFrame. We have been telling our clients to Right click and select the "Open in a new tab" option, but that is a pretty lousy workaround.

BTW, I tried using a javascript window.open and an anchor tag with target="_blank", but neither one of those options work.

Any ETA when the new version of ChromeFrame will be available?
We have been telling our users the same.  I'm also interested if there is another workaround.
Project Member

Comment 9 by bugdroid1@chromium.org, Mar 4 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=185956

------------------------------------------------------------------------
r185956 | ananta@chromium.org | 2013-03-04T20:14:48.170100Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/protocol_sink_wrap.cc?r1=185956&r2=185955&pathrev=185956

Fix a crash seen in ChromeFrame when opening a non CF top level tab from a CF page.

This was a regression caused by the fix for bug http://code.google.com/p/chromium/issues/detail?id=168308
which was to not invalidate the protocol sink mapping for CF pages which are switched in from IE.

The crash in this case occurs because the protocol sink mapping is removed in the call to IInternetProtocol::Terminate
as this is treated as a ChromeFrame request. This is only a temporary CF url which eventually transitions to
the actual URL which  is opened in IE. For the curious we intercept IInternetProtocol::LockRequest and for
the special gcf://attach_external_tab requests we addref the protocol data and return without calling the original
LockRequest API. When UnlockRequest is invoked we rely on the protocol data mapping to exist to release the
protocol data and return without calling the original UnlockRequest API.

In this case the sequence is IInternetProtocol::LockRequest, IInternetProtocolRoot::Terminate followed by
IInternetProtocol::UnlockRequest. In our terminate handler we remove the protocol data mapping for the attach tab
request. When UnlockRequest is called we call the original API and end up crashing.

Fix is to not invalidate the protocol data mapping for attach tab requests.

A test for this is in the works by robertshield.

BUG= 178415 
R=robertshield
Review URL: https://chromiumcodereview.appspot.com/12395021
------------------------------------------------------------------------

Comment 10 by Deleted ...@, Mar 5 2013

we found a workaround for this. you can use window.open, but you have to have the third parameter set filled in. i.e. 

window.open("http://www.someurl.com", null, "resizable=yes");

It doesn't matter what parameters you fill in, but you have to fill something in.
Labels: Merge-Approved Mstone-26
Merge approved for M26 (1410 branch).
Project Member

Comment 12 by bugdroid1@chromium.org, Mar 6 2013

Labels: -Merge-Approved merge-merged-1410
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=186289

------------------------------------------------------------------------
r186289 | robertshield@chromium.org | 2013-03-06T00:19:47.737932Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1410/src/chrome_frame/protocol_sink_wrap.cc?r1=186289&r2=186288&pathrev=186289

Merge 185956
> Fix a crash seen in ChromeFrame when opening a non CF top level tab from a CF page.
> 
> This was a regression caused by the fix for bug http://code.google.com/p/chromium/issues/detail?id=168308
> which was to not invalidate the protocol sink mapping for CF pages which are switched in from IE.
> 
> The crash in this case occurs because the protocol sink mapping is removed in the call to IInternetProtocol::Terminate
> as this is treated as a ChromeFrame request. This is only a temporary CF url which eventually transitions to
> the actual URL which  is opened in IE. For the curious we intercept IInternetProtocol::LockRequest and for
> the special gcf://attach_external_tab requests we addref the protocol data and return without calling the original
> LockRequest API. When UnlockRequest is invoked we rely on the protocol data mapping to exist to release the
> protocol data and return without calling the original UnlockRequest API.
> 
> In this case the sequence is IInternetProtocol::LockRequest, IInternetProtocolRoot::Terminate followed by
> IInternetProtocol::UnlockRequest. In our terminate handler we remove the protocol data mapping for the attach tab
> request. When UnlockRequest is called we call the original API and end up crashing.
> 
> Fix is to not invalidate the protocol data mapping for attach tab requests.
> 
> A test for this is in the works by robertshield.
> 
> BUG= 178415 
> R=robertshield
> Review URL: https://chromiumcodereview.appspot.com/12395021

TBR=ananta@chromium.org
Review URL: https://codereview.chromium.org/12483004
------------------------------------------------------------------------
Labels: -Mstone-26
Project Member

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

Labels: -Feature-ChromeFrame -Mstone-25 M-25 Cr-ChromeFrame
Status: Fixed
Confirmed fixed in latest build of GCF.

Thanks

Sign in to add a comment