Reported by matteosistisette, 18 months ago.

Whenever you use slideDown("slow") on any object, the animation, instead of being smooth, starts with a little jump. With slideUp, the movement starts smoothly, but it ends with a little jump.

This is not a discontinuity in speed or acceleration, this is a discontinuity in the position, so no matter what the speed curve is supposed to be (accelerating, decelerating, ease in, ease out, no ease, uniform speed, whatever) it is plainly wrong.

I'm testing on Mozilla Firefox, it may work properly in other browsers.

You can try it with any minimal test that uses slideUp and slideDown; see for example  http://docs.jquery.com/Tutorials:Live_Examples_of_jQuery and click on the "slide in" and "slide out" buttons in "example B"

Reported by d@…, 14 months ago.

This ticket is a followup to the discussion in  http://forum.jquery.com/topic/should-null-be-passed-in-query-strings-generated-by-jquery-param where I am using jQuery.ajax to send data to a web service.

Given

jQuery.param({"string":"foo","null":null,"undefined":undefined})

the output is

"string=foo&null=null&undefined=undefined"

which the server will interpret as the strings "null" and "undefined" rather than as empty values.

My expected output would be:

"string=foo&null=&undefined"

where null values are coerced to empty string, and undefined values have no value. (This is the behaviour in Prototype 1.7, which seems reasonable.)

Reported by louisremi@…, 12 months ago.

jQuery.fx.interval should be replaced by an 'animation-tick' throttling feature. Why removing fx.interval?

• reducing fx.interval fails at producing noticeably smoother animations (browser vendors even agreed on a 16.666 value to aim for 60fps)
• fx.interval is useless in browsers supporting requestAnimationFrame
• developers struggle at updating the interval value while their animation is running (example:  http://forum.jquery.com/topic/jquery-fx-interval-controlled-by-ui-slider-help )

Why throttling animation ticks instead?

• because it serves a similar purpose (saving CPU cycles when animations do not need to run at 60fps)
• because it can solves all of the above problems
• because the implementation adds only 1 line of code:  https://github.com/jquery/jquery/pull/334/files

Reported by mako281@…, 12 months ago.

Add Google Chrome to jQuery.browser, that is all :)

Reported by Quozzo, 10 months ago.

Using .attr("value") returns the same as using .val() although the "value" attribute remains unchanged in the DOM, as seen by Dragonfly on Opera. New text entered in an input should be returned with .val() but not .attr("value") which should return the value of the "value" attribute, that getAttribute() does.

$('#foo').val() == $('#foo').attr('value')

 http://209.85.12.237/30095/43/0/f5198393/attrbug.htm

Reported by rwaldron, 10 months ago.

Remove jQuery.browser from jQuery core, relocate to compatibility plugin

http://bugs.jquery.com/ticket/9385#comment:7

per description at:  http://api.jquery.com/jquery.browser/

Reported by superbulldeng@…, 9 months ago.

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.

Reported by gnarf, 7 months ago.

We are starting to use more and more setTimeout( fn, 0 ); calls around our code base. I think now that there is also a setImmediate and there is also the postMessage that we should probably try to take advantage of these.

I would like to propose a jQuery.later( fn ) that wraps the "best" possible function here.

Reported by scott.gonzalez, 7 months ago.

Deferreds should always be resolved asynchronously. Any abstraction that deals with a potentially async operation should always act asynchronously. The current implementation prevents users from writing code that takes advantage of async behavior and can cause bugs in bad code that is written against an initially synchronous implementation that later becomes asynchronous.

This also has the (positive) side effect of cached XHR requests in IE being resolved asynchronously.

Reported by gnarf, 7 months ago.

This was discussed when we talked about removing the .data("events") code. We would like to discourage/deprecate this usage, and perhaps release something like $.fn.events() to replace it in a "debugging extension".

I'd like to suggest that we deprecate the current usage as soon as possible.

Reported by mathias, 6 months ago.

Please consider deprecating/removing jQuery#size() in favor of jQuery#length.

jQuery 1.8?

Reported by timmywil, 6 months ago.

This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8.

These are my ideas so far:

1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes.
2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally.
3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath.
4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly.
5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js.
6. Combine dirNodeCheck and dirCheck into a single function.
7. Add a better fallback for Sizzle.contains.
8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft.
9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it.
10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication.
11. Follow spec for acceptable character ranges. Currently, we use "\u00c0-\uFFFF\", which may not be correct. third party pull  https://github.com/jquery/sizzle/pull/61
12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support.
13. Per Dave's suggestion, explore a parsed selection cache that would hold 50 (or however many) of the most recent selectors already parsed. This would remove the need for quickIs in event and make matchesSelector use in event delegation much faster. This supplements #5.

Reported by fastfasterfastest, 6 months ago.

