Closed Bug 798740 Opened 12 years ago Closed 12 years ago

[email] account setup gets stuck on spinner screen if mozTCPSocket is not available

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::E-Mail
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 799547

People

(Reporter: dietrich, Unassigned)

References

Details

it was my mozilla.com account.

i couldn't see if i typed my password in wrong, since there's no "show password" option.

tried a couple of times.

Otoro, 10/5 build.
same with gmail.
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
OS: Mac OS X → Gonk
Hardware: x86 → ARM
(In reply to Dietrich Ayala (:dietrich) from comment #0)
> i couldn't see if i typed my password in wrong, since there's no "show
> password" option.

Casey, can we add a "show password" checkbox to the account creation screens where the password is being entered?  (For a screen like credentials where in theory you can see that there is a password there, selecting the box would of course not reveal the password.  Right now I think we put sentinel dummy text in, which we could clear when the checkbox gets selected.)

Dietrich, was there any log output available from "adb logcat"?  And were you using wi-fi or 3g or what?  Thanks.
Component: Gaia → Gaia::E-Mail
E/GeckoConsole(  432): [JavaScript Error: "TypeError: navigator.mozTCPSocket is undefined" {file: "app://email.gaiamobile.org/js/ext/gaia-email-opt.js" line: 18429}]
E/GeckoConsole(  432): Content JS LOG at app://email.gaiamobile.org/js/ext/gaia-email-opt.js:34270 in getConfig: Attempting to get autoconfiguration...
E/GeckoConsole(  432): Content JS LOG at app://email.gaiamobile.org/js/ext/gaia-email-opt.js:34307 in getConfig:   Looking in GELAM
E/GeckoConsole(  432): Content JS LOG at app://email.gaiamobile.org/js/ext/gaia-email-opt.js:34314 in getConfig:   Looking in local file store
E/GeckoConsole(  432): Content JS LOG at app://email.gaiamobile.org/js/ext/gaia-email-opt.js:34288 in onComplete: SUCCESS
E/GeckoConsole(  432): Content JS LOG at app://email.gaiamobile.org/js/ext/gaia-email-opt.js:20404 in ImapProber: PROBE:IMAP attempting to connect to mail.mozilla.com
E/GeckoConsole(  432): Content JS ERROR at app://email.gaiamobile.org/index.html:45 in errHandler: onerror reporting: TypeError: navigator.mozTCPSocket is undefined @ app://email.gaiamobile.org/js/ext/gaia-email-opt.js : 18429

twice ^
Thanks for the log!

The non-existence of mozTCPSocket is concerning since we can't speak IMAP without it.
I have reproduced on my Otoro with both the official Oct-05 and Oct-06 builds, but a self-spun b2g-desktop build from mozilla-central tip is fine.  I'll try the official b2g-desktop builds.
The linux build from https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2012-10-06-03-05-35-mozilla-central/ is fine for me.  To make the Otoro happy I tried doing a make reset-gaia from my gaia dir after nuking the profile dir, but that did not make anything work better.

I can only conclude this is a platform issue somehow related to Otoro.

Naoki, can you track down a regression range for this, or do you have one already?

Josh, do you have any idea why mozTCPSocket might not be working on Otoro only?
Summary: [email] account setup is stuck on spinner screen → [email] account setup gets stuck on spinner screen if mozTCPSocket is not available
Can you print out the value of the dom.mozTCPSocket.enabled pref? I am having trouble identifying any other way that navigator.mozTCPSocket could be null.
Ah, I had been ruling that out because the error was that it was undefined not null, but that does look possible (especially if returning null causes it to never be defined at all by whatever is constructing things.)

Using "adb shell", in /system/b2g/defaults/pref the only file I have is user.js, and it is very short.  In contrast, b2g-desktop's defaults/pref dir has b2g.js, b2g-l10n.js, and services-sync.js.
er, and b2g.js is where we do:
// TCPSocket
pref("dom.mozTCPSocket.enabled", true);
It would not appear to be the preference; b2g.js must just live elsewhere in the image; maybe in the jar.  I just flashed the device with the Oct 8th Otoro build, telnetted to the debug 9999 port (after doing "adb forward tcp:9999 tcp:9999" so "telnet localhost 9999" works) and ran:

Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService).getBranch("").getBoolPref("dom.mozTCPSocket.enabled")

