Thank you for reporting this bug. We will make it our priority to review this report.
carat browsing of IE8 and GXT input widgets
carat browsing of IE8 and GXT input widgets
Since I cannot control if my users have caret browsing enabled or disabled on IE8, I would like it if the cursor position wouldn't flash within GXT non-text input components (i.e. button), as I attempt to show here.
Is there a way to get buttons to that the unselectable attribute is set on them?
Also, I have noticed the cursor position blink underneath a cell on a grid. It is as though the row has a higher z index and if I click close enough to the bottom of the row, I can get a cursor to blink.
I am working on a grid with read only cells and edit cells, so removing cursor position selection would be helpful. I'm not interested in disabling caret selection for the web page, since users should be able to cut and paste. I just want to stop/hide it in areas where it is confusing to the user.
We are also experiencing this problem.
It's easily demonstratable in the Explorer Demo. Tabbing through the Forms Examples (http://www.sencha.com/examples/#Exam...mple(uibinder)) are interesting. The cursor carrot ends up blinking behind the slider element, etc...
Is this a verified bug that's being worked on?
Does anyone have a workaround to get rid of the cursor carrot systematically?
User base is getting more and more confused/annoyed with the cursor that isn't a cursor...
At times a user will select a text field and the "carot" cursor will start blinking and they cannot type. The cursor is a little more to the left than the actual cursor.
When this happens, user expects to type, but cannot.
I'm looking more into this accessibility feature, but it seems so far that this is how the browser is intended to work, despite what it does to pages that required text input from the user.
As an example, if I am at a StackOverflow page (say, http://stackoverflow.com/questions/1...-from-websites, to pick an example at random) and enable caret browsing, if I use the arrow keys to move into the search text box, I am not able to type once I am in there.
Google search turns out to be a poor example - they have it wired so that a keystroke anywhere on the page, caret browsing or no, resulting is appending to the search text box - but if you enable caret browsing, and use it to enter the text box with already entered text, typing new characters appends to the end instead of where the cursor was.
Next: http://en.wikipedia.org/wiki/Main_Page - I can again navigate into the search text boxes, but am totally unable to enter text if I use the caret browsing to get there.
One more quick example: Bing search - roughly the same as stackoverflow.
All of this testing was initially done in Firefox 15, but I'm getting similar results in IE8 - the cursor just gets stuck on wikipedia, stackoverflow gets that same blink right at the left edge of the textbox (but if I hit the tab key I can enter it - same also seems to work on http://sencha.com/examples), and google gets keystrokes always appended to the end of the box, even when the cursor is elsewhere. On Bing, I am not even able to get the cursor into the text box without tab, or using the mouse.
If you have an example of a page that works correctly by these criteria (and I selected those pages deliberately to try to go after ones that should work across the board) with behavior you'd like your app to emulate, I might be able to either suggest a way to handle all events in your app, or look into a change in the library itself. But so far, GXT 2 and 3 seem consistent in IE8 and FF15 as many other popular web sites that should be conforming to accessibility requirements.
I agree this is complex and affects other web sites.
To take one of your examples, http://en.wikipedia.org/wiki/Main_Page, I don't see how as a user I can click on the text box and cause the caret cursor to show and give the appearance there is a cursor when there indeed isn't.
So, I see there is a couple of issues with caret browsing 1) navigation and 2) false appearance of input.
So, my initial example of text within the "Submit" button is frustrating, the issue that is more apparent to us is the second example. This shows up in even more odd ways with the grids.
Here is the closest behavior I could mimic with wiki. Any while this annoys me, at least it is more obvious not a cursor in the text box than I hve see with GXT.
I am sure this is something we have to live with, due to issues with IE. I was just hoping you had some way/idea of how to disable caret browsing for a given page.
In Firefox I can get this:
The cursor is even inside the search field, but I still can't type to do anything. In IE8 I can't get this effect on the wikipedia page, but on stackoverflow I get this:
It is something I'll keep looking at, but if any kind of mitigation comes at the cost of breaking browser accessibility features, it can't become part of the library.
I appreciate you looking into this as well. I guess I know why it happens to me more with GXT than other web sites, since I have to develop for IE8, but for all my personal use, I use a better browser (i.e. Chrome).
I think the design of the grids also lead to this happening more easily, since the widgets are overlaid on top of other HTML when selected. That seems to be the area where users see it the most (and complain about it).