Revert "Reland "Move WebUI code to run on the UI thread only.""
This reverts commit 52fd322ec1.
Revert "Reland "Remove InstantIOContext since it's not needed anymore.""
This reverts commit 6360b9fdb0.
Revert "Add extra thread hops in WebUI code on ChromeOS to simulate old timing."
This reverts commit dbb65740f2.
TBR=jennyz@chromium.org
Bug: 1082326, 1062873
Change-Id: Ic6e6d1cce833c9927ac80ceada5e682c3d120553
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2203707
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#769199}
This is a reland of 2dd9b658bb. There's no change, the fix was in different code in r768065.
TBR=nasko@chromium.org
Original change's description:
> Move WebUI code to run on the UI thread only.
>
> The optimization to run it on the IO thread was for the non-network service path. We can now simplify this.
>
> InstantIOContext can be removed, I'll leave that for a follow-up as this is already big.
>
> Bug: 908955,1062873
> Change-Id: Ia209d22575f49159227e49accf249dccb4fbaffe
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2190744
> Reviewed-by: Nasko Oskov <nasko@chromium.org>
> Commit-Queue: John Abd-El-Malek <jam@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#767182}
Bug: 908955, 1062873
Change-Id: Iae51e1c9b17a9c9d68bdfebd3a07387f34070339
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2197500
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#768133}
The optimization to run it on the IO thread was for the non-network service path. We can now simplify this.
InstantIOContext can be removed, I'll leave that for a follow-up as this is already big.
Bug: 908955,1062873
Change-Id: Ia209d22575f49159227e49accf249dccb4fbaffe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2190744
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#767182}
CHECK, CHECK_EQ etc., and NOTREACHED/NOTIMPLEMENTED have moved
to the much smaller headers check.h, check_op.h, and notreached.h,
respectively.
This CL updates .cc files to use those headers instead when
possible, with the purpose of saving compile time.
(Split out from https://crrev.com/c/2164525 which also has
notes on how the change was generated.)
Bug: 1031540
Change-Id: I643818242b92e19a1048fac89dd8aae323e8b1ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2164510
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#763511}
It no longer defines base::MakeUnique, so it should only be included
where base::WrapUnique is used.
Generated by:
for x in `git grep -l '#include "base/memory/ptr_util.h"' content`; do \
grep -q WrapUnique "$x" || sed -i -e \
'/^#include "base\/memory\/ptr_util\.h"$/d' "$x"; done
Bug: 755727
Tbr: mkwst@chromium.org
Change-Id: Ie2a34ff8f0fe83491185cd9f1a0aa52aa21829bb
Reviewed-on: https://chromium-review.googlesource.com/1005834
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549918}
base/memory/ptr_util.h includes will be cleaned up later.
Generated by:
git grep -l base::MakeUnique content/ | xargs perl -pi -e 's/base::MakeUnique/std::make_unique/'
Bug: 755727
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I10d622bde1d70b9a5f5aee0f229262c7018ec56b
Reviewed-on: https://chromium-review.googlesource.com/740181
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512186}
We declared the key to lookup the chrome blob storage at
two places. This caused problems in jumbo builds where
cc files are merged and the symbols clashed.
Bug: 746953
Change-Id: Icc11b256026536983841b084f6d2a74358594a47
Reviewed-on: https://chromium-review.googlesource.com/738133
Commit-Queue: Daniel Bratell <bratell@opera.com>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511608}
The object is never used on the IO thread, and even had DCHECKs to
ensure that's the case, so it makes no sense in ProfileIOData.
It's also one of the few things exposed by ResourceContext, which we're
probably going to get rid of.
BUG=712296
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
Review-Url: https://codereview.chromium.org/2820163002
Cr-Commit-Position: refs/heads/master@{#466358}
This is making progress in issue 675631 as well as unblocking
https://codereview.chromium.org/2592813002/ (per
AndroidProviderBackend::FromHistoryBackend()'s usage).
BUG=675631
TBR=clamy,nhiroki (for side-effects in content/ and storage/browser/fileapi/)
Review-Url: https://codereview.chromium.org/2597773002
Cr-Commit-Position: refs/heads/master@{#440406}
This removes support for <keygen> by updating it
to be an HTMLUnknownElement. As a result, it's
no longer a form-associated element and no
longer has IDL-assigned properties.
The <keygen> tag is still left in the parser,
similar to <applet>, so that it maintains the
document parse behaviours (such as self-closing),
but is otherwise a neutered element.
Tests that were relying on <keygen> having its
own browser-created shadow root (for its custom
select element) have been updated to use
progress bars, while other tests (such as
<keygen>-related crash tests) have been
fully removed.
As Blink no longer treats this tag as special,
all the related IPC infrastructure is removed,
including preferences and enterprise flags,
and all localized strings, as they're all now
unreachable.
This concludes the "Intent to Remove" thread
for <keygen> at
https://groups.google.com/a/chromium.org/d/msg/blink-dev/z_qEpmzzKh8/BH-lkwdgBAAJ
BUG=568184
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
Review-Url: https://codereview.chromium.org/2536993002
Cr-Commit-Position: refs/heads/master@{#440245}
A mostly-automated change to convert instances of WrapUnique(new Foo(...)) to
MakeUnique<Foo>(...). See the thread at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/iQgMedVA8-k
for background.
To avoid requiring too many manual fixups, the change skips some cases that are
frequently problematic. In particular, in methods named Foo::Method() it will
not try to change WrapUnique(new Foo()) to MakeUnique<Foo>(). This is because
Foo::Method() may be accessing an internal constructor of Foo.
Cases where MakeUnique<NestedClass>(...) is called within a method of
OuterClass are common but hard to detect automatically, so have been fixed-up
manually.
The only types of manual fix ups applied are:
1) Revert MakeUnique back to WrapUnique
2) Change NULL to nullptr in argument list (MakeUnique cannot forward NULL
correctly)
3) Add base:: namespace qualifier where missing.
WrapUnique(new Foo) has not been converted to MakeUnique<Foo>() as this might
change behaviour if Foo does not have a user-defined constructor. For example,
WrapUnique(new int) creates an unitialised integer, but MakeUnique<int>()
creates an integer initialised to 0.
git cl format has been been run over the CL. Spot-checking has uncovered no
cases of mis-formatting.
BUG=637812
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
Review-Url: https://codereview.chromium.org/2256173002
Cr-Commit-Position: refs/heads/master@{#416174}
Instead have it get the cert provider from its delegate (ResourceDispatcherHost) which in turn gets it from its delegate. The new method in ResourceDispatcherHostDelegate does use ResourceContext, but we are centralizing its use in just one class. In the future when the interface to resource dispatcher is mojo calls, we will have the child process' user ID which we can then use to get a profile interface for that user.
BUG=598073
Review-Url: https://codereview.chromium.org/2088763004
Cr-Commit-Position: refs/heads/master@{#401402}
Reason for revert:
Creating reland. The problem was a test that gets the salt on the IO thread. It should be changed to the UI thread.
Original issue's description:
> Revert of Make default media device ID salts random by default (patchset #13 id:260001 of https://codereview.chromium.org/1987643002/ )
>
> Reason for revert:
> Reverting because it is breaking the WebRTC MacTester bot.
> https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/55969/
>
> Original issue's description:
> > This results in different hashed device IDs on each session on embedders that don't have a specialized implementation of device ID salts such as WebView, Blimp and Content Shell. The new default helps prevent user fingerprinting on these embedders.
> >
> > Since the new default logic is basically the same as for Chrome incognito mode, Chrome's implementation of salts has been updated to defer to the new default on incognito mode.
> >
> > BUG=315022
> >
> > Committed: https://crrev.com/4db1329e005388540eb07429ac97827ca9bc422b
> > Cr-Commit-Position: refs/heads/master@{#399883}
>
> TBR=jam@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=315022
>
> Committed: https://crrev.com/f72bda81d0c3e6f256826e9ecdf6d745e4ad76c8
> Cr-Commit-Position: refs/heads/master@{#399887}
TBR=jam@chromium.org
BUG=315022
Review-Url: https://codereview.chromium.org/2068103003
Cr-Commit-Position: refs/heads/master@{#399902}
Reason for revert:
Reverting because it is breaking the WebRTC MacTester bot.
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/55969/
Original issue's description:
> This results in different hashed device IDs on each session on embedders that don't have a specialized implementation of device ID salts such as WebView, Blimp and Content Shell. The new default helps prevent user fingerprinting on these embedders.
>
> Since the new default logic is basically the same as for Chrome incognito mode, Chrome's implementation of salts has been updated to defer to the new default on incognito mode.
>
> BUG=315022
>
> Committed: https://crrev.com/4db1329e005388540eb07429ac97827ca9bc422b
> Cr-Commit-Position: refs/heads/master@{#399883}
TBR=jam@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=315022
Review-Url: https://codereview.chromium.org/2065383003
Cr-Commit-Position: refs/heads/master@{#399887}
Since the new default logic is basically the same as for Chrome incognito mode, Chrome's implementation of salts has been updated to defer to the new default on incognito mode.
BUG=315022
Review-Url: https://codereview.chromium.org/1987643002
Cr-Commit-Position: refs/heads/master@{#399883}
The need for this probably went away with TestBrowserThreadBundle.
BUG=598073
Review-Url: https://codereview.chromium.org/2064293002
Cr-Commit-Position: refs/heads/master@{#399839}
This is only file moves, this doesn't have any code or behavior changes.
Review-Url: https://codereview.chromium.org/1934223004
Cr-Commit-Position: refs/heads/master@{#393403}
ResourceDispatcherHostImpl::AddResourceContext() is called on the UI thread,
but all other users of |active_resource_contexts_| access it on the IO thread.
Review URL: https://codereview.chromium.org/1600263002
Cr-Commit-Position: refs/heads/master@{#371687}
In ServiceWorkerURLRequestJob::DidDispatchFetchEvent(), if response.stream_url of ServiceWorkerHostMsg_FetchEventFinished is set, ServiceWorkerURLRequestJob starts reading the body of the response from the stream instead of the blob.
But the stream may not be registered yet.
It is because ServiceWorkerHostMsg_FetchEventFinished is sent from the worker thread but StreamHostMsg_StartBuilding which triggers the stream registration is sent from the main thread of the ServiceWorker process.
So if ServiceWorkerURLRequestJob can't get the stream in DidDispatchFetchEvent(), call StreamRegistry::SetRegisterObserver() to receive the stream registration event.
When ServiceWorkerURLRequestJob successfuly gets the stream, it starts reading the stream.
The codes for reading the stream is almost same as the codes in StreamURLRequestJob.
This change depends on these changes:
https://codereview.chromium.org/760823002https://codereview.chromium.org/759823003
BUG=436424
Review URL: https://codereview.chromium.org/759203002
Cr-Commit-Position: refs/heads/master@{#308059}
This CL changes the persistence of host zoom levels to be on
a per-storage-partition basis, as opposed to (the current)
per-profile basis. This is needed to allow WebView content
(withing apps) to keep their zoom levels independent of those
in the main browser window.
BUG=335317
Review URL: https://codereview.chromium.org/393133002
Cr-Commit-Position: refs/heads/master@{#303841}
HostZoomMap will be moving from BrowserContext to StoragePartition soon
as part of fixing this bug. Many sites will still want to access the
default HostZoomMap for a BrowserContext, so we will rename this
function in order to be clear about that.
BUG=335317
Review URL: https://codereview.chromium.org/506073002
Cr-Commit-Position: refs/heads/master@{#292147}
BUG=269139
TEST= open http://src.chromium.org/chrome/trunk/src/chrome/test/data/webrtc/manual/peerconnection.html using http (not https) note the source ids in the Audio source and Video source dropdown. Restart chrome and notice that the source ids in the dropdown are unchanged. Clear the cookie cache and press the Refresh devices button and notice that the source ids have changed.
Review URL: https://codereview.chromium.org/54863002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@238103 0039d316-1c4b-4281-b951-d872f2087c98
This fixes the memory leaks introduced by the original CL.
BUG=171585
Review URL: https://chromiumcodereview.appspot.com/12637006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@187777 0039d316-1c4b-4281-b951-d872f2087c98
This infrastructure is shared by both renderer and worker processes, so having
it live in renderer_host/ was not quite right. This change also nicely reduces
the number of files in renderer_host/.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/11414299
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@171194 0039d316-1c4b-4281-b951-d872f2087c98
Empty ResourceContext constructors and destructors are needed on iOS since
profile_io_data has a subclass of the interface, but iOS doesn't use all the code in resource_context_impl.cc
Also removes a bunch of #include/using cruft in resource_context_impl.cc
BUG=None
Review URL: https://chromiumcodereview.appspot.com/11365253
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168192 0039d316-1c4b-4281-b951-d872f2087c98
This intentionally doesn't change the ChromeOS behavior at all. They all still use the default FileSystemContext.
This code also exposes the normal and media URLRequestGetters via the StoragePartition, and cleans up a bit of code that was accessing the URLRequestGetter in odd ways. Also, it makes Workers correctly use the Media Cache for Media fetches.
TBR=benjhyden,sky,davemoore,piman,mkwst,kalman
BUG=85121
Review URL: https://chromiumcodereview.appspot.com/10909182
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157284 0039d316-1c4b-4281-b951-d872f2087c98
* Get rid of BrowserContext::GetAppCacheService and ResourceContext::GetAppCacheService as they've been replace by accessors on the StoragePartition and WorkerStoragePartition classes.
* Added a BrowsingContext::GetRequestContextForStoragePartition(id) accessor so the constellation of storage context + main request context can initialized properly. Implemented that method in chrome's Profile class in terms of the existing GetRequestContextForIsolatedApp(id) accessor.
* Hold references to the ChromeAppCacheService and ChromeBlobStorageContext inside of ResourceMessageFilter and provide accessors to them. These are for use by the ResourceDispatcherHost singleton which would otherwise not have enough context to get needed references to partitioned things.
* Widen the ResourceDispatcherHostDelegate::RequestBeginning method to also take an AppCacheService* parameter since that value can no longer be retrieved via the ResourceContext. Chrome's impl of this delegate interface needs that value to construct OfflineResourceThrottles.
* Poke at WorkerProcessHost to create ResourceMessageFilters and others to utlize the correct URLRequestContext so the right set of cookies are used in shared workers.
TBR=mihaip,sail,thakis
BUG=85121
Review URL: https://chromiumcodereview.appspot.com/10916132
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156991 0039d316-1c4b-4281-b951-d872f2087c98
ResourceContext is the IO thread projection of the Profile. Since one profile
may now have multiple StoragePartitions (and thus multiple storage contexts),
we need to remove these accessors. All code in the IO thread has enough
information to find their appropriate storage context objects without needing
to grab it through the ResourceContext. The only users of the ResourceContext
storage context APIs are in worker_host classes.
As a result of this change, a number of APIs that previously just took 1
ResourceContext now need to take 4 additional objects. We could create a
StoragePartitionForIO class that parallels StoragePartition, but since the
API ugliness is purely limited to workers, the abstraction isn't worth its
weight.
BUG=85121
Review URL: https://chromiumcodereview.appspot.com/10885044
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156126 0039d316-1c4b-4281-b951-d872f2087c98
