Make most browser accelerators not repeat.

Make most browser accelerators not repeat.

Prevent browser accelerators from repeating unless they're associated with the
following commands:

  IDC_FIND_NEXT
  IDC_FIND_PREVIOUS
  IDC_FOCUS_NEXT_PANE
  IDC_FOCUS_PREVIOUS_PANE
  IDC_MOVE_TAB_NEXT
  IDC_MOVE_TAB_PREVIOUS
  IDC_SELECT_NEXT_TAB
  IDC_SELECT_PREVIOUS_TAB

BUG=626154
TEST=Ctrl-Tab still repeats but Ctrl-t doesn't

Committed: https://crrev.com/42d287c9658c6bfa1202275597f28399409e8603
Cr-Commit-Position: refs/heads/master@{#416995}

[Daniel Erat, 2016-07-07 21:08:49]

derat@chromium.org changed reviewers:
+ pkasting@chromium.org, sky@chromium.org

[Daniel Erat, 2016-07-07 21:08:50]

https://codereview.chromium.org/2128243003/diff/1/ui/base/accelerators/accele...
File ui/base/accelerators/accelerator_manager.cc (right):

https://codereview.chromium.org/2128243003/diff/1/ui/base/accelerators/accele...
ui/base/accelerators/accelerator_manager.cc:28: if (priority == kHighPriority) {
this isn't exactly related but i saw the old code while i was investigating this
change and it freaked me out. :-P

[Daniel Erat, 2016-07-07 21:09:19]

Peter, I'm assuming you'll let me know if this is a horrible idea. :-)

[Peter Kasting, 2016-07-07 21:17:57]

Hmmm.  I'm definitely suspicious of this, because it breaks native key-repeating
behavior.

What do other browsers and apps do?  Are there any that make certain shortcuts
non-repeatable?

[Daniel Erat, 2016-07-07 21:30:52]

On 2016/07/07 21:17:57, Peter Kasting wrote:
> Hmmm.  I'm definitely suspicious of this, because it breaks native
key-repeating
> behavior.
> 
> What do other browsers and apps do?  Are there any that make certain shortcuts
> non-repeatable?

on linux, both gedit (i.e. gnome) and firefox create a big pile of tabs when i
hold ctrl-n or ctrl-t, respectively. a coworker tested this for me with safari
on os x; the new-tab accelerator repeats there as well.

so i can't deny that this breaks precedent... but it still feels to me like it
removes a probably-accidental misfeature. the delay before autorepeat activates,
and the frequency at which it repeats, are user-configurable and presumably
configured to aid in typing (and primarily for backspace and the arrow keys, i'd
wager). having autorepeat apply to accelerators (at least ones dissimilar from
e.g. "find next", where it seems useful) doesn't make sense to me.

[Peter Kasting, 2016-07-07 21:42:44]

On 2016/07/07 21:30:52, Daniel Erat wrote:
> On 2016/07/07 21:17:57, Peter Kasting wrote:
> > Hmmm.  I'm definitely suspicious of this, because it breaks native
> key-repeating
> > behavior.
> > 
> > What do other browsers and apps do?  Are there any that make certain
shortcuts
> > non-repeatable?
> 
> on linux, both gedit (i.e. gnome) and firefox create a big pile of tabs when i
> hold ctrl-n or ctrl-t, respectively. a coworker tested this for me with safari
> on os x; the new-tab accelerator repeats there as well.
> 
> so i can't deny that this breaks precedent... but it still feels to me like it
> removes a probably-accidental misfeature. the delay before autorepeat
activates,
> and the frequency at which it repeats, are user-configurable and presumably
> configured to aid in typing (and primarily for backspace and the arrow keys,
i'd
> wager). having autorepeat apply to accelerators (at least ones dissimilar from
> e.g. "find next", where it seems useful) doesn't make sense to me.

I know I've used held-down-ctrl-t and ctrl-n before.  Admittedly, in debugging
scenarios mostly, but they have been intentional.

I feel like someone could argue me into removing repeat on a destructive
shortcut like ctrl-w, but it's harder to justify on something like ctrl-t.  And
even then, I can see arguments for allowing holding down ctrl-w to quit and the
like.  I kinda feel like the burden of proof is on the argument that breaks
native behavior, and right now I don't feel like either side is massively
compelling.

Has anyone ever complained about this?  I haven't seen any requests for this,
maybe you have.

[sky, 2016-07-07 22:29:02]

IMO if users are complaining about this it wouldn't be unique to
chrome, and the user should change the auto-repeat rate. For example,
couldn't you extend this argument to pressing delete/backspace in text
editors should be throttled way back as someone might accidentally
hold it down for too long?

I'll mention that Windows doesn't attempt to throttle destructive keys
like alt-f4 (close active window). If you hold it down long enough all
your windows end up closing.

You might ping Alex for his thoughts.

  -Scott

On Thu, Jul 7, 2016 at 2:42 PM,  <pkasting@chromium.org> wrote:
> On 2016/07/07 21:30:52, Daniel Erat wrote:
>> On 2016/07/07 21:17:57, Peter Kasting wrote:
>> > Hmmm. I'm definitely suspicious of this, because it breaks native
>> key-repeating
>> > behavior.
>> >
>> > What do other browsers and apps do? Are there any that make certain
> shortcuts
>> > non-repeatable?
>>
>> on linux, both gedit (i.e. gnome) and firefox create a big pile of tabs
>> when i
>> hold ctrl-n or ctrl-t, respectively. a coworker tested this for me with
>> safari
>> on os x; the new-tab accelerator repeats there as well.
>>
>> so i can't deny that this breaks precedent... but it still feels to me
>> like it
>> removes a probably-accidental misfeature. the delay before autorepeat
> activates,
>> and the frequency at which it repeats, are user-configurable and
>> presumably
>> configured to aid in typing (and primarily for backspace and the arrow
>> keys,
> i'd
>> wager). having autorepeat apply to accelerators (at least ones dissimilar
>> from
>> e.g. "find next", where it seems useful) doesn't make sense to me.
>
> I know I've used held-down-ctrl-t and ctrl-n before. Admittedly, in
> debugging
> scenarios mostly, but they have been intentional.
>
> I feel like someone could argue me into removing repeat on a destructive
> shortcut like ctrl-w, but it's harder to justify on something like ctrl-t.
> And
> even then, I can see arguments for allowing holding down ctrl-w to quit and
> the
> like. I kinda feel like the burden of proof is on the argument that breaks
> native behavior, and right now I don't feel like either side is massively
> compelling.
>
> Has anyone ever complained about this? I haven't seen any requests for this,
> maybe you have.
>
> https://codereview.chromium.org/2128243003/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Daniel Erat, 2016-07-08 00:58:10]

On 2016/07/07 22:29:02, sky wrote:
> IMO if users are complaining about this it wouldn't be unique to
> chrome, and the user should change the auto-repeat rate. For example,
> couldn't you extend this argument to pressing delete/backspace in text
> editors should be throttled way back as someone might accidentally
> hold it down for too long?
> 
> I'll mention that Windows doesn't attempt to throttle destructive keys
> like alt-f4 (close active window). If you hold it down long enough all
> your windows end up closing.
> 
> You might ping Alex for his thoughts.

i think that autorepeat suppression was first added to chrome os in 2012 for
http://crbug.com/152145. since then, a bunch of other WM shortcuts handled by
ash were also suppressed in an ad-hoc fashion (http://crbug.com/514350,
http://crbug.com/590892, http://crbug.com/457961, etc. -- see "git blame
c061dd11^ -- ash/accelerators/accelerator_table.c"). there are only a few WM
shortcuts where autorepeat actually makes sense, as far as i'm aware, so i
recently switched to a whitelist approach (http://crbug.com/626014).

chrome os is now in a spot where e.g. ctrl-n doesn't repeat, as it's handled by
ash, but ctrl-w does, as it's handled by chrome. i was trying to resolve that
here by updating chrome's behavior to match ash's. if this change should be
chrome-os-only, i'm okay with that.

i don't know if there have been user complaints for the specific browser
accelerators that i'm limiting here (as opposed to the various bugs that were
worked around with the earlier ash changes), although i've personally
experienced unwanted tab-closing due to ctrl-w autorepeating. my autorepeat
settings are the way that i want them for typing, and changing them to avoid
accelerator behavior that i have never intended to trigger doesn't seem like a
great solution. :-/

which alex were you referring to, scott? kuscher@, or someone else?

[Peter Kasting, 2016-07-08 01:15:21]

On 2016/07/08 00:58:10, Daniel Erat wrote:
> On 2016/07/07 22:29:02, sky wrote:
> > IMO if users are complaining about this it wouldn't be unique to
> > chrome, and the user should change the auto-repeat rate. For example,
> > couldn't you extend this argument to pressing delete/backspace in text
> > editors should be throttled way back as someone might accidentally
> > hold it down for too long?
> > 
> > I'll mention that Windows doesn't attempt to throttle destructive keys
> > like alt-f4 (close active window). If you hold it down long enough all
> > your windows end up closing.
> > 
> > You might ping Alex for his thoughts.
> 
> i think that autorepeat suppression was first added to chrome os in 2012 for
> http://crbug.com/152145. since then, a bunch of other WM shortcuts handled by
> ash were also suppressed in an ad-hoc fashion (http://crbug.com/514350,
> http://crbug.com/590892, http://crbug.com/457961, etc. -- see "git blame
> c061dd11^ -- ash/accelerators/accelerator_table.c"). there are only a few WM
> shortcuts where autorepeat actually makes sense, as far as i'm aware, so i
> recently switched to a whitelist approach (http://crbug.com/626014).
> 
> chrome os is now in a spot where e.g. ctrl-n doesn't repeat, as it's handled
by
> ash, but ctrl-w does, as it's handled by chrome. i was trying to resolve that
> here by updating chrome's behavior to match ash's. if this change should be
> chrome-os-only, i'm okay with that.

Yeah, that discrepancy is bad.  Personally I would have operated under the rule
that "CrOS should match windows" and not added such no-repeat hacks (or removed
the already-added ones), but I don't own CrOS, and I imagine the folks who do
aren't keen to do that; if so, then doing this patch for CrOS only is probably
best.

> which alex were you referring to, scott? kuscher@, or someone else?

Ainslie, I'd think.

[sky, 2016-07-08 02:28:54]

Yes, Ainslie, sorry for not being clear.

  -Scott

On Thu, Jul 7, 2016 at 6:15 PM,  <pkasting@chromium.org> wrote:
> On 2016/07/08 00:58:10, Daniel Erat wrote:
>> On 2016/07/07 22:29:02, sky wrote:
>> > IMO if users are complaining about this it wouldn't be unique to
>> > chrome, and the user should change the auto-repeat rate. For example,
>> > couldn't you extend this argument to pressing delete/backspace in text
>> > editors should be throttled way back as someone might accidentally
>> > hold it down for too long?
>> >
>> > I'll mention that Windows doesn't attempt to throttle destructive keys
>> > like alt-f4 (close active window). If you hold it down long enough all
>> > your windows end up closing.
>> >
>> > You might ping Alex for his thoughts.
>>
>> i think that autorepeat suppression was first added to chrome os in 2012
>> for
>> http://crbug.com/152145. since then, a bunch of other WM shortcuts handled
>> by
>> ash were also suppressed in an ad-hoc fashion (http://crbug.com/514350,
>> http://crbug.com/590892, http://crbug.com/457961, etc. -- see "git blame
>> c061dd11^ -- ash/accelerators/accelerator_table.c"). there are only a few
>> WM
>> shortcuts where autorepeat actually makes sense, as far as i'm aware, so i
>> recently switched to a whitelist approach (http://crbug.com/626014).
>>
>> chrome os is now in a spot where e.g. ctrl-n doesn't repeat, as it's
>> handled
> by
>> ash, but ctrl-w does, as it's handled by chrome. i was trying to resolve
>> that
>> here by updating chrome's behavior to match ash's. if this change should
>> be
>> chrome-os-only, i'm okay with that.
>
> Yeah, that discrepancy is bad. Personally I would have operated under the
> rule
> that "CrOS should match windows" and not added such no-repeat hacks (or
> removed
> the already-added ones), but I don't own CrOS, and I imagine the folks who
> do
> aren't keen to do that; if so, then doing this patch for CrOS only is
> probably
> best.
>
>> which alex were you referring to, scott? kuscher@, or someone else?
>
> Ainslie, I'd think.
>
> https://codereview.chromium.org/2128243003/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Peter Kasting, 2016-08-20 03:03:59]

Description was changed from

==========
Make most browser accelerators not repeat.

Prevent browser accelerators from repeating unless they're associated with the
following commands:

  IDC_FIND_NEXT
  IDC_FIND_PREVIOUS
  IDC_FOCUS_NEXT_PANE
  IDC_FOCUS_PREVIOUS_PANE
  IDC_MOVE_TAB_NEXT
  IDC_MOVE_TAB_PREVIOUS
  IDC_SELECT_NEXT_TAB
  IDC_SELECT_PREVIOUS_TAB

BUG=626154
TEST=Ctrl-Tab still repeats but Ctrl-t doesn't
==========

to

==========
Make most browser accelerators not repeat.

Prevent browser accelerators from repeating unless they're associated with the
following commands:

  IDC_FIND_NEXT
  IDC_FIND_PREVIOUS
  IDC_FOCUS_NEXT_PANE
  IDC_FOCUS_PREVIOUS_PANE
  IDC_MOVE_TAB_NEXT
  IDC_MOVE_TAB_PREVIOUS
  IDC_SELECT_NEXT_TAB
  IDC_SELECT_PREVIOUS_TAB

BUG=626154
TEST=Ctrl-Tab still repeats but Ctrl-t doesn't
==========

[Peter Kasting, 2016-08-20 03:03:59]

pkasting@chromium.org changed reviewers:
- pkasting@chromium.org

[Peter Kasting, 2016-08-20 03:04:16]

Removing self from review (see comments on bug)

[Daniel Erat, 2016-08-31 22:18:10]

derat@chromium.org changed reviewers:
+ estade@chromium.org

[Daniel Erat, 2016-08-31 22:18:10]

scott and evan, we had some more discussion of this over email (subject "Is the
default repeat rate too fast on chromeos?"). what are your current feelings? i
can ask on the email thread instead if that's better. :-)

ainslie@ supports making this change on all platforms. i'm okay with just doing
it on chrome os. (i think it's the right thing to do everywhere, but i
understand arguments about consistency with existing conventions on a given OS.)

[Daniel Erat, 2016-08-31 22:20:15]

The CQ bit was checked by derat@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 22:20:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 22:24:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 22:24:10]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Evan Stade, 2016-08-31 22:30:08]

On 2016/08/31 22:18:10, Daniel Erat wrote:
> scott and evan, we had some more discussion of this over email (subject "Is
the
> default repeat rate too fast on chromeos?"). what are your current feelings? i
> can ask on the email thread instead if that's better. :-)
> 
> ainslie@ supports making this change on all platforms. i'm okay with just
doing
> it on chrome os. (i think it's the right thing to do everywhere, but i
> understand arguments about consistency with existing conventions on a given
OS.)

I'm personally in favor of this change. I can't think of a reason you'd want to
hold down Ctrl+T on purpose, and if you did it by mistake you could probably
slow your computer to a crawl. Holding down delete or some other shortcuts might
also do bad things if you did it by mistake, but at least there's a use case for
doing it on purpose. If there's some use case we haven't thought of, I suspect
our users will let us know on the bug tracker.

[sky, 2016-08-31 23:46:24]

https://codereview.chromium.org/2128243003/diff/1/chrome/browser/ui/views/acc...
File chrome/browser/ui/views/accelerator_table.cc (right):

https://codereview.chromium.org/2128243003/diff/1/chrome/browser/ui/views/acc...
chrome/browser/ui/views/accelerator_table.cc:284: return
std::vector<int>(kRepeatableCommandIds,
Can this be a set?

[sky, 2016-08-31 23:46:41]

On 2016/08/31 22:18:10, Daniel Erat wrote:
> scott and evan, we had some more discussion of this over email (subject "Is
the
> default repeat rate too fast on chromeos?"). what are your current feelings? i
> can ask on the email thread instead if that's better. :-)
> 
> ainslie@ supports making this change on all platforms. i'm okay with just
doing
> it on chrome os. (i think it's the right thing to do everywhere, but i
> understand arguments about consistency with existing conventions on a given
OS.)

If Alex says do it, we do it.

[Daniel Erat, 2016-09-01 16:48:30]

thanks, scott. i've merged and hopefully worked around some test issues due to
accelerator differences between platforms.

https://codereview.chromium.org/2128243003/diff/1/chrome/browser/ui/views/acc...
File chrome/browser/ui/views/accelerator_table.cc (right):

https://codereview.chromium.org/2128243003/diff/1/chrome/browser/ui/views/acc...
chrome/browser/ui/views/accelerator_table.cc:284: return
std::vector<int>(kRepeatableCommandIds,
On 2016/08/31 23:46:24, sky wrote:
> Can this be a set?

yep, looks like it can!

[Daniel Erat, 2016-09-01 16:51:39]

The CQ bit was checked by derat@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-01 16:51:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-01 17:55:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-01 17:55:52]

Dry run: This issue passed the CQ dry run.

[sky, 2016-09-01 19:31:06]

https://codereview.chromium.org/2128243003/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/browser_view.h (right):

https://codereview.chromium.org/2128243003/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/browser_view.h:666: std::set<int>
repeatable_command_ids_;
How often do we trigger accelerators, especially ones with a repeat? My
suspicion is it isn't worth caching this. WDYT?

[Daniel Erat, 2016-09-01 19:47:31]

https://codereview.chromium.org/2128243003/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/frame/browser_view.h (right):

https://codereview.chromium.org/2128243003/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/frame/browser_view.h:666: std::set<int>
repeatable_command_ids_;
On 2016/09/01 19:31:06, sky wrote:
> How often do we trigger accelerators, especially ones with a repeat? My
> suspicion is it isn't worth caching this. WDYT?

the local copy was initially due to mirroring the accelerator_table_ code. it
feels weird to initialize a new set every time we see a repeatable accelerator
(especially since these come in quickly if they're being repeated), but at the
same time, it's small and we're probably doing much bigger allocations for other
reasons.

i'd prefer to leave this, but i'll remove it if you really want me to. :-)

but one other option would be instead have an chrome::IsCommandRepeatable()
function be exposed by accelerator_table.h. it could just iterate through the
few entries in its local array every time it's called.

[sky, 2016-09-01 21:47:52]

Leave it then. LGTM

[sky, 2016-09-01 21:48:18]

I do like the IsCommandRepeatable option.

On Thu, Sep 1, 2016 at 12:47 PM,  <derat@chromium.org> wrote:
>
>
https://codereview.chromium.org/2128243003/diff/20001/chrome/browser/ui/views...
> File chrome/browser/ui/views/frame/browser_view.h (right):
>
>
https://codereview.chromium.org/2128243003/diff/20001/chrome/browser/ui/views...
> chrome/browser/ui/views/frame/browser_view.h:666: std::set<int>
> repeatable_command_ids_;
> On 2016/09/01 19:31:06, sky wrote:
>> How often do we trigger accelerators, especially ones with a repeat?
> My
>> suspicion is it isn't worth caching this. WDYT?
>
> the local copy was initially due to mirroring the accelerator_table_
> code. it feels weird to initialize a new set every time we see a
> repeatable accelerator (especially since these come in quickly if
> they're being repeated), but at the same time, it's small and we're
> probably doing much bigger allocations for other reasons.
>
> i'd prefer to leave this, but i'll remove it if you really want me to.
> :-)
>
> but one other option would be instead have an
> chrome::IsCommandRepeatable() function be exposed by
> accelerator_table.h. it could just iterate through the few entries in
> its local array every time it's called.
>
> https://codereview.chromium.org/2128243003/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Daniel Erat, 2016-09-02 00:05:08]

On 2016/09/01 21:48:18, sky wrote:
> I do like the IsCommandRepeatable option.

cool, i shall do that.

[Daniel Erat, 2016-09-02 00:29:54]

The CQ bit was checked by derat@chromium.org to run a CQ dry run

[Daniel Erat, 2016-09-02 00:30:11]

thanks, i've simplified this now.

[commit-bot: I haz the power, 2016-09-02 00:30:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-02 01:36:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-02 01:36:02]

Dry run: This issue passed the CQ dry run.

[sky, 2016-09-02 14:07:43]

Much better, thanks. LGTM

[Daniel Erat, 2016-09-07 16:42:22]

The CQ bit was checked by derat@chromium.org

[commit-bot: I haz the power, 2016-09-07 16:42:57]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-07 18:04:20]

Description was changed from

==========
Make most browser accelerators not repeat.

Prevent browser accelerators from repeating unless they're associated with the
following commands:

  IDC_FIND_NEXT
  IDC_FIND_PREVIOUS
  IDC_FOCUS_NEXT_PANE
  IDC_FOCUS_PREVIOUS_PANE
  IDC_MOVE_TAB_NEXT
  IDC_MOVE_TAB_PREVIOUS
  IDC_SELECT_NEXT_TAB
  IDC_SELECT_PREVIOUS_TAB

BUG=626154
TEST=Ctrl-Tab still repeats but Ctrl-t doesn't
==========

to

==========
Make most browser accelerators not repeat.

Prevent browser accelerators from repeating unless they're associated with the
following commands:

  IDC_FIND_NEXT
  IDC_FIND_PREVIOUS
  IDC_FOCUS_NEXT_PANE
  IDC_FOCUS_PREVIOUS_PANE
  IDC_MOVE_TAB_NEXT
  IDC_MOVE_TAB_PREVIOUS
  IDC_SELECT_NEXT_TAB
  IDC_SELECT_PREVIOUS_TAB

BUG=626154
TEST=Ctrl-Tab still repeats but Ctrl-t doesn't
==========

[commit-bot: I haz the power, 2016-09-07 18:04:21]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-09-07 18:07:04]

Description was changed from

==========
Make most browser accelerators not repeat.

Prevent browser accelerators from repeating unless they're associated with the
following commands:

  IDC_FIND_NEXT
  IDC_FIND_PREVIOUS
  IDC_FOCUS_NEXT_PANE
  IDC_FOCUS_PREVIOUS_PANE
  IDC_MOVE_TAB_NEXT
  IDC_MOVE_TAB_PREVIOUS
  IDC_SELECT_NEXT_TAB
  IDC_SELECT_PREVIOUS_TAB

BUG=626154
TEST=Ctrl-Tab still repeats but Ctrl-t doesn't
==========

to

==========
Make most browser accelerators not repeat.

Prevent browser accelerators from repeating unless they're associated with the
following commands:

  IDC_FIND_NEXT
  IDC_FIND_PREVIOUS
  IDC_FOCUS_NEXT_PANE
  IDC_FOCUS_PREVIOUS_PANE
  IDC_MOVE_TAB_NEXT
  IDC_MOVE_TAB_PREVIOUS
  IDC_SELECT_NEXT_TAB
  IDC_SELECT_PREVIOUS_TAB

BUG=626154
TEST=Ctrl-Tab still repeats but Ctrl-t doesn't

Committed: https://crrev.com/42d287c9658c6bfa1202275597f28399409e8603
Cr-Commit-Position: refs/heads/master@{#416995}
==========

[commit-bot: I haz the power, 2016-09-07 18:07:06]

Patchset 4 (id:??) landed as
https://crrev.com/42d287c9658c6bfa1202275597f28399409e8603
Cr-Commit-Position: refs/heads/master@{#416995}