Firebug issues and bug reports.
John J. Barton
I want to outline things Firebug wants from Mozilla. But to understand
my priorities, I want to start with our goal: Firebug has to be the
run-away, hands-down best web debugger. Being compatible with Firefox is
not enough; debugging Javascript is not enough; being marginally better
in some ways is not enough. I believe that Firebug is a substantial
reason web developers choose Firefox and that in turn helps create web
pages that work excellent with Firefox as well as furthering the overall
Mozilla goal of excellent open web. All the major browsers have Firebug
look-a-likes now so we need leap ahead.
An overview of Firebug development plans is here:
http://getfirebug.com/workingGroup/2009/FirebugWorkingGroup30APR09.html
My top priority now is bug 448602 (and 506961), because it is so close,
we need it for AJAX accessibility tools, and it provides important new
value to developers.
The jsd code predates web 2.0; a large but focused problem is jsd2, bug
449452. I'd give more details if someone works on this. For now I have a
patch for bug 449464 as a way to get started, it provides callback
events per Javascript compilation unit, superseding onScriptCreated(). I
plan to invest half of my time on this during Firebug 1.5.
A looming problem is updates needed for CSS, HTML5, SVG, XML, and as we
have discussed, new infrastructure like Workers and Storage support. I
don't know how much of this needs platform help since I pretty much can
only look into these cases when users complain. Some of the things we
know about include Bugs 503007 js access to user agent css, 342715 to
sort out the windows, 391177 similar, 507783 for tracking Workers. Some
of this is just Firebug work.
A broad problem, touching large parts of mozilla is the error message
problem, 435025. Briefly we need to know which window the error comes
from, what line of source (for non-JS/xpcom), and better messages (xpcom).
We also want to improve the net panel for better timing, 488270.
Generally our plan is to put more events on this panel so users can see
when things are happening, a Timeline more than a Net panel. For example
we plan to show paint, memory pressure, and gc events.
We plan to extend "break on <event>" to increase integration between JS
and CSS/HTML. We will do what we can for Firebug 1.5 and file bug
requests to make it better once we understand what to ask for.
Another major area is remote debug support, in case Firefox goes to
multi-process. Also relates to Bespin, Worker threads, and cross-browser
Firebug. I think almost all of this work needs to move forward within
the JS layer until we have an API and code with some functionality or
performance problems. IBM in the form of Mike Collins has agreed to
contribute code to Firebug for remote access to debug features, see
http://groups.google.com/group/webdebugprotocol
The firebug-related mozilla bugs I watch are tagged with Whiteboard
[firebug-p1] or [firebug-p2] or [firebug-p3], one being highest.
jjb
Rob Campbell
> (In response to Boris' request).
I think this is a great crack at getting us better-situated on the
platform and should give us the opportunity to start making gecko do
what we want it to instead of the other way around.
> I want to outline things Firebug wants from Mozilla. But to understand
> my priorities, I want to start with our goal: Firebug has to be the
> run-away, hands-down best web debugger. Being compatible with Firefox is
> not enough; debugging Javascript is not enough; being marginally better
> in some ways is not enough. I believe that Firebug is a substantial
> reason web developers choose Firefox and that in turn helps create web
> pages that work excellent with Firefox as well as furthering the overall
> Mozilla goal of excellent open web. All the major browsers have Firebug
> look-a-likes now so we need leap ahead.
Do you have any criteria by which we could measure how Firebug is the
"Best" web debugger? Not to diffuse what you're striving for here, but I
think some definition of "how Firebug can be the best" is worth some
consideration.
I also think it's worth making a strenuous effort to not degrade the
browser in any way with the debugger installed and active. It should be
fully-usable. If people have to switch profiles or disable other
extensions, that makes it harder to love.
> An overview of Firebug development plans is here:
> http://getfirebug.com/workingGroup/2009/FirebugWorkingGroup30APR09.html
This is pretty incomplete and, imo, vague view of what we should be
planning for. It doesn't take into account some of Honza's (Odvarko's)
ideas and other possible directions we should be looking at for next
versions. Fortunately, you covered some details below.
Overall UI code is confusing and kind of quirky. The whole thing is
custom code from the ground up and I wouldn't mind going through it and
trying to make some updates and improvements.
We're hearing random reports (e.g., from Twitter, not the most precise
or effective way of submitting bug reports, but I think the collection
of messages is worthy of consideration that "there's something there")
about performance issues with Firebug installed. Doing a rudimentary run
with stand-alone Talos last week, I measured an approximate 7%
degradation in performance with Firebug installed. This is in a clean,
Talos-generated profile.
Probably not a high enough number to reflect what users are complaining
about, but it is something. I think you suggested it could be due to the
way Firebug does a look-up onlocationchange to check the places database
for an annotation. More-likely, users are complaining because when they
turn on Firebug, they're getting a dual-hit for script debugging and
network monitoring. We should strive to make these less of a pain.
Anyway, just a couple of things we should be considering in addition to
the bugs you mention below. Having additional help would be a boon, so,
platform (and Firefox) guys, if you're interested...
> My top priority now is bug 448602 (and 506961), because it is so close,
> we need it for AJAX accessibility tools, and it provides important new
> value to developers.
>
> The jsd code predates web 2.0; a large but focused problem is jsd2, bug
> 449452. I'd give more details if someone works on this. For now I have a
> patch for bug 449464 as a way to get started, it provides callback
> events per Javascript compilation unit, superseding onScriptCreated(). I
> plan to invest half of my time on this during Firebug 1.5.
Kind of a chicken and egg problem. Giving more details if someone offers
to help.
I know at least two people who are at least somewhat interested in
making changes to the jsd layer. Taras Glek and Timeless to name them.
> A looming problem is updates needed for CSS, HTML5, SVG, XML, and as we
> have discussed, new infrastructure like Workers and Storage support. I
> don't know how much of this needs platform help since I pretty much can
> only look into these cases when users complain. Some of the things we
> know about include Bugs 503007 js access to user agent css, 342715 to
> sort out the windows, 391177 similar, 507783 for tracking Workers. Some
> of this is just Firebug work.
yeah, I think we can make some improvements to HTML and CSS panels in
Firebug. There are a few features and bugs we can probably add there.
> A broad problem, touching large parts of mozilla is the error message
> problem, 435025. Briefly we need to know which window the error comes
> from, what line of source (for non-JS/xpcom), and better messages (xpcom).
there are a *lot* of dependent bugs attached there.
Do we have any concrete ones we could start asking for help with?
> We also want to improve the net panel for better timing, 488270.
> Generally our plan is to put more events on this panel so users can see
> when things are happening, a Timeline more than a Net panel. For example
> we plan to show paint, memory pressure, and gc events.
Net Panel is stalled on this bug for 1.5, gecko 3.6. Bug 488270 - New
APIs for precise time measurement. I think there's a patch but it's
still stuck in review land.
Talking with Honza (odvarko - E_TOO_MANY_HONZAS), we discussed a few
other things for the timeline, like moz-after-paint events, reflows and
others.
Not sure if memory would make sense there or in a separate panel. In
either case, I'm anxiously awaiting word on tracevis and ben and dion's
memory tool.
> We plan to extend "break on <event>" to increase integration between JS
> and CSS/HTML. We will do what we can for Firebug 1.5 and file bug
> requests to make it better once we understand what to ask for.
For the HTML panel, saving rendered/changed markup (issue 9) is probably
the single most-requested feature. Kevin Decker's been working on an
extension to provide this, but I'd really like to see something
implemented in Firebug core to provide it.
The inspector issues are another painful area. Mike Ratcliffe began work
on a canvas-based inspector overlay implementation but it's currently
quite slow. I've offered to help him with this and there are likely
going to be some platform bugs filed to improve performance.
> Another major area is remote debug support, in case Firefox goes to
> multi-process. Also relates to Bespin, Worker threads, and cross-browser
> Firebug. I think almost all of this work needs to move forward within
> the JS layer until we have an API and code with some functionality or
> performance problems. IBM in the form of Mike Collins has agreed to
> contribute code to Firebug for remote access to debug features, see
> http://groups.google.com/group/webdebugprotocol
>
> The firebug-related mozilla bugs I watch are tagged with Whiteboard
> [firebug-p1] or [firebug-p2] or [firebug-p3], one being highest.
Thanks for getting this started, John.
--
Rob Campbell - robcee _ mozilla _ com (fill in the blanks!)
http://antennasoft.net/robcee
Jan Odvarko
> APIs for precise time measurement. I think there's a patch but it's
> still stuck in review land.
I would like to yet highlight the importance of the
https://bugzilla.mozilla.org/show_bug.cgi?id=488270
bug.
This is critical for the Net panel and I hope the fix will be part of
Fx 3.6.
The patch (quite simple) is there and only needs review.
Honza
Mike Shaver
Could you request review on it, then, please?
Mike
Mike Beltzner
there another potential reviewer for that code space? jduell?
cheers,
mike
On 11-Aug-09, at 3:58 PM, Mike Shaver wrote:
> On Tue, Aug 11, 2009 at 2:39 PM, Jan Odvarko<odv...@gmail.com> wrote:
> Could you request review on it, then, please?
>
> Mike
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform