Closed Bug 280312 Opened 20 years ago Closed 20 years ago

Submit button should disable until submit done

Categories

(Core Graveyard :: XForms, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aaronr, Assigned: smaug)

References

()

Details

Attachments

(1 file, 1 obsolete file)

According to 8.1.9 in the spec, "Upon activation, this control must become unavailable for further activations until the submit process concludes with either an xforms-submit-done or xforms-submit-error event." If you go to the URL in the URL field, you'll see that we do not behave accordingly.
Assignee: aaronr → smaug
Status: NEW → ASSIGNED
Attached patch v1 (obsolete) — Splinter Review
I'm not happy adding two interfaces for this small feature. Comments?
One suggestion would be to, rather than setting the attributes on the button from the submission element, the submission element could dispatch an event to the submit element to enable/disable it (xforms-enable/xforms-disable). It is handled in nsXFormsControlStub::HandleDefault and will set or remove the attribute for you . That should alleviate your need for nsIXFormsSubmitElement interface and keep submit element in nsXFormsTriggerElement.cpp. I don't see anyway around having the sumission remember the submit element, though. Nothing short of implementing some kind of 'handle' system and pass the submit element's 'handle' in the contextinfo of the submit event, at least. Like a hash. But that is a lot of overhead for such a simple thing :=)
No, xforms-enable/disable can't be used for this: "This event is dispatched whenever the value of the bound instance data node changes, additionally whenever the bound instance data node becomes enabled indirectly, through the relevant model item property evaluating to true."
Simple way around that is to create a private event that does the same thing, then. You made a good point in that since enable/disable don't exactly reflect whether the button is enabled or disabled but more a reflection of the instance data, then we really shouldn't use the same properties that xforms-enable and xforms-disable use. A form author would see his button reflecting the styles he assigned to a disabled button, but not have his handler called and wonder why.
Comment on attachment 173203 [details] [diff] [review] v1 > Simple way around that is to create a private event that does the same thing, then. Or just use this patch ;)
Attachment #173203 - Flags: review?(aaronr)
I have a question: Should our goal here be to act visually equivalent to the behavior that the user would see if the submit button had become disabled via changes to bound instance data? If that is the goal, then this patch might show differences to the user since it sets @disabled to "disabled" instead of "1" like the MDG would set it. Also, this patch doesn't remove @enabled when it adds @disabled. Otherwise the patch looks great.
Attachment #173203 - Flags: review?(aaronr)
Attached patch v.1.0.1Splinter Review
Only change is that I don't set the disabled attribute of the button element, but just use the DOM interface to set it disabled. Note, this |disabled| is not the same thing as the xforms-disabled. MDG sets the disabled attribute of the xf:submit element, this patch sets the disabled state of the DOMHTMLButton element.
Attachment #173203 - Attachment is obsolete: true
Attachment #174137 - Flags: review?(aaronr)
Attachment #174137 - Flags: review?(aaronr) → review+
Comment on attachment 174137 [details] [diff] [review] v.1.0.1 >+++ nsXFormsSubmissionElement.cpp 12 Feb 2005 12:28:55 -0000 ... >+ // If the submission is already active, do nothing. >+ if (!mSubmissionActive && NS_FAILED(Submit())) { The comment is a bit cryptic. // Submit if submission not active already, otherwise do nothing ? I'm not too happy about the need for two interfaces either... if it is possible to retrieve the sending party of an event, you could check the sender and find the "activator" through that? That would save the submission-interface. r=!gAbovePossible || (gAbovePossible && patch.mWithThatChanged) :)
> r=!gAbovePossible || (gAbovePossible && patch.mWithThatChanged) Through other channels smaug informed me that gAbovePossible is PR_FALSE :) Checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: