867838 - Ability to minimize devtools toolbox when docked at bottom

Status: RESOLVED FIXED

(DevTools :: Framework, defect)

Description

[Heather Arthur [:harth]]

I find myself wanting to minimize the devtools down to just the tab bar (tools+command buttons) sometimes when I have them docked at the bottom.

A button to minimize/un-minimize is what I'd want.

Comment 1

[Girish Sharma [:Optimizer]]

@Joe, do we want this ? If yes, I can work on this.

Comment 2

[Joe Walker [:jwalker]]

Is this an ease-of-access thing?
What's the problem that it solves?

Comment 3

[Heather Arthur [:harth]]

Yeah, I don't know if anyone else wants this. I often want to get the devtools out of the way without closing them and losing context, and using the separator to move it down works, but it's a common action for me.

Comment 4

[Girish Sharma [:Optimizer]]

FWIW, I also want this, and for mostly the same reasons. You just need to get the Toolbox out of the view. and dragging via the splitter is very heavy (page + toolbox repaints) and slow.

Comment 5

[Joe Walker [:jwalker]]

What if we were to remember the state for a page while the browser was open, (or maybe even longer)?
I don't suppose it would be too hard for each tool to have a exportStateToJson function.

Comment 6

[Girish Sharma [:Optimizer]]

But still some things like, paused debugger cannot be maintained. And I am sure that if netmonitor were to store states in memory (or even on file) I would directly mean saving the whole page (plus the formatting it to json) on to memory ( or file)

And then what will be the behavior :
Lets say I have Debugger, inspector and netmonitor open and everyting is being used. Debugger has breakpoints, I am inspecting a node, and netmonitor has all the network request information. If I close the toolbox, and open it again, should all three tools start and the state be restored ?
This seems a bit heavy to me, and unwanted too.

Comment 7

[Joe Walker [:jwalker]]

