621861 - s/observes=/command=/ where it applies, in comm-central

Status: NEW

(MailNews Core :: Backend, defect)

Comment 1

[:aceman]

How can I know where this applies?
What is the purpose of this cleanup?

Comment 2

[[e-mail]]

There are a number of XUL elements (buttons, keys, menuitems) that often share state. (In the case of menuitems, this can also include context menuitems.) To avoid having to update each element separately, there are two schemes that broadcast updates from a central element to the UI elements.

The first scheme is called the broadcaster/observer mechanism. You have (typically) a <broadcaster> element with an id, and then your UI elements use observes="id_of_broadcaster". This causes all attribute changes on the broadcaster to be propagated to all the UI elements that observe it.

The second scheme is the command mechanism. This scheme resembles the broadcaster scheme, except that the broadcasting element usually has a <command> tag and the observing element uses the command="cmd_id" attribute. For buttons this works nearly the same as the broadcaster mechanism, except that the command event is despatched on the command element instead of the button. However for keys and menuitems the processing is markedly different. Keys don't broadcast anything, instead they check the disabled attribute of the command element (NOT the key element). Menuitems also don't broadcast anything, but when their popup opens, a small list of attributes is automatically synchronised. (If the menuitem is never shown then its attributes are never updated.) In all cases the command element is required to have the oncommand attribute.

Since the command element is newer than the broadcaster element, many older windows may not have been updated to take advantage of it, in some cases because additional code changes are required, for example where event handlers incorrectly attempt to update the state on the UI element.