[Webkit-unassigned] [Bug 60170] [Chromium] Speech-enabled input fields need the ability to trigger without a click

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jun 17 16:50:22 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=60170





--- Comment #13 from Dominic Mazzoni <dmazzoni at google.com>  2011-06-17 16:50:22 PST ---
> --- Comment #10 from Satish Sampath <satish at chromium.org>  2011-06-16 04:09:39 PST ---
> onToggle doesn't seem like the right name for this function. It doesn't toggle between 2 states but moves the state from idle to recording and recording to waiting states. I would suggest moving the code under each case statement to separate functions and add a new toggleSpeechInputState() function which actually moves between Idle and Recording states. I think you'd want a pending recognition session to be cancelled and a new one started if this toggleSpeechInputState() function was called when state == Recognizing.

I'm happy with using toggleSpeechInputState, but I don't want to
change the behavior of what happens when you cancel while already in
the recognition stage - that'd affect clicks as well. The goal is
simply to abstract what happens when you click now so that the "click"
could be triggered by a keypress instead - I don't think there's
anything wrong with the current behavior, which is to start recording
the first click, and stop recording the second click (but not cancel
recognition).

If you want different behavior for the second click, let's save that
for another change.

Or, if the current behavior is fine, maybe toggleSpeechInputState
isn't the right name for the method. How about startOrStopSpeechInput?

> Darin Fisher (:fishd, Google) <fishd at chromium.org> changed:
>> Source/WebKit/chromium/public/WebInputElement.h:80
>> +        WEBKIT_API bool isSpeechEnabled() const;
>
> it looks like toggleSpeechRecognition and isSpeechEnabled are related methods, but
> they do not use the same terms.  if isSpeechEnabled is supposed to return true

isSpeechEnabled means, "does this input element have the
x-webkit-speech attribute, meaning that speech input is allowed?"

toggleSpeechRecognition means, "for an input that has speech input
enabled, start recognizing if it's not already, or stop recognizing if
you've already started." It doesn't change the result of
isSpeechEnabled - that's controlled by the DOM element's attribute.

My proposed change: isSpeechInputEnabled and startOrStopSpeechInput.

(We could provide startSpeechInput and stopSpeechInput also, if we
think they'd be needed or useful. However, a startOrStopSpeechInput is
still needed because when the user triggers speech input by an action
in the browser process, whether by a key, context menu, etc. it
doesn't make sense to send one round-trip to the renderer process to
determine the current state, then flip the state in another RPC, with
a possible race condition. Having a startOrStopSpeechInput method
exactly mimics the user behavior when they click on the microphone
icon, which is what we want.

- Dominic

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list