(In reply to Girish Sharma [:Optimizer] from comment #6)
> But still some things like, paused debugger cannot be maintained. And I am
> sure that if netmonitor were to store states in memory (or even on file) I
> would directly mean saving the whole page (plus the formatting it to json)
> on to memory ( or file)
> 
> And then what will be the behavior :
> Lets say I have Debugger, inspector and netmonitor open and everyting is
> being used. Debugger has breakpoints, I am inspecting a node, and netmonitor
> has all the network request information. If I close the toolbox, and open it
> again, should all three tools start and the state be restored ?
> This seems a bit heavy to me, and unwanted too.

There's no reason why we need to store everything, we can be selective. That said, I'd love for the debugger to remember my breakpoints like chrome does.

Comment 8

[Girish Sharma [:Optimizer]]

(In reply to Joe Walker [:jwalker] from comment #7)
> There's no reason why we need to store everything, we can be selective. That
> said, I'd love for the debugger to remember my breakpoints like chrome does.

This can actually be an option in the Options panel.

[✓]Remember breakpoints until the page is loaded.

and something similar can be done for some other selective things that we want to be persisted from other tools.

That being said, these might not be equal to have the tools running, but out of the view for a short while. Even though this can be achieved by docking out the tools out of the way, that is not an "easy to bring back the tools into view" choice.

That being said, I also think that this feature has a low usage. If some other people want this, then we can think of implementing this.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Joe Walker [:jwalker] from comment #7)
> That said, I'd love for the debugger to remember my breakpoints like chrome does.

Can you elaborate a bit on your use case (perhaps in a new bug)? I remember I had it in the original plan, but IIRC Victor convinced me (or I convinced myself) that this wasn't actually needed in practice.

Comment 10

[Victor Porof [:vporof][:vp]]

(In reply to Panos Astithas [:past] from comment #9)
> (In reply to Joe Walker [:jwalker] from comment #7)
> > That said, I'd love for the debugger to remember my breakpoints like chrome does.
> 

1). Handling source text changes is hard.
2). I do agree that in some usage subsets this would be nice (reloading a FF OS app in the simulator currently requires us to restart the debugger, because sources never change), however 1).

Comment 11

[Girish Sharma [:Optimizer]]

(In reply to Victor Porof [:vp] from comment #10)
> (In reply to Panos Astithas [:past] from comment #9)
> > (In reply to Joe Walker [:jwalker] from comment #7)
> > > That said, I'd love for the debugger to remember my breakpoints like chrome does.
> > 
> 
> 1). Handling source text changes is hard.
> 2). I do agree that in some usage subsets this would be nice (reloading a FF
> OS app in the simulator currently requires us to restart the debugger,
> because sources never change), however 1).

How much memory intensive it would be to have a map of source vs breakpoint list ? for a page until the url is changed or tab is closed.

Comment 12

[Joe Walker [:jwalker]]

(In reply to Victor Porof [:vp] from comment #10)
> (In reply to Panos Astithas [:past] from comment #9)
> > (In reply to Joe Walker [:jwalker] from comment #7)
> > > That said, I'd love for the debugger to remember my breakpoints like chrome does.
> > 
> 
> 1). Handling source text changes is hard.

I'm not sure it's that hard, or that it's required. Sure chrome is annoying when it puts the breakpoints back in the wrong place after you edited the source and refreshed, but for me I'd still rather it be there than not.

And that said, putting it back in the right place is just a matter of importing a diff/match/patch library like [1] and saying: "Previously we were at line X that looked like this, where are we now?"

This has the added approach that a re-write level change would leave us dropping the breakpoint, which is probably what we want anyway.

[1] http://code.google.com/p/google-diff-match-patch/source/browse/trunk/javascript/diff_match_patch_uncompressed.js

Comment 13

[Girish Sharma [:Optimizer]]

FWIW, IE allows to minimize the devtools into one single tabbar at the bottom of the browser, all be it by just shifing the whole toolbox outside of the browser.

Comment 14

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

(In reply to Girish Sharma [:Optimizer] from comment #13)
> FWIW, IE allows to minimize the devtools into one single tabbar at the
> bottom of the browser, all be it by just shifing the whole toolbox outside
> of the browser.

So does Firebug.

It would be a simple case of adding the button, collapsing the toolbox content when the button is clicked and expanding it again if the button or a tab is clicked. This way everything would be perfectly preserved.

Comment 15

[Joe Walker [:jwalker]]

(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #14)
> (In reply to Girish Sharma [:Optimizer] from comment #13)
> > FWIW, IE allows to minimize the devtools into one single tabbar at the
> > bottom of the browser, all be it by just shifing the whole toolbox outside
> > of the browser.
> 
> So does Firebug.
> 
> It would be a simple case of adding the button, collapsing the toolbox
> content when the button is clicked and expanding it again if the button or a
> tab is clicked. This way everything would be perfectly preserved.

This was the cause of a ton of confusion for Firebug though. To this day I still get it wrong when closing Firebug.

If we do do something like this then we need to have the tools still visible at least.

Comment 16

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

We would still have the tabs visible, just not the tool content.

Comment 17

[Girish Sharma [:Optimizer]]

Yup, and we can have the blue-ish glow on the active tab, to indicate that its still active. Moreover, when (if?) toolbox tabs and developer toolbar gets combined, this will make even more sense.

Comment 18

[Girish Sharma [:Optimizer]]

Few thoughts:
1) The minimize button should only be present in the BOTTOM host.
2) translateY vs toolbox.height ?
3) Minimize button changes to restore button when minimized ?
4) Highlighter should still be visible on screen when the toolbox is minimized with inspector selected ?
5) In continuation with the above one.. should any tool be still selected when toolbox minimized ?

Comment 19

[Girish Sharma [:Optimizer]]

Also adding to the list .. 
6) If debugger is paused, should it resume ?

Comment 20

[Patrick Brosset <:pbro>]

2 ideas on user voices, amounting to a total of 30 votes:

https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5984862-button-for-minimising-the-toolbox-to-just-the-butt
https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/6729673-offer-a-minified-toolbar-mode

I've been spending a couple of hours this morning working on this and have something almost ready. Will post a patch soon (I'm just not sure about the button position and image).

Comment 21

[Patrick Brosset <:pbro>]

Attachment: Bug_867838_-_Add_the_possibility_to_minimize_the_b.diff

WIP, misses tests.

Comment 22

[Patrick Brosset <:pbro>]

Attachment: MozReview Request: Bug 867838 - Add the possibility to minimize the bottom-hosted toolbox; r=jryans

Bug 867838 - Add the possibility to minimize the bottom-hosted toolbox

Comment 23

[Patrick Brosset <:pbro>]

Attachment: MozReview Request: Bug 867838 - Minor eslint code cleanup in toolbox-host.js; r=jryans

Bug 867838 - Minor eslint code cleanup in toolbox-host.js

