Remove NonSelectableText subclass of Text

Remove NonSelectableText subclass of Text

We can teach Text::createTextRenderer how to create these special types of text renderers and make make
createTextRenderer non-virtual again. The only reason it exists outside createRenderer was to make it
non-virtual. If we do decide to make it virtual again we should move createRenderer back up to Node and
use that.

Originally I tried to just use a plain Text node but it broke text selection behavior for <input type="button">
because RenderTextFragment had special behavior with an override of canBeSelectionLeaf that made the text
only selectable if the renderer is editable (ex. contenteditable=true around the button).

BUG=265699

[ojan, 2013-07-30 01:35:31]

lgtm

I'm not sure we ever need to make button text unselectable. Seems fine as is if
users aren't complaining/confused.

Looks like Firefox makes them atomic (e.g. user-select:all?).

[commit-bot: I haz the power, 2013-07-30 01:38:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/esprehn@chromium.org/21182003/3001

[esprehn, 2013-07-30 01:38:29]

On 2013/07/30 01:35:31, ojan wrote:
> lgtm
> 
> I'm not sure we ever need to make button text unselectable. Seems fine as is
if
> users aren't complaining/confused.
> 
> Looks like Firefox makes them atomic (e.g. user-select:all?).

Yeah, I think ours might actually be too. I can't quite seem to get the
selection down into the button.

[commit-bot: I haz the power, 2013-07-30 05:54:45]

Retried try job too often on mac_blink_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_blink_...

[esprehn, 2013-07-30 07:51:02]

This seems to fail editing selection tests now:

editing/selection/3690703-2.html
editing/selection/3690703.html
editing/selection/3690719.html
editing/selection/selection-button-text.html

So the RenderTextFragment is actually doing something which is strange since as
far as I understand it the reason text is not selectable is because its
anonymous. Perhaps I'll need to add the css in this patch as well.

[eseidel, 2013-07-30 08:00:46]

It's trivial to drag select into a button:

data:text/html,<button>foo</button>

I'm not sure that was an intentional behavior change when it was made.  Do we
know when this "regressed"?  (years ago?) Are we sure we like this behavior?

[esprehn, 2013-07-30 08:05:48]

On 2013/07/30 08:00:46, eseidel wrote:
> It's trivial to drag select into a button:
> 
> data:text/html,<button>foo</button>
> 
> I'm not sure that was an intentional behavior change when it was made.  Do we
> know when this "regressed"?  (years ago?) Are we sure we like this behavior?

Wrong kind of button, this is about <input type="button" value="foo"> and the
other button types: type="image", type="submit", type="reset".

It appears there's a hack on RenderTextFragment to make it not selectable:

virtual bool canBeSelectionLeaf() const OVERRIDE { return node() &&
node()->rendererIsEditable(); }

This was added in https://bugs.webkit.org/show_bug.cgi?id=13624 to fix the
regression.

[esprehn, 2013-07-30 10:12:20]

I managed to get this to work, but it turns out we do need the
RenderTextFragment weirdness to match the selection behavior for buttons. It
looks like my bug isn't quite right, the text not being anonymous didn't make it
selectable in normal cases, but it does make it selectable sometimes (ex. right
click on a single word in the button).

Making this change would let us devirtualize createTextRenderer again, but it
does mean an input button specific hack in Text.cpp.

eseidel, ojan? What do you think, is this change good/bad? :)