279516 - controls not initialized with MIP's

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[aaronr]

Changing instance values updates controls accordingly to reflect Model Item
Properties, but controls are not initialized with the MIP's.  During XForms
document initialization, all of the MIP's are given during
nsXFormsMDGEngine::Recalculate and will be distributed to controls during model
revalidation, but all of that happens before form controls are constructed and
bound.  Sounds like maybe we need to send xforms-recalculate to the models right
before or after xforms-ready?  Or look for a way for control to set its own
attributes during refresh?

Comment 1

[aaronr]

Attachment: testcase that shows the problem

in this testcaes, when the document is loaded, the pushbutton should either be
hidden or disabled (depending on how we handle relevant="false()").  Right now
it is fully visable and enabled.

Comment 2

[aaronr]

Whatever the solution ends up being, we need to keep in mind this note from
4.3.5 in the spec:

"Prior to the dispatching of the xforms-ready event handler, there are no form
controls bound to instance data, so xforms-valid and other notification events
are not dispatched."  So if we do a xforms-recalculate, it needs to be after
xforms-ready.  For what it is worth, fP does that (sends a recalc after ready).
 But Novell plugin doesn't send any event after xforms-ready and right now we
match that lead.

Comment 3

[Allan Beaufour]

Correct. Somewhat hidden, but I've had that as a todo for some time:
http://lxr.mozilla.org/seamonkey/source/extensions/xforms/nsXFormsModelElement.h#69

Comment 4

[Allan Beaufour]

Attachment: Patch

Fixes the problem (and a typo in nsXFormsNodeState)

Comment 5

[Allan Beaufour]

Attachment: Also removes obsolete todo comment

Forgot to remove todo comment

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 172876 [details] [diff] [review]
Also removes obsolete todo comment

Looks ok, but could you still make sure that the 
event target is right in nsXFormsControlStub::HandleDefault
Something like this:
  nsCOMPtr<nsIDOMEventTarget> target;
  aEvent->GetTarget(getter_AddRefs(target));
  nsCOMPtr<nsIDOMElement> te(do_QueryInterface(target));
  if (te && te != mElement) {
    *aHandled = PR_FALSE;
    return NS_OK;
  }

Or maybe there could a helper function
PRBool nsXFormsUtils::EqualsTarget(nsIDOMEvent* aEvent, nsIDOMNode* aNode);

Both are ok.
r=me

Comment 7

[Allan Beaufour]

Attachment: w/smaug's comments

Comment 8

[Allan Beaufour]

Comment on attachment 172899 [details] [diff] [review]
w/smaug's comments

New patch on the way, that fixes bug 280553 too.

Comment 9

[Allan Beaufour]

*** Bug 280553 has been marked as a duplicate of this bug. ***

Comment 10

[Allan Beaufour]

Attachment: Ahem, a refresh() too

1) The controls, logically, needed a refresh() too.

2) The initialization now happens between xforms-model-construct-done and
xforms-ready, which is more correct.

xforms-ready is still not standard-compliant though.

Comment 11

[Allan Beaufour]

*** Bug 280565 has been marked as a duplicate of this bug. ***

Comment 12

[Doron Rosenberg (IBM)]

*** Bug 280267 has been marked as a duplicate of this bug. ***

Comment 13

[Allan Beaufour]

sr, nice, but with the informations -- or rather lack of same -- coming from you
... should I check it in?

Comment 14

[Allan Beaufour]

:( some of the previous checks-ins break this....

Comment 15

[Allan Beaufour]

Attachment: Updated to current CVS

This one is up to date with CVS, and fixes a slip in bug 279957, where
ProcessBindElements() were called twice.

Comment 16

[Allan Beaufour]

The latest patch is check in ready, but you are not keeping me informed about
what to do about the beta.

Comment 17

[Doron Rosenberg (IBM)]

sorry for the miscommunication.  I just checked it in.

Comment 18

[aaronr]

Attachment: windows build fix

ConstructDone signature has a problem on Windows.  This will fix it.

Comment 19

[Brian Ryner (not reading)]

checked in the bustage fix.