State change event not fired when document designMode is turned off
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
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
|
Reporter | |
Comment 1•3 years ago
|
||
Another possibility to check: we probably get a notification via nsIDocumentObserver::ContentStateChanged for NS_EVENT_STATE_READWRITE on the body/root element.
|
|
Reporter | |
Comment 2•2 years ago
|
||
I'm going to handle this in bug 1764500, since there are other reasons we need to change the type of notification we use.
Description
•