The documentation of $.ajax states "The jqXHR objects returned by $.ajax() as of jQuery 1.5 implement the Promise interface...". This is not true in 1.7.1. As a consequence one cannot (safely) use the Promise programming model on the object returned by $.ajax.

If you use a beforeSend callback and the callback returns false, then $.ajax does not return an object that implements the Promise interface - $.ajax instead returns a boolean.

E.g.,  http://jsfiddle.net/67DJr/

$.ajax( '/echo/html' , { beforeSend: function(){ return confirm('Access resource?'); } })
    .done(function() { alert("success"); })
    .fail(function() { alert("error"); })
    .always(function() { alert("complete"); });

The above code causes a javascript error if user clicks Cancel.

Per documentation, $.ajax should always return an object that implements the Promise interface. In the case of beforeSend returning false, and thus cancelling or preventing the call from being made, it seems to make sense for $.ajax to return a Promise object that has been rejected.

Reported by dmethvin, 5 months ago.

On behalf of morris.johns (lastspottedat) timefiler.com

When getBoundingClientRect() is not available, jQuery.offset has a large block of ugly code that depends upon other ugly feature sniffs that exist only for use by the offset() function (such as jQuery.support.subtractsBorderForOverflowNotVisible).

For older versions of Safari (or older mobile safari) it seems simpler to calculate offset using window.webkitConvertPointFromNodeToPage(). For example, the Sencha Touch codebase uses webkitConvertPointFromNodeToPage() - see sencha-touch-1.1.1\src\core\Element.position.js :

    getXY : function() {
        // @FEATUREDETECT
        var point = window.webkitConvertPointFromNodeToPage(this.dom, new WebKitPoint(0, 0));
        return [point.x, point.y];
    },

    getOffsetsTo : function(el){
        var o = this.getXY(),
            e = Ext.fly(el, '_internal').getXY();
        return [o[0]-e[0],o[1]-e[1]];
    },

I have used a function similar to the code given in the stack overflow link for our own proprietary ajax library, supporting a variety of current and obsolete desktop browsers."

 http://stackoverflow.com/a/4758996/436776

Reported by ajpiano, 5 months ago.

It's probably more useful into have a method in core for serializing a form directly to an object, instead of an array of objects with name and value keys. Luckily, Ben Alman has a very small implementation that leverages the existence of serializeArray to give us just such a method.

My experience tells me this is a relatively common use-case: I've used it on a number of projects, and I've directed numerous people toward it as well in the last year or two. Not only is it beneficial when developing single-page apps with Backbone or the like, it's considerably simpler than existing options (in core) for users who need to submit a form via ajax, but also want to augment the data with some properties beforehand.

 https://raw.github.com/cowboy/jquery-misc/master/jquery.ba-serializeobject.js

While most plugins should stay just that - plugins - I think that this feature is common enough, lean enough, and low-level enough for us to be able to offer it in core.

Reported by jpate, 5 months ago.

tested in jquery 1.6.4, 1.7.1

tested in chrome 15.0.874.121 m win7 x64

to reproduce: create a div with the following style: box-sizing:border-box;width:50;padding:10px;margin:10px solid red

call jQuery(elem)animate({width:50;height:50})

the box will jump to the wrong starting size, then animate

test case:  http://jsfiddle.net/GUfuf/6/

patch:  https://github.com/jamie-pate/jquery/commit/72bd44aebb10a66f2d7d51f87bc398f5d6541b95#src/css.js

Reported by jaubourg, 5 months ago.

It consists primarily in having promise.then implemented like promise.pipe.

We can keep current promise.then under a new alias (attach?) for people who would still want to add callbacks without the cost promise.pipe implies (though we have done, fail and progress for this already).

Change is breaking but only to those who used the value returned by promise.then (either by storing the object or using chaining). I think the tradeof is reasonable enough.

Reported by jaubourg, 5 months ago.

This enhancement is quite simple. There is some concern about $.Callbacks flags being in a string format. I propose to accept objects as an alternative so that you could do both of the following:

$.Callbacks( "once memory" );
$.Callbacks({
    once: true,
    memory: true
});

Reported by dmethvin, 5 months ago.

There are several steps to this, we can break them out later:

1) Work with the Closure Compiler team to ensure that CC can parse jQuery correctly and work with the ADVANCED_OPTIMIZATIONS option.

2) Update jQuery's style guide, code, and unit tests to ensure we'll be able to use CC going forward.

3) Create a style guide for plugin writers and jQuery developers to ensure their own code is CC-worthy. Perhaps we can add some indication of CC-worthiness at the plugins site?

4) Document critical dependencies that will hamper minimization, such as using ambiguous methods like .load() or .show() (see #10997).

5) Provide a tool to users that allows them to combine jQuery with their own plugins and code for best minimization.

It's unlikely this will all get done in 1.8 but we need to figure out where it goes on the roadmap.