Let's make one so people can't complain it's hard.

In all versions of jquery after 1.8.3 calling the html method with trueor false produces two different behaviors. If you look at the this test case you will see that there are two <p> elements having their html set with html(true) and html(false). That test case uses the latest 2.x version of jQuery. We see the same behavior in this test case using the latest 1.x version of jQuery. Following the version backwards we can see the following:

Version 1.8.3 test case -- neither of the html calls write anything to the elements.
Version 1.9.1(and all future versions) test case -- calling html with true writes true to the element while calling with false writes nothing.

While this is not a serious issue, it would be preferable for the html method to act the same for both boolean values. While the 1.8.3 behavior wrote nothing, it was at least consistent for both true and false. It seems to me that html should either go back to writing nothing in both cases or writing "true" for true(as it does now) and "false" for false.

This behavior was tested on Chome 37.0.2062.124, Safari 7.0.6 (9537.78.2), and Firefox 32.0.3 and identical behavior was seen in all three browsers.

There are at least references in CONTRIBUTING.md and in package.json (thx arthurvr!) but there may be more.

jquery.com & friends will need to be updated as well.

http://bugs.jquery.com/ticket/5280

The fix was to put the following

jQuery( window ).on( "unload", function() {
    for ( var key in xhrCallbacks ) {
        xhrCallbacks[ key ]();
    }
});

in xhr.js
However, this makes 'xhr' dependent on 'events' and if you were to create your own custom build with '-events', it will give error on IE9 "... doesn't support property or method 'on'"

IE9 supports window.onbeforeunload. May be we should use that instead.

$.each('rrrrrrr',function(){});

The method should be verified for the parameters;
eg:

if(/\[object Object\]|\[object Array\]/.test(Object.prototype.toString.call(params))){
//todosomething
}

Originally reported by @jzaefferer: http://bugs.jquery.com/ticket/14509

From the Amsterdam team meeting:

Create $.xhr which is based on $.ajax but without any of the legacy options (async:false) or things specific for non-xhr (jsonp/script)

Options to keep:

• beforeSend (expose the native xhr so we can cover the removed xhrFields option)*
• cache (possibly rename to something like noCache)*
• data (if not a string: will use default $.param and append to url for GET requests, otherwise * send as * * request body, as today)
• headers
• method (aka ‘type’)
• username
• password
• url
• timeout

Options to remove:

• accept (use headers)
• async (use a different method for sync requests)
• contents (do custom parsing yourself)
• contentType (use headers)
• context (use $.proxy)
• converters (global hash of convertors or do it yourself)
• crossDomain (non-xhr)
• dataFilter (do it yourself)
• dataType (jq will use response’s content-type)
• global (everything should be consistent)
• ifModified (make it a plugin)
• isLocal (expose localProtocols as a global config array instead)
• jsonp (non-xhr)
• jsonpCallback (non-xhr)
• processData (who knows? no one is sending XML documents anymore, right?)
• scriptCharset (non-xhr)
• statusCode (handle the responses yourself)
• mimeType (don’t override stuff)
• scriptCharset (non-xhr)
• success/error/complete (legacy)
• traditional (convert the data option to a string with $.param(.., true) yourself)
• xhr
• xhrFields (use beforeSend instead)

As the first step, this would delegate to $.ajax. Eventually it should be possible to build jQuery with just this interface, without any of the other methods like $.get, $.getJSON or even $.ajax.

When making an ajax-request to a http-url from a page loaded over https, the request is blocked in Chrome 38, but neither the error handler nor the complete handler functions are called.

In Safari 7, the request succeeds (with a warning) and the success and complete handlers are called.
In Firefox 32, the request fails and the error and complete handlers are called.

Example: https://openascent.org/static/ajax-chrome.html

Originally reported by ripdog: http://bugs.jquery.com/ticket/15239

The docs for .position() clearly state that they return the "current position of an element relative to the offset parent." - explicitly not the position based on the viewport. However, .position does report different results based on where it is moved on the page due to scrolling.

Here's a fiddle: http://jsfiddle.net/6g5upsvq/ Click the button, then scroll and click it again. The .offsetTop direct from the DOM stays constant, but .position changes.

Originally reported by @jzaefferer at: http://bugs.jquery.com/ticket/14510

