MozType not dynamically updated

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
12 years ago
11 months ago

People

(Reporter: jhp (no longer active), Assigned: Allan Beaufour)

Tracking

({fixed1.8.0.5, fixed1.8.1})

Trunk
fixed1.8.0.5, fixed1.8.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

2.35 KB, application/xhtml+xml
Details
2.21 KB, application/xhtml+xml
Details
1.84 KB, patch
Doron Rosenberg (IBM)
: review+
Details | Diff | Splinter Review
(Reporter)

Description

12 years ago
Allan can describe this better, but I'll give it a shot.

Currently, MozType attribute is set in |nsXFormsDelegateStub::Refresh()|, but
this is not good enough for elements that have CSS rules depending on MozType. 
Example coming up.
(Reporter)

Comment 1

12 years ago
Created attachment 200379 [details]
testcase

This is a modified testcase from the upload bug 275453.  When it is first
loaded, it defaults to "anyURI" as the type of the bound node, so this selects
the "upload[mozType|type="http://www.w3.org/2001/XMLSchema#anyURI"]" CSS rule,
which in turn binds to the functional "xformswidget-upload".

If you then select "none" from the dropdown, this should select the default
"upload" CSS rule, which binds to "xformswidget-upload-disabled".  But this
doesn't happen immediately.  You first have to do something to cause the model
to refresh, at which point the buttons of the upload element will be disabled,
since the "xformswidget-upload-disabled" binding is now being used.
(Assignee)

Comment 2

12 years ago
Quick thoughts: nsXFormsMDGEngine::SetNodeValue() should check if it sets the
value of @xsi:type, and inform the model to refresh the parent of the attribute.
Or directly set the type attribute on the parent.
(Assignee)

Comment 3

11 years ago
Created attachment 218701 [details]
testcase (non-upload)
(Assignee)

Updated

11 years ago
Assignee: aaronr → xforms
(Assignee)

Comment 4

11 years ago
(In reply to comment #2)
> Quick thoughts: nsXFormsMDGEngine::SetNodeValue() should check if it sets the
> value of @xsi:type, and inform the model to refresh the parent of the attribute.
> Or directly set the type attribute on the parent.

Second thought: Kind of hacky, and involves a lot of checks for each recalculate step. Instead nsIXFormsControl::dependencies should return @xsi:type as a dependency (if it exists).
(Assignee)

Comment 5

11 years ago
Created attachment 223762 [details] [diff] [review]
Patch

Adds @xsi:type as a dependency if it is present on the bound node of a control. That triggers a rebind and rebuild. The rebind is not strictly necessary, but a newly bound control might assume that it gets both a Bind() and a Refresh().
Assignee: xforms → allan
Status: NEW → ASSIGNED
Attachment #223762 - Flags: review?(Olli.Pettay)

Comment 6

11 years ago
Comment on attachment 223762 [details] [diff] [review]
Patch

Changes to nsXFormsControlStubBase::ProcessNodeBind aren't related to this bug.
Without those, r=me
Attachment #223762 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 7

11 years ago
Created attachment 223763 [details] [diff] [review]
Patch v2
Attachment #223762 - Attachment is obsolete: true
Attachment #223763 - Flags: review?(doronr)

Updated

11 years ago
Attachment #223763 - Flags: review?(doronr) → review+
(Assignee)

Comment 8

11 years ago
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
(Assignee)

Updated

11 years ago
Keywords: fixed1.8.0.5
(Assignee)

Updated

11 years ago
Keywords: fixed1.8.1
(Assignee)

Updated

11 years ago
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.