20470 - need to be able to get command dispatcher from text control frame

Status: RESOLVED FIXED

(Core :: XUL, defect, P1)

Description

[buster]

talked to hyatt, discovered that we need a way for the text control frame to
tell the xul command dispatcher that something has changed, and "update
commands" needs to get called.  but I have no way of doing this today.

hyatt sez:  waterson is the man, submit a bug and have him talk to me about it.

so her ya go.

once this bug is fixed, I'll do the work in the text control frame.

Comment 1

[buster]

this will probably end up being a beta blocker.  without this, I can't fix
20471, which means some menu items will only enable/disable when focus changes,
instead of whenever the user interacts with the text control.

guessing M13, chris please change if that isn't right.  if you push this beyond
M14, also change 20471.  thanks.

Comment 2

[Chris Waterson]

talked to hyatt. he said we needed to add back the nsIDOMXULCommandDispatcher
attribute to nsIControllers. Is that correct? (If so, it's a no brainer: I'll
do it tomorrow...)

Comment 3

[buster]

yep, that's my understanding.  add the attribute back on, set up the code so the
getter gives me the command dispatcher object, and I'm happy.

Comment 4

[Chris Waterson]

damn buster, you're easy to please. i'll get on it.

Comment 5

[Chris Waterson]

Ok, this involved a bit more thinking that I thought it would. Just to verify
the ownership model here...

xul doc [1]===>[1] command dispatcher [1]--->[n] element
                           ^ [1]                   || [1]
                           |                       ||
                           |                       \/ [1]
                           +----------------[1] controllers
                                                   || [1]
                                                   ||
                                                   \/ [n]
                                                controller

Where double arrows indicate "strong ref" and single arrows indicate "weak
ref", and [1]-->[1] indicates "one-to-one" and [1]-->[n] indicates
"one-to-many".

Comment 6

[Chris Waterson]

Also, is there any reason that we need to make the "controllers" object
creatable through XPCOM? I'd just as soon use an internal interface to
construct the controllers object. Nobody is going to be creating controllers on
their own, are they?

Comment 7

[David Hyatt]

Correct.  Someone might also have a weak ref back to the command dispatcher or
controllers (or element) from the controller.

Comment 8

[David Hyatt]

Correct.  Nobody ever makes the controllers object, but remember that the HTML
input field (gkhtml) and the GlobalWindowImpl (in jsdom.dll) are making it, and
that's why I made it XPCOM.

Comment 9

[Chris Waterson]

ok, how about the CommandDispatcher object? will anyone outside of RDF.DLL ever
need to create one of those?

Comment 10

[David Hyatt]

Nope.

Comment 11

[Chris Waterson]

Attachment: proposed fix

Comment 12

[Chris Waterson]

Attachment: nsXULCommandDispatcher.h

Comment 13

[Chris Waterson]

Attachment: nsXULControllers.h

Comment 14

[Chris Waterson]

Fix attached: hyatt could you review?

. Generally gave nsXULCommandDispatcher.cpp and nsXULControllers.cpp some badly
needed love.

- Cleaned up some methods that weren't checking return codes
- Created private header files

. Got rid of nsIXULCommandDispatcher interface because it wasn't needed.

. Removed XULCommandDispatcher from RDF factory; cannot be created externally
now.

. Set the command dispatcher after creating the controllers object in
nsXULElement (XXX should we do this in GlobalWindowImpl, too?)

Comment 15

[David Hyatt]

Go nuts.

Comment 16

[Paul MacQuiddy]

Buster can verify if he wishes, I don't think claudius can