Throw correct exceptions from collapse/selectAllChildren on detached doctypes

[ayg]

According to the previous spec, trying to collapse to or select a
doctype that is not in the current document would not throw. But
Chrome, Firefox, and Edge all do throw. (WebKit doesn't seem to throw
for doctypes at all.) The wpt test also tests that browsers do throw in
this case.

[ayg]

Updated to reflect the fact that this affects collapse() too.

[ayg]

@masayuki-nakano points out that this introduces an inconsistency with extend() and setBaseAndExtent(), which do not throw in this case in Chrome. I think we should throw in all cases, because it matches the current behavior of Edge and Firefox and probably the old behavior of Chrome.

[ayg]

I wrote a test case:

• collapse to detached doctype: Chrome, Firefox, and Edge throw; WebKit doesn't
• extend to detached doctype: Firefox and Edge throw; Chrome and WebKit don't
• extend to out-of-range index: Firefox, Edge, and WebKit throw; Chrome doesn't
• selectAllChildren on detached doctype: Chrome, Firefox, and Edge throw; WebKit doesn't
• setBaseAndExtent on detached doctype: Chrome, Firefox, and Edge throw; WebKit doesn't
• setBaseAndExtent on out-of-range index: Chrome and Firefox throw; Edge and WebKit don't

So in most cases three out of four throw, and in the rest it's 50/50, so I think we should just throw in all cases here.

[ayg]

I should add that usually when browsers disagree, we have a strong preference for not throwing, but I think maybe this is different because half of the not-throwing behavior is due to the fact that WebKit doesn't ever throw when setting a range endpoint to a doctype. This is clearly not required by web compatibility. If you leave out WebKit from the doctype cases, behavior is 100% in favor of throwing in most cases. But on second thought, it's always easier not to throw, so maybe the spec should say never to throw. @rniwa, what do you think?

This issue blocks Mozilla's implementation, which I guess therefore won't get done until August.

[rniwa]

I can be convinced about throwing for doctype but I don't think we'd like to change the behavior for out-of-range index since we've seen web contents and App-specific web content that do use such index and expect WebKit to do the "right thing".

[ayg]

@rniwa By out-of-range index you mean for setBaseAndExtent specifically? For all the others it looks like WebKit already throws, according to my earlier testing.

[marcoscaceres]

@rniwa seems there was only one small issue for @ayg to address here (as webkit already throws in various places that @ayg tested)? Can we move this forward?

[rniwa]

@marcoscaceres : if someone can fix the PR, then yes. I don't think we can marge the PR as is due to the aforementioned issue.