New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 122352 link

Starred by 48 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2014
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

"Tab" key in extension popup doesn't work, possibly Windows specific

Reported by, Apr 6 2012

Issue description

Chrome Version       : 18.0.1025.151
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :

What steps will reproduce the problem?
1. Install an extension which makes good use of the "Tab" keyboard shortcut to advance to next field. One example extension is "Passwordmaker Pro", available from:

2. Inside the extension (to the right of the address bar) click in the first password field, and enter a value.

3. Press the "Tab" key on the keyboard, to advance to the next password field.

What is the expected result?
The cursor should jump to the next password field, and allow data entry into the next field.

What happens instead?
The first field is de-selected, but the next field is not selected. Hitting "Tab" repeatedly still doesn't move selection to a new field or button.

Please provide any additional information below. Attach a screenshot if possible.

This used to work, but it's a long time ago. I cannot remember when this last worked, but I think it was around Chrome 15 Stable, or possibly Chrome 16 Stable.

The problem was present in Chrome 17 Stable, and as of today I can also confirm it doesn't work in 18 Stable (18.0.1025.151).

This _may_ be Windows specific. The user "bitboxer (Bodo Tasche)" on Github reports no problems on Mac OS X.

There are other extensions and people who report having the same issue:

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.151 Safari/535.19


Comment 1 by, Apr 7 2012

Sorry, I forgot to explicitly mention this in the title: This issue is for extensions, the Tab key doesn't work in extensions, but it does work elsewhere in the browser UI.

Second, while this issue may seem minor, it is *very* annoying. Very experienced Windows/computer users (such as yourself, dear reader!) have committed the "tab to reach next field" to muscle memory. It is one of the most common keyboard shortcuts, and thus it's very annoying that it doesn't work here.

Comment 2 by, Apr 25 2012

Bump! This is a genuine bug report -- please don't let it die.

Comment 3 by, Apr 26 2012

 Issue 120607  has been merged into this issue.

Comment 4 by, Apr 26 2012

Summary: "Tab" key in extension popup doesn't work, possibly Windows specific

Comment 5 by, Apr 26 2012

Labels: Action-FeedbackNeeded
After failure when hitting Tab key, click the mouse into the same or another field and try hitting Tab again.

Does hitting Tab change fields after that?

Comment 6 by, Apr 26 2012

Yes, that does work. If you click on the extension window, the tab key works as expected after that.

Comment 7 Deleted

Comment 8 by, Apr 26 2012

As best I can tell there are 2 separate situations, which could be different.

** Situation one, initial focus:

1) Click on the extensions (Password Maker's) icon next to the Address Bar.
2) The extension UI becomes visible, is in the foreground, and seems that it should have focus.
3) Press the TAB key. _It does not work_.
4) Manually click with the mouse on the extension UI, either into an input field, or just on the extension background.
6) Press the TAB key. _It now works correctly_.

I believe this is the same as reported in comment 6 above.

** Situation two, non-matching passwords in the Password Maker UI.
The Password Maker extension has 2 input fields for password, in order to verify that it's entered correctly. For this issue:
1) Click on the extensions (Password Maker's) icon next to the Address Bar.
2) The extension UI becomes visible.
3) Click with the mouse into the _second_ password field, and enter something
4) Click with the mouse into the _first_ password field, and enter a password that is different from the one in step 3.
5) Wait for a moment for the password backgrounds to turn red, and the text "Password Wrong" to appear in the bottom.
6) Press the TAB key. Notice that pressing TAB _removes_ focus from the current input field, but does not bring focus to a _new_ input field. Repeatedly pressing TAB after this doesn't do anything, i.e. TAB now doesn't work.

Labels: -Area-Undefined -Action-FeedbackNeeded Area-Internals Feature-Extensions
Status: Available
I am having this issue in an extension I author. The first 'tab' press won't move focus to the next input. But after you explicitly click another input with the mouse, 'tab' will start working again.

Comment 11 by Deleted ...@, May 24 2012