Discussed this at the jQuery team meeting in Amsterdam: The spec is still changing a lot (within whatwg and draft pages on github), so we'll wait for it to ship, unprefixed, not behind a flag, in stable browsers first.

Once that happened, we should change/fix our implementation to match the spec (and shipped implementation).

Can use .pipe() to continue using any jQuery-specific functionality.

Reproduced here: http://jsfiddle.net/8w22tgao/

For instance if the form has the style-rule "display: inline" and contains a div-element as first child, $('form').is(':hidden') returns true.

It appears that the problem only occur if the first child-element of the form is a block-node (display: block). The bug also only appears in Chrome and Safari, not in Firefox.

Open console in browser and run
http://jsfiddle.net/471rpspj

Chrome 38 added support for ES6 for-of. I'm proposing that jQuery collections are made compatible with this statement, which can be achieved with this line (from discussion on Twitter):

jQuery.prototype[Symbol.iterator] = Array.prototype.values;

Live demo: http://jsbin.com/movuxu/1/edit (view in Chrome)

Originally reported by dmethvin at: http://bugs.jquery.com/ticket/10198

We need to run the unit tests with an XHTML doctype to ensure that everything passes.

Issue reported for jQuery 1.6.3

I'm not 100% sure this is a issue because I can reproduce it starting from jQuery 1.6 and I don't think it could hide itself for so much time. However I noted that width() returns a rounded width of an element, not the "computed width" as asserted by the documentation.

I've created a dummy demo but basically if you set the width of an element to say 10.5px, width() returns 11.

Originally reported by Jogi: http://bugs.jquery.com/ticket/15104

Issue with space in selector with jquery 1.11.1 and Internet explorer.

exemple:

$(".testCls [name='blabla']")

cannot find anything when with older version, it work.

jsfiddle: http://jsfiddle.net/kwfHZ/1/

The third variation of toggleClass method in documentation is as follows:
.toggleClass( [switch ] )
switch
Type: Boolean
A boolean value to determine whether the class should be added or removed.

It says "the" class, while no particular class is specified, and it toggles all the class names present in the matched elements.

it would be great if the documentation reads the same.

As a side note:

Also, at later point, the docs says:

if no arguments are passed to .toggleClass(), all class names on the element the first time .toggleClass() is called will be toggled.

It would be nice if it is added as the first variant of the method, along with a better description other than "all class names on the element the first time .toggleClass() is called will be toggled"? " Something like "all class names that were present on the element when .toggleClass() is called for the first time will be toggled" will be better IMHO.

Originally reported by petka_antonov@… at: http://bugs.jquery.com/ticket/12031

Doing OOP with jQuery events requires a lot of $.proxy boilerplate. the .addEventListener interface allows passing an object as a handler like so:

function SomeWidget( elem ) {
    this.elem = elem;
}

SomeWidget.prototype = {
    constructor: SomeWidget,

```
renderTo: function( target ) {
    $(target).append(this.elem);
    this.elem.addEventListener( "click", this );
    this.elem.addEventListener( "mousemove", this );
},

mousemove: function( e ) {

},

click: function( e ) {

},

handleEvent: function( e ) {
    return this[e.type].apply( this, arguments );
}
```

};

With jQuery you have to do this:

function SomeWidget( elem ) {
    this.elem = elem;
    //Each method needs to be bound to the instance. This also has overhead of creating many functions.
    this.mousemove = $.proxy( this.mousemove, this );
    this.click = $.proxy( this.click, this );
}
SomeWidget.prototype = {

constructor: SomeWidget,
renderTo: function( target ) {
    $(target).append(this.elem);
    $(this.elem).on( {
        click: this.click,
        mousemove: this.mousemove
    });
},

mousemove: function( e ) {

},

click: function( e ) {

}

};



With jQuery supporting objects as event handlers, it would work like:

function SomeWidget( elem ) {
    this.elem = elem;
}
SomeWidget.prototype = {

constructor: SomeWidget,
renderTo: function( target ) {
    $(target).append(this.elem);
    $(this.elem).on( "click mousemove", this );
},

mousemove: function( e ) {

},

click: function( e ) {

},

handleEvent: function( e ) {
    return this[e.type].apply( this, arguments );
}

};



And that's it. No $.proxy hacks, no redundant creation of functions just to retain binding.
Issue reported for jQuery 1.7.2
    

