CloseWatcher constructor is unclear on what getEnabledState should be set to.

[keithamus]

What is the issue with the HTML Standard?

The establish a close watcher algorithm is "given" a window, a list of steps cancelAction, a list of steps closeAction, and an algorithm that returns a boolean getEnabledState.

Step 2 of new CloseWatcher(options) is:

Let closeWatcher be the result of establishing a close watcher given this's relevant global object, with:

1. cancelAction given canPreventClose being to return the result of firing an event named cancel at this, with the cancelable attribute initialized to canPreventClose.
2. closeAction being to fire an event named close at this.

At no point does this mention what the getEnabledState algorithm should be. It seems as though it should be an algorithm returning true?

/cc @domenic @mfreed7

[mfreed7]

That's like a function pointer that returns a boolean that is true if the close watcher should be enabled at any given point. It's called when closewatcher wants to start running things, and it's provided by e.g. the closedby code.

[annevk]

Yes, but it's not being supplied for new CloserWatcher() at the moment. @keithamus is politely pointing out that 8029d4f introduced a regression.

[keithamus]

I understand where I wasn't clear in my questioning.

At no point does this mention what the getEnabledState algorithm should be

Here I mean "the closewatcher construction steps do not define what the given getEnabledState is", leaving it open for interpretation if it is []() -> bool { return true; } or []() -> bool { return false; }