| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intent is to allow unit-tests that use render view
to override ChildThread::CreateBridge() to provide their
own resource loading.
This is used by the upcoming translate unit-test.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/503032
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35014 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
jam, please review changes to the plugin create channel IPCs.
mpcomplete, please review changes to chrome_plugin_host.cc
ChromeFrame needs to intercept URL requests issued directly by plugins like gears to ensure that they
get routed through the host browser network stack. We decide whether or not a request is to be handled
based on the renderer process id and the render view id (routing id), which get passed in the
ViewHostMsg_RequestResource IPC. If this request is issued by Gears then the routing id comes in as
MSG_ROUTING_NONE, which causes the request to go through the chrome network stack.
Fix is to pass the host render view id to the plugin in the PluginMsg_Init IPC. The plugin already
receives the renderer process id. Both these ids now come back in the ViewHostMsg_RequestResource
IPC.
This fixes an issue with wave when rendered in full tab mode in ChromeFrame, where dropping a file into
a wave would cause the renderer to hang.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=23992
Bug=23992
Review URL: http://codereview.chromium.org/370007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31387 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
DISALLOW_EVIL_CONSTRUCTORS in a bunch of files.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/173538
Patch from Thiago Farina <thiago.farina@gmail.com>.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24774 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APIs and concrete classes defined in our new appcache library, and get rid of the old files.
There are many files in the CL, mostly to pickup constant values now defined in our new appcache library, and to reflect a terminilogy change (from 'context' to 'host').
TEST=some existing unit tests apply
BUG=none
Review URL: http://codereview.chromium.org/170003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24022 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
they are sent.
A good portion of this CL is to support the new UI test.
The IPC to notify the renderer of a redirect now includes a ResponseInfo struct
allowing WebURLLoaderImpl to provide detailed response info (including response
headers) to WebKit. This isn't strictly necessary, but I thought I'd include
this to make the code more future proof.
A cross origin restriction is added to SyncResourceHandler::OnRequestRedirected
that mimics the code in WebCore/platform/network/cf/ResourceHandleCFNet.cpp.
This is most unfortunate, and I filed a bug at bugs.webkit.org about the
similar duplication of logic in WebCore.
There seemed to be enough code paths leading to request cancellation at the
ResourceDispatcher level that I couldn't easily ensure that a request only gets
cancelled once. So, I added an is_cancelled flag to record if it is not
necessary to send a ViewHostMsg_CancelRequest IPC. This avoids some warnings
in the ResourceDispatcherHost.
To support my UI test, I needed to change URLRequestMockHttpJob to know how to
serve redirects. I moved URLRequestHttpJob::IsRedirectResponse to its base
class, URLRequestJob so that the implementation could be shared. This revealed
a minor bug in URLRequest. We were never resetting response_info_ upon
following a redirect. I added this code consolidated similar code from
URLRequest::Redirect and URLRequest::RestartWithJob into a new PrepareToRestart
method.
To support my UI test, I added a "hit count" field to URLRequestFilter, and I
added an associated automation IPC to query the value. The test was a bit
challenging to write because there is no way to tell the difference from JS.
Before and after, it appears to JS as though the cross-origin redirect failed.
However, the server can see the extra redirect request. So, I simply record
the number of hits against URLs of the form http://mock.http/foo, and use that
to observe if any extra requests were made. I implemented the new IPC message
by extending the AutomationResourceMessageFilter. This allowed me to trap the
IPC message on the IO thread where it is safe to probe the URLRequestFilter. I
then changed the implementation of AutomationMsg_SetFilteredInet to work
similarly.
I revised URLRequestMockHTTPJob::GetOnDiskPath to support ports. This actually
allowed me to reuse URLRequestMockHTTPJob to service URLs in different security
origins. My test redirects from http://mock.http/ to http://mock.http:4000/.
Please see the comments in cross-origin-redirect-blocked.html for details about
how the test functions.
R=brettw,wtc
BUG=16413
TEST=covered by resource_dispatcher_host_uitest.cc
Review URL: http://codereview.chromium.org/159370
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22067 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits the ipc code from the common project. The 'common' project pulls in
all of webkit, the v8 bindings, skia, googleurl, and a number of other projects
which makes it very difficult to deal with especially for external projects
wanting just to use some of Chromium's infrastructure. This puts the ipc code
into its top-level ipc/ directory with a dependency only on base. The common
project depends on the new ipc/ipc.gyp:ipc target so that all projects currently
pulling common in to get the IPC code still have it available. This mostly
follows agl's pre-gyp attempt to do this which was r13062.
Known issues:
- Currently a number of projects depend on chrome/chrome.gyp:common in order to
use the IPC infrastructure. Rather than fixing all of these dependencies I have
made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules
section of DEPS so that checkdeps.py doesn't complain. Over time projects that
need IPC should depend on the IPC project themselves and dependencies on common
removed, although I don't think many projects that need IPC will be able to get
away without common currently.
- ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a
ipc/ should not refer to files in chrome/... now. I'm not sure how to resolve
this since it's really an IDE bug
- the named pipe name (windows+linux) and the logging event name (all) + env
variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion
of ipc/ being an independent library. I think this should be examined in a
subsequent, much smaller patch.
- I've eliminated the IPC.SendMsgCount counter since it was implemented in a way
to create a dependency from ipc/ to chrome/common/chrome_counters. This is the
same approach that r13062 took.
http://codereview.chromium.org/155905
(Patch from James Robinson)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21342 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the code now does range request without any caching
the code path for passing file handle is not used any more.
Changes:
1. Remove response_data_file in webkit_glue::ResourceResponseHead
2. Remove response_data_file in net::ResourceInfo
3. Remove code that passes file handle using IPC
4. Remove code that passes file hadnle from network layer to ResourceDispatcherHost
5. Remove MediaResourceHandler
6. Remove code in disk_cache that expose the file handle
7. Remove ChromeURLRequestContext::CreateOffTheRecordForMedia() so no more OTR request context for media, in OTR mode simply memory cache is used
8. Reset cache size for media cache to default
BUG=12249
BUG=12256
Review URL: http://codereview.chromium.org/113931
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17227 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
- reduce header dependencies
- miscellanous cleanups (whitespace, explicit deps)
Review URL: http://codereview.chromium.org/113945
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17177 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
WebKit name for this piece of data.
R=jackson
BUG=None
TEST=No behavior change
Review URL: http://codereview.chromium.org/115743
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16843 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we delete a ResourceLoaderBridge before OnCompletedRequest is received, bad things happen. There's a lot of leaks at the following points:
1. OnMessageReceived ignores the message.
2. RemovePendingRequest removes it's internal deferred_message_queue.
But ViewHostMsg_Resource_DataReceived is not POD. We should also close the shared memory handle inside it.
Review URL: http://codereview.chromium.org/115396
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16297 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
in WebKit.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13343 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
browser processes to support an implementation of the HTML5AppCache spec with most of the logic running in the browser process. The gist of most of the changes are to indicate which frame each resource request is coming from, and to indicate which appcache each response was retrieved from (if any).See https://docs.google.com/a/google.com/Doc?docid=agv6ghfsqr_15f749cgt3&hl=en
Review URL: http://codereview.chromium.org/9712
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13258 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
This reverts commit r13062 which, unsurprisingly, broke the build.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13063 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
(No review URL: Rietvelt couldn't cope)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13062 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We'll need this to correctly load stylesheets that lack a Content-Type header in standards mode.
We're waiting on https://bugs.webkit.org/show_bug.cgi?id=24904 upstream before this works fully. This change, as it stands, is a no-op.
R=wtc
BUG=7448
Review URL: http://codereview.chromium.org/55049
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12739 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
Plumbing the security origin of the frame making the request to SSL land.
R=wtc
BUG=8706
Review URL: http://codereview.chromium.org/48038
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11851 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
The usage of RDH is now like RD, the client sends the message to RDH to see if it should handle it. I added methods to the Receiver interface so that RDH can get to the process id/handle/type when starting requests.
Review URL: http://codereview.chromium.org/42202
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11816 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
Implemented ResourceDispatcher::OnDownloadProgress to handle
ViewMsg_DownloadProgress IPC message, implementation is a clone of
ResourceDispatcher::OnUploadProgress because they have identical behavior.
Review URL: http://codereview.chromium.org/39104
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11681 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Added entry to ResourceResponseHead so that it contains
either a base::PlatformFile (OS_WIN) or
base::FileDescriptor (OS_POSIX) for passing the file
handle from browser to renderer process.
2. Also added IPC messages for reporting download progress
and ACK message for it. ResourceLoaderBridge::Peer::OnDownloadProgress
is added so that the peer is notified of the download
progress in the renderer process.
3. Load flag to kick start the resource loading for media
files. LOAD_MEDIA_RESOURCE is added so that
ResourceDispatcherHost knows how to use a different
ResourceHandler for handling media resource request.
Review URL: http://codereview.chromium.org/27168
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11661 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
ChildThread so that the same code is used by the plugin process (and soon, workers).
Review URL: http://codereview.chromium.org/42108
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11581 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
it was causing sync XMLHttpRequests to hang, breaking many layout tests).
TBR=darin
Review URL: http://codereview.chromium.org/39321
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11221 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
failures.
Review URL: http://codereview.chromium.org/39311
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11201 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
breaking NPAPI tests on Vista due to an erroneuous commented line).
TBR=darin
Review URL: http://codereview.chromium.org/39309
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11197 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
Reverting CL as plugin UI tests fail on Vista
Review URL: http://codereview.chromium.org/40260
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11187 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
This allows to tag a request on the renderer side with its security info. It is useful for the "frame info" dialog.
When showing that dialog for blocked frames, the security info can be retrieved and users can see the cert details for the blocked frame.
TEST=Open a page containing a frame served over bad HTTPS. The frame is blocked (replaced with a warning message). Right-click, select "Frame info". The dialog should have a "show cert" button which when pressed should show the frame's bad cert.
BUG=2853
Review URL: http://codereview.chromium.org/7276
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11179 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tests, and it might have caused a unit tests failure.
purify error : UMR in URLRequest::response_data_file
failing test:
URLFetcherHeadersTest.Headers:
c:\b\slave\chromium-rel-builder\build\src\chrome\browser\net\url_fetcher_unittest.cc(222): error: Value of: source->response_headers()->GetNormalizedHeader("cache-control", &header)
Actual: false
Expected: true
c:\b\slave\chromium-rel-builder\build\src\chrome\browser\net\url_fetcher_unittest.cc(223): error: Value of: header
Actual: ""
Expected: "private"
c:\b\slave\chromium-rel-builder\build\src\chrome\browser\net\url_fetcher_unittest.cc(181): error: Value of: response_code
Actual: 404
Expected: 200
Release only.
Review URL: http://codereview.chromium.org/39191
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10988 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Added entry to ResourceResponseHead so that it contains
either a base::PlatformFile (OS_WIN) or
base::FileDescriptor (OS_POSIX) for passing the file
handle from browser to renderer process.
2. Also added IPC messages for reporting download progress
and ACK message for it. ResourceLoaderBridge::Peer::OnDownloadProgress
is added so that the peer is notified of the download
progress in the renderer process.
3. Load flag to kick start the resource loading for media
files. LOAD_MEDIA_RESOURCE is added so that
ResourceDispatcherHost knows how to use a different
ResourceHandler for handling media resource request.
Review URL: http://codereview.chromium.org/27168
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10972 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
Also do some lint removal while I'm at it.
Review URL: http://codereview.chromium.org/20107
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9269 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/20072
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9209 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/17016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7529 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/11024
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6743 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
ResourceDispatcherHost
Review URL: http://codereview.chromium.org/12890
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6261 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
avoid some more Windows specific code.
Move Process and SharedMemory into the base namespace (most changes).
Review URL: http://codereview.chromium.org/10895
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5446 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an issue with a windowed flash instance not rendering content at times.The bug occurs as a result of the following:-1. The flash plugin executes a script via GetURLNotify. This script calls window.open with the target as self, which shows up as a new tab in the browser. This causes a new RenderView object to be instantiated (See RenderView::CreateWebView).2. RenderView::CreateWebView sends over the ViewHostMsg_CreateWindow IPC message to the browser. The handler in the browser sends over an ack for this message with the window handle. This is used as the parent window for any plugins instantiated in the page.3. At times, the newly created view starts receiving data which is processed before the ViewMsg_CreatingNew_ACK message is received and processed by the view. This causes the plugin to be instantiated without a parent window thus ending up as a top level window.The fix is to queue up resource messages and process them after we receive the ack for the ViewHostMsg_CreateWindow IPC.
Tests :- Covered by UI tests.
R=jam
Review URL: http://codereview.chromium.org/7514
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3631 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
which does the right thing based on whatever platform we're
compiling for, along with changing the hardcoded "stdext::",
which is a MSVC++ism to use base::hash_{map,set}.
B=1869
Review URL: http://codereview.chromium.org/1629
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1862 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
|