GitLab

BUG=589168

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

Revert of Make click targets inside links work. (patchset #1 id:1 of https://codereview.chromium.org/2030413002/ )

Reason for revert:
Failing on Mac 10.11 (dbg): https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac10.11%20%28dbg%29/builds/2237

Error message is:

Harness Error. harness_status.status = 2 , harness_status.message = null

Sorry to revert this again. :(

Original issue's description:
> Make click targets inside links work.
>
> There are pages that attach click handlers to elements that are found inside links, and screen readers might try to click such elements. Our existing doDefaultAction logic wasn't handling this possibility.
> For example, there might be a graphic inside a link and the screen reader might invoke the default action on the graphic.
> BUG=615904
> TBR=dmazzoni@chromium.org
>
> Committed: https://crrev.com/f491eb9a53ed36e90ab45c943a0e52247ec00da5
> Cr-Commit-Position: refs/heads/master@{#397760}

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

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

Originally Chrome OS's touch accessibility support was implemented purely
as an event rewriter. Tapping the screen generates a mouse move event,
which announces the object under the finger without clicking it, and then
double-tapping anywhere on the screen generates a click at the last point
where the user tapped. It's also possible to trigger clicks and drags by
more advanced means.

This worked well for touch exploration alone, but it's also possible for
the current accessibility object to move due to a gesture (to move to the
next or previous object on the screen, for example) or due to input focus
moving. In those cases, a double-tap was sending a simulated click to the
wrong point - it was sending it to the last touch exploration point, rather
than to the current accessibility object.

This change fixes this behavior by changing how the touch accessibility
support works.

First, it introduces the concept of the anchor point, which is the point
where the next simulated click will go. Initially this is set via touch
exploration, however now as soon as ChromeVox identifies the object under
the finger, it sends the center point of that object as the new explicit
anchor point, and that point overrides the touch exploration point for the
duration of this touch.

Second, when the user does a discrete gesture to click on the current anchor
point (double-tap, split-tap, or single-tap), it sends a gesture command
to ChromeVox, allowing ChromeVox to directly activate the current object.
However, if the user holds their finger down, it still passes through the
touch events so dragging and long-pressing are possible.

Third, it simplifies "split tap" support where you can tap a second finger
as a shortcut to clicking. That support now only supports a basic click and
not a long-press or drag.

BUG=513713,613694
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

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

In http://crbug.com/493941, it was mentioned that we could fix all current pylint warnings before enabling pylint warnings in the presubmit -- but actually we could also enable warnings in the presubmit now without causing any problems; pylint will only print warnings about lines that are changed in a CL, and turning on warnings now could be potentially helpful in cleaning up the code.

And turning on pylint warnings in check-webkit-style and the presubmit is just a one line change; any reason not to just do it now?

NOPRESUBMIT=true
BUG=493941

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

After this CL, ResourceRequestBody from ResourceHostMsg_Request
will get sent after a cross-site transfer in FrameMsg_Navigate:

- ResourceDispatcherHostImpl::BeginRequest stores
  ResourceHostMsg_Request::request_body into
  ResourceRequestInfoImpl::body_

- NavigationResourceThrottle::WillStartRequest forwards
  ResourceRequestInfoImpl::body_ into a call to
  NavigationHandleImpl::WillStartRequest, where the body gets stored in
  NavigationHandleImpl::resource_request_body_

- NavigationHandleImpl::WillRedirectRequest takes care to
  reset the body if a redirect changed the method to a non-POST.
  (see also https://crbug.com/582211#c22).

- RenderFrameHostManager::OnCrossSiteResponse forwards
  NavigationHandleImpl::resource_request_body_ into the call to
  NavigatorImpl::RequestTransferURL.  The body is used to set
  the proper method on FrameNavigationEntry and used to populate
  CommonNavigationParams.

BUG=582211, 613004
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

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

-Removed document.setRootScroller and replaced it by making the
document.rootScroller attribute writable.

-Moved the RootScroller object from FrameHost into Document. Now each
Document has its own RootScroller object which manages the rootScroller
for that Document. This means each iframe on the page will have its own
rootScroller. I've allowed setting it from iframes now too, making the
API more composable; setting a rootScroller on an iframe's Document
simply doesn't change any behavior.

-Made the rootScroller "sticky". Previously, if the current rootScroller
becomes invalid (for example, the rootScroller Element becomes
display:none) it would reset to the default element. With this CL, we'll
use the default while the rootScroller is invalid, but we keep the
rootScroller set. When it becomes valid again, we'll use it again. This
is done by making RootScroller::m_rootScroller the Element the page has
set as the root scroller. RootScroller::m_effectiveRootScroller is the
Element we're using internally to handle viewport actions.

-Changed the criteria for a valid rootScroller. Elements in an iframe can
now be used. Only elements that exactly fill the viewport are considered
valid.

BUG=505516

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

Summary of changes available at:
https://chromium.googlesource.com/v8/v8/+log/a9e2bf5a..9cdf7a6f

Please follow these instructions for assigning/CC'ing issues:
https://github.com/v8/v8/wiki/Triaging%20issues

Please close rolling in case of a roll revert:
https://v8-roll.appspot.com/
This only works with a Google account.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

TBR=hablich@chromium.org,machenbach@chromium.org,yangguo@chromium.org,vogelheim@chromium.org

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

JIS keyboard produces different characters for Shift+Num0..9,
which is incorrectly handled by |KeyboardCodeFromCharCode()| and
results in wrong |keyCode|.

This CL maps |keyCode| for Num0..9 based on |NSEvent::keyCode|, which matches FF's logic:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode#Printable_keys_in_standard_position

We want this issue fixed because it's affecting "Command+Shift+2/7" hotkeys among Japanese Gmail users.

This CL also adds tests for |keyCode| on different keyboard&InputSource combinations.

Example issue before CL:
On US layout - Shift+Num7 generates |keyCode| 55 (VKEY_7).
On JIS layout - Shift+Num7 generates |keyCode| 222 (VKEY_OEM_7) because the produced character is |'|.

After CL:
Both are 55 (VKEY_7), which matches Firefox and Edge.

BUG=440066

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

Previously, the test converter assumed that input files are always valid utf-8;
this change makes the converter also support utf-16 files. There are some files
in the wpt repo that are not valid utf-8 but are valid utf-16, e.g.
web-platform-tests/html/infrastructure/urls/resolving-urls/query-encoding/utf-16be.html.
BUG=463001

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

Previous CL forgot to set the value of always_show_context_menu_on_touch.
This CL fixes that.

BUG=616971

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

BUG=612498,543268
TEST=Added the files blimp/science.cc, blimp/science_unittest.cc, blimp/science2.cc, blimp/science2_unittest.cc, blimp/science_browsertest.cc, and science.cc. Verified that blimp/science.cc was flagged for missing unit tests.

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

This will be needed by the cc::CompositorFrameMetadata StructTraits.

BUG=611802

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

This patch converts the usage of CanonicalCookie's constructor in
CreateMonsterFromStoreForCG() to CanonicalCookie's Create() method.

We are doing this because Create() is more robust, as it does
validation of the parameters and return NULL as an error signal
if they fail to comply with the checks.

BUG=57061
TEST=net_unittests
R=mmenke@chromium.org

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

This moves another step performed by gyp-mac-tool into a standalone script.

BUG=616813
R=sdefresne@chromium.org

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

This is a trivial change to make Event.SelfRemovableParameterRunnable final.

BUG=615277

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

https://chromium.googlesource.com/skia.git/+log/2cee902847a9..adf5afa628ad

$ git log 2cee90284..adf5afa62 --date=short --no-merges --format='%ad %ae %s'
2016-06-03 robertphillips Add SampleApp slide with animating lightmapped objects & transparency
2016-06-03 herb Add gm for displaying different variants of 8888 bitmaps and fix a small rejection case for sprite blitters.
2016-06-03 caryclark fix windows assert
2016-06-03 scroggo Fix undefined behavior in libpng
2016-06-03 halcanary SkPDF: handle unpremul right
2016-06-03 csmartdalton Abandon offset support with texel buffers
2016-06-03 liyuqian Add Softkey UIState to Viewer
2016-06-03 csmartdalton Support ARB extensions for indirect drawing

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
TBR=herb@google.com

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

Fixes 'undeclared identifier __NR_access/__NR_open' compile errors.

__NR_access and __NR_open don't exist on ARM64. So, like the earlier
code in same file, added __NR_access and __NR_open case under
!defined(__aarch64__) check.

BUG=613452

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

This patch adds the following new histograms:
Renderer4.GpuImageDecodeState
=============================
This records the state of the software decode used for gpu upload.
Specifically, it identifies whether the decode was used or not used and
whether it was used/wasted once or several times. The possible states
are all combinations of those values:
- Used, once
- Wasted, once
- Used, relocked
- Wasted, relocked

Renderer4.GpuImageDecodeState.FirstLockWasted
=============================================
This indicates whether the first lock of the decode described above was
used. This is important, since if we waste the first decode, we lose
the guarantee that we can relock and upload this without doing more work

Renderer4.GpuImageUploadState.Used
==================================
This indicates whether the uploaded image was used in raster.

Renderer4.GpuImageUploadState.FirstRefWasted
============================================
This indicates whether the uploaded image was used during the first
ref. In other words, if the ref reached 0 for the first time without
the image being used, this would record "true, it was wasted".

R=ericrk
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

BUG=605340

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

This function is more closely related to the code in test_result_writer.py than the code in rebaseline.py; however it wouldn't be simpler to make this function a method of TestResultWriter, since the TestResultWriter constructor takes several arguments which are not relevant to the baseline_name function.

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

The buildGradient() method can just create and return a Gradient instead
of populating the GradientData struct it's being passed.
Also make calculateGradientTransform() use the return value rather than
an out variable, and make it const qualified. Make
platformSpreadMethodFromSVGType static and use Traversal<> sugar in
SVGGradientElement::buildStops.

BUG=614368

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

There is no longer a need to filter out ECDSA.

BUG=none

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

BUG=615588

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

There are pages that attach click handlers to elements that are found inside links, and screen readers might try to click such elements. Our existing doDefaultAction logic wasn't handling this possibility.
For example, there might be a graphic inside a link and the screen reader might invoke the default action on the graphic.
BUG=615904
TBR=dmazzoni@chromium.org

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

. It is necessary to send the --use-mus-in-renderer flag to the renderer.
. Allow content_browser to connect to the renderer and get a handle to
  a RenderWidgetWindowTreeClientFactory.

BUG=none

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

The raw pointer overload of ListValue::Append() is deprecated and will
be removed. Instead, code should just write:
- ListValue::AppendBoolean()
- ListValue::AppendInteger()
- ListValue::AppendDouble()
- ListValue::AppendString()

BUG=581865

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

https://chromium.googlesource.com/external/github.com/catapult-project/catapult.git/+log/37cec23b5d25..80132ac6935a

$ git log 37cec23b5..80132ac69 --date=short --no-merges --format='%ad %ae %s'

TBR=catapult-sheriff@chromium.org

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

Add removed code from https://codereview.chromium.org/1495623008
that changes the position of the viewer when it hides/unhides.

Added logic that calculates the x and y position offset of the dialog
when it unhides.

BUG=611603

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

RenderWidgetHostViewMac is careful about creating ui::Compositor and so
currently only does this in Show and SwapCompositorFrame.  However, if
it the RenderWidgetHostView is created while the RenderWidgetHost is
visible, then Show will early out and never create a ui::Compositor.

This causes problems with begin frame scheduling, which wants to have
the Display (which is created as part of creating the ui::Compositor's
output surface currently) own the real begin frame source that drives
everything.  In that world, if no ui::Compositor exists, no frames ever
are sent or swapped.  So, the ui::Compositor needs to be created first.

Also, if the ui::Compositor is correctly created during Show (or the
constructor), then there's no need to ensure that it exists during
swap compositor frame, and so that can be safely removed.

R=asvitkine@chromium.org,ccameron@chromium.org

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

Whitelist pointer event manual tests in the import process

Using update-w3c-deps in Chromium c517903e.

BUG=612924

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

BUG=
TBR=stgao@chromium.org

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

Add tests and Win10 expectations for color emoji.
Also fix an expectation for emoji fallback test to look for the color
emoji font first, which will be present on Win10, but not on Win7.

Skia change to enable color emoji on Win8.1+: https://codereview.chromium.org/1984943002/

BUG=333011

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

This change moves the close button to the far right in the Physical Web
ListUrlsActivity.

BUG=603132

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

BUG=584660

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

BUG=546019

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

BUG=616265
TEST=none
R=msw@chromium.org

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

BUG=616633

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

The raw pointer overload of ListValue::Append() is deprecated and will
be removed. Instead, code should just write:
- ListValue::AppendBoolean()
- ListValue::AppendInteger()
- ListValue::AppendDouble()
- ListValue::AppendString()

BUG=581865

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

In order to allow Chrome on iOS to use build/mac/tweak_info_plist.py,
add options required to control the format of the generated plist file
(--format), the product reported to breakpad (--platform) and a way to
override some portion of the version string (--version-overrides).

This is required to allow Chrome on iOS to migrate from it old fork of
tweak_info_plist shell script and to incorporate tweak_info_plist.py
in the GN build.

BUG=502295

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

As compositor will no longer know tree hierarchy information, it is
expected to dump a layer list instead of a layer tree to chrome tracing.

The value root_layer is also deleted because it is used to judge whether
the dumped layer_tree_impl has a list or not on the FrameViewer side.

Chrome://tracing will show a layer_tree_impl without depth, this is
expected.

This CL is blocked by Issue 1947553002, and potentially influenced by
the LayerTreeImpl's JSON issue.

Devtools need to deal with the new format information. On the devtools
side, we make the first drawsContent layer "contentRoot" and treat all
other layers as the contentRoot's child.

BUG=605940
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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