GitLab

This allows significant cleanup of CSSCursorImageValue, so do that too.

Intent-thread:

 https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/r0lnh5Rw23M

TBR=timvolodine@chromium.org
BUG=650598

Review-Url: https://codereview.chromium.org/2522443002
Cr-Commit-Position: refs/heads/master@{#438116}

TBR=changwan@chromium.org

BUG=673588

Review-Url: https://codereview.chromium.org/2574713002
Cr-Commit-Position: refs/heads/master@{#438115}

We're deprecating DOMWindowProperty, which is now equivalent to ContextLifecycleObserver.
This CL replaces DOMWindowProperty with ContextLifecycleObserver in PresentationController.

BUG=610176

Review-Url: https://codereview.chromium.org/2569963003
Cr-Commit-Position: refs/heads/master@{#438114}

The test has been flaky on Linux/ChromeOS.

TBR=msramek@chromium.org

BUG=624836

Review-Url: https://codereview.chromium.org/2569083002
Cr-Commit-Position: refs/heads/master@{#438113}

Check each second for the loading of the page.
It must reach 25%, 50% then 75%.
If one test fails, load distilled version.

BUG=673658

Review-Url: https://codereview.chromium.org/2572583003
Cr-Commit-Position: refs/heads/master@{#438112}

And, also include noto-cjk

BUG=None
Test=None

Review-Url: https://codereview.chromium.org/2540343003
Cr-Commit-Position: refs/heads/master@{#438111}

Switch to implicit registration of prefinalizers along with removing
the ability to dynamically unregister a prefinalizer; the latter
being an unused feature.

The requirement to manually register a prefinalizer has proven to be
a chore and a source of bugs. Case in point: HTMLCanvasElement
currently declares a prefinalizer, but doesn't register it. Simplify
the programming model by automatically registering prefinalizers.

R=haraken
BUG=673645

Review-Url: https://codereview.chromium.org/2565983002
Cr-Commit-Position: refs/heads/master@{#438110}

This patch splits MockResourceClients into MockResourceClient and
MockImageResourceClient, because MemoryCacheTest and ResourceFetcherTest
just need MockResourceClient and do not want to depend on
MockImageResourceClient that has a dependency to ImageResource.

BUG=655920

Review-Url: https://codereview.chromium.org/2559703002
Cr-Commit-Position: refs/heads/master@{#438109}

The ScopedFocusNavigation class, which is used internally for
keeping state of traversing next/previous focusable element in a
scope, could become inconsistent state that the current element
of the scope does not point to the element that is being traversed.

Specifically, such situation happens when
nextElementWithGreaterTabIndex() and previousElementWithLowerTabIndex()
are called. These functions moves the current pointer within the
whole scope and when the function finishes, all elements are
exhausted and the current pointer will be null, while it can
return some element inside the scope.

Therefore, in findFocusableElementRecursivelyForward() and
findFocusableElementRecursivelyBackward(), both of which
has a loop

  while (found) {
    ...
  }

and inside the loop, the following pattern

  found= findFocusableElementInternal();
  continue;

can be affected by this inconsistency, because
findFocusableElementInternal() can end up calling those
problematic functions.

This CL also refactors the ScopedFocusNavigation class a bit,
to hide these traversal state within the class, and it now
exposes only "findFocusableElement(forward or backward)" API
for traversing.

BUG=671428

Review-Url: https://codereview.chromium.org/2562753003
Cr-Commit-Position: refs/heads/master@{#438108}

1. if transformList is the empty string,
 set in to the string "matrix(1, 0, 0, 1, 0, 0)".
2. Parse transformList by following the syntax description[1].
 if parsing failed, throw SyntaxError.
3. Set is2D to false if the <transform-list> consists of any 3D
 Transform functions. Otherwise set is2D to true.
4. Transform all <transform-function>s to 4x4 matrices.
5. Post-multiply all matrices from left to right.
6. Return the result of invoking create a matrix of type
 DOMMatrixReadOnly or DOMMatrix as appropriate.

spec list:
https://drafts.fxtf.org/geometry/#dom-dommatrix-dommatrix-transformlist
[1] = https://drafts.csswg.org/css-transforms-1/#svg-syntax

BUG=388780, 660819

Review-Url: https://codereview.chromium.org/2516973002
Cr-Commit-Position: refs/heads/master@{#438107}

exo: Produce an error if get_keyboard_device_configuration is called with a keyboard object that already is associated with a device configuration object.

BUG=670247

Review-Url: https://codereview.chromium.org/2567903003
Cr-Commit-Position: refs/heads/master@{#438106}

No generated code is changed
spec: https://dom.spec.whatwg.org/#interface-nondocumenttypechildnode

BUG=662005

Review-Url: https://codereview.chromium.org/2570433004
Cr-Commit-Position: refs/heads/master@{#438105}

Today, we accidentally add dynamically added inline stylesheets in the
navigator view. They are displayed as "(index)" styles, and bring in
confusion.

This patch makes sure we don't create a UISourceCode for stylesheet
unless it have a url.

BUG=none
R=dgozman

Review-Url: https://codereview.chromium.org/2565343003
Cr-Commit-Position: refs/heads/master@{#438104}

This is a preparation step for typed events, which will not inherit from Common.Event.

BUG=none

Review-Url: https://codereview.chromium.org/2562453003
Cr-Commit-Position: refs/heads/master@{#438103}

The function is unused now. It was used in PrerenderLocalPredictor before, which
was removed at http://crrev.com/325673.

BUG=none

Review-Url: https://codereview.chromium.org/2569763002
Cr-Commit-Position: refs/heads/master@{#438102}

This patch does two things:
- do not suggest SVG properties for non-svg nodes in StylesSidebarPane
- suggest only SVG properties for SVG nodes

BUG=389577
R=dgozman

Review-Url: https://codereview.chromium.org/2571713002
Cr-Commit-Position: refs/heads/master@{#438101}

Reland of https://codereview.chromium.org/2562643003/ after fixing the
issue.

BUG=577659

Review-Url: https://codereview.chromium.org/2573473002
Cr-Commit-Position: refs/heads/master@{#438100}

We rarely handle all attributes in a loop.
Instead, we have filters to iterate only on accessors,
on data type attributes, so on.
It is very confusing to have all attributes in a
variable in .py and filter them in .tmpl files.

This CL applies such filters in pre-process in .py
and uses more descriptive names in template contexts.
It keeps 'attributes' for some usages, which are
to be replaced.

This is a refactoring in template engine, so it
does not change generated code.

BUG=650150

Review-Url: https://codereview.chromium.org/2568403002
Cr-Commit-Position: refs/heads/master@{#438099}

BUG=635908

Review-Url: https://codereview.chromium.org/2566203002
Cr-Commit-Position: refs/heads/master@{#438098}

Reason for revert:
Test is no longer flaky.

Original issue's description:
> Disable flaky test
>
> ResourcePrefetchPredictorBrowserTest.LearningJavascriptAppendChild was
> detected to be flaky by chromium-try-flakes.
>
> TBR=lizeb@chromium.org
>
> BUG=673028
>
> Committed: https://crrev.com/8ae700640b7237af3acc10025827497be8376aab
> Cr-Commit-Position: refs/heads/master@{#437907}

TBR=asargent@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=673028

Review-Url: https://codereview.chromium.org/2575453002
Cr-Commit-Position: refs/heads/master@{#438097}

Chrome build fails when use_ozone is true.

R=sky@chromium.org, warx@chromium.org
BUG=496681

Review-Url: https://codereview.chromium.org/2562233002
Cr-Commit-Position: refs/heads/master@{#438096}

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

BUG=670836
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2552163003
Cr-Commit-Position: refs/heads/master@{#438094}

BUG=555132

Review-Url: https://codereview.chromium.org/2566873002
Cr-Commit-Position: refs/heads/master@{#438093}

These were added & used on the CrOS side, but not documented here.

BUG=599960

Review-Url: https://codereview.chromium.org/2572633002
Cr-Commit-Position: refs/heads/master@{#438092}

TBR=nasko@chromium.org,waffles@chromium.org
BUG=672652

Review-Url: https://codereview.chromium.org/2565853003
Cr-Commit-Position: refs/heads/master@{#438091}

FrameFetchContext is containing too many things. We'd like to slim it
down to hold basically only things that receive and handle notifications
from ResourceFetcher.

The methods for ClientHintsPreferences on FrameFetchContext is placed
there (I guess) just not to introduce dependencies from core/fetch to
core/loader, core/frame, etc. See
https://codereview.chromium.org/1189523015 which introduced this logic
initially.

----

Compatibility analysis:

It's safe to directly pass frame() to FrameClientHintsPreferencesContext
in FrameFetchContext::dispatchDidReceiveResponseInternal(). If the
passed ResourceFetcher is already clearContext()-ed, we never reach
dispatchDidReceiveResponseInternal(). So, we can assume that the
ResourceFetcher passed to updateFromAcceptClientHintsHeader() was
always not yet clearContext()-ed.

HttpEquiv::processHttpEquivAcceptCH() was passing document.fetcher()
to updateFromAcceptClientHintsHeader(). Document::m_fetcher is cleared
only in Document::shutdown(). Therefore, document.frame() being non-null
at the beginning of processHttpEquivAcceptCH() means that the Document
hasn't yet shutdown.

context().frame() call on document.fetcher() returns document.frame()
unless clearContext() was called. This is true even when
setImportsController() was called on the Document. This is clarified by
a separate CL https://codereview.chromium.org/2547843002/.

There're three callers of ResourceFetcher::clearContext(). One of them
is Document::shutdown(). So, we don't need to care it. The other cases
are:
- setImportsController() called by LinkImport::process() while
  Document::loader() is null
- DocumentLoader::detachFromFrame() was called

However, I think this behavior was not intended initially and was
introduced just accidentally as stated above.

R=yhirano@chromium.org
BUG=671533

Review-Url: https://codereview.chromium.org/2544933003
Cr-Commit-Position: refs/heads/master@{#438090}

Recast the conditionally-eager finalization of Animation objects - only
needed if the Animation object has a CompositorAnimationPlayer attached -
wrapping instead the player object inside an eagerly-finalized object.

By doing so, we remove the need to support explicit prefinalizer
registration.

R=haraken
BUG=673645

Review-Url: https://codereview.chromium.org/2570503002
Cr-Commit-Position: refs/heads/master@{#438089}

They're not doing anything specific to the ResourceFetcher but just
consulting the FrameFetchContext via ResourceFetcher. Especially,
didReceiveResponse() contains a lot of back calls to the ResourceLoader.
The logic should just be implemented inside the ResourceLoader.

defersLoading() is also removed since it's used only by the unit tests
and can be replaced by invocation of public method context().

Renamed unary didFail() to handleError() as it's not a WebURLLoaderImpl
implementation and therefore it's confusing that it has the "did"
prefix.

R=yhirano@chromium.org,japhet@chromium.org,tsepez@chromium.org,kinuko@chromium.org
BUG=669383

Review-Url: https://codereview.chromium.org/2533683002
Cr-Commit-Position: refs/heads/master@{#438088}

BUG=555132

Review-Url: https://codereview.chromium.org/2565173002
Cr-Commit-Position: refs/heads/master@{#438087}

Service executables don't live alongside other build artifacts, so in component builds
Windows doesn't normally know where to look for them at runtime. This overrides the
DLL search path temporarily before launching any service child process.

BUG=None
R=ben@chromium.org

Review-Url: https://codereview.chromium.org/2574653002
Cr-Commit-Position: refs/heads/master@{#438086}

Review-Url: https://codereview.chromium.org/2573673002
Cr-Commit-Position: refs/heads/master@{#438085}

BUG=669690
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2545243002
Cr-Commit-Position: refs/heads/master@{#438084}

Currently, ChromeVox sends all queued speech output to the speech panel.

This unfortunately causes performance issues.

For example, in Gmail, if ChromeVox sends ~500 utterances, which can happen if we have a large block of text (since we split on sentences), ChromeVox stops responding to key commands.

ChromeVox should stay responsive in any situation especially if a user taps on the control key repeatedly.

This change makes it so we only show the currently spoken text which gets around the potentially expensive calls to send text to the panel background page (which blocks).

BUG=672955
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2570593002
Cr-Commit-Position: refs/heads/master@{#438083}

- try to scroll to the view's bounding rectangle when a client requests make visible
- add switch as a checkbox (matched for that predicate)

BUG=673048

Review-Url: https://codereview.chromium.org/2572573002
Cr-Commit-Position: refs/heads/master@{#438082}

Implement FakePepperInterfaceGoogleDriveFs, and implement
FakeDriveURLResponseInfoInterface and FakeDriveURLLoaderInterface, which
FakePepperInterfaceGoogleDriveFs uses.  FakePepperInterfaceGoogleDriveFs
is going to be used by the unit tests of the future code.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_nacl_sdk;master.tryserver.chromium.mac:mac_nacl_sdk;master.tryserver.chromium.win:win_nacl_sdk

Review-Url: https://codereview.chromium.org/2538163003
Cr-Commit-Position: refs/heads/master@{#438081}

I noticed a lot of complex logic in content_layer.cc and
static_tab_scene_layer.cc that appears to do nothing useful anymore.  I
simplified it by:
1) Always detaching and reattaching the live and static sublayers
instead of trying to preserve the existing structure.  (There shouldn't
be any performance cost to this.)
2) Following a much simpler policy for positioning and clipping.  I
compared the behavior of the old and new logic in a variety of device
rotation, tab switcher and URL-bar-hiding scenarios, and I haven't
yet observed any regression.

BUG=662427

Review-Url: https://codereview.chromium.org/2566753004
Cr-Commit-Position: refs/heads/master@{#438080}

The shader cache code is going to move into //gpu/ipc/host. However, the
singleton is content only. So factor out the code that deals with the
singleton instance inside content.

BUG=604369

Review-Url: https://codereview.chromium.org/2565223003
Cr-Commit-Position: refs/heads/master@{#438079}

This also includes DevToolsSession::Dispatch utility method
which offers message to DevToolsManagerDelegate.

BUG=664683
TBR=pfeldman

Review-Url: https://codereview.chromium.org/2548263002
Cr-Commit-Position: refs/heads/master@{#438078}

I've root caused this and the problem was introduced in this CL:
https://codereview.chromium.org/2446053002

That CL moved the logic which reported the worker process launch from the
IPC Channel Connected method to an IO completion port listener.  This works
fine on un-official builds, however it breaks on official builds.  The
reason for the failure is that the remoting_desktop process on official
builds are signed and include 'UiAccess' in their manifest.  When the
launcher process uses ShellExecuteEx to launch the worker process in this
scenario, we actually see two processes get launched sequentially.  The
first starts and exists with error code 'STATUS_ELEVATION_REQUIRED' and
the second launches with the correct permissions.  This behavior worked
fine before as we listened for the connection to the IPC channel which
was done by the second, successful process launch.  With the new code,
we observed the first process launch, set up the Mojo channel for it, and
tried waiting on its process handle which exits immediately.  The second
process then starts and fails to connect to the Mojo channel.

I investigated whether UiAccess is truly required for the desktop binary
and I think that it is.  For the Ctrl+Alt+Del scenario, there are registry
keys that can be set which will require that flag.  For Alt+Tab, it is
possible that some windows might not be accessible if they have a high
high enough integrity level (+ UiAccess themselves).

So instead of removing the UiAccess flag, my approach is to listen for the
worker process creation and exit events.  I store the value of the last seen
worker process id and use that in our process launch detection code once the
launcher process exits.  This allows both un-official builds (which do not
require the extra permissions hop) and official builds will work consistently.

BUG=666992

Review-Url: https://codereview.chromium.org/2568983004
Cr-Commit-Position: refs/heads/master@{#438077}