When setting opacity to an element in IE8+, according to http://www.quirksmode.org/css/opacity.html I can use

.opacity {
    filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=50);
    opacity: 0.5;
}

note that the opacity in IE8 filter is in upper case

but jQuery 1.* currently only support getting the result setted in lower case opacity, like filter: progid:DXImageTransform.Microsoft.Alpha(opacity=50);

see demo http://jsfiddle.net/c9d5ctfa/ in IE8

Also in MSDN, both upper case and lower case are used in the examples.

My PR: #1704

Originally reported by john.david.dalton@… at: http://bugs.jquery.com/ticket/11570

Soo way back in 2005 Dean Edwards proposed an event system that slapped the listeners on the actual element. This allowed cache to be destroyed once the element was GC'ed.  http://dean.edwards.name/weblog/2005/10/add-event2/

Over the weekend Peter Michaux proposed a similar solution:  https://twitter.com/#!/petermichaux/status/189012245483757568  https://github.com/petermichaux/evento/blob/bd065a9b254a8d14b956ec438dc06c29622c3ef6/src/eventTarget.js#L165

I noticed that jQuery supports events on vanilla objects too so this change would align elements and objects.

The gist is that since jQuery is already adding an expando for a UID they can just use that property as the actual storage for the element.

Then all the code to recursively clean .removed'ed elements event/custom data could be removed as when the element is GC'ed that data is destroyed.

Issue reported for jQuery git

Hello,

When I try to install jquery with bower, nothing is extracted in bower_components excepted 2 files: .bower.json and index.

Here is the output I get:
C:\npm>bower install http://github.com/jquery/jquery -V
bower jquery#* cached http://github.com/jquery/jquery#e-tag:2f8d55f95
bower jquery#* validate e-tag:2f8d55f95 against http://github.com/jquery/jquery#*
bower jquery#* new version for http://github.com/jquery/jquery#*
bower jquery#* resolve http://github.com/jquery/jquery#*
bower jquery#* download http://github.com/jquery/jquery
bower jquery#* resolved http://github.com/jquery/jquery#e-tag:ebe029cc9
bower jquery#* install jquery#e-tag:ebe029cc9

jquery#e-tag:ebe029cc9 bower_components\jquery

My system info:
Bower version: 1.3.2
Node version: 0.10.29
OS: Windows_NT 6.1.7600 x64

Is there something wrong I did?

Originally reported by superbulldeng@… at: http://bugs.jquery.com/ticket/10190

There is a "upload" property in the xhr object returned by new XMLHttpRequest() in supported browser. But the object returned by $.ajax() seems didn't contain this property. This property is important to get the state of file upload progress.

Issue reported for jQuery 1.6.3

Originally reported by joshpeek at: http://bugs.jquery.com/ticket/9885

Adds global ajaxBeforeSend to complement local beforeSend event.

 https://github.com/jquery/jquery/pull/439

Issue reported for jQuery 1.6.2

The native XMLHttpRequest API doesn't have methods to get request headers. It would be useful to add one to the jqXHR object, to facilitate debugging and test automation. While $.ajaxSetup() or direct $.ajax() calls pass headers directly, a full-proof way to get request headers just before they're sent would need to take into consideration that headers can be added via beforeSend:

jqXHR.setRequestHeader('headerKey', headerValue);

User requests dating back from 2011 suggest this would be a useful feature:
http://stackoverflow.com/questions/7564007/get-sent-headers-in-an-xmlhttprequest
http://stackoverflow.com/questions/9102279/is-there-a-way-to-get-all-the-request-headers-in-a-jquery-ajax-call
... and "request headers" showing up in Google's autocomplete when searching for "jqXHR get".

Originally reported by vsevik@… at: http://bugs.jquery.com/ticket/11484

This ticket is inspired by discussion in Chrome Developer Tools mailing group:  https://groups.google.com/group/google-chrome-developer-tools/browse_thread/thread/e22f4cb5b0685dbd

SourceURL is a way to give a name to the script executed by eval() for debugging purposes. See  http://blog.getfirebug.com/2009/08/11/give-your-eval-a-name-with-sourceurl/

