Bug 16707 - user/password set to undefined means missing
Summary: user/password set to undefined means missing
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: XHR (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-12 07:07 UTC by Anne
Modified: 2012-10-11 10:08 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anne 2012-04-12 07:07:46 UTC
When the user/password arguments are set to undefined they should be treated as missing arguments. Either via an IDL option or because that is what undefined means per ES/IDL.
Comment 1 Cameron McCormack 2012-04-12 07:42:40 UTC
If we don't change Web IDL due to http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0105.html then bang a [TreatUndefinedAs=Missing] on those two arguments.  If we do change Web IDL, then [TreatUndefinedAs=Missing] will disappear and it'll just be the default behaviour.

I wonder what the behaviour should be if undefined is specified for username but not for password.
Comment 2 Anne 2012-04-12 07:50:28 UTC
The other alternative here is that since undefined becomes null per IDL we could maybe make null mean missing in prose.

Currently user/password are a bit of a mess because of bug 10326 and to a lesser extent bug 15418. If someone could explain what we should do for them that would be nice.
Comment 3 Boris Zbarsky 2012-04-12 17:05:36 UTC
Right.  The big question is whether explicit null passed should mean "missing".  If it should, then we should have a nullable string here with null as default value and just have the prose talk about null.  If it should not, then we should use [TreatUndefinedAs=Missing], probably have this be a non-nullable string, and the prose should talk about missing arguments.
Comment 4 Anne 2012-10-11 10:08:14 UTC
This is fixed as suggested in comment 3 by bug 17242 comment 16.