1245654 - Ctrl + Shift + C no longer toggles the DOM inspector in Firefox Dev Edition

Status: VERIFIED FIXED

(DevTools :: Inspector, defect)

Description

[mitchmadhouse]

What did you do?
================
1. Go to a web page
2. Press Ctrl + Shift + C to select an element on the page

What happened?
==============
The developer inspector window opens, but unable to inspect elements.

What should have happened?
==========================
Inspector is toggled on so that elements can be selected on the page.

Is there anything else we should know?
======================================
I have downloaded regular Firefox in the meantime, and the shortcut works there.

Comment 1

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

I guess this is expected given bug 1213680, right :pbro?

We may see many others surprised by the change.

Comment 2

[mitchmadhouse]

Commented on the closed bug thread. I don't understand why you would remove (probably) one of the most used dev shortcuts in favour of appeasing one person's father who found it confusing. That's kind of mind boggling, and enough to make me stop using Firefox. Ctrl + Shift + C has been inspect element for some time, and F12 is the shortcut to simply open the inspector without highlighting. 

Removing the shortcut to highlight elements on the page doesn't seem like a usability improvement to me.

Comment 3

[Kai Strecker [:kstrecker]]

Ctrl + Shift + C is the most used shortcut when doing some frontend developing. Removing this shortcut destroys the whole workflow.
Clicking on the "element selection" button requires that much more time, that is slows down the workflow and thus it makes no fun any more to use the Firefox devtools.
I am also thinking about using an other web browser than Firefox, until the Ctrl + Shift + C shortcut gets added again.

I really hope, that the shortcut gets added again.

Comment 5

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

Another report:

https://www.reddit.com/r/firefox/comments/43wv5u/ctrlshiftc_no_longer_working_properly/

Comment 6

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

Pinging others involved in the original change to make sure everyone's aware of the reports.

Comment 7

[Ronan Jouchet]

