Last Comment Bug 991806 - (firebug-gaps) Firebug Gaps
(firebug-gaps)
: Firebug Gaps
Status: NEW
:
Product: Firefox
Classification: Client Software
Component: Developer Tools (show other bugs)
: 30 Branch
: All All
-- normal with 15 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: J. Ryan Stinnett [:jryans] (use ni?)
Mentors:
Depends on: 672733 704094 797876 815464 820878 821610 859045 859051 862855 884125 889571 895893 925269 963933 977128 987877 994559 1004511 1004678 1005825 1006508 1031194 1032855 1061823 1067318 1067323 1099234 1106336 1108695 1133849 1138243 1145669 1150498 1150499 1159078 firebug-commands 1165010 1173504 1178218 1179070 1219917 1220758 1226566 1226637 1226640 1227054 1231452 1247392 1257833 1267140 1267226 1267234 1267238 1269704 1270015 1270025 1277828 1279602 1280024 1284012 1302361 1302363 1312250 1316528 1323746 1324385 1334408 1335316 1335327 1336045 1336934 devtools/auto-completion 1338645 1340574 764958 859042 859058 892935 895880 895887 901250 909754 911209 921102 922221 930631 940950 962627 966468 966895 967493 972655 983600 985597 991810 992679 992947 993416 993445 994055 994555 994729 1004535 1007949 1017515 1024693 1038964 1050190 1064458 1095521 1096294 1108212 1150715 1152276 1154363 1158144 1159725 1164883 1167080 1168872 1184172 1201475 1211525 1243045 1259060 1267144 1312168 1320351 1323700
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-03 10:39 PDT by Jeff Griffiths (:canuckistani) (:⚡︎)
Modified: 2017-02-21 02:01 PST (History)
32 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Jeff Griffiths (:canuckistani) (:⚡︎) 2014-04-03 10:39:20 PDT
This is a tracking bug that should depend on any bugs related specifically to fixing gaps in functionality with Firebug.
Comment 1 User image Patrick Brosset <:pbro> (PTO, back on Feb 27th) 2014-04-10 01:40:33 PDT
See https://etherpad.mozilla.org/devtools-firebug-gaps-prio for a list of gaps.
Comment 2 User image Albert Scheiner [:alberts] 2014-04-10 02:53:09 PDT
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 User image Patrick Brosset <:pbro> (PTO, back on Feb 27th) 2014-04-10 02:54:19 PDT
(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 User image Patrick Brosset <:pbro> (PTO, back on Feb 27th) 2014-04-10 02:55:03 PDT
Removed bug 991662 from the dependencies, this is just a bug we need to fix, not a feature gap.
Comment 5 User image Joe Walker [:jwalker] (needinfo me or ping on irc) 2014-05-29 03:00:04 PDT
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 User image (Unavailable until Apr 3) [:bgrins] 2014-05-29 05:24:22 PDT
(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 User image Joe Walker [:jwalker] (needinfo me or ping on irc) 2014-05-29 05:56:22 PDT
(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 User image Tim Nguyen :ntim 2014-06-08 00:09:44 PDT
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 User image Jens 2016-03-10 03:00:38 PST
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 User image Sebastian Zartner [:sebo] 2016-03-10 05:37:52 PST
You're right. I've added it.

Sebastian
Comment 11 User image Jeff Griffiths (:canuckistani) (:⚡︎) 2016-03-10 17:22:42 PST
(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 User image Jens 2016-03-11 00:22:42 PST
(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 User image Bryan Clark (DevTools PM) [:clarkbw] 2016-03-11 14:06:13 PST
(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 User image Sebastian Zartner [:sebo] 2016-11-19 05:54:31 PST
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 User image Patrick Brosset <:pbro> (PTO, back on Feb 27th) 2016-11-21 03:04:16 PST
(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 User image Sebastian Zartner [:sebo] 2016-11-21 10:17:38 PST
(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 User image Patrick Brosset <:pbro> (PTO, back on Feb 27th) 2016-11-22 03:11:26 PST
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 User image Sebastian Zartner [:sebo] 2016-11-22 05:33:11 PST
(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 User image Sebastian Zartner [:sebo] 2016-11-23 02:09:06 PST
So far I got:

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

Sebastian
Comment 20 User image Sebastian Zartner [:sebo] 2016-11-24 14:28:24 PST
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 User image Sebastian Zartner [:sebo] 2016-11-24 14:29:48 PST
(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 User image Jim Merick 2016-12-07 02:14:20 PST
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 User image Tim Nguyen :ntim 2016-12-07 04:33:35 PST
(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 User image Albert Scheiner [:alberts] 2016-12-07 15:40:59 PST
(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 User image Tim Nguyen :ntim 2016-12-07 16:36:19 PST
(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 User image Sebastian Zartner [:sebo] 2016-12-07 17:50:43 PST
(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 User image Keith Ritt 2017-02-01 22:15:52 PST
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 User image Sebastian Zartner [:sebo] 2017-02-02 00:51:57 PST
(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 User image bombledmonk 2017-02-02 08:19:36 PST
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 User image Sebastian Zartner [:sebo] 2017-02-02 09:38:08 PST
(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 User image Arkadiusz Michalski (Spirit) 2017-02-02 11:26:23 PST
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 User image Arkadiusz Michalski (Spirit) 2017-02-06 09:37:08 PST
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 User image shahajip 2017-02-17 00:18:31 PST
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 User image Sebastian Zartner [:sebo] 2017-02-17 11:47:21 PST
(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 User image shahajip 2017-02-18 07:52:27 PST
@Julian Descottes , @Sebastian Zartner
Thanks.
Comment 36 User image alex 2017-02-20 23:53:10 PST
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 User image alex 2017-02-20 23:55:38 PST
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 User image Sebastian Zartner [:sebo] 2017-02-21 02:01:51 PST
(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

Note You need to log in before you can comment on or make changes to this bug.