Issue 102177 in chromium: Tabindex / focus issue
chro...@googlecode.com
Owner: ----
Labels: Feature-ChromeFrame Type-Bug OS-Windows Pri-2
New issue 102177 by wiegert....@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
ChromeFrame version: 15.0.874.106 (Official Build 107270)
Related URL(s): (internal app...but test page that proved it out attached)
Steps to reproduce the issue:
1. Create a form with multiple fields
2. Programmatically set the tabindex on them from 1...<number of fields>
3. When on the page, hit tab and focus stays on first field
What do you expect to happen?
I expect focus to go from field that has tabindex=1 to field with tabindex=2
What do you see instead?
Focus stays on the tabindex=1 field the first time you hit tab and then
after that its OK.
This sounds trivial, but in my order entry app, it is a complex form what
needed to be setup with explicit tab stops. And users are keying in data in
the first field, hitting tab, beginning to enter data for next field and
overwriting the first field. Very annoying.
Another issue with this: You can start somewhere else on the form
(tabindex=2), and then key in data and hit tab, and then the focus goes
onto the tabindex=1 field. Its as if chrome frame always wants to go to
tabindex=1 first, instead of the next field in the tab sequence
Attachments:
cfTest.html 689 bytes
chro...@googlecode.com
Comment #1 on issue 102177 by wiegert....@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
FYI -
Code was working fine prior to 15.0.874.106 chrome frame auto update.
Works fine in Chrome 15.0.874.106
chro...@googlecode.com
Comment #2 on issue 102177 by blakebis...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
There is no apparent activity on this ticket. When will this be triaged
and, more importantly, fixed?
chro...@googlecode.com
Comment #3 on issue 102177 by blakebis...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
The workaround is to use the <body onload=""> event to set the focus,
rather than jQuery. The attached file runs for me on IE8/GCF. Note that I
also added a <form> element.
Attachments:
testtab.html 483 bytes
chro...@googlecode.com
Comment #5 on issue 102177 by christhi...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
This is a major blocker for our product as well. Users are sent to a form
element at the top of long forms the first time they press "tab".
It seems to me that there must be a variable for "current tab index" that
is not being updated until the tab key is physically pressed in GCF. Once
the tab key is pressed ONCE, the tab index is handled correctly via the tab
key, via focus events, and via mouse clicks.
If you navigate to a new page, the behavior resets (and the first tab press
always focuses the first element). If you enter a new URL in the address
bar, the behavior also resets. I have been unable to work around the
problem by simulating a tab press by dispatching a KeyboardEvent (it is
very possible I am dispatching the event incorrectly).
However, if the registry key "HandleTopLevelRequests" is set to 0, the GCF
behavior changes slightly. Navigation between links does no longer resets
the behavior. Entering a new URL in the address bar still resets the
behavior. Thus, it seems this behavior occurs any time a "top level
request" is handed off to IE, then back to GCF.
chro...@googlecode.com
Comment #8 on issue 102177 by wiegert....@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
I took a similar approach to blakebis (although much more brute force). My
app was already tracking the id of the last input that had focus, so I had
that id available to me. I added a textbox and styled it didn't have a
border and it blended in to the screen. I gave it the first tabindex and
gave it a focus handler. In the focus handler I had a pretty big
if..then.else block that set checked the last field id that had focus and
then set focus to the next field in line after that. Its probably not %100
accurate, but it works for our purposes. I won't post the code out of fear
of embarrassment, but if anyone wants a snippet let me know :)
I think it will be issues like this that might force us to rethink chrome
frame (had one other issue before a couple of weeks before this). We have
a captive internal audience and can dictate what browsers we want to
support. We may dictate Chrome in the future and abandon IE/GCF.
chro...@googlecode.com
Comment #9 on issue 102177 by ruipmari...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
I've had success by simply setting the first input with a tabindex=-1. W3C
defines negative values for tabindex as follows:
"If the value is a negative integer, the user agent must allow the element
to be focused, but should not allow the element to be reached using
sequential focus navigation.".
In practice, this means GCF will not consider the first input as part of
sequential navigation but, due to its current erratic behavior, it will
consider the next input field -- which is the input itself.
chro...@googlecode.com
Comment #12 on issue 102177 by kylejgin...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
The bug is insanely annoying. I found the GCF is a good step in the right
direction, but still not 100%. Here is our hacked up version.
https://raw.github.com/gist/2151586/1088a6de91872a88e3c372332d9cbe3e34ddca79/gcfTabBug.js
I'm about to pull the plug on chrome frame because this bug has caused so
much pain for so long.
chro...@googlecode.com
Comment #13 on issue 102177 by slick...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
This bug needs to be addressed or at least acknowledged by someone in the
development team.
chro...@googlecode.com
Comment #14 on issue 102177 by blakebis...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
Interestingly, I cannot reproduce this bug anymore.
Win7(64-bit)/IE9/GCF 18.0.1025.168
chro...@googlecode.com
Comment #15 on issue 102177 by rich...@r7development.com: Tabindex / focus
issue
http://code.google.com/p/chromium/issues/detail?id=102177
With Windows 7, IE 9, CF 18.0.1025.168 I'm also not seeing this issue
anymore either.
chro...@googlecode.com
Comment #16 on issue 102177 by david.bu...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
The problem still exists in Windows 7 (32 bit) , IE9, cf version
18.0.1025.168 (Official Build 134367). And yes it would be nice if someone
acknowledged this issue
chro...@googlecode.com
Comment #17 on issue 102177 by wiegert....@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
I guess I have given up on this issue. I did my pseudo workaround listed
earlier in the thread (comment 8)and it works. We are actually switching to
Chrome... I have a captive audience (internal users), and we are
recommending Chrome as the browser of choice. So we will allow users to
use GCF, but won't invest time and effort to address issues like this. If
it has too many issues, we will pull the plug and have just IE. People
will switch to Chrome pretty quickly if that happens as my app just doesn't
perform well in IE due to heavy client side javascript, jquery, and other
dynamic processing.
I am just curious if there is any way to escalate issues?
chro...@googlecode.com
Comment #18 on issue 102177 by kylejgin...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
Yesterday I had as many people as I know with gmail accounts (7) star this
issue thinking that might have something to do with it.
chro...@googlecode.com
Comment #21 on issue 102177 by sam.phil...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
In case folks are still running into this, I found an extension to the
approach from Comment 9. Setting the tab index on the initial field to -1
worked perfectly but had the drawback that you cannot tab to that field
(e.g. can't shift-tab to go back). I used jquery's blur functionality to
remove the tabindex hack after focus leaves that element. Here's a
snippet:
var removeTabIndexAfterBlurComplete = function() {
window.setTimeout(function() {
$theFirstInputFieldInYourForm.attr("tabindex",0);
},0);
};
$theFirstInputFieldInYourForm.focus().blur(removeTabIndexAfterBlurComplete);
chro...@googlecode.com
Comment #22 on issue 102177 by sihnst...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
Has there been any other workarounds for this issue? I am having the
tabindex issue using GCF 17 in IE7 in a Websphere Portlet Factory developed
site.
chro...@googlecode.com
Comment #23 on issue 102177 by nikhil.a...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
Does anyone know the version in which this issue is resolved?
chro...@googlecode.com
Comment #25 on issue 102177 by nikhil.a...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
Does that mean that the bug is no longer there in V22? Was there any code
update to fix the defect?
chro...@googlecode.com
Comment #26 on issue 102177 by blakebis...@gmail.com: Tabindex / focus issue
http://code.google.com/p/chromium/issues/detail?id=102177
All I know is that I cannot reproduce the bug since about V20. To answer
your question directly, I cannot reproduce it in V22. I have no idea if
code was checked in that resolves the issue because this ticket was never
actually addressed by the Chrome team. Perhaps they sneaked the fix in
somewhere without attaching the fix to a ticket.