Hey Sebastian, Thanks for looking at these issues. I have since downgraded both FF and FB for the time being, as I'm on a tight schedule and I find the older one is more stable/predictable at the moment.
In terms of #1: two reasons. FB has always added watches to the top of the list (afaik), so that's what I'm used to after using it for many years now. The logical reason as to why I think it makes sense there, is that the input field is at the top. When I have 10 watchlist items, it's weird to see my expression disappear from the input field and appear 10 lines down, between existing watch expressions and the local variables (that is, it makes it harder to find). Maybe I'll get used to it, but I'd say keep the input field next to the input field. As for #4, the version I'm using 1.12.8 shows me the source file and line. If the browser is failing during parsing, and can tell me the exact line of code, then I should be able to see that line of code in the debugger as well. (that is, the file has been loaded already since the browser *tried* to parse it, so it is in memory somewhere.) #5 is likely more to do with animation than with d3, in that some print / draw buffers are queuing up or something. #6 is probably unrelated to 7301. In my case, it's not stopping on phantom breakpoints. It's stopping on breakpoints that exist. The problem is that the breakpoints are getting triggered during parsing rather than execution. This means I have to basically disable the breakpoint, reload the page, add the breakpoint after the file has been parsed (code line numbers are green). Sometimes the code never goes 'green', despite functioning correctly. I can reproduce regularly, but I can't simplify. My project has 50-100 js files being loaded via requirejs. (obviously they'll be compiled for prod). #7 I only tend to notice after a day of dev when my memory starts to get limited. I've been trying to monitor it more closely, but haven't seen a smoking gun yet. #8. Not a huge issue, just weird. It's like it renders part of the first page, and then forgets to draw more. Then when I scroll, the draw function kicks back into gear. It's not even very common. I might see it a couple times a day doing constant development. Thanks for your help. On Friday, 25 July 2014 19:21:32 UTC+12, Sebastian Zartner wrote: > > Hi Glenn, > > thanks for reporting these issues. I'll comment on each one individually. > >> >> 1. Adding watch items in the watch panel of the "script" section: >> items should be added at the top where the input box is, not appended to >> the bottom of the list. (e.g., add two watch expressions. second one >> should be above the first, but FB 2.0 appends it to bottom) >> >> What's the reason behind that? It sounds like a personal preference to me. > >> >> 1. Errors in the console have line number and a JS file. Clicking the >> error should highlight the line in the source. Currently it gets taken to >> the source page, but the line isn't marked. (Correction: sometimes it is. >> Sometimes it isn't. Sometimes it blinks and disappears.) >> >> I could reproduce that. Reported in issue 7607 > <https://code.google.com/p/fbug/issues/detail?id=7607>. > >> >> 1. Sometimes breakpoints in source code are triggered during the >> loading of the file, rather than during the line's execution. The >> execution >> stops at the bottom of the file, despite where the breakpoint is. The >> file >> appears in the scripts list, and sometimes it doesn't. This is apparently >> random, and hugely annoying. Using requirejs if that makes a difference. >> >> I am not able to reproduce that. We need a test case for this. > >> >> 1. Sometimes when there's an error parsing javascript files, the >> console shows the file and the line number, but the script tab doesn't >> load >> the source, so it takes you to the main html page source instead. Ideally >> it will show you the file and the line. It feels like it's related to #3. >> >> If a syntax error is encountered within a JavaScript file, the parser > stops parsing it. Firefox doesn't provide the source code of the script in > this case, so Firebug can't display it. > Allowing to display syntax errors within the *Script* panel is requested > for in issue 2935 <https://code.google.com/p/fbug/issues/detail?id=2935> > and I just created the platform bug 1043825 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1043825> related to it. > >> >> 1. Console messages are oddly slow. When the last line of the console >> is an error, sometimes it takes minutes to appear (whilst apparently >> doing >> nothing...). The print buffer of the console seems to get "lazy". This is >> hugely annoying when there's an error on the last line because you have >> to >> wait a long time to see where the error actual is. This might be related >> to >> the FB feature where the DOM view lags behind the animation (d3.js); that >> is, for a 200ms visual animation, firebug might renders the DOM changes >> for >> around half a minute. This has been around for a while, but I only >> noticed >> the laggy console after FB 2.0. >> >> This was also reported by Stephen Tayler in another thread > <https://groups.google.com/d/topic/firebug/z-3HrzoBHoY/discussion>. > Currently this can't be reproduced by us, so we need a proper test case. As > I understand Stephen he also uses d3.js, so maybe it's related to that? > >> >> 1. Sometimes breakpoints stop in the wrong line. In the script view, >> I see the breakpoint on line 216, but it's stopping on 211 for it. (both >> line numbers are green (active) ) >> >> May be related to issue 7301 > <https://code.google.com/p/fbug/issues/detail?id=7301>. If your test case > doesn't fit to what is described in there, please file a new issue and > provide a test case for it. > >> >> 1. Memory leaks. I have to restart FF / FB periodically because my >> memory keeps creeping up. I'll investigate whether this is my fault or >> not, >> but I never noticed this problem until FB 2.0 / FF 30 >> >> This needs to be investigated further. A meta-issue for this is reported > in issue 2601 <https://code.google.com/p/fbug/issues/detail?id=2601>. > Though if you see a memory spike on a specific action you do in Firebug, > please let us know. > >> >> 1. In the scripts tab, sometimes the source file is clipped. E.g., my >> file is 200 lines, but only say, 43 lines are shown. Sometimes it appears >> later, sometimes not. >> >> I didn't see that yet. Does this also happen on a fresh Firefox profile > with just Firebug installed > <https://getfirebug.com/wiki/index.php/Install_Firebug_into_a_clean_profile>? > Is it clearly reproducible or does this happen randomly? > > Sebastian > -- You received this message because you are subscribed to the Google Groups "Firebug" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/firebug. To view this discussion on the web visit https://groups.google.com/d/msgid/firebug/cf308051-2aa5-495a-8045-a270196a4ac7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
