Flame, while running: Gaia 4d1d0ea5a82cddeeab497774cfa1703639e3c7d9 SourceStamp dc352a7bf234 BuildID 20140826040204 Version 34.0a1 Base image: v123 STR: 1. Open Settings and select Find my Device 2. Select the "Create Account or sign in" button Expected: I would get routed to FX Accounts Actual: Nothing happens. This works fine using the latest 2.0 Flame build. Logcat attached. qawanted for regression info.

[Blocking Requested - why for this release]: This functionality should work and it will be confusing for those who are trying to create an account using this path.

Branch Check Issue DOES occur in Flame 2.1 nightly, 2.0 nightly. Flame 2.1 Nightly Device: Flame Master BuildID: 20140827125050 Gaia: 6e804a42ab90f4251c7fe8c68731dc1c6abd8006 Gecko: d3f9fd13aefc Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 -------------------------------------------------------------------------- -------------------------------------------------------------------------- Issue DOES NOT occur in Flame 2.0 nightly, Flame 2.1, 2.0, 1.4 (all tinderbox/engineering builds). Flame 2.0 Nightly Device: Flame 2.0 BuildID: 20140827000204 Gaia: d72f8ad53448aed577c01ff6e11d958463f261e7 Gecko: 2a18149b3ae8 Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 -------------------------------------------------------------------------- Device: Flame Master BuildID: 20140827125050 Gaia: 6e804a42ab90f4251c7fe8c68731dc1c6abd8006 Gecko: d3f9fd13aefc Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 -------------------------------------------------------------------------- Device: Flame 2.0 BuildID: 20140827074629 Gaia: 1de9e49fc7e3e679f589178e6fbd67903b496ca1 Gecko: 83f2f10431a6 Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 -------------------------------------------------------------------------- Device: Flame 1.4 BuildID: 20140827090228 Gaia: 05653cb12d324649687dad3eeb2ea373a2ad84d4 Gecko: baf01c5965ef Version: 30.0 (1.4) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Please excuse the error above. Confirming that this issue DOES NOT occur in Flame 2.0 nightly build.

QA-Wanted Triage - not requesting a regression-window if we can't repro this in Tinderbox builds (NON-nightly)

regression, blocking 2.1

I am able to repro this with the User build of the aurora branch (using the flash tool). I haven't had to debug user builds much in the past, so I took some notes on the process[1]. Anyway, I see some weird stuff in the adb logs when I click the login button in the FMD Settings panel: E/GeckoConsole( 287): 1409903988370 Identity.FxAccounts DEBUG get assertion for https://find.firefox.com E/GeckoConsole( 287): 1409903988399 Identity.FxAccounts DEBUG get assertion failed: {} E/GeckoConsole( 1651): Content JS ERROR at app://settings.gaiamobile.org/js/findmydevice.js:1 in FindMyDevice.init/</<.onerror: Find My Device: onerror fired: {} It looks like FxA is firing the onerror callback, but FMD only handles 2 possible error strings[2], and any other errors are silently ignored :-( I'll dig further tomorrow into the source of the bug. [1] https://gist.github.com/6a68/00137b5157fd427c691a [2] https://github.com/mozilla-b2g/gaia/blob/v2.1/apps/settings/js/findmydevice.js#L39-L40