and "true" came back...
and Cc["@mozilla.org/tcp-socket;1"]?
JS> Cc["@mozilla.org/tcp-socket;1"]
undefined
JS> Ci.nsIDOMTCPSocket
nsIDOMTCPSocket
JS> Ci.nsITCPSocketParent
nsITCPSocketParent
JS> Ci.nsITCPSocketChild
nsITCPSocketChild
>JS> Cc["@mozilla.org/tcp-socket;1"]
>undefined

I see "@mozilla.org/tcp-socket;1" when I run this in a chrome scratchpad on desktop, so this is probably a good place to start looking.
Let's make sure there's a TCPSocket.manifest file somewhere?
ARGH

http://mxr.mozilla.org/mozilla-central/source/dom/network/src/Makefile.in#24

We overwrite the EXTRA_MODULES variable when MOZ_B2G_RIL is defined.
Blocks: 746069
Because b2g nightlies just switched to mozilla-aurora, the fix (https://bugzilla.mozilla.org/show_bug.cgi?id=799547) probably won't be in tonight's nightly build.  I've requested mozilla-aurora approval to land the fix even though the mozilla-central landing hasn't happened yet to try and get it in the nightly.
Er, just read the rules and so I can land it now because it's a basecamp blocker without explicit approval.  Landing...
The state of this bug is confusing. Comment #16 implies this was fixed in bug 799547? Comment #17 implies the fix was going to land in aurora. However, there is no update since.

Is this a dupe of bug 799547?
Flags: needinfo?(bugmail)
The patch landed on aurora and mozilla-central.  This bug should be fixed and effectively a dupe of 799547, although I was going to close it as fixed on its own once I verified the build appears happy.

Unfortunately, my otoro device is not currently showing up on 'adb devices' right now, so I am unable to verify.  If someone else can give it a try, that would be good, or I'll see if my device is happier after it can charge the battery a little more, or maybe try some recovery options.  (A round of remove battery then put it back in, plug into USB, turn on device did not net results yet.)
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: needinfo?(bugmail)
Resolution: --- → FIXED
Oops; I set resolved/fixed thinking my verification would pass.  I'll leave this fixed for now, and ideally someone else can hit verify or reopen.
The TCP part indeed works in the nightly.  After I stopped using the non-operational USB port, I was able to flash and setup a yahoo.com e-mail account over AT&T "H" internet.

The bad news is that I am experiencing some type of failure with body retrieval and/or summarization.  I will look into that on a different bug.
(In reply to Andrew Sutherland (:asuth) from comment #21)
> The TCP part indeed works in the nightly.  After I stopped using the
> non-operational USB port, I was able to flash and setup a yahoo.com e-mail
> account over AT&T "H" internet.
> 
> The bad news is that I am experiencing some type of failure with body
> retrieval and/or summarization.  I will look into that on a different bug.

Now that I look again, the 10-10 nightly hsa older contents than I was expecting.  The Mail app is definitely out-of-date; the visuals are all at least a day old.  I just ran with a trunk gaia build on b2g-desktop and yahoo.com got created a-okay with subjects showing up, etc.

I'm going to declare tentative victory without any new weird bugs for now; if the problem appears with the Oct 11th nightly and the mail UI is up-to-date I'll investigate that bug then.
Going to dupe for clarity. FIXED with no owner and no change is confusing.
Resolution: FIXED → DUPLICATE
(In reply to Andrew Sutherland (:asuth) from comment #22)
> > The bad news is that I am experiencing some type of failure with body
> > retrieval and/or summarization.  I will look into that on a different bug.
> 
> I'm going to declare tentative victory without any new weird bugs for now;
> if the problem appears with the Oct 11th nightly and the mail UI is
> up-to-date I'll investigate that bug then.

The Oct 11th build looks right, the problem continues to exist; I have filed Bug 800396 to track and resolve the IMAP issue.
Cleared blocking flag based on duplicate resolution.
blocking-basecamp: + → ---
You need to log in before you can comment on or make changes to this bug.