Range.intersectsNode() does not behave according to the specification.

Range.intersectsNode() does not behave according to the specification.

We should return true if parent is null as per specification.
https://dom.spec.whatwg.org/#dom-range-intersectsnode

Previously, WebKit would throw a NotFoundError, apparently
to match Firefox's behavior. However, these days, Firefox
complies with the specification and returns true here.

Picked from webkit https://trac.webkit.org/changeset/189225

BUG=535153
Committed: https://crrev.com/7634f50b38265607d2304c785dd07366e0a09585
Cr-Commit-Position: refs/heads/master@{#352310}

[pals, 2015-09-23 07:14:29]

sanjoy.pal@samsung.com changed reviewers:
+ ager@chromium.org

[pals, 2015-09-23 11:29:41]

Patchset #2 (id:20001) has been deleted

[pals, 2015-09-23 11:30:44]

PTAL. Thanks

[pals, 2015-09-23 11:35:22]

sanjoy.pal@samsung.com changed reviewers:
+ sigbjornf@opera.com

[sof, 2015-09-23 12:16:46]

Could you create a tracking bug for this, as it makes a user facing change
(albeit minor/obscure)?

Also, how does Safari and IEs behave?

[pals, 2015-09-23 12:38:27]

On 2015/09/23 12:16:46, sof wrote:
> Could you create a tracking bug for this, as it makes a user facing change
> (albeit minor/obscure)?
> 
> Also, how does Safari and IEs behave?

Updated the description with the bug id.

I haven't checked the IE but Webkit recently changed as per specification here
https://trac.webkit.org/changeset/189225.

[sof, 2015-09-25 09:16:47]

On 2015/09/23 12:38:27, pals wrote:
> On 2015/09/23 12:16:46, sof wrote:
> > Could you create a tracking bug for this, as it makes a user facing change
> > (albeit minor/obscure)?
> > 
> > Also, how does Safari and IEs behave?
> 
> Updated the description with the bug id.
> 
> I haven't checked the IE but Webkit recently changed as per specification here
> https://trac.webkit.org/changeset/189225.

Thanks; checking details, older IE versions haven't provided
Range.intersectsNode(), so there are any backwards compat worries here wrt to
it.

https://github.com/timdown/rangy is aligned with the DOM spec also.

[sof, 2015-09-25 09:17:04]

https://codereview.chromium.org/1364683003/diff/40001/Source/core/dom/Range.cpp
File Source/core/dom/Range.cpp (right):

https://codereview.chromium.org/1364683003/diff/40001/Source/core/dom/Range.c...
Source/core/dom/Range.cpp:402: if (!parentNode)
Could you move this up to the line after where parentNode is initialized?

https://codereview.chromium.org/1364683003/diff/40001/Source/core/dom/Range.c...
Source/core/dom/Range.cpp:428: if (!parentNode)
Ditto.

[sof, 2015-09-25 09:25:35]

On 2015/09/25 09:16:47, sof wrote:
> On 2015/09/23 12:38:27, pals wrote:
> > On 2015/09/23 12:16:46, sof wrote:
> > > Could you create a tracking bug for this, as it makes a user facing change
> > > (albeit minor/obscure)?
> > > 
> > > Also, how does Safari and IEs behave?
> > 
> > Updated the description with the bug id.
> > 
> > I haven't checked the IE but Webkit recently changed as per specification
here
> > https://trac.webkit.org/changeset/189225.
> 
> Thanks; checking details, older IE versions haven't provided
> Range.intersectsNode(), so there are any backwards compat worries here wrt to
> it.
> 
> https://github.com/timdown/rangy is aligned with the DOM spec also.

s/are any/aren't any/g :)

[pals, 2015-09-28 11:29:06]

Fixed the comments. PTAL.

https://codereview.chromium.org/1364683003/diff/40001/Source/core/dom/Range.cpp
File Source/core/dom/Range.cpp (right):

https://codereview.chromium.org/1364683003/diff/40001/Source/core/dom/Range.c...
Source/core/dom/Range.cpp:402: if (!parentNode)
On 2015/09/25 09:17:04, sof wrote:
> Could you move this up to the line after where parentNode is initialized?

Done.

https://codereview.chromium.org/1364683003/diff/40001/Source/core/dom/Range.c...
Source/core/dom/Range.cpp:428: if (!parentNode)
On 2015/09/25 09:17:04, sof wrote:
> Ditto.

Done.

[sof, 2015-09-28 14:08:41]

lgtm.

Could you add a mention of https://trac.webkit.org/changeset/189225 to the
description also?

[pals, 2015-10-05 07:18:58]

The CQ bit was checked by sanjoy.pal@samsung.com

[commit-bot: I haz the power, 2015-10-05 07:19:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1364683003/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1364683003/60001

[commit-bot: I haz the power, 2015-10-05 09:40:15]

Committed patchset #3 (id:60001)

[commit-bot: I haz the power, 2015-10-05 09:41:21]

Patchset 3 (id:??) landed as
https://crrev.com/7634f50b38265607d2304c785dd07366e0a09585
Cr-Commit-Position: refs/heads/master@{#352310}