I like the sentiment behind this! I just put together some wording to clarify the problem atjquery/api.jquery.com@6137d67 but am not really happy about it.

Do you know the range of browser support? It looks like thismay be usable on all browsers that jQuery 2.x supports but not jQuery 1.x:http://stackoverflow.com/questions/18003264/document-implementation-createhtmldocument-browser-support

Mainly I'd be worried about Android, especially Android 2.3.

I'll modify this PR to check for support with jQuery.isFunction() first, falling back todocument. Just to be sure. Also I'm already adding this to the 1.x branch (PR follows in a few minutes 😃 ).

I'm now checking fordocument.implementation.createHTMLDocument first, so it should be fine.

This seems really nice,especially if we can drop the fallback in 2.x. Thanks,@fhemberger!

See thecomment here.

See thecomment here.

Any news on this issue? Can it be merged in it's current state?

@fhemberger This will go into 1.12/2.2 so we don't want to land it in master if a 1.11.1/2.1.1 is going to come out soon. We haven't forgotten about it though!

@dmethvin Great, thanks.

We're already working on a separate plug-in for strict security-related DOM filtering, which will work nicely together with this patch.

A few remarks regarding the commit:

1. Second line must always be empty
2. Commit message line 3 too long: 82 characters, only 80 allowed.
3. Please don't add new lines longer than 100 characters (we'll going to enforce the limit in the near future once we fix all the code).

Waaah! Rebasing from master added all commits … relevant is only6a4672c. If you want, I can send a new, clean PR which should be easier to merge.

You probably didn't rebase but merge it.

if you want, I can send a new, clean PR which should be easier to merge.

That might be the best way to do it

You could alsogit rebase -i master to remove all commits other than yours and thengit push -f origin parsehtml_2.x to restorethis PR.

Unfortunately, we had to back it out for now because of Safari 8 bugs:b779831.

This is the related WebKit bug report:https://bugs.webkit.org/show_bug.cgi?id=137337

@fhemberger

This is the related WebKit bug report:https://bugs.webkit.org/show_bug.cgi?id=137337

Thanks a lot for finding it!

This seems hard to patch on our side (at least without adding a lot of code) and usingdocument.implementation.createHTMLDocument('') everywhere except Safari 8 would be quite weird as it's a security-related feature; it could make developers trust their inputs a little too much and put Safari 8 users at risk.

What do you all think? Judging by the fact that the bug is still open I don't see a quick solution on Safari side.

Well, you could detect this specific bug using the code of the test case:

vardoc=document.implementation.createHTMLDocument('');varbodyEl=doc.documentElement.lastChild;bodyEl.innerHTML='<form></form><form></form>';varisSafariBug=(bodyEl.childElementCount===1);

Add this check to the generalsupport methods and if it returns true, just fall back todocument. It's not a nice solution but it would be a solution nonetheless.

Oh 💩.

Well, here for the second time in a week we are faced with a crippling Safari bug and no way to know what Apple may decide what to do. How about feature-detect this similar to what@fhemberger describes and skip using the technique in Safari as a result? Then we can simply warn people that using Safari is less safe.

Yes, I think that's the best way to deal with this right now … then the changes of this PR could be backported 1:1 for the 1.x branch (as we don't have any fallback there for IE8 as well).

This was originally backported to 1.12/2.2 but due to#2941 we're backing out the patch on those branches (as they wen't meant to be non-breaking releases and there may always be more issues around that); we'll try to fix the issue for 3.0.