I am having the EXACT problem as on Comment 10 as well. There is also an issue with the focus() and autofocus, which I think that problem or THIS bug share a commmon issue. To fix the autofocus I had to use a hack I found so the autofocus would work:

if( !== "?foo") { = "?foo";
  throw new Error;  // load everything on the next page;
                    // stop execution on this page

However I have found it does NOT fix the Tab issue. Hope someone finds a legit fix for this issue. Makes us authors look like we don't know what we are doing. :-|

Comment 12 by, May 28 2012


Comment 13 by, May 28 2012

 Issue 114248  has been merged into this issue.
Hi all,
I am also having the same problem. The tab key navigation simply sucks in chrome extension. I am testing it against 21.0.1145.0 developer release. I also checked my extension against version 19.0.1084.52 which is presumably the stable version but the problem appears with this version too. Any hopes that this problem could be solved by chrome team or any workarounds developers have come up with?

Comment 15 by, Jun 17 2012

Same problem here. Focus does not move to second element after pressing tab on the first. I would say this is a major UI bug for those of us who like to navigate with the keyboard.

Comment 16 by, Jun 17 2012

I also think this could be tagged as a major UI bug for windows users.  

Comment 17 by Deleted ...@, Jun 25 2012

I'm also facing this problem. Works fine in linux. No fix for this yet?? :(
 Issue 137662  has been merged into this issue.

Comment 19 by Deleted ...@, Aug 14 2012

Agree with Comment #16. The bug only appears on windows. My extensions's popup works perfectly on OS X. not quite sure about Linux though.

Summary: 2 major bugs when opening ext popup on Windows.
1. Does not focus the popup page when clicking on the ext. icon.
   - the <script type="text/javascript" async="" src="whatever.js"></script> 
     or the = "?foo" workaround both works to gain the popup focus.

2. However, with the workaround, tab index are messed up. Upon popup shows, the 1st element got focused. when hitting the tab-key, focus to the page is lost entirely.

Comment 20 by, Oct 9 2012

Some more information on this.

Even if you explicitly set focus to an entryfield, the tab doesn't work.

If you add a keyup event listener to that entryfield, the tab key event doesn't even come to the entry field (but typing doesn't work).

So the first tab press is simply getting eaten somehow.

Comment 21 by Deleted ...@, Nov 8 2012

Someone fix this @_@
Don't let this bug get burried... it's so annoying!

Comment 23 by, Nov 9 2012

Not only annoying, it is actually breaking a feature of an extension... please fix :|
i also just waiting for this bug to be fixed before i publish my extension.

Comment 25 Deleted

Please fix this it kills usability in Chrome extensions we publish.

Comment 27 by, Dec 14 2012

Consider this for the Hotlist-Fixit-Dec-2012 ?

Labels: Hotlist-Fixit-Dec-2012
Status: Assigned
I think issue 1 from comment 8 (initial focus is broken) is actually a PasswordMaker Pro bug. If you load the extension's popup.html in a tab, it has the same issue. But if you remove all the <script> and <style> tags, the issue is fixed (both in a tab and in the popup).

 Issue 2  does seem to be a bug with the popup only. (Load it in a tab and it works.)
Project Member

Comment 30 by, Dec 19 2012

The following revision refers to this bug:

r173932 | | 2012-12-19T16:40:27.288652Z

Changed paths:

Fix bug where extension popups would not properly receive input focus when
first shown.

BUG= 122352

Review URL:
Status: Fixed

Comment 32 by, Jan 11 2013

This is not fixed in Chrome 24.0.1312.52 on Windows 7. At least not for the PasswordMaker Pro extension. The first password field gets the focus but the Tab key still does not work until you click the mouse in the extension popup somewhere.

Perhaps the fix went into v25, but the bug tracker software does not give us that information.
That's right, this fix didn't make it into M24. It'll be fixed in M25.

Comment 34 by, Jan 11 2013

I'm running the latest dev build (Version 25.0.1364.29 dev-m) and it still has the same problem.

