- 24 Jul, 2013 19 commits
-
-
sidharthms@chromium.org authored
EnterNotify and LeaveNotify events will be dispatched to event handlers. BUG=263220 Review URL: https://chromiumcodereview.appspot.com/19664007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213308 0039d316-1c4b-4281-b951-d872f2087c98
-
rlarocque@chromium.org authored
Compile failed on buildbot: http://build.chromium.org/p/chromium.win/buildstatus?builder=Win%20Builder%20%28dbg%29&number=18573 > Add the tracing manager > > BUG=248357 > > Review URL: https://chromiumcodereview.appspot.com/19762005 TBR=zork@chromium.org Review URL: https://codereview.chromium.org/19471017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213307 0039d316-1c4b-4281-b951-d872f2087c98
-
miu@chromium.org authored
The Google Test templates provide a default value printer function that naively dumps all bytes in the range [&object, &object + sizeof(object)). However, due to the memory layout of the TestScenario class (on some platforms), there was a hole of uninitialized memory being read from; and this triggered Valgrind errors. The solution here is to implement an ostream& operator<<(ostream&, const TestScenario&) function that will not read from uninitialized memory regions. BUG=263315 Review URL: https://chromiumcodereview.appspot.com/19647013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213304 0039d316-1c4b-4281-b951-d872f2087c98
-
gab@chromium.org authored
BUG=179830, 262796, 263548 Review URL: https://chromiumcodereview.appspot.com/19477008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213303 0039d316-1c4b-4281-b951-d872f2087c98
-
boliu@chromium.org authored
Inside OnDraw, RequestDrawGL can fail and return false, which means there will not be a follow up DrawGL call to actually trigger the draw, but the FallbackTick is cancelled anyway. Fix by moving the cancel inside DrawSWInteral to reflect we only want to cancel when we actually draw. BUG=internal b/9978808 NOTRY=true Review URL: https://chromiumcodereview.appspot.com/19509007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213302 0039d316-1c4b-4281-b951-d872f2087c98
-
zork@chromium.org authored
BUG=248357 Review URL: https://chromiumcodereview.appspot.com/19762005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213299 0039d316-1c4b-4281-b951-d872f2087c98
-
mukai@chromium.org authored
This method is called when a window is maximized or fullscreen. The first attempt was reverted due to a test failure in LauncherTooltipManagerTest, and it turns out that's because the observer method is not emitted correctly. BUG=249509 TBR=harrym@chromium.org, jamescook@chromium.org TEST=manually Review URL: https://chromiumcodereview.appspot.com/20056003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213298 0039d316-1c4b-4281-b951-d872f2087c98
-
danakj@chromium.org authored
When a CopyResult provides a TextureMailbox, the ReleaseCallback must be called on the TextureMailbox when then client is done with the CopyResult. This change ensures that this happens. If the TextureMailbox is never removed from the CopyResult, then the CopyResult destructor takes care of it. Since the texture was never used, it uses a sync point of 0. When the TextureMailbox is removed from the CopyResult, then RWHVAura makes sure it calls the ReleaseCallback once it has the pixels it needs in memory. Since the pixels are already available on the CPU, it can use a sync point of 0 as well. R=piman BUG=263483 Review URL: https://chromiumcodereview.appspot.com/19990007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213297 0039d316-1c4b-4281-b951-d872f2087c98
-
rsesek@chromium.org authored
BUG=242290 R=mark@chromium.org Review URL: https://chromiumcodereview.appspot.com/19960008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213294 0039d316-1c4b-4281-b951-d872f2087c98
-
tonyg@chromium.org authored
BUG=None NOTRY=True Review URL: https://chromiumcodereview.appspot.com/19925002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213293 0039d316-1c4b-4281-b951-d872f2087c98
-
jennyz@chromium.org authored
BUG=175796 TBR=jamescook Review URL: https://chromiumcodereview.appspot.com/19744003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213292 0039d316-1c4b-4281-b951-d872f2087c98
-
dtu@chromium.org authored
Quick fix for now, but I may need to reconsider how run_measurement resolved name conflicts. BUG=263511 TEST=None. R=tonyg@chromium.org Review URL: https://chromiumcodereview.appspot.com/19915008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213290 0039d316-1c4b-4281-b951-d872f2087c98
-
asanka@chromium.org authored
Exposes POTENTIALLY_UNWANTED ClientDownloadResponse verdict from the SafeBrowsing service to ChromeDownloadManagerDelegate. Downloads for which this verdict is seen will be marked with the danger type DOWNLOAD_DANGER_TYPE_POTENTIALLY_UNWANTED. A dangerous download prompt will be displayed on the download shelf indicating that the download may make changes to the browser or system. Changes are for Windows only since the POTENTIALLY_UNWANTED signal is only implemented for Windows. BUG=262983 Review URL: https://chromiumcodereview.appspot.com/19863005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213289 0039d316-1c4b-4281-b951-d872f2087c98
-
petewil@chromium.org authored
Firstly, this uses more correct fields for displaying synced notifications. The Annotation field is better than the description or text fields in most cases. Secondly, this fixes some image fetch problems. I was using images from the expanded_notification section instead of the collapsed_notification section, and the schemaless URLs were being interpreted by the chrome code as UNC paths! I added a function to add a default schema of https: if none was provided to prevent the GURL code from thinking "//" meant a UNC path on windows. Thirdly, I noticed some changes to the server side protobuf that we were not in sync with, so I copied the new fields into the protobuf that we use. (This includes the annotation field). BUG=262303,247668 Review URL: https://chromiumcodereview.appspot.com/19771013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213288 0039d316-1c4b-4281-b951-d872f2087c98
-
jianli@chromium.org authored
This is the 1st patch to add progress bar notification support. It contains: 1) A new progress type is added and a new optional progress value is added. 2) NotificationView creates and adds a NotificationProgressbar child view. BUG=170924 TEST=manual test by creating a progress bar notification Review URL: https://chromiumcodereview.appspot.com/18662006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213287 0039d316-1c4b-4281-b951-d872f2087c98
-
earthdok@chromium.org authored
Fixes memory leak in PrintPreviewDialogControllerUnitTest.* (unit_tests). R=thestig@chromium.org BUG=176888 Review URL: https://chromiumcodereview.appspot.com/19714003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213286 0039d316-1c4b-4281-b951-d872f2087c98
-
kkania@chromium.org authored
This is in preparation for switching from mongoose to net::HttpServer. BUG=none Review URL: https://chromiumcodereview.appspot.com/19616008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213285 0039d316-1c4b-4281-b951-d872f2087c98
-
joaodasilva@chromium.org authored
BUG=247435 Review URL: https://chromiumcodereview.appspot.com/19482020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213284 0039d316-1c4b-4281-b951-d872f2087c98
-
danakj@chromium.org authored
The SkColorFilter* we get in GLRenderer is a refcounted object with a reference on it. Since we just store it in a raw pointer, we leak that reference. Instead, store it in a RefPtr. R=senorblanco BUG=259815 Review URL: https://chromiumcodereview.appspot.com/19267024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213283 0039d316-1c4b-4281-b951-d872f2087c98
-
- 23 Jul, 2013 21 commits
-
-
gspencer@chromium.org authored
during unit tests. Submitting separately first so that try/cq servers can be used for the main CL () BUG=chromium:236093 TBR=cpu@chromium.org Review URL: https://codereview.chromium.org/19551005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213280 0039d316-1c4b-4281-b951-d872f2087c98
-
tonyg@chromium.org authored
This measurement reports the hottest functions during page load. I plan to run it over the top million sites. It works by loading each page twice, the profile is captured for the second load only. This is because cross-origin navigations cause the renderer to be swapped out during profiling and to get more stable results. This required a couple of core modifications: 1. csv_page_measurement_results should work when the page runner creates a dummy results object because discard_first_results is enabled. 2. discard_first_results should discard the first result of each page in the page set. Not just the first page. BUG=None Review URL: https://chromiumcodereview.appspot.com/19857003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213279 0039d316-1c4b-4281-b951-d872f2087c98
-
mathp@chromium.org authored
In certain cases, generates a suggestion object from the iframe params. BUG=None Review URL: https://chromiumcodereview.appspot.com/19803006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213278 0039d316-1c4b-4281-b951-d872f2087c98
-
noamsml@chromium.org authored
This implements the confirm request side of privet registration that sends an authenticated request to the cloud print server to claim the device. BUG=245375 Review URL: https://chromiumcodereview.appspot.com/19788004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213277 0039d316-1c4b-4281-b951-d872f2087c98
-
thestig@chromium.org authored
Review URL: https://chromiumcodereview.appspot.com/19626003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213276 0039d316-1c4b-4281-b951-d872f2087c98
-
shadi@chromium.org authored
BUG=249435 Review URL: https://chromiumcodereview.appspot.com/19482009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213275 0039d316-1c4b-4281-b951-d872f2087c98
-
lambroslambrou@chromium.org authored
This makes the method consistent with the other methods of HostNativeMessaging, and allows future flexibility to define error codes, instead of just passing a boolean to onDone(). BUG=249970 TEST=Verify host setup flow, with and without native messaging. Review URL: https://chromiumcodereview.appspot.com/17465007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213274 0039d316-1c4b-4281-b951-d872f2087c98
-
boliu@chromium.org authored
Restores state that matches ContextState::RestoreGlobalState with some exceptions. Also remove some unneeded states from MODE_DRAW. BUG= NOTRY=true Review URL: https://chromiumcodereview.appspot.com/19787007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213273 0039d316-1c4b-4281-b951-d872f2087c98
-
ajwong@chromium.org authored
Until this CL, TestingProfile had 3 distinct URLRequestContexts it would return to the user: one via profile->GetDefaultStoragePartition()->GetRequestContext(), one via profile->GetRequestContext(), and one via profile->GetResourceContext->GetRequestContext(). All of these had different cookie stores. This CL unified them so they all return the one from profile->GetDefaultStoragePartition()->GetRequestContext(). This correctly mimics how production code works. Doing this had a bunch of implications: (1) Removes TestingProfile::CreateRequestContext()/ResetRequestContext() (2) Changes MockRequestContext to share the URLRequestContext with TestingProfile. (3) TestingProfile now requires all BrowserThreads. Point (3) effectively adds TestBrowserThreadBundle into a bunch more spots. Because of that, we also have the following changes: (a) AshTestBase now has a TestBrowserThreadBundle (b) Removed a bunch of real threads from tests. (c) TemplateUrlService has reworked synchronization semantics. (d) Removed MultiThreadTestHelper. (e) Added TestingIOThread class + testing API in IOThread to mock out various IO thread tasks which enervated with the new TestBrowserThreadBundle. TBR=bauerb,brettw,isherman,joth,jyasskin,mattm,mmenke,mnissler,pkasting,rkc,rlp,satorux,tim,xians,joth BUG=159193 Review URL: https://chromiumcodereview.appspot.com/17127002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213272 0039d316-1c4b-4281-b951-d872f2087c98
-
jvoung@chromium.org authored
Demonstrate a canonical way to detect if the browser has support for NaCl/PNaCl in the SDK examples. Do the check before creating the embed tag, when the page loads. If the browser does not have support, do not create the embed and just update the status message. If NaCl is disabled in about:plugins, then this will show an error. If NaCl is not enabled in about:flags, then this will not show an error and continue loading. The embed tag will then either (a) be created for CWS apps or (b) show a puzzle piece for the open web. For PNaCl, the page will show an error and not attempt to create an embed tag if either NaCl is disabled in about:plugins, or PNaCl is disabled in about:flags. BUG=243040 NOTRY=true Review URL: https://chromiumcodereview.appspot.com/19751003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213271 0039d316-1c4b-4281-b951-d872f2087c98
-
danakj@chromium.org authored
These DCHECKs fire if we ever commit to the impl side twice without performing a draw in between. There are various ways that this could happen, and it doesn't really matter to the CopyOutputRequest code anyways, so remove the DCHECKs and deal with the case gracefully instead. Test: LayerTreeHostTestAsyncTwoReadbacksWithoutDraw BUG=263486 R=enne,piman Review URL: https://chromiumcodereview.appspot.com/19668008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213270 0039d316-1c4b-4281-b951-d872f2087c98
-
thestig@chromium.org authored
Review URL: https://chromiumcodereview.appspot.com/19647011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213269 0039d316-1c4b-4281-b951-d872f2087c98
-
jln@chromium.org authored
This enables a seccomp-bpf sandbox for NaCl on x86_64 and i386. This policy is a little bit less tight than Chromium's renderers policy and should be tightened in the future. BUG=168812 R=mseaborn@chromium.org Review URL: https://codereview.chromium.org/19980003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213268 0039d316-1c4b-4281-b951-d872f2087c98
-
gbillock@chromium.org authored
This is because any AV trigger needs to happen after the file is in its final location. R=kinuko@chromium.org, vandebo@chromium.org BUG=None Review URL: https://chromiumcodereview.appspot.com/18565002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213267 0039d316-1c4b-4281-b951-d872f2087c98
-
chrome-admin@google.com authored
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213264 0039d316-1c4b-4281-b951-d872f2087c98
-
cbiesinger@chromium.org authored
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=154770:154777&mode=html TBR= BUG= Review URL: https://codereview.chromium.org/20005005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213263 0039d316-1c4b-4281-b951-d872f2087c98
-
tommycli@chromium.org authored
HasPermissionsForFile and HasPermissionsForFilesystemFile is currently used as general bitmask-based permissions querying functions for files. This change deprecates those functions and adds some additional explicit grants and grant-checking methods instead. The larger goal is to deprecate all usage of PlatformFile bitmasks in ChildProcessSecurityPolicy in favor of explicitly granted permissions. This is to improve security and allow for a permissions set different than PlatformFile. See https://chromiumcodereview.appspot.com/18129002. Original post by vandebo: https://groups.google.com/a/chromium.org/d/msg/chromium-dev/2cGLolxsOs4/Ga8eF7iEejkJ BUG=262142 Review URL: https://chromiumcodereview.appspot.com/19599006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213262 0039d316-1c4b-4281-b951-d872f2087c98
-
hubbe@chromium.org authored
Third try for getting asynchrous readpixels to work everywhere. This is identical to: https://codereview.chromium.org/16831004/, but with the following fixes: OutOfProcessPPAPITests.Graphics3D (removed a check in query_tracker.cc) GLReadbackTest.ReadPixelsWithPBO (removed, no longer a valid test) GLReadbackTest.ReadPixelsWithPBOAndQuery (now uses the correct query) And, new in this CL: Disable asynchronous readpixels on macosx prior to 10.8, as it would seem that the GL_ARB_fence extension doesn't seem to work on any driver, and there are crashes in readpixel itself on intel drivers. The original CL only disabled the async readpixels path for intel drivers. BUG=258169 Review URL: https://chromiumcodereview.appspot.com/19579008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213261 0039d316-1c4b-4281-b951-d872f2087c98
-
yoz@chromium.org authored
Continuation of cleanup of chrome/ includes in extension.cc. BUG=162530 Review URL: https://chromiumcodereview.appspot.com/19547009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213260 0039d316-1c4b-4281-b951-d872f2087c98
-
mukai@chromium.org authored
This CL still keeps some of multi-workspace code, but they are a bit tough to test. BUG=259568 R=jamescook@chromium.org TEST=ash_unittests covers Review URL: https://chromiumcodereview.appspot.com/19460014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213259 0039d316-1c4b-4281-b951-d872f2087c98
-
joth@chromium.org authored
Final call into WebKit API ommitted as it depends on blink change https://codereview.chromium.org/19883002/ BUG=263263 Review URL: https://chromiumcodereview.appspot.com/19693016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213255 0039d316-1c4b-4281-b951-d872f2087c98
-