GitLab

BUG=441485

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

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

When unplugging an external display the WindowTreeHost is destroyed, destroying
the window and stopping the capture. However the compositor is destroyed before
the window in the WindowTreeHost destructor.

This change add an extra check that the compositor is valid before dereferencing.

BUG=441747
TEST=on link_freon unplugging external display does not result in crash when
running desktopCapture example against the external display

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

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

The initial commit was in 42f9c67b. The difference is:
- Left out testing/buildbot/chromium.win.json since it caused
  http://crbug.com/441690 and more investigation is needed.

TBR=jochen@chromium.org
R=jam@chromium.org
BUG=98637

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

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

It appears that this fixes the issue where rendered contents wouldn't
appear on the screen. I say "it appears" because this bug is very
difficult to repro, and so I can never say it's actually gone, just
that I wasn't able to make it happen anymore.

I can come up with a line of reasoning that the glBegin/End causes
the driver to go and validate its internal state. Perhaps sometimes the
dirty bit for the FBO is missed (and doing the glBegin/End immediately
after changing the FBO ensure it's picked up). Ultimately it is just a
guess.

This workaround was discovered by accident through the following
sequence of steps when debugging:
1. Draw a triangle to the CAOpenGLLayer after drawing the texture, to
   ensure that we are actually getting draw calls
   - This appeared and kept updating even when the texture stopped
     updating
2. Draw a triangle to the FBO's texture from the CAOpenGLLayer's
   context, to make sure changes to the texture would go through
   - This appeared and kept updating even when the textures topped
     updating (so it's probably a problem with the command buffer
     context).
3. Draw a triangle to the FBO's texture from the command buffer's
   context just before glSwapBuffers
   - This triangle never appeared, so I tried the next experiment.
4. Draw a triangle to the FBO's texture right after it is bound using
   glBindFramebufferEXT
   - Suddenly the bug went away (and I never saw the triangle, because
     it was drawn over).
5. Just do a glBegin/End with program 0, since we found this was enough to
   work around driver bugs in the past.
   - Still couldn't repro the bug with this.

BUG=435786

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

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

BUG=440101

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

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

This CL adds efficient access to read-only properties of a device.
The properties thus accessible are:
- build_description
- build_fingerprint
- build_id
- build_product
- build_type
- build_version_sdk (returns a number)
- product_cpu_abi
- product_model
- product_name

These properties are required to eliminate the need of some accesses to
android_commands through device.old_interface.

Other properties can still be accessed (and cached if requested), using
DeviceUtils.GetProp.

BUG=267773

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

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

https://codereview.chromium.org/795053006/ added support for
EGLClientBuffer to work around dma_buf issues and also we
have support to export the buffer to dma_buf handle. This
conflicts with the DCHECK in bufferfactory.

BUG=434115

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

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

DCHECK() that it was not launched with DisableSandbox().

The utility process is used for sandboxed image decoding
(and probably only that) on Android.

BUG=396568
NOTRY=True

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

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

R=lcwu@chromium.org,byungchul@chromium.org
BUG=None

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

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

After CL: https://codereview.chromium.org/369703002, Android
WebView just has a NULL SSLHostStateDelegate. So it does not remember
any user decisions on SSL errors. This is a regression of behavior from
L (m37).

History:
JB behavior: Larger error codes are assumed to have higher severity. And
if the user has allowed an SSL error with a high severity, the user
won't be prompted for a lower severity SSL error.

K and L behavior: A specific SSL error will be allowed only if the error
bit field is a subset of previously allowed error codes.

trunk behavior for webview (without this patch): We don't remember
user's decision at all.

This CL:
Maintain the same behavior with K and L.

BUG=441065

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

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

This implements, behind a flag, fill on account select in the password
manager. When the --enable-fill-on-account-select flag is used (or set
in chrome://flags), instead of autofilling on page load, the password
manager will mark fields as "autofilled" that it believes it can
appropriately autofill, but it will wait until the user has selected
those fields manually and chooses the appropriate account before filling
them in.

There are two main advantages to this approach. The first is that it
raises the bar for attackers with XSS's to sites in harvesting
passwords. These attackers will not be able to rely on a mere user
gesture before the field is filled; the user now must explicitly choose
the account before it fills. Secondly, it has the possibility of
improving the browsing experience on sites where the password manager
fails to fill correctly, as it won't actually fill until the user
chooses to do so, so if it tries to fill a wrong field, they user will
simply not choose an account.

The most basic part of this CL is quite straightforward in that if the flag is
enabled, it simply stops, marks the fields as autofilled, and does not actually
fill the fields with the credentials. However, there is a more complicated
corner case: forms where the username is not editable, but the password field
is, such as google.com/accounts after a user has logged in once. For these
cases, it was necessary to add additional logic so that the *password* field
can be clicked and the credentials can be selected. This requires a new IPC and
some new autofill plumbing to change the dropdown menu, which was added in a
previous CL, while this CL sets the appropriate option in the IPC.

BUG=410963

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

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

BUG=440079
R=teravest

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

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

BUG=440572

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

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

R=charliemooney@chromium.org
BUG=none
TEST=easier to scan code

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

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

Windows API makes it possible to impersonate access token of the last
process that called CloseClipboard(). Chromoting calls it from a system
process, so it has to impersonate anonymous token before calling
CloseClipboard().

BUG=441834

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

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

Renamed old Aura TouchSelectionController in ui/base to
TouchEditingControllerDeprecated and also the corresponding factory
class to TouchEditingControllerFactory. In addition to preventing name
conflict with the new unified TouchSelectionController, the names match
better with the file name (touch_editing_controller).

BUG=399721

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

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

This quick fix is designed to make trunk more stable and to be easy to apply and revert as needed.

BUG=438951
TBR=vabr@chromium.org

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

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

This patch unintentionally also changed behavior of the Chrome Apps
Notification API. Revert for now, and figure out whether we should
actually want this.

BUG=366098, 440256

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

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

For all event devices, we'll use the device path to find out if it's
permanently attached. Expose this property on EventConverterEvdev and
use it when populating DeviceDataManager.

TEST=chrome on link_freon & rush_ryu
BUG=437539

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

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

Summary of changes available at:
https://chromium.googlesource.com/chromium/blink/+log/293e0e5..923676f

TBR=lushnikov@chromium.org,vsevik@chromium.org,dglazkov@chromium.org

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

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

Aura expects these to be the same, so just use location() everywhere.

This shouldn't affect anything because although we were passing along
screen location inside root_location(), Event::UpdateForRootTransform
sets it back to the transformed location(). So no code actually saw our
screen location.

BUG=none
TEST=unit tests, manual on link_freon with 2 monitors

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

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

We're dispatching to WindowTreeHost in the wrong space. Looks like the
transform is generally identity in tests, but let's still make sure to
use the right space.

BUG=none
TEST=interactive_ui_tests in chromeos ozone build

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

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

BUG=428869

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

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

Track the total time a download takes, including network and server
overhead.

BUG=436134

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

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

This removes the only caller of WebDataSource::triggeringEventTime(),
which is transient data we probably shouldn't be stashing on a long-lived class anyway.

BUG=

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

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

net: remove eldietista.es from HSTS list by request of owner.
Cr-Commit-Position: refs/heads/master@{#308144}

The CL fixes the problem where the touchpad physical clicks become
right clicks when the mouse primary button is swapped.

Contributed by sheckylin@chromium.org

BUG=440932
TEST=link_freon ChromeOS build

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

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

That class doesn't really need to be ref-counted externally. There is one
catch: the caller is responsible for ensuring ClientCertStore is alive for the
duration of its async operation.

Resolve this by detaching it into a ref-counted Core internal to
SSLClientAuthHandler. Add a test to test this case.

Also make ContentBrowserClient's default client auth hook always select no
certificate so content_shell doesn't hang.

This relands the rest of https://codereview.chromium.org/596873002

BUG=439134

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

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

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

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

https://chromium.googlesource.com/angle/angle/+log/16545669136028420f67..797ff4c0ecf1b4950f694817

BUG=440701

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

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

BUG=

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

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

BUG=441757
TBR=dbeam@chromium.org
NOTRY=true

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

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

WeakPtrFactory members should always be last so that they invalidate WeakPtrs prior to other destructors running. These are mostly trivial/mechanical ones.

(We'll also need https://codereview.chromium.org/795003003/, which I split out)

BUG=303818
TBR=rockot,vitalybuka,cbentzel,shess,dmazzoni,stanisc,sky,tim,mathp,benjhayden,kinuko,scottmg,sergeyu,zork,ddorwin

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

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

This changes the way category filter processes multi-categories groups.
Previously, adding a disabled-by-default- category to a regular category
would prevent the event from matching filter if only regular category
is enabled. This is somewhat counter-intuitive, the expected behavior
is that each category is processed by the filter independently. The new
logic is:

1. if at least one category in event category group matches at
least one category enabled in the filter, the event passes;

2. if at least one category in event category group matches at least
one category explicitly excluded in the filter, the event is
filtered out;

3. the event is passed by default, if included categories list is empty
and event has at least one category that is not disabled-by-default-.

Note no existing tests were modified (though I'm not sure if (2) should
be the way it is).

BUG=

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

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

This is the implementation for the following steps of the register
algorithm[1]:

    'If the webapp is already registered, run the following substeps:
     1. Retrieve the push registration associated with the webapp.
     2. If there is an error, reject promise with a DOMException whose
        name is "AbortError" and terminate these steps.
     3. When the request has been completed, resolve promise with a
        PushRegistration providing the details of the retrieved push
        registration.'

Currently the implementation assumes that errors can be recovered from
and attempts to do a fresh push registration if accessing storage
fails; I left a TODO for us to decide this case later.

Depends on https://codereview.chromium.org/785983002

[1]: https://w3c.github.io/push-api/#widl-PushRegistrationManager-register-Promise-PushRegistration

BUG=401422,429212

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

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

Move serving_dirs to UserStorySet, delete Page.archive_path (instead using PageSet.WprFilePathForUserStory).
Update user_story_runner to no longer gate archive-specific logic with instanceof PageSet check.

BUG=439512

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

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

Also, remove the 'set noparent'; that was probably useful when
build/OWNERS had a wildcard, but it doesn't any more.

R=brettw@chromium.org
BUG=

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

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

As per review comments on the issue
https://codereview.chromium.org/573553004/#msg3
removing HistoryService::profile() method.

BUG=430070

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

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

Add power.lock_screen_dim_delay_ms and
power.lock_screen_off_delay_ms prefs that provide alternate
screen-dim and screen-off inactivity delays that are honored
while the screen is locked. They currently default to 30 and
40 seconds, respectively.

BUG=190499

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

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

Summary of changes available at:
https://chromium.googlesource.com/skia/+log/0ac8c78..a60b2ea

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

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

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