Submit button should disable until submit done

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
13 years ago
10 months ago

People

(Reporter: aaronr, Assigned: smaug)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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

13 years ago
Assignee: aaronr → smaug
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 1

13 years ago
Created attachment 173203 [details] [diff] [review]
v1

I'm not happy adding two interfaces for this small feature.
Comments?
(Reporter)

Comment 2

13 years ago
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

13 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."
(Reporter)

Comment 4

13 years ago
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

13 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)
(Reporter)

Comment 6

12 years ago
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

12 years ago
Attachment #173203 - Flags: review?(aaronr)
(Assignee)

Comment 7

12 years ago
Created attachment 174137 [details] [diff] [review]
v.1.0.1

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)
(Reporter)

Updated

12 years ago
Attachment #174137 - Flags: review?(aaronr) → review+

Comment 8

12 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

12 years ago
> r=!gAbovePossible || (gAbovePossible && patch.mWithThatChanged)

Through other channels smaug informed me that gAbovePossible is PR_FALSE :)

Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.