Bug 67426 - Implement TextEvent.inputMethod
Summary: Implement TextEvent.inputMethod
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: UI Events (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: http://www.w3.org/TR/DOM-Level-3-Even...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-01 12:37 PDT by Eli Grey (:sephr)
Modified: 2024-03-21 01:45 PDT (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eli Grey (:sephr) 2011-09-01 12:37:02 PDT
TextEvent.inputMethod is needed to discern the method of input used to triggered a textInput event.
Comment 1 Alexey Proskuryakov 2011-09-01 12:58:59 PDT
Is there a specific use case for this?

I think that this API is poorly designed, and would prefer that we don't implement it. For example, what should the inputMethod property be equal to when typing with Mac OS X U.S. keyboard layout? It sometimes works indistinguishably from IME (specifically, when using press-and-hold to type accented characters on Lion).
Comment 2 Ryosuke Niwa 2011-09-01 13:12:39 PDT
I think inputMethod is a poor property name as well. the name input method is normally referred to text input assisting software such as Microsoft IME, Kotoeri, and ATOK.
Comment 3 Eli Grey (:sephr) 2011-09-01 13:17:46 PDT
(In reply to comment #1)
> Is there a specific use case for this?

I don't really think anyone cares if something comes from a keyboard, but some of the other ones (paste, voice, handwriting) could make sense in a webapp. I agree that it is poorly designed though. Ideally, it would be a list of methods used to output the text (also dropping the IME method, since they're all IMEs anyways) instead of this. Given that, inputMethod is still sufficient enough right now for webapp dev, and could be changed in a later spec.
Comment 4 Leandro Graciá Gil 2011-09-02 02:54:47 PDT
Should we implement inputMethod now then? I have no strong opinion about this.

This comes from bug 60451, but it would be also possible to solve the event firing part of it without adding an inputMethod attribute to text events. In fact, speech input has already an onwebkitspeechchange event that also provides alternative result candidates with their confidence.
Comment 5 Alexey Proskuryakov 2011-09-02 08:56:25 PDT
I think that we shouldn't implement this.
Comment 6 Ryosuke Niwa 2011-09-02 10:02:00 PDT
(In reply to comment #5)
> I think that we shouldn't implement this.

I would have agreed given the seemingly poor name and values, but now I realize that this is a part of DOM level 3: http://www.w3.org/TR/DOM-Level-3-Events/#events-TextEvent
Comment 7 Ryosuke Niwa 2011-09-02 10:30:09 PDT
Okay, I did some research on this and apparently neither Firefox nor Opera supports textinput event. Given that I see little to no benefit in implementing this property, which is really hard to implement correctly in WebKit.
Comment 8 Leandro Graciá Gil 2011-09-02 10:40:09 PDT
(In reply to comment #7)
> Okay, I did some research on this and apparently neither Firefox nor Opera supports textinput event. Given that I see little to no benefit in implementing this property, which is really hard to implement correctly in WebKit.

The fact is that it's already there and working in Chromium. Try using addEventListener("textInput") with some <input type=text> element. However it looks like only the event itself is actually supported, not its inputMethod or locale attributes. Should we leave it as it is? Maybe add the event for the speech input case but ignore the inputMethod?
Comment 9 Ryosuke Niwa 2011-09-02 10:46:14 PDT
(In reply to comment #8)
> The fact is that it's already there and working in Chromium. Try using addEventListener("textInput") with some <input type=text> element.

We should consider dropping the support altogether given only Trident and WebKit support the event (I checked with Ehsan about Gecko's plan and he told me he doesn't know any plans to implement in Gecko), and there are alternatives such as input and beforeinput events.

>However it looks like only the event itself is actually supported, not its inputMethod or locale attributes. Should we leave it as it is? Maybe add the event for the speech input case but ignore the inputMethod?

That appears to be the plan to maintain the consistency although I'd argue that we should just kill the event.
Comment 10 Ryosuke Niwa 2011-09-02 11:01:11 PDT
Correction.  There IS a Mozilla but to implement textinput event and someone from Mozilla Japan is interested in fixing this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=622245.  So we may not be able to kill this event after all.  But let's see what Mozilla does before implementing this property in WebKit.
Comment 11 Ojan Vafai 2011-09-02 11:04:31 PDT
I fully support killing textInput and replacing it with beforeInput if we find we can do so without causing a compat issues. Certainly we should not further extend textInput and instead focus on implementing beforeInput and making it meet all the use-cases.

I feel less strongly about whether we should fire the event for speech input, but we don't need to implement inputMethod in order to do so.
Comment 12 Leandro Graciá Gil 2011-09-05 03:02:43 PDT
Thank you for your comments. I think probably the best option now is to fire the event for consistence with what it's already landed, but not to add any inputMethod or additional information to the TextEvents until it's clear what to do about them.

If anyone has other suggestions or reasons for not doing this please don't hesitate to share them.
Comment 13 Ahmad Saleem 2024-02-17 06:07:09 PST
If I am not mistaken, it got dropped:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=12958

TextEvent is not in spec.

Should we create separate new bug to get rid of 'TextEvent'?
Comment 14 Karl Dubost 2024-03-21 01:45:05 PDT
Yes This is probably irrelevant and should be closed.