GitLab

BUG=none
TEST=none


Review URL: http://codereview.chromium.org/8351008

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107840 0039d316-1c4b-4281-b951-d872f2087c98

BUG=
TEST=


Review URL: http://codereview.chromium.org/8353025

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107839 0039d316-1c4b-4281-b951-d872f2087c98

BUG=chromium:101435
TEST=manual


Review URL: http://codereview.chromium.org/8413050

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107838 0039d316-1c4b-4281-b951-d872f2087c98

This fixes the bug where you're able to click on the wrench of panels whose originating extension has been unloaded, resulting in a crash.

BUG=101118
TEST=PanelBrowserTest.NonExtensionDomainPanelsCloseOnUninstall


Review URL: http://codereview.chromium.org/8387010

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107837 0039d316-1c4b-4281-b951-d872f2087c98

Fix history importing by delaying DownloadManager creation. Replace GetNextIdThunkType with DownloadIdFactory (RefCountedThreadSafe, created by DownloadService).

DownloadService uses the same DownloadIdFactory for an OTR profile as its original profile.

DownloadService passes the DownloadIdFactory into the DownloadManager so that the DownloadManager can allocate new valid ids for items loaded from the history or downloads started on the ui thread.

Since the DownloadService precedes and outlives its DownloadManager, DownloadManager does not have a scoped_refptr<DownloadIdFactory>. Objects that do have a scoped_refptr<DownloadIdFactory>: DownloadService, ProfileIOData, ShellBrowserContext, ShellResourceContext.

The DownloadIdFactory must be RefCountedThreadSafe because ProfileIOData outlives Profile and because it's used in both the OTR and original profiles.

Longer term, the import process should strictly precede profile initialization, and the next_download_id counter should be loaded from the History db strictly before DownloadService is created and creates a DownloadIdFactory.

BUG=98966

Review URL: http://codereview.chromium.org/8401001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107836 0039d316-1c4b-4281-b951-d872f2087c98

BUG=102161

Review URL: http://codereview.chromium.org/8414031

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107835 0039d316-1c4b-4281-b951-d872f2087c98

BUG=chromium-os:18457
TEST=None


Review URL: http://codereview.chromium.org/8413026

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107834 0039d316-1c4b-4281-b951-d872f2087c98

TBR=alicet
Review URL: http://codereview.chromium.org/8418042

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107833 0039d316-1c4b-4281-b951-d872f2087c98

propagated correctly.

BUG=ChromeFrame tests should now pass on IE8.
TBR=robertshield
Review URL: http://codereview.chromium.org/8418041

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107832 0039d316-1c4b-4281-b951-d872f2087c98

TBR=eroman

Review URL: http://codereview.chromium.org/8400079

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107830 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107829 0039d316-1c4b-4281-b951-d872f2087c98

Revert 107810 (The NetInternalsDNSView tests are timeout out and causing bots to go red) - Roll webkit 98723:98752

TBR=caseq
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/8343072

TBR=johnnyg@chromium.org
Review URL: http://codereview.chromium.org/8343076

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107828 0039d316-1c4b-4281-b951-d872f2087c98

where a new AutomationResourceMessageFilter instance was created for a render view/render process id
combination. This happens typically on IE8 and above where new windows could go into a different IE process.

BUG=none
TBR=robertshield
Review URL: http://codereview.chromium.org/8414038

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107827 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none
TEST=none
Review URL: http://codereview.chromium.org/8413052

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107824 0039d316-1c4b-4281-b951-d872f2087c98

This makes BrowserNonClientFrameViewAura's translucent gray
background always stick out a bit beyond the sides and
bottom of windows, instead of just peeking out when the user
hovers for resizing.

I originally added a separate view for this, but it looked
strange since Chrome already draws a shadow along the top of
the tab strip.

BUG=101977
TEST=manual

Review URL: http://codereview.chromium.org/8343066

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107823 0039d316-1c4b-4281-b951-d872f2087c98

Converted top-level NewRunnableMethod and straggler NewRunnableFunction usage to Bind for Sync module

BUG=102167
TEST=unit_tests/regression


Review URL: http://codereview.chromium.org/8341117

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107822 0039d316-1c4b-4281-b951-d872f2087c98

BUG=98322
TEST=None


Review URL: http://codereview.chromium.org/8319008

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107821 0039d316-1c4b-4281-b951-d872f2087c98

If we failed to startup, Stop() doesn't get called, so ensure we cleanup up 
properly in StartDoneImpl.

BUG=102009
TEST=unit_tests


Review URL: http://codereview.chromium.org/8341091

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107820 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none
TEST=none


Review URL: http://codereview.chromium.org/8418026

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107819 0039d316-1c4b-4281-b951-d872f2087c98

I've tested this using all combinations of field trials (both naturally
selected as well as forced through the --instant-field-trial commandline
switch), and everything works as expected.

BUG=101930
TEST=Clicking on the label text should turn the checkbox on/off.


Review URL: http://codereview.chromium.org/8400044

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107818 0039d316-1c4b-4281-b951-d872f2087c98

- Cleanup TabRendererGtk::PaintIcon so select which surface we should paint and
  instead of copy/pasting the same code in each block.
