Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The timing of "deactivate an EditContext" when HTMLElement.editContext is replaced with another one or null #75

Open
masayuki-nakano opened this issue Oct 13, 2023 · 3 comments
Labels
needs-spec-edits Issue was resolved but spec needs to be updated

Comments

@masayuki-nakano
Copy link

https://w3c.github.io/edit-context/#extensions-to-the-htmlelement-interface

In the list:

  1. If oldEditContext is not null, then:
    4.1 Assert: oldEditContext's associated element is equal to this.
    4.2 Set oldEditContext's associated element to null.
  2. Set this's internal [[EditContext]] slot to be editContext.
  3. If oldEditContext is not null and oldEditContext is this's node document's active EditContext, then run the steps to deactivate an EditContext with oldEditContext.

I think that the Step.6 should be between Step 4.1 and 4.2 because it's odd and may be error prune if it happens after disassociated from an element.

@johanneswilm johanneswilm transferred this issue from w3c/editing Oct 13, 2023
@dandclark
Copy link
Contributor

It is a good point that firing compositionend after the EditContexts are switched could be confusing.

If we make this change though, I would propose that step 6 be moved even earlier, before step 2.3. After 2.3 things are in an inconsistent state because we've changed the EditContext's associated element but not yet updated the Element's [[EditContext]] internal slot, so we shouldn't fire compositionend and run page author JS at that time.

@dandclark dandclark added the Agenda+ Queue this item for discussion at the next WG meeting label Dec 12, 2023
@masayuki-nakano
Copy link
Author

@dandclark

If we make this change though, I would propose that step 6 be moved even earlier, before step 2.3

Yeah, sounds reasonable!

@dandclark
Copy link
Contributor

We resolved during today's Editing WG call to do this reordering.

[08:56] next: #75
[08:57] dandclark: as the spec is written now, if you have an EC that's being composed in and you disconnect it, we fire compositionend on the disembodied EC
[08:57] proposal: reverse these steps so that we fire compositionEnd before the EC is disconnected
[08:57] q+
[08:58] whsieh: would this allow script to reconnect an EC in the middle of disconnecting?
[08:59] dandclark: should make sure this edge case is not ambiguous
[08:59] sanketj_: do any of the known users of EC use compositionEnd
[09:00] dandclark: Google Docs, maybe?
[09:00] johanneswilm: follow masayuki's proposal, check edge case of reentrant EC reconnect

@dandclark dandclark added the needs-spec-edits Issue was resolved but spec needs to be updated label Jan 11, 2024
@johanneswilm johanneswilm removed the Agenda+ Queue this item for discussion at the next WG meeting label Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-spec-edits Issue was resolved but spec needs to be updated
Projects
None yet
Development

No branches or pull requests

3 participants