`writingsuggestions` might need to default to "off" about html HOT 15 OPEN

But it's likely that the feature relies on some not-upstreamed Edge-only backend, as the relevant CLs (1, 2) don't really add any functionality related to the attribute. So maybe Edge Canary is the way to go for testing this.

That's right -- Edge Canary is the thing to test with here.

For clarity, there are two things being discussed in this thread that are related but not the same:

• The writingsuggestions attribute, newly standardized and shipping in Chrome and Edge 124. This can be used by authors as a signal to browsers to turn off any browser-native writing suggestions features that the platform may have implemented. The details of these writing suggestions features are left up to browsers. Chrome/Chromium does not currently implement any such feature, so writingsuggestions is effectively a no-op there for the time being.
• The Edge text prediction feature. This has already existed in Edge for a while, but going forward web authors will be able to turn it off selectively with the writingsuggestions attribute.

from html.

Ok, cool. We can try out Edge.

Just to be clear, the compat/interop issues around what event(s) get fired from this feature when the user hits “tab” (or otherwise accepts a suggestion). It’s not related to the what predictive text gets suggested by different engines.

We totally need to align on the events and spec something.

from html.

Hey @marcoscaceres! Would you be able to provide some more details on the issues you've hit on those sites and their underlying cause(s)?

from html.

For example with the form in https://www.reddit.com/submit
We can start typing a text. "I want to celebrate by dancing."

The current result in the WebKit implementation is:
"I want to cecelebrate by dancdancing"

This doesn't happen on all sites. For example, here currently on the Github form, this is working quite well. But it is breaking on some sites.

from html.

For example with the form in https://www.reddit.com/submit We can start typing a text. "I want to celebrate by dancing."

The current result in the WebKit implementation is: "I want to cecelebrate by dancdancing"

Curious to learn more about how you ended up in this state? Would you be able to share more details about your order of operations?

@marcoscaceres mentioned composition events...are you saying the reason Webkit's implementation of this feature is broken on Reddit is related to composition events?

from html.

@sanketj, we will follow up with fuller details later today.

from html.

In the case of Reddit’s submit page, either compositionend or beforeinput ‘s .data is being concatenated to the current text content of the input <span>.

In WebKit, let’s say we type “predicta” and the browser suggests “predictable”, and we hit the tab key, we fire the following events in this order:

On Reddit, this results in “predicapredictable ”. Because the code if minified, we are unsure which of compositionend or beforeinput ‘s .data is being appended, resulting in the wrong text.

@sanketj, could you please try the following code in Edge and let us know the event order that you are using (or any additional events you are firing)?

<textarea rows="10" cols="150"></textarea>

<script>
    const textarea = document.querySelector('textarea');
    // Let's monitor the composition events
    window.addEventListener('compositionstart', (event) => {
        console.log('compositionstart', event);
    });
    window.addEventListener('compositionupdate', (event) => {
        console.log('compositionupdate', event);
    });
    window.addEventListener('compositionend', (event) => {
        console.log('compositionend', event);
    });
    // before input?
    textarea.addEventListener('beforeinput', (event) => {
        console.log('beforeinput', event);
    });
</script>

We would be super interested in hearing if Reddit’s submit page is working for you without issues.

from html.

(Alternatively, is this feature shipping in some Edge or Chromium build where we could try it?)

from html.

The feature was enabled in Chrome 124, so should be available in Chrome Canary, at the very least.

from html.

@yoavweiss, do you know if maybe this is not enabled on Mac platforms? We can't get it to work (i.e., we are not seeing any predictions) on regular text areas 😢

from html.

It shouldn't be AFAICT.
But it's likely that the feature relies on some not-upstreamed Edge-only backend, as the relevant CLs (1, 2) don't really add any functionality related to the attribute. So maybe Edge Canary is the way to go for testing this.

from html.

@sanketj, could you please try the following code in Edge and let us know the event order that you are using (or any additional events you are firing)?

<textarea rows="10" cols="150"></textarea>

<script>
    const textarea = document.querySelector('textarea');
    // Let's monitor the composition events
    window.addEventListener('compositionstart', (event) => {
        console.log('compositionstart', event);
    });
    window.addEventListener('compositionupdate', (event) => {
        console.log('compositionupdate', event);
    });
    window.addEventListener('compositionend', (event) => {
        console.log('compositionend', event);
    });
    // before input?
    textarea.addEventListener('beforeinput', (event) => {
        console.log('beforeinput', event);
    });
</script>

With Edge's text prediction feature, no composition/input events are fired for the text prediction until it is accepted by the user (ie. the user hits "Tab"). Once the prediction is accepted, the beforeInput (with insertText as the type), compositionStart, compositionEnd events are all fired, in that order. If Safari matches this behavior, do you see fewer compat issues? As @dandclark mentions, you can also try this out in Edge yourself. Note that the writingsuggestions attribute will only work in newer versions.

There was a change that we made to the input events spec to specify that accepted writing suggestions should fire the beforeInput event with insertReplacementText as the type. This has yet to be implemented though.

We would be super interested in hearing if Reddit’s submit page is working for you without issues.

It looks like Edge text predictions are not working on Reddit too. We'll dig in and get back to you on if this is due to a compat issue or just a browser or site bug.

cc: @siliu1 @stephanieyzhang

from html.

Right, @sanketj, but it seems it's not web compatible. You are right that we will see "fewer compat issues" issues, but in Edge Reddit is also broken (as you pointed out):

Hitting tab does not work on Reddit☝️ the suggestion gets swallowed.

from html.

Right, @sanketj, but it seems it's not web compatible. You are right that we will see "fewer compat issues" issues, but in Edge Reddit is also broken (as you pointed out):

IMG_1754.MOV
Hitting tab does not work on Reddit☝️ the suggestion gets swallowed.

That is definitely a bug, thanks for helping us find it! We'll look into fixing it. Overall, we're open to finding the right set/order of events that all text prediction implementations (or "inline writing suggestions" should we call them?) should follow.

I will note that accepting predictive text and inserting that into the DOM is not a new pattern. IME methods like software keyboards offer predictive text too (see image below) and those have been working on the web for a long time, so I'm quite hopeful this can be implemented in a web compatible way.

What do you think about following precedent set by software keyboards?

from html.

We totally agree that there is nothing super new here... we admittedly made some (unspecified) assumptions on our side about how to implement this, that we are trying to rectify.

And yes, the interaction between this and pop-over suggestions is a challenge too:

And yes, it seems we need composition events for anyone doing off-screen contenteditable, which I think is what Google Docs does.

So yes, we are not doing anything super new here - totally agree with you there.

That is definitely a bug, thanks for helping us find it! We'll look into fixing it.

Ok, please get back to us. Please also note all the other sites we listed above. They might also be buggy in Edge too. We will continue to refine what we are doing on the WebKit side to get this as web compatible as possible.

The core question is still how much breakage are we willing to tolerate? We can agree, as implementers, that it's (Reddit's comment form) a site bug - but it's probably going to break a ton of sites that are using similar react components... or it might not?

That's what we'd like to reach consensus on. If we can tolerate breakage like we see on Reddit, then we can leave this on... but otherwise, we might either need to consider switching this off or coming up with an alternative.

from html.