Skip to content

/ jquery

Permalink
Browse files
Loading status checks…

Core: Fix trim in Android<4.1

  • Loading branch information
@mgol
mgol committed Feb 13, 2014
1 parent d792e40 commit eda283d0e4d59074ae98af0fdc2951e6c109d5fd
Unified Split
Showing with 19 additions and 3 deletions.
  1. +19 −3 src/core.js
22 src/core.js
View file
@@ -24,6 +24,10 @@ var
return new jQuery.fn.init( selector, context );
},

// Support: Android<4.1
// Make sure we trim BOM and NBSP
rtrim = /^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g,

// Matches dashed string for camelizing
rmsPrefix = /^-ms-/,
rdashAlpha = /-([\da-z])/gi,
@@ -336,9 +340,21 @@ jQuery.extend({
return obj;
},

trim: function( text ) {
return text == null ? "" : trim.call( text );
},
// Support: Android<4.1
// Use native String.trim function wherever possible
trim: trim && !trim.call("\uFEFF\xA0") ?
function( text ) {
return text == null ?
"" :
trim.call( text );
} :

// Otherwise use our own trimming functionality
function( text ) {
return text == null ?
"" :
( text + "" ).replace( rtrim, "" );
},

// results is for internal usage only
makeArray: function( arr, results ) {

13 comments on commit eda283d

@markelog

This comment has been minimized.

Sign in to view
Copy link
Member

@markelog markelog replied Feb 14, 2014

I don't think we should add that amount of code without having discussion about it first, until then, i think we should revert this
@mgol

This comment has been minimized.

Sign in to view
Copy link
Member Author

@mgol mgol replied Feb 14, 2014

I discussed this with @dmethvin & @gibson042.

EDIT: Anyway, this commit is already in, no point in reverting it back in forth, we can discuss it here if you have doubts and optionally revert later.

One way to reduce the code size here would be to remove the check completely and just always use the second logic. I'm not sure if that would introduce any performance penalty.

BTW, this is the only issue that was making Android 4.0 consistently fail.
@markelog

This comment has been minimized.

Sign in to view
Copy link
Member

@markelog markelog replied Feb 14, 2014

But not with the rest of the team, that's why we use PRs, to have full discussions and commit only if we all on the same page.

Anyway, this commit is already in, no point in reverting it back in forth

That's not an argument, for example – if i would revert it and then said exactly the same thing, would that really matter for this issue?

My arguments are the same as in #1514
@markelog

This comment has been minimized.

Sign in to view
Copy link
Member

@markelog markelog replied Feb 14, 2014

Another example, if it would start with PR, i, or someone else could point that this is not our style guide, now in order to fix it, you should do another commit.
@mgol

This comment has been minimized.

Sign in to view
Copy link
Member Author

@mgol mgol replied Feb 14, 2014

But not with the rest of the team, that's why we use PRs, to have full discussions and commit only if we all on the same page.

That's true, I just didn't think this change will be controversial as this is the only issue making Android 4.0 fail. There are a lot of things commited without PRs by most of team members.

Anyway, this commit is already in, no point in reverting it back in forth

That's not an argument, for example – if i would revert it and then said exactly the same thing, would that really matter for this issue?

That is an argument (you just disagree with it), please try to be considerate. Anyway, yes, this would apply in the same way if you did the same, it's just now we know we disagree on the issue and if we revert it now it'll generate 1-2 additional commits depending on the team decision whereas if we wait for the next meeting and discuss it there, we'll have 0-1 additional commits depending on the resolution.
@mgol

This comment has been minimized.

Sign in to view
Copy link
Member Author

@mgol mgol replied Feb 14, 2014

Another example, if it would start with PR, i, or someone else could point that this is not our style guide, now in order to fix it, you should do another commit.

These kinds of things should be handled by our linters, otherwise mistakes will always keep happening.
@markelog

This comment has been minimized.

Sign in to view
Copy link
Member

@markelog markelog replied Feb 14, 2014

please try to be considerate

I'm sorry if i wasn't

it's just now we know we disagree on the issue and if we revert it now it'll generate 1-2 additional commits depending on the team decision whereas if we wait for the next meeting and discuss it there, we'll have 0-1 additional commits depending on the resolution

i'm not saying we should do the revert now, i was just expression my position on this.

There are a lot of things commited without PRs by most of team members.

I probably went a little over the board, but still, review for this amount of code should have happened, if we would decided to land it, we could have discuss the code, maybe it's presented with a new bug or it could be simplified, now we can do only damage control.

These kinds of things should be handled by our linters, otherwise mistakes will always keep happening.

From the old days, reviews was a solution for it, i don't see why it couldn't be now
@mgol

This comment has been minimized.

Sign in to view
Copy link
Member Author

@mgol mgol replied Feb 14, 2014

I probably went a little over the board, but still, review for this amount of code should have happened, if we would decided to land it, we could discuss the code, maybe it's presented with a new bug or it could be simplified, now we can do only damage control.

It was premature on my part, I agree for +59 bytes I should have created a PR and waited for feedback a little longer.
@dmethvin

This comment has been minimized.

Sign in to view
Copy link
Member

@dmethvin dmethvin replied Feb 14, 2014

Discussing it last night with @mzgol I wondered whether we should just go back to our own string replace for all browsers. It seems like the only place where we might process a big string would be globalEval.
@gibson042

This comment has been minimized.

Sign in to view
Copy link
Member

@gibson042 gibson042 replied Feb 16, 2014

the only place where we might process a big string would be globalEval

And even there, explicit regex anchoring means we'll stay pretty darn efficient. I'm sold on abandoning String.trim for Android<4.1, but doing it ourselves will still be costly even without the test.
@markelog

This comment has been minimized.

Sign in to view
Copy link
Member

@markelog markelog replied Feb 18, 2014

the only place where we might process a big string would be globalEval

Is there a reason why we do this? See https://github.com/jquery/jquery/pull/1449/files
@dmethvin

This comment has been minimized.

Sign in to view
Copy link
Member

@dmethvin dmethvin replied Feb 18, 2014

It wouldn't seem that trimming is even needed there, I agree.
@gibson042

This comment has been minimized.

Sign in to view
Copy link
Member

@gibson042 gibson042 replied Feb 18, 2014

#1449 aside, the performance hit of non-native jQuery.trim should be negligible in both places where we might process big strings:

  • jQuery.globalEval (where it's followed by interpretation and execution of the string)
  • 1.x jQuery.parseJSON (where it's followed by .replace( <global JSON token regex>, function ):

    jquery/src/ajax/parseJSON.js

    Line 17 in a96ff1c

    str = jQuery.trim( data + "" );
    )

If there is a performance penalty, we're actually more likely to see it when processing shorter strings in a loop:
Please sign in to comment.
You can’t perform that action at this time.