GitLab

in the getrealpan flow.

Also, switch to using RealPanClient instead of fake card numbers (meaning we can not demo the UI until getrealpan works).

BUG=451286

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

Cr-Commit-Position: refs/heads/master@{#314369}

Disable RepostFormWarningTest#testFormResubmissionCancel and RepostFormWarningTest#testFormResubmissionContinue since they're flaky.

BUG=454834
TBR=ppi

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

Cr-Commit-Position: refs/heads/master@{#314368}

This also removed the code from content, which doesn't belong there because it's for a feature in Chrome.

In order to implement this in a unified way, I needed to create a public interface around ChildThread. A lot of the change is updating callers of ChildThread to use ChildThreadImpl instead.

BUG=448473

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

Cr-Commit-Position: refs/heads/master@{#314367}

Also remove references to deleted BrowserMainTest.

BUG=139429

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

Cr-Commit-Position: refs/heads/master@{#314366}

R=ckehoe@chromium.org, timurrrr@chromium.org
BUG=449198

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

Cr-Commit-Position: refs/heads/master@{#314365}

This patch lets the task queue manager run more than one posted task
per invocation. This helps reduce the overhead of yielding to and from
the main message loop and can speed up cases where tasks are posted
very frequently. One example is indexeddb, where some operations such as
index building can result in 2500 posted tasks/s (Nexus 7).

This patch also adds accounting for the desired run time of the next
pending delayed task. This information is used to break out of a work
batch if a delayed task should be run instead. Doing this avoids adding
extra delay to delayed tasks.

A potential downside of this change is that it can penalize work that
runs on the message loop without going through the task queue manager.
Based on performance tests[1], almost all tasks on the renderer main
thread are already getting executed by the task queue manager, so I
believe this change shouldn't cause a regression.

Note that this version of the patch still uses a batch size of 1 while
we investigate some mac test failures triggered by larger batch sizes.

[1] https://docs.google.com/a/chromium.org/spreadsheets/d/1IJZpBabW1pr4fb2T8BlkleHcOvHYrjvmCx_dLesxfMA/edit#gid=1492760051

BUG=444764,451593,453898

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

Cr-Commit-Position: refs/heads/master@{#314364}

BUG=449675
TEST=zha@, sgabriel@ manually checked on devices (1x, 2x)

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

Cr-Commit-Position: refs/heads/master@{#314363}

If the device manufacturer is Samsung, skip the check for mmap
exec support.  This avoids triggering a warning on some devices.

See also:
  https://codereview.chromium.org/869593002/
  https://codereview.chromium.org/858983002/
  https://codereview.chromium.org/857833002/

BUG=448084

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

Cr-Commit-Position: refs/heads/master@{#314362}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#314361}

Extension host closed notifications are sent from the original profile (never
the incognito profile). Use the original profile when listening for these
notifications.

BUG=454320

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

Cr-Commit-Position: refs/heads/master@{#314360}

WebUI should override the default Blink style for buttons so that buttons can be rendered with the correct font.

BUG=448624
TEST=manually checked on devices (Pixel)

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

Cr-Commit-Position: refs/heads/master@{#314359}

BUG=454481

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

Cr-Commit-Position: refs/heads/master@{#314358}

Now that the migration of the tracing files is completed and all the
tracing clients have been updated to point to base/trace_event/,
it is safe to remove the forwarding headers from the old location.
The only purpose of those headers, in fact, was to handle the renames
in smaller CLs.
The only thing left, at this point, is gradually renaming the
namespaces, which is going to be handled in the upcoming CLs.

See crrev.com/837303004 and the related bug for motivations.

BUG=451032
TBR=jam@chromium.org,sky@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#314357}

This CL makes sure following scenarios work properly on mac/linux/cros/win:
1. Dragging and dropping within a <webview> works
2. Dragging from one <webview> to another <webview> works.
3. Dragging from one <webview> and cancelling it by releasing mouse
  on non-droppable target works where there can be 3 cases:
    a. the release is done within the same <webview>
    b. the release is done within a different <webview>
    c. the release is done outside of any <webview>, i.e. the embedder.

The key fix here is to call guest RVH->DragSourceSystemDragEnded() correctly
on the guest where the drag was initiated. Calling DragSourceSystemDragEnded()
correctly means we call it in all cases and also make sure we only call it once.
This ensures that the input state of the guest stays correct, otherwise it will go
stale and won't accept any further input events.

The strategy I've used to call DragSourceSystemDragEnded() on a guest RVH when
the following conditions are met:
a. Embedder has seen SystemDragEnded()
b. Embedder has seen DragSourceEndedAt()
c. The guest has seen some drag status update other than WebDragStatusUnknown.

Note that c) should ideally be done differently: The guest has seen at least one of
{WebDragStatusOver, WebDragStatusDrop}. However, if a user drags a source
quickly outside of <webview> bounds, then the BrowserPluginGuest never sees
any of these drag status updates.

BUG=450175
Test=
1) On webview based signin page, try dragging some text from the signin page to user name field, it should now work.
2) Load a chrome app with two <webview>s
e.g. https://github.com/lazyboy/chromium/tree/master/tests/chrome-apps/webview_input
Now see there are two <webview>s, one red and one blue, perform following and expect things to work correctly:

a. select and drag text from red webview, e.g. "this is guest", to an tex box within the same webview, expect it to insert that text to the <input> box.
b. now do the same as a), but drag it to the text box within the second/blue <webview>, expect that text to be inserted.
c. select and drag text from red <webview>, drag it but stay within the red <webview> and release it somewhere where there's no text box, expect the drag operation to be cancelled properly, make sure you can still type in the text box of that <webview>.
d. do the same as c) but release it somewhere in the blue <webview> where there's no input box, expect the same, make sure you can type in both <webview>'s input box.
e. do the same as c), but release it somewhere in the app where there's no input box (white background), expect the same and make sure you can type in both <webview>'s input box.

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

Cr-Commit-Position: refs/heads/master@{#314356}

For saved autofill profiles, use the associated language code when retrieving
address ui components. For new autofill profiles, save the best language code
tag returned from libaddressinput's BuildUiComponents.

BUG=454034

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

Cr-Commit-Position: refs/heads/master@{#314355}

Summary of changes available at:
https://chromium.googlesource.com/skia/+log/532faa9..4c93a12

CQ_EXTRA_TRYBOTS=tryserver.blink:linux_blink_rel,linux_blink_dbg
TBR=stephana@google.com

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

Cr-Commit-Position: refs/heads/master@{#314354}

R=arv@chromium.org
BUG=454776

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

Cr-Commit-Position: refs/heads/master@{#314353}

Since the popup close process is asynchronous, it's possible that the popup
doesn't close by the time the platform delegate is deleted. If that's the
case, we need to be sure to close it, so that we do our cleanup (like
removing ourselves as an observer).

BUG=454361

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

Cr-Commit-Position: refs/heads/master@{#314352}

The current infobar/bubble doesn't work well with the text message and help link
for protected media identifier permission request. With this CL, we'll show the
existing platform verification modal UI when using
ProtectedMediaIdentifierPermissionContext on ChromeOS.

When we have an agreement on how to use the current infobar/bubble for protected
media identifier permission request on ChromeOS, we can revert this CL.

BUG=446263

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

Cr-Commit-Position: refs/heads/master@{#314351}

BUG=453835

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

Cr-Commit-Position: refs/heads/master@{#314350}

TBR=earthdok@chromium.org
NOTRY=true
BUG=446256

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

Cr-Commit-Position: refs/heads/master@{#314349}

This changes the internal function GetPlatformKeysOfExtension to always pass a PlatformKeys value to its callback.
The only function change is: If the base::Value read from StateStore has an incorrect type, it will be ignored and a new empty (but correct) value will be created.

BUG=450167

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

Cr-Commit-Position: refs/heads/master@{#314348}

The |report_session_status| and |device_status_frequency| policies
were added on the server side in violation of our protocol:
Policies must always be added to the client-side proto first and
synced to the server.

In general, new policies should be added to the device policy proto
and policy_templates.json at the same time. As an emergency fix, this
CL gets a free pass for that rule as it is an emergency fix.

BUG=430908
TEST=None

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

Cr-Commit-Position: refs/heads/master@{#314347}

This CL adds |device_heartbeat_settings| to the device policy proto.
We accidentally added |device_heartbeat_settings| with index 34 on
the server and |reboot_on_shutdown| with the same index on the client.
To resolve this conflict, one of the two settings needs to change
index. Since |device_heartbeat_settings| is not being read or written
by anyone yet, it is the one to move.

We must avoid such conflicts in the future by adding all policies on
the client-side first and syncing the resulting proto to the server.

In general, new policies should be added to the device policy proto
and policy_templates.json at the same time. As an emergency fix, this
CL gets a free pass for that rule as it is an emergency fix.

BUG=430908
TEST=None

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

Cr-Commit-Position: refs/heads/master@{#314346}

The value of the option is simply passed down to WaitUntilFullyBooted
when block=True.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#314345}

Contains fixes for error message creation.

https://chromium.googlesource.com/angle/angle/+log/bc393d..592ab9

BUG=454520

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

Cr-Commit-Position: refs/heads/master@{#314344}

BUG=170587, 170592
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#314343}

Summary of changes:
https://chromium.googlesource.com/android_tools/+log/aaeda3d..f6e2370

BUG=427718

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

Cr-Commit-Position: refs/heads/master@{#314342}

Now that we have access to the IO thread, pass the IO task runner to
the main thread and use that to register and listen for page flip
events.

BUG=none

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

Cr-Commit-Position: refs/heads/master@{#314341}

Changes in wizard_controller.cc - chromeos namespace usage cleanup.

BUG=454801
TEST=existing browser tests + manual test with --test-auto-update-ui

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

Cr-Commit-Position: refs/heads/master@{#314340}

BUG=451075

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

Cr-Commit-Position: refs/heads/master@{#314339}

Move the chrome.diagnostics extension API from chrome/ to
extensions/.

BUG=395240

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

Cr-Commit-Position: refs/heads/master@{#314338}

R=estade@chromium.org
BUG=421816

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

Cr-Commit-Position: refs/heads/master@{#314337}

Make it possible to use cr for building on mac. Mostly this is a clone of what
we are doing on Linux, except that I had to work around "readlink -e" not being
available.

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

Cr-Commit-Position: refs/heads/master@{#314336}

BUG=454562
TEST=Manual, see bug

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

Cr-Commit-Position: refs/heads/master@{#314335}

The locale parameter (hl=) has been broken by the componentization of
web_resource, and is now always empty.
This CL restores the right behavior.

BUG=454485

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

Cr-Commit-Position: refs/heads/master@{#314334}

This patch adds an extra dependency on content.gyp:content_browser
to browser_app_shim in order to generate permission_status.mojom.h
before compile.

BUG=454447

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

Cr-Commit-Position: refs/heads/master@{#314333}

Summary of changes available at:
https://chromium.googlesource.com/skia/+log/fef4c32..532faa9

CQ_EXTRA_TRYBOTS=tryserver.blink:linux_blink_rel,linux_blink_dbg
TBR=stephana@google.com

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

Cr-Commit-Position: refs/heads/master@{#314332}

R=asvitkine@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#314331}

If a device is disabled, it should show the disabled screen and not
start any sessions. Regular sessions, auto-launch for public sessions
and auto-launch for consumer kiosk mode respected this. Auto-launch
for enterprise kiosk mode takes a different code path that had
slipped through the cracks. The effect was that single-app kiosk mode
would auto-launch even if a device was disabled.

BUG=454005
TEST=New browser test

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

Cr-Commit-Position: refs/heads/master@{#314330}