Adding sourceURL to scripts loaded by domManip would make debugging easier. example: $('head').append('<script src="test.js'></script>');

Similar (but different) request http://bugs.jquery.com/ticket/8292 was closed as wontfix earlier, so some comments on the reasons mentioned there:

This is a functionality that:

• only developers will need while debugging

Yes, but is very valuable for developers and it comes with virtually zero cost for users.

• is only useful for Chrome users

sourceURL is supported by Firefox and WebKit (Chrome, Safari) which makes together more than 60% of browser market share.

• is of limited use as the names would need to be randomly generated

In the example mentioned above the url could and should be taken from the src attribute of the script tag. This is the same url the script was loaded from.

Vsevolod Vlasov, webkit reviewer

Issue reported for jQuery 1.7.1

use jquery 2.1.1;

<form>
    <input type="text"  name="nodeName"> 
</form>

error :

Uncaught TypeError: undefined is not a function jquery-2.1.1.js:1610

1603: filter: {
1604:
1605:       "TAG": function( nodeNameSelector ) {
1606:           var nodeName = nodeNameSelector.replace( runescape, funescape ).toLowerCase();
1607:           return nodeNameSelector === "*" ?
1608:               function() { return true; } :
1609:               function( elem ) {
1610:                   return elem.nodeName && elem.nodeName.toLowerCase() === nodeName;
1611:               };
1612:       },

Originally reported by pferreir at: http://bugs.jquery.com/ticket/10495

While trying to inject the Facebook "like button" JS in a page in execution time, I got some funny behavior:

var fjs = $('script:first');
$('<script/>').attr({'async': true, 'src': '//connect.facebook.net/en_US/all.js#xfbml=1&appId=xxx'}).insertBefore(fjs)

fails (same with the equivalent before() call).

While

var fjs = $('script:first').get(0);
var e = $('<script/>').attr({'async': true, 'src': '//connect.facebook.net/en_US/all.js#xfbml=1&appId=xxx'}).get(0);
fjs.parentNode.insertBefore(e, fjs)

works just ok.

I tried different combinations of native/jQuery elements and they all fail. This happens at least since 1.6.1.

Issue reported for jQuery git

Originally reported by daliuskal@… at: http://bugs.jquery.com/ticket/14839

 http://jsfiddle.net/6DLSw/12/ 2s+ first time, ~50ms later on. The first run is extremely slow.

 http://jsfiddle.net/6DLSw/13/ ~50ms when jQuery.data(el) was already called (note that the key doesn't matter).

The bug seems to have started with version 2.0.2 or so, when the jQuery.data was rewritten.

Using 1.11.0 on first case takes ~190ms first time, other times it's ~60ms.

This is affecting jquery ui performance very badly, e.g.  http://jsfiddle.net/6DLSw/6/ - first red rectangle drop takes 2s+.

Issue reported for jQuery 2.1.0

The .offset() function documentation states:

Get the current coordinates of the first element, or set the coordinates of every element, in the set of matched elements, relative to the document.

However in reality it returns coordinates relative to the closest parent document-fragment (shadow-root). To demonstrate this I have set up this simple test. My test also contains a simple patch which fixes the problem for the set of browsers that I tested on (Chrome 37+, Firefox 31+, IE 11). I'm not sure how to handle the set-coordinates part of the function's behavior (which I don't really use) so my patch only handles the get path.

There are a bunch of other libraries which depend on offset() which are affected by this - I've setup tests for a couple of them here and here.

Originally reported by hungerandthirst@… at: http://bugs.jquery.com/ticket/9883

The jQuery docs explicitly state that "No onreadystatechange mechanism is provided, however, since success, error, complete and statusCode cover all conceivable requirements."

Frankly I think that's limiting users unnecessarily. What if I want to respond to something when I get headers back? What if I want to know when I start receiving content back from the server?

An excellent example of this is using jQuery for bandwidth testing. Without a way to detect when I initially receive content back from the server (not just beforeSend), I will also include any delay spent waiting for the server to respond.

I've added support for the RECEIVE_HEADER and LOADING event as per the XMLHttpRequest specs in  this pull request.

I would also like to see support for onreadystatechange as well since those are valuable states that we are only limiting ourselves and losing value by not tracking.

Issue reported for jQuery git

Using $('<html>') I can get back a collection of a single HTMLHtmlElement, but doing this with some attributes (e.g.: $('<html class="js">'), returns an empty collection. I think this happens because the first case goes through document.createElement, while the second does not and falls into a innerHTML parser.

Originally reported by tde: http://bugs.jquery.com/ticket/14038

API documentation specifies: "Note that .width("value") sets the content width of the box regardless of the value of the CSS box-sizing property."

There are two key factors leading to this bug

"box-sizing:border-box"
"border:1px solid black"
width specified in ems
Code that reproduces this bug

<html>
    <head>
        <style>
            #container {width:100%;}
            #box {border:1px solid black; margin:0 auto; box-sizing:border-box;}
        </style>
        <script type="text/javascript" src="http://code.jquery.com/jquery-2.0.1.js"></script>
        <script>
            var $ = jQuery.noConflict();
            $(document).ready(function() {
                $('#box').width('10em'); // width should be 10em, but jquery set it to 12em
            });
        </script>
    </head>
    <body>
        <div id="container">
            <div id="box">
                <p>some text</p>
            </div>
        </div>
    </body>
</html>

e.g. resolve

jQuery(document.activeElement, form)

to

jQuery(form).find(document.activeElement)

Compare: http://jsfiddle.net/7vLserb1/

Originally reported by alexanmtz at: http://bugs.jquery.com/ticket/8556

As you can see in live example:  http://jsfiddle.net/FRbyf/6/

The fadeIn or any opacity animation doesn't work when applied in element that his child have a position different from static.

All browsers work as expected except IE7 and IE8.

Issue reported for jQuery 1.4.4

http://jsperf.com/jquery-off-with-callback/2 found by @doochik.

This probably happens because of the recursion, it's still fast though, in absolute numbers that is, but i wonder if could do better?

I'm thinking if we could do something, it should not hurt the byte size, otherwise it too much of the edge case to do something drastic.

if you call $("#someid").html( htmlString ) when htmlString contains malformed tags, the malformed
tags are silently dropped.

For example, http://jsbin.com/bucik/1/edit?html,console,output

This should not be silent, a warning should be logged.

See #1684 (comment) for latest update.

In case of body {zoom: 1.2} (or 1.1, 1.6) on Safari, get div.offsetWidth === 3, then body's zoom forcibly set 1 on this:
https://github.com/jquery/jquery/blob/master/test/data/jquery-1.9.1.js#L1519

Check this below.
https://gist.github.com/tgfjt/ce0d9e419036904649de

I know that jQuery.clean is a core function that convert html text to DOM,but I didn't found it in 1.11.0 version?And it seems like rename jQuery.cleanData?

Originally reported by antti@… at: http://bugs.jquery.com/ticket/14989

It is sometimes annoying that $(window).width() or $(window).outerWidth() do not include the scrollbar width in their value. Especially when trying to match the window width to the CSS media queries.

Currently e.g. if you have a media query in the CSS such as

@media screen and (max-width: 1600px) {
  body {background: red;}
}

When the red background is actually applied to the document by the browser, jQuery tells the window width is less than 1600px (1600 - scrollbar width).

This is annoying e.g. in cases where there are some mobile-specific stuff that needs to be done in both, CSS and JS. And they would need to be done at the exactly same width of the document/window.

However, plain JavaScript returns 1600 as the window width when asked at the point of the breakpoint as follows:

console.log(window.innerWidth);

Is it possible to get either $(window).width() or $(windor).outerWidth() working consistently with the browser's actual width? $(document).width() and $('body').width() will not return the same as "window.innerWidth" either, they return the same as $(window).width() and $(window).outerWidth().

Fixing this would greatly help making consistent code with the CSS media queries.

Possible workarounds currently are:

• Using plain javascript, i.e. window.innerWidth
• Checking $('...').is(':visible') for some element that is visible only in the target width

Here's an example of what I mean:  http://jsfiddle.net/aq5vb/

Issue reported for jQuery 2.1.0

Originally reported by @dmethvin: http://bugs.jquery.com/ticket/15141

Not sure if it's practical to cherry-pick, and there will be several additional code blocks that need cleanup.

Ref d837f11

$.expr() doesn't work.

It doesn't work when I want to create a user-defined selector by using the$.expr().

My code:

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>jQuery User Guide——user-defined selector</title>
    <script src="http://code.jquery.com/jquery-1.8.3.min.js"></script>
    <style>
        body{font-size:13px}
        div{width: 260px;padding-left: 10px;font-size: 13px;line-height: 23px;background-color: #eee;}
    </style>
</head>
<body>
    <script> 
        ;(function($){
            $.extend($.expr[':'],{
                'between':function(elem,index,match){
                    var arrSingle=match[3].split('-');
                    return arrSingle[0]<=index&&index<=arrSingle[1];
                }
            });
        })(jQuery);

        $(function(){
            for(var i=0;i<10;i++){
                $('<div>'+i+'</div>').appendTo('body');
            }
            $('div:between(3-6)').css({'background':'#555','color':'#fff'});
        });
    </script>
</body>
</html>

I search many pages and look up some books and turtorials to find the reason why the code doesn't work,but I failed.Few people use $.expr().Many people maybe have no need to create a user-defined selector.But I find the reason by comparing with the the older version jQuery finally.

I use thejquery-1.8.3.js and jquery-1.4.2.js to run this code.
It works with jquery-1.4.2.js and doesn't work with jquery-1.8.3.js.

In jquery-1.4.2.js,the $.expr()'s index argument is the true index of the element argument.

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>jQuery User Guide——user-defined selector</title>
    <script src="http://code.jquery.com/jquery-1.4.2.min.js"></script>
    <style>
        body{font-size:13px}
        div{width: 260px;padding-left: 10px;font-size: 13px;line-height: 23px;background-color: #eee;}
    </style>
</head>
<body>
    <script> 
        ;(function($){
            $.extend($.expr[':'],{
                'between':function(elem,index,match){
                    var arrSingle=match[3].split('-');
                   //index is true index of elem
                   //console.log(index);
                    return arrSingle[0]<=index&&index<=arrSingle[1];
                }
            });
        })(jQuery);

        $(function(){
            for(var i=0;i<10;i++){
                $('<div>'+i+'</div>').appendTo('body');
            }
            $('div:between(3-6)').css({'background':'#555','color':'#fff'});
        });
    </script>
</body>
</html>

In jquery-1.8.3.js the $.expr()'s index argument is 0 all the time,the index is not the true element's index.

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>jQuery User Guide——user-defined selector</title>
    <script src="http://code.jquery.com/jquery-1.8.3.min.js"></script>
    <style>
        body{font-size:13px}
        div{width: 260px;padding-left: 10px;font-size: 13px;line-height: 23px;background-color: #eee;}
    </style>
</head>
<body>
    <script> 
        ;(function($){
            $.extend($.expr[':'],{
                'between':function(elem,index,match){
                    var arrSingle=match[3].split('-');
                    //the index  is 0 all the time.
                   //console.log(index);
                    return arrSingle[0]<=index&&index<=arrSingle[1];
                }
            });
        })(jQuery);

        $(function(){
            for(var i=0;i<10;i++){
                $('<div>'+i+'</div>').appendTo('body');
            }
            $('div:between(3-6)').css({'background':'#555','color':'#fff'});
        });
    </script>
</body>
</html>

I'm not sure this is a bug or not,but I can't find too much information about this by using google . I commit here and want to get some help.

Problem / Issue

There's a known issue with IE8 and HTML5, that when it clones/adds a non-standard element to the page, it adds a blank prefix to the tag (and includes the colon).
Note: "non-standard" is not exactly correct, there are standard, less common elements that this also happens to.

jQuery is not selecting those blank-prefixed elements when there's a multi-stage (combo) selector. It works with find() and using the tagname without the prefix, but not when using a selector pattern like $('<ancestor> <descendant>');. Refer to the example below, for a clearer understanding.

Affected Browsers: I only know this applies to IE8. I'm doubtful that it applies to other versions of IE, but I'm not able to test.

Update

My statement above isn't exactly correct; .find() doesn't necessarily solve the issue. You'll notice inconsistent behavior when you use pseudo-selectors, such as :visible. The demo shows that the IE8 bug (prefixed colon) is not handled using jQuery, and using pseudo-selectors should at least be consistent with selecting by element tagname (whether it includes the prefixed elements, or not). That is $('some-element'); and $('some-element:visible'); should return the same results, if there are no hidden some-element.

The behavior I found in IE8 is that $('some-element:visible') acts like $('some-element:visible,\\:some-element:visible'). What I'm after is something to patch the IE prefix bug so that $('some-element') acts like $('some-element,\\:some-element').

Demo / Test Case

http://jsfiddle.net/vol7ron/9sverLdu/
http://fiddle.jshell.net/vol7ron/9sverLdu/show/ (for IE8 testing)

<some-element>
    <span>foo</span>
</some-element>



<script>
    // Add custom element to DOM for IE8
    document.createElement('some-element');


    jQuery(document).ready(function ($) {
        var $el = $('some-element');
        var $clone = $el.clone();

        // create a copy of the element after the original
        // IE8 should create an element with a blank prefix <:some-element>...</:some-element>
        $el.after($clone);

        // method 1
        outputLength( 
            "$('some-element span').length", 
            $('some-element span') 
        );

        // method 2
        outputLength( 
            "$('some-element').find('span').length", 
            $('some-element').find('span') 
        );

        // method 3
        outputLength( 
            "$('some-element span, \\\\:some-element span').length", 
            $('some-element span, \\:some-element span') 
        );


        // method 4
        outputLength( 
            "$('some-element:visible span').length", 
            $('some-element:visible span') 
        );

    });

    function outputLength(_label, _elems){
        var $label  = jQuery('<label />').html(_label + ' : ');
        var $value  = jQuery('<span  />').html(_elems.length);
        var $output = jQuery('<div />').append($label,$value);
        jQuery('body').append($output);
        console.log($output.html(), _elems);  // incase you prefer console
    }
</script>

Hi,

i've installed v 1.11.1 by Bower. In the minified version there's still the sourceMappingURL comment pointing to the .map file. This conflicts with what stated in the official download page

Any hint on how to circumvent this issue or on how to contribute on this?

Originally reported by jwagner: http://bugs.jquery.com/ticket/14484

.css({'left':'+=50%'})

...moves the item by 50 pixel instead of 50%, while

.animate({'left':'+=50%'})

...works as expected (adds 50%).

The docs suggest that .css and .animate should behave identically ( http://api.jquery.com/css/):

As of jQuery 1.6, .css() accepts relative values similar to .animate().

If "similar" should really mean "similar" but not identical, it would help to give a hint in the docs that relative percentage values are not supported by .css.

The problem shows up in current Chrome, Firefox and IE10.

Fiddle to reproduce: http://jsfiddle.net/2VGgg/

Since we don't commit the built file on each change, the bower.json file refers to the non-existent dist/jquery.js file. If someone tries to install from the repo as they did in gh-1671, they get confusing results. Now that we use npm for our own internal needs we could just create and commit the bower.json file at release time instead of leaving it in the repo.

In IE8- $.isEmptyObject('bugaga'); returns true.
In all other browsers - false.

jQuery 1.11.1

Listening to the change event is not consistent across browsers.

Minimal test case:

var input = document.querySelectorAll('input')[0];

input.indeterminate = true;

$(input).on('change', function(){
    alert('change');
});

JsFiddle.

In Chrome and Firefox, the change event fires when the element is clicked. For IE11, the input needs to be clicked twice: once to remove the indeterminate state, then again to fire the change event.

It is possible to work arround this issue by manually firing the change event for indeterminate input elements.

// As other browsers already fire the change event,
// only bind the listener for IE.
if ( window.navigator.userAgent.indexOf('Trident') >= 0 ) {

    $(function(){

        // Pointer events in IE10, IE11 can be handled as mousedown.
        $(document).on('mousedown', 'input', function(){

            // Only fire the change event if the input is indeterminate.
            if ( this.indeterminate ) {
                $(this).trigger('change');
            }
        });
    });
}

I'm checking the user agent here; firing of the event could probably be detected by creating an input element and triggering click on it.

Not a huge issue, but the url right here seems to be broken...

Originally reported by john at: http://bugs.jquery.com/ticket/9628

Right now we're rounding off the answers from width(), height(), etc. to the nearest pixel - this makes it hard to do good positioning of elements (especially for animations). For example if you have 3 items that are width 33% inside of a 100px element we're returning 33px for each element. Theoretically an animation method might be able to return a more interesting result if they know that there are extra fractional-numbers getting rounded off.

I got a report on this directly from Mozilla but I agree with them that this particular change makes it hard to get to good numbers.

See also: #3239.

Issue reported for jQuery 1.6.1