Comment 24

[Patrick Brosset <:pbro>]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5523323df213

Comment 25

[Patrick Brosset <:pbro>]

Ah, I forgot one use case:
- minimize the host
- resize it using the splitter
as a user, there's an expectation that resizing while minimized will put it back in its maximized state. And that clicking the button again would minimize it again.
But that is not what happens, the toolbox gets resized but is still partly hidden, minimized.
The 2 patches I submitted are still reviewable I think. I will add a 3rd patch to take care of this later.

Comment 26

[Brian Grinstead [:bgrins]]

(In reply to Patrick Brosset [:pbrosset] [:patrick] [:pbro] from comment #22)
> Created attachment 8614665 [details]
> MozReview Request: Bug 867838 - Add the possibility to minimize the
> bottom-hosted toolbox
> 
> Bug 867838 - Add the possibility to minimize the bottom-hosted toolbox

Can you add a screenshot of this?  I pulled down the patch but wasn't seeing the icon (seems like maybe it didn't get added to the patch).  I like that clicking on a tool restores the size and it works well (expect the issue you mention in Comment 25), but I'm worried about how many things are visible by default in the toolbar tab strip.

Now that the frames button that got turned on by default we would have the following things visible on a clean profile:

Select Frame|Split Console|Responsive Mode|Options|Minimize/Maximize|Side Docking|Window Docking|Close

I don't have any great ideas about how to organize this better, but I think we should at least request a UX review for this.

Comment 27

[Patrick Brosset <:pbro>]

