991806 - (firebug-gaps) [meta] Firebug Gaps

Status: NEW

(DevTools :: General, enhancement, P3)

Description

[Jeff Griffiths (:canuckistani) (:⚡︎)]

This is a tracking bug that should depend on any bugs related specifically to fixing gaps in functionality with Firebug.

Comment 1

[Patrick Brosset <:pbro>]

See https://etherpad.mozilla.org/devtools-firebug-gaps-prio for a list of gaps.

Comment 2

[Albert Scheiner [:alberts]]

would Firebug's option in the CSS panel > right click > "Add Rule ..." be something for this list?
( example: https://getfirebug.com/img/css/screenCSS-copy.png )

Comment 3

[Patrick Brosset <:pbro>]

(In reply to albert from comment #2)
> would Firebug's option in the CSS panel > right click > "Add Rule ..." be
> something for this list?
> ( example: https://getfirebug.com/img/css/screenCSS-copy.png )
It's already in the list: bug 966895

Comment 4

[Patrick Brosset <:pbro>]

Removed bug 991662 from the dependencies, this is just a bug we need to fix, not a feature gap.

Comment 5

[Joe Walker [:jwalker]]

Bug 983600 landed - "Place inspector first in list of tools". This is a dup of bug 991810, "Move the inspector button to the top left" because bug 983600 does both things.

In terms of firebug gaps this is one step forwards (inspector button to top left) and one step backwards "inspector first in list of tools).

We have data to show that the inspector should be first (Jeff's telemetry data that shows inspector being used more than the console even though it's not first on the list), and and understanding of why that is "html is easier than JS".

Firebug devotees however will probably hate this and our Firebug theme should probably have a way to reset the ordering back to console-first.

If we get lots of push-back on the ordering outside of Firebug users, then we might need a global option.

Comment 6

[Brian Grinstead [:bgrins]]

(In reply to Joe Walker [:jwalker] from comment #5)
> Bug 983600 landed - "Place inspector first in list of tools". This is a dup
> of bug 991810, "Move the inspector button to the top left" because bug
> 983600 does both things.
> 
> In terms of firebug gaps this is one step forwards (inspector button to top
> left) and one step backwards "inspector first in list of tools).
> 
> We have data to show that the inspector should be first (Jeff's telemetry
> data that shows inspector being used more than the console even though it's
> not first on the list), and and understanding of why that is "html is easier
> than JS".
> 
> Firebug devotees however will probably hate this and our Firebug theme
> should probably have a way to reset the ordering back to console-first.

This is outside of the current theming capabilities - each tool uses a property on the tool object itself for ordering.  But if we switched to flexbox for the tabs we could use the flex `order` property to switch them from CSS.

> If we get lots of push-back on the ordering outside of Firebug users, then
> we might need a global option.

If we do decide that the order should be changeable per user, we could consider allowing sorting on the list of tools in the settings page so that it could be fully customized, rather than this one special case.

Comment 7

[Joe Walker [:jwalker]]

(In reply to Brian Grinstead [:bgrins] from comment #6)
> (In reply to Joe Walker [:jwalker] from comment #5)
> > Bug 983600 landed - "Place inspector first in list of tools". This is a dup
> > of bug 991810, "Move the inspector button to the top left" because bug
> > 983600 does both things.
> > 
> > In terms of firebug gaps this is one step forwards (inspector button to top
> > left) and one step backwards "inspector first in list of tools).
> > 
> > We have data to show that the inspector should be first (Jeff's telemetry
> > data that shows inspector being used more than the console even though it's
> > not first on the list), and and understanding of why that is "html is easier
> > than JS".
> > 
> > Firebug devotees however will probably hate this and our Firebug theme
> > should probably have a way to reset the ordering back to console-first.
> 
> This is outside of the current theming capabilities - each tool uses a
> property on the tool object itself for ordering.  But if we switched to
> flexbox for the tabs we could use the flex `order` property to switch them
> from CSS.

Absolutely, I'm expecting that an FB theme will include code

> > If we get lots of push-back on the ordering outside of Firebug users, then
> > we might need a global option.
> 
> If we do decide that the order should be changeable per user, we could
> consider allowing sorting on the list of tools in the settings page so that
> it could be fully customized, rather than this one special case.

Yes. We should see how much pushback we get on the ordering change first.

Comment 8

[Tim Nguyen :ntim]

Since I didn't like the moving change, I created this userstyles to move things back :
@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
/* The inspector tab part doesn't seem to work :( */
#toolbox-tab-inspector.devtools-tab {-moz-box-ordinal-group:2 !important}
/* This part should now work */
#toolbox-option-container {-moz-box-ordinal-group:0 !important;}
#toolbox-tabs {
  -moz-box-ordinal-group: 1 !important;
}

#toolbox-picker-container {-moz-box-ordinal-group:2 !important}
#toolbox-buttons {-moz-box-ordinal-group: 3 !important;}

#toolbox-controls-separator {-moz-box-ordinal-group: 4!important;visibility:visible !important;margin-right:5px !important;}
#toolbox-controls {-moz-box-ordinal-group: 5 !important;}
#openwith-toolboxbox {
  -moz-box-ordinal-group:5 !important;
}

Comment 9

[Jens]

IMHO this bug should also depend on #1004511, see comment at https://bugzilla.mozilla.org/show_bug.cgi?id=1004511#c2 The devtools' search boxes miss functionality compared to the ones in Firebug. Maybe someone could add this dependency as I don't have permission to do so.

Comment 10

[Sebastian Zartner [:sebo]]

You're right. I've added it.

Sebastian

Comment 11

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Sebastian Zartner [:sebo] from comment #10)
> You're right. I've added it.
> 
> Sebastian

needinfo'ing Bryan. While we do strive for relative parity with Firebug, we're not going to reimplement everything if it doesn't make sense.

Comment 12

[Jens]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #11)
> (In reply to Sebastian Zartner [:sebo] from comment #10)
> > You're right. I've added it.
> > 
> > Sebastian
> 
> needinfo'ing Bryan. While we do strive for relative parity with Firebug,
> we're not going to reimplement everything if it doesn't make sense.

Jeff, when I have 100 search results and want to go to the previous result, then I have to press <enter> 99 times in the devtools to cycle through all results. This drives my nuts (especially if I press <enter> once to much, then I have to cycle through all results again). In Firebug I just click on "Prev" button once.

Comment 13

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #11)
> needinfo'ing Bryan. While we do strive for relative parity with Firebug,
> we're not going to reimplement everything if it doesn't make sense.

Looking at creating a Firebug Q1 meta bug to gather the priorities into one place.

(In reply to Jens from comment #12)
> Jeff, when I have 100 search results and want to go to the previous result,
> then I have to press <enter> 99 times in the devtools to cycle through all
> results. This drives my nuts (especially if I press <enter> once to much,
> then I have to cycle through all results again). In Firebug I just click on
> "Prev" button once.

Understood, Jeff didn't mean to call out this particular bug but that in general there are a lot of UI elements like Panels and such that we should think carefully about integrating instead of just moving them over wholesale.  Some things already exist in devtools but are poorly organized, just want to be deliberate about the additions.

Comment 14

[Sebastian Zartner [:sebo]]

With Firefox 50 and enabling e10s by default on more and more machines Firebug began to break for users. Some of them are already complaining on the Firebug discussion group[1], because they are missing features and say that the UX in Firebug was better. Those users currently seem to prefer to switch over to the Chrome DevTools in case Firebug is not working anymore for them instead of staying with Firefox.

Patrick, I know the team is busy with devtools.html, though could some of the blockers of this bug be prioritized to provide Firebug users a smooth transition (and to improve the UX of the DevTools)?
I've previously asked Firebug users for the most important issues[2] in relation to bug 1267303. I may direct people to that thread again to tell what what they are missing most if that helps in any way.

Sebastian

[1] https://groups.google.com/forum/#!forum/firebug
[2] https://groups.google.com/d/topic/firebug/Q6eyvGt6hyI/discussion

Comment 15

[Patrick Brosset <:pbro>]

(In reply to Sebastian Zartner [:sebo] from comment #14)
> With Firefox 50 and enabling e10s by default on more and more machines
> Firebug began to break for users. Some of them are already complaining on
> the Firebug discussion group[1], because they are missing features and say
> that the UX in Firebug was better. Those users currently seem to prefer to
> switch over to the Chrome DevTools in case Firebug is not working anymore
> for them instead of staying with Firefox.
> 
> Patrick, I know the team is busy with devtools.html, though could some of
> the blockers of this bug be prioritized to provide Firebug users a smooth
> transition (and to improve the UX of the DevTools)?
> I've previously asked Firebug users for the most important issues[2] in
> relation to bug 1267303. I may direct people to that thread again to tell
> what what they are missing most if that helps in any way.
> 
> Sebastian
> 
> [1] https://groups.google.com/forum/#!forum/firebug
> [2] https://groups.google.com/d/topic/firebug/Q6eyvGt6hyI/discussion
Thanks a lot Sebastian.

I guess there are 2 main categories:
- feature gaps,
- and small differences in the location or behavior of existing features.

For feature gaps, I looked at bug 1267303 and it seems to be:
- break on XHR and DOM mutations
- event side panel
- rule-view validity feedback as you type
- console auto-complete improvements.

It would be great if we could ask users today if this is still the right list of things to work on.
Could you reach out on the Firebug mailing list?
I'll also do it on the @FirefoxDevTools twitter account and the dev-developer-tools mailing list.

For small differences, this is going to be harder to get however. When switching tools, it's often the little differences that hurt. The problem with those, is that it isn't an easy thing for users to report. It's usually the sum of all of them that make people think that the new tool they've been force to use isn't doing the job, but calling out precisely any single detail is hard.
Very often though, there isn't a reason for us to be slightly different from Firebug (or Chrome for that matter), so we need to continue and keep an eye on this, and smooth out rough edges where we can (this is something we've been doing over the past, and need to continue, the most recent one I have in mind is bug 1316528 which you file).

Comment 16

[Sebastian Zartner [:sebo]]

(In reply to Patrick Brosset <:pbro> from comment #15)
> (In reply to Sebastian Zartner [:sebo] from comment #14)
> > With Firefox 50 and enabling e10s by default on more and more machines
> > Firebug began to break for users. Some of them are already complaining on
> > the Firebug discussion group[1], because they are missing features and say
> > that the UX in Firebug was better. Those users currently seem to prefer to
> > switch over to the Chrome DevTools in case Firebug is not working anymore
> > for them instead of staying with Firefox.
> > 
> > Patrick, I know the team is busy with devtools.html, though could some of
> > the blockers of this bug be prioritized to provide Firebug users a smooth
> > transition (and to improve the UX of the DevTools)?
> > I've previously asked Firebug users for the most important issues[2] in
> > relation to bug 1267303. I may direct people to that thread again to tell
> > what what they are missing most if that helps in any way.
> > 
> > Sebastian
> > 
> > [1] https://groups.google.com/forum/#!forum/firebug
> > [2] https://groups.google.com/d/topic/firebug/Q6eyvGt6hyI/discussion
> Thanks a lot Sebastian.

Thank you for the fast response!

> I guess there are 2 main categories:
> - feature gaps,
> - and small differences in the location or behavior of existing features.

Correct. Well, smaller and bigger differences in behavior, I'd say.

> For feature gaps, I looked at bug 1267303 and it seems to be:
> - break on XHR and DOM mutations
> - event side panel
> - rule-view validity feedback as you type
> - console auto-complete improvements.
> 
> It would be great if we could ask users today if this is still the right
> list of things to work on.
> Could you reach out on the Firebug mailing list?

I asked in several threads now to post to https://groups.google.com/forum/#!topic/firebug/Q6eyvGt6hyI/discussion.

> I'll also do it on the @FirefoxDevTools twitter account and the
> dev-developer-tools mailing list.

Great, thanks!

> For small differences, this is going to be harder to get however. When
> switching tools, it's often the little differences that hurt. The problem
> with those, is that it isn't an easy thing for users to report. It's usually
> the sum of all of them that make people think that the new tool they've been
> force to use isn't doing the job, but calling out precisely any single
> detail is hard.

You're totally right.
Though note that people still love Firebug especially for it's UI, which still has some advantages over other tools. And those smaller and bigger UI features and differences are what made Firebug great and what users are now missing most.

> Very often though, there isn't a reason for us to be slightly different from
> Firebug (or Chrome for that matter), so we need to continue and keep an eye
> on this, and smooth out rough edges where we can (this is something we've
> been doing over the past

I know, and thank you for that!

> and need to continue, the most recent one I have in mind is bug 1316528 which you file).

I am trying to file all those things step by step, though there are more pressing issues, I think. So, let's wait for the answers we get from the mailing list and Twitter.

Sebastian

Comment 17

[Patrick Brosset <:pbro>]

It's proving hard to get feedback (as always). So far I've mostly spent time telling people that we already had the features they were requesting. Apart from this, here are the things people have asked for:
- font-size in the Firebug theme: bug 1319079
- live previewing changes made in the markup-view (when editing attributes, text content or HTML): bug 815464 and bug 1067318.

I think these 2 plus what I said in comment 15 would make a good list:
- break on XHR and DOM mutations
- event side panel
- rule-view validity feedback as you type
- console auto-complete improvements.

Please let us know if you hear anything else on your side. I'll try and see how we can plan this.

Comment 18

[Sebastian Zartner [:sebo]]

(In reply to Patrick Brosset <:pbro> from comment #17)
> It's proving hard to get feedback (as always).

Yes, I didn't get any new feedback so far. :-/

> So far I've mostly spent time telling people that we already had the features they were requesting.

And some obviously misunderstood your post[1] as a request for arbitrary new features or the other way round.

> Please let us know if you hear anything else on your side. I'll try and see
> how we can plan this.

Will do. Let wait one or two more days.

Sebastian

[1] For reference: https://twitter.com/FirefoxDevTools/status/800705364446629889

Comment 19

[Sebastian Zartner [:sebo]]

So far I got:

- option to add cookies (bug 1231451 and bug 1231452)
- console log message display improvements (bug 1269730)

Sebastian

Comment 20

[Sebastian Zartner [:sebo]]

I got very good points today:

- Inspector DOM view (bug 704094; actually already exists, though has poor UX)
- CSS auto-completion, especially property values but also selectors (totally missed to mention that, but really annoying)
- Inspector UI update is slow (maybe not a "Firebug gap", but definitely an issue; actually the whole UI is a bit slow, I guess due to the constant client/server communication)

Nothing was mentioned twice, so it's hard to do some priorization. My assumption for priority is:

1. break on XHR and DOM mutations (mainly DOM mutations)
2. CSS auto-completion
3. console auto-complete improvements
4. events side panel
5. live previewing changes made in the markup-view
6. console log message display improvements
7. rule-view validity feedback as you type
8. Inspector DOM view (bug 704094; actually already exists, though has poor UX)
9. font-size in the Firebug theme: bug 1319079
10. option to add cookies (bug 1231451 and bug 1231452)

Sebastian

Comment 21

[Sebastian Zartner [:sebo]]

(In reply to Sebastian Zartner [:sebo] from comment #20)
> - CSS auto-completion, especially property values but also selectors

That should read "missing CSS auto-completion".

Sebastian

Comment 22

[Jim Merick]

In Firebug 2 is possible to change size of position, margins, paddings and the element itself (in Layout panel where is visible box model). In dev tools it is possible change everything except element dimensions. Will it be possible in dev tools (Firebug 3)?

Comment 23

[Tim Nguyen :ntim]

(In reply to Jim Merick from comment #22)
> In Firebug 2 is possible to change size of position, margins, paddings and
> the element itself (in Layout panel where is visible box model). In dev
> tools it is possible change everything except element dimensions. Will it be
> possible in dev tools (Firebug 3)?

You already can, just double click the dimensions in the box-model section of the "Computed" tab in the inspector.

Comment 24

[Albert Scheiner [:alberts]]

(In reply to Tim Nguyen :ntim (use needinfo?) from comment #23)
> (In reply to Jim Merick from comment #22)
> > In Firebug 2 is possible to change size of position, margins, paddings and
> > the element itself (in Layout panel where is visible box model). In dev
> > tools it is possible change everything except element dimensions. Will it be
> > possible in dev tools (Firebug 3)?
> 
> You already can, just double click the dimensions in the box-model section
> of the "Computed" tab in the inspector.

Not working for me, dev edition (52), see video:
https://owncloud.scheiner.cc/index.php/s/qMJJNF7ArFphsTz/download

Comment 25

[Tim Nguyen :ntim]

(In reply to Albert Scheiner [:alberts] from comment #24)
> (In reply to Tim Nguyen :ntim (use needinfo?) from comment #23)
> > (In reply to Jim Merick from comment #22)
> > > In Firebug 2 is possible to change size of position, margins, paddings and
> > > the element itself (in Layout panel where is visible box model). In dev
> > > tools it is possible change everything except element dimensions. Will it be
> > > possible in dev tools (Firebug 3)?
> > 
> > You already can, just double click the dimensions in the box-model section
> > of the "Computed" tab in the inspector.
> 
> Not working for me, dev edition (52), see video:
> https://owncloud.scheiner.cc/index.php/s/qMJJNF7ArFphsTz/download

Ah, yes, it currently doesn't work for the width/height. But some of Jim's use cases are covered (changing margin/padding).

Comment 26

[Sebastian Zartner [:sebo]]

(In reply to Tim Nguyen :ntim (use needinfo?) from comment #25)
> (In reply to Albert Scheiner [:alberts] from comment #24)
> > (In reply to Tim Nguyen :ntim (use needinfo?) from comment #23)
> > > (In reply to Jim Merick from comment #22)
> > > > In Firebug 2 is possible to change size of position, margins, paddings and
> > > > the element itself (in Layout panel where is visible box model). In dev
> > > > tools it is possible change everything except element dimensions. Will it be
> > > > possible in dev tools (Firebug 3)?
> > > 
> > > You already can, just double click the dimensions in the box-model section
> > > of the "Computed" tab in the inspector.
> > 
> > Not working for me, dev edition (52), see video:
> > https://owncloud.scheiner.cc/index.php/s/qMJJNF7ArFphsTz/download
> 
> Ah, yes, it currently doesn't work for the width/height. But some of Jim's
> use cases are covered (changing margin/padding).

Width and height are covered in bug 1061823.

Sebastian

Comment 27

[Keith Ritt]

As a long time Firebug user I am heavily dependent on the 'Open in new tab' option for debuggin AJAX (XHR) calls in the console tab. When I did that, I was able to view the AJAX call in a separate browser tab with the request parameters sent as well. With the Firefox developer tools, the only option I see is one called 'Open URL in new tab', which does almost what I need, but it does not use any of the request data when it opens in a new tab.

Comment 28

[Sebastian Zartner [:sebo]]

(In reply to Keith Ritt from comment #27)
> As a long time Firebug user I am heavily dependent on the 'Open in new tab'
> option for debuggin AJAX (XHR) calls in the console tab. When I did that, I
> was able to view the AJAX call in a separate browser tab with the request
> parameters sent as well. With the Firefox developer tools, the only option I
> see is one called 'Open URL in new tab', which does almost what I need, but
> it does not use any of the request data when it opens in a new tab.

It works for GET requests, but not for POST requests, which is covered in bug 1220758.

Sebastian

Comment 29

[bombledmonk]

The UI for the Console command line is gapped.  The parser for determining when input should be run with enter or shift+enter seems a bit indeterminate. The firebug console had an option for a side panel with a normal text editing area that also allowed for code to be input with white space without having to worry about switching between enter and shift+enter and hoping I'm hitting the right one at the right time.

Comment 30

[Sebastian Zartner [:sebo]]

(In reply to bombledmonk from comment #29)
> The firebug console had an option for a side panel with a
> normal text editing area that also allowed for code to be input with white
> space without having to worry about switching between enter and shift+enter

This is tracked in bug 1133849.

Sebastian

Comment 31

[Arkadiusz Michalski (Spirit)]

This bug also fit to Firebug Gaps
https://bugzilla.mozilla.org/show_bug.cgi?id=1336045
We have this possibility in Firebug, Chrome, but not in FX Dev Tools. Options like preserve logs or enable/dissable cache should be available if main view.

Comment 32

[Arkadiusz Michalski (Spirit)]

https://bugzilla.mozilla.org/show_bug.cgi?id=1320351 << another gap, now in DevTools we have DOM panel but using it is not as comfortable as in Firebug.

Comment 33

[shahajip]

Can anyone guide me how to do following things in dev tools.
1. on for all web pages option
2. Single Dev tools window for all tabs open. (Like firebug)

Comment 34

[Sebastian Zartner [:sebo]]

(In reply to shahajip from comment #33)
> Can anyone guide me how to do following things in dev tools.
> 1. on for all web pages option
Bug 1284012.

> 2. Single Dev tools window for all tabs open. (Like firebug)
Bug 1219917.

Both are listed in the "Depends on" list above.

Sebastian

Comment 35

[shahajip]

@Julian Descottes , @Sebastian Zartner
Thanks.

Comment 36

[alex]

Please correct me if I'm wrong, but I can't find following obvious (for me at least, using it a lot) features:

1. In the Inspector view, I've used to just select the code parts and copy them, right in the "tree" view. 
Not it's not possible in the Web Console. Only attrs/tag names separately. I can switch to "Edit" mode, but then the tree disappears, and everything goes in the solid block without line breaks (probably the way the page was saved, but still). I'd like selecting feature back, since it helps a lot when you need to copy the code.

Comment 37

[alex]

Please correct me if I'm wrong, but I can't find following obvious (for me at least, using it a lot) features:

2. Network panel, there's no way to resize columns. So surprised! It's 2017, 22 years ago I was able to do this in every window in Windows 95... Why?! For example, I'd like to see longer urls - and I can't. My screen is wide enough, but still some unneeded (at the moment) columns occupy all the space, and there are no "disable" nor "resize" features...

Comment 38

[Sebastian Zartner [:sebo]]

(In reply to alex from comment #36)
> 1. In the Inspector view, I've used to just select the code parts and copy
> them, right in the "tree" view. 

Selecting is deactivated, because you can move elements within the tree via drag & drop. As alternatives you can either switch to the edit mode or right-click an element and choose Copy > Outer HTML. Both show/copy the HTML source as it was received through the network (including spaces and line breaks), they do *not* copy the source formatted like shown in the node view.

Regarding that allowing to select text within the tree structure would conflict with the drag & drop feature and the, in my opinion, rather small use case, I assume this won't be implemented. Though if you insist on that feature, you should create a new bug blocking this one, outline your use case and clarify how this could be implemented without conflicting with other features.

(In reply to alex from comment #37)
> Please correct me if I'm wrong, but I can't find following obvious (for me
> at least, using it a lot) features:
> 
> 2. Network panel, there's no way to resize columns. So surprised! It's 2017,
> 22 years ago I was able to do this in every window in Windows 95... Why?!
> For example, I'd like to see longer urls - and I can't. My screen is wide
> enough, but still some unneeded (at the moment) columns occupy all the
> space, and there are no "disable" nor "resize" features...

That's covered by bug 862331. (Not a Firebug gap, because in Firebug you couldn't resize the columns, either.) Hiding columns is covered by bug 862855.

Sebastian

Comment 39

[mj]

No choice for the css font-weight

Comment 40

[Sebastian Zartner [:sebo]]

(In reply to mj from comment #39)
> No choice for the css font-weight

Auto-completion is also missing for several other CSS properties. This is being worked on in bug 1337918 and its blockers.

Sebastian

Comment 41

[Jens]

(In reply to Sebastian Zartner [:sebo] from comment #38)
> (In reply to alex from comment #36)
> > 1. In the Inspector view, I've used to just select the code parts and copy
> > them, right in the "tree" view. 
> 
> Selecting is deactivated, because you can move elements within the tree via
> drag & drop. As alternatives you can either switch to the edit mode or
> right-click an element and choose Copy > Outer HTML. Both show/copy the HTML
> source as it was received through the network (including spaces and line
> breaks), they do *not* copy the source formatted like shown in the node view.
> 
> Regarding that allowing to select text within the tree structure would
> conflict with the drag & drop feature and the, in my opinion, rather small
> use case, I assume this won't be implemented. Though if you insist on that
> feature, you should create a new bug blocking this one, outline your use
> case and clarify how this could be implemented without conflicting with
> other features.

I recently had this as well. I put my use case and implementation idea at new Bug 1343825. Happy if you folks could add your comments there.

Comment 42

[Peter]

I really miss the vertically splitted console panel with multiline edit area. It was better to write code that stayed there after running it.

Comment 43

[Sebastian Zartner [:sebo]]

That's covered in bug 1133849. For now you should have a look at Scratchpad.

Sebastian

[1] https://developer.mozilla.org/en-US/docs/Tools/Scratchpad

Comment 44

[mj]

Something cool on firebug is when you add a new rule, it's sorted in Alphabetical order.
I think it's more effecient.

Comment 45

[decembre56]

I appreciate Firebug to help me when i want make an userstyle.

I try to test the dev tool bar for that but i found that Firefox's Developer Toolbar don't provide Readable Userstyles Name for CSS selector lines (like it is in Firebug).
Read (because my english is not enough , with screenshots):
https://forum.userstyles.org/discussion/53223/firefoxs-developer-toolbar-readable-userstyles-name-for-css-selector-lines-like-firebug#latest

And i miss the FireXPath addon (work only on firebug):
any plan to port it to dev tool bar (or something similar) ?

Comment 46

[Sebastian Zartner [:sebo]]

(In reply to decembre56 from comment #45)
> I appreciate Firebug to help me when i want make an userstyle.
> 
> I try to test the dev tool bar for that but i found that Firefox's Developer
> Toolbar don't provide Readable Userstyles Name for CSS selector lines (like
> it is in Firebug).
> Read (because my english is not enough , with screenshots):
> https://forum.userstyles.org/discussion/53223/firefoxs-developer-toolbar-
> readable-userstyles-name-for-css-selector-lines-like-firebug#latest

This is a meta-bug to keep track of all the different Firebug gaps. So, can you please create a separate bug for this issue and mark it as blocker for this one?
 
> And i miss the FireXPath addon (work only on firebug):
> any plan to port it to dev tool bar (or something similar) ?

Currently, there are bug 963933, bug 987877 and bug 1032855 filed to improve the XPath related functionality, which should mostly cover FirePath's features. If you're missing something else, please file a bug for it.

Sebastian

Comment 47

[decembre56]

(In reply to Sebastian Zartner [:sebo] from comment #46)
> (In reply to decembre56 from comment #45)
> This is a meta-bug to keep track of all the different Firebug gaps. So, can
> you please create a separate bug for this issue and mark it as blocker for
> this one?
>  

I do it and I hope i don't make a mistake ...
https://forum.userstyles.org/discussion/53223/firefoxs-developer-toolbar-readable-userstyles-name-for-css-selector-lines-like-firebug#latest

Comment 48

[u403777]

Firebug let me select code in the Inspector Area with my mouse cursor.

With Firefox's Developer Toolbar, this is not possible. There I need to right click at an element, select Edit HTML and then select code. This is annoying. Furthermore, I cannot select code which covers two or more elements.

Comment 49

[Sebastian Zartner [:sebo]]

(In reply to nebo from comment #48)
> Firebug let me select code in the Inspector Area with my mouse cursor.
> 
> With Firefox's Developer Toolbar, this is not possible. There I need to
> right click at an element, select Edit HTML and then select code. This is
> annoying. Furthermore, I cannot select code which covers two or more
> elements.

That's covered in bug 1343825.

Sebastian

Comment 50

[Mark Clements]

> Severity: normal → enhancement

Given that part of the justification for dropping Firebug support was that the built-in developer tools would provide all the functionality of this tool, any missing features are actually regression bugs, not enhancements.

I am a bit concerned if the attitude is to bat this missing functionality into the long-grass, now that users no longer have the option to continue using Firebug.

Personally, I have simply disabled updates and will continue to use Firebug on an old version of Firefox until the built-in tools are mature enough, but eventually that will cause me problems, I expect.

Can someone confirm why these outstanding features have been downgraded, as that severity change implies?

Comment 51

[Patrick Brosset <:pbro>]

(In reply to Mark Clements from comment #50)
> Can someone confirm why these outstanding features have been downgraded, as
> that severity change implies?
They have not been downgraded. The severity flag was changed to make it easier for us to extract lists of bugs from bugzilla.

We would like to be able to quickly differentiate things like existing features that are simply broken, from features that need to be implemented.
These Firebug gaps are just that: new features.

I agree that missing Firebug features are very important and we will try to continue working on them as time allows (you're very welcome to help by the way). But as new features, they need a different type of work than simpler bug fixing, and that's why we need to be able to filter them in a different list on bugzilla.