Vista doesn't use a new method to identify text boxes (although standard
text boxes now get the benefit of Text Services Framework which provides an
enhanced TIP experience). The problem is that the text boxes in Firefox and
many other cross-platform applications aren't truly text boxes. Just looking
like a text box and acting like a text box isn't enough if it doesn't
identify itself as one to the system.
But the fact remains that the input panel shouldn't care whether or not the
input focus is on a text box because it needs to be able to work with
non-standard text boxes and other non-textbox controls (such as the command
prompt). For example, there's nothing stopping me from writing a program
that handles text input on a button and then give focus to that button and
use the input panel to send text to it. Wouldn't be logical, but the input
panel doesn't make assumptions about that.
You can verify this by clicking Start -> Run then tab over to the Cancel
button so it has the focus. Then pop open the input panel and you'll see you
can write in it and click insert. You just get a beep cause cancel button
doesn't handle text input, but the point is, input isn't disabled.
I don't know enough about the accessibility API's to give you an answer you
could take back to Firefox but while it'd be great for them to do things the
right way, they won't. At least not until the next version where supposedly
they promised to play nicer with the host OS since right now it's a pretty
bad least common denominator between OSX and Windows and that's not really
benefitting users of either platform. But I believe the answer lies
somewhere in IAccessible.get_AccRole which has an enumeration value of
ROLE_SYSTEM_TEXT for text boxes.
--
Josh Einstein (Tablet PC MVP)
Einstein Technologies
Tablet Enhancements for Outlook - Try it free:
www.tabletoutlook.com
"Dave P" <> wrote in message
news:BE389E2A-00FB-4F2E-9AAC-...
> In reply to both of you.
>
> "Josh Einstein" wrote:
>> I have a suggestion but
>> it's a bit off the wall. Go into the input panel options and on the
>> advanced tab change the password slider all the way to low. Maybe the TIP
>> is getting confused in its detection of password boxes?
>
> I already had the slider on low.
>
> "Chris H" <> wrote:
>> No, that's not what I meant. The cursor before the TIP opens should be
>> in a text input area, otherwise it has no where to send the conversion.
>
> The cursor was in a text input area before and after I opened the TIP.
>
> HOWEVER, I think it is something to do with the cursor. In IE7 the TIP
> worked fine until I loaded a new page. While a page is connecting (with a
> blank window below the tab and the cursor not in one of the toolbar
> fields) I
> get the same result - grayed out insert button. If I switch over to
> Firefox I
> get the grayed out button even when the cursor is in the toolbar fields.
>
> I am aware of the old issues with Firefox not properly interacting with
> Tablet XP such that the small TIP icon would not appear next to a text box
> but on my Tablet XP machine I can open and use the TIP without a problem.
> It
> seems to be something new with Vista.
>
> Also, as I said, killing the tabtip process and letting it restart solves
> the problem for a while. After I restarted it I tried switching between
> the
> Firefox URL text box and the Search text box (opening the TIP, entering
> text,
> and closing the TIP each time). It passes 16 times without a problem. I
> also
> tried using the TIP in IE and Firefox alternately and I haven't run into a
> problem yet.
>
> One other thing to note, it's not exclusive to Firefox. When I first
> encountered the problem I installed Opera and was running into the same
> issue
> there.
>
> I appreciate your help. Let me know if you have any more ideas or if there
> is anything I could try to narrow down the issue.
>
> Also, if Vista is using a new method to identify text boxes and you can
> describe it, I'd be glad to cross post it in the Firefox bug board.
Similar Threads
Linear Mode
