workaround webkit parsing error

[alexlamsl]

#2053 (comment)

[kzc]

Why is AST_Assign part of the condition at all?

The following is not handled:

$ echo 'console.log(function(){}.a);' | bin/uglifyjs -c -b webkit,beautify=false
console.log(function(){}.a);

Should be:

         if (output.option("webkit")) {
             var p = output.parent();
             if (p instanceof AST_PropAccess && p.expression === this) return true;
         }

An aside: I noticed a few single quotes in recent commits for string literals. Generally the uglify code base uses double quotes.

[alexlamsl]

function(){1+1}.a works fine under Safari 5 - I even tried (function(){1+1}.a+1); and other variations.

[alexlamsl]

I noticed a few single quotes in recent commits for string literals.

That was a mess-up on my part - I was too busy getting Node.js REPL to list the candidates correctly that I forgot to replace all the single-quotes to double-quotes in the end. Sorry about that.

[alexlamsl]

Also Safari 5 would be happy with (function(){1}.a=1); - so you need some form of binary expression in there to trip on this missing parenthesis issue.

But I got lazy with the conditions, because it also trips on things like (function(){for(;1+1;);}.a=1); (but not (function(){for(;;);}.a=1);) and doing a TreeWalker on this seems to be overkill.

Thanks for the reminder about checking AST_PropAccess.expression - will fix now.

[kzc]

function(){1+1}.a works fine under Safari 5

...and presumably under phantomjs.

That's interesting. It's so rare and obscure I wouldn't make the distinction between LHS and RHS - especially in light of the fact that it is behind a "webkit" option.

In any case the patch above does not look at the parent expression leading to unnecessary parens:

$ echo 'console.log(a[function(){1 + 1}] = 1);' | bin/uglifyjs -b webkit,beautify=false
console.log(a[(function(){1+1})]=1);

[alexlamsl]

Thanks for putting up with me. I was just making a case for less code.

You are always welcome 😉

I just need to let some steam out - both me and my box do not thrive under 35℃ & 100% humidity.

[kzc]

now I'm getting failure from pdfjs.js in test/jetstream.js - investigating.

If your patch with the AST_Assign condition works - just use it.

Can the webkit output option be hardcoded in test/jetstream.js by default?

[alexlamsl]

Can the webkit output option be hardcoded in test/jetstream.js by default?

I am contemplating between test/mocha/release.js and test/jetstream.js

Hence the discovery for the current fireworks - and no, AST_Assign does not help. Though I just found out I forgot to swap phantomjs from 2.5.0-beta to 2.1, so may be there's a new bug?

Rolling back and re-testing as we speak.

[alexlamsl]

OT: https://groups.google.com/forum/#!topic/phantomjs/9aI5d-LDuNE

[alexlamsl]

Yup, phantomjs 2.5.0-beta got some new webkit bug - the current release version works just fine.

[alexlamsl]

Updated test/mocha/release.js and test/jetstream.js to use webkit by default. Also discovered the package[-lock].json muckery by npm@5 install can be disabled with --no-save.