GitLab

Failed WebRtcBrowserTest on android_dbg_triggered_tests.

> Switch to BoringSSL.
> 
> (This is a reland of r283542 which was reverted in r283591 because it
> broke the WebView build. The android_aosp trybots are broken[1] so this
> based on hope.)
> 
> This is a much larger change than its diff suggests. If it breaks
> something, please revert first and ask questions later.
> 
> [1] http://code.google.com/p/chromium/issues/detail?id=394597
> 
> BUG=none
> 
> Review URL: https://codereview.chromium.org/399993002

TBR=agl@chromium.org

Review URL: https://codereview.chromium.org/405503002

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

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

http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=178352:178380&mode=html
TBR=abarth@chromium.org,johnme@chromium.org,eseidel@chromium.org
BUG=

Review URL: https://codereview.chromium.org/400703004

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

This modifies the eviction order to consider occlusion so that the
LayerEvictionTileIterator and TileManager::EvictionTileIterator will
evict occluded tiles before unoccluded tiles in the same priority bin.

The current eviction order is to evict tiles that are:
1. In a lower priority bin
2. Not required for activation
3. At worse resolution
4. Farther away from visible

This patch adds occlusion to the order to evict tiles that are:
1. In a lower priority bin
2. Not required for activation
3. At worse resolution
4. Occluded
5. Farther away from visible

This patch depends on https://codereview.chromium.org/374653003/ which
tracks occlusion per tree and stores the info on the Tile.

BUG=178971

Review URL: https://codereview.chromium.org/377793003

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

BUG=392678

Review URL: https://codereview.chromium.org/386043006

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

Moves all code remaining in sync/notifier to components/invalidation.
Updates gyp files, DEPS, and #includes accordingly.

In terms of program behavior, this should be one big no-op.  This CL
contains no non-trivial code changes.

In terms of the build system, this is a significant change.  Symbols
that were previously exported through sync_notifier and related targets
have moved into the components/invalidation related targets.  Some
SYNC_EXPORT macros have been replaced with INVALIDATION_EXPORT, which is
significant since INVALIDATION_EXPORT is currently a no-op but
SYNC_EXPORT has meaning under some build configurations.

Unlike most other files in sync/notifier, invalidation_util.{cc,h} was
moved to sync/internal_api/public/base.  This is so it could be
referenced from sync/internal_api/public/base/invalidation.cc.  This is
a slight regression, but it should be fixed in the next CL when we move
all invalidations-related code out of sync/internal_api.

TBR=rogerta,benwells
BUG=259559

Review URL: https://codereview.chromium.org/387733004

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

This is necessary to handle context menu , popup menu etc.

BUG=380438

Review URL: https://codereview.chromium.org/396813003

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

BUG=354841
NOTRY=True

Review URL: https://codereview.chromium.org/395133006

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

There are situations where the pdf plugin will initialize itself in such a way
that it never notifies content/renderer/ that it has started. In so doing, it
also fails to send a stop message, since it tries to ensure it doesn't send
mismatched start/stop messages.

Print preview decides when to display the preview based on when loading
stops. Since this only considers the page's content and not the pdf plugin's
initialization, there is a race condition where we may try to preview before
the plugin is ready. In this cases, we show "Loading preivew..." and never load
the actual preview.

There is a hack in place in print_preview_web_helper.cc to delay the process of
showing the preview to maximize the chance that the pdf plugin will be ready.
This change should allow us to rip that out.

BUG=376969

Review URL: https://codereview.chromium.org/397713005

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

If I type an exact query that I issued before, SearchProvider shouldn't
offer an extension to the autocompletion, even if that I issued that longer
query more recently.  This is counter to user's expectations: if I issued
the query before and type it again and hit enter, I should get that query.

I do not plan to bother running an experiment for this change.

BUG=246411

Review URL: https://codereview.chromium.org/397723003

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

BUG=

Review URL: https://codereview.chromium.org/353063005

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

BUG=394627
R=zea@chromium.org

Review URL: https://codereview.chromium.org/395413002

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

