796594 - [email] Sending a mail via gmail/ActiveSync 12.x (or lower) servers does not work

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[John Shih]

## Environment :
Otoro phone, build 2012-10-02
Build info: 
* "gaia" revision= 216ca858b69ec3c090893feb4d2f4b906e38e368
* "gecko" revision= 30be6b65d956f155cc6a3fa6a0854fdb6c9e4ac2

## Repro :
1. Launch the Email app
3. Log in with a account (I use gmail here)
4. After log in, write an email to another account


## Expected:
* The target account will receive the email

## Actual:
* Didn't receive

## Note:
* I've test with gmail to gmail & gmail to mozilla
* It only successful with 
1. Use gmail send a email to myself (same account) from website 
2. Receive the email in email app
3. Reply the email (to the account itself)
4. Check the gmail website, then it will receive

Comment 1

[Jim Porter (:squib)]

Ok, so this is because SendMail works differently pre-ActiveSync 14.0 (Gmail uses 12.0.) It should work fine under Hotmail, though.

Comment 2

[Jim Porter (:squib)]

asuth: To fix this, I'm going to need to allow the ActiveSync core code to post arbitrary content to the server. Currently, I have a method called `doCommand` that handles commands, and it takes two arguments: the WBXML for the command, and a callback. To support this, and some other stuff down the line, I'll need arguments for all the following:

* The command name
* The command's post data
* The command's content type
* The callback
* Additional parameters in the URL
* Additional HTTP headers

The first 3 can be combined into one argument when sending ordinary WBXML by examining the supplied WBXML code, but that obviously doesn't work for arbitrary data. Any thoughts on what the best API for this would be? I was thinking something like so:

  // Posts WBXML to the server
  post: function(command, callback) {}

  // Posts arbitrary data to the server
  postData: function(commandName, contentType, data, callback) {}

I'm not sure where the URL params or the HTTP headers should go, though.

Comment 3

[Kai-Chih Hu [:khu]]

I think it's a blocker.

Comment 4

[Jim Porter (:squib)]

asuth: Oh, to explain in a little more detail, my main concern with how to pass the URL params and HTTP headers is that 99% of the calls won't use these, but we need to use them in one or two cases. I'd rather not force all the callers to pass in a bunch of nulls, and I'd rather the callback be the last arg, since the callbacks can get fairly long.

Comment 5

[Jim Porter (:squib)]

Ok, I've fixed this on my fork of GELAM and the patch is percolating through the various subrepos we have for email. First PR is here: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/60

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jim Porter (:squib) from comment #4)
> asuth: Oh, to explain in a little more detail, my main concern with how to
> pass the URL params and HTTP headers is that 99% of the calls won't use
> these, but we need to use them in one or two cases. I'd rather not force all
> the callers to pass in a bunch of nulls, and I'd rather the callback be the
> last arg, since the callbacks can get fairly long.

I think the way you did it is pretty reasonable (callback, with optional args afterwards).  The idioms are usually either use a typeof check to shift omitted arguments in the (req, req, opt, opt, callback) case so you can do (req, req, callback), or just end up passing an object dictionary as the sole argument ({callback: cb, extraParams: {}, extraWhatever: {}}.

Doing the reviews now.

Comment 7

[Jim Porter (:squib)]

Checked in: https://github.com/mozilla-b2g/gaia/pull/5636

Comment 8

[John Shih]

verified on otoro-ics 2012
build info:
gaia : a3339652136fde9e5207e1bc1263a410c84f55fc
mozilla-central : aecce9686d0b0e6ec25bb31e837eadace251a951