Make plugin elements return false from canStartSelection.

Make plugin elements return false from canStartSelection.

The canStartSelection property of Node is to indicate that text
selection can start there, i.e. it's some variety of text or editable.
Image and media elements, for example, are excluded.

After I switched long-press selection to consider this property in
r385360, context menu events stopped being forwarded correctly to
plugins because the events were absorbed by text selection instead.  The
root cause was this incorrectly assigned Node property.

For completeness:
- I made the long-press layout tests run on all platforms.  After
  r385360, they were no longer Android-specific, and I only just learned
  of their existence now.

BUG=621063
Committed: https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3
Cr-Commit-Position: refs/heads/master@{#401359}

[aelias_OOO_until_Jul13, 2016-06-18 02:30:56]

aelias@chromium.org changed reviewers:
+ yosin@chromium.org

[aelias_OOO_until_Jul13, 2016-06-18 02:31:04]

Hi yosin@, PTAL.

[yosin_UTC9, 2016-06-21 08:09:32]

https://codereview.chromium.org/2078143002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/html/HTMLCanvasElement.h (right):

https://codereview.chromium.org/2078143002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/html/HTMLCanvasElement.h:215: bool
canStartSelection() const override { return false; }
HTMLCanvasElement::canStartSelection() should return true if this canvas shows
fall back content.

Example: You can see fall back content when JavaScript is disabled.

<style>canvas { outline: orange 1px solid; }</style>
<canvas id="canvas" width="300" height="300">
  An alternative text describing what your canvas displays. 
</canvas>

https://codereview.chromium.org/2078143002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/html/HTMLPlugInElement.h (right):

https://codereview.chromium.org/2078143002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/html/HTMLPlugInElement.h:107: bool
canStartSelection() const override { return false; }
HTMLPluginElement::canStartSelection() should return true if this plug-in shows
fall back content.

Example: You can see fall back when OBJECT element w/o "src" attribute:

<object>fallback content</object>

[aelias_OOO_until_Jul13, 2016-06-21 20:39:26]

Description was changed from

==========
Make plugin elements return false from canStartSelection.

The canStartSelection property of Node is to indicate that text
selection can start there, i.e. it's some variety of text or editable.
Image and media elements, for example, are excluded.

After I switched long-press selection to consider this property in
r385360, context menu events stopped being forwarded correctly to
plugins because the events were absorbed by text selection instead.  The
root cause was this incorrectly assigned Node property.

For completeness:
- I also marked HTMLCanvas element as nonselectable, as that seems like
  a related oversight (although there are no known bugs from this yet).
- I made the long-press layout tests run on all platforms.  After
  r385360, they were no longer Android-specific, and I only just learned
  of them now.

BUG=621063
==========

to

==========
Make plugin elements return false from canStartSelection.

The canStartSelection property of Node is to indicate that text
selection can start there, i.e. it's some variety of text or editable.
Image and media elements, for example, are excluded.

After I switched long-press selection to consider this property in
r385360, context menu events stopped being forwarded correctly to
plugins because the events were absorbed by text selection instead.  The
root cause was this incorrectly assigned Node property.

For completeness:
- I made the long-press layout tests run on all platforms.  After
  r385360, they were no longer Android-specific, and I only just learned
  of their existence now.

BUG=621063
==========

[aelias_OOO_until_Jul13, 2016-06-21 22:07:50]

https://codereview.chromium.org/2078143002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/html/HTMLCanvasElement.h (right):

https://codereview.chromium.org/2078143002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/html/HTMLCanvasElement.h:215: bool
canStartSelection() const override { return false; }
On 2016/06/21 at 08:09:32, Yosi_UTC9 wrote:
> HTMLCanvasElement::canStartSelection() should return true if this canvas shows
fall back content.

OK, I removed the canvas part of this patch -- it can be improved in a future
patch if there is a need.  (The canvas fallback mechanism is different and more
complex than plugins, so this is looking like too out-of-scope for this patch.)

https://codereview.chromium.org/2078143002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/html/HTMLPlugInElement.h (right):

https://codereview.chromium.org/2078143002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/html/HTMLPlugInElement.h:107: bool
canStartSelection() const override { return false; }
On 2016/06/21 at 08:09:32, Yosi_UTC9 wrote:
> HTMLPluginElement::canStartSelection() should return true if this plug-in
shows fall back content.
> 
> Example: You can see fall back when OBJECT element w/o "src" attribute:
> 
> <object>fallback content</object>

Switched to check useFallbackContent().  For testing this behavior, I added
fallback test cases to the WebViewTest, and I deleted the NodeTest because that
test environment isn't sufficiently realistic for fallback content loading.

[yosin_UTC9, 2016-06-22 01:23:18]

lgtm w/ small nit

https://codereview.chromium.org/2078143002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp (right):

https://codereview.chromium.org/2078143002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp:107: if
(!useFallbackContent())
How about below?

return useFallbackContent() && Node::canStartSelection();

[aelias_OOO_until_Jul13, 2016-06-22 01:33:02]

aelias@chromium.org changed reviewers:
+ yutak@chromium.org

[aelias_OOO_until_Jul13, 2016-06-22 01:33:03]

Adding yutak@ for core/html OWNERS.

https://codereview.chromium.org/2078143002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp (right):

https://codereview.chromium.org/2078143002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp:107: if
(!useFallbackContent())
On 2016/06/22 at 01:23:18, Yosi_UTC9 wrote:
> How about below?
> 
> return useFallbackContent() && Node::canStartSelection();

Done.

[Yuta Kitamura, 2016-06-22 06:06:30]

LGTM (but you may need to fix a layout test failure
editing/selection/readonly-disabled-text-selection.html)

[aelias_OOO_until_Jul13, 2016-06-22 18:21:07]

The CQ bit was checked by aelias@chromium.org

[aelias_OOO_until_Jul13, 2016-06-22 18:21:07]

The patchset sent to the CQ was uploaded after l-g-t-m from yosin@chromium.org,
yutak@chromium.org
Link to the patchset: https://codereview.chromium.org/2078143002/#ps80001
(title: "Fix readonly-disabled-text-selection for changes in r401155")

[commit-bot: I haz the power, 2016-06-22 18:21:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2078143002/80001

[commit-bot: I haz the power, 2016-06-22 18:28:44]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-06-22 18:34:05]

Description was changed from

==========
Make plugin elements return false from canStartSelection.

The canStartSelection property of Node is to indicate that text
selection can start there, i.e. it's some variety of text or editable.
Image and media elements, for example, are excluded.

After I switched long-press selection to consider this property in
r385360, context menu events stopped being forwarded correctly to
plugins because the events were absorbed by text selection instead.  The
root cause was this incorrectly assigned Node property.

For completeness:
- I made the long-press layout tests run on all platforms.  After
  r385360, they were no longer Android-specific, and I only just learned
  of their existence now.

BUG=621063
==========

to

==========
Make plugin elements return false from canStartSelection.

The canStartSelection property of Node is to indicate that text
selection can start there, i.e. it's some variety of text or editable.
Image and media elements, for example, are excluded.

After I switched long-press selection to consider this property in
r385360, context menu events stopped being forwarded correctly to
plugins because the events were absorbed by text selection instead.  The
root cause was this incorrectly assigned Node property.

For completeness:
- I made the long-press layout tests run on all platforms.  After
  r385360, they were no longer Android-specific, and I only just learned
  of their existence now.

BUG=621063

Committed: https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3
Cr-Commit-Position: refs/heads/master@{#401359}
==========

[commit-bot: I haz the power, 2016-06-22 18:34:07]

Patchset 5 (id:??) landed as
https://crrev.com/a1c7f43d9e5166bf0b21fc3690728e79bb6fd2a3
Cr-Commit-Position: refs/heads/master@{#401359}