Closed Bug 1245654 Opened 5 years ago Closed 5 years ago

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

Categories

(DevTools :: Inspector, defect)

All
Other
defect
Not set
normal

Tracking

(firefox45 unaffected, firefox46+ verified, firefox47+ verified)

VERIFIED FIXED
Firefox 47
Tracking Status
firefox45 --- unaffected
firefox46 + verified
firefox47 + verified

People

(Reporter: mitchmadhouse, Assigned: pbro, NeedInfo)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

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.
Component: Editing → Developer Tools: Inspector
Product: Mozilla Developer Network → Firefox
I guess this is expected given bug 1213680, right :pbro?

We may see many others surprised by the change.
Flags: needinfo?(pbrosset)
Whiteboard: [specification][type:bug]
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.
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.
Blocks: 1213680
Status: UNCONFIRMED → NEW
Ever confirmed: true
Pinging others involved in the original change to make sure everyone's aware of the reports.
Flags: needinfo?(mratcliffe)
Flags: needinfo?(jgriffiths)
Flags: needinfo?(hholmes)
(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.
Thanks J. Ryan
(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!
Flags: needinfo?(jgriffiths)
Flags: needinfo?(mratcliffe)
I agree with Comment 7 and think the change should be reverted
(In reply to Brian Grinstead [:bgrins] from comment #10)
> I agree with Comment 7 and think the change should be reverted

Me too.
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.
Flags: needinfo?(pbrosset)
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.
Assignee: nobody → pbrosset
Status: NEW → ASSIGNED
(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 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!
Attachment #8720742 - Flags: review?(bgrinstead) → review+
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.
[Tracking Requested - why for this release]: Ensure this gets to 46.
(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!
Flags: needinfo?(hholmes)
https://hg.mozilla.org/mozilla-central/rev/f9e4a56281d8
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 47
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).
Attachment #8720742 - Attachment is obsolete: true
Attachment #8721285 - Flags: review+
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
Attachment #8721285 - Flags: approval-mozilla-aurora?
Duplicate of this bug: 1249053
Hello, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(mitchmadhouse)
(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).
(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 on attachment 8721285 [details] [diff] [review]
pick-element-shortcut.diff

Reverting a keyboard shortcut to earlier behavior. 
OK to uplift to aurora.
Attachment #8721285 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(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) !
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
QA Whiteboard: [bugday-20160302]
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]
As this bug is verified on both Linux(Comment 33) and Windows (Comment 34), I am marking this as verified!
Status: RESOLVED → VERIFIED
QA Whiteboard: [bugday-20160302] → [bugday-20160302] [bugday-20160307]
Depends on: 1338768
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.