mozilla :: #mobile

19 Apr 2017
00:18lizzardIm not sure. you might reference those bugs on reddit tho
00:18lizzardINteresting that it may be specific devices
00:32Caspy7lizzard: thanks
06:19bernardhi, can anyone tell me how to print firefox for android c++ logs
06:20bernardusing adb or gdb
06:21bernardlike i want to see this log, LOG(("nsIOService::SetOffline offline=%d\n", offline));
06:48bernardanyone?
06:48bernardhow do i debug native code in firefox for android
06:48bernard?
13:31sebastianArgh "Send to device" is now missing in my Nightly too (saw some reports about that) - @grisha: Help!
13:33sebastianmh, I still see my desktop in "history" but with Last Synced. April 5.
14:31njparksebastian: would you have time to join vidyo for cc discussion now?
14:32sebastiannjpark: Yes! I'm just grabbing coffee. I'll join in a minute!
15:16ahuntnjpark: I just found the focus findbugs stuff I did, its still a PR for now. It looks like I had to add R.* and Manifest.* since theyre generated files that findbugs doesnt like (i.e. they use non-standard naming): https://github.com/mozilla-mobile/focus-android/pull/466/files
15:17njparkahunt: yeah my findbugs talks about R.class file filter too. I see, thanks!
15:26snorpjchen: do you have an open review request from me or did mozreview screw up
15:26snorpI think I hate mozreview
15:26jchensnorp: i have one from a few days ago. but i thought you were going to update it?
15:26snorpjchen: I did
15:27snorpI guess you don't get notified?
15:27snorpjchen: wait you cleared the initial request right?
15:27snorpbut then you got another one?
15:28jchensnorp: yeah like last week. but i looked and it didn't have the attachnative stuff in it so i thought you were still working on it
15:28snorpjchen: ah yeah I put a new one up
15:28snorpI thought
15:28snorpoh maybe I didn't
15:28jchenyeah i see it now. didn't get notified though
15:29snorppiece of crap
15:29snorpjchen: oh I just realized something about my patch
15:30snorpoh nm I tested it
15:30snorpbut I have a question
16:17nalexandereoger: I expect you'll be interested in the Send Tab disappearing reports ^
16:17nalexandereoger: might be linked to your devices work?
16:19eogeris there a bug on file?
16:22nalexandereoger: I think there is, but I don't know it! sebastian, grisha, njpark ^
16:36bkellysnorp: do you know if fennec builds work with icecc?
16:37snorpbkelly: haven't tried, but my guess is that it should
16:37snorpbkelly: assuming you have the ndk everywhere, etc
16:37bkellyhmm
16:37snorpoh doesn't icecc distribute the tools
16:37snorpso maybe that doesn't work
16:37bkellyyea, not sure how icecc would find it
16:41bkellysnorp: hmm.. do I have to do something special to get rustc for android?
16:41snorpbkelly: there is a special deal you have to run
16:41snorpbkelly: it prints the command in the error I think?
16:41bkellywas trying to follow these instructions: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_for_Android_build
16:41snorpit's some rustup command to download the android backend
16:41snorpyeah I think bootstrap might be busted :/
16:41bkellyah, yea... it does give the command
16:42bkellysnorp: DEBUG: configure: error: You must install the Android build-tools version 23.0.3. Try |mach bootstrap|. (Looked for /srv/.mozbuild/android-sdk-linux/build-tools/23.0.3)
16:42bkellyI just did mach bootstrap :-\
16:42snorpoh
16:42snorpyeah that's some bug with either bootstrap or the sdk, I'm not sure
16:43snorpif you just run 'android' from ~/.mozbuild/android-sdk-linux/tools you can install that build-tools thing
16:44nalexanderbkelly: snorp: it's basically impossible to install specific versions of the tools from the command line. Blame Google.
16:44nalexanderbkelly: you have to do it by hand :(
16:44snorpyeah, that
16:44nalexanderbkelly: I tried to fix it and wasn't able to make it happen.
16:44nalexanderbkelly: snorp: the long term approach is to move to Gradle, which does the tool installs correctly.
16:44bkellyit won't let me download it
16:44snorpright
16:45nalexanderSo, sorry -- I've tried to address it multiple times.
16:45nalexanderbkelly: eh? That's... not good.
16:45snorpbkelly: you should uncheck everything but the build-tools bit
16:46bkellyit doesn't even show build tools 23.0.3
16:46snorpwtf
16:46* snorp checks what he has
16:46bkellytrying 23.0.1
16:46snorpapparently I have 23.0.1, yeah
16:47bkellymade it past configure
16:47snorpcool
16:47snorpsorry
16:47nalexanderbkelly: ~/.mozbuild/android-sdk-macosx/tools/bin/sdkmanager "build-tools;23.0.3" should work, with your path adjusted.
16:47snorpsdk sucks
16:47bkellythanks
16:47bkellygoing to grab lunch while this compiles
16:47nalexanderbkelly: sorry that this isn't turnkey anymore.
16:48snorplunch is a good idea
17:20eogerif there a bug on file for about:home on android not reacting to click on tiles? I've had this problem for a while now
17:22sebastianeoger: Nightly? I see this in local builds after breaking gecko/browser.js
17:23eogerI'm using beta
17:24kats-luncheoger: do you see the same problem if you open a new tab?
17:24JanHeoger: what happens when you manually try to load an URL in that broken tab?
17:25kats-lunchmight be bug 1324205
17:25firebothttps://bugzil.la/1324205 NEW, nobody@mozilla.org Clicking on top sites sometimes does nothing
17:26eogerJanH white screen
17:26eogerif I open a new tab, about:home works
17:27eoger(only on this new tab, the old one is not fixed)
17:28JanHkats-lunch, eoger: that sound suspiciously like bug 1324205
17:28kats-lunchindeed
17:28eogerI'm getting it a lot
17:28JanHkats-lunch: but your logcat there is from beta, so doesn't include the browser console (with any JS errors) by default
17:29JanHoops, wrong bug
17:29JanHi meant to say: that sounds suspiciously like bug 1356563
17:29firebothttps://bugzil.la/1356563 FIXED, nchen@mozilla.com Race condition on startup that can break opening of initial/restored tabs
17:31eogertook a video of the problem, just to make sure we are talking about the same thing
17:31eogerhttps://gfycat.com/SophisticatedTinyFrenchbulldog
17:32JanHeoger: to confirm, you could turn on consoleservice.logcat and then look for logcat entries from BrowserConsole the next time you encounter this - if it's the same problem, you should see some JS errors about the window being undefined or suchlike
17:33JanHor try this add-on I think: https://addons.mozilla.org/android/addon/console/
17:33eogerI still have the faulty tab open, I'll do it right now
17:34eogerdoesn't log anything though :( maybe I need the page to reload
17:34JanHI think the error is only logged on startup
17:35eogerokay, I'm hitting this problem almost every day so I'll definitely have something
17:35snorpwhoa
17:35snorpthis is on beta?
17:35snorpas in the one that's getting shipped today?
17:36* snorp installs beta
17:36JanHsnorp: it's a race condition - for me, this only started happening frequently after the recent uBlock update
17:36snorpah, ublock you think
17:36snorpok
17:37JanHbut others have reported it before that as well
17:37JanHalso e.g. bug 1344892 made this happen much more frequently as well
17:37eogeractually, when I switch to the faulty tab, I see 2 errors in about:console
17:37firebothttps://bugzil.la/1344892 FIXED, nchen@mozilla.com Let native calls dispatch to XPCOM event queue
17:37eogeraTab is null, aBrowser is null
17:38snorpeoger: can you paste the full error?
17:38JanHeoger: that would be expected
17:38JanHbecause of the race condition, we fail to create the initial gecko-side tabs on startup, so they're open in the UI, but not in Gecko
17:39eogersnorp I couldn't get a stack trace sorry :(
17:39JanHso this sounds like its definitively bug 1356563
17:39JanHit's
17:39snorpJanH: what is racing, gecko session restore vs fennec session restore?
17:39JanHno, the Java UI starts dispatching all queued messages/events before the Gecko chrome window is ready
17:40JanHmost of the time for most people it works
17:40JanHbut sometimes (with add-ons, depending on phone, moon phase, whatever) the gecko chrome window takes longer to initialise and misses all those initial messages that were queued up from java before gecko was ready
17:41snorphmm
17:41eogerI've had this problem for a while, does that means it is in release too?
17:41snorpJanH: so that's maybe not so much a race, but the state is just set erroneously
17:41snorpeoger: I hope not...
17:41snorpjchen: ^^^^^ we need to get to the bottom of this
17:41snorpit sounds eventdispatcher/xpcom loop related
17:41snorpI'll try to debug here too
17:41jchenisn't it just fixed?
17:42snorpwell, the most recent patch would not affect beta
17:42eogerI'm using beta as my daily driver, and the merge was yesterday, and I had that problem for a while..
17:42snorpso probably not fixed in all cases at least
17:42snorpoh
17:42snorpeoger: wait so you're using 54?
17:42eoger53
17:42snorpyeah no new build yet
17:43snorpok
17:43snorpthat means it's gonna go to release :(
17:43* snorp sends mail
17:43jchenthe bug's existed for a while afaict
17:43eogeryup
17:44snorphmmm
17:44snorpjchen: but the fix on the bug doesn't apply for 53 does it?
17:44jchensnorp: need a rebased patch for older branches
17:45snorpah 53 does have the chrome-document-loaded thing
17:45snorpjchen: ok please do that
17:46snorpwe probably need to hold 53 for that
17:46eogersorry, I should probably have made that bug report before :(
17:47snorpeoger: no worries
18:23sebastianahunt: I just noticed that WebView does requests for /favicon.ico - even though we do not need that in Focus. I wonder if we should just return 404 in shouldInterceptRequest().
18:24ahuntI guess that works (until we find a website that uses /favicon.ico as an image in their actual page)
18:28sebastianahunt: I'm writing a test using MockWebServer and the random favicon.ico requests are driving me crazy :)
18:42mcomellagrisha: Are there docs to explain what are the account states (e.g. engaged, cohabiting) and why they exist?
18:43grishamcomella: there should be...and i keep meaning to put them together. nalexander had some state machine diagrams iirc that were mostly up to date
18:44nalexandergrisha: mcomella: https://people-mozilla.org/~nalexander/FxA_client_states.pdf is close to up-to-date for iOS.
18:44mcomellaWow! Yay! ty
18:44liuchelol
18:44grishathere it is
18:44nalexanderAnd so is https://people-mozilla.org/~nalexander/SyncStateMachine%20new.pdf
18:45mcomellabnicholson: ^ fyi
18:45njparksebastian: would there be another l10n push to focus soon?
18:46njpark(soon meaning this or next week)
18:46nalexandergrisha: I just pushed the Graffle to ~nalexander, so if you want to move those into the documentation that's being worked on, please do.
18:46sebastiannjpark: I can do an import now, let's see what's in there
18:46njparksebastian: cool, yeah it's been a week so probably a few changes
18:47grishanalexander: awesome, thanks!
18:47nalexanderNow... this mostly represents Android (FxA) and iOS (Sync).
18:48JanHsebastian: in https://reviewboard.mozilla.org/r/127712/#review133754, did you mean to ask "why the if-else?" or "why make sure onTabOpen... runs on the UI thread?"
18:50sebastianJanH: Yeah, basically would it break if we always postToUIThread()?
18:50mcomellagrisha: So does the account need to be in the "Married" state to do anything useful with it (e.g. Sync)?
18:53JanHsebastian: it shouldn't, since some codepaths (that load the startup tab from the background thread) will cause a redispatch anyway
18:53sebastianJanH: So the if-else is more or less an optimization to avoid the overhead?
18:54JanHsebastian: I just saw e.g. notifyListeners in Tabs.java following the same pattern and thought it nicer to avoid this where possible
18:54nalexandermcomella: yes. Married is when you have keys and tokens.
18:54JanHbut yes, it's not absolutely required (at least I hope so :-) )
18:54sebastianJanH: I wonder if this might make sense inside postToUIThread()
18:54sebastianassuming the check doesn't add overhead =)
18:55JanHor we might have some code that expects that posted stuff will always run only after we've returned to the event loop
18:55grishamcomella: you can also talk to fxa and do things like device registration whenever you have a sessionToken, so also in an Engaged state
18:56mcomellagrisha: At what point does the account need to be verified?
18:56sebastianJanH: Yeah, true. Maybe let's not introduce those kind of regressions. :)
18:56grishawhenever fxa tells you so after logging in, essentially
18:57mcomellaty
18:57grishawell, there is sign in verification, which could be skipped sometimes if you just logged in from the same ip, for example
18:57grishaand then there's email verification, which is a sign up thing
18:59nalexandermcomella: verification is required only to allow one to get Sync keys. If you wanted to use services that didn't require Sync keys, you'd never need to verify -- you'd have a sessionToken, from which you can get oauth tokens, and from there authenticate to other services.
19:00mcomellagrisha: Does `State.verified` represent the email or sign in verification?
19:01mcomella(and I assume Nick is referring to email?)
19:02flodst3fan: button title -> button label
19:02flod(just taking a quick look at the iOS strings)
19:02grishai wonder if that state is opaque to the client. there's a verified flag (as well as verfication reason/method) in the fxa auth server responses for /login endpoint, and others - see the api docs https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#post-v1accountlogin
19:04* grisha back in a bit, lunch
19:10snorpJanH: you've not seen bug 1356563 since the fix went in, right?
19:10firebothttps://bugzil.la/1356563 FIXED, nchen@mozilla.com Race condition on startup that can break opening of initial/restored tabs
19:10snorpor jchen, esawin, etc
19:15JanHsnorp: no, I didn't
19:16JanHsnorp: I had also switched my local build back and forth with and without the patch twice and the pattern was clear
19:16snorpJanH: great, thanks
19:29sebastiannjpark: I added a new test case: https://github.com/mozilla-mobile/focus-android/blob/master/app/src/androidTest/java/org/mozilla/focus/activity/WebViewDataTest.java
19:30njparksebastian: awesome, you spawn a local webserver it seems
19:31sebastianYeah
19:31njparksebastian: can i make it to host custom html files as well?
19:33sebastiannjpark: Yeah, in this case I let it return to resources from androidTest/assets
19:33njparksebastian: thanks for this, I should learn more about how you used it, maybe I can host a google ad and check whether it's blocked
19:45bkellymultiple phones sitting on my desk charging... flashbacks to fxos
19:49snorpbkelly: drink an emergency beer
19:49bkellysnorp: at least I get to use this pile of phones on my shelf
19:49snorpheh
19:49bkellyI pulled out my old n4
19:49snorpaka the best android phone ever made?
19:50snorpyou gotta be careful though
19:50snorpit will try to run away
19:50kbrosnanmy n4 said hello to the sidewalk in los gatos
19:51kbrosnanit was not much of a n4 after that
19:51bkellyI prefered the n5, but the wifi hardware is busted in that one
19:54snorpkbrosnan: ah the frictionless case strikes again
20:18* bkelly relearns the joys of udev rules.
20:18ahuntnjpark: on the topic of static analysis, theres also coverity. Its a proprietary tool, but a lot of FOSS projects get free access (including us IIRC). They run the analysis on their servers, and you need to request a login from someone to view the reports.
20:19jchenmy n4 is so physically bloated at this point that if it were a samsung it would have blown up by now
20:19ahuntIm not sure how useful it is for Java, but Ive seen it find major issues in a C++ project (I think the reports require logins precisely because they have found potential security bugs)
20:19njparkahunt: yeah it was mentioned too, I didn't think we have account with them anymore.. but I could be wrong
20:20njparkapparently jmaher is also looking into adding coverall to the gecko-dev, will ping him when he's back
20:20ahuntnjpark: https://scan.coverity.com/projects/firefox/
20:20ahuntIm not sure how thats different from https://scan.coverity.com/projects/firefox-mobile
20:21njparkahunt: the graph shows different data, but repo is same..
20:22ahuntIts possibly just different build configurations (I think they have to inject their tool into the build process, so it only analyses whatever gets built)
20:24njparkahunt: sent access request, I wonder who is the coverity admin @ mozilla
20:25ahuntnjpark: I think its also Sylvestre, but Im not sure anymore
20:27bkellysnorp: so, our mochitest test_openWindow.html does run on android
20:28bkellysnorp: but it doesn't exercise any of the background behavior
20:28snorpbkelly: yay?
20:28snorpbkelly: cool
20:28snorpbkelly: that's something then
20:28bkellysnorp: is there anything more we can write a test for here?
20:28snorpbkelly: not with current harnesses
20:28snorpsince they all require fennec to be running :)
20:28bkellysnorp: but can't fennec be running and not-foreground?
20:29snorpbkelly: not with how mochitest, etc, all work
20:29snorpbkelly: "not-foreground" really means "activity is not started at all"
20:29snorpbkelly: for what we care about wrt swc openWindow
20:30bkellysnorp: is that true? part of this call is to bring the app to the foreground even if its still running I thought
20:30snorpbkelly: right
20:30snorpbkelly: that's insignificant, though
20:30bkellyit is?
20:30snorpbkelly: the difficult path is when fennec isn't running at all and we receive a web push
20:31snorpbkelly: which is handled in a background service
20:31snorpbkelly: and then that sw wants to open a window
20:31bkellyyea
20:31snorpit's the same code I think? (start the activity)
20:31snorpbut the path is different
20:32bkellysnorp: I'm just thinking for a test coverage part its an equally valid scenario to test
20:32bkelly^part^point of view
20:32snorpsure
20:32snorpwell the thing we have now is probably ok too
20:34bkellyok
20:34bkellyI guess I just have to manually test for now
20:34bkellysnorp: how do I get something added to the manual test criteria for release?
20:37bkellysnorp: one of the things I was thinking of doing was to make LaunchOrBringToFront() return a MozPromise that resolves when the app is in the foreground
20:43bkellyI guess that would be difficult
21:18njparksebastian, ahunt: I made a quick summary of today's discussion in the same etherpad: https://public.etherpad-mozilla.org/p/fennec_codecoverage
23:42ahuntDoes it make sense to run fennec when the profile cant be created? GeckoProfile.forceCreateLocked() simply swallows any errors when creating the profile dir - but plenty of downstream code indirectly expects the profile dir to exist, and will crash if it doesnt - so Im guessing throwing then and there would be more sane? (I dont know if the code
23:42ahuntthat would crash even gets run in this scenario though)
23:43ahuntActually, I could just test exactly that scenario locally to find out
20 Apr 2017
No messages
   
Last message: 157 days and 4 hours ago