- 12 May, 2014 16 commits
-
-
eseidel@chromium.org authored
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=173842:173849&mode=html TBR= BUG= Review URL: https://codereview.chromium.org/277233003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269749 0039d316-1c4b-4281-b951-d872f2087c98
-
amogh.bihani@samsung.com authored
Vp9 codec is supported after KitKat (API level 19) Expectation values are modifed in the test case based on the Android sdk version HLS mime types are supported after Ice-cream sandwich (API level 14) A check for identifying android version is added which decides whether the mime type should be added in the media_map_ or not. Theora is not supported on Android. This check is also added in the "IsCodecSupportedOnAndroid". MediaCanPlayType test are re-enabled on android. BUG=357665 Review URL: https://codereview.chromium.org/230413003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269748 0039d316-1c4b-4281-b951-d872f2087c98
-
https://codereview.chromium.org/270453004/hamaji@chromium.org authored
Reason for revert: This broke our app. We do not understand why the breakage happened or why browser_tests could not catch this yet. However, as our app do not want this in M36, I'd revert this change without checking. BUG=372163 Original issue's description: > Pepper: Clean up ProgressEvent logic. > > This simplifies NexeLoadManager, which is getting pretty big. This also removes > an unused field from ProgressEvent, and adds a convenience function for posting > a task to dispatch a progress event from the main thread, which is often > necessary to ensure that progress events are posted to the DOM after other > state changes. > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=269362 TBR=dmichael@chromium.org,teravest@chromium.org NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/275403004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269747 0039d316-1c4b-4281-b951-d872f2087c98
-
creis@chromium.org authored
Add null checks where needed and ensure that the right type of entry is used for each use case. BUG=370863, 273710 TEST=See bug, comment 3 for repro steps. Review URL: https://codereview.chromium.org/273163003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269746 0039d316-1c4b-4281-b951-d872f2087c98
-
calamity@chromium.org authored
This CL changes the generation of bookmark apps to create an icon that consists of the favicon's dominant color as a background with the first letter of the app's domain painted over it. The letter is either black or white depending on the luminance of the background. This CL also turns on generation of 2x icons for 32 and 48 px icons. BUG=315632 Review URL: https://codereview.chromium.org/246333006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269745 0039d316-1c4b-4281-b951-d872f2087c98
-
jackhou@chromium.org authored
BUG=371689 Review URL: https://codereview.chromium.org/274633003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269744 0039d316-1c4b-4281-b951-d872f2087c98
-
vabr@chromium.org authored
Crashes on Win7, more info on the bug. TBRing the expected test owner. Your friendly tree sheriff. BUG=372277 TBR=michaelpg@chromium.org Review URL: https://codereview.chromium.org/281513002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269743 0039d316-1c4b-4281-b951-d872f2087c98
-
raymes@chromium.org authored
This adds the ability to fetch accessibility data from the plugin. It also adds a test for this function. BUG=303491 Review URL: https://codereview.chromium.org/265283005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269742 0039d316-1c4b-4281-b951-d872f2087c98
-
simonhong@chromium.org authored
Use OutputSurface::DidSwapBuffers() as the source of whether we swapped or not. R=brianderson@chromium.org BUG=363414 TEST=cc_unittests Review URL: https://codereview.chromium.org/246753008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269738 0039d316-1c4b-4281-b951-d872f2087c98
-
zhaoqin@google.com authored
TBR=bruening@chromium.org BUG=none Review URL: https://codereview.chromium.org/273393003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269737 0039d316-1c4b-4281-b951-d872f2087c98
-
zhaoqin@google.com authored
TBR=jam@chromium.org BUG=372254 Review URL: https://codereview.chromium.org/279133002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269736 0039d316-1c4b-4281-b951-d872f2087c98
-
gab@chromium.org authored
between Protected Preferences and unprotected Preferences. Migration from unprotected Preferences to Protected Preferences was previously done after both stores had been initialized. This was inherently incorrect as some operations (PrefHashFilter::FilterOnLoad) would occur before the values had been moved to the proper store. It also introduced a weird method in PrefHashFilter::MigrateValues which required an independent PrefHashFilter (backed by a copy of the real PrefHashStore). This after-the-fact migration caused Settings.TrackedPreferenceCleared spikes when changing a value from being enforced to not being enforced (as we'd have a MAC, but no value yet in this store when running FilterOnLoad()) and more importantly it also caused issue 365769 -- both of these issues highlight the incorrectness of the current approach. The migration back from Protected Preferences to unprotected Preferences when enforcement was disabled was using yet another mechanism which would only kick in when a given pref was written to (ref. old non-const SegregatedPrefStore::StoreForKey()). The new framework intercepts PrefFilter::FilterOnLoad() events for both stores and does the back-and-forth migration in place before it even hands them back to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the JsonPrefStores (so that they are agnostic to the migration; from their point of view their values were always in their store as they received it). Furthermore, this new framework will easily allow us to later move MACs out of Local State into their respective stores (which is a task on our radar which we currently have no easy way to accomplish). The new framework also handles read errors better. For example, it was previously possible for the unprotected->protected migration to result in data loss if the protected store was somehow read-only from a read error while the unprotected store wasn't -- resulting in an in-memory migration only flushed to disk in the store from which the value was deleted... The new framework handles those cases, preferring temporary data duplication over potential data loss (duplicated data is cleaned up once confirmation is obtained that the new authority for this data has been successfully written to disk -- it will even try again in following Chrome runs if it doesn't succeed in this one). Note: This CL helped LSAN discover an existing leak in post_task_and_reply_impl.cc, see issue 371974 for details. BUG=365769, 371974 TEST= A) Make sure all kTrackedPrefs consistently report Settings.TrackedPreferenceUnchanged across changes from various enforcement levels (using --force-fieldtrials). B) Make sure the prefs are properly migrated to their new store (and subsequently cleaned up from their old store) when changing the enforcement_level across multiple runs. C) Make sure prefs are properly migrated in a quick startup/shutdown with a new enforcement_level and that their old value is properly cleaned up in a subsequent startup at the same enforcement_level (or re-migrated at another enforcement_level). R=bauerb@chromium.org, robertshield@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org Initially Committed in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269346 Reverted in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269367 Committed again: https://src.chromium.org/viewvc/chrome?view=rev&revision=269415 Reverted again: https://src.chromium.org/viewvc/chrome?view=rev&revision=269438 Review URL: https://codereview.chromium.org/257003007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269735 0039d316-1c4b-4281-b951-d872f2087c98
-
sungmann.cho@navercorp.com authored
BUG=357776 Review URL: https://codereview.chromium.org/274313002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269734 0039d316-1c4b-4281-b951-d872f2087c98
-
chrome-admin@google.com authored
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269727 0039d316-1c4b-4281-b951-d872f2087c98
-
ojan@chromium.org authored
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=173823:173842&mode=html TBR= BUG= Review URL: https://codereview.chromium.org/276243002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269726 0039d316-1c4b-4281-b951-d872f2087c98
-
erikwright@chromium.org authored
BUG=365762 R=engedy@chromium.org, jochen@chromium.org, pkasting@chromium.org, zea@chromium.org Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=269396 Review URL: https://codereview.chromium.org/268643002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269725 0039d316-1c4b-4281-b951-d872f2087c98
-
- 11 May, 2014 24 commits
-
-
bokan@chromium.org authored
Added field allows Blink to properly restore pinch-zoomed page when using new "virtual viewport" mode of pinch. Dependent Blink patch: https://codereview.chromium.org/263853008 BUG=364112 Review URL: https://codereview.chromium.org/266673014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269724 0039d316-1c4b-4281-b951-d872f2087c98
-
erikwright@chromium.org authored
BUG=365762 R=pkasting@chromium.org Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=269310 Review URL: https://codereview.chromium.org/270533007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269723 0039d316-1c4b-4281-b951-d872f2087c98
-
ckocagil@chromium.org authored
Disable SigninErrorNotifierTest.AuthStatusEnumerateAllErrors and SigninErrorNotifierTest.ErrorAuthStatusProvider BUG=372236 TBR=michaelpg@chromium.org Review URL: https://codereview.chromium.org/279123002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269722 0039d316-1c4b-4281-b951-d872f2087c98
-
zhaoqin@google.com authored
TBR=bokan@chromium.org TEST=waterfall BUG=372226 Review URL: https://codereview.chromium.org/272403003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269717 0039d316-1c4b-4281-b951-d872f2087c98
-
erikwright@chromium.org authored
Handle TemplateURLService load failure better, and make some test correctness fixes that will be needed later. This also does a variety of miscellaneous cleanups to the modified files. BUG=364183 TEST=none R=jered@chromium.org, pkasting@chromium.org TBR=engedy Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=269329 Review URL: https://codereview.chromium.org/272573004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269716 0039d316-1c4b-4281-b951-d872f2087c98
-
siggi@chromium.org authored
missing from uploaded crashes. BUG=371817 Review URL: https://codereview.chromium.org/275213003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269715 0039d316-1c4b-4281-b951-d872f2087c98
-
ttuttle@chromium.org authored
BUG=356791 Review URL: https://codereview.chromium.org/238863005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269714 0039d316-1c4b-4281-b951-d872f2087c98
-
erikwright@chromium.org authored
This is already initialized by CocoaProfileTest. BUG=365762 TBR=asvitkine@chromium.org Review URL: https://codereview.chromium.org/276063003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269713 0039d316-1c4b-4281-b951-d872f2087c98
-
chrome-release@google.com authored
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269709 0039d316-1c4b-4281-b951-d872f2087c98
-
kqyang@chromium.org authored
BUG=367366 Review URL: https://codereview.chromium.org/263003003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269707 0039d316-1c4b-4281-b951-d872f2087c98
-
tfarina@chromium.org authored
Looks simpler that way instead of having the action that generates the pak file and the header files separated. BUG=None TEST=None R=jamescook@chromium.org,jochen@chromium.org Review URL: https://codereview.chromium.org/273783002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269706 0039d316-1c4b-4281-b951-d872f2087c98
-
fsamuel@chromium.org authored
BUG=364141, 330264 TBR=jamescook@chromium.org, michaelbai@chromium.org Review URL: https://codereview.chromium.org/261363002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269705 0039d316-1c4b-4281-b951-d872f2087c98
-
abarth@chromium.org authored
without having access to the core Mojo system. Currently the only reason these files depend on core is to get kInvalidHandle, but there's no such constant on the C++ side anymore. This CL replaces core.kInvalidHandle with |null| and teaches the handle converters how to convert null to and from an invalid handle. R=sky@chromium.org BUG=372065 Review URL: https://codereview.chromium.org/278093003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269704 0039d316-1c4b-4281-b951-d872f2087c98
-
kkimlabs@chromium.org authored
BUG=368034 Review URL: https://codereview.chromium.org/259863007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269703 0039d316-1c4b-4281-b951-d872f2087c98
-
ajuma@chromium.org authored
This reverts http://crrev.com/216313007. Re-rastering a layer with text during a scale animation can cause many texture uploads during the animation (as new glyphs are generated at each scale). To re-enable this behavior in the future, we need to either make it dependent on distance-field fonts, or we need a way to reuse glyphs during scale animations (allowing text to become slightly blurry rather than generating new glyphs every frame). BUG=366225 Review URL: https://codereview.chromium.org/272283003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269701 0039d316-1c4b-4281-b951-d872f2087c98
-
mgiuca@chromium.org authored
"Multiple display test does not work on Windows bots. Please skip (don't disable) the test using SupportsMultipleDisplays()" Previously, this message only showed on Windows 8 if you forget to check SupportsMultipleDisplays in a test with multiple displays. Now it shows on Windows 7 as well. Without this message, you get a much more confusing crash. BUG=370796 Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=268933 Review URL: https://codereview.chromium.org/270253003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269700 0039d316-1c4b-4281-b951-d872f2087c98
-
https://chromiumcodereview.appspot.com/275303003/iannucci@chromium.org authored
TBR=hinoka@chromium.org BUG= Review URL: https://codereview.chromium.org/275313003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269696 0039d316-1c4b-4281-b951-d872f2087c98
-
chrome-release@google.com authored
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269692 0039d316-1c4b-4281-b951-d872f2087c98
-
sdefresne@chromium.org authored
Nothing is used from favicon_service.h, so remove the include. BUG=371821 Review URL: https://codereview.chromium.org/278913002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269690 0039d316-1c4b-4281-b951-d872f2087c98
-
zhaoqin@google.com authored
TBR=bruening@chromium.org BUG=372177 Review URL: https://codereview.chromium.org/278193002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269689 0039d316-1c4b-4281-b951-d872f2087c98
-
mdempsky@chromium.org authored
Avoids releasing capture in EndMoveLoop if capture was switched to another window while dragging. This variant relies on checking if a drag input window still has capture before releasing the grab. A better alternative is in CL https://codereview.chromium.org/262893002/. TBR=sadrul@chromium.org BUG=363503 TEST=Follow the exact steps in the bug description. TEST=interactive_ui_tests --gtest_filter=*TabDragging* Review URL: https://codereview.chromium.org/272363002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269688 0039d316-1c4b-4281-b951-d872f2087c98
-
mmenke@chromium.org authored
BUG=362608 Review URL: https://codereview.chromium.org/274183002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269687 0039d316-1c4b-4281-b951-d872f2087c98
-
vabr@chromium.org authored
Introduce a BrowserContextKeyedService to collect logs from the PasswordManagerClient instances, and distribute them to PasswordManagerInternalsUI instances for display. The service will also ensure that nothing is logged in Incognito profiles, and that logs are flushed as soon as no one is displaying them. Except for checking the incognito bit, the whole functionality is implemented in the LogRouter class inside the password_manager component, for easy code sharing across platforms. The service inherits from LogRouter, and adds nothing except for leveraging the BrowserContextKeyedServiceFactory framework to keep the functionality from OTR profiles. This CL only introduces the service, it does not put it to use (outside tests) yet. For that there will be another CL (https://codereview.chromium.org/269513003, but WIP, not fit for (re)viewing yet). Yet another CL deals with renaming PasswordManagerLogger to LogReceiver: https://codereview.chromium.org/264793010/ Design doc: https://docs.google.com/document/d/1ArDhTo0w-8tOPiTwqM1gG6ZGqODo8UTpXlJjjnCNK4s/edit?usp=sharing#heading=h.cqh4wuj8j4yl BUG=347927 Review URL: https://codereview.chromium.org/262583007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269686 0039d316-1c4b-4281-b951-d872f2087c98
-
piman@chromium.org authored
This message can only affect RenderWidgetHostImpl::WaitForSurface, which is only called on Mac. However, it is never sent on mac. So just remove it. BUG=None Review URL: https://codereview.chromium.org/273113005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269685 0039d316-1c4b-4281-b951-d872f2087c98
-