If a significant new feature (or set of features) is introduced in new release, the version numbering can move into 2.* scheme. An example of such feature can be support for remote debugging.

+

If a significant new feature (or set of features) is introduced in new release, the version numbering can move into 2.* scheme. An example of such a feature can be support for JSD2 or even remote debugging.

== Schedule ==

== Schedule ==

−

The goal is to introduce new Firebug release till April 2013

−

{| class="wikitable" style=""

{| class="wikitable" style=""

|-

|-

! style="width:200px" | Phase || style="width:200px" | Start Date

! style="width:200px" | Phase || style="width:200px" | Start Date

|-

|-

−

| Alpha || Started

+

| Alpha || 2013-08-14

|-

|-

−

| Beta || -

+

| Beta || 2013-01-14

|-

|-

−

| Final Release || -

+

| Final release || 2013-02-14

|}

|}

−

* The entire release cycle (from the first alpha to the final release) should target 4-5 months

+

* The entire release cycle (from the first alpha to the final release) should target 6 months

* The beta phase should be at least 4 weeks

* The beta phase should be at least 4 weeks

* The new release should introduce 8-10 new features (or significant bug fixes)

* The new release should introduce 8-10 new features (or significant bug fixes)

Line 33:

Line 31:

Use this section to suggest any feature you'd like to see in Firebug.next.

Use this section to suggest any feature you'd like to see in Firebug.next.

* Request auto-responder in the [[Net Panel]] ([http://code.google.com/p/fbug/issues/detail?id=6459 issue 6459]; reason: makes much easier to debug response headers and JS files in a production environment).

The user should have the possibility to choose certain event types to be logged to the [[Console Panel]].

+

For shorthand CSS properties it should be possible to expand them to see the longhand properties that make them up.

'''Tasks:'''

'''Tasks:'''

−

* Create menu items for the different event groups

+

* Save the longhand properties to every shorthand property

−

* Refactor setting the event types to work together with the ones set via <code>[[monitorEvents()]]</code>.

+

* Create a twisty and allow toggling the display of the longhand properties

+

* Remove the ''Expand Shorthand Properties'' option

−

==== Libraries code rewrite ====

−

The APIs inside the <code>/lib</code> should be refactored to simplify and optimize them. Because extensions are also using these functions, it is important to keep the backward compatibility as far as possible.

−

'''Tasks:'''

+

==== Sniff WebSocket traffic ====

−

* Rewrite the functions

+

WebSocket requests should be displayed to the user.

−

* Add JSDocs to all functions

+

−

+

−

==== Line numbers in CSS Edit Mode ====

+

−

The Source Edit Mode of the [[CSS Panel]] should have line numbers for easier navigation.

+

'''Tasks:'''

'''Tasks:'''

−

* Integrate Orion into the Source Edit Mode

+

* Create new tab for WebSocket requests

−

* Ajust the display to fit to the Firebug UI

+

* Listen to WebSocket traffic

+

* Dynamically output the WebSocket messages

−

==== Cache options ====

+

==== Display the return value and the exception thrown ====

−

Reading the Firebug preferences from the Firefox preferences should just happen once to avoid unnecessary disk accesses.

+

The value being returned or the exception being thrown should be displayed to the user.

'''Tasks:'''

'''Tasks:'''

−

* Adjust <code>getPref()</code>

+

* Display a special "scope" row in the watch panel with these values

−

* Adjust <code>setPref()</code>

+

* Change the background color for this row

+

* Give the ability to edit the return value (future plan)

+

* Prevent the user from editing the exception thrown or the return value (for now)

Version Numbering

If a significant new feature (or set of features) is introduced in new release, the version numbering can move into 2.* scheme. An example of such a feature can be support for JSD2 or even remote debugging.

Schedule

Phase

Start Date

Alpha

2013-08-14

Beta

2013-01-14

Final release

2013-02-14

The entire release cycle (from the first alpha to the final release) should target 6 months

The beta phase should be at least 4 weeks

The new release should introduce 8-10 new features (or significant bug fixes)

Suggested Features

Use this section to suggest any feature you'd like to see in Firebug.next.

Feature Description

Adopt JSD2

Firebug script debugger and all related features like BON (break on ...) should be based on new JSD2 API. Using JSD2 API will also enable remote debugging.

Part of this task is also internal Firebug architecture refactoring so it's ready for remote debugging features. Note that adopting JSD2 doesn't automatically mean that Firebug is remote-debugging-ready. This is covered by issue 5837

Note that this task doesn't have to make it into Firebug.next, but it could be possible (if useful) to at least merge code changes.