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. > > 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! > > 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. 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. -- 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.