(In reply to Brian Grinstead [:bgrins] from comment #26)
> (In reply to Patrick Brosset [:pbrosset] [:patrick] [:pbro] from comment #22)
> > Created attachment 8614665 [details]
> > MozReview Request: Bug 867838 - Add the possibility to minimize the
> > bottom-hosted toolbox
> > 
> > Bug 867838 - Add the possibility to minimize the bottom-hosted toolbox
> 
> Can you add a screenshot of this?  I pulled down the patch but wasn't seeing
> the icon (seems like maybe it didn't get added to the patch).
Weird, I did add the images to the patch.
Here's a gif of the feature in action: https://dl.dropboxusercontent.com/u/714210/toolbox-minimize.gif
> I like that
> clicking on a tool restores the size and it works well (expect the issue you
> mention in Comment 25),
Yeah, I need to get this fixed.
>but I'm worried about how many things are visible by
> default in the toolbar tab strip.
> 
> Now that the frames button that got turned on by default we would have the
> following things visible on a clean profile:
> 
> Select Frame|Split Console|Responsive Mode|Options|Minimize/Maximize|Side
> Docking|Window Docking|Close
> 
> I don't have any great ideas about how to organize this better, but I think
> we should at least request a UX review for this.
I agree for the UX review. I don't have ideas either, I think anything else we choose is going to make this feature less discoverable. Maybe it doesn't need to be though, this could remain sort of a power-user-only feature only accessible via a keyboard shortcut (in any case, adding a keyboard shortcut would be a good idea). Or we could have a long click on the dock button, or dbl-click on the toolbar, ...
Note, however, that the button only appears when the toolbox is docked at the bottom, which is when the toolbox is the wider. Maybe Jeff can provide data about screen resolutions here since we now have telemetry for this.

Comment 28

[Patrick Brosset <:pbro>]

Attachment: Animated GIF of the feature in action

Hey Stephen, it'd be great to have a ui/ux review on this new toolbox minimize feature I'm working on.
One of the main discussions is what should trigger this: a button in the toolbar (as the screenshot demonstrates), a keyboard shortcut, some other means.
I guess we want this to be discoverable to users, but that's the same thing for everything we add, and if we put everything in the UI, we're going to end up with hundreds of buttons in no time.

Comment 29

[Brian Grinstead [:bgrins]]

(In reply to Patrick Brosset [:pbrosset] [:patrick] [:pbro] from comment #27)
> (In reply to Brian Grinstead [:bgrins] from comment #26)
> >but I'm worried about how many things are visible by
> > default in the toolbar tab strip.
> > 
> > Now that the frames button that got turned on by default we would have the
> > following things visible on a clean profile:
> > 
> > Select Frame|Split Console|Responsive Mode|Options|Minimize/Maximize|Side
> > Docking|Window Docking|Close
> > 
> > I don't have any great ideas about how to organize this better, but I think
> > we should at least request a UX review for this.
> I agree for the UX review. I don't have ideas either, I think anything else
> we choose is going to make this feature less discoverable. Maybe it doesn't
> need to be though, this could remain sort of a power-user-only feature only
> accessible via a keyboard shortcut (in any case, adding a keyboard shortcut
> would be a good idea). Or we could have a long click on the dock button, or
> dbl-click on the toolbar, ...
> Note, however, that the button only appears when the toolbox is docked at
> the bottom, which is when the toolbox is the wider. Maybe Jeff can provide
> data about screen resolutions here since we now have telemetry for this.

ni? Jeff about any possible data we have about the toolbox size / screen resolution people are using

Comment 30

[Tim Nguyen :ntim]

Comment on attachment 8615520 [details]
Animated GIF of the feature in action

I have just tried this on my machine. This is a quite neat feature, although I do have some suggestions :
- This minimized mode could probably be confusing if the developer toolbar is on as well. The user might attempt to click "Toggle Tools" in the dev toolbar to unminimize the toolbox. Maybe there could be a change in behaviour here, or maybe we could combine both the toolbox and the dev toolbar in the future (somewhat like this : http://shorlander.dropmark.com/85185/1111798 )

- Just for polishing, the bottom border of the toolbox tabs looks quite ugly in combination with the developer toolbar top border, it creates a double border between those 2 toolbars

- Polishing as well, I would probably add a short transition (0.2s?) when toggling the minimized mode

Comment 31

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

(In reply to Brian Grinstead [:bgrins] from comment #29)
> (In reply to Patrick Brosset [:pbrosset] [:patrick] [:pbro] from comment #27)
> > (In reply to Brian Grinstead [:bgrins] from comment #26)
> > >but I'm worried about how many things are visible by
> > > default in the toolbar tab strip.
> > > 
> > > Now that the frames button that got turned on by default we would have the
> > > following things visible on a clean profile:
> > > 
> > > Select Frame|Split Console|Responsive Mode|Options|Minimize/Maximize|Side
> > > Docking|Window Docking|Close
> > > 
> > > I don't have any great ideas about how to organize this better, but I think
> > > we should at least request a UX review for this.
> > I agree for the UX review. I don't have ideas either, I think anything else
> > we choose is going to make this feature less discoverable. Maybe it doesn't
> > need to be though, this could remain sort of a power-user-only feature only
> > accessible via a keyboard shortcut (in any case, adding a keyboard shortcut
> > would be a good idea). Or we could have a long click on the dock button, or
> > dbl-click on the toolbar, ...
> > Note, however, that the button only appears when the toolbox is docked at
> > the bottom, which is when the toolbox is the wider. Maybe Jeff can provide
> > data about screen resolutions here since we now have telemetry for this.
> 
> ni? Jeff about any possible data we have about the toolbox size / screen
> resolution people are using

No data on toolbox size - I posted this screen rez spreadsheet / graph a couple of days ago:

https://docs.google.com/spreadsheets/d/1pp4EO1o0wpOr2webx-TmzNhl-yMn75pXc_Nw-zmFPaQ/edit#gid=2119694026

tl;dr: most screens are either 1920x1080 or 1366x768. There's a sizeable chunk in the other category - I'm not surprised by that because there are so many variants of laptops and weird LCD monitors out there.

Significantly - 1366x768 is also the most popular resolution on the internet, and the native resolution of the 11" MBAir ( and many PC Ultrabooks ). We should care deeply about how our tools look at this resolution.

Comment 32

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

(In reply to Tim Nguyen [:ntim] from comment #30)
...
> - This minimized mode could probably be confusing if the developer toolbar
> is on as well. The user might attempt to click "Toggle Tools" in the dev
> toolbar to unminimize the toolbox. Maybe there could be a change in
> behaviour here, or maybe we could combine both the toolbox and the dev
> toolbar in the future (somewhat like this :
> http://shorlander.dropmark.com/85185/1111798 )

We've long thought about merging gcli into the console - if we do that then the only thing in the developer toolbar is the toogle button and the error count.

I like shorlander's mockup, but would prefer to step back a bit and consider more thoroughly:

 - for a minimized toolbox, what should we show? What tasks is the user trying to accomplish and how do we help?
 - for the developer toolbar, same questions.

If we go with a unified experience, the key wrangling points are - what do we expose by default and how deep do we go with customization.

Comment 33

[Patrick Brosset <:pbro>]

(In reply to Jeff Griffiths (:canuckistani) from comment #32)
> We've long thought about merging gcli into the console - if we do that then
> the only thing in the developer toolbar is the toogle button and the error
> count.
> 
> I like shorlander's mockup, but would prefer to step back a bit and consider
> more thoroughly:
> 
>  - for a minimized toolbox, what should we show? What tasks is the user
> trying to accomplish and how do we help?
My understanding of the user voice ideas, and other various comments I've read about this is that the primary use case is to get the toolbox out of the way, to give more space to the page itself.
But do this in the way that the toolbox remains active (maybe I want the track network requests, maybe I'm recording a per profile, maybe I just don't want to wait for the toolbox to init again so I minimize it instead of closing it).
So it's not so much a task the user is trying to accomplish *with* the toolbox, rather than just getting rid of it.
However, the toolbox, once minimized, can still serve a purpose. One of the other comments I've seen is that the js error count should appear in the debugger tab for example. As you said, that's one of the things the developer toolbar does, and that the minimized toolbox could do instead.
Last, the minimized toolbox can server as handy toolbar for tools that don't require the toolbox: the eyedropper, the 3d view, the screenshot button, the responsive view. In a way, it becomes almost like the "design mode" toolbar we've been discussing some time ago.

Comment 34

[Patrick Brosset <:pbro>]

(In reply to Tim Nguyen [:ntim] from comment #30)
> - Just for polishing, the bottom border of the toolbox tabs looks quite ugly
> in combination with the developer toolbar top border, it creates a double
> border between those 2 toolbars
> 
> - Polishing as well, I would probably add a short transition (0.2s?) when
> toggling the minimized mode
Both good points, thanks, I'll fix these.

Comment 35

[Patrick Brosset <:pbro>]

Comment on attachment 8614665 [details]
MozReview Request: Bug 867838 - Add the possibility to minimize the bottom-hosted toolbox; r=jryans

Bug 867838 - Add the possibility to minimize the bottom-hosted toolbox; r=jryans

Comment 36

[Patrick Brosset <:pbro>]

Comment on attachment 8614666 [details]
MozReview Request: Bug 867838 - Minor eslint code cleanup in toolbox-host.js; r=jryans

Bug 867838 - Minor eslint code cleanup in toolbox-host.js; r=jryans

Comment 37

[Patrick Brosset <:pbro>]

The last 2 commits fix the following:
- in minimized mode, the toolbox can't be resized, I couldn't find a good way to support this nicely and I don't think it's a primary use case to support, so let's delay this to a follow-up if needed,
- there is now a transition when the toolbox minimizes/maximizes
- moved some code around to make things cleaner
- there's no double borders now when minimizing with the gcli command bar below.

Comment 38

[Patrick Brosset <:pbro>]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=835de8452301

Comment 39

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Comment on attachment 8614666 [details]
MozReview Request: Bug 867838 - Minor eslint code cleanup in toolbox-host.js; r=jryans

https://reviewboard.mozilla.org/r/10005/#review9113

Ship It!

::: browser/devtools/framework/toolbox-hosts.js:4
(Diff revision 2)
> +/* globals DOMHelpers, Services */

Ah, I wasn't sure if we were doing this global thing or not.  I'll start adding them in my own code too! :)

Comment 40

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Comment on attachment 8614665 [details]
MozReview Request: Bug 867838 - Add the possibility to minimize the bottom-hosted toolbox; r=jryans

https://reviewboard.mozilla.org/r/10003/#review9137

Overall, I think it's great!  It looks nice, and I think will be really useful.

But, I am also worried about the extra command button taking up space.  However, I don't have any great ideas, other than possibly putting these modes in some kind of menu, like Chrome does if you hold down the mouse button on the switching button.  

I'll leave it you, UX, and others here to decide if this must be resolved before landing.

::: browser/devtools/framework/toolbox.js:697
(Diff revision 2)
> +                                  .getBoxQuads({box: "content"})[0]

`getBoxQuads` is disabled in Release builds currently (see bug 1107559).

It seems bad to use here until we know it's on everywhere.

::: browser/devtools/framework/toolbox.js:1214
(Diff revision 2)
> +    this.emit("will-select", id);

Is this used anywhere?

::: browser/devtools/framework/toolbox.js:1185
(Diff revision 2)
> +    this.emit("may-select", id);

Nit: possibly `before-select`?  Up to you.

Comment 41

[Brian Grinstead [:bgrins]]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #40)
> ::: browser/devtools/framework/toolbox.js:697
> (Diff revision 2)
> > +                                  .getBoxQuads({box: "content"})[0]
> 
> `getBoxQuads` is disabled in Release builds currently (see bug 1107559).
> 
> It seems bad to use here until we know it's on everywhere.

What?  We are using this for the highlighter via this.layoutHelpers.getAdjustedQuads and have been for quite a while - are you sure this is disabled?

Comment 42

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Brian Grinstead [:bgrins] from comment #41)
> (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #40)
> > ::: browser/devtools/framework/toolbox.js:697
> > (Diff revision 2)
> > > +                                  .getBoxQuads({box: "content"})[0]
> > 
> > `getBoxQuads` is disabled in Release builds currently (see bug 1107559).
> > 
> > It seems bad to use here until we know it's on everywhere.
> 
> What?  We are using this for the highlighter via
> this.layoutHelpers.getAdjustedQuads and have been for quite a while - are
> you sure this is disabled?

Ah, I was mistaken.  It's disabled in Release for web content, but enabled everywhere for chrome-scope.  Nothing to worry about here then.

Comment 43

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

(In reply to Patrick Brosset [:pbrosset] [:patrick] [:pbro] from comment #28)
...
> One of the main discussions is what should trigger this: a button in the
> toolbar (as the screenshot demonstrates), a keyboard shortcut, some other
> means.

I checked out the try build and I like it a lot as-is. I thin it needs a keyboard shortcut as well as the button though. The button gives us discover-ability, and the kb shortcut ( displayed on hover of the button in a tooltip? ) gives the user efficiency.

> I guess we want this to be discoverable to users, but that's the same thing
> for everything we add, and if we put everything in the UI, we're going to
> end up with hundreds of buttons in no time.

For me anything that controls the toolbox itself should probably be visually discoverable.

The other question I had was - what should work without having to pop up the whole toolbox? Most of the toolbox buttons work, and rulers should work too once that feature is done.

Comment 44

[Patrick Brosset <:pbro>]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #42)
> (In reply to Brian Grinstead [:bgrins] from comment #41)
> > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #40)
> > > ::: browser/devtools/framework/toolbox.js:697
> > > (Diff revision 2)
> > > > +                                  .getBoxQuads({box: "content"})[0]
> > > 
> > > `getBoxQuads` is disabled in Release builds currently (see bug 1107559).
> > > 
> > > It seems bad to use here until we know it's on everywhere.
> > 
> > What?  We are using this for the highlighter via
> > this.layoutHelpers.getAdjustedQuads and have been for quite a while - are
> > you sure this is disabled?
> 
> Ah, I was mistaken.  It's disabled in Release for web content, but enabled
> everywhere for chrome-scope.  Nothing to worry about here then.
Yep, you got me very worried for a second there :)
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsINode.cpp#2750

Comment 45

[Patrick Brosset <:pbro>]

I'm going to land this as-is, and file a bug to add a keyboard shortcut.
We have about 3 weeks before the next uplift, so in that time we can:
- either agree (having Stephen's input would be great) on the UI for this make it happen in a follow-up bug if needed,
- or disagree in which case I can simply hide the new button from the UI before the next uplift to avoid shipping something in the UI that won't stay.
In either case we have time to do this, and the rest of the code won't have to be changed, so it's ok to land this now.

Comment 46

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/da39e8190236
https://hg.mozilla.org/integration/fx-team/rev/67db850294e4

Comment 47

[Patrick Brosset <:pbro>]

Thanks Ryan for the review btw, I've removed the event I added which wasn't used and renamed the other one to before-select, I agree that it sounds better.

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/da39e8190236
https://hg.mozilla.org/mozilla-central/rev/67db850294e4

Comment 49

[Stephen Horlander [:shorlander]]

Comment on attachment 8615520 [details]
Animated GIF of the feature in action

Looks like this was hidden in bug 117746 and I don't have time to review it ATM.

Comment 50

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

> Looks like this was hidden in bug 117746 and I don't have time to review it
> ATM.
Bug 1177463 is the complete bug number.

Comment 51

[Patrick Brosset <:pbro>]

Putting this on devtools UX's radar because we decided hiding this feature until we got a UX review first.