Firebug14
From MozillaWiki
- Overall
- "Off" text label to close Firebug instead of the X of previous versions (4)
- Doesn't always appear (6, 15)
- Activation behavior is annoying (7)
- Appears to be site-specific
- Can turn on globally for all sites but then when you click "Off" appears to just be per-site Off and will reappear next link you click
- "Off" text label to close Firebug instead of the X of previous versions (4)
- Inspection
- "Edit" label is unintuitive; you can edit in-place without clicking on it
- Default size of "Style" pane causes the text to be laid out in a goofy manner (1)
- In the DOM panel, "get childElementCount" -- why the space between get and childElementCount? (2)
- Firebug inserts a div into the document for itself; long-time behavior but still lame (9)
- Selecting any of the "Show" items from the pull-down menu cause the item you've selected in the inspector to expand erroneously
- + Firebug greys out invisible elements, Safari doesn't (10)
- + Firebug has very useful context menu, Safari doesn't (10)
- - Safari highlights the current line when hovered over
- Console
- Instructions for enabling the console panel are confusing (3)
- color scheme is wonky; bar beneath firebug main bar is a different shade of dark gray (4)
- weird "enabling javascript debugger to support console" message (4)
- weird "Reload to activate window console" message (6)
- "Larger Command Line" UI confusing (5)
- - Auto-complete is nice but Safari's is nicer as it shows preview of autocompletion text
- ReferenceError error message is confusing / useless in referencing Firebug source snippet (8)
- CSS
- "Edit" label is unintuitive; you can edit in-place without clicking on it
- Why is this panel necessary given HTML panel's Style sub-panel
- Code
- - No word-wrap; Safari has it (11 vs 12) But, Safari's word-wrap can lock the UI for really long lines
- - No syntax-hightlighting of JS code; Safari has it when code isn't embedded in HTML (13 vs 14)
- +/- Great that we show eval code as options; bad that it's mixed in with normal code, can make it hard to find what you're looking for (Safari lacks eval, but as a result easier to find the code you want) (21)
- When you have a lot of JS, the pop-up menu gets very unwieldy. Safari does suffer the same problem. (23)
- + Much more responsive than Safari which frequently locks the UI as you select different code blocks (tested bespin.mozilla.com)
- Weird "Warning. Script Panel was inactive during page load" error from time to time that tells me I must "Reload to see all sources" (22)
- +/- We gray out the line numbers of lines that are apparently invalid for breakpoints, but we do let you set breakpoints on them. Safari also lets you set invalid breakpoints and does not indicate that such lines are invalid in any way, but the line numbers are more aesthetic and ours flicker constantly when scrolling. (24 vs 25)
- Safari has a weird UI where it *always* remembers where you set breakpoints until you refresh; not sure if this is an advantage or not (26)
- + Safari has a bug where if you reload within the script debugger view, you lose the code entirely and have to reload the page; debugger is in a weird state after this (33)
- - Safari's debugger UI for call stack and variables is far more aesthetic than ours (note our childish debugger icons) and the variables are more usefully organized into "Local" and "Global" categories; ours is fairly confusing (27 vs 28).
- +/- Our stack gives more useful information than Safari's at first glance (name of function verses "(anonymous function)") but this is a tenuous win as Safari tells you the name of file and line number and we don't, plus Safari makes it clear where you are in the stack and we don't (29 vs 30)
- + We have a nifty feature to see and toggle all breakpoints in the current page (31); Safari doesn't
- + We have a few other debugger features, like "Break on All Errors", "Decompile for eval() source", and "Track Throw/Catch", plus the mysterious "Show chrome sources" thingie (32). Didn't test these, not sure how well they work.
- + We have "watch" expressions; Safari doesn't
- - Got the debugger in a weird state (Bespin running on localhost) just by stepping through various execution paths for a few minutes. The "watch" panel showed state from a breakpoint, but the stack panel and breakpoints panels were empty. Using the application, it's clear that a function was paused, but other functions continued to execute and the app responded to user interaction. Safari does not have this problem. After playing with the UI
- I'm able to reproduce this issue. I set a breakpoint in the rendering loop for Bespin, and then I interact with Bespin. This is weird enough as I would expect all execution to be paused. But then when I step over a few lines, remove the breakpoint, and continue execution, the UI no longer behaves normally--in this case, the cursor blink ceases to function.
- Safari has its own issues. Breakpoints can persist across page reloads with no visual indication that they have been set. It's not clear how to turn them off when this occurs, and in my own experience resetting them and then clearing them doesn't always work.
- However
- DOM
- Slightly confusing; browser for all JS objects, not just DOM
- Not sure if better or worse than Safari's approach of expanding objects in the console
- Net
- - Disabled by default; after enabling, says "Net panel activated. Any requests while the net panel is inactive are not shown." Reloading the page results in Firebug de-activating for some reason (due to weird activation behavior cited above). Safari doesn't force you to reload the page when turning on their equivalent feature.
- Appears that you have to select "On for All Web Pages" and then reload in order for it to work
- Pretty aggressive in displaying "Net panel activated" messages (16)
- Could be more clear what the blue and red vertical lines mean, but the pop-up on hover is good (17)
- + We have more granular resource loading data than Safari (17 vs. 18)
- - After page finishes loading, subsequent loading information is displayed in the wrong scale; confusing (19). Safari expands the timeline as you would expect, though it does make it harder to read. (20)
- - Disabled by default; after enabling, says "Net panel activated. Any requests while the net panel is inactive are not shown." Reloading the page results in Firebug de-activating for some reason (due to weird activation behavior cited above). Safari doesn't force you to reload the page when turning on their equivalent feature.