(In reply to Joshua Mitchell [:Joshua_M] from comment #4) > QA-Wanted Triage - not requesting a regression-window if we can't repro this > in Tinderbox builds (NON-nightly) Have you tried using user builds instead of engineering builds here?

(In reply to Jason Smith [:jsmith] from comment #7) > (In reply to Joshua Mitchell [:Joshua_M] from comment #4) > > QA-Wanted Triage - not requesting a regression-window if we can't repro this > > in Tinderbox builds (NON-nightly) > > Have you tried using user builds instead of engineering builds here? We have not tried; I considered it somewhat of a moot point to do so because we (Qanalysts) do not pull tinderbox USER builds down into our repositories so a regression-window in this manner would be prohibitively time-consuming as each individual build used would need to be downloaded. That being said - it IS an avenue we can pursue of you feel it has value.

I think we should - this is fundamental bustage, so we probably need to find out what broke it.

Regression-window worker: you will want to pull builds from here https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-central-flame/ to find the initial window and then repeat in the appropriate inbound folder

Hey Sam, When the user is logged out, and clicks the 'sign in' button on the FMD Settings panel, it looks like onerror is firing with an empty error message. Normally we'd expect '{"name":"UNVERIFIED_ACCOUNT"}', for example. But here we just get '{}'. See comment 6 for an adb log snippet showing the error; I've verified it occurs in the debugger, too. Is this a known bug? Cheers, Jared

I'm unable to provide a window due to swapped builds do not work. The first broken gecko & last working gaia flash shows no homescreen; and the first broken gaia & last working gecko is stuck on Firefox logo after flash. I noticed that the version changed from 33.0a2 to 34.0a2 between these two builds. Maybe it had something to do with that. Last Working Environmental Variables: Device: Flame BuildID: 20140902084459 Gaia: 649245c238a043af32acb109b2613f578323f8e1 Gecko: 114b010b6bf1 Version: 33.0a2 Firmware: V123 First Broken Environmental Variables: Device: Flame BuildID: 20140902123006 Gaia: 44bf2e3bc5ddea9db9a8c851bd353cb234aa883c Gecko: 5b8210dcf52a Version: 34.0a2 Firmware: V123 Gecko pushlog: http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=114b010b6bf1&tochange=5b8210dcf52a Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/649245c238a043af32acb109b2613f578323f8e1...44bf2e3bc5ddea9db9a8c851bd353cb234aa883c Notes: 1) The Last Working here is later than what was mentioned at comment 0. However I've triple-checked that last working is indeed working/not reproducing the issue. 2) This issue is exclusive to Aurora branch non-ENG builds. All the other branches or Aurora branch ENG builds do NOT reproduce this issue. Builds were pulled from https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-aurora-flame/ for the window. 3) Unable to bisect further using inbound builds because the issue is branch only.

While I look at this Jared, we might ask ourselves whether the current error sniffing in FMD is unnecessarily tight. Off the top of my head, if the device is online (and maybe if we have a separate path for unvalidated accounts), it may make sense to handle any FxA error by throwing up the create account screen. Or maybe not. It's a resilience vs specificity choice.

I do not get this in the emulator with: Gecko d3f9fd13aefc Gaia 6e804a42ab90f4251c7fe8c68731dc1c6abd8006 and my usual build setup. I am trying to determine what flags I need to set to have a non-engineering build. If anyone happens to know, please LMK.

I switched out most of my Gecko build flags and am getting something much snappier, but "make profile" is still adding the Test Apps. Jared, can you remind me how to build a production Gaia from an arbitrary local tree?

Hey Sam, I think Gecko is not at fault here, it appears that the productionizing process (running uglify2 on the settings app) is generating a bunch of JS errors and might be the cause. For reference, in Gaia, creating a user build is just a matter of doing `make production` or `PRODUCTION=1 make reset-gaia`. I'm not sure how this works on Gecko. THanks for looking, I'll ni? you again if Gaia is not guilty :-)

I've done quite a bit of digging. I am certain something's gone wrong with the Gecko aurora builds: Steps: 1. Use the TWQA flash tool to flash aurora, user build, gaia+gecko 2. Observe that the sign in button in FMD Settings panel does not work, as reported here. 3. Check out the v2.1 branch 100 commits behind the "first broken" gaia commit from comment 12, which is SHA 0059d16. Flash it onto device using "make production" 4. Still broken! 5. Check out today's **master** branch of gaia and flash it onto device using "make production" 6. Still broken! If the version of Gaia doesn't matter, I'm inclined to say it must be something in the way the Gecko build was generated. I'm honestly not sure where to go from here. :piwei, you're listed as the QA contact...any thoughts?

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #17) > I'm honestly not sure where to go from here. :piwei, you're listed as the QA > contact...any thoughts? Sorry, no. I assigned myself as QA contact to find the regression window, which unfortunately was unsuccessful.

