IMAP/TCP on FirefoxOS

[Tankred Hase]

Hi,

we're evaluating a Firefox Packaged App port of Whiteout Mail for Desktop/FirefoxOS and started testing the code on a Geeksphone running Firefox OS 1.3. Most of the stuff works out of the box, but unfortunately the app get stuck when connecting to the gmail imap server via the tcp-socket.

We call TCPSocket.open and then 'onopen' is fired, but that's it. The 'ondata' event is never fired, so we don't get any data from the server. It's also quite weird that the 'ssl' attribute on the socket object is false even though we set the 'useSSL' option to true when calling open. What are we doing wrong? Is the documentation still up to date or has the api changed https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket ?

Andrew, you obviously have the most experience with imap on FirefoxOS ... perhaps you can point us in the right direction?

Here's our app manifest:

https://github.com/whiteout-io/mail-html5/blob/dev/firefox/src/manifest.webapp

Here's the imap/tcp code:

https://github.com/whiteout-io/browserbox/blob/896823ab8a84d6ceeba503e67009f8c8ad7b5f59/src/browserbox-imap.js#L202

Thanks in advance for your time!

Tankred

Whiteout Networks GmbH c/o Werk1

Grafinger Str. 6

D-81671 München

Geschäftsführer: Oliver Gajek

RG München HRB 204479

[Andrew Sutherland]

Awesome to hear about the porting efforts! I am happy to answer any
questions here, especially since our dev.b2g and dev.gaia lists can have
more traffic, but it's worth considering joining those lists (see
https://www.mozilla.org/about/forums/) if you're expecting to do a lot
of development or don't want to limit yourself to the Gaia email
developers' knowledge (we should all be on this list I think).

https://bugzil.la/784816 changed useSSL to useSecureTransport. I think
only v1.0.1 still uses useSSL.

I have updated the documentation at:
https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket.open
https://developer.mozilla.org/en-US/docs/Web/API/TCP_Socket_API

If you find any other out-of-date pages, please feel to update them or
let me know and I'll make sure they get updated. Because the raw socket
/ TCP socket spec at http://www.w3.org/2012/sysapps/tcp-udp-sockets/ (as
you probably know) has been in a heavy state of flux and is one of those
legacy/troublesome security concern APIs that is sort-of cordoned off,
its docs haven't been the highest priority, so there may be some other gaps.

I'd probably suggest checking out https://bugzil.la/932183 for
information on how the flow control mechanism was altered if you do any
type of flow control. For example, because TCPSocket can't accept a
Blob right now (although the spec calls for it), we have logic at
https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/master/data/lib/mailapi/worker-support/net-main.js
that leverages this to efficiently send Blobs so we don't OOM. The
worker-thread counterpart to that logic is at
https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/master/data/lib/node-net.js.
(TCPSocket does not yet work on workers but will soon.
https://bugzil.la/916199 is fairly active and should probably land for
v2.1.)

However, you should be aware that https://bugzil.la/982779 that improved
various issues in our Blob implementations (particularly as it relates
to memory-backed Blobs and cross-process-Blobs) and was only uplifted to
v1.4. In general I think you should be okay on v1.3 because I patched
the Camera/Gallery apps so they use file-backed Blobs, but if you see
weirdness, that could be why.

Also relevant is https://bugzil.la/861196 where I greatly expanded on
our returned SSL error codes. That may not matter as much to you if
you're still gmail-specific right now. The only time you should see an
exception whose error.name matches /^Security/ is if the user is being
attacked or *the date is wrong on the phone*. We see the latter a lot
from testers and are planning to provide a specialized error message to
tell them to set their clock.

Andrew

[Tankred Hase]

Well that did the trick ... some minor CSS fixes, but looks like the
Firefox port is in reach :)

> --
> You received this message because you are subscribed to the Google Groups
> "Email.js Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emailjs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--

[Tankred Hase]

Hi Andrew,

thanks again for your fast response.

One other question ... how can I test the packaged app in the desktop
runtime during? I can only select the FirefoxOS simulator, but it
seems the desktop now supports privileged app as well. But this is not
documented anywhere:
https://developer.mozilla.org/en-US/Marketplace/Options/Open_web_apps_for_desktop

