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 ==

Line 17:

Line 17:

! 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 || -

|-

|-

-

| Final Release || -

+

| Final release || -

|}

|}

-

* 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 31:

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 ====

+

==== Sniff WebSocket traffic ====

-

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.

+

WebSocket requests should be displayed to the user.

'''Tasks:'''

'''Tasks:'''

-

* Rewrite the functions

+

* Create new tab for WebSocket requests

-

* Add JSDocs to all functions

+

* Listen to WebSocket traffic

+

* Dynamically output the WebSocket messages

-

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

+

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

-

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

+

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

'''Tasks:'''

'''Tasks:'''

-

* Integrate Orion into the Source Edit Mode

+

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

-

* Ajust the display to fit to the Firebug UI

+

* 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)

-

==== Cache options ====

+

==== Display authored CSS color values ====

-

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

+

There should be an option allowing the user to display the CSS color values as they were defined.

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

-

Final release

-

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.