GitLab

NOTRY=true
BUG=335455
TBR=nduca

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

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

On Android, resize event caused by showing/hiding top controls may be
expensive and cause janky fling if it is sent before the end of fling.
Let the browser know the end of fling so that the browser can delay the
resize event.

As we have not resolved the issue of raciness between the main thread
and the compositor thread, and between the renderer process and the
browser process, about the sequence of fling events and notifications,
for now we don't use the notification to update the fling status in
ContentViewGestureHandler and GestureEventFilter.

The DidStopFlinging notification is sent along the following path:

- Renderer side:
  - compositor-thread-flinging:
      InputHandlerProxy::CancelCurrentFling()
   -> InputHandlerWrapper::DidStopFlinging()
   -> InputHandlerManager::DidStopFlinging()
   -> InputEventFilter::DidStopFlinging()
   -> IPC::Sender::Send(ViewHostMsg_DidStopFlinging)

  - main-thread-flinging (existing except the steps same as compositor-thread-flinging):
      WebViewImpl::endActiveFlingAnimation()
   -> RenderWidgetCompositor::didStopFlinging()
   -> LayerTreeHost::didStopFlinging()
   -> ThreadProxy::MainThreadHasStoppedFlinging()
   -> LayerTreeHostImpl::MainThreadHasStoppedFlinging()
   -> InputHandlerProxy::MainThreadHasStoppedFlinging()
   then same as compositor-thread-flinging[1:]

- Browser side:
     RenderWidgetHostImpl::OnMessageReceived(ViewHostMsg_DidStopFlinging)
  -> RenderWidgetHostImpl::OnFlingingStopped()
     // Android only. No-op on other platforms
  -> RenderWidgetHostViewAndroid::DidStopFlinging()
  -> ContentViewCoreImpl::DidStopFlinging()
  -> ContentViewCore.onNativeFlingStopped() // Java
  -> ContentViewClient.onFlingStopped()
  then downstream embedder code

BUG=244736

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

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

Platform libraries may return non-null function pointers from dlsym or
getProcAddress for unsupported GL functions. Previously the function
binding logic tried to address this with a separate extension function
binding step, but since some of the bindings were still done without
consulting the extension string, this failed to account for some
conflicts between core and extension functions such as
glDiscardFramebufferEXT vs. glInvalidateFramebuffer.

Fix this by binding all functions that have multiple versions only after
the context has been made current, and consulting the extension and
version strings. The logic for binding each function is now only in one
place in the generated code and easy to follow.

The patch still does not guarantee that the function pointers would be
set to null if the function is unsupported. It only attempts to guarantee
that an incorrect version of a function is not bound in case another
version is supported. The patch is conservative like this to avoid
requiring the exact specification of binding conditions in case a function
only has one name, and to make it less likely to expose bugs elsewhere.

GetGLCoreProcAddress and GetGLProcAddress are combined into one function,
which always first looks for the function pointer with dlsym and then
with GetProcAddress. The new conditions for binding make sure that this
does not result in errors.

The patched bindings do not query for incorrect OES or ARB extension
strings without the GL_ prefix. Including the incorrect extension strings
without the prefix is assumed to have been a mistake. This applies to
OES_get_program_binary, OES_vertex_array_object, ARB_get_program_binary,
ARB_vertex_array_object, and APPLE_vertex_array_object.

BUG=322489
TEST=gpu_unittests, cc_unittests, WebGL conformance tests

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

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

BUG=134249

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

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

BUG=333499
TEST=none
R=oshima@chromium.org

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

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

BUG=333038

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

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

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

http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=165318:165326&mode=html
TBR=
BUG=

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

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

We're experimenting with using values other than 0 or 1 to control coverage
granularity.

BUG=324216
TBR=glider@chromium.org

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

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

Before this, we fail create a main thread shared context if there are no
webviews in hardware initialized mode. The future plan is for
accelerated 2d canvas and webgl to use a shared context with the gpu
thread service, but keep inline video using the ui thread service.

Currently only video uses main thread context for webview, so for now,
only gate context creation for main video on having a
hardware-initalized webview. This makes turning on accelerated canvas
more convenient.

BUG=332146

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

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

This contains a stub Privet file system, behind a flag.

BUG=332182

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

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

Min granularity was still not being calculated right. Fix it again and add a unit test.

BUG=268300

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

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

The general rule is that touch editing handles should fade out when they
are dismissed, unless handles and text are moving relative to each
other. So, handles fade out except in following cases, in which they
disappear almost immediately (i.e. they fade out super quickly):
- When handle is dragged out of content view. In this case it should
  actually scroll the contents, but that's a separate issue (see
  crbug.com/269003);
- When starting touch scrolling or gesture navigation.

BUG=313561

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

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

Test that the proper languages and keyboards are displayed at OOBE for
each supported region.

BUG=327034
NOTRY=True

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

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

Replaces a DCHECK with parse error when parsing a WebM
cluster that has no timecode. This supplements the existing
WebMClusterParser::OnBlock() logic that similarly indicates
parse error when processing blocks. However, if there were
no blocks in the cluster, then the DCHECK could have been
hit if there were no timecode.

R=acolwell@chromium.org
BUG=335344
TEST=(local Linux) All media_unittests pass including the new ones

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

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

R=sky@chromium.org

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

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

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

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

Don't hook up Init()/Shutdown() to our test harnesses yet, because
things blow up (we currently have singletons that will hold handles
across tests).