Hmm. This is a really weird bug. Marcia, have you seen anything like this in past releases, where a bug is reproducible on user builds, but not engineering builds?

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #19) > Hmm. This is a really weird bug. > > Marcia, have you seen anything like this in past releases, where a bug is > reproducible on user builds, but not engineering builds? Yes, I have heard of this happening before. But because we ship user builds, I think we definitely need to be more concerned with what is happening in the user builds.

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #19) > Hmm. This is a really weird bug. > > Marcia, have you seen anything like this in past releases, where a bug is > reproducible on user builds, but not engineering builds? We've observed a dramatic increase in this in the last 2 weeks. It used to be much more rare. Also - I remember at least one instance of a bug not only specific to user builds - but specific to Nightly user builds, and did not repro in Eng builds OR Tinderbox user builds.

OK, I tried again with a user build, this time enabling console and debug traces, and finally found a clear error in the adb logs. This is what I see after I tap the "sign in" button in the FMD Settings panel: E/GeckoConsole( 322): 1410580437088 Identity.FxAccounts DEBUG watch: {fd791434-8454-49ed-aa78-ed3ab2dfaa84} E/GeckoConsole( 322): 1410580437088 Identity.FxAccounts DEBUG Current rp flows: 2 E/GeckoConsole( 1351): Content JS LOG at app://settings.gaiamobile.org/js/findmydevice.js:1 in FindMyDevice._onChangeLoginState: settings, logged in: false E/GeckoConsole( 1351): Content JS LOG at app://settings.gaiamobile.org/js/findmydevice.js:1 in FindMyDevice.init/</<.onready: Find My Device: onready fired E/GeckoConsole( 322): 1410580438397 Identity.FxAccounts DEBUG get assertion for https://find.firefox.com I/Gecko ( 322): ************************* I/Gecko ( 322): A coding exception was thrown in a Promise resolution callback. I/Gecko ( 322): See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise I/Gecko ( 322): I/Gecko ( 322): Full message: ReferenceError: XPCOMUtils is not defined I/Gecko ( 322): Full stack: @jar:file:///system/b2g/omni.ja!/components/FxAccountsUIGlue.js:35:3 I/Gecko ( 322): this.FxAccountsManager._uiRequest@resource://gre/modules/FxAccountsManager.jsm:310:14 I/Gecko ( 322): this.FxAccountsManager.getAssertion/<@resource://gre/modules/FxAccountsManager.jsm:577:16 I/Gecko ( 322): Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:865:23 I/Gecko ( 322): this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:744:7 I/Gecko ( 322): I/Gecko ( 322): ************************* E/GeckoConsole( 322): 1410580438424 Identity.FxAccounts DEBUG get assertion failed: {} E/GeckoConsole( 1351): Content JS ERROR at app://settings.gaiamobile.org/js/findmydevice.js:1 in FindMyDevice.init/</<.onerror: Find My Device: onerror fired: {} Sam, thoughts?

To be as explicit as possible, I used the flash tool[1] to flash today's aurora user build onto my flame. Gaia 7fe8807b384e1867fa4322f49a1310126fc5a849 Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/1d4b0fc511dc BuildID 20140912000203 Version 34.0a2 ro.build.date Tue May 20 09:29:20 CST 2014 ro.bootloader L1TC200110G0 ro.build.version.incremental 94 [1] https://github.com/Mozilla-TWQA/B2G-flash-tool/blob/master/flash_pvt.py

Something's busted with Gecko's XPCOM handling. The traceback is in stable code that creates a new object to send Gaia a message. Here are the lines in trunk: https://github.com/mozilla/gecko-dev/blob/master/services/fxaccounts/FxAccountsManager.jsm#L309 https://github.com/mozilla/gecko-dev/blob/master/b2g/components/FxAccountsUIGlue.js#L36 This code has worked for months. I think we need XPCOM expertise.

ni on Blake to see if he can figure out why we are getting the errors in Comment 22 that are preventing the button from functioning.

Michael Wu in #b2g asked me to try "an eng build with gaia installed via make production". This did not repro. Then he suggested I iterate through the specific differences between Gecko eng and prod builds (marionette, profiling, ?). Could I punt this task until we have a regression window? Even better would be for someone who regularly manages builds to flip those flags, but I'll take whatever help I can get.