- When calling any version of GtkThemeService::GetCached*, don't first get the
  pixbuf (which can lock) and then check if you have a cairo cached version of
  the pixbuf, discarding the result of locking every time except the first.

BUG=100803
TEST=none


Review URL: http://codereview.chromium.org/8341089

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107817 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: http://codereview.chromium.org/8370022

TBR=brettw@chromium.org
Review URL: http://codereview.chromium.org/8413057

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107816 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: http://codereview.chromium.org/8370022

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107815 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: http://codereview.chromium.org/8368018

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107814 0039d316-1c4b-4281-b951-d872f2087c98

This also adds a trace_analyzer::TraceEvent class that can be constructed from JSON data (via base::Value). TraceEvent mirrors base::debug::TraceEvent in a form that is lower performance and easier to use in test code.

BUG=95714
TEST=base_unittests

Review URL: http://codereview.chromium.org/7981004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107813 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: http://codereview.chromium.org/8399019

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107812 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107811 0039d316-1c4b-4281-b951-d872f2087c98

TBR=caseq
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/8343072

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107810 0039d316-1c4b-4281-b951-d872f2087c98

Currently, each widget's tooltip-manager listens to every single X event in the system, all the time. This can get expensive as the number of windows increase. Instead of doing this, the change here makes a TooltipManagerViews only listen to the mouse-events on the corresponding Widget. It starts its timer when the mouse enters the widget, and stops the timer when the mouse leaves the widget. So at a single time, only one TooltipManagerViews will be activated, and looking to update the its tooltip.

BUG=97249
TEST=none

Review URL: http://codereview.chromium.org/8417025

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107809 0039d316-1c4b-4281-b951-d872f2087c98

User callbacks are run in separate tasks posted by the pipelining code. If the
user closes their stream before the task runs, we shouldn't try to call the
stale callback.

BUG=101936
TEST=net_unittests


Review URL: http://codereview.chromium.org/8414010

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107808 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: http://codereview.chromium.org/8400043

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107807 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: http://codereview.chromium.org/8414032

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107806 0039d316-1c4b-4281-b951-d872f2087c98

This should make it somewhat easier to figure out which FATAL log line
fired, in the face of inlining and branching.

BUG=none
TEST=monitor crashes.


Review URL: http://codereview.chromium.org/8401018

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107805 0039d316-1c4b-4281-b951-d872f2087c98

Move PageZoom enum into content/public/common and into the content namespace. Also move content_costants to content/public/common.

BUG=98716
Review URL: http://codereview.chromium.org/8413051

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107804 0039d316-1c4b-4281-b951-d872f2087c98

BUG=101456
TEST=Select Minimum in the margins dropdown.

Review URL: http://codereview.chromium.org/8392012

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107803 0039d316-1c4b-4281-b951-d872f2087c98

BUG=chromium-os:22024
TEST=compiles, tests pass.
Review URL: http://codereview.chromium.org/8417009

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107802 0039d316-1c4b-4281-b951-d872f2087c98

When the preview is finally shown in these field trials, the dropdown will
always be closed, so this may help avoid some flicker.

In the process, change IsHiddenExperiment() to include the SILENT experiment
(helps eliminate some calls).

BUG=none
TEST=none


Review URL: http://codereview.chromium.org/8400068

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107801 0039d316-1c4b-4281-b951-d872f2087c98

BUG=98145
TEST=Start not signed in to sync, and install an app with the 'experimental'
permission. Then visit a page in the app which calls
chrome.app.experimental.getNotificationChannel({clientId:"foo"}) - you should
get an infobar asking you to sign in.


Review URL: http://codereview.chromium.org/8400027

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107800 0039d316-1c4b-4281-b951-d872f2087c98

Support is now controlled by the flag:
--enable-tracking
and the default is always on.  To turn it off, use:
--enable-tracking=0

All profiler code is compiled now in release and official
builds (in addition to debug, where it was already active),
but most entry points can be disabled (turned into no-ops) 
by a single const bool setting atop tracked_objects.cc (in 
case folks want to revert the perf-impact of this change).

Transition to faster Now() service on Windows for the 
profiler use only.
The TimeTicks::Now() function on Window uses locking
to get a 64 bit time value.  This CL transitions 
times used for profiling to more directly use a
32 bit Time interface, which is actually what drives the
64 bit TimeTicks.  By using the smaller value, we avoid 
the need for locks, or even atomic operations for the most
part in the tracking system.  On linux, we just down-sample
the standard TimeTicks to 32 bits for consistency (clean
ability to snapshot asyncronously without atomics...
but I should verify that such is helpful to performance).

I've also put in yet more cleanup and refactoring.

r=rtenneti
bug=101856
Review URL: http://codereview.chromium.org/8391019

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8400073

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107799 0039d316-1c4b-4281-b951-d872f2087c98

Only redraw the entire tabstrip if we're animating or are dragging a
tab. Otherwise we can fast path and only draw all the tabs to the left of the
dirty rectangle and still get the correct stacking behaviour.

BUG=100803
TEST=all tab functionality should work without artifacts.


Review URL: http://codereview.chromium.org/8414004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107798 0039d316-1c4b-4281-b951-d872f2087c98