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

Issue 27401 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Nov 2009
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

ChromeFrame network requests fail randomly

Project Member Reported by ananta@chromium.org, Nov 11 2009

Issue description

Launch ChromeFrame in IE in full tab mode and start navigating to
a number of URLs like cf:http://www.timesofindia.com, 
cf:http://www.google.com, etc. 

Some of these requests end up failing and cause ChromeFrame to display the 
request failed page.

 

Comment 1 by bugdro...@gmail.com, Nov 11 2009

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

------------------------------------------------------------------------
r31731 | ananta@chromium.org | 2009-11-11 15:01:47 -0800 (Wed, 11 Nov 2009) | 26 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/automation/automation_resource_message_filter.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/automation/automation_resource_message_filter.h?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/automation/url_request_automation_job.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/automation/url_request_automation_job.h?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/external_tab_container.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/chrome_active_document.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/chrome_active_document.h?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/chrome_frame_activex_base.h?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/urlmon_url_request.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/urlmon_url_request.h?r1=31731&r2=31730

ChromeFrame HTTP requests would randomly fail if we navigated to multiple HTTP sites. This was because
the automation resource message filter tracked HTTP requests based on the request ids which are generated
by the renderer process. As a result a new request would get created say with id 0, while an existing request
would end in ChromeFrame causing the new request to incorrectly shutdown.

Fix is to revert back to the original way of tracking requests with an auto incrementing id. The automation url
job maintains both ids now, i.e. the automation request id and the chrome request id. The download notification
receives the automation id and basically looks up the associated automation request id and sends the notification
back to ChromeFrame.

This fixes bug http://code.google.com/p/chromium/issues/detail?id=27401

Other fixes in this CL include the following:-
1. The active document instance would never get destroyed. This was because we call ShowUI on the doc host 
   which maintains a reference. We need to call HideUI in Setsite of NULL, which releases the reference.

2. When the active x instance is shutting down we try to shutdown all running requests in the OnDestroy handler.
   To ensure that the request is deleted from the request map and released in the same thread which created it
   we post a task back to the ui thread which never runs as the window is being destroyed. Fix is to create
   a message only window with every urlmonrequest instance which supports task marshaling.

Tests in a future CL.

Bug= 27401 

Review URL: http://codereview.chromium.org/386008
------------------------------------------------------------------------

Comment 2 by ananta@chromium.org, Nov 11 2009

Status: Fixed

Comment 3 by bugdro...@gmail.com, Nov 19 2009

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

------------------------------------------------------------------------
r31731 | ananta@chromium.org | 2009-11-11 15:01:47 -0800 (Wed, 11 Nov 2009) | 26 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/automation/automation_resource_message_filter.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/automation/automation_resource_message_filter.h?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/automation/url_request_automation_job.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/automation/url_request_automation_job.h?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/external_tab_container.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/chrome_active_document.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/chrome_active_document.h?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/chrome_frame_activex_base.h?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/urlmon_url_request.cc?r1=31731&r2=31730
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/urlmon_url_request.h?r1=31731&r2=31730

ChromeFrame HTTP requests would randomly fail if we navigated to multiple HTTP sites. This was because
the automation resource message filter tracked HTTP requests based on the request ids which are generated
by the renderer process. As a result a new request would get created say with id 0, while an existing request
would end in ChromeFrame causing the new request to incorrectly shutdown.

Fix is to revert back to the original way of tracking requests with an auto incrementing id. The automation url
job maintains both ids now, i.e. the automation request id and the chrome request id. The download notification
receives the automation id and basically looks up the associated automation request id and sends the notification
back to ChromeFrame.

This fixes bug http://code.google.com/p/chromium/issues/detail?id=27401

Other fixes in this CL include the following:-
1. The active document instance would never get destroyed. This was because we call ShowUI on the doc host 
   which maintains a reference. We need to call HideUI in Setsite of NULL, which releases the reference.

2. When the active x instance is shutting down we try to shutdown all running requests in the OnDestroy handler.
   To ensure that the request is deleted from the request map and released in the same thread which created it
   we post a task back to the ui thread which never runs as the window is being destroyed. Fix is to create
   a message only window with every urlmonrequest instance which supports task marshaling.

Tests in a future CL.

Bug= 27401 

Review URL: http://codereview.chromium.org/386008
------------------------------------------------------------------------

Labels: -Area-ChromeFrame bulkmove Feature-ChromeFrame
Project Member

Comment 5 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 6 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Feature-ChromeFrame Cr-ChromeFrame

Sign in to add a comment