967540 - [Contacts] Exporting to SD card contacts imported from Gmail with invalid dates never ends

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Contacts, defect)

Description

[Germán Toro del Valle (:gtorodelvalle)]

STR:
1. Open the Contacts app.
2. Click on the Settings icon.
3. Click on the "Import Contacts" button.
4. Click on the "Gmail" button.
5. Authenticate into Gmail (if not already done).
6. Select a contact with an invalid date. In the past, Google Contacts accepted birthdays such as "June 24" as a contact birthday. Google does not accept these "dates" any longer but contacts created in the past may maintain them. This was my case :-)
7. Import the contact.
8. Click on the back (less than) icon in the upper left corner to get back to Settings.
9. Click on the "Export Contacts" button.
10. Click on the "Memory card" button.
11. Select the contact imported in 6.
12. Click on the "Export" button in the upper right corner of the page.

OBSERVED:
13. The "Export to SD Card" overlay never closes.

EXPECTED:
13. The "Export to SD Card" overlay is shown and once the contacts have been exported to the SD card it is closed.

Comment 1

[Germán Toro del Valle (:gtorodelvalle)]

Hi Ayman, what do you suggest we do with those "invalid dates" when importing from Gmail? Should we just ignore them? Thanks!

Comment 2

[Germán Toro del Valle (:gtorodelvalle)]

Obviously the issue is avoiding getting invalid dates in our DB... I included the exporting to SD card since it is one of the places where having invalid dates in the contacts DB ends up being a problem ;-)

Comment 3

[ayman maat :maat]

Ok so after lengthy discussions with German we have concluded that the most economic option is to not import these dates. It would be preferable to import them and append a ‘place holder’ year in the empty field being that day and month are the most important data stings for birthdays. However the problem is that we have no way of knowing what format the date is in so the development overhead for conversion is large and the risk of error (day in month field - month in day field) is also significant and this leads to importing - converting - appending of placeholder year being uneconomical path to follow.

In view of this we can discard such dates.

Comment 4

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: 15950.html

Requesting review by Francisco since he may be familiar to the issue due to the Gmail Connector implementation and also so he can comment on the matter :)

Comment 5

[Germán Toro del Valle (:gtorodelvalle)]

Nominating to 1.3? since the exporting to SD card issue is just one of the issues which may arise once an invalid date is stored as a contact property in the DB.

Comment 6

[Preeti Raghunath(:Preeti)]

moving to 1.4?

Comment 7

[ayman maat :maat]

why is this 1.4? this should be fixed in 1.3
renominating 1.3?

Comment 8

[Germán Toro del Valle (:gtorodelvalle)]

If it helps to get this bug nominated to 1.3, I would say that this is a bug caused by data provided by a third party (in this case Google). Having these kind of bugs once the version is on the streets may become a nightmare :-) On the other hand, we do already have a quite simple patch solving it, including 2 new unit tests covering it ;-) Just my 2 cents! ;-)

Comment 9

[Jason Smith [:jsmith]]

Does this reproduce on 1.2? Just wondering if this is a regression or not.

Comment 10

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 8370173 [details]
15950.html

Hei German!

Thanks for the patch, working beautifully, thanks for taking care of enabling the unit tests for the gmail connector back!

You rock!

Comment 11

[Germán Toro del Valle (:gtorodelvalle)]

BTW, if there were not enough reasons for nominating as v1.3+, we just realised thanks to Mari Ángeles that Google still accepts any text as a "valid" value for the birthday date. It just shows a warning next to the field but it stores it and sends it to external parties accessing the contacts :-O This is, anyone can set "foo" as a Google contact's birthday date which would end up in our contacts DB as an invalid date. In our case, the bday property of contacts is a date whereas in the Google case I guess it can be anything. Another 2 cents! Geez, this is becoming kind of expensive... :-p

Comment 12

[Francisco Jordano [:arcturus] [:francisco]]

+1 to become 1.3+

We have a patch that is perfectly save, add more and more unit tests and save us for possible headaches :) WIN WIN.

Comment 13

[Germán Toro del Valle (:gtorodelvalle)]

Merged in master: https://github.com/mozilla-b2g/gaia/commit/95cea779da64742c1f46da1a628c8c7a21604d8e

Comment 14

[Maria Angeles Oteo (:oteo)]

(In reply to Jason Smith [:jsmith] from comment #9)
> Does this reproduce on 1.2? Just wondering if this is a regression or not.

Reproducing the bug in 1.2 too
Gecko-2cf306d
Gaia-539a25e

It is not a regression but the bug is bad enough to block as German explains in comment 8 and comment 10,  the export is totally hung and user has to restart the app :(

Comment 15

[Preeti Raghunath(:Preeti)]

1.3+ per concerns

Comment 16

[John Ford [:jhford] CET/CEST Berlin Time]

I was not able to uplift this bug to v1.3.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1.3, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1.3
  git cherry-pick -x -m1 95cea779da64742c1f46da1a628c8c7a21604d8e
  <RESOLVE MERGE CONFLICTS>
  git commit

Comment 17

[Germán Toro del Valle (:gtorodelvalle)]

Merged in v1.3: https://github.com/mozilla-b2g/gaia/commit/467ef8c9145d9a57d35b0619db541d23b522b958

Comment 18

[Loli (:lolimartinezcr)]

Tested (02/06/2014) and working:
1.3
Gecko: 1fe8aca
Gaia: fb35a67