Has it not been merged into 25 yet?
26.0.1408.1 (Official Build 181614) canary
Works great! Don't worry, guys! Hope fix will be available in the stable version soon.
Project Member

Comment 36 by, Mar 10 2013

Labels: -Area-Internals -Feature-Extensions Cr-Internals Cr-Platform-Extensions
Project Member

Comment 37 by, Mar 14 2013

The following revision refers to this bug:

r188114 | | 2013-03-14T17:32:46.898690Z

Changed paths:

Revert 173932 "Fix bug where extension popups would not properly..."
It breaks popup sizing with threaded compositing enabled.

> Fix bug where extension popups would not properly receive input focus when
> first shown.
> BUG= 122352 
> Review URL:

BUG= 181559
Review URL:
Project Member

Comment 38 by, Mar 14 2013

Labels: merge-merged-1410
The following revision refers to this bug:

r188152 | | 2013-03-14T18:58:28.986105Z

Changed paths:

Merge 188114 "Revert 173932 "Fix bug where extension popups woul..."

> Revert 173932 "Fix bug where extension popups would not properly..."
> It breaks popup sizing with threaded compositing enabled.
> > Fix bug where extension popups would not properly receive input focus when
> > first shown.
> > 
> > BUG= 122352 
> >
> > 
> > Review URL:
> BUG= 181559 
> Review URL:
Review URL:
Had to revert because it breaks with threaded compositing enabled. Reopening.
Status: Assigned

Comment 41 by Deleted ...@, Apr 6 2013

I've tested this with the Wrapper Bot Chrome extension.

I opened the popup, clicked a text area and pressed tab.

The focus does not shift to other input elements.

Conclusion... bug still not fixed in version 26.0.1410.43 m.
Yes, the fix was reverted, so this bug is back. I'm working on an alternate fix.

Comment 43 by, May 22 2013

Any updates on this bug?

Comment 44 by Deleted ...@, Jun 10 2013

This bug is driving me insane...please fix.

Comment 45 by Deleted ...@, Jul 5 2013

I am also experiencing this issue in version 27.0.1453.116 m.

Has anyone at least found some sort of temporary workaround?

The popup does not even detect the initial 'tab' keydown which causes the form to lose focus, so I am not sure how to resolve this.

Comment 46 by Deleted ...@, Jul 5 2013

Are there any updates regarding this bug? I've tried to make a temporary work-around with onkeyup listeners, but detecting the TAB key on all browsers and different OSs (Win, Mac) are problematic.

Comment 47 by, Jul 24 2013

Bug still exists in 29.0.1547.76 m

I have an extension with a login/password box and it's a bit frustrating to people when they hit tab to switch to the password box and end up typing part of their password in the login box.

Comment 49 by Deleted ...@, Oct 17 2013

Bug still exists in:

Google Chrome	30.0.1599.69 (Официальная сборка 226629) m
ОС	        Windows 
Blink	        537.36 (@158213)
JavaScript	V8

Status: Available
I'm mass-declaring bug bankruptcy on extensions bugs. Unassigning myself as owner.
Owner: ----
Seems to be fixed in Version 32.0.1700.76 m. It finally worked for me for the first time.


Agreed, works for me now as well (Windows 7 x64). Thanks!
Status: WontFix
Excellent. Thanks for the report.
Hey! Why "WontFix", not "Resolved"? ;D
32.0.1700.76, Windows 7 x65 - works fine.
WontFix here means there's nothing to fix. It is fixed already.

To mark it as Fixed we'd want a record of what was done to fix it, so we can track. But we didn't do anything as part of this bug.

If it makes a difference we can mark this as a duplicate of another bug that has the record, but I doubt it is worth the effort to go hunt for that every single time.
Thanks for explanation,, funnur.
Do you know anything about how and where the bug was fixed?
Nope. If I did I would have had a bug number and would have marked it as duplicate. :)

Comment 59 by, Jan 24 2014

I'd guess that switching to Aura "fixed" it by virtue of completely replacing the UI rendering code. :)

Sign in to add a comment