Closed Bug 624588 Opened 13 years ago Closed 13 years ago

Change Panorama shortcut to Ctrl+Shift+E (Shift-Cmd-E on Mac)

Categories

(Firefox Graveyard :: Panorama, defect, P2)

defect

Tracking

(blocking2.0 final+)

VERIFIED FIXED
Firefox 4.0b10
Tracking Status
blocking2.0 --- final+

People

(Reporter: khanes, Assigned: ddahl)

References

Details

(Keywords: user-doc-needed, Whiteboard: [hardblocker][strings][fx4-fixed-bugday])

Attachments

(1 file, 6 obsolete files)

Most of the complaints about Tab Candy/Panorama I am seeing are when users accidentally enter it (via the ctrl+e). If this is the case, one solution is to have the ctrl+e hot key still present, but disabled by default.

Those users that want a tab candy hot key can have one by enabling it (they will be the more motivated demographic anyway), and we minimize accidentally entering Panorama.
blocking2.0: --- → ?
Not ready to actually block on this without some input from UX. -> uiwanted
Keywords: uiwanted
Yup, we want to do this.
blocking2.0: ? → final+
Keywords: uiwanted
Whiteboard: [hardblocker]
Assignee: nobody → ddahl
For the shortcut, I think we want to make it a little less likely to be triggered accidentally. Not knowing whether it conflicts with anything else (it doesn't seem to here, at least), Shift-(Ctrl|Cmd)-E is the current recommendation from the UX team.
(In reply to comment #3)
> For the shortcut, I think we want to make it a little less likely to be
> triggered accidentally. Not knowing whether it conflicts with anything else (it
> doesn't seem to here, at least), Shift-(Ctrl|Cmd)-E is the current
> recommendation from the UX team.

Shift-ctrl-E conflicts with AdBlock plus subscriptions (which seems minor, IMHO)
Wrote this patch before reading limi's latest comment...
Attachment #503304 - Flags: review?(dietrich)
Whiteboard: [hardblocker] → [hardblocker] [has patch]
I think we should probably map ctrl-e back to Search and avoid the pref...
... that is if we change the shortcut to shift-ctrl-e, which your patch doesn't seem to do?
(In reply to comment #7)
> ... that is if we change the shortcut to shift-ctrl-e, which your patch doesn't
> seem to do?

Correct. I just posted the patch to move on to some other things see comment 5. In the meantime i was thinking about this. We could just ditch the pref. that makes this way less code.

What do drivers think?

btw, ctrl-e was 'search'? search what?
(In reply to comment #8)
> (In reply to comment #7)
> > ... that is if we change the shortcut to shift-ctrl-e, which your patch doesn't
> > seem to do?
> 
> Correct. I just posted the patch to move on to some other things see comment 5.

Sure, you attached a patch that you wrote before reading recent comments, but why are you request review on it? Seems like we really need a final decision whether to change the shortcut or disable it.
(In reply to comment #6)
> I think we should probably map ctrl-e back to Search and avoid the pref...

We've been debating the command key for a long time, ctrl-e might not be ideal, but it's still important to have around/available. The utility of a command key is pretty high.

This bug isn't to get rid of the key combo entirely, it should still be available for users who like the utility of one hand, quick, panorama access (3 finger combos almost certainly not counting as such). A pref might be more difficult, but I feel it's the right answer in this case. Search still has another key combo iirc.
> btw, ctrl-e was 'search'? search what?

It used to be an alternative to ctrl-k, "Web Search".
I introduce to the court Exhibit A: bug 592183 and its comments, wherein various combinations were considered, and the choice of ctrl-e was explained and defended. The idea of making it a two-key shortcut was that this shortcut, for users who use Panorama, would be a very common action. Among two-key shortcuts, ctrl-e was the only available one.

If we do move to shift-ctrl-e, though, I agree with Dāo that there's no need to pref it.
(In reply to comment #11)
> > btw, ctrl-e was 'search'? search what?
> 
> It used to be an alternative to ctrl-k, "Web Search".

Note that this was only on Windows... albeit our largest platform. Just for the record.
Attachment #503304 - Flags: review?(dietrich)
(In reply to comment #3)
> For the shortcut, I think we want to make it a little less likely to be
> triggered accidentally. Not knowing whether it conflicts with anything else (it
> doesn't seem to here, at least), Shift-(Ctrl|Cmd)-E is the current
> recommendation from the UX team.

Changing the command key at this stage of the game seems high-risk. We didn't figure out the problems with the ctrl+space for a long time after it was implemented. And bug 592183 certainly illustrates the difficulty in finding a key combo that has as few conflicts as cmd/ctr-e.
shift-ctrl-[letter] is generally not a problem.
No pref needed, and collision with ABP is not a problem as long as we can ensure that Panorama is preferred. 

We should put back Ctrl-E on Windows, if that's what we used to ship with.
(In reply to comment #16)
> No pref needed, and collision with ABP is not a problem as long as we can
> ensure that Panorama is preferred. 

Wladimir (ABP developer) is generally very quick to update his extension, and IIRC, he includes code in ABP that detects shortcut collisions.

> We should put back Ctrl-E on Windows, if that's what we used to ship with.

I concur. We copied that shortcut from IE, which uses Ctrl+E for web search. Also, accidentally focusing the search box isn't much of a problem when the user was trying to close a tab.
Maybe map Ctrl+E to Web Search or Panorama according to browser.panorama.activate_keycommand.enabled?
(In reply to comment #18)
> Maybe map Ctrl+E to Web Search or Panorama according to
> browser.panorama.activate_keycommand.enabled?

No, we don't want a pref for this.
Summary: pref off hot key to enter Panorama by default → Change Panorama shortcut to Shift-Ctrl/Cmd-E
Whiteboard: [hardblocker] [has patch] → [hardblocker][strings]
Could somebody please explain why you don't want a pref? Over in Bug 592183 the need for an two-key shortcut was well accepted by UX.

Anyway, how difficult will it be for an addon to remap this in a sane way?
(In reply to comment #17)
> Wladimir (ABP developer) is generally very quick to update his extension, and
> IIRC, he includes code in ABP that detects shortcut collisions.

No, not yet - for now that code is only in the Element Hiding Helper extension that needs to choose between two shortcut keys dynamically. I decided against including that code in Adblock Plus because of additional startup delay (around 40ms from what I remember). This is due to enumerating all xul:key tags which needs to happen during the window load event. I tried delaying initialization but xul:key tags inserted later might end up ignored, nsXBLWindowKeyHandler caches its data (happens when the first keypress event is processed). But I guess that I won't be able to avoid doing this now.

Firefox hotkeys will get priority over ABP hotkeys either way, the latter ones are inserted dynamically when the window loads, so they will be processed last.
(In reply to comment #0)
> Most of the complaints about Tab Candy/Panorama I am seeing are when users
> accidentally enter it (via the ctrl+e).

I'm not really surprised that people are complaining. How does one exit Tab Candy? All the obvious "close" buttons will close tabs or tab groups - scary. And it is all but obvious that the window's close button will exit Tab Candy rather than close the window (I hesitated quite a bit before trying it).
Attachment #503304 - Attachment is obsolete: true
Attachment #503476 - Flags: review?
Attachment #503476 - Flags: review? → review?(dao)
Comment on attachment 503476 [details] [diff] [review]
v 0.2 Added Shift modifier - no pref

Still need to map Ctrl+E to web search.
Attachment #503476 - Attachment is obsolete: true
Attachment #503522 - Flags: review?(dao)
Attachment #503476 - Flags: review?(dao)
Comment on attachment 503522 [details] [diff] [review]
v 0.2 Added Shift modifier - no pref, ctrl-e on windows (search) added back

>--- a/browser/base/content/browser-sets.inc
>+++ b/browser/base/content/browser-sets.inc
>@@ -225,16 +225,19 @@
> # We support Ctrl+K on all platforms now and advertise it in the menu since it is
> # our standard - it is a "safe" choice since it is near no harmful keys like "W" as
> # "E" is. People mourning the loss of Ctrl+K for emacs compat can switch their GTK
> # system setting to use emacs emulation, and we should respect it. Focus-Search-Box
> # is a fundamental keybinding and we are maintaining a XP binding so that it is easy
> # for people to switch to Linux.
> #
>     <key id="key_search" key="&searchFocus.commandkey;" command="Tools:Search" modifiers="accel"/>
>+#ifdef XP_WIN
>+    <key id="key_searchWin" key="&searchFocusWin.commandkey;" command="Tools:Search" modifiers="accel"/>
>+#endif
> #ifdef XP_MACOSX
>     <key id="key_search2" key="&findOnCmd.commandkey;" command="Tools:Search" modifiers="accel,alt"/>
> #endif
> #ifdef XP_GNOME
>     <key id="key_search2" key="&searchFocusUnix.commandkey;" command="Tools:Search" modifiers="accel"/>
>     <key id="key_openDownloads" key="&downloadsUnix.commandkey;" command="Tools:Downloads" modifiers="accel,shift"/>
> #else

Please keep calling this key_search2 and update the above comment (partly reverting attachment 478834 [details] [diff] [review]).
Thanks for the link to the originating patch.
Attachment #503522 - Attachment is obsolete: true
Attachment #503524 - Flags: review?(dao)
Attachment #503522 - Flags: review?(dao)
Comment on attachment 503524 [details] [diff] [review]
v 0.3 Added Shift modifier - no pref, ctrl-e on windows (search) added back

> <!ENTITY searchFocus.commandkey       "k">
>+<!ENTITY searchFocus.commandkey2      "e">
> <!ENTITY searchFocusUnix.commandkey   "j">

As opposed to the key's id, searchFocusWin.commandkey made more sense. It's consistent with searchFocusUnix.commandkey and .label/.accesskey/.commandkey aren't supposed to have numbers added.
Attachment #503524 - Attachment is obsolete: true
Attachment #503548 - Flags: review?(dao)
Attachment #503524 - Flags: review?(dao)
Attachment #503548 - Flags: review?(dao) → review+
Late l10n-hit, but a small one. Le sigh. If there's a lot of pushback, I'd be fine with just dropping the IE-compat shortcut baloney, entirely. It's actually based on an old Windows Explorer compat issue - IE9 doesn't do ctrl+e anymore (look ma, no searchbox!)
Keywords: user-doc-needed
(In reply to comment #30)
> Late l10n-hit, but a small one. Le sigh. If there's a lot of pushback, I'd be
> fine with just dropping the IE-compat shortcut baloney, entirely. It's actually
> based on an old Windows Explorer compat issue - IE9 doesn't do ctrl+e anymore
> (look ma, no searchbox!)

IE9 still does ctrl+e. They insert a question mark ('?') in the address bar and focus it to indicate that whatever is entered after that mark will be treated as a search query, not a URL. Chrome has done the same since its launch.
Pike says no string changes, so that suggests not re-adding Ctrl+E.
ok. new patch in a moment.
Attached patch v 0.4 one liner (obsolete) — Splinter Review
Attachment #503605 - Flags: review?(dao)
Comment on attachment 503605 [details] [diff] [review]
v 0.4 one liner

This is effectively a string change, since accel+shift+&tabView.commandkey; could already be taken...
That's unlikely, I don't think we need to worry about it.
Comment on attachment 503605 [details] [diff] [review]
v 0.4 one liner

I searched through the browser.dtds on l10n-central, there don't seem to be any conflicts.
Attachment #503605 - Flags: review?(dao) → review+
FWIW, anything in browser-doctype.inc can contribute, not least baseMenuOverlay.dtd. Didn't check anything in-depth, though.
So Ctrl+E will be idle now?
(In reply to comment #39)
> So Ctrl+E will be idle now?

Yes. However, the web console dynamically binds ctrl-e (end of line) to the console input on UI construction, but this is a new feature and very developer-centric.
Firefox UX Team said in comment #16:
> We should put back Ctrl-E on Windows, if that's what we used to ship with.
I would love to land this if drivers give the OK - either patch:)
It's a final+ blocker, no explicit approval needed, patch which just adds the extra modifiers and leaves Cmd+E idle.
http://hg.mozilla.org/mozilla-central/rev/6419e802aab0
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b10
Had to back this out due to orange:
http://hg.mozilla.org/mozilla-central/rev/1eb45ae169fa

Various tabcandy tests trigger the UI using the shortcut, so they need to be updated, e.g.:

http://hg.mozilla.org/mozilla-central/annotate/f24f049857a5/browser/base/content/test/tabview/browser_tabview_bug595191.js#l93
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Fixed all tests that synthesizeKey. test files had errant trailing spaces as well - emacs/js2-mode auto-corrected them.
Attachment #503548 - Attachment is obsolete: true
Attachment #503605 - Attachment is obsolete: true
Attachment #503959 - Flags: review?(dao)
Attachment #503959 - Flags: review?(dao) → review+
hardblocker = blocker
Severity: normal → blocker
Severity: blocker → normal
Keywords: checkin-needed
Whiteboard: [hardblocker][strings] → [hardblocker][strings][needs landing]
I noticed that this has [strings] in the whiteboard, but the patch actually doesn't touch the strings.  Does this really have l10n impact?
http://hg.mozilla.org/mozilla-central/rev/993dea936b18
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [hardblocker][strings][needs landing] → [hardblocker]
dao: thank you for landing this. was just about to.
Yes, there's a new potential conflict in control keys with the changed modifiers. Not that l10n *should* change those in the first place.

I'll post to .l10n.
Blocks: 626448
(In reply to comment #52)
> Yes, there's a new potential conflict in control keys with the changed
> modifiers. Not that l10n *should* change those in the first place.

In that case, let's readd [strings] to the whiteboard.
Whiteboard: [hardblocker] → [hardblocker][strings]
Shift-Ctrl is another default shortcut for switch IME, at least in Windows / Linux with Chinese IME installed. Change to Shift-Ctrl blocks users from using this feature.

Suggest -> reopen.
(In reply to comment #54)
> Shift-Ctrl is another default shortcut for switch IME, at least in Windows /
> Linux with Chinese IME installed. Change to Shift-Ctrl blocks users from using
> this feature.
> 
> Suggest -> reopen.

Bob, is this not a problem with other shift-ctrl-* commands?
(In reply to comment #55)
> (In reply to comment #54)
> > Shift-Ctrl is another default shortcut for switch IME, at least in Windows /
> > Linux with Chinese IME installed.
> 
> Bob, is this not a problem with other shift-ctrl-* commands?

Yeah, not a problem. For example, we can use shift-ctrl-t to restore closed tabs without switching IME.
(In reply to comment #56)
> (In reply to comment #55)
> > (In reply to comment #54)
> > > Shift-Ctrl is another default shortcut for switch IME, at least in Windows /
> > > Linux with Chinese IME installed.
> > 
> > Bob, is this not a problem with other shift-ctrl-* commands?
> 
> Yeah, not a problem. For example, we can use shift-ctrl-t to restore closed
> tabs without switching IME.

I'm a little confused. The shortcut for Panorama is now shift-ctrl-E. I assume that shouldn't be a problem for Chinese IME users then?
Ah, sorry I misunderstood the title. :/ So it's Ctrl-Shift-E or Ctrl-Cmd-E.
I confirm that it's not a problem for Chinese IME users.
Summary: Change Panorama shortcut to Shift-Ctrl/Cmd-E → Change Panorama shortcut to Ctrl+Shift+E (Shift-Cmd-E on Mac)
This new shortcut is seriously awful. It's a too much of a hand stretch for something that will be used so frequently (my poor tendons!), and within approx 30 seconds of me using the new shortcut, I managed to hit Ctrl+Shift+W which closed the whole window, which confuse and frustrate users *far* more than closing a single tab.

Having this shortcut will pretty much guarantee I will never use it.

Please revert for the sake of your users!
The shortcup interferes with adblock plus preferences panel, which means that I cannot use it so far. Shouldnt it take over ADP?
I have to say that I agree with comment 60. I was peeved that the shortcut was originally changed from CTRL + space, as that was a perfect shortcut for me, but this change takes it a step further and is most definitely annoying.

Personally, I'd really like to see this reviewed, particularly with the intent to add a pref to change the shortcut to something more suitable.

Or perhaps someone can answer the question in comment 20 about the possibility of an addon to fix this.
"It's a too much of a hand stretch for
something that will be used so frequently (my poor tendons!)"

http://dubroy.com/blog/how-many-tabs-do-people-use-now-with-real-data/

There's a study here that pegs the median number of tabs used as around 5, so I don't imagine that most people are clamoring for panorama.
What you can take from that study, is that those users, who use more tabs, use *many* more tabs (as a power user / dev, that's certainly me), and those users are the ones who would benefit the from panorama most (and use it frequently).

Personally, I'm using it (especially at work), many tens of times per hour. Or at least, I used to :-/
Okay, but why bother investing Mozilla's time in this feature for power users, yet strip out the RSS feed? It just looks like something someone cooked up in Labs and felt like it would make a good bullet point for Firefox 4, even though most users wouldn't benefit from.
I also liked the old Ctrl+Space much better. But I do fully understand why there was a need to change.

For anyone interested in changing the shortcut - I invested some minutes and wrote a tiny addon that should be sufficient for the time being :)

https://addons.mozilla.org/en-US/firefox/addon/change-panorama-shortcut/
(In reply to comment #66)
> For anyone interested in changing the shortcut - I invested some minutes and
> wrote a tiny addon that should be sufficient for the time being :)
> 
> https://addons.mozilla.org/en-US/firefox/addon/change-panorama-shortcut/

Sweet, back to cmd-E for me. Thanks Tim!
Two keys for the original shortcut were fine - Ctrl-E was located right next to Ctrl-T on a QWERTY keyboard and so you could use one hand to go into Panorama and the other on the mouse to select that tab to get into.

Ctrl-Shift-E (and other 3-key shortcuts) make the time to switch longer and you may as well drag your mouse to Panorama icon in the top bar to make the switch, there's no time saving.

Now, even though extensions can solve this kind of problem (thanks to Tim in this case, as in the comments above) - there should be a preferences dialog where you can at least *see* the keyboard shortcuts. To allow changing them would be great as well. How else are you going to know it's Ctrl-Shift-E?
I have to agree with comment 60.  I just hit the change in the daily build.  Command-shift-E is not only not discoverable, it's REALLY uncomfortable to use, and not just because I've got tendonitis in my arms.  It forces you to stretch your fingers and wrist into a really unnatural position.  It's not easily accessible on the keyboard.  And it needs to be, because it's something that I'd want to access frequently.

To be useful, the time and "pain" involved in accessing Panorama needs to be < the time and pain involved in having more tabs visible at once in the browser.  Command-shift-E is quite literally, much more painful to use, and just far more difficult.  Using the icon is about as time intensive as finding the right tab in the browser, so I probably wouldn't use Panorama with this shortcut.  With an easily accessible shortcut, or with multitouch activation, I was using it a lot.  With command-E, it was easy to access without taking my hand off the trackpad or mouse.  With command-shift-E, I feel like I need to join cirque-du-soliel to stretch in the right way to access it.
An important thing to note is that Panorama is de-emphasized in Firefox 4 compared to the original plan (for several reasons), but will probably be a bit more available and prominent in later releases.

Right now, there isn't an obvious, available shortcut key that doesn't interfere with other functionality, but we hope to do an audit of the shortcut keys after Firefox 4 ships, so the least recently used ones can be freed up. Test Pilot would be an excellent way to gather data on this.

If you have tendonitis, I'd definitely recommend using the add-on to get it off Cmd-Shift-E, and possibly even to a two-handed shortcut (Option-Space was the initial design, but this collided with input method selection on certain platforms).
(In reply to comment #71)

Thanks for the explanation. It definitely helps clear the air. Though it is a little disappointing seeing various things not make it into Firefox 4. Guess we just need to hope that they'll find their way in further down the line.
I'll definitely consider the plugin.  One thing to note is that features like this are useful in part because they are present in each instance of Firefox I run.  I can remap the key on my own systems, but when I use new systems, I expect things to be mapped the same way, and of course they won't be.

Just a thought - what about control or option P on the Mac?  When I try them now, option-P gives me π, and control-P gives me something that behaves like an up arrow.  Neither are terribly useful.  Plus, P is a good mnemonic for Panorama!  :)
Sorry for continuing to complain, but the situation is really weird.

Now we have a feature integrated into firefox (panorama) which is probably mostly used by advanced users, but because of the complicated shortcut it will likely be unusable for them. So now i have to install an add-on to change the shortcut. If i am right we have mostly two groups of users: one does not use panorama, the other need an add-on to use it comfortable. From this point of view panorama should better completely remain as an add-on or the shortcut has to be easy to use, anything else does not make much sense.

I am really stunned.
Verified fixed 

Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110123 Firefox/4.0b10pre
Status: RESOLVED → VERIFIED
Depends on: 592183
I totally agree with comment #74.

I'm a power user, at least I consider myself as one. I was thrilled when I saw CTRL+E .. so easy to use, so handy, so close to CTRL+W, CTRL+T... so comfy.

Now this CTL+SHIFT+E comes in. I'm not a pianist , nor I want to become one. It's not comfortable, not handy. It's much worse than it was.

What's the point ? People can't hit a key? I feel sorry for them.
At least find a normal solution.
- Option to choose between this nonsense ctrl+shift+e and ctrl+e
OR
- Configurable hotkey for Panorama

But this is completely UNACCEPTABLE.
Another issue:
If I start using CTRL+SHIFT+E ..and press CTRL+SHIFT+W, I close _ALL_ of my tabs.

Now.. which is the bigger problem?
- If I close ONE tab which I can reopen OR open a new tab.
- If I CLOSE ALL MY TABS and there is no way to know which ones I had open from the History.

.... No comment.
(In reply to comment #77)
> If I CLOSE ALL MY TABS and there is no way to know which ones I had open from
> the History.

History > Recently Closed Windows
Will that save the closed tabs into a group so I can know which tabs did I have when the close happens?
(In reply to comment #78)
> (In reply to comment #77)
> > If I CLOSE ALL MY TABS and there is no way to know which ones I had open from
> > the History.
> 
> History > Recently Closed Windows

While there is always that option, the point remains that closing all current tabs is worse than closing one tab. It's a situation that you want to avoid happening by accident. There is a much higher risk of losing something you don't want to lose, like a half written Email, or a video that you were letting load in the background.

I do feel comment 77 brings up a valid point and shows that the original argument that people might accidentally trigger Panorama isn't as awful as previously thought. But that's just my view.
(In reply to comment #43)
> It's a final+ blocker, no explicit approval needed, patch which just adds the
> extra modifiers and leaves Cmd+E idle.

From what I've seen, you, sir, are unbelievably short-minded and plainly ignorant.
It looks like you're on a crusade to dismiss everything that came from Microsoft, even the things that actually make sense, just to be different.
So, you choose to leave a shortcut **idle** instead of making it do *something*, which it has been doing for years. Ctrl+E has been tied to "search" and that's it! It's only Windows? Maybe. There's also Ctrl+K? Maybe.
The plain fact is, users browse with right hand on mouse, left on keyboard. So, that's why all good shortcuts are there, like Ctrl+W, Ctrl+R, Ctrl+T, Ctrl+C, Ctrl+V etc.
Now, you try to press Ctrl+K with the left hand (sat it regular typing position) and see for yourself how nice it is.

The beginning of this very bug report was that people were accidentally getting in Panorama, by hitting Ctrl+E. GUESS WHY THEY WERE HITTING Ctrl+E IN THE FIRST PLACE??? Could it be, to get to "Search", **maybe**?
And what do you do? Instead of fixing it back to the way it was, you just disable Ctrl+E  and change shortcut for Panorama!!!

Now, I know that *if* you bother respond at all, you'll probably just dismiss me. Just go to the beta feedback and search for "Ctrl+E" and "search shortcut". I wonder, how much negative feedback it'll take until the reality finally makes contact with you...
Reopening for input, I agree that we shouldn't remove/regress a shortcut and break muscle memory just because we're not using this for Panorama after all. (Note that the shortcut only exists on Windows, AFAIK).

The reason that the failure case of accidentally triggering this was bad is that Panorama takes away all your context and leaves you wondering what happened, and how to get back to where you were.

Accidentally triggering the *search* shortcut is much less drastic (it essentially just moves focus), and more likely to just be a "oh, I didn't hit the Ctrl-W key after all, my tab is still here, let me hit Ctrl-W again."(In reply to comment #81)

> (In reply to comment #43)
> From what I've seen, you, sir, are unbelievably short-minded and plainly
> ignorant.

This is completely unacceptable behavior in a bug tracker, consider this your warning. Making your point without resorting to ad hominem attacks isn't hard.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html — section 1.3 might be something you want to keep in mind.

Note that I'm reopening this *despite* your comment, since it was on the list of bugs I wanted to follow up on to make sure they were fixed properly.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Bad quoting on my part, the second half was directed at comment 81, but that reference ended up in the previous paragraph. )
"Note that the shortcut only exists on Windows"

Well.. so most of the users have to wrangle with it.

Anyway. Sorry for interrupting the 'war' but:
Can't we just move back to the original ctrl+e version?

Or ... listen. Just put a button there which switches between these options.
And.. its perfect. Or put it into the about:config.

I don't really want to patch the source and have a build system just for a
single hotkey... its getting ridiculous.
(In reply to comment #82)
> This is completely unacceptable behavior in a bug tracker, consider this your
> warning. Making your point without resorting to ad hominem attacks isn't hard.
> ...
> Note that I'm reopening this *despite* your comment, since it was on the list
> of bugs I wanted to follow up on to make sure they were fixed properly.

Noted. Let me see, now... take a look at this:

(Quote comment #30)
> I'd be fine with just dropping the IE-compat shortcut baloney, entirely.

And this is an acceptable remark from someone that is actually in charge of making decisions in here?
After all these years, it's no longer "IE-compat baloney", it's what YOU have made people USE and LEARN! Now, if that person isn't anti-Microsoft biased, I don't know who is.

Sorry if the adjectives I used were offensive, but that attitude is equally offensive to me, in an open-source world: "I don't like it, I single-handedly decide, it will be THAT way!"... some people could call that "dictatorship"...
Just a passing thought here, but would some variation on the tilde key (just
above the Tab key) work? At the moment, CTRL + Tilde scrolls between tab
groups(I only just found this out!), but would it be more sensible to have that
as the main Panorama shortcut and CTRL + SHIFT + Tilde be the scroll between
tab groups shortcut?
This may sound like a ragepost but this is the 3rd time I lost ALL OF MY WORK due to the new shortcut.

Thanks. Seriously.. thank you.

Please just attach a patch which removes the WHOLE Panorama.
(In reply to comment #86)
> Just a passing thought here, but would some variation on the tilde key (just
> above the Tab key) work? At the moment, CTRL + Tilde scrolls between tab
> groups(I only just found this out!), but would it be more sensible to have that
> as the main Panorama shortcut and CTRL + SHIFT + Tilde be the scroll between
> tab groups shortcut?

Ctrl+Shift+[~] is the same as Ctrl+[~], only reverse direction. It's the same paradigm as Alt+Tab and Ctrl+Tab, where the addition of Shift modifier just goes backwards (if you assume that the unshifted direction is forward).
CTRL+~ would only work for keyboards with US layout (and maybe some other), at least if you want to use just one hand. With a DE layout you have to press STRG+AltGr++ (~ is on the + key next to return), that's a nightmare, no one with such a keyboard will ever use it.
(In reply to comment #89)
> CTRL+~ would only work for keyboards with US layout (and maybe some other), at
> least if you want to use just one hand. With a DE layout you have to press
> STRG+AltGr++ (~ is on the + key next to return), that's a nightmare, no one
> with such a keyboard will ever use it.

You know, I can't understand two things with this:
a. why are they even trying to make the shortcuts common on all platforms
b. why don't they invest that time to make a fully configurable shortcut editor

Firstly, each platform has its own shortcuts by default. I don't see Microsoft and Apple and Linux guys try to match each other's shortcuts. So, in Windows we have some vacant keys which we can't use because the Mac users use it, and the Mac users have empty keys that they can't use because the Linux uses them. How stupid is that?
Just by making a simple shortcut editor, every user can change the shortcuts to what they prefer, and what their keyboard is best suited for, and that will be the end of the story!
Make everything configurable, people, not hard-coded to what **someone** thinks is best.
(In reply to comment #90)
> b. why don't they invest that time to make a fully configurable shortcut editor

I would love it, but i think that is not an option for FF4. That short before the RC they probably wont implement such a basic modification.
(In reply to comment #87)
> This may sound like a ragepost but this is the 3rd time I lost ALL OF MY WORK
> due to the new shortcut.
> 
> Thanks. Seriously.. thank you.
> 
> Please just attach a patch which removes the WHOLE Panorama.

The fact that Ctrl-Shift-W closes all tabs, and combined with the loss of the close all tabs warning (separate bug), this got a whole lot worse.

I definitely agree that the current solution is not good, and I'm talking to Paul about what to do here. I have a proposal, and I'll put it in the bug tomorrow, once I have made sure there aren't any other edge cases I have missed.

Apologies for these two separate issues conspiring and making this painful, I'll find a way to fix it. Give me until tomorrow, and I'll outline what the solution will be.
If you're going to rethink the shortcuts *after* Firefox 4, then it seems that maybe this shouldn't have a shortcut for now at all.

As you can see from the very angry poster, users learn if you let them! If you make a shortcut now, only to find a better one later then you'll be going through this all over again, and in the end people will be asking for a pref to map back to whatever you choose now, or they'll have to use an extension.

An extension or a pref in the first place seems to be the sane course right now, then people *already* have it installed if they want to override whatever is chosen in the future.
Why is this re-opened? Ctrl/Cmd+Shift+E activates Panorama, as per request.

If we want to re-enable Ctrl/Cmd+E, file another bug for that, and we can evaluate the late-l10n cost. As Gavin indicated in comment 32, it's unlikely that will make Firefox 4.

Closing this back up now.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
I have had the same problem (with the removal of CTRL+E for search), and decided I couldn't wait for the Firefox head cheeses to do something that they don't want to do. So I created this simple add-on:

https://addons.mozilla.org/en-US/firefox/addon/change-search-shortcut/

Along with the previous (simple) add-on, which I used as a basis for mine, you should have a complete solution.

Enjoy! Cheers!
One more thing:
Can we AT LEAST have "key_search2" re-enabled on Windows builds as well (empty key and modifier binding), so that my add-on can work on that, and leave "key_search" alone to be CTRL+K ?

Unix and OS X BOTH have two 'search' keys, "key_search" and "key_search2". Why did you remove it from Windows?

Is even that TOO MUCH to ask for?
Status: RESOLVED → VERIFIED
Whiteboard: [hardblocker][strings] → [hardblocker][strings][fx4-fixed-bugday]
Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Pointing out that the popular Foobar addon breaks the Ctrl+Shift+E shortcut for some reason. (Pressing it with the addon enabled only highlights the current URL in the address bar, failing to trigger the Tab Group window)
Dear Mozilla's,

what is wrong??

You not shifted 'Ctrl+E' to 'Ctrl+Shift+E' but you also put the 'tab groups button' into a submenu which only appears when there are more tabs than space on the tab bar (version 12 speaking).

Ok, people could revert to 'Ctrl+Shift+E' even if it is a nuisance to type that with only your left hand trying to avoid 'Ctrl+Shift+W' which would close the whole window.

But even then 'Ctrl+Shift+E' does not work on a tab where you are watching a flash video (like youtube).

I'm really sorry if my I may sound a little unfriendly but I get the idea that it is the intent to make the panorama feature totally inaccessible.

This would disappoint me very much as as I like the feature very much.

Perhaps you could give some ideas to make it work again or you could look at the problem that 'Ctrl+Shift+E' does not work while watching flash video.

Thanks.
Thanks for your feedback, but this bug report was resolved a few months ago. Can you please report your concerns to a new bug report? Thank you.
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.