Firebug/WeeklyUpdates/2014-04-22

Jan Odvarko, Sebastian Zartner, Florent Fayolle, Simon Lindholm, Joe Walker, Jakob Kaltenbrunner, Christoph Dorn, Belakhdar Abdeldjalil

Firebug Releases

• Firebug 2 beta 3
  • Honza: do release on Friday
  • Everyone: tips for blog post news

Firebug 2 Blockers

• Issue 7381: Execution stops on error after reload when 'Break On All Errors' is not active
  • Honza: take a look
• Issue 7203: A throbber should appear when setting a breakpoint in the Console panel
  • Farshid: status?
• Issue 7127: Fix "Break On All Errors" in regard of "Break On Exceptions" and "Ignore Caught Exceptions"
  • If anyone has any suggestions, please post a comment.
  • The "Break on All Errors" could be disabled when "Break on all exceptions" is on.

• Sometimes it is not possible to create a breakpoint
  • Honza: needs STRs
  • There is an exception in the tracing console

• Issue 5440: Integrate EventBug into Firebug
  • Should we add it into Firebug 2?
  • Simon: do some test case + instructions + list of all features
  • Anything not finished?

• Issue 7082: OSX style issues in new UI
  • Thomas doing great progress
  • Honza: give feedback for 1px splitter

e10s Strategies

Round table discussion

Joe:

• Firebug has some better UI aspects, which native tools can and should learn from
• It doesn't make sense to duplicate features (e.g. having two Net panels)
• Firebug has a good set of extensions, which are valuable to people and native tools won't have
• Sometimes native tools hide features to keep the UI simple, maybe there is a role for Firebug in being an advanced UI

Christoph:

• The way how Firebug is extensible is smart
• Firebug did a lot of things right
• The way how templates work is good
• Firebug defined the way how devtools (in different browsers) look today
• Do you want to compete and fade out?
• Do you want to do next step and be innovative again?
• Where you want to be in 5 years?
• Firebug can be a platform that integrates web services (tools). Not only Firefox extensions but consuming also web services.
• e10s is key for Firebug survival
• Does FirePHP work with Firebug 2?
• You can get more contributors by offering right API.
• You'll attract more contributors if the infrastructure is great and extensible.

Sebastian

Overall strategy:

• Keep Firebug a separate tool but interact with the DevTools
• Rebuild it based on RDP to make it e10s ready
• Use (reworked) APIs of the DevTools as far as possible
• Implement unique but important features to make it outstanding of the other tools

Steps how to reach that goal:

1. Implement a fallback for the case we're not ready when e10s is obligatory (i.e. turn off e10s for Firebug or run it in the client process)
2. Create some general functionality to access the page remotely (I guess that's what Honza calls the SDK)
3. Locate each point where Firebug accesses the page directly
4. Rework the located points, so that they access the page through RDP and e10s messages, first general things like TabWatcher than panel by panel, using DevTools APIs where applicable; while doing that already add some new features
5. Add more new features on top of the new structure

Notes from the meeting:

• Interaction with devtools: little features like new commands for the command line
• New actors would have to be created, but actors for cookies, index DB has landed already
• Existing actors can be monkey patched.
• Sebastian estimate for e10s adoption: 1 year (optimistic) - 2 years (pessimistic).
• Firebug is still preferred by some users because it has a better UI
• There are still a lot of users of Firebug Lite

Florent

Axes:

• Being able to maintain Firebug
• Keep our identity as a DevTool
• Keep our users
• Introduce features to innovate

Overall strategy (with targets axes):

• Keep our current UI logic (panel name, layout, etc. ; people are used to it) -- Axe 2, 3
• Implement features that are necessary to most of the developers but won't be integrated to the DevTools, so we don't compete -- Axe 3, 4
• Reuse good ideas from the DevTools -- Axe 3
• Be RDP compliant in some ways to be e10s ready -- Axe 1, 3

Steps how to reach that goal:

• Clearly define what is the playground of Firebug and the DevTools one.
• Use the API of the DevTools
• Progressively, integrate Firebug into the DevTools

We are not shielded from another issue related to Firefox changes (we already have experienced it with JSD1 -> JSD2 and now with e10s, maybe there will be something else afterwards...). That's the reason why relying on the DevTools API and a narrow cooperation with their team look the most viable option.

Notes from the meeting:

• We don't have enough time.
• We need to define the playground (unique set of features that are not in native tools to avoid).
• Why Firebug should lose users?
• We could integrate existing extensions into Firebug
• If we integrate too many addons, users could be confused.
• We should not turn Firebug into something like the Web Developer toolbar (too much unrelated features)
• The way how to define new features:
  • Target a lot of users
  • Make sure features are related
  • Features, which are not integrated by the devtools
• We can have a group working on dev-tools extensions

Djalil

Overall strategy:

• Make firebug an advenced debuger (rest client, perf analytics, js game debuger, ...)
• Keep it as simple as now (keep same design)
• Keep existing panel (dont know if it's possible)

Steps how to reach that goal:

1. Integrate devtools, i dont think we have choise, it's not only about e10s but also about all the new things (sourcemap, webgl/ canvas debuging, ...) i know that it's a difficulte decision, for me firebug was a revolutionary tools and now it's time for a new revolution.

Honza

Overall strategy:

• Firebug doesn't compete with native tools
• Firebug is extending native tools.
• Firebug focuses on unique features (e.g. analytic tools, support for JS libs, client-server debugging)

Steps how to proceed:

1. Build DevTools SDK on top of native tools (code name Firebug SDK)
2. Use existing e10s infrastructure from native tools through SDK.
3. Build unique features on top of the SDK

Simon

Overall strategy:

• compete with native tools (we are established, have a nice UI, and our base functionality - which is what matters most - is really solid; hence I think we can be successful in doing this)
• build parts of Firebug on top of devtools backend, to move faster (and get closer to remoting)
• focus on unique features

Steps how to proceed:

1. Investigate running Firebug in the content process, or otherwise find workarounds for e10s. Much of what strategy to choose hinges on this. IMO no other solution will be ready in the right time frame, and we'll still have users wanting to continue use the original Firebug, so this is critical is either case. Assuming we can cope:
2. Slowly move towards remoting by rebuilding on top of devtools backend.
3. Build some new features ourselves, and others (e.g. clones of new features) with help of devtools APIs.