Status

()

Firefox
Developer Tools
P3
normal
3 years ago
a month ago

People

(Reporter: canuckistani, Unassigned)

Tracking

(Depends on: 79 bugs, {meta})

30 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

This is a tracking bug that should depend on any bugs related specifically to fixing gaps in functionality with Firebug.
Alias: firebug-gaps
Depends on: 991810
Depends on: 983600
See https://etherpad.mozilla.org/devtools-firebug-gaps-prio for a list of gaps.
Depends on: 991662
Depends on: 940950
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 )
(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
Removed bug 991662 from the dependencies, this is just a bug we need to fix, not a feature gap.
No longer depends on: 991662
Depends on: 994729
No longer depends on: 993459
Depends on: 1004535
Depends on: 1004678

Updated

3 years ago
Depends on: 1006508
Depends on: 972655
Depends on: 1007949
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.

Updated

3 years ago
Depends on: 1017515
(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.
(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

3 years ago
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;
}
Depends on: 1024693
Depends on: 797876
Depends on: 1032855
Depends on: 909754
Depends on: 1038964
Depends on: 859058
Depends on: 1050190

Updated

3 years ago
Depends on: 992679
Depends on: 1067323
Depends on: 1067318

Updated

3 years ago
Depends on: 1095521
Depends on: 1031194
Depends on: 1031192
Depends on: 1099234

Updated

3 years ago
Depends on: 1108212
Depends on: 930631

Updated

3 years ago
Depends on: 1108695
Depends on: 1005825
Depends on: 1133849
Depends on: 1096294
Depends on: 962627
Depends on: 1138243
Depends on: 1145669
Depends on: 901250
Depends on: 815464
Depends on: 921102
Depends on: 1152276
Depends on: 1154363
Depends on: 1150715

Updated

2 years ago
Depends on: 1158144
Depends on: 764958

Updated

2 years ago
Depends on: 1164157

Updated

2 years ago
Depends on: 1164883

Updated

2 years ago
Depends on: 1164882

Updated

2 years ago
No longer depends on: 1164882

Updated

2 years ago
Depends on: 1165010
Blocks: 1167080
Blocks: 1168872
No longer blocks: 1167080
Depends on: 1167080
Depends on: 1159725
Depends on: 922221
Depends on: 884125
Depends on: 1173504
Depends on: 1179070

Updated

2 years ago
Depends on: 859042
Depends on: 1064458
Depends on: 1201475
Depends on: 1159078
Depends on: 1184172
No longer blocks: 1168872
Depends on: 1168872

Updated

2 years ago
Depends on: 1226637, 1226640
No longer depends on: 1031192
Depends on: 1233321

Updated

2 years ago
No longer depends on: 1233321

Updated

2 years ago
Depends on: 1226566
Depends on: 859045

Comment 9

a year ago
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.
You're right. I've added it.

Sebastian
Depends on: 1004511
(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.
Flags: needinfo?(clarkbw)

Comment 12

a year ago
(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.
(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.
Flags: needinfo?(clarkbw)
See Also: → bug 1256749
Depends on: 1257833
Depends on: 1259060
Depends on: 1227054
Depends on: 1211525
Depends on: 672733
Depends on: 1267140
Depends on: 1267144
Depends on: 821610
Depends on: 895893
OS: Mac OS X → All
Hardware: x86 → All
Depends on: 1267226
Depends on: 1267234
Depends on: 1267238
See Also: → bug 1267303
Depends on: 1269704
Depends on: 1270015
Depends on: 1270025
Depends on: 967493
Depends on: 1277828
Depends on: 1280024

Updated

a year ago
Depends on: 1284012

Updated

10 months ago
Depends on: 820878

Updated

10 months ago
Depends on: 1178218

Updated

10 months ago
Depends on: 1302361

Updated

10 months ago
Depends on: 1302363
Depends on: 1300934
Depends on: 925269
No longer depends on: 1300934
Depends on: 1316528
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
Flags: needinfo?(pbrosset)
Depends on: 987877
Depends on: 1061823
Depends on: 1150498
Depends on: 1150499
(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).
Flags: needinfo?(pbrosset)
(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
Depends on: 1312168
Depends on: 1279602
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.
(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
So far I got:

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

Sebastian
Depends on: 1106336
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
(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

Updated

7 months ago
Depends on: 1243045
Depends on: 963933

Comment 22

7 months ago
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

7 months ago
(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.
(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

7 months ago
(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).
(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

Updated

6 months ago
Depends on: 1323700

Updated

6 months ago
Depends on: 1323746
Depends on: 1324385

Updated

6 months ago
Depends on: 1219917
Depends on: 1231452
Depends on: 1220758
Depends on: 889571
Depends on: 1334408
Depends on: 859051
Depends on: 1335316
Depends on: 1335327
Depends on: 1247392

Comment 27

5 months ago
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.
(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
Depends on: 1312250

Comment 29

5 months ago
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.
(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
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.

Updated

5 months ago
Depends on: 1336045
Depends on: 1336934
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.
Depends on: 1320351
Depends on: 1337918
Depends on: 1338645

Comment 33

4 months ago
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)
Depends on: 1340574
(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

4 months ago
@Julian Descottes , @Sebastian Zartner
Thanks.

Comment 36

4 months ago
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

4 months ago
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...
Depends on: 862855
(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

Updated

4 months ago
Depends on: 1166963

Comment 39

4 months ago
No choice for the css font-weight
(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

4 months ago
(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.
Depends on: 1343825

Comment 42

4 months ago
I really miss the vertically splitted console panel with multiline edit area. It was better to write code that stayed there after running it.
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

4 months ago
Something cool on firebug is when you add a new rule, it's sorted in Alphabetical order.
I think it's more effecient.
Depends on: 1345983
Depends on: 1337701
Blocks: 1344523
Depends on: 1351982
Depends on: 1354446

Updated

2 months ago
Depends on: 1356870
Depends on: 1358383
Depends on: 1267235

Comment 45

2 months ago
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) ?
(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

Updated

2 months ago
Keywords: meta
Priority: -- → P3

Comment 47

2 months ago
(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
Depends on: 1360868
Depends on: 1362030
Depends on: 1362031
Depends on: 1362035
You need to log in before you can comment on or make changes to this bug.