Just click the run button in jsFiddle and bring up the Firefox error console to reproduce.

Thanks for taking the time to contribute to the jQuery project by writing a bug ticket and providing a testcase!

I tried your test case (with FF 3.6.12 on WinXP in Safe-Mode) and what you reported isn't a bug. The Firefox error console doesn't display an error, just a warning. Also check https://developer.mozilla.org/en/error_console.

In this case the warning can be safely neglected.

Ok, I stand corrected; it's a warning, not an error. But another ticket that was recently closed, http://bugs.jquery.com/ticket/7291, also related to a Firefox warning, not error, and as far as I know it wasn't invalidated just because it's a warning. That's the jQuery 1.4.3 Console Warning I mentioned, "Unknown pseudo-class or pseudo-element 'sizzle'" But you're the experts, so if you say ignore it, I haven't much choice. Thanks for replicating it at any rate, so I know it's not related to my setup.

Excuse me for asking, but why should I have warnings if I don't have anything wrong on page? When Firefox console fills up, it makes Firefox slower... So I get warnings on my pages all the time and filling up Firefox console. Any chance to fix this?

I too was getting this same "Unexpected token in attribute selector: '!'" error with jQuery 1.4.4. As catimp99 pointed out, jQuery 1.4.3 gives a different error. However, another site recommended falling back to jQuery 1.4.2, which I have now done. This resolved my problem and I am no longer getting inundated with these warning messages. So, until this issue is resolved, it is best to stay with jQuery 1.4.2.

Why was this ticket closed? If you Google this error message, you'll see posts all over the internet about this jQuery error....warning message.

Replying to [comment:7 Elbow Man]:

[...] However, another site recommended falling back to jQuery 1.4.2, which I have now done. [...] So, until this issue is resolved, it is best to stay with jQuery 1.4.2. Why was this ticket closed? If you Google this error message, you'll see posts all over the internet about this jQuery error....warning message.

I am left bewildered that you prefer following the recommendation on some random website over the information one of the jQuery core developers gives you.

I can only state it again: This is no error and can be safely neglected. There is nothing "bad" happening.

I think you guys are missing the point: Some developers spend hours if not days perfecting such as css, pixel alignment on graphics, compliant html code etc to provide profesional products to our clients.

Then after all of that we get 'warnings' while from a technical point of view I can agree that it's just a warning, but when the client brings it to your attention and you re-itterrate @its just a warning' well lets just say that in the majority your level of prefesionalism decreases. As one of my clients said to me 'If it were a car I would not take it from the garage until it was fixed' he has a point.

I to, if only to maintain a profesional image to my clients hav ereverted back to 1.4.2 until this 'warning' is fixed.

Jonathan Parker

It would be really helpful if someone would explain what the warning means and why it appears. I can probably live with the warning, but not without knowing why it happens.

This is a bug with non-zero developer cost.

I found this warning disconcerting as well, and took the time to do a google search and find this bug. It's apparent that hundreds, if not thousands of other developers are left scratching their heads at this strange warning. I for one wasted some time thinking it was a malformed DOCTYPE declaration...

The question is, how much developer time will be spent searching for a resolution to this non-problem? I'd guess hundreds or thousands of collective hours over time, even more if you include the repetitive nature of clearing the javascript error console.

If that's not enough of an argument, consider the fact that this behavior breaks one of the most important rules of any good library: Do What I Expect. I for one do not expect perfectly functioning software to be throwing warnings.

Please reopen. Thanks.

By the way this is happening on jquery 1.4.4 on Firefox 3.6 OSX 10.6

I found that the code row that cause the warning is the 4139:

