Prototype 1.5.1 release candidate
The first release candidate for Prototype 1.5.1 is now available for download. Prototype 1.5.1_rc1 contains bug fixes, performance improvements, and a few new features. If you’re using Prototype 1.5.0 in your application, we urge you to upgrade to this release candidate and report any bugs you may encounter. Assuming no heinous bugs are found, you can expect the final version to be released sometime within the next couple of weeks.
Keep reading for an overview of what’s changed (or see the full CHANGELOG for more details).
Bug fixes
- $$ no longer returns duplicates for certain selectors. [#7568]
- Hash#toQueryString no longer doubly encodes certain parameters. [#7421]
- $H no longer iterates over shadowed properties in Safari. [#7421]
- Form.Element#disable will now call blur(), removed blur() call from Form.Element#enable. [#6034]
- Fixed an issue with serializing empty array inputs. [#7516]
- Fixed a bug in the simulated hasAttribute for IE due to getAttributeNode sometimes returning null.
- Fixed that Form.Methods and Form.Element.Methods weren’t being applied correctly to forms and form elements in Safari. [#7358]
- Fixed setStyle with opacity: 0 to work correctly in IE.
- Fixed that Form.Element#activate shouldn’t raise an exception when the form or field is hidden.
New features and changes
- $$ now supports virtually all of CSS3, with the exception of some pseudo-elements (like ::first-letter) and some pseudo-classes (like :hover).
- Prototype now has support for JSON encoding and decoding built in. If you’ve had issues with the official json.js library extending Object.prototype, you can now use our implementation instead. Thanks Tobie!
- Element.extend can now take a tag name or array of tag names as its first argument to apply the given methods to specific tags.
- Added String#empty, String#blank, String#startsWith, String#endsWith, String#include, and String#times.
- Added Number#toPaddedString.
- Added Form#request, which uses the form’s action and method attributes, along with its serialized parameters, to create an Ajax.Request.
- Removed support for “throw $continue” in Enumerable iterators. If you were using this in your scripts, please replace it with “return” instead.
Performance improvements
- $$ is now blazing fast. Seriously—try it out. If you’re using $$ at all, you owe it to yourself to upgrade! Element#down, Element#up, Element#previous and Element#next received performance boosts too (along with everything else that uses Selector).
- Element#getStyle and Element#setStyle are now faster.
- Array#uniq is faster. [#7417]
- String#escapeHTML now uses a cached div and text node, making it much faster. [#6937]
- Enumerable iteration is faster now that it incurs only one try/catch block instead of two (as a result of removing support for $continue).
The $$/Selector improvements come from Andrew and Christophe’s many hours of work, and were inspired by Jack Slocum’s DomQuery and Joe Hewitt’s CSS selector-to-XPath translation. Selector is now backed by XPath where available (Firefox and Opera 9), and is optimized to be 5x faster on average than the previous version in browsers without XPath.
Thanks to everyone who contributed to this release!
Sorry, comments are closed for this article.
Comments
I plugged it into my project and immediately Firebug was spewing out thousands of the same error:
too much recursion return value.apply(null, [this].concat($A(arguments))); Prototype.js line 1283
This is with Script.aculo.us 1.7.0 I’m not sure what is causing this, I can’t debug
Also, your JSON page says “String#evaJSON” (no L) twice.
Kroc, thanks for the heads up on the JSON docs, I’m correcting this right now.
@Kroc Camen: That’s an issue with a Scriptaculous method that’s since been merged into Prototype. You’ll need to use the latest (unreleased) verison of Scriptaculous, which you can find here: http://svn.rubyonrails.org/rails/spinoffs/scriptaculous/src/
While looking at the new Form.request I don’t see any attempt to encode/escape the form contents. So then I went to Form.serialize and didn’t see any there either. Any chance of getting something like encodeURIComponent in there as an option?
@sam: Thanks for the headsup. Unfortunately the scriptaculous SVN doesn’t appear to be stable yet. I get the error “options has no properties | effects.js (line 258)”. Anyway, I suspect once Scriptaculous 1.5.1 is released a subsequent stable update to scriptaculous should appear. :)
Joseph:
Form#request, just likeForm#serialize, internally callsHash#toQueryString, which usesencodeURIComponent, so you should be safe!@Tobie: Excellent, thanks.
wow! this is awesome.
prototype just keeps getting better and better, as expected. the changelog looks really good, specially Form.request and css3-enabled-$$!
thanks for everyones hard work!
hey there, first of all thanks for the great software!
why do I get a not implemented javascript error when walking up the DOM with parent=Element.up(obj); ?
this happens only to IE6, I must say. IE7/Firefox work ok.
Greetz
Gio, can’t guess. But if you read the big red message box above the comment form, you would know that bug reports should be sent to the tracker ;)
You’re passing
objto theupmethod? Is that a string? It should be :SIt still doesn’t like minification (http://www.crockford.com/javascript/jsmin.html) too well – any plans to insert all the curly braces, etc so that a compressed/smaller version can be included on production sites? When I inserted all the braces, etc in RC1, the file size was reduced to approx. 40kb. Pretty handy for faster initial site download.
This is great, thanks! One thing I would really love is for prototype to receive the ability to send AJAX request parameters in JSON format (ie {“id”: 393, “name”: “Joe”} etc). I am sending my AJAX requests to an ASP.NET C# function which expects parameters to be passed in JSON format. Currently Prototype sends them in query string format. I always have to make minor changes to Prototype because of this limitation.
Reading http://prototypejs.org/learn/json it strongly suggests “You should always set the sanitize parameter to true and an appropriate content-type header (application/json) for data coming from untrusted sources (external or user-created content) to prevent XSS attacks.”
I wonder why sanitize isn’t true by default? In my experiences it’s more common that unexperienced developers will use this just to shoot themselves into their foot.
@Markus: Because the most common use case for JSON unserialization is from the result of an Ajax request, which is necessarily same-domain. Typically you trust data coming from your own domain.
@Jon: http://www.andrewdupont.net/2007/02/26/packing-prototype/
@Jon Compressed Versions of Prototype off of the Prototype Core Google Group:
(-1.4, 1.5rc0, 1.5rc1, 1.5final)
http://groups.google.com/group/prototype-core/browse_thread/thread/ef05ede819727d52
It appears that IE 5.5 does not support the getElementsByTagName command when you pass the special asterik (’*’) node. It always returns 0 nodes. The only confirmation I could find on this was on a mailing list for the dojo toolkit at http://dojotoolkit.org/pipermail/dojo-interest/2006-March/005386.html
Replacing all instances of
with as the post suggests appears to fix the problems I was having.The new JSON tutorial has “Objet.toJSON” (missing the “c”) once.
Fixed! Thanks.
Thanks for this new update!!!
But I’ve noticed that Ajax request are not sent whith this new update and when I switch to the 1.5.0 rc1 request are well sent.
I send with ” new Ajax.Request(url,{...}); “
And I don’t know why they are not sent in this new version.
Thanks
Ok I’ve found the problem.
There is a bug for “setRequestHeader()” if the original JSON library is loaded because this library add the toJSONString method to all object so in this part of script ” for (var name in headers) this.transport.setRequestHeader(name, headers[name]); ” it bugs and I think you should add a property test like “if (typeof headers[name] == ‘function’) continue;” to prevent this error.
Thanks a lot for everything!!
@ Peter: As advised in the post above, Prototype now has support for JSON encoding and decoding built in. If you’re having issues with the official json.js library extending
Object.prototype, you can now use our implementation instead.Yes, $$ and up(), down(), etc. are blazingly fast – BUT I can’t get them to work with any parameters (like index or cssrule). This following worked fine in release 1.5.0: anchor = node.down(‘a.menuitem’); but returns nothing in 1.5.1. I am lucky that this specific tag is actually the first from where I’m selecting, so I tried the following workaround: anchor = node.down(); which return exactly the expected tag (also in the current release candidate). Are there any changes in syntax, that I’m not aware of?
Yes I use your JSON implementation now, but if people load a library that extends the Object.prototype with a or some functions it will appear the same problem because Headers can only be String and so to prevent this error (not only with the original JSON library) I think properties which are not string must be jumped in the FOR loop.
Volker: This is quite surprising. Could you please fill a bug report about your issue?
Peter: Extending Object.prototype is verboten. The only other library that I know of which is still doing so is Rico, and because of that it does not play well with Prototype.
It seems support for HTTP authentication in AJAX (bug #4192) still isn’t integrated into prototype.js. Is there a reason for that?
http://dev.rubyonrails.org/ticket/4192
Hello, there is a bug with the setOpacity method with Netscape Navigator. Netscape is detected as a Gecko navigator but the style.opacity don’t work in Netscape and the correct property is style.MozOpacity. MozOpacity also works with FireFox (fortunately) so style.opacity must be replaced by style.MozOpacity.
Thanks for all.
well i have problems when i’m using prototype and json in firefox 2 … why??? i don’t know :( thx
I had the same problem with el.down() that Volker did. What I was working with, however, was an element that I had cloned but not yet attached to the DOM tree. In Prototype 1.5.0, this worked fine, but not in 1.5.1.
Not sure if this was Volker’s issue, but I thought that this tidbit might be useful to anyone bug fixing. It would be best, of course, if Prototype continues to support CSS queries within nodes that are not yet attached to the DOM tree.