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)
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.
Assignee | ||
Comment 1•10 years ago
|
||
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)
Assignee | ||
Comment 2•10 years ago
|
||
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.
Comment 3•10 years ago
|
||
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.
Updated•10 years ago
|
Attachment #8481436 -
Flags: review?(bugmail) → review+
Assignee | ||
Comment 4•10 years ago
|
||
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.
Comment 5•10 years ago
|
||
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).
Assignee | ||
Comment 6•10 years ago
|
||
For the worker-bootstrap fix: Merged in GELAM master: https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/983fd1462c4f0df450775d89c240af1cfb197392 from pull request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/333 Merged in Gaia master: https://github.com/mozilla-b2g/gaia/commit/c61e43835285f429ef56ec2e4bc6e1d6668efe98 from pull request: https://github.com/mozilla-b2g/gaia/pull/23502
Assignee | ||
Comment 7•10 years ago
|
||
As a data point, if I use latest Aurora, 33.0a2 (2014-08-29), it loads up fine with DEBUG=1.
Assignee | ||
Comment 8•10 years ago
|
||
Tried with latest nightly, and the fix in comment 6 was enough, nightly now works.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•10 years ago
|
||
Ugh, I was looking in the wrong window. Still an issue with nightly.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 10•10 years ago
|
||
This seems to work now with nightly 35.0a1 (2014-09-11) so closing.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•