(function(){
   var html = document.documentElement,
      matches = html.matchesSelector || html.mozMatchesSelector || html.webkitMatchesSelector || html.msMatchesSelector,
      pseudoWorks = false;

   try {
      // This should fail with an exception
      // Gecko does not error, returns false instead
--->      matches.call( document.documentElement, "[test!='']:sizzle" ); <---

Won't fix?!? Guess we'll be sticking with 1.4.2 from here forward.

I can only state it again: This is no error and can be safely neglected. There is nothing "bad" happening.

Accept that some plugins dont work correctly because of the error. colorBox for example fails. Ill go with the recommendations and fall back to the previous version.

I make one last attempt to respond on this ticket:

Two pieces of information beforehand which give more insight into the "history" of this warning:

• Ticket #7243 and the commit to fix that ticket. The fix is directly related to this warning.

• In ticket #7291 John Resig himself already stated

Yep - unfortunately this is an issue with Firefox - for some reason they throw an uncatchable warning that we can't prevent (they should be throwing an exception that we can catch).

Replying to [comment:10 jah@…]:

It would be really helpful if someone would explain what the warning means and why it appears. I can probably live with the warning, but not without knowing why it happens.

This warning only pops up in Firefox. No other browser that I'm aware of shows such a warning. The reason for this is a bug in Firefox.

The warning comes from a code piece within the Sizzle code (the jQuery selector engine). The code in question looks like this

var matches = html.mozMatchesSelector;

try {
    // This should fail with an exception
    // Gecko does not error, returns false instead
    matches.call( document.documentElement, "[test!='']:sizzle" );
} catch( pseudoError ) {
    pseudoWorks = true;
}

The comment already explains pretty good what is happening:

• Passing an invalid selector to matchesSelector should throw an exception
• Gecko < 2.0 doesn't correctly implement the function as defined by the W3C. It just returns false instead of throwing an exception.
• Firefox instead of throwing the exception logs a warning to the error console which is unpreventable by user code.
• This warning pops up in FF only
• It is triggered by a code snippet which is only needed because of FF and because we need to feature detect this wrong behavior.

Althouhg Gecko 2.0 (-> FF4) finally does fix the implementation of this function (it now correctly throws an exception) it still outputs a warning to the error console which still can't be prevented. -> Note that the code in question is wrapped in a try/catch but the warning gets logged anyway in FF4.

Further reading W3C matchesSelector() and W3C Rules for processing selectors

Replying to [comment:9 anonymous]:

[...] but when the client brings it to your attention and you re-itterrate @its just a warning' well lets just say that in the majority your level of prefesionalism decreases.

So you are saying you have clients which are tech-savvy enough to find and check the error console but they won't accept the fact that you did a perfect job and that a warning does not mean you are unprofessional, even when explained to them? That is indeed a bad situation. Hopefully the information in this response helps you to overcome this problem with your client. This isn't an issue with your work or jQuery doing something wrong. It's a bug in Firefox.

Replying to [comment:9 anonymous]:

>I think you guys are missing the point: Some developers spend hours if not days perfecting such as css, pixel alignment on graphics, compliant html code etc to provide profesional products to our clients. Then after all of that we get 'warnings'

Replying to [comment:11 josh@…]:

This is a bug with non-zero developer cost. [...] The question is, how much developer time will be spent searching for a resolution to this non-problem? I'd guess hundreds or thousands of collective hours over time, even more if you include the repetitive nature of clearing the javascript error console.

I can feel what you are saying, we are sitting in the same boat. Consider how many hours of our free-time (==no money) we spend to deliver jQuery to you, consider how many hours we lost to find out that FF doesn't correctly implement the function as defined by the W3C. The hours we lost to find a workaround for this. The hours we lost to find it logs an uncatchable warning when feature detecting this. The hours we loose to answer question/bug reports about this stupid FF behavior.

Replying to [comment:11 josh@…]:

If that's not enough of an argument, consider the fact that this behavior breaks one of the most important rules of any good library: Do What I Expect. I for one do not expect perfectly functioning software to be throwing warnings.

I completely agree with this argument. Firefox indeed breaks this rule. We neither would have expected a pretty good software like FF to unconditionally log warnings when it shouldn't.

Replying to [comment:15 anonymous]:

Accept that some plugins don`t work correctly because of the error. colorBox for example fails.

This is simply untrue. This warning can't have such an effect on ANY plugin or ANY javascript code for that matter. If the colorBox jQuery plugin doesn't work correctly anymore with the newest jQuery version you should report that to the plugins author and demand an updated version.

I'm surprised at the people who balk at the status "wontfix". I've been coding for 25 years, and a status of "wontfix" means all sorts of things from: "not our problem" , to "not in the spirit of our code", to "not a bug", etc. It's not a personal attack / doling out punishment, and it certainly isn't malicious refusal to help; it's a professional final decision & moving on. As soon as I saw that status, I thought--oh, okay, not jQuery's problem.

Further, experience tells us that warnings are exactly that: a program saying "Hey, by the way, in case you didn't mean to do this, I think I maybe found a problem, but if it works the way you expect, never mind, because, written by a human, I'm, NOT, AS, SMART, AS, A, HUMAN." I hope every one of you has to write a (pick a language) program someday that throws warnings and you're forced to decide whether your principles prevent you from continuing to use that language (because no good language, like C, or Java, or PHP, used in millions upon millions of devices, would ever throw warnings), or evaluate the warnings as "oh, that's just the compiler being silly; that's not a problem, actually", and (if necessary, explaining to your client's satisfaction because you own your experience) keep your job. What about all the expert programmers who just dispense with the nonsense and hide warnings from you? The warnings are still there, but now we're treading on bad policy. Suddenly, one group shuts up because they (wrongly) think there's nothing they should condider (whether or not is actually important), and another group chimes in because it's "unprofessional" to hide warnings that would be nice to know (but still aren't important).

Back to the subject, I am NOT part of the jQuery team, or at all related to the project; I am a code consumer. From my perspective, punishing experienced developers (by, e.g., refusing to use the new version) for implementing a *common/tried/true* bug-tracking system in *complimentary* code that other, experienced developers have little problem adjusting to simply means that you're limiting yourself to marginal programming, relegated to a set of doubtful hires, because we're looking for a little more experience in the people we hire. Even if you're not in the running for a programmer's job, it's like walking into a police station and complaining about the bulletproof glass because it doesn't suit you--but it's a police station (!) with its practical realities and its own culture. When in Rome (programmer's land), do as the Romans (programmers) do. If visitors need to take this observation personally, okay, but there's no reason for it (for me, the complainers, or the developers): "wontfix" is entirely the wrong target, and I'm grateful--at 5AM, trying to finish a project--for the efficiency. Thank you, dev team, for the excellent work, excellent code, and for sticking with jQuery for all this time.

I created the ticket originally, and I want to thank jitter for his lengthy, recent explanation. Back then, I wrote--if you say ignore it, I haven't much choice--and that's what I've been doing. If he told me then that it's due to a firefox bug, I would have been in his corner. Firefox is hardly perfect; just look at how much memory it uses.

So did anyone bother to file a bug on Firefox about this? I certainly didn't see one filed...

I've been reading through this thread and I'm pretty frustrated by the approach shown here. Honestly, despite that explanation of what "wontfix" means, the developer reaction does feel a bit like they are saying "We don't care, now buzz off with your funny little warning, man!"

The thing is, these mysterious warnings did start around maybe version 1.4, and they can't seem to get deemed. When one is gone, it is replaced by another.

Now I don't doubt that the problem is righteously in Firefox, and in a perfect world, it would be Firefox what fixes it. But in reality, it *should be jQuery that provides a workaround*. And not only because it was a change in jQuery that brought up the problem in the first place. Most importantly, because in reality it's easier to "bring Mohammad to the mountain" than "bring the mountain to Mohammad".

This whole affair reminds me of Internet Explorer being a never-ending source of headaches and frustrations for web developers and designer. We all new it's IE's poor implementation of W3C standards that breaks our designs. We hate(d) IE for that, but in the end it was us who had to adapt to its flaws, rather than hoping for Micro$oft to do as we please.

I understand the jQuery developers think their code is correct accord to W3C, and they feel reluctant to coding a workaround to a problem that's elsewhere. But if we waited for the change to happen in FF, we might well be too old for coding when it happens.

If the warnings offend thee, the workaround is to ignore or disable warnings in the Firebug console.

Another workaround would be to disable the use of the very fast native-code W3C-compliant Firefox querySelectorAll method and instead send all selectors through the Javascript-based Sizzle engine. So in return for working around the harmless Firefox warning, your code is much slower in Firefox and the blame for the performance hit falls on jQuery. Given a choice between being unjustly blamed for a Firefox warning and rightly blamed for a serious performance degradation, I'll take the unjust blame.

Replying to [comment:21 dmethvin]:

Oh, nice argument. At least rhetorically nice. But what about substance?

If the warnings offend thee, the workaround is to ignore or disable warnings in the Firebug console.

I first thought this "advice" was ironic. But alas it isn't. It is like saying "If you think IE sucks as a browser, stop using it." It's a poor advice even for end users, but unthinkable for designers. They ''still'' have to deal with IE.

Given a choice between being unjustly blamed for a Firefox warning and rightly blamed for a serious performance degradation, I'll take the unjust blame.

Though when you look at it from the other side, if the issue is resolved ''here'' instead of on the FF side, you take all the __fame__. (As I've read somewhere: ''"People with reactive attitude seek to avoid blame. People with proactive attitude seek to achieve fame."'' ;-))

But this is not about blame at all. It's about progress, and where it can be made first, realistically.

Finally, regarding performance: I don't see a significant performance gain from 1.4.2, which did not cause the warning, to 1.4.3 and above, which do. Whichever way 1.4.2 worked, it was fast enough, and it avoided the warning. So we already had a version that had both. I really don't know what "serious performance degradation" you are referring to.

This is a jquery issue so someone should be fixing it.

Warnings are not acceptable. Please fix this bug.

...> The warning comes from a code piece within the Sizzle code (the jQuery selector engine). The code in question looks like this

> var matches = html.mozMatchesSelector;
> 
> try {
>     // This should fail with an exception
>     // Gecko does not error, returns false instead
>     matches.call( document.documentElement, "[test!='']:sizzle" );
> } catch( pseudoError ) {
>     pseudoWorks = true;
> }
> 

The comment already explains pretty good what is happening: - Passing an invalid selector to matchesSelector should throw an exception - Gecko < 2.0 doesn't correctly implement the function as defined by the W3C. It just returns false instead of throwing an exception. - Firefox instead of throwing the exception logs a warning to the error console which is unpreventable by user code. - This warning pops up in FF only - It is triggered by a code snippet which is only needed because of FF and because we need to feature detect this wrong behavior. Althouhg Gecko 2.0 (-> FF4) finally does fix the implementation of this function (it now correctly throws an exception) it still outputs a warning to the error console which still can't be prevented. -> Note that the code in question is wrapped in a try/catch but the warning gets logged anyway in FF4.

>...>

Proposal line 4455 following:

try {
  // This should fail with an exception
  // Gecko does not error, returns false instead
  // <orig. $jquery-1.5:>
  // matches.call( document.documentElement, "[test!='']:sizzle" );
  // <proposal to Ticket #7535, 2011-02-03:> 
  // Gecko valid (resp. W3C invalid) selector match pattern
  pseudoWorks = ! matches.call(
    document.documentElement,
    "\\\\@-moz-  document \\\\{ body:-moz-first-node \\\\}" 
  );

} catch( pseudoError ) {
  pseudoWorks = true;
  // <testing only> alert('MalformedSelectorException: ' + pseudoWorks);
}

While some write that it is "just a warning", "there is nothing bad happening" etc, the bad thing that happens all the time since 1.4.3 is that many hours are spent on finding that non-existent '!' in code. And someone has to pay for all these hours.

And don't try to convince that "just a warning" is not an error. It is an error, it's just of different severity.

Just like many others - reverting to 1.4.2 (1.5? what? naaah.. reverting).

Replying to [comment:25 alexandro-fernandez@…]:

== Proposal line 4455 following: ==

> 
> try {
>   // This should fail with an exception
>   // Gecko does not error, returns false instead
>   // <orig. $jquery-1.5:>
>   // matches.call( document.documentElement, "[test!='']:sizzle" );
>   // <proposal to Ticket #7535, 2011-02-03:> 
>   // Gecko valid (resp. W3C invalid) selector match pattern
>   pseudoWorks = ! matches.call(
>     document.documentElement,
>     "\\\\@-moz-  document \\\\{ body:-moz-first-node \\\\}" 
>   );
> 
> } catch( pseudoError ) {
>   pseudoWorks = true;
>   // <testing only> alert('MalformedSelectorException: ' + pseudoWorks);
> }
> 
> 

\\\\@-moz-  document \\\\{ body:-moz-first-node \\\\

should be

 
\\\\@-moz-document \\\\{ body:-moz-first-node \\\\

without that gap

FYI, Firefox 4.0 will not produce the offending warning, starting with beta12; see https://bugzilla.mozilla.org/show_bug.cgi?id=631615 . We apologize for the inconvenience.

Replying to [comment:28 zackw@…]:

FYI, Firefox 4.0 will not produce the offending warning, starting with beta12; see https://bugzilla.mozilla.org/show_bug.cgi?id=631615. We apologize for the inconvenience.

So given that response, and the fact that the ticket is still closed, should we assume you are going to just sit it out until (a) FF 4 final comes out, (b) all FF users upgrade (that couple of million), and (c) everyone forgets there's been an issue in the first place?

And that even if [comment:25] and [comment:28] already give you an obviously easy workaround on a silver tablet?

Now how about a __clear__ position here?

It seems pretty obvious that '''you just don't wanna do it'''.

If so, don't just explain who's fault it is, and why it should be someone else who should take action. If you feel taking action yourself on this is completely out of question, than have the guts and tell us to stop asking for it, because we just ain't gonna get it! Period.

No doubt you are going to loose some of us, but at least everybody will know who is who and what is what.

Your move.

You guys whining and complaining about this really need to chill out. It's already been pointed out that the fault lies with Firefox and not these developers yet you're nagging and badgering them with your useless carrying on.

While I agree that it's annoying and outright frustrating when we take the time to perfect everything else, everyone still complaining about this needs to accept that it's nothing wrong with your code and, if necessary, explain that to your clients . . . or maybe even yourselves.

So please, stop acting like they need to apologise to you and fix things that clearly are not wrong on their end. The world is not going to end because Firefox has decided to be a PITA about this little issue.

Which is exactly what it is: little.

Clearing the error console repeatedly isn't really a workable way of developing.

Ignoring all warnings isn't either, of course

(and that suggestion feels rather insulting).

So I was stuck at jquery 1.4.2 due to this issue...

but thanks to Fernando, I'm looking forward to finally being able

to try out 1.5, with his patch.

Jquery guys... I love your product,

and I hope you'll incorporate Fernando's workaround (or another one) into your next release.

It would do a lot in the way of fixing your credibility

and professional image,

which you've tainted substantially (in my eyes anyway, but I doubt

I'm the only one) by the response you've shown so far to this problem.

In my view, Firefox had a bug and, yeah, they screwed up fixing it the first time. They're fixing it and seem to be acting in good faith,

and think I even saw an apology here...

I don't see that there's much else they can do beyond that.

So it's pretty clear to me that it's not Firefox that's making the conscious decision to be a PITA at this point.

Hmm. This is mildly irritating. I can understand not wanting to lace the code with messy workarounds for broken browsers, but I'd love to see a count of workarounds for IE[678] bugs there must be in the jquery source.

p.s. as others have said, I think sticking with 1.4.2 for now seems a good solution.

Ok I just came here searching for the cause of the warning. I am not even using jQuery, but I am using Sizzle. I guess it should have been a Sizzle ticket...

Not to nag you, just to let you know that, yes, developers do care about warnings. They will invest time in finding the cause for them. And they will end up here. Just count the posts asking to please implement the workaround, so we don't need to patch Sizzle ourselves... If there are many.. well just look at it as a crowd pleaser. :)

I just implemented the workaround from comment #25, seems to work like a charm. Gone is the warning! Thanks Alexandro!

I've looked through the proposed solution - unfortunately it is not sufficient.

The test in Sizzle is looking for two things: 1) Making sure that unknown pseudo-selectors throw an exception and 2) Making sure that unknown (specifically, !=) attribute selectors throw an exception. Both of these are done simultaneously and with the same test.

Right now the proposed solution only tests to see if unknown pseudo-selectors throw an exception (and only in non-Gecko-based browsers). The solution does not cover unknown attribute selectors and thus is insufficient. Right now the particular proposal is no different from just doing useragent sniffing - you're checking to see if an unrelated feature exists and if so assume that exceptions aren't thrown. Because of this when Firefox 4 comes out this proposed solution will continue to assume that the code doesn't work in Firefox - which is demonstrably not the case. It's no longer a feature test if the test continues to fail once the feature has been fixed.

I agree completely with the synopsis in [comment:16 jitter]. If another solution is proposed that covers both of the actual cases (and without using some level of inference) then we can absolutely go with that solution. Until that time though this bug will remain as 'wontfix'.

Replying to [comment:36 john]:

I've looked through the proposed solution - unfortunately it is not sufficient. The test in Sizzle is looking for two things: 1) Making sure that unknown pseudo-selectors throw an exception and 2) Making sure that unknown (specifically, !=) attribute selectors throw an exception. Both of these are done simultaneously and with the same test. Right now the proposed solution only tests to see if unknown pseudo-selectors throw an exception (and only in non-Gecko-based browsers). The solution does not cover unknown attribute selectors and thus is insufficient. Right now the particular proposal is no different from just doing useragent sniffing - you're checking to see if an unrelated feature exists and if so assume that exceptions aren't thrown. Because of this when Firefox 4 comes out this proposed solution will continue to assume that the code doesn't work in Firefox - which is demonstrably not the case. It's no longer a feature test if the test continues to fail once the feature has been fixed. I agree completely with the synopsis in [comment:16 jitter]. If another solution is proposed that covers both of the actual cases (and without using some level of inference) then we can absolutely go with that solution. Until that time though this bug will remain as 'wontfix'.

line 4455: Revision of [comment:25]:

  try {
    // This should fail with an exception
    // Gecko does not error, returns false instead
    // <orig. $jquery-1.5:>
    // matches.call( document.documentElement, "[test!='']:sizzle" );
    // <proposal to Ticket #7535, 2011-02-20:>
    // (1) tests  if gecko 1.8+ only pseudo el. does not match 
    // (2) checks if gecko 2+ only method (WCAG-Proposal) is available
    if( ! matches.call( html.firstChild, ":-moz-first-node" ) ||
          document.currentScript ) {
    // (3) tests matchesSelector implementation v.s. line 4452 
          matches.call( html, " [test!='']:-moz-first-node" );
    }
  } catch( pseudoError ) {
    pseudoWorks = true;
  }
  // <testing only>
  // alert('MalformedSelectorException thrown: ' + pseudoWorks);

@john

THX for your review.

''Guesses:''

It seems that firefox (gecko 1.8+) developers had a different point of view regarding css error handling:

• If an css syntax error occurs, the css parser handles it.
• By creating a invalid (virtual) css selector, the exception thrown in the css parser is not passed to the js parser. (webdeveloper shows a css and not a js warning).
• The js function matchesSelector (prior gecko 2.0+) makes no destinction between right or wrong css syntax and returns whatever the css parser says.

''Further thoughts:''

As you may know jQueryUI creates lots of css warnings (e.g. proprietary ie filters). In a jQueryUI environment, one css warning or less is not worth debating on it.

But if you use jQuery as is, the webdeveloper toolbar always shows a red css error button (warnings and errors are handled equally).

A webdesigner has no benefit from this css button anymore, as on every test drive he must check the error console. Sever css issues won't strike his eye.

''In conclusion:''

I'd say this is not a bug (neither in Firefox nor in jQuery).Fixing this interpretation thing though, would make css validation eye-catching again. Besides, Firefox 3 will probably remain primary working environment for many webdesigners in the near future, as mozilla plugins take their time to be updated to Firefox 4.

Handling this issue on jQuery side, makes much more sense than wainting for a Firefox fix (obviously there are more roadworks on bugs.mozilla.org then here in this place).

And...

Many a little makes a mickle.

I got this error, and it made me twitch, but had already decided *I STILL LOVE JQUERY!!!*

Thanks to the jQuery community for a totallysuperawesome tool!

p.s. Then I came here and found it is root-caused in Firefox.

@john

Thanks for reviewing the suggested patch. I take it that if we use the patch from comment:25 we get a suboptimal Sizzle on Firefox 4 because it will be assuming a bug still exists in Firefox 4 that actually has been fixed? That is a shame indeed, thanks for pointing that out.

Now I see that in comment:37 anonymous is suggesting a changed patch that supposedly doesn't suffer from the same problem. I am by no means an expert in this stuff (far from it, I trust on jQuery for this :) but I read this second patch to work like this:

He splits the test into two parts. The first part does not generate the warning message and will fail on Firefox 3. The second part does generate the warning on Firefox 3, but because the first one already failed it will never be evaluated on that browser. On Firefox 4 however the first part succeeds and it goes on to the second part. Because the warning problem is apparently fixed (or will be?) on Firefox 4 we don't get the warning but we do get a trustworthy result that is equivalent to the original test?

I hope you get the time to review (and hopefully implement!) this fixed patch... Until then I (never thought I would say this) will have to just trust anonymous for writing good code. :) Changing my patch to the one from comment:37...

I can't live with the warning and can't live with using an old Sizzle version either! :)

I agree 100% with Jonathan Parker (comment 9)

The childishness of these responses is ridiculousness. There is nothing wrong with jQuery. If you want to find a hack to work through a problem created by FF please do so and post it. As it stands however, this warning interferes with nothing and jQuery is being completely compliant with ww3 standards so they have no obligation to fix it.

Would anyone from jquery care to comment on the solution proposed in comment 36? I noticed the first solution was shot down within 2 weeks, but it's currently been 5 weeks since the new one was offered and jquery dev is still mum. Is there anything wrong with this solution? If there is, please let us all know, and if not, when will it be adapted?

BTW, many of us develop web apps that are tested on and need to work cleanly with mainstream browsers like IE and FF. At the end of the day, regardless of who's problem it might really be, I have to make sure all my code works without any errors or warnings, no ifs or buts about it. It's not acceptable to brush it off or ignore it, and I would expect the same from jquery, which I consider a professional dev team.

I'm currently resorting to v1.4.2, but hope to see some resolution to this soon.

Replying to [comment:37 anonymous]:

line 4455: Revision of [comment:25]:

>   try {
>     // This should fail with an exception
>     // Gecko does not error, returns false instead
>     // <orig. $jquery-1.5:>
>     // matches.call( document.documentElement, "[test!='']:sizzle" );
>     // <proposal to Ticket #7535, 2011-02-20:>
>     // (1) tests  if gecko 1.8+ only pseudo el. does not match 
>     // (2) checks if gecko 2+ only method (WCAG-Proposal) is available
>     if( ! matches.call( html.firstChild, ":-moz-first-node" ) ||
>           document.currentScript ) {
>     // (3) tests matchesSelector implementation v.s. line 4452 
>           matches.call( html, " [test!='']:-moz-first-node" );
>     }
>   } catch( pseudoError ) {
>     pseudoWorks = true;
>   }
>   // <testing only>
>   // alert('MalformedSelectorException thrown: ' + pseudoWorks);
> 

Unfortunately this proposed change is still checking for Gecko-centric selectors and properties - which really makes no sense. We need to be testing != in all browsers, not just a subset of those browsers - and not using browser-specific hacks to arrive at those results. Since the :-moz-first-node test throws an exception in every browser but Firefox - and the second test reduces Firefox to just 4.0 and newer - it means that the != test is really only running in Firefox 4.0 and newer, which is unacceptable. I'm still open to any solution that can do this without browser-specific hacks.

Thanks John,

for spending time on reviewing the proposed workarounds.

Here is (hopfully) the final solution to this issue:

line 4455: Revision 2 of comment 25:

  try {
    // This should fail with an exception
    // Gecko does not error, returns false instead
    // <orig. $jquery-1.5:>
    // matches.call( document.documentElement, "[test!='']:sizzle" );
    // <proposal to Ticket #7535, 2011-03-24:>
      if( ! html.mozMatchesSelector || document.currentScript ){
        matches.call( html, "[test!='']:sizzle" );
      }
    //else{
    // /*FF lt 4*/
    //}
  } catch( pseudoError ) {
    pseudoWorks = true;
  }
  // <testing only>
  // alert('MalformedSelectorException thrown: ' + pseudoWorks );

The solution is in the air, I can smell it :-)

Cheers!

Alex

So I was experiencing the same error message with jQuery 1.5.1 while traying to append to an empty div:

$("#div-id").append("<code>...</code>");

It works if the div element I'm trying to append is not empty, however if it's empty it triggers the error message.

Finally I realized I was doing tests without properly formed html document. So added the correct <html><head></head><body>...</body></html>, may things work without any errors.

So have that in count.

Fco.

It worked OK for me in Firefox 4 I when I included the jquery JS file like this:

<script src='jquery.js'></script>

as opposed to:

<script src='jquery.js' />

So should not this count as a Firefox bug?

That counts as invalid markup.

Oops~ Thanks for telling!

Replying to [comment:30 anonymous]:

You guys whining and complaining about this really need to chill out. It's already been pointed out that the fault lies with Firefox and not these developers yet you're nagging and badgering them with your useless carrying on.

So, why do jQuery's team try to fix things which are IE's bugs ?

OK, this problem was fixed by Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=631615), but many countries even use old versions browsers 'cuz they don't have the money for a good machine or for many reasons that I won't comment here ...

Now, I'm not saying "c'mon, fix everything for old versions browsers", it would be the last straw, but if this problem many people needs a solution, I think it would be perfect to give a solution ... of course, if that wasn't so "complicated".

Having read through the above comments, I wish to draw your attention to the following issue, which results in the warning being discussed above, but breaks functionality (no errors, 1 warning). The following code works in all browsers (jquery 1.4.2)

<html>

<script type="text/javascript" src="jquery-1.4.2.min.js"></script>

<script type="text/javascript" src="jquery.xslt.js"></script>

<body>

<div id="transformResult"></div>

<script type="text/javascript">

$(function() {

$('#transformResult').xslt("/web/example.xml", "/web/example.xsl");

});

</script>

</body>

</html>

but the following fails in firefox (jquery 1.6 - also tested 1.5.4)

<html>

<script type="text/javascript" src="jquery-1.6.min.js"></script>

<script type="text/javascript" src="jquery.xslt.js"></script>

<body>

<div id="transformResult"></div>

<script type="text/javascript">

$(function() {

$('#transformResult').xslt("/web/example.xml", "/web/example.xsl");

});

</script>

</body>

</html>

The only difference is the jquery version. I would be interested in a fix for this, so I can use the latest jquery.

kind regards,

Steve

(p.s. left as closed as the bug may relate to firefox or xslt plugin)

Wow!

No warnings and I save bandwidth.

1.4.2 is awesome!

Alas no comments on the validity of the patch proposed by Alex in comment:45...

Going to use it none the less. I prefer a suboptimal sizzle over one that throws warnings.

Any one care to comment on why it is not good? If it is good, can;t we just get over it and apply it?

Hi Alex

I try to use your solutions in JQuery 1.7 .

But is not fixed.

try {

This should fail with an exception

Gecko does not error, returns false instead

//matches.call(document.documentElement, "[test!='']:sizzle"); >>> error

if (!html.mozMatchesSelector || document.currentScript) {

matches.call(html, "[test!='']:sizzle");

}

} catch (pseudoError) {

pseudoWorks = true;

}

I'm using Chrome 18.0.1025.162 m

'''matches.call(html, "[test!='']:sizzle");: [Exception: Error: SYNTAX_ERR: DOM Exception 12]

Replying to [comment:45 anonymous]:

Thanks John, for spending time on reviewing the proposed workarounds. Here is (hopfully) the final solution to this issue: line 4455: Revision 2 of comment 25:'''

>   try {
>     // This should fail with an exception
>     // Gecko does not error, returns false instead
>     // <orig. $jquery-1.5:>
>     // matches.call( document.documentElement, "[test!='']:sizzle" );
>     // <proposal to Ticket #7535, 2011-03-24:>
>       if( ! html.mozMatchesSelector || document.currentScript ){
>         matches.call( html, "[test!='']:sizzle" );
>       }
>     //else{
>     // /*FF lt 4*/
>     //}
>   } catch( pseudoError ) {
>     pseudoWorks = true;
>   }
>   // <testing only>
>   // alert('MalformedSelectorException thrown: ' + pseudoWorks );
> 

The solution is in the air, I can smell it :-) Cheers! Alex

I don't know why, but I'm getting this same error in Visual Studio 2012. And it's not a warning. It stops my code from running.

#12195 is a duplicate of this ticket.