Demonstrate in the NaCl SDK API demo for pp::Graphics2D how
to use full device resolution on HiDPI displays. For Graphics2D,
the example now calls pp::View::GetDeviceScale(), and creates
a Graphics 2D context with the correct number of pixels, as well
as show when to call pp::Graphics2D::SetScale().

It also scales the mouse position to the correct location and
increases the radius of the circle created in DrawMouse() to match.

BUG=144071,392557
TEST=Build NaCl SDK, run with --force-device-scale-factor=2

Review URL: https://codereview.chromium.org/397173003

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

This also fixes a bug caused by registering for notifications in all profiles instead of just our own.

BUG=394158,354046

Review URL: https://codereview.chromium.org/399603002

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

change_ids are more trouble then they are worth. I'm going to try
something else for resolving conflicts.

BUG=389339
TEST=covered by tests
R=ben@chromium.org

Review URL: https://codereview.chromium.org/397263004

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

Based on existing LSan suppression from
  https://codereview.chromium.org/63153007

BUG=318221
R=earthdok@chromium.org
TBR=earthdok@chromium.org
NOTRY=true

Review URL: https://codereview.chromium.org/399893004

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

BUG=346958

Review URL: https://codereview.chromium.org/402663002

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

selection_requestor.h

BUG=367549
TEST=None
R=derat
TBR=dcheng,sky (for trivial changes to clipboard_aurax11.cc and os_exchange_data_provider_aurax11.cc)

Review URL: https://codereview.chromium.org/396813004

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

ConvertSkiatoRGBA in png_coder.cc calls gfx::ConvertSkiaToRGBA.
It's little bit confusing.

For readability sake,
I change ConvertSkiatoRGBA to ConvertSkiaToRGBA.

BUG=NONE
TEST=gfx_unittests --gtest_filter="PNGCodec*"

Review URL: https://codereview.chromium.org/396133002

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

We should have the same handling regardless of whether the 'mode' member is
NotifyGrab or NotifyUngrab. According to
http://tronche.com/gui/x/xlib/events/input-focus/grab.html, whether the mode
field is NotifyGrab or NotifyUngrab depends on whether there is a new
capturer for the keyboard. The X window has lost keyboard capture in both cases.

BUG=392480
TEST=None

Review URL: https://codereview.chromium.org/379773003

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

Previously the fake input stream is creating a new thread to pump the callbacks, this is unnecessary and FakeAudioInputStream::Stop() might take time to stop the thread. I suspect that this is one of the potential causes for the timeout in WebRtc content browser tests on Android bots.

This patch changes the code to use AudioManager audio thread instead, hopefully this can reduce the flakiness on Android tests.
Also it changes |beep_lock| from a global lock to a lock used only by BeepContext privately.

BUG=387895
TEST=bots

Review URL: https://codereview.chromium.org/399623008

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

Port InsertHistoryAndBookmark and InsertSearchTerm to use
base::CancelableTaskTracker instead of CancelableRequestConsumer.

BUG=371818

Review URL: https://codereview.chromium.org/365133003

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

BUG=90057
R=thestig@chromium.org
TBR=thestig@chromium.org
NOTRY=true

Review URL: https://codereview.chromium.org/402713003

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

Make behavior uniform with other apps on Android, where after a copy from
an editable field, the insertion handle is hidden and only the cursor
remains visible.

BUG=394773

Review URL: https://codereview.chromium.org/394953005

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

BUG=367239

Review URL: https://codereview.chromium.org/387903003

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

Added "Net.QuicClientHelloRejectReasons" histogram to track 
the reject reason in UMA. Currently it tracks only reject 
reason. 

Once we have more data, will add the multiple reject reasons
to histograms.xml (instead of listing all potential 
combinations). We are guessing, that we would have few 
failures due to multiple errors.

R=jar@chromium.org, rch@chromium.org, asvitkine@chromium.org, wtc@chromium.org

Review URL: https://codereview.chromium.org/342863005

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

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

It removes erase operations for SkBitmaps
which touch whole inside pixels
since all pixels should be drawn fully.

Additionally, it removes a unused function, CreateSuperimposedBitmap().

BUG=NONE
TEST=gfx_unittests --gtest_filter="SkBitmapOperationsTest*"

Review URL: https://codereview.chromium.org/394183002

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