Tankred

[Andrew Sutherland]

On 07/19/2014 04:50 AM, Tankred Hase wrote:
> One other question ... how can I test the packaged app in the desktop
> runtime during? I can only select the FirefoxOS simulator, but it
> seems the desktop now supports privileged app as well. But this is not
> documented anywhere:
> https://developer.mozilla.org/en-US/Marketplace/Options/Open_web_apps_for_desktop

I just did a bit of investigation on this, and my impression is that
it's probably still in the process of being implemented, or at least
made user friendly. Specifically, as I understand it, there are two
ways privileged app installation could work:

A) Installation via remote debug protocol. This is the way to side-load
privileged apps onto the phone. However, Firefox desktop seems to not
want to do this. If I run Firefox Nightly and enable remote debugging
and tell it to listen on a port and then connect to that Firefox
Instance from the new WebIDE, it doesn't work. There's an explicit
guard in
http://dxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webapps.js#812
that throws an error when it tries to launch, ostensibly after the
install is completed (the app shows up in PROFILE/webapps/). However if
I comment out that guard, things still don't work. If I directly browse
the Firefox instance via the app protocol, it also does not work.

B) Installation via standard marketplace mechanism. Because you want
your app to be privileged, I think this requires your app to already be
reviewed in the market or for you to be running your own marketplace
that you've configured Firefox to look at. I don't know how to do that,
though there do seem to be some docs on it. This seems like somewhat of
a hassle. I should note that when I installed a (normal) app from the
marketplace on linux, A webapprt stub was created that created a
.desktop file in ~/.local/share/applications and a stub under my home
directory at "~/.APPNAME-HASHLOOKINGTHING". This suggests a completely
different codepath is involved and more work is required.


I went looking for bugs but only found fixed bugs. It seems like this
issue may span devtools and multiple groups, so asking someone more
knowledgeable may be the best solution. I'd advise two things:

1) Join the dev-webapps list/group and ask about this
(https://www.mozilla.org/about/forums/#dev-webapps). I can of course
ask for you, but it's probably beneficial all around if there's some
visibility of your work in there, if only because then Mozilla
evangelism/developer relations/bizdev/webapprt people will see you and
maybe be able to help in ways I could not.

2) A workaround is just to explicitly authorize an origin. You don't
need to package your app either; it can be served via localhost (or
preferably a virtual-homed localhost that is only serving your app code
so it gets its own origin/etc.). See the part of
https://github.com/mozilla-b2g/gaia/blob/master/apps/email/README.md
that discusses "Running in Firefox".

Andrew

[Tankred Hase]

Thanks alot for your help! I'll need to try this out...

[Andrew Sutherland]

On 07/19/2014 09:03 PM, Andrew Sutherland wrote:
> 1) Join the dev-webapps list/group and ask about this
> (https://www.mozilla.org/about/forums/#dev-webapps). I can of course
> ask for you, but it's probably beneficial all around if there's some
> visibility of your work in there, if only because then Mozilla
> evangelism/developer relations/bizdev/webapprt people will see you and
> maybe be able to help in ways I could not.

I started a thread on dev-webapps about this since I'm also interested
in the problem because we'd like to create a desktop variant of our app:
https://groups.google.com/d/msg/mozilla.dev.webapps/QNk6KnajAao/CT4_vPvEIL0J

The responses so far suggest there's still work to do to enable this
use-case further, but
https://wiki.mozilla.org/Mobile/Projects/BetaChannel is probably worth
looking at, including the temporary version of the server at http://d2gk.co/

Andrew

[Tankred Hase]

Awesome! Thanks Andrew.

It be great to see some improvements in tooling for desktop. I
understand why Mozilla is investing a lot in Firefox OS, but it seems
to me that developers are currently more interested in the desktop
platform, because that's where the biggest marketshare is (#1 desktop
browser in Germany). And after all, more desktop apps in the Firefox
Marketplace will obviously also lead to more apps for FirefoxOS.