You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

XPFE Embedding Issues

There are numerous issues that must be addressed to successfully embed a JavaScript debugger into a browser. Much was learned from the successes and shortcomings of the support for the Java based JSDebugger 1.x in Navigator 4.x. XPFE presents some additional problems - especially because at this point there are some important unknowns about that browser's eventual architecture.


  • Basic threading and messagepump issues..
    • Unless the debugger window ui is on a different thread from the target window ui we will have deadlock. This was not generally a problem with the old system because the UI and JS ran on different threads. The target window could post a message into JS, block its layout, and go back into the message loop to allow other window's UIs to run.
    • Even with (optional) thread per window there still needs to be support for multiple (or multiplexed) message pumps.
  • the html parser must give correct line numbers. In the old layout it mostly worked right. This caused me to have to support manual hacking of line number 'alignment' in the debugger UI. NOTE: we must verify that line counting in the html parser uses the same scheme as that in the JS parser for dealing with Unix/Mac/DOS style EOLs.
  • JSD must have full access to source
  • It would be nice if JSD could have seperate access to 'raw' source streams and combined 'raw' and 'generated' streams; i.e. one shows what was fetched from the server, the other additionally shows the result after document.write calls have been evaluated.
  • Correctly expose all uses of JS in the browser
    • in <script> tags
    • inlined handlers
    • JS entities
    • JS style sheets
    • Prefs?
    • mail and news?
    • Other?
  • Can we run the debugger window on a seperate JSRuntime?
  • Can we Have instances of the debugger window debug other instances of the debugger window? Each debugger has its own runtime and targets one other runtime; either the one shared by 'normal' windows or one used by some specific debugger.
  • How do we support security protection of the use of the debugger apis?
  • Can we 'drive' the browser from the debugger UI?
  • What other interfaces of the browser can we control from the debugger?
  • How do we manage debugger prefs? Via netlib? via the jsfile object?
  • Can we support 'Just In Time' debugging? - button in error dialog? button in JSConsole?
  • Start up the debugger when we hit the debugger keyword?
  • Can we get source form the browser cache? (this was not possible in JSD 1.x)
  • Browser pref (with UI!) for whether or not user whats to allow debugging.
  • Autoupdate of debugger?
  • Run debugger from a server? i.e. .js files that make up the debugger are run straight from a server.
  • Ship debugger .js files with browser?

last update: John Bandhauer 16 November 1998