View Full Version : Preventing the 'tabindex=-1" setting for DataView panels

7 Mar 2014, 8:11 AM
One of the issues I have with the DataView in Ext JS 4 running in Chrome is whenever I click in the view, a blue border appears around the panel. I tracked this down and figured out that this happens because the wrapper div for the component contains a 'tabindex="-1"' attribute, something like this:

<div class="x-component x-component-default x-border-box" id="dataview-1009" tabindex="-1" style="">

I found that if I use the Chrome developer tool to remove the tabindex attribute, I no longer get a blue box around the panel when I click inside. What I haven't been able to figure out is how to prevent this attribute from being generated in the first place. Any help in solving this would be greatly appreciated.



7 Mar 2014, 8:27 AM
Can you provide a small test case that displays this? We have several reports, but most are caused by outside css causing the focus border as this is not implemented by default.

You can create a test case using our fiddle:

7 Mar 2014, 8:31 AM
Your KitchenSink demo application behaves this way (look at the DataView sample), as does the sample code for DataView in your online documentation - http://docs.sencha.com/extjs/4.2.1/#!/api/Ext.view.View. The code snippet I included in my original post actually came from the code generated from the DataView documentation page. If you run either of these in Chrome and click in the DataView, you should see a blue border around the panel. If you edit the code to remove the tabindex=-1, the blue border will not show when you click in the panel.


9 Mar 2014, 2:14 AM
I'm not able to reproduce this using Chrome 33.0.1750.146 or

I am able to force it to happen by removing the default ExtJS CSS:

.x-webkit *:focus {
outline: none !important;

On Windows removing that rule gives a blue outline.

To follow my steps you'll need to force the element for have the :focus pseudo (there's a menu for that at the top of the Styles section).

11 Mar 2014, 6:15 AM
Interesting. I'm running Chrome 33.0.1750.146 m on Windows 7. When I go to the Sencha site http://docs.sencha.com/extjs/4.2.1/#!/api/Ext.view.View, run the Live Preview for the data, and then click inside of the data view, I see a blue box. This is consistent with the way my Ext JS application behaves as well (also the DataView sample of the Sencha Kitchen sink). However, when I run Chrome on my Mac, I do not see this behavior. I wonder if I have some sort of 'accessibility' setting turned on in my Windows Chrome which causes this to happen. To show you that I'm not completely crazy, here is a sample screen shot of what I see when I click in the DataView panel for the Sencha documentation page:


The driving factor is definitely the inclusion of the tabindex attribute (possibly combined with some Chrome preference that I'm unaware of). If I just use the following simple HTML in Chrome I get a blue box when I click in 'Box 1', but not when I click in 'Box 2'.

<div style="width: 200px;height: 200px;background-color: #efefef" tabindex="-1">Box 1</div>
<div style="width: 200px;height: 200px;background-color: #ddd" background-color="#DDD">Box 2</div>

Even if the box is the result of some Chrome preference, in my application I would prefer to not have the blue box appear ever for certain of my data views. Maybe I just need to make sure that my CSS really has the x-webkit setting you've identified.



11 Mar 2014, 6:38 AM
After some more experimentation, I've found that the only way that I can get rid of the blue box without eliminating the tabindex attribute is to use a 'style: {outline:none}' when I define my dataview. I've tried using CSS and my browser doesn't seem to want to respond to it. I used my simple HTML example (posted earlier) and played with various style sheet settings and the only thing that worked for me was to put the outline:none directly in the style attribute of the div itself. That isn't a terrible solution because I'm not using the style config value for anything else, but I wish I knew why my version of Chrome was being difficult about this setting.

Big thanks to skirtle for identifying the key CSS attribute. I was using the Chrome developer tool and I couldn't figure out which attribute was making this happen.