(This is a reland of r283542 which was reverted in r283591 because it
broke the WebView build. The android_aosp trybots are broken[1] so this
based on hope.)

This is a much larger change than its diff suggests. If it breaks
something, please revert first and ask questions later.

[1] http://code.google.com/p/chromium/issues/detail?id=394597

BUG=none

Review URL: https://codereview.chromium.org/399993002

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

The default implementation (CastServiceSimple) starts up a single page
passed in on the command line.

R=damienv@chromium.org,lcwu@chromium.org,jam@chromium.org
BUG=336640

Review URL: https://codereview.chromium.org/397143003

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

Revert of Added wrapper test class for touch_exploration_controller. (https://codereview.chromium.org/386043002/)

Reason for revert:
Causes LSAN errors on CrOS: http://build.chromium.org/p/chromium.memory/builders/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%283%29/builds/2299/steps/ui_unittests/logs/DoubleTap

e.g.
Indirect leak of 2904 byte(s) in 1 object(s) allocated from:
    #0 0x44edfb in operator new(unsigned long) /usr/local/google/work/chromium/src/third_party/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:55
    #1 0x9fbc47 in CreateStrategy ui/events/gesture_detection/velocity_tracker.cc:201
    #2 0x9fbc47 in ui::VelocityTracker::VelocityTracker(ui::VelocityTracker::Strategy) ui/events/gesture_detection/velocity_tracker.cc:234
    #3 0x9fa322 in ui::VelocityTrackerState::VelocityTrackerState() ui/events/gesture_detection/velocity_tracker_state.cc:18
    #4 0x9f5d64 in ui::GestureDetector::GestureDetector(ui::GestureDetector::Config const&, ui::GestureDetector::GestureListener*, ui::GestureDetector::DoubleTapListener*) ui/events/gesture_detection/gesture_detector.cc:191
    #5 0x1431ddf in GestureListenerImpl ui/events/gesture_detection/gesture_provider.cc:296
    #6 0x1431ddf in ui::GestureProvider::InitGestureDetectors(ui::GestureProvider::Config const&) ui/events/gesture_detection/gesture_provider.cc:629
    #7 0x142ebdd in ui::FilteredGestureProvider::FilteredGestureProvider(ui::GestureProvider::Config const&, ui::GestureProviderClient*) ui/events/gesture_detection/filtered_gesture_provider.cc:19
    #8 0x1410cd3 in ui::GestureProviderAura::GestureProviderAura(ui::GestureProviderAuraClient*) ui/events/gestures/gesture_provider_aura.cc:19
    #9 0x9e9bcd in ui::TouchExplorationController::TouchExplorationController(aura::Window*) ui/chromeos/touch_exploration_controller.cc:33
    #10 0x663c47 in ui::TouchExplorationTest::SwitchTouchExplorationMode(bool) ui/chromeos/touch_exploration_controller_unittest.cc:214
    #11 0x674532 in ui::TouchExplorationTest_DoubleTap_Test::TestBody() ui/chromeos/touch_exploration_controller_unittest.cc:563
    #12 0x7babc8 in HandleExceptionsInMethodIfSupported\u003Ctesting::Test, void> testing/gtest/src/gtest.cc:2045
    #13 0x7babc8 in testing::Test::Run() testing/gtest/src/gtest.cc:2061
    #14 0x7bcd08 in testing::TestInfo::Run() testing/gtest/src/gtest.cc:2237
    #15 0x7bda46 in testing::TestCase::Run() testing/gtest/src/gtest.cc:2344
    #16 0x7d072a in testing::internal::UnitTestImpl::RunAllTests() testing/gtest/src/gtest.cc:4065
    #17 0x7cfd70 in HandleExceptionsInMethodIfSupported\u003Ctesting::internal::UnitTestImpl, bool> testing/gtest/src/gtest.cc:2045
    #18 0x7cfd70 in testing::UnitTest::Run() testing/gtest/src/gtest.cc:3697
    #19 0x7770b4 in RUN_ALL_TESTS testing/gtest/include/gtest/gtest.h:2231
    #20 0x7770b4 in base::TestSuite::Run() base/test/test_suite.cc:227
    #21 0x76e0c1 in Run base/callback.h:401
    #22 0x76e0c1 in base::(anonymous namespace)::LaunchUnitTestsInternal(base::Callback\u003Cint ()> const&, int, bool, base::Callback\u003Cvoid ()> const&) base/test/launcher/unit_test_launcher.cc:498
    #23 0x76da5c in base::LaunchUnitTests(int, char**, base::Callback\u003Cint ()> const&) base/test/launcher/unit_test_launcher.cc:553
    #24 0x59cfaa in main ui/base/test/run_all_unittests.cc:105
    #25 0x7fd0195b276c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226

Original issue's description:
> Added wrapper test class for touch_exploration_controller.
> Wrapper class is currently located in the unittest file and is a friend of touch_exploration_controller.
> 
> BUG=377040
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=283741

TBR=aboxhall@chromium.org,dmazzoni@chromium.org,evy@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=377040

Review URL: https://codereview.chromium.org/404473006

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

Watching for new hid devices is racy because the hidraw device rules are
still running. Fix the race by explicitly waiting for the hidraw device
add event. The properties needed from the hid device can be gotten by
fetching the parent of the hidraw device from the sysfs tree.

BUG=394200

Review URL: https://codereview.chromium.org/396993010

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

WebApp code was deleted here:
https://codereview.chromium.org/19746

WebIntents code was deleted here:
https://codereview.chromium.org/22407016/
https://codereview.chromium.org/12225076/

BUG=241909

Review URL: https://codereview.chromium.org/382703002

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

Since we're already including the HTTP response code as a field in the report,
don't bother including the specific error code in the status as well.

BUG=

Review URL: https://codereview.chromium.org/398173003

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

tests.

Until now, setting up password manager python tests is
complicated and doesn't fit the requirement of the test
bots. This cl allows to make running and configuring of the
tests much easier for the bots.

BUG=393531

Review URL: https://codereview.chromium.org/386423002

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

Password Autofill is supposed to be a convenience. If it creates a
blocking dialog, it is no longer convenient. The original intention of
password Autofill was that it would only prompt the user after a full
username was typed in. Until that behavior is implemented, never prompt the
user for keychain access.

Effectively, this means that passwords stored by Chrome still work, since
Chrome can access those without a prompt, but passwords stored by Safari,
Firefox, or Chrome Canary will not work. Note that the latest build of Safari
and Firefox don't create keychain items with the relevant tags anyways.

BUG=178358

Review URL: https://codereview.chromium.org/386043005

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

The home-card can be in a minimized state. In this state, only a narrow line
is displayed at the bottom of the screen, and dragging it up shows the overview
mode. When a window is selected in the overview mode, the home-card is minimized
again.

BUG=381224
R=mukai@chromium.org, oshima@chromium.org

Previously landed in r283539, reverted in r283564 because it broke tests.

Review URL: https://codereview.chromium.org/394043002

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

BUG=388289

Review URL: https://codereview.chromium.org/393583002

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

This broke Chrome OS valgrind bots, for example:
http://build.chromium.org/p/chromium.memory.fyi/builders/Chromium%20OS%20%28valgrind%29%284%29/builds/27033

> Refactor code that defers extension background page loading
> 
> src/extensions depends on chrome::NOTIFICATION_PROFILE_CREATED to support deferred loading of extension background pages when the profile isn't ready yet. This is a layering violation.
> 
> * Remove Chrome concepts like "browser window ready" and "profile created" from ProcessManager. Introduce ProcessManagerDelegate with a general concept of deferring background page loading.
> * Consolidate all the tricky Chrome-specific background page loading rules into ChromeProcessManagerDelegate. This keeps all the rules in one place. Annotate each block of special case code with the bug that inspired it.
> * Extend unit test coverage for ProcessManager.
> 
> This will make it easier to eliminate chrome::NOTIFICATION_PROFILE_DESTROYED in ProcessManager in a later CL.
> 
> BUG=392658
> TEST=unit_tests ProcessManagerTest, browser_tests ProcessManagerBrowserTest, manual
> 
> Review URL: https://codereview.chromium.org/381283002

TBR=jamescook@chromium.org

Review URL: https://codereview.chromium.org/399153002

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

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