Open Bug 640631 Opened 11 years ago Updated 3 years ago
Add hook to all extension devs to prettify source files before Firefox processing
Component: General → DOM
QA Contact: general → general
One more thing-- It would be great if any solution here can prettify any block of JS that gets processed, including eval and things like eval. For example, Facebook passes a huge one-line string of code into an eval-like operation. I can't load it at the moment, but as I recall it "eval's" by setting the contents of a new script block, like "new_script_element.text= long_code_string", and then inserting it into the <head> block.
that's a completely separate beast from <script> elements.
James makes a good point. Scripts added through evals and other methods would also need to be tidyable because they are also visible in Firebug's script panel.
How about if we simplify this request? We understand that evals are technically and politically difficult so we could deal with them in a separate bug report. Why don't we say that we want to be able to manipulate all source files after they have loaded but before Firefox has processed them. We could use the mime type to identify the file so I guess that this would be all that we would need. James, as a first step would this work for you?
11 years ago
Summary: Add hook to all extension devs to prettify JS / HTML before Firefox processing → Add hook to all extension devs to prettify source files before Firefox processing
You can't use the MIME type to identify <script>-loaded scripts. They're very commonly loaded with all sorts of bogus MIME types. You just need a hook in the scriptloader.
Other than the MIME type problem Boris describes, it would definitely be a good first step for me to handle compressed JS in HTML and JS files. I think that would let me support all Google sites. It's Facebook that does the weird eval-like thing.
Hmm, I just checked again and it looks like Facebook isn't doing the weird eval-like thing anymore. Which is great news for me and anyone else who wants to debug it.
I don't necessarily see a problem with providing a "prettify" hook in the JS engine; that would catch calls to eval, the Function constructor, and anything in JSAPI. Sure, it would affect performance when prettifying was turned on, but as long as the non-prettified case was unaffected, that should be fine. The new Debug API (bug 636907) could make this available to JS. The opportunity to do general munging could certainly be abused, but this seems like a legitimate and necessary use case.
Jim: Would be great to hear where you think such a hook should be added, and if you know of anyone that could do it.
>The opportunity to do general munging could certainly be abused, but this seems >like a legitimate and necessary use case. Yup, sadly it seems like our only choice, particularly because the JS to be tidied can be unfinished and buggy. Besides, using a hook will allow us to control exactly how the code is to be formatted, unpack packed code etc. I hadn't heard about the Debug API until you mentioned it here ... it does seem like the perfect place for the hook to be made available. Thanks for working on the API, it will really make life easier for us on the Firebug side of things.
If we're ok having a JS hook for this, then we can just do it the way we JSContext::localeCallbacks, basically. So the embedding (nsJSEnvironment) would set up a function that would get called; it could call prettifiers as needed.
Now that 4.0 is out, would any developers here be willing to add that JS hook for this bug? Or at least a solution for normal (non-eval) compressed JS? Thanks again for any help!
Confirming in the hope that Jim will see commment 11.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #15) > Confirming in the hope that Jim will see commment 11. I would assume it would be a debugger hook invoked from jsfun.cpp:Function (the Function constructor), and either js::Compiler::compileScript or its callers. The reason one might need to pull it out to compileScript's callers is that eval caches the compiled form of some scripts, and that cache's accuracy shouldn't depend on the prettification script being well-behaved. I think this means we need to cache post-prettified scripts, so that if the prettifier returns different results at different times for the same input, the cache still won't affect the system's behavior.
Is any developer willing to take this on? Or is someone working on it already and I just need to be patient? I don't mean to be pushy, but my use for it-- anti-censorship-- is timely (plus my grant income relies on it, alas). I can't really make the change myself without a lot of time; is there any other way I can help? Many thanks again for any help, I'm very grateful for your time.
Checking back in-- Has the new debugging subsystem been completed yet? If so, this bug can probably be closed, right? And we can get to work on the Firebug extension to prettify the JS.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.