166754 - Add support for inkwell handwriting recognition

Status: VERIFIED DUPLICATE of bug 165652

(Camino Graveyard :: OS Integration, enhancement, P5)

Description

[Joseph Delaney]

Mac OS X 10.2 "Jaguar" adds pen-based handwriting input. With most OS X software
it is possible to write directly into the document that you are working with.
Using Fizzila, you must use the "inkpad" - in intermediary tool that then pastes
the text into Mozilla.

Chimera works partially - you can write directly into the URL address bar, but
not into a textarea or text input on an html page.

Comment 1

[Jo Hermans]

Yep, confirmed (well, I don't have a Watcom here, but I know that it can't work
now).

That would be neat. The reason that we're not accepting input, is that the text
and textarea's are not real native widgets (but the URLbar in Chimera is). I'm
not too sure how easy it is to add this feature.

Comment 2

[Torben]

Changing component to Chimera since that is where this is asked for.

Comment 3

[Joseph Delaney]

Actually I was only mentioning that it already is partially supported in
Chimera. It would be excellent if Mozilla supported any input device, regardless
of what it was (keyboard or pen, or any of the devices designed for handicapped
accessibility), so I actually see this as going beyond a Mac-only handwriting
recognition issue. Why limit that only to Chimera?

Comment 4

[Greg K.]

Another bug dependent on native text fields?

Comment 5

[Simon Fraser [no longer active]]

To default owner (d'oh!)

Comment 6

[Greg K.]

*** Bug 177219 has been marked as a duplicate of this bug. ***

Comment 7

[Emilio Silva]

Using Inkwell will sometimes crash Chimera.  Maybe the severity should be higher?

If you start writing 'anywhere' when a non-native (or no) widget has focus, the
pad won't disappear (recognition won't occur).  I can work around that by
pressing Cmd-L, what moves focus to the location bar, which accepts some
recognized text.  But sometimes Chimera  will crash when that happens.

There is a note in the new Developer's documentation about Inkwell, that
may or may not be relevant:

"NSTextInput protocol

The InkWell text input service can ask you to return the content of your text
input client that extends to your document range; so the implementation for the
NSTextInputProtocol method, -attributedSubstringFromRange:, should be prepared
to get out-of-bounds range. In that case, you should return the intersection of
your document range and the range specified in the argument. If the location of
the range is completely out-of-bounds of your document range, you can return nil."

Command-xxx shortcuts entered using the ink toolbar do work.

Comment 8

[S Woodside]

Emilio: Since this bug is for the enhancement to work with inkwell, please file
that crash under a separate bug to at least not crash with inkwell.

Comment 9

[Simon Fraser [no longer active]]

I want to see that crash log.

Comment 10

[Greg K.]

See also Mozilla equivalent bug 165652.

Comment 11

[Emilio Silva]

Can't reproduce the crash mentioned in Comment #7, appears to be fixed on
Chimera 0.7 / OSX 10.2.4.

Bug <a href=http://bugzilla.mozilla.org/show_bug.cgi?id=177219>177219</a> (a
longer description of comment #7) still holds, and could be addressed before
having full support to handwriting.

Camino could be  made to behave as Netscape (7.02): ignore what you write, but
let the yellow pad disappear.

Comment 12

[Samuel Sidler (old account; do not CC)]

This is a definite enhancement and since the crash wasn't reproduced *2 years*
ago, I'm setting this for future and a priority of 5.

Comment 13

[Samuel Sidler (old account; do not CC)]

Is this at all dependent on the core accessibility bug? (Implementing accessibility stuff on OS X.)

Comment 14

[Stuart Morgan]

I don't see any reason that this would be Camino-specific, so duping to the core bug.