Re: [clipboard] kill onbefore* events?

On Thu, Mar 10, 2016 at 10:50 AM, Hallvord Reiar Michaelsen Steen <
hsteen@mozilla.com> wrote:

> On Thu, Mar 10, 2016 at 4:23 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
> > Once I get back to work, I will start to program a version 5.0 of my
> editor
> > that handles the new eventtype correctly.
> >
> > Anyone still not having upgraded from version 4.35, the editor doesn't
> end
> > up doing crazy/uncontrolled stuff when receiving voice input. It simply
> does
> > nothing on voice input
>
> That's sort of the polar opposite of Gary's goal that new stuff should
> "just work" :)
>
> It also means that you do *not* consider it a goal of your spec
> development to make it easier to handle stuff the developer hasn't
> explicitly thought of - like IMEs, accessibility helpers and possible
> future input stuff - in a way that would have a chance of "just
> working"?


> I'd consider it a brilliant technological achievement if voice input
> fired key insertion beforeInput events (and potentially
> keydown/up/press - why not? /me <3 back compat :-p) and your app "just
> worked" with the new Apple device while you were scuba diving (and
> more importantly: on the 10 000 sites that never bothered updating to
> the new version of your JS lib at all).
>
>

The beforeInput inputType works no matter what the input device is
(different from keydown/up/press). So if a new input device can use the
existing inputTypes (for a new type of key input that works by letting the
camera read hand gestures), then it will indeed just "work" even though I
am still scuba-diving.

The problematic part comes up when new inputTypes were used -- the fact
that a new inputType was used indicates that the existing inputTypes
couldn't cover what was needed. A type of "voice control" may have very new
and different ways of trying to change existing text, where a new command
"ah... sorry, computer..." may mean to remove the last 3-4 words.

In the cases where a new inputType was used, in the editors that I know, I
think the JS developers would prefer to cancel those entirely until they
have tested them out. But if another JS editor developer is more confident
that his editor will be able to just handle it right, she could just let
the browser handle any inputType unknown to her code.


> Anyway - however much fun we can have imagining the future, this
> discussion is sort of off-topic when we're arguing whether to replace
> specialised paste and drop events with a general beforeInput
> eventType=paste and eventType=drop approach.
>
> Johannes also wrote:
>
> >> Easier to read because there's less if() branching and switch()
> >> statements.
>
> > You mean in the JavaScript code? Well, it will be maybe three-four event
> > more event handlers and then maybe 25 cases in the beforeInput/input
> event
> > handler.
>
> 25 cases is a lot :)
>
> >> Easier to debug because if you want to debug pasting, you ask your
> >> debugger to break on a paste event.
>
> > I assume you are here thinking of the debugging issues it gives in the
> > browser code. This I know nothing about.
>
> Not meant as boasting but just to explain where I'm seeing things
> from: I've been debugging random issues on random websites for the
> last 14 years or so, usually working on code I have not had the luxury
> of prior knowledge of, I've been dissecting heavily obfuscated code at
> least since GMail hit the web. 25+ cases inside one event handler
> inside an obfuscated script is hard. 25+cases inside a non-obfuscated
> script still means you might have to step over quite a few statements
> to get to the code you want to see running.
>
> > In the JS code I cannot see why this wouldn't be solveable by filtering
> > through the events with a switch and then just debugging the part of the
> > code that is executed for a specific action.
>
> Browser people who advocate for this solution should be tasked with
> creating a usable debugger UI for this :)
> Most debuggers already have UI for breaking on a specific event type.
> This is a solved problem. None have UI for creating conditional
> breakpoints on a specific event type AFAIK - not saying it can't be
> done, but it's harder.
>
> -Hallvord
>



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org