Open Bug 640631 Opened 14 years ago Updated 2 years ago

Add hook to all extension devs to prettify source files before Firefox processing

Categories

(Core :: DOM: Core & HTML, enhancement, P5)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
enhancement

Tracking

()

People

(Reporter: miker, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 I am adding a feature to Firebug which prettifies scripts (it is a very commonly requested feature). This is simple but now the prettified source in Firebug is different from the non-prettified source in Firefox so debugging does not work. I need to find a way to intercept a script as Firefox loads it and then prettify the script before Firefox processes it. The prettify method would need to be a JavaScript method on the Chrome side. If we can prettify the scripts then Firefox will be working with the prettified code so the error lines, stepping and source will all match what we have in Firebug. Could we add a hook to all source files after they load but before Firefox has parsed them so that extension developers can manipulate the text? This could be used to prettify JavaScript or HTML and return the source to Firefox. We could use the mime type to identify the content if this is passed with the script. Reproducible: Always
Jonas, thoughts?
Component: General → DOM
QA Contact: general → general
If I may-- This is to fight online censorship. I'm working on the anti-censorship software called CGIProxy, and with the compressed JavaScript code in sites like Gmail and Facebook, we're hitting the limits of what Firebug can do. If the JS could be reformatted to one statement per line, we could debug these sites, and get them into censored countries. If it helps, I can pay for these changes. If we don't want to put the needed changes into the distributed code, I'd still be willing to pay for a custom version (preferably 4.x) that does what is needed. I'd be very grateful if this problem was solved somehow. Given everything happening in the Middle East and Africa right now, I think it's very important. Plus, I know that a number of developers are looking for a solution for the same issue in Firebug.
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?
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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.