(In reply to Sam Penrose from comment #26) > Michael Wu in #b2g asked me to try "an eng build with gaia installed via > make production". This did not repro. Then he suggested I iterate through > the specific differences between Gecko eng and prod builds (marionette, > profiling, ?). Could I punt this task until we have a regression window? > Even better would be for someone who regularly manages builds to flip those > flags, but I'll take whatever help I can get. See https://bugzilla.mozilla.org/show_bug.cgi?id=1058978#c12

Since Blake is out, adding ni on Bobby - if possible can you look at Comment 24? Thanks.

Hi Marcia, I've unfortunately got too much on my plate to jump on this in a timely manner, and I don't think my unique expertise is need enough (yet) to justify letting this sit until my plate clears up. Sorry about that.

I may have misspoken. The problem is that after XPCOM is imported (without error), it is undefined. (In reply to Sam Penrose from comment #24) > Something's busted with Gecko's XPCOM handling. The traceback is in stable > code that creates a new object to send Gaia a message. Here are the lines in > trunk: > > https://github.com/mozilla/gecko-dev/blob/master/services/fxaccounts/ > FxAccountsManager.jsm#L309 > https://github.com/mozilla/gecko-dev/blob/master/b2g/components/ > FxAccountsUIGlue.js#L36 > This code has worked for months. I think we need XPCOM expertise.

:tchung - we're kinda out of ideas and this is a 2.1 blocker. FxA team has very few patches land in 2.1. We believe this is lower level and a system issue. halp!

The only thing i can do is pass the buck around. ni? Jst, to see if he can find another xpcom developer to help with debugging. JST, comment 24 is where the ask from platform team is needed. Can you assist someone to help bobby out since his plate is full?

As the person who raised the XPCOM flag, I want to reiterate: the actual symptom we're seeing is more like "Javascript doesn't work in this file" or maybe "Components utils.import doesn't work in this file". Specifically, in FxAccountsUIGlue.js: Cu.import("resource://gre/modules/XPCOMUtils.jsm"); // line 11, no error thrown But try to use it: ReferenceError: XPCOMUtils is not defined only on certain production builds.

Andrea, can you have a look and see what's going on here?

(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #34) > Andrea, can you have a look and see what's going on here? Yes. I'll ping 6a68 on irc in a couple of hours. In the meantime I'll try to reproduce the issue.

I tried to reproduce the issue using gaia and gecko up-to-date compiling locally, and I cannot see the issue. I'll try again on monday. Do you think there is some difference between emulator/flame/desktop/inari builds for this particular issue?

(In reply to Andrea Marchesini (:baku) from comment #36) > I tried to reproduce the issue using gaia and gecko up-to-date compiling > locally, and I cannot see the issue. I'll try again on monday. > > Do you think there is some difference between emulator/flame/desktop/inari > builds for this particular issue? That is precisely the question. The only important difference we know of is this bug. We are struggling to determine and bisect the incidental differences to determine which is generating the bug, so far without success.

more data: with today's 2.1 build on a Flame with v123 base - repro with User Build NO repro with Eng Build. The plot thickens.

(In reply to Edwin Wong [:edwong] from comment #38) > more data: with today's 2.1 build on a Flame with v123 base - repro with > User Build NO repro with Eng Build. The plot thickens. Yeah, that's consistent with what we've found in the past (see comment 14 and comment 17). What's new is we have some data suggesting this is only reproducible with releng user builds, not user builds created locally from gecko + gaia (see comment 36). I'm biting the bullet and finally getting gecko set up locally, so that I can try to reproduce the user build problems.

ni bhavna, Fabrice, the issue is repro on user build but not on Eng build. Do you guys know how best to tackle this? is it a build issue?

:_6a68 said via email: I've been unable to reproduce this when building Gecko locally. One of the Gecko DOM hackers tried and was also unable to reproduce this on local builds.

Hi John, Do you think you could help us investigate this bug? It is only reproducible on user pvtbuilds - several people have tried and failed to reproduce on local Gecko builds. Summarizing steps to reproduce quickly: 1. Inside FXOS, go to Settings app 2. open the Find My Device panel (you should be logged out of Firefox Accounts) 3. click the 'sign in' button 4. nothing happens. (normally, the Firefox Accounts dialog pops up) The logcat seems to indicate that the Gecko code isn't linked properly (see comment 22 for pasted log snippet). Unfortunately, QA has not been able to generate a regression window, due to unrelated brokenness around the time this bug was observed. A few questions: - Would you mind trying to build a user build of B2G locally and see if this bug is reproducible for you? - Have you seen any other strange behavior on the user builds since 2.1 was branched? - How exactly are the user builds created? I haven't been able to find clear documentation of how this works--I'm sure it's in some wiki page, I just don't know where. I'm running on mac os, but I'm happy to create a VM and use your exact arguments / build scripts, if it will help me understand what is going on here. Thanks very much! Jared

Now that we have moved over to base v180, I just wanted to note the most current results flashing the Flame KK builds from the TPE tool: Button doesn't work: Gaia 93a99bea0b40d81bd063f7d8b1964dc1ba35ba7b SourceStamp d7e31ecd48af BuildID 20140924000243 Version 34.0a2 base: v180 full flash Button does work: Gaia ff6dbb006e4e60edba697639aa2a2a199b07069b SourceStamp 1e2993c99323 BuildID 20140924040205 Version 35.0a1 base: v180 full flash

Hi Marcia - I'm not familiar with the TPE tool, what's that? Also, are those user or engineering builds? - Jared

This seems related to marionette. Taking an otherwise working omni.ja from an eng build and disabling marionette startup through profile-after-change makes it break. mdas, any ideas what's going on? This seems to be fixed on trunk, but Gecko 34 / Aurora has issues.

I knew this was going to be something dumb.

Comment on attachment 8494988 [details] [diff] [review] Add missing XPCOMUtils.jsm imports (For Gecko 33/34) Review of attachment 8494988 [details] [diff] [review]: ----------------------------------------------------------------- hm, how did that ever worked?

Apparently XPCOMUtils was put back in FxAccountsUIGlue.js in bug 1060647. So I'll just land the addition to b2g/components/MobileIdentityUIGlue.js.

https://hg.mozilla.org/integration/b2g-inbound/rev/fafd0c1c426a As for how this ever worked, well, bug 798491 is the answer. On B2G, all JS components and JSMs share the same global to save memory. This footgun has finally blown off someone's foot. Maybe we should turn this off on debug builds.

Comment on attachment 8494988 [details] [diff] [review] Add missing XPCOMUtils.jsm imports (For Gecko 33/34) Approval Request Comment [Feature/regressing bug #]: Regressed by bug 988469. [User impact if declined]: Firefox Accounts / Find My Device / etc. won't work. [Describe test coverage new/current, TBPL]: This should've been caught by existing tests. We might want to look at doing debug builds differently to catch this in the future. [Risks and why]: This is broken right now. Can't get much worse. [String/UUID change made/needed]: None.

Comment on attachment 8494988 [details] [diff] [review] Add missing XPCOMUtils.jsm imports (For Gecko 33/34) MArcia, can you please help verify this once it lands on 2.1 ? Thanks!

The version that landed on m-c is actually different from the version that needs to land on m-a. m-a needs the patch that's in this bug. I'll land a follow up to put it in.

Sorry about that, I backed out the original landing and re-landed the attached patch. https://hg.mozilla.org/releases/mozilla-aurora/rev/692bb6a3c514

Verified fixed on 2.1 Flame using: Gaia 063de64a4ffc606e931ed7b09e93282713c46eca SourceStamp 055d46b81ed1 BuildID 20140929000203 Version 34.0a2 Base: v180 + Shallow Flash The button is now functional in this build.

Issue verified fixed on Flame 2.1 and Flame 2.2 Device: Flame 2.1 KK (319mb) (Full Flash) BuildID: 20141011000201 Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1 Gecko: d813d79d3eae Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.2 Master KK (319mb) (Full Flash) BuildID: 20141011040204 Gaia: 95f580a1522ffd0f09302372b78200dab9b6f322 Gecko: 3f6a51950eb5 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 The Create account or sign in button in Find My Device leads to the Firefox Accounts sign up/sign in page.