Alternate fix would be to allow the regex to continue to match, but make thegetElementById selection conditional.

https://github.com/jquery/jquery/blob/master/src/core/init.js#L68-L70

// HANDLE: $(#id)} else if (match[2]) {    elem = document.getElementById( match[2] );    // Support: Blackberry 4.6    // gEBID returns nodes no longer in the document (#6963)    if ( elem && elem.parentNode ) {        // Inject the element directly into the jQuery object        this.length = 1;        this[0] = elem;    }    this.context = document;    this.selector = selector;    return this;} else {    return this;}

You would rather see it throwing a error?

This is bydesign.

@markelog

Just so I'm understanding correctly, it is by design that$("#") behaves differently from$(document).find("#")?

Hm,@rwaldron what is your thoughts on it?

Don't both of those return an empty set? What change in behavior are you advocating for one or both cases?

I just want to say how ridiculously easy Github makes it to push the wrong button.

:-)

Don't both of those return an empty set?

$(document).find("#") would be passed directly to Sizzle, which would throw an error. WhereasjQuery("#") would usegetElementById as an optimization technic, which would return an empty set.

Which looks as inconsistency... which would affect very small amount of users

According tohttps://html.spec.whatwg.org/multipage/dom.html#the-id-attribute:

The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character. The value must not contain any space characters.

So, I think jQuery('#') must throw an error.

It doesn't throw an error if you enter from the console I guess. So I wrote the test case that I wish was already on the ticket.http://jsfiddle.net/8wdfL6ph/

There are limited number of places and cases that jQuery throws errors on bad selector input. For example in the quoted spec you gave, we don't throw an error if there are duplicated IDs, or if the ID had escaped space characters for that matter. Usually the result is an empty set, but that's not guaranteed since the input is invalid. So it seems strange to go our of our way to single out one specific invalid input and throw an error just on that.

Even in#4321 the main reason it was fixed was because it was returningundefined rather than a set. The old behavior seems clearly bad, there's no other case I know of where a chaining method would returnundefined.

While we don't really go out of our way, Sizzle has been increasingly diligent about rejecting invalid input. I support letting Sizzle handle this particular case, especially since excepting it fromrquickExpr takes no extra code at all.

That should make it fall into the general case and die in the current convenient place, which is fine. I was more concerned about identifying cases we should deal with explicitly.

@gibson042 do you want to fix this in Sizzle?

It should already be correct in Sizzle... all this PR needs is a unit test.

It should already be correct in Sizzle... all this PR needs is a unit test.

Unit test already falling with this one, need to edit it and it would be finished

We have a unit test for this with the old 0-length behavior so we're changing things up. Since it's a 3.0 i'm okay with that.