In Safari 4.0.3, you can set a breakpoint in JavaScript code that is run during the initial page load. If the page is reloaded, the debugger will stop on these breakpoints during the initial page load. In nightly r50423 (and earlier, but not sure when), I'm unable to get the debugger to stop in these "initial page load" breakpoints. Note that the debugger WILL stop in "initial page load" code for "debugger" JavaScript statements, but not for breakpoints.
Did a little more investigation on this. Here's an HTML file to load: ----- snip ----- <p>hello <script> if (!true) debugger; console.log(new Date().getTime() + ": user app starting"); document.title = new Date(); console.log(new Date().getTime() + ": user app finishing"); </script> <p>world ----- snip ----- Augment ScriptsPanel.js's addScript() method to add the following line as the first line in the method: ----- snip ----- WebInspector.log(new Date().getTime() + ": ScriptPanel.addScript(" + sourceURL + ")"); ----- snip ----- Now, load the page, open inspector, go the Scripts panel, open the console, and reload the page. You should see something like below: ----- snip ----- 1257533565513: ScriptPanel.addScript(file:///Users/pmuellr/tmp/test_reload.html) 1257533565496: user app starting 1257533565497: user app finishing 1257533565534: ScriptPanel.addScript() 1257533565535: ScriptPanel.addScript() ----- snip ----- Note that the lines are out of order. The "user app" messages are actually generated BEFORE the call to addScript(), but get added after it in the log; having the out of order messages isn't an issue (as far as I'm concerned). The issue IS that there's no way the breakpoints could get hit if addScript() isn't run to reset the sourceIDs in the first place. This out-of-order behavior happens if you have breakpoints set in the HTML file or not. One last thing to try. Change the "if (!true)" at the beginning of the HTML file to "if (true)". This will cause the debugger statement to be executed. In this case, during a reload. addScript() is actually run before the JavaScript is run, so you will actually stop at the debugger statement.
*** This bug has been marked as a duplicate of bug 28799 ***