(In reply to Kai Strecker [:kstrecker] from comment #3)
> Ctrl + Shift + C is the most used shortcut when doing some frontend
> developing. Removing this shortcut destroys the whole workflow.
> Clicking on the "element selection" button requires that much more time,
> that is slows down the workflow and thus it makes no fun any more to use the
> Firefox devtools.
> I am also thinking about using an other web browser than Firefox, until the
> Ctrl + Shift + C shortcut gets added again.
> 
> I really hope, that the shortcut gets added again.

Same here, "I really hope that the shortcut gets added again". This "fix" is changing existing behavior that:
 - Helps efficiency.
 - Has been here for ages (since Firebug).
 - Behaves the same in Chrome.

Comment 8

[mitchmadhouse]

Thanks J. Ryan

Comment 9

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

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #6)
> Pinging others involved in the original change to make sure everyone's aware
> of the reports.

Thanks!

Comment 10

[Brian Grinstead [:bgrins]]

I agree with Comment 7 and think the change should be reverted

Comment 11

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

(In reply to Brian Grinstead [:bgrins] from comment #10)
> I agree with Comment 7 and think the change should be reverted

Me too.

Comment 12

[Patrick Brosset <:pbro>]

Sorry for the radio silence on this bug in the past weeks. It's on my TODO list of things to get to in the 47 timeframe. Hopping to get to it tomorrow.

Comment 13

[Patrick Brosset <:pbro>]

My plan so far:

- make ctrl+shift+C engage the element picker mode
- do not focus the browser window when that happens
  - this was the original issue reported in bug 1213680, that the devtools windows would briefly be shown, then disappear in the background behind the browser window (in docked mode)
  - and this would make it consistent with what chrome does

We have to be aware of one limitation though (and chrome has the same): if the inspector is already open and you press that shortcut then, then the browser window isn't going to be focused.
This was discussed in bug 1213680 comment 13. Again, Chrome does this too, so having the same behavior would, at least, help users feel familiar.
It is a problem only in windowed mode when the devtools windows covers the browser window I guess. If you're working in docked mode, nothing's going to change. And if you're working in windowed mode but with the 2 windows side by side, then it's not a problem either.

So overall, it should be so much of an issue.

Comment 14

[Patrick Brosset <:pbro>]

(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #13)
>   - this was the original issue reported in bug 1213680, that the devtools
> windows would briefly be shown, then disappear in the background behind the
> browser window (in docked mode)
I meant to say *non-docked* mode (separate window)

Comment 15

[Patrick Brosset <:pbro>]

Attachment: MozReview Request: Bug 1245654 - Make the inspector shortcut start the pick mode again; r=bgrins

Review commit: https://reviewboard.mozilla.org/r/35441/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/35441/

Comment 16

[Brian Grinstead [:bgrins]]

Comment on attachment 8720742 [details]
MozReview Request: Bug 1245654 - Make the inspector shortcut start the pick mode again; r=bgrins

https://reviewboard.mozilla.org/r/35441/#review32119

Thanks!

Comment 17

[Brian Grinstead [:bgrins]]

Try push:  https://treeherder.mozilla.org/#/jobs?repo=try&revision=66e12b6eae43

Comment 18

[Patrick Brosset <:pbro>]

Thanks Brian.
I had already pushed to try in fact, just not published the URL here yet because I was expecting test failures. 
I will fix the failing test and land the change.

Comment 19

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

[Tracking Requested - why for this release]: Ensure this gets to 46.

Comment 20

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #6)
> Pinging others involved in the original change to make sure everyone's aware
> of the reports.

Thanks!

Comment 21

[Patrick Brosset <:pbro>]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=bb566f197e4d&group_state=expanded

Comment 22

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/f9e4a56281d8

Comment 23

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f9e4a56281d8

Comment 24

[Patrick Brosset <:pbro>]

Attachment: pick-element-shortcut.diff

This is the patch that landed on fx-team and m-c (On top of the R+'d patch, it only contains a few test fixes that I had missed the first time around).

Comment 25

[Patrick Brosset <:pbro>]

Comment on attachment 8721285 [details] [diff] [review]
pick-element-shortcut.diff

Approval Request Comment
[Feature/regressing bug #]: bug 1213680
[User impact if declined]: If declined, the ctrl+shift+C shortcut will only open the inspector, not engage the "select element from the page" mode. This shortcut was changed in bug 1213680 but users requested that we add that functionality back. This shortcut is used a lot to pick elements from the page and many users' workflows depend on it.
[Describe test coverage new/current, TreeHerder]: 2 mochitests cover this feature.
[Risks and why]: This is basically reverting to an earlier behavior, so there is very little risk
[String/UUID change made/needed]: none

Comment 27

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hello, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!

Comment 28

[Ronan Jouchet]

(In reply to Ritu Kothari (:ritu) from comment #27)
> Hello, could you please verify this issue is fixed as expected on a latest
> Nightly build? Thanks!

Is this going to land in Aurora too? It's not there (yet?) in 46.0a2 (2016-02-23).

Comment 29

[Patrick Brosset <:pbro>]

(In reply to Ronan Jouchet from comment #28)
> Is this going to land in Aurora too? It's not there (yet?) in 46.0a2
> (2016-02-23).
I've made an approval request for it to land in Aurora in comment 25. So as soon as this gets approved, it should land in Aurora.

Comment 30

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8721285 [details] [diff] [review]
pick-element-shortcut.diff

Reverting a keyboard shortcut to earlier behavior. 
OK to uplift to aurora.

Comment 31

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6c1a67c8233c

Comment 32

[Ronan Jouchet]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #30)
> Comment on attachment 8721285 [details] [diff] [review]
> pick-element-shortcut.diff
> 
> Reverting a keyboard shortcut to earlier behavior. 
> OK to uplift to aurora.

Confirmed fixed in Aurora 46.0a2 (2016-02-28) !

Comment 33

[Nazir Ahmed Sabbir [:NaSb]]

Successfully Reproduced this bug with Firefox Developer Edition 46.0a2 (2016-02-03) ; 
(Build ID:  20160203004041) on Linux, 64 Bit with the instructions from comment 0

This Bug is now verified as fixed on Latest Firefox Nightly 47.0a1 (2016-03-02)(Build ID: 20160302030209)
Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0 and

Latest Firefox Developer Edition 46.0a2 (2016-03-02) ; (Build ID: 20160302004006)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0

Comment 34

[Forhad Hossain]

I have reproduced the bug in Nightly 47.0a1 (2016-02-03) windows 7 32 bit with the instructions from comment 0

Bug is fixed now on Latest Nightly 47.0a1 (2016-03-05)(Build ID:20160305030241)
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0 and

Developer Edition 46.0a2 (2016-03-05)(Build ID:20160305004010)
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0

[testday-20160304]

Comment 35

[Mohammad Maruf Islam]

As this bug is verified on both Linux(Comment 33) and Windows (Comment 34), I am marking this as verified!