Added event onwebkitspeechchange and invoke on new speech input results.

• Component: Forms
• Status: RESOLVED FIXED

[Satish Sampath]

This patch adds the event 'webkitspeechchange' to the input element and attribute 'onwebkitspeechchange' to the input element IDL. Until now when receiving new speech input results, the input element's 'onchange' event handler was invoked. Instead of that we are now invoking the 'onwebkitspeechchange' handler. Also updated the relevant layout tests.

[Satish Sampath]

Created attachment 69711 [details]
Patch

Adding Kent Tamura as an additional reviewer as he is familiar with the input element.

[Jeremy Orlow]

Comment on attachment 69711 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=69711&action=review

r=me assuming you fix the nits

> WebCore/html/HTMLInputElement.cpp:1214
> +    } else if (attr->name() == onwebkitspeechchangeAttr) {

no {}s

> WebCore/html/HTMLInputElement.idl:104
> +#if !defined(LANGUAGE_OBJECTIVE_C) || !LANGUAGE_OBJECTIVE_C

Why do this?

[Kent Tamura]

(In reply to comment #2)

> > WebCore/html/HTMLInputElement.idl:104
> > +#if !defined(LANGUAGE_OBJECTIVE_C) || !LANGUAGE_OBJECTIVE_C
> 
> Why do this?

I have the same question.  I have no idea of reasons to omit it for Objective-C.

[Satish Sampath]

(In reply to comment #3)
> (In reply to comment #2)
> 
> > > WebCore/html/HTMLInputElement.idl:104
> > > +#if !defined(LANGUAGE_OBJECTIVE_C) || !LANGUAGE_OBJECTIVE_C
> > 
> > Why do this?
> 
> I have the same question.  I have no idea of reasons to omit it for Objective-C.

I don't know the reason, but I saw two prominent IDLs do it in this fashion (http://trac.webkit.org/browser/trunk/WebCore/dom/Element.idl#L139 and similarly in WebCore/dom/Document.idl) and hence followed that. But I also notice many other IDLs not use this ifdef guard, so I'll remove it now and if required in future will add.

[Satish Sampath]

Created attachment 69765 [details]
Patch

Patch with comments addressed, will submit.

[WebKit Review Bot]

Comment on attachment 69765 [details]
Patch

Rejecting patch 69765 from review queue.

[e-mail] does not have reviewer permissions according to http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/config/committers.py.

- If you do not have reviewer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags.

- If you have reviewer rights please correct the error in WebKitTools/Scripts/webkitpy/common/config/committers.py by adding yourself to the file (no review needed).  The commit-queue restarts itself every 2 hours.  After restart the commit-queue will correctly respect your reviewer rights.

[WebKit Commit Bot]

Comment on attachment 69765 [details]
Patch

Clearing flags on attachment: 69765

Committed r69100: <http://trac.webkit.org/changeset/69100>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Eric Seidel (no email)]

This is Android specific it seems. What spec covers this?

[Jeremy Orlow]

(In reply to comment #9)
> This is Android specific it seems. What spec covers this?

Satish works on Chromium (he has a chromium.org address :-)

The W3C Speech XG is where the standard development is happening.

[Jeremy Orlow]

(In reply to comment #10)
> (In reply to comment #9)
> > This is Android specific it seems. What spec covers this?
> 
> Satish works on Chromium (he has a chromium.org address :-)
> 
> The W3C Speech XG is where the standard development is happening.

If you're interested in this, you should look at the parent (blocks) bug...there's a lot of information in there.

[Jeremy Orlow]

(In reply to comment #10)
> (In reply to comment #9)
> > This is Android specific it seems. What spec covers this?
> 
> Satish works on Chromium (he has a chromium.org address :-)
> 
> The W3C Speech XG is where the standard development is happening.

If you're interested in this, you should look at the parent (blocks) bug...there's a lot of information in there.