Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patch Function#call and Function#apply together, more robust than single fix. #347

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Xotic750
Copy link
Contributor

call Ref: #304
apply Ref: #99
Original call only fix: #345

@Xotic750
Copy link
Contributor Author

I am guess that you will want so more tests added for apply, like those for call. To be honest though, if there was a problem then it would be rearing its ugly head.

es5-shim.js Outdated

if (shouldPatchCallApply) {
// Constant. ES3 maximum array length.
var MAX_ARRAY_LENGTH = 4294967295;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how is this calculated? Is it the same in every ES3 browser, or does it vary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Math.pow(2, 32) - 1. This is the maximum value that any ES3 environment that I have tested supports (I don't know if it is in the spec somewhere). Then in ES5 it changes to Number.MAX_SAFE_INTEGER for arrays and strings (this is in the spec as far I remember). Arrays seem to follow this but strings still seem to be limited to 65k characters, it is a similar story with arguments, I don't think any environment supports more than 65k args (and many support much less). So this seemed a sensible number to choose to check if it was array-like, the smallest max array length? We could set it to Number.MAX_SAFE_INTEGER, but this patch is only going to be applied on ES3 environments, I don't know, I am in two minds about what it should be?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed this, well the use of it. Need to make sure and remove the code.

@Xotic750
Copy link
Contributor Author

Xotic750 commented Dec 9, 2015

Since adding the apply tests, there are 4 failures on IE8 that I am not sure about and need to find out why they happen.

@Xotic750
Copy link
Contributor Author

Xotic750 commented Dec 9, 2015

Just 1 IE8 failing test remaining.

@Xotic750
Copy link
Contributor Author

IE8 is now without fail. IE7 also tested without fail. Opera 11 and 12 tested ok. Need to test other ES3 environments that I don't have access to.

// Boxed string access bug fix.
if (splitString && to_string.call(argsArray) === '[object String]') {
// `str_split` is safe to use here, no known issue at present.
argsArray = call.call(str_split, argsArray, '');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's already a call-bound strSplit btw, you should just be able to do strSplit(argsArray, '')

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah wait, i see that it's defined farther down.

I wonder if we should do all the call-bindings before patching Function#call?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it will make any difference, when call is patched then bind patch is in play and it will use the patched call. When call is not patched then there is also a native bind. Totally up to you and how you feel about it, do it before or later. The important thing is to not use any bound functions within the patch itself otherwise you end up with a circular condition.

@Xotic750
Copy link
Contributor Author

Is there is anything more that you require for this patch (except a rebase)?

@ljharb
Copy link
Member

ljharb commented Dec 19, 2015

In general this one makes me very nervous, so I'm intending to let it sit and marinate for awhile. I'll want to extensively test it across many browsers.

I'm also curious to see if there's a performance impact on the browsers this patches, and what it might be.

@Xotic750
Copy link
Contributor Author

No problem, just say if there are any changes that you want.

… single fix.

Ref: es-shims#304

Changed some code back as mentioned in comments.

Changed more code as per comments

Changed more code as per comments.

Changed some variable names to better reflect comments.

Fixed missed invocation.

Added some comments and code changes as discussed.

[tests] Remove unneeded jshint comment.

[Tests] use the preferred it/skip pattern for this strict mode test.

es-shims#345 (comment)
And some other cleanup

Added `arguments` expectations to tests.

Add tests for `Object#toString` of typed arrays and Symbols, if they exist.

Added note about typed array tests.

Fix `hasToStringTagRegExpBug`

Removed RegExp and Array bug detection as can not test, possible Opera 9.
Fixed missing `force` on `defineProperties` that caused the patch to not be applied on IE<9.
Fixed `Uint8ClampedArray` tests for Opera 11 and IE10 that don't have it.

Removed offending test that was moved to detection, but forgotten.

Avoid all possibilities of `call` calling `call`.

Do not pass `undefined` argument, we know IE<9 has unfixable bug.

Final cleanup (hopeully)

Port over work from `apply` fix

Move code so that it is specific to the fix.

Robustness, move before bind.

Remove `Array#slice` tests.

Add notes about `eval` and `apply` avoidance.
@ljharb
Copy link
Member

ljharb commented Apr 22, 2022

@Xotic750 can you please check the "allow edits" checkbox on the RHS of the PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants