Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Here is a very SimpleTest test that demonstrates the problem. See comments in the code for details.
class DemonstrateDrupalPostErrorTestCase extends DrupalWebTestCase {
function getInfo() {
return array(
'name' => t('Demonstrate drupalPost form API error'),
'description' => t('Use to troubleshoot potential bug in drupalPost class'),
'group' => t('User')
);
}
function testChangeUserName() {
// Use this line if you want the test to fail.
$admin_user = $this->drupalCreateUser(array('administer users', 'administer permissions'));
// Use this line if you want the test to pass. Unlike the last line, there is no 'administer permissions'.
// $admin_user = $this->drupalCreateUser(array('administer users'));
$this->drupalLogin($admin_user);
$regular_user = $this->drupalCreateUser(array());
// We attempt to change the user's name here.
$edit['name'] = 'New name';
$this->drupalPost('user/' . $regular_user->uid . '/edit', $edit, t('Save'));
// This line spits out the results of the saved form. It displays "An illegal choice has been
// detected error" from form.inc when the role checkboxes are visible on the form (when the $admin_user
// has 'administer permissions' permission set)
file_put_contents('output.html', $this->drupalGetContent());
// Fails when $admin user has 'administer permissions' permission
$this->assertText(t('The changes have been saved.'), t('Successful save message displayed.'));
}
}
Comment | File | Size | Author |
---|---|---|---|
#89 | 335035-checkboxes-d7.patch | 576 bytes | andypost |
#83 | 335035-simpletest-no-submit-disabled.83.patch | 6.8 KB | effulgentsia |
#79 | 335035-simpletest-no-submit-disabled-D7.patch | 2.06 KB | Dave Reid |
#70 | 335035-disabled-controls.patch | 10.41 KB | boombatower |
#65 | 335035-disabled-controls.patch | 10.45 KB | boombatower |
Comments
Comment #1
Steve Dondley CreditAttribution: Steve Dondley commentedThis is what the $post variable looks like after handleForm()
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis issue is with the disabled checkbox. According to [1], disabled controls cannot be successful (ie. 'valid for submission').
[1] http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.12
Comment #3
chx CreditAttribution: chx commentedComment #4
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis brakes:
- Node edit
- Node preview
- Translation functionality
The "teaser_js" control (added by node_body_field()) is skipped by the new posting logic, while it is apparently needed for the test to succeed.
Comment #5
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe two first failures (Node *) are due to the tests assuming they are posted in javascript teaser mode... (silly)
The last failure is due to the logic of skipping disabled fields: we should not skip them if we have a value for them. We don't babysit that case: the value set by the code could be invalid.
Comment #6
chx CreditAttribution: chx commentedEven better! I was expecting the testing bot to run the tests and now it did and they passed.
Comment #7
Damien Tournoud CreditAttribution: Damien Tournoud commentedRerolled to remove some fuzz.
Comment #8
Dries CreditAttribution: Dries commentedCould you (i) make this a little bit more verbose and (ii) fix the typo (missing 'be' before 'required' -- I think). Thanks! :)
Comment #9
ksenzeeHere's a reroll with fleshed-out comments. Damien, let me know if the comments I added actually reflect what's going on in the code.
Comment #10
ksenzeeNew version attached, with comments revised per Damien in IRC.
Comment #11
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis is blocking #334671: Add tests for user role administration, so let's get this in.
Comment #12
Dries CreditAttribution: Dries commentedI can't make sense of these code comments. I jumped to the patch without reading this discussion. I think we need to work on better comments so they can be understood easily.
Comment #13
ksenzeeHmmm. What's going on here, basically, is that we're programming the internal browser not to follow spec. In real life, a disabled checkbox doesn't send a POST value. The patch in #2 makes the simpletest browser follow the spec. Unfortunately, it also breaks a bunch of tests. The change introduced in #5 makes the tests pass again by letting a disabled checkbox send a POST value if it's checked, and ignoring it if it doesn't.
I can write a paragraph full of comments to that effect, but I don't think that's the right answer. I think the right answer is to go back to the patch in #2 -- make the simpletest browser conform to the spec -- and fix the broken tests. Any test that counts on browser functionality that doesn't exist in the real world can't be very reliable. For example, I took a look at the broken translation test Damien mentions in #4. One of its helper functions depends on a certain POST value getting sent. I checked the actual POST values that Firefox sends when you submit that form, and that value isn't there.
Even worse, I'm running the tests right now, and I've got more tests failing than just the ones Damien mentioned in #4. We may have written tests since November that rely on this broken behavior. Blech.
Comment #14
Damien Tournoud CreditAttribution: Damien Tournoud commentedLet's try with this instead: we simply ignore disabled controls, both from $edit and $post.
Comment #15
Dries CreditAttribution: Dries commentedI agree with ksenzee in #13. Damien's patch in #14 seems to implement his suggestion. It would be great if ksenzee could review the patch in #14 and re-run against his setup as he reported some additional tests failing.
Comment #16
Dave ReidI need to look into this too. I ran into problems with tests on user/x/edit form coming back with 'Invalid choice detected' unless I provided a value for the disabled checkbox for the 'authenticated user' role in drupalPost().
Comment #17
ksenzeeThe patch in #14 fixes the tests that were failing for me. We still have tests that are setting disabled checkboxes, which now has absolutely no effect, so we probably need some documentation for test writers letting them know not to bother. But as far as this patch is concerned I think we're good to go.
Comment #18
Dries CreditAttribution: Dries commentedMaybe we should generate an exception when we detect unnecessary fields being set?
Comment #19
webchickCNW, per Dries's feedback.
Comment #20
boombatower CreditAttribution: boombatower commentedSubscribe.
/me has no time to write code for #18.
Comment #21
BerdirThere should be imho a possibility to "force" disabled fields to be sent. Maybe if explicitly selecting a disabled field, it should still be sent ? (I haven't looked at the code yet how it exactly works).
I'm asking because I'm currently writing a test for #91663: Permission of text format is not checked when editing an entity and instead reset to something a user can use.. My patch is going to display the unchangeable field as a disabled textfield. I am writing a test to make sure that the content can't simply be overwritten, because a user could do things he isn't allowed to that way if that would work. I can't write such a test if simpletest ignores the disabled fields.
Comment #22
ksenzee@Berdir: The thing is, it's not just Simpletest that ignores the disabled fields. Real browsers ignore them as well. In your case, I believe that if you apply your patch, submit the node form, and examine the POST request (using TamperData in Firefox, or whatever), you'll see that the disabled fields aren't even in the POST. We'd be writing behavior into Drupal that would never be triggered by a real live user, only by Simpletest.
I'm guessing that what you're looking for is a way to ensure that a user can't just hack the HTML, enable the #edit-body field, and then submit the form. FAPI should prevent that from happening, and we ought to be able to write a FAPI test for that behavior (for all I know, there's already such a test). I don't think that making the Simpletest browser uncompliant with the W3 spec is the right way to handle the question. But I agree it needs to be addressed. #91663: Permission of text format is not checked when editing an entity and instead reset to something a user can use. is a royal pain.
@boombatower: I could theoretically write code for #18 if I knew what I was doing. I may pester you for help in IRC.
Comment #23
ksenzeeI discussed this with boombatower in IRC and we came to the conclusion that at some point -- at least in a FAPI test -- we'll have to be able to simulate the user hacking the "disabled" attribute out of the HTML and submitting the form. But this behavior is clearly non-standard, and the test writer should have to specify that that's what they want. Otherwise you'll get test writers that set a value on a disabled field and expect it to go through, not understanding that a real browser wouldn't send the value. That's why the original patch broke translation.test (#4).
So boombatower proposed the following:
drupalPost('url', $edit, submit, TRUE)
. I actually wonder if we shouldn't do something likedrupalPost('url', $edit, submit, array('simulate_hack' => TRUE))
.Comments? Objections?
Comment #24
BerdirSounds fine to me. I would suggest using array('submit_disabled') or something similiar which is easier to understand and there might other configurable non-standard behaviors at a later point.
Comment #25
boombatower CreditAttribution: boombatower commentedI think having a settings array is probably best and Berdirs suggestion seems the most logical.
We may want to merge the last three parameters into the $settings parameter.
Comment #26
BerdirYou can use the following to merge the defaults:
Comment #27
Dave ReidInstead of adding a parameter and code that will not be used for 99% of tests, maybe we should 'duplicate' the drupalPost code for this disabled field test instead. Let's ask ourselves how this feature is going to be reused. If it's not, why should it be in DrupalWebTestCase?
Comment #28
boombatower CreditAttribution: boombatower commented#26: I was just using sudo code, otherwise yes.
#27: If we merge the last three parameters into one it won't have so many parameters. I'm not a big fan of duplicate code.
Comment #29
BerdirHm, I thought about merging the parameters too, I'm not sure, because merging $options with $settings would mean to merge url() and drupalPost() specific options. That is probably confusing from a DX perspective.
Another way would be to ignore disabled fields unless a value for these is explicitly specified. For example, a input field named "my_disabled_field" with disabled="disabled" is only sent when $edit['my_disabled_field'] exists. This would eliminate the need for another setting variable but again, it is probably confusing for a developer writing tests.
Comment #30
boombatower CreditAttribution: boombatower commentedWe discussed that, but we would rather it throw an error if you do that since it is normally invalid.
We can merge the last two as they are SimpleTest specific.
Comment #31
David_Rothstein CreditAttribution: David_Rothstein commentedThis might be slightly out of scope, but relevant in response to Dave Reid's comment in #27:
Why limit this to disabled fields only?
In addition to disabled fields, there are plenty of other ways someone might try to hack a site by sending things that the browser normally wouldn't send (e.g., they can try to choose an option in a select list that is not one of the allowed choices). It would definitely be a good thing if it were possible to write tests that simulated these kinds of attacks.
At Acquia, we (and by "we" I actually mean "Barry Jaspan" in this case!) wrote some code a while back to do this in a general way. Sheepishly, the code is for Drupal 5 so might be totally useless, but I'm posting it here in case it's inspirational :) The basic idea in the function below is that you use the $additional parameter to post form values that the browser normally wouldn't send (but otherwise, $edit and $additional have the exact same syntax). I think adding a parameter like this to drupalPost() in D7 might be the right way to go here.
Comment #32
BerdirOh, I like $additional. Easy to understand & implement, flexible and cleanly seperated from the valid data ($edit).
Comment #33
boombatower CreditAttribution: boombatower commentedLets add $additional then as a parameter to drupalPost(). Before or after $headers? I'm kinda thinking before as it would match the idea behind $options for url().
Otherwise I like the idea as it allows for a number of special cases. So then add the check for disabled fields and the message as described above, but after processing all values add on the $additional values before making cURL request.
Comment #34
Dave ReidAn $additional parameter sounds good. Looking at the current definition:
Hmm... could we maybe just wrap one $options array? Our 'special' keys/values will be ignored when passed into url(), so the only thing to look out for is name collision with the current url() parameters. I think the simplicity would be worth it.
Comment #35
Berdir@34
We don't need 'submit_disabled' anymore if we use $additional. And, because $additional could contain anything, I don't think it's a good idea to merge them, we would need to explicitly remove all possible url() params from that, or they would be sent as POST data. ($additional will be sent directly as key=value POST data, no validation from SimpleTest is done, so that we can manually force anything we want and don't need anything handled specially)
Comment #36
boombatower CreditAttribution: boombatower commentedI agree with #34, but possible we can just do a key like 'url_options' and put everything that is passed to url() in there. I think that is simpler to code and clearer.
Comment #37
Dave Reid@35-Berdir:
In that case we could have:
Easy as that.
Comment #38
BerdirOk, attaching a first patch.
I used the format Dave Reid proposed in #37.
It seems that no test is currently using either $headers nor $options so there are not changes necessary except of the "broken" tests in node.module.
Comment #39
BerdirForgot to update the status
Comment #41
BerdirHm, it seems the Translation test always enables a specific language. However, when there is only one language (=English), it does now create a failure because the enabled checkbox is disabled. Well, atleast that seems to work correctly :)
Updated the Translation tests to check if the enabled checkbox is not already checked.
Comment #42
boombatower CreditAttribution: boombatower commentedShouldn't:
be
Also I wrote a test for this:
Interestingly the first time I submit the page for the disabled field I get the expected error message from SimpleTest. The second time the value is submitted and the FormAPI saves it. I would expect the form API to ignore the value. Is that a bug? Would seem like.
I went ahead and changed the test to reflect the form API's behavior, but through my test "test" (heh) it shows the added functionality for disabled fields works.
Attached patch also has corrected message.
Comment #43
boombatower CreditAttribution: boombatower commentedBased on http://api.drupal.org/api/file/developer/topics/forms_api_reference.html... :
It seems the #disabled is merely a theme property. I'm thinking we should change it to actually ignore submitted values as it would seem unclear and provide a somewhat odd DX.
Comment #44
Dave ReidWhat should happen in the case that I add #disabled = TRUE to my form element, but then have a JavaScript that will un-disable the field on a certain condition. How will FAPI know when it can or cannot accept the input value?
Comment #45
boombatower CreditAttribution: boombatower commentedCreated related issue: #426056: Server-side enforcement of #disabled is inconsistent.
Comment #46
Dave ReidComment #47
BerdirThe reason I wrote "not" is that we write what is expected for all assertions (And when it's red, it is not true), but removing it makes sense, I was really unsure about that.
#44 is probably the reason why #disabled fields are not ignored, because we don't know if the property has been changed with JS or not. the teaser_js field is such an example, which is "actived" with JS.
One example when a #disabled field should never be used is at #91663: Permission of text format is not checked when editing an entity and instead reset to something a user can use..
Another #disabled related issue: #410926: Using FAPI #disabled on some element types causes values to be ignored.
Comment #48
Damien Tournoud CreditAttribution: Damien Tournoud commentedThere is no reason to generate a failure when $edit contains a value for a disabled field. After all, a disabled field on a normal browser can *have* a value, that value is just not submitted. If you want to forcefully submit a value in that field, simply alter the page content so as to remove the disabled="disabled" property, as you would do in a normal browser.
Basically, I think my patch in #2 is the way to go. The new test is unrelated with that patch, and should be discussed in #426056: Server-side enforcement of #disabled is inconsistent.
Comment #49
boombatower CreditAttribution: boombatower commentedThere a consensus that needs to be met. We either allow overriding of the POST array like #42, or we force the user to use xpath and such to change the field itself (not very pretty). If we choose the latter as in #2 then we can remove the extra parameter.
An error message should be generated as that is consistent with the standard and provides a useful message for DX (like our other field not found and form not found messages).
Comment #50
Damien Tournoud CreditAttribution: Damien Tournoud commented@boombatower: I don't see any value in an error message.
Our simpletest works like a virtual browser. In a real browser, you can have disabled fields, and those can have values. You can post a form including some of those disabled fields, but their values will not be sent to the server. No error message will be displayed to the user when you post a form with disabled fields. There is no reason to do that any differently in our virtual browser.
The translation tests are doing the good thing:
It shouldn't have to care if the checkbox for this language code is disabled or not. As long as the checkbox exist, it should be ok to set a value to it. It will just be ignored if it's disabled.
By the way, here is the code to remove the disabled attribute of a checkbox by ID:
Comment #51
boombatower CreditAttribution: boombatower commentedI am not arguing that this is hard, merely that is differs from our current flow. A browser does not output a message if you set field values that don't exist...or push a button that doesn't exist...since obviously you can't....
I'm fine with this going in either way, I just think from a debugging perspective that either way you use to submit disabled field values an error message is displayed if you use the standard edit when the field is disabled. In the same sense then setting a field value for a field that isn't on the page (aka it won't be sent) it would seem consistent that we also generate a message for a disabled field (which value won't be sent).
This is minor otherwise and should rarely occur so I don't want to hold up the patch.
So we just need to decide the larger issue which is whether to allow an override of remove the disabled attribute....I don't see an outstanding argument for either. I somewhat agree that removing the disabled attribute feels about the same as hacking the page with (say firebug) on that level seems good, I'm just not sure it is obvious to a developer, but again very rare usage.
Since the priority of the patch is to not send disabled field values by default and #2's implementation fits with less code I would vote for that, just not sure on the error message, but otherwise #2 is fine with me.
Comment #52
Berdir@DamZ
While removing the disabled attribute works for this, I still think that there is a use case for 'additional_post', because that allows to send everything, even things that are not defined the form. *
A possible use case: Write a test to assure that #access works as expected. It should not allow to send a value for a field or multiple fields that are hidden with that. This would for example be nice to write tests for #152473: Make #access more flexible.
I don't really care if we output a failure or not, but I agree with boombatower that it would be more consistent, as we have failures when a field or form does not exist at all.
* Sure, you could also add additonal fields to the HTML, but do you really want to do that ? :)
Comment #53
Dave ReidUgh, I just ran into this one again writing some tests for contrib module. We can't write any tests that involve the user/x/edit form until we figure out which direction to go and get this fixed.
Comment #54
boombatower CreditAttribution: boombatower commentedCan we come to a consensus. I think #52 states a good case for 'additional_post'
Comment #55
boombatower CreditAttribution: boombatower commentedI cleaned up the documentation and re-rolled #42 for HEAD. For clarification it follows the format described in #52, that being 'additional_post'.
Once this gets in I will work on: #426056: Server-side enforcement of #disabled is inconsistent
Comment #57
boombatower CreditAttribution: boombatower commentedTotally forgot to even create a patch....which was annoying as I reverted changes.
I attempted to re-create the changes quickly.
Comment #59
boombatower CreditAttribution: boombatower commentedThe failing test had not been updated for new format.
Comment #60
moshe weitzman CreditAttribution: moshe weitzman commentedSeems reasonable to me. Found 2 typos:
behavor
failue
Comment #61
boombatower CreditAttribution: boombatower commentedCorrected typos.
RTBC per #60.
Comment #62
Dries CreditAttribution: Dries commented- It would be nice if the documentation of testDisabledField described the expected behavior. The 'additional_post' parameter confused me.
- In URLs we use dashes, not underscores.
-
+ } else {
has a coding style issueComment #63
boombatower CreditAttribution: boombatower commentedOnce this complete I will start on: #426056: Server-side enforcement of #disabled is inconsistent
Fixed other issue. I thought I had fixed style errors from original, but missed that.
Comment #64
stella CreditAttribution: stella commentedTypo in comment for 'testDisabledField()' function:
by using th eadditional_post parameter
. Other than that I think it looks great, and I feel bad for setting it back to needs work for such a trivial issue.Comment #65
boombatower CreditAttribution: boombatower commentedFixed
Comment #66
stella CreditAttribution: stella commented+1 for this patch
Summary of what it does:
Cheers,
Stella
Comment #68
boombatower CreditAttribution: boombatower commentedTest slave crapped.
Comment #70
boombatower CreditAttribution: boombatower commentedBelieve this is a re-roll, lots of fun...many to underlying code.
Comment #71
boombatower CreditAttribution: boombatower commentedIt should be RTBC since just re-roll.
Comment #72
Damien Tournoud CreditAttribution: Damien Tournoud commentedI'm fairly -1 on this patch. The whole "additional_post" is scope creep, and the parameter name is really awkward (quoting Dries, who brought this to my attention, "it is like, wtf?").
In #346095: Test #ajax, I started suggested splitting drupalPost() itself. Thinking about it more, I think we need three functions:
I suggest we just commit the disabled field part right now, and discuss refactoring drupalPost() and related functions in a separate patch.
Comment #73
Dave ReidYes. I agree that the additional_post stuff needs to be split out in a separate feature request.
Comment #74
boombatower CreditAttribution: boombatower commentedIf we do #72 then lets get abstract browser in and clean it from there. No sense reworking a soon to be replaced code base.
I would somewhat vote for getting it in...since it is holding up other issues...but seems like everyone is against that...so then lets postpone this for after abstract browser is in.
Comment #75
chx CreditAttribution: chx commentedThe browser patch is in.
Comment #76
sun.core CreditAttribution: sun.core commentedThe browser patch is out? ;)
Comment #77
boombatower CreditAttribution: boombatower commentedSadly yes. I maintain and enhance it @ http://drupal.org/project/browser.
Comment #78
Dave ReidAnyone up for re-rolling this? This is a pretty critical bug since it's hampering any kind of testing in contrib.
Comment #79
Dave ReidLet's just get a simple version of this in now please. Simple patch that changes a user test that submits on user/x/edit which would fail if the user has the 'administer permissions' permission since they get the visible role checkboxes and disable authenticated user role checkbox.
Comment #81
effulgentsia CreditAttribution: effulgentsia commentedThere's a patch that passes bot in #712990: Test framework does not correctly emulate browser submission of disabled elements that was marked duplicate. Feel free to merge in those hunks to get #79 working.
Comment #82
rfaySubscribing. This is an important one.
Comment #83
effulgentsia CreditAttribution: effulgentsia commentedI just read this entire thread, and can't find anything in it that argues against the patch I had in #712990: Test framework does not correctly emulate browser submission of disabled elements, so I'm re-uploading that one, renamed with this issue number.
I agree with Damien with respect to the last code block in #50. If you want to submit input for an element that doesn't exist or for an element that is disabled, you should update the HTML, just like you would do if you were using javascript to hack a form. We can create a wrapper class for this if we want to make it easier for test writers, and that's something I'll take up in #426056: Server-side enforcement of #disabled is inconsistent, which has already reached consensus, but needs tests before landing, and the test will need to emulate just such a hacking attempt, so I postponed that issue until this one lands.
Beyond the scope of this issue, this patch also strengthens the FAPI disabled test from assertEqual to assertIdentical, because the main reason that test couldn't use the stronger assertion to begin with is because of this simpletest bug that is being fixed.
Comment #84
boombatower CreditAttribution: boombatower commentedSeems fine.
Comment #85
naxoc CreditAttribution: naxoc commentedSubscribe
Comment #86
effulgentsia CreditAttribution: effulgentsia commentedCatchier title? Really hoping this lands soon. Several FAPI issues are hard to write proper tests for without this.
Comment #87
webchickWas going to commit this, but it has Dries's fingerprints all over it. Dries, if you want to have a crack at it feel free. Else I'll look more closely and commit in the next day or two.
Comment #88
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #89
andypostLooking at
http://api.drupal.org/api/function/form_type_checkboxes_value/7
http://api.drupal.org/api/function/form_type_select_value/7
First function returns key=1 second key=key
This is a quick fix, because all testing bots are broken
EDIT:
Different result for checkboxes and select
Comment #90
effulgentsia CreditAttribution: effulgentsia commentedConfirming that 1 FAPI test is broken in HEAD and that #89 fixes it.
I was confused why #83 was responsible for the breakage, as it had passed bot on 2/18, and the line being changed in #89 has existed in form.inc for a long time before that and wasn't touched by the #83 patch. The problem was caused by the combination of #83 and #414424-118: Introduce Form API #type 'text_format', where each patch on its own was fine, but together, they exposed the bug fixed by #89.
Comment #91
andypost@effulgentsia For me this still seems a strange, FAPI checkboxes and select default values should be assigned by pointing a key, but broken test shows that value is equal to some data...
Result array should hold an array
Also I cant understand value
"test_1":""
Comment #92
effulgentsia CreditAttribution: effulgentsia commentedThere remains much weirdness with the code internals of checkboxes, radios, and multi-selects, and about half a dozen issues trying to clean them up: for starters, #654796: Identify fix bugs with checkbox element. The code in form_type_checkboxes_value() is very weird indeed, and hopefully will be cleaned up as part of that issue. The implicit conversion of NULL to empty string causing
"test_1":""
done within _form_builder_handle_input_element() needs to be looked at too, perhaps also as part of that issue. But these are all legacy problems, nothing new.The new problem causing a broken HEAD right now is that #414424-118: Introduce Form API #type 'text_format' introduced this:
Which means once form_type_checkboxes_value() returns a value, each individual checkbox's form_type_checkbox_value() doesn't get merged into $form_state['values']. Before the above code was introduced, what form_type_checkboxes_value() returned ended up being overridden anyway by form_type_checkbox_value(), but now it's not, so the fact that what form_type_checkboxes_value() returns is inconsistent with the #return_value of each checkbox is a problem, and that's what's being solved, not entirely elegantly, by #89.
Hopefully, as we work our way through the forms system issue queue, the remaining messes will get solved and in a way that's grokkable. I look forward to seeing you on those issues.
Comment #93
webchickCommitted to HEAD. Thanks!
Comment #94
webchickComment #96
Heine CreditAttribution: Heine commentedWas #89 committed? #803212: Protection against forgery of input selection value doesn't work with checkboxes is also caused by this issue.
Comment #97
effulgentsia CreditAttribution: effulgentsia commented#89 solved the problem for default values, but not for forgery. I posted a fix to the forgery bug on #803212: Protection against forgery of input selection value doesn't work with checkboxes.
Comment #98
dgtlmoon CreditAttribution: dgtlmoon commentedWhat does this mean for form fields where they are set to 'disabled' but then enabled with jQuery (by removing the disabled status), how does one test that field for submission?
Comment #99
rfay@dgtlmoon - wrong place for this conversation. You might open a new support issue or post on http://drupal.stackexchange.com
I'm *pretty* sure that you'll get a horrible validation failure if you change a form element from disabled to enabled using jquery. Don't do that.
Comment #100
dgtlmoon CreditAttribution: dgtlmoon commentedNope, it's all 100% client side as far as i can see.