Closed Bug 1764739 Opened 2 years ago Closed 2 years ago

State change event not fired when document designMode is turned off

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1764500

People

(Reporter: Jamie, Unassigned)

References

(Blocks 1 open bug)

Details

When designMode is turned on for a document, we fire a state change for the editable state. When designMode is turned off, we don't fire an event. This isn't a huge problem without CTW, but when CTW is enabled, it means the document remains "stuck" as editable when it isn't any more. I think turning off designMode is probably pretty rare, but this is still not great.

While there is obs_documentWillBeDestroyed, that doesn't ever seem to get fired... and even if it did, I suspect we wouldn't be able to use it because the editor wouldn't be destroyed yet, so we wouldn't know if it was being fired for the document or some descendant.

Some notes from Matrix on how we might be able to do this:

there's a NotifyDocumentWillBeDestroyed (https://searchfox.org/mozilla-central/source/editor/nsIDocumentStateListener.idl#21), but it's a bit complicated to get (you need the nsIEditor)
if you want to be notified once for designMode being turned off, then getting the nsIEditor from the docshell and registering a nsIDocumentStateListener and using NotifyDocumentWillBeDestroyed should work
Alternatively:
You can probably notify from Document::EditingStateChanged or so

Another possibility to check: we probably get a notification via nsIDocumentObserver::ContentStateChanged for NS_EVENT_STATE_READWRITE on the body/root element.

See Also: → 386027
Blocks: eventa11y

I'm going to handle this in bug 1764500, since there are other reasons we need to change the type of notification we use.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.