Closed
Bug 280312
Opened 20 years ago
Closed 20 years ago
Submit button should disable until submit done
Categories
(Core Graveyard :: XForms, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: aaronr, Assigned: smaug)
References
()
Details
Attachments
(1 file, 1 obsolete file)
17.45 KB,
patch
|
aaronr
:
review+
|
Details | Diff | Splinter Review |
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 | ||
Updated•20 years ago
|
Assignee: aaronr → smaug
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•20 years ago
|
||
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 :=)
Assignee | ||
Comment 3•20 years ago
|
||
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.
Assignee | ||
Comment 5•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Attachment #173203 -
Flags: review?(aaronr)
Assignee | ||
Comment 7•20 years ago
|
||
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 8•20 years ago
|
||
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)
:)
Comment 9•20 years ago
|
||
> 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
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•