search

mattdiamond / fuckitjs

The Original Javascript Error Steamroller
4.1k stars 91 forks source link

Iframe sandboxing and therePerfect #7

Closed jswartwood closed 12 years ago

jswartwood commented 12 years ago

Adding iframe sandboxing to allow multiple scripts to be evaluated simultaneously.

Adding therePerfect method to return the "working" scripts; now you can recommit and go home for the day.

mattdiamond commented 12 years ago

This is an awesome idea... I'll merge it in once I have some more time to look it over.

wjcrowcroft commented 12 years ago

+1

This is the main feature I'm waiting on before we incorporate this into our build process at work.

matthopson commented 12 years ago

... they should have sent a poet.

jswartwood commented 12 years ago

I was thinking about this today, and with my pull we lose execution in the main frame which will cut potentially working jQuery code because the expected DOM is missing.

Also, the execution will no longer be "visible" for those that still want to FuckIt directly in production (vs using FuckIt as part of their build process).

This pull may need some tweaks... maybe clone the parent DOM into the iframe first before running, then possibly capture the therePerfect output and dump it back into the main thread for "visible" execution.

mattdiamond commented 12 years ago

What if we return a Deferred object that resolves once the eval goes through, allowing the developer to chain FuckIt calls?

I suppose we lose the advantage of asynchronous script loading...

jswartwood commented 12 years ago

Simple. I like it.

mattdiamond commented 12 years ago

done and done.

jswartwood commented 12 years ago

How do you feel about therePerfect? I can easily mod it to work with the deferreds instead of iframes.

mattdiamond commented 12 years ago

I'm conflicted... on the one hand, I like the idea of returning the "fixed" scripts, but on the other hand, that would inspire people to actually fix their mistakes instead of relying on a terribly designed and ultimately harmful crutch. Lame.

What about resolving the Deferred with the corrected script so it's available in the callback? Like so:

FuckIt("badScript.js").done(function(fixedScript){
    console.log(fixedScript); //hooray
});

We would just need to include window.fuckedScript as the sole argument to the .resolve() call.

jswartwood commented 12 years ago

My thought was that a sarcastic name might be enough to disuade people from actually using output in the real world - it could've just as easily been called lessFuckedScript or atLeastItsSomething. If we just return the "clean" output, there may be even less implication about the completely horrible idea of actually using anything this lib spits out.

Honestly, I can't imagine anyone actually assuming this is doing anything useful... the fact that the script gets run over-and-over until it's fixed should probably cause enough issues itself.

I did kind of want to ride the build-tools wave a bit... would a phantomjs headless runner (with "clean script" export) be too much? :P

mattdiamond commented 12 years ago

Oh yeah I'm totally on the same page, I would hope nobody actually uses this for any real purpose. Though the amount of people that have joked about using it in production makes me worry a little.

I like the build-tool idea though... I think that would be a better place for actually retrieving and saving the processed scripts, rather than the browser plugin. Feel free to write something up for that. Hell, someone should probably build a node-fuckit package.

Also, I'm pretty sure when it comes to FuckItJS, there's no such thing as "too much."

jswartwood commented 12 years ago

I would also say there is almost certainly no such thing as "too little" ;)