Closed Bug 1060475 Opened 10 years ago Closed 10 years ago

[email] DEBUG=1 in firefox nightly not working with emailjs changeset

Categories

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jrburke, Assigned: jrburke)

References

Details

Attachments

(1 file)

Just a small quirk, does not affect the main usage of the email app on devices, just a specific kind of dev setup, using Firefox desktop and a `make DEBUG=1` build that runs email in non-optimized mode.

In gelam's worker-bootstrap.js, it sets up a `var document = { cookie: null };`. I believe that was for something that was needed in the pre-emailjs approach, so I think it is just dead weight now. Removing it and running the gelam tests still result in all of them passing.

However, since it is set before the importScripts for alameda.js, alameda thinks it is in the browser and tries to document.querySelectorAll for a script node with a data-main attribute, and that fails in the non-optimized mode, because there is no real document in the worker.

This is not a problem after a build because alameda and the dependencies for the worker are hoisted above that statement. This is a further indication it is no longer needed.

I should have caught this when working on bug 885110 because I removed the skipDataMain usage the worker was doing to prevent this issue before, but I was so focused on the typical device install that I missed it.
Attached file GELAM pull request
Asking :asuth for review since he has the historical context. I will generate the gaia pull request if this one is r+ and will carry that r+ forward for the gaia pull request, and testing on the device and in the desktop browser.
Attachment #8481436 - Flags: review?(bugmail)
This does not completely fix desktop usage, I am seeing this error now from net-main.js:

NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "TCPSocket does not have permission in this context.

but I believe that to be hopefully a temporary permissions glitch in nightly. I have dom.mozTCPSocket.enabled to true.
As noted on irc r=asuth to remove those lines entirely and not move them since they're from the pre-HTML cookie cache that just tracked whether we had accounts or not.

(In reply to James Burke [:jrburke] from comment #2)
> This does not completely fix desktop usage, I am seeing this error now from
> net-main.js:
> 
> NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "TCPSocket
> does not have permission in this context.
> 
> but I believe that to be hopefully a temporary permissions glitch in
> nightly. I have dom.mozTCPSocket.enabled to true.

This looks potentially serious here.  If it was a question of the preference not being enabled or you not having authorized the origin, TCPSocket would simply be null for you.  Last time I saw something like this it was related to structure clones or typed-arrays from one compartment being exposed, wrapped, into another compartment.  We certainly have changed some things related to typed-arrays and buffers with the switch to email.js.  Nothing jumps out at me in terms of how Firefox would really differ from b2g-desktop here, although it wouldn't surprise me if things did.
Attachment #8481436 - Flags: review?(bugmail) → review+
Gaia pull request is:
https://github.com/mozilla-b2g/gaia/pull/23502

As to the socket error, tapping on it leads to this line in net-main.js:

    var sock = socket.open(host, port, options);

which I do not think is impacted by the recent changes, it is just trying to open a socket. So I am more hopeful that it is just a permissions glitch. I want to dig into it more, but will likely do that after landing the aforementioned change, since it is a blocker to getting to that error, and after finishing up some other things that are more critical to land today.

I will keep this bug open though so that it can be used to track to an ending where desktop can be used.
A bit off topic but for testing stuff in browsers we created a TCPSocket shim over WebSocket. It is pretty neat, as the TLS termination is also done in browser javascript, not in the proxy server, so no MITM issues to worry about if we would want to use it in production for some reason. The goal is to get our entire email application running in a browser with no code changes.

The shim works like this:

    TCPSocket <-> TLS encrypt/decrypt <-> WebSocket <-> Node Proxy <-> TCP <-> Destination host

This way we can run the stuff in a regular browser that otherwise would require special privileges / environments (obviously if the TCP access is the only privileged requirement).

I even have a demo of a webpage that connects to Gmail IMAP and SMTP here: http://node.kreata.ee/ (probably going to take it down some time in the near future, before someone tries to abuse it).
As a data point, if I use latest Aurora, 33.0a2 (2014-08-29), it loads up fine with DEBUG=1.
Tried with latest nightly, and the fix in comment 6 was enough, nightly now works.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Ugh, I was looking in the wrong window. Still an issue with nightly.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This seems to work now with nightly 35.0a1 (2014-09-11) so closing.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: