tc39 / Function-prototype-toString-revision

:fishing_pole_and_fish: ECMA-262 proposal to update Function.prototype.toString
https://tc39.github.io/Function-prototype-toString-revision
26 stars 10 forks source link

Web compatibility issue reported #33

Open littledan opened 6 years ago

littledan commented 6 years ago

A bug was filed against Chrome for the Function.prototype.toString change. The reporter claims it breaks their site, and is recommending users to switch to IE. The reporter said,

We have .replace() code specifically looking for .replace('function anonymous() {', '') which no longer works since upgrading to version 66 of Chrome

What do we make of this "compatibility issue"? Should we reconsider https://github.com/tc39/Function-prototype-toString-revision/pull/13 ? cc @gsathya

ljharb commented 6 years ago

Can the reporter be evangelized to change their site, or do we think this is a more widespread problem?

hax commented 6 years ago

It's very likely no programmer will expect extra newline before ), especially old browsers never add it. So it's very likely many old codes of reflection of functions will potentially fail! You don't get many reports just because there is rare use of new Function() and even rare cases of combination of new Function and reflections. So the risk of it will likely to be underestimated.

And, IMO, the reason of append newline is flawed, see my comment: https://github.com/tc39/Function-prototype-toString-revision/pull/13#issuecomment-403441040

michaelficarra commented 6 years ago

@littledan Perhaps, if we discover that this is a common enough pattern, we should special-case empty parameter lists to omit the newline? Or even go a step further and test for trailing line comments (though this may be hard to do spec-wise).

littledan commented 5 years ago

Or even go a step further and test for trailing line comments (though this may be hard to do spec-wise).

What's the hard part about this? Could we remove trailing line comments from each parameter, in the Function.prototype.toString representation, for example?


I'm not sure why @hax 's comment was marked as off-topic; it seems relevant to me.