R=sky@chromium.org

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

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

R=sky@chromium.org
BUG=121242
TEST=visual test

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

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

Go back to KeystoneRegistration.framework 1.1.0.3659. The new registration
framework 1.2.0.6782, when using -[KSRegistration
checkForUpdateWasUserInitiated:YES], is not compatible with an older installed
Keystone version such as the current 1.1.0.3973. This results in the About
page showing "Update failed (error: 11)" and this message being printed to
stderr:

ksadmin: unrecognized option `--user-initiated'

In this case, updating is not broken, and Keystone will continue to update
Chrome in the background, but no indication of update availability will be
made in Chrome’s about page.

> Update KeystoneRegistration.framework to 1.2.0.6782.
> 
> The big change in this version is that an installation attempt initiated by
> the application can show up as ondemand on the server. This will allow us to
> provide throttled Mac downloads (such as a "5% push") with correct behavior.
> 
> BUG=35495
> R=thakis@chromium.org
> 
> Review URL: https://codereview.chromium.org/141193002

BUG=35495
TBR=mark@chromium.org

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

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

Previously this was ignored in the GN build but disabling the plugin is used on some buildbots.

BUG=http://crbug.com/330298
R=thakis@chromium.org, thakis

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

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

BUG=332167

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

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

This broke after switching the fetching of plugin stream data to the plugin process because now the data from ResourceDispatcher is passed directly to the plugin and it's read-only.

BUG=308466
R=ananta@chromium.org

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

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

R=scottmg@chromium.org

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

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

users.

In Google Chrome-branded builds, show an infobar at startup to users with
32-bit-only systems, and add a message to the about page for those users
advising that automatic updates will soon stop because the system
configuration is about to become unsupported.

A provision is made to change this message to an "end-of-the-line" message for
the final 32-bit-compatible build. When this switch is flipped, the autoupdate
status and promotion button on the about page will be hidden. The
"end-of-the-line" message will appear there, alongside the icon normally used
for failed updates. The startup infobar text will change at that point as
well.

No observable changes for non-branded Chromium builds (since they're not
receiving updates through this mechanism) or for users with 64-bit-capable
systems (because they're not being obsoleted).

R=arv@chromium.org, thakis@chromium.org, thakis
BUG=303280,331810,331830

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

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

BUG=330709,178409
TBR=glider@chromium.org,eugenis@chromium.org

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

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

sky@ please look at the files in chrome/browser for owner approval.

Long term, the idea is to unify several updaters in Chrome, so having a specific namespace could help avoiding name conflicts.

Short term, the change reduces some naming verbosity in the implementation but makes the call site names longer, so it is a wash.

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

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

Without this, GYP will fail if you manually specify gomadir in your GYP_DEFINES.

R=jamesr@chromium.org, jamesr

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

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

R=scottmg@chromium.org, scottmg

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

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

Feedback API is in split mode, so without the parameter, the event may
get sent to a wrong profile.

BUG=334590

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

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

Using cc frames for now which should fix the bots. Also removing error to fix the perf-bots. I'll enable once I examine manually that all bots are working.

BUG=335610
TBR=ernstm@chromium.org
NOTRY=true

No-try since I've tested locally and this will fix the win perf bots.

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

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

Rather than using the (now-obsolete) version in platform/android. Once
this lands, we can delete the android stub.

R=jamesr@chromium.org
BUG=none

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

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

"Get Started" was replaced by the new first-run UI.

BUG=319963

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

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

This test is not possible with ubercomp, which is always on in aura.
So disable the test. It should just go away entirely once all platforms
are using ubercomp.

R=piman
BUG=272379,270918

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

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

This was causing linux_aura single-process browser tests to crash since
they don't set up a default X error handler. When the compositor is
shutting down it does a finish and this might try to swap to the X
window.

Also change the windows shutdown ordering to match.

R=ben, enne
BUG=270918

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=245028

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

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

Previously, the Chrome OS SAML login flow was passing the LSID obtained
via /ServiceLogin to /GetUserInfo in order to retrieve the authenticated
user's e-mail address. It turns out that this is wrong because
/ServiceLogin yields a browser LSID and /GetUserInfo expects a
programmatic LSID. In many cases, the two LSID flavors are identical and
the existing code worked. But under some conditions, the browser LSID
could be different, causing /GetUserInfo to fail.

This CL switches to /ListAccounts instead, which handles browser LSIDs.
An additional advantage of /ListAccounts is that it will read the LSID
from cookies, removing the need to extract the LSID from the cookie jar
explicitly.

I could have further simplified the code by doing an XHR to /ListAccounts
from the JS code of the auth extension, avoiding the JS -> C++ -> JS round
trip. However, this would have been a CORS request, requiring the GAIA
URL to be hard-coded in the auth extension's manifest. The implementation
in this CL, which makes the /ListAccounts call from C++, is more flexible
as it preserves the ability to change the GAIA URL via a command-line
flag.

BUG=332132
TEST=Updated browser test and manual

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

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

BUG=
NOTRY=True

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

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

BUG=None
NOTRY=true

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

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

We should take into account the font scale factor the user has chosen
when drawing text in the WebView.

(Also fixes presubmit warnings in AwSettings.java)

BUG=335343

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

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

BUG=329993
TBR=cpu@chromium.org
NOTRY=true

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

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