On May 29, 12:26 pm, Jonathan <[email protected]> wrote: > On May 28, 9:16 pm, John J Barton <[email protected]> wrote: > > > If the Firebug icon is orange, then Firebug is using Firefox debugging > > features that slow down execution and cause other overhead. > > If you switch to a tab tat does not have Firebug active, the icon > > should be gray and performance should be normal. > > I thought that was how it was supposed to work, but when I originally > tried it, enabling the debugger seemed to enable it for every tab, and > disabling it for a given tab didn't speed things up. I just tried > again, and that didn't happen. I'm not sure what's going on here. I'll > post again if I can reproduce and isolate the problem.
Firebug has two orthogonal controls: per-site activation and per-panel enablement. They are not connected. If you enable the debugger, it is enabled on every site. I believe your local install has some problem. Please try Firebug > Firebug Icon Menu > Options > Reset All. If that does not help, install Firebug in a new Firefox profile. > > > > Second, I have a lot of scripts that reload themselves with a "pass" > > > parameter that make them do different things on each pass.... when > > > the script reloads itself for the second pass, the breakpoints > > > disappear! Why is that happening, and how can I prevent it? > > > I don't understand what you are doing here. Breakpoints are set on > > URLs. + line numbers. If you load the same file with two different > > URLs Firebug will think these are two different files. It has no > > practical way to know that the source is the same. > > To clarify what I'm doing, the first time a script is loaded it has no > parameters, and it does something (e.g., prompts the user to enter > some options). Then it reloads itself with the parameter ...?pass="2", > plus some other parameters, and does something else (e.g., displays a > report). Some of the scripts have three or four passes. > > I see what's happening now. I have to set the breakpoints for each > pass, then the debugger remembers them for that pass -- as long as > none of the parameters change! It's manageable, but very awkward. > Isn't there a way to configure it to look at the pathname part of the > URL, instead of the whole URL? > > Imagine a script that receives a timestamp as a parameter in the URL. > Maybe its logic depends on that. The URL is guaranteed to be different > for every run, so the breakpoints have to be set again for every run! > > To avoid this problem I think I'd have to rewrite the scripts so that > they execute passes by iterating a top-level loop, instead of by > reloading themselves. That's the way they were originally written. I > changed them because the top-level loop made them substantially harder > to write and debug. I don't want the debugger's limitations to force > me to change them back! Well I don't want to re-program the debugger for one very unusual use case! I don't see any reason to reload, reparse, and recompile the source code to change the call parameters. All you have to do is call the functions again. > > > > Third, the whole business of loading a script, setting breakpoints, > > > and reloading the script seems chancy... > > > a script can have persistent effects when > > > loaded, e.g., modifying a database. The conditions you need to test > > > with are present before the first load; by the time you can set > > > breakpoints, they've been changed. Is there a way to avoid this? > > > Yes, arrange your test harness to prepare the state of the system in a > > standard way. This issue is not unique to breakpoints, but rather to > > reproducibility. > > I'm sorry, that's the sort of solution that's fine in theory but very > ugly in practice. It drastically increases the amount of work I have > to do before I can even begin debugging. > > I recognize the usefulness of test harnesses, but they are costly -- > they have to be debugged along with the code being tested, and as the > test conditions diversify they can get very complex. Yes, this is true, but in the end you will have a much better system. > > So far I've needed no test harnesses in this project. Now -- again -- > they're an extra burden I'm expected to assume in order to use the > debugger. > > I'm happy with Firebug in most other respects, but this aspect of the > debugger is a big liability. I hope someone can point out a workaround. If we had time it would be fun to try to create a controlled execution environment for debugging. As far as I know such solutions have only been created as parts of student projects, not in a production debugger. jjb -- You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/firebug?hl=en.
