Closed Bug 929435 Opened 6 years ago Closed 6 years ago

Treat undefined DOMStrings as null in the Contacts API

Categories

(Core Graveyard :: DOM: Contacts, defect, major)

x86
Gonk (Firefox OS)
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
mozilla28

People

(Reporter: jmcf, Assigned: reuben)

References

Details

(Keywords: regression)

Attachments

(2 files)

if a SIM contact does not have any associated phone number mozICcManager.readContacts is returning a contact which on the tel field contains array with one element and the 'string' undefined as tel.value.
this is happening on master branch and master gaia. Don't know if it is happening on koi.
Whiteboard: qawanted
at UI level this is what is happening
Not sure is it the same case as bug 808220 comment #14 and bug 808220 comment #16.
Assignee: nobody → gwang
Cannot reproduce this on v1.2 (10/28 build):
Gecko-e8d81ae
Gaia-2ef9bc3
Whiteboard: qawanted
This is an XPCOM/IDL problem.
And the regression is due to bug 850430  Contacts API: Use WebIDL

Originally, string parser will check if string = undefined when parsing.
This part was removed after use WebIDL.

https://hg.mozilla.org/mozilla-central/rev/533d30be7e6e

    2.36 -function sanitizeStringArray(aArray) {
    2.37 -  if (!Array.isArray(aArray)) {
    2.38 -    aArray = [aArray];
    2.39 -  }
    2.40 -  return aArray.map(stringOrBust).filter(function(el) { return el != undefined; });
    2.41 -}
    2.42 +ContactAddress.prototype = {
    2.43 +  // This function is meant to be called via bindings code for type checking,
    2.44 +  // don't call it directly. Instead, create a content object and call initialize
    2.45 +  // on that.
    2.46 +  initialize: function(aType, aStreetAddress, aLocality, aRegion, aPostalCode, aCountryName, aPref) {
    2.47 +    this.type = aType;
    2.48 +    this.streetAddress = aStreetAddress;
    2.49 +    this.locality = aLocality;
    2.50 +    this.region = aRegion;
    2.51 +    this.postalCode = aPostalCode;
    2.52 +    this.countryName = aCountryName;
    2.53 +    this.pref = aPref;
    2.54 +  },
 
Dear Reuben,
Could you help check?
Flags: needinfo?(reuben.bmo)
Depends on: 850430
Blocks: 850430
blocking-b2g: --- → 1.3?
No longer depends on: 850430
Keywords: regression
Component: DOM: Device Interfaces → DOM: Contacts
Assignee: gwang → reuben.bmo
Flags: needinfo?(reuben.bmo)
Summary: navigator.mozIccManager is returning the string 'undefined' for SIM contacts without tel number → Treat undefined DOMStrings as null in the Contacts API
Attachment #824947 - Flags: review?(anygregor)
Attachment #824947 - Flags: review?(anygregor) → review+
https://hg.mozilla.org/mozilla-central/rev/14215376a810
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Er.... why was this change to introduce [TreatUndefinedAs=Null] needed?  For an nullable string, that's already the default behavior.

And in fact, if I simply back this patch out the codegen doesn't change at all.  So what was the effect of this patch?  Did the test that was checked in actually fail without it?
resolved in master 1.3. remove blocking flag
blocking-b2g: 1.3? → ---
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.