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 14 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 884125 889571 895893 925269 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 1243045 1257833 1267140 1267226 1267234 1267238 1269704 1270015 1270025 1277828 1279602 1280024 1284012 1302361 1302363 1316528 1323700 1323746 1324385 764958 859042 859058 892935 895880 895887 901250 909754 911209 921102 922221 930631 940950 962627 963933 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 1259060 1267144 1312168
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-03 10:39 PDT by Jeff Griffiths (:canuckistani) (:⚡︎)
Modified: 2017-01-16 05:05 PST (History)
27 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> 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> 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> 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 Brian Grinstead [: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> 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> 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

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