trim : jQuery handling of native (or custom defined) objects methods

Reported by:	stephane.rebai@gmail.com	Owned by:	stephane.rebai@gmail.com
Priority:	low	Milestone:	1.5
Component:	unfiled	Version:	1.4.4
Keywords:		Cc:
Blocked by:		Blocking:

Description

i'm not sure if this should be called a bug but it is an issue while working on websites with contents(read javascript codes) from differents sources.

Short version:

if trim is prototyped like

String.prototype.trim = function(){}

Jquery checks for a native trim and fires it with :

trim.call(text);

which causes conflict if the prototype uses the "this" reference (as it should).

As i understand it, the "call" use changes "this" context to jQuery object instead of String.

It may be useful and i see no problems with it until i encounter a custom "trim" method which code is :

String.prototype.trim = function()
{
    var b=0,e=this.length -1;
    while(this.substr(b,1) == " ") b++;
    while(this.substr(e,1) == " ") e--;
    return this.substring(b,e+1);
}

Aside of the evidently cpu power lost in this function , you can see that a call to "this" is made which seems legitimate : the length of the string "trim" is being applied to.

The bad effect of jquery "call" behaviour is that "this.length" leads to "undefined" in this context making an infinite loop.

to confirm that i've changed in jQuery (1.4.4):

trim.call(text);

to just

trim(text);

and get rid of the infinite loop.

Final solution may be more complicated than that however, i can imagine an improved "trim native" checking but don't know of a way to do it for now.

Note that i may be totally wrong and i would greatly appreciate that you explain me in what so i can figure out new things.

Regards,

Stéphane

Attachments (0)

Change History (5)

Changed November 24, 2010 03:47PM UTC by addyosmani comment:1

owner:	→ stephane.rebai@gmail.com
priority:	undecided → low
status:	new → pending

I've devised a very simplistic test case to verify that custom trim methods are not resulting in infinite loops or errors being thrown here Live Test Case. I am also not seeing the internal behavior we currently have in place causing issues. So that we can be clear on the specific bug you are referring to, could you kindly create a full test case on jsFiddle that reproduces the issue you've encountered so that we can further investigate?.

Changed November 24, 2010 10:18PM UTC by jitter comment:2

I also can't reproduce this. I even tried with a special crafted test case which makes sure the custom trim is assigned before jQuery runs.

Changed November 25, 2010 08:53PM UTC by zerterone comment:3

Thanks to both.

Your test cases were valid except for one thing : custom trim was defined in an external js.

It's not a jquery bug but a concurrent run-time conflict.

While producing a test case and so waiting for both js files to load i've seen no error in trim working after jquery has loaded.

It seems that custom trim was defined somewhat during jquery lib was loading leading to this behaviour.

Thanks a lot and sorry for false bug submission.

Changed November 25, 2010 10:40PM UTC by jitter comment:4

Replying to [comment:3 zerterone]:

Thanks a lot and sorry for false bug submission.

Zerterone are you the original reporter? And if I understood correctly you request this ticket to get closed?

Changed November 26, 2010 06:03AM UTC by addyosmani comment:5

resolution:	→ worksforme
status:	pending → closed

From zerterone's response (and a quick google search which appears to confirm they and the original ticket submitter are the same person) it would appear that this has been confirmed as not being a jQuery core bug. With this in mind I will be closing this ticket, however if you have any further test cases or information related to this ticket which you would like to submit, please feel free to re-open and we will investigate once again.

Side navigation

#7615 closed bug (worksforme)