mozilla :: #mobile

8 Sep 2017
02:01spohlis there a way to log output from a mochitest to the console when running the test in an android emulator?
02:24jchenspohl: is the output in `adb logcat`?
04:01spohljchen: yes, it is! thank you!!
06:23freesamaelAnyone know if there's a way to attach gdb when running mochitest on android? "mach run --debug" works for normal runs, but is there an equivalent way for "mach mochitest"?
07:25KWierso|afkfreesamael: if mdn is right, sounds like | ./mach mochitest --debugger=gdb | might work
07:27freesamaelKWierso|afk: that doesn't seem to work for fennec, unfortunately :/ I tried that but it doesn't attach debugger
07:28freesamaelAlso tried jimdb/bin/gdb and got "No rule to make target 'mochitest-remote'"
12:31knafragI think I found a bug in firefox focus on android (more specifically firefox klar). Could somebody please confirm that I have the right idea of what should happen, before I file a bug for nothing?
13:01sebastiandamn. too late.
13:14esawindroeh: which ad-blocking add-ons have you tested with custom tabs?
13:33droehesawin: I didn't test extensively or anything, just a quick check with uBlock Origin
13:34esawindroeh: ublock origin is longer working for me, not sure if that was the switch to webextension or something on our side
13:35droehesawin: Interesting!
13:36RyanVMhuh, it broke for me on Nightly awhile back, but the webext version got it working again
13:36esawinRyanVM: right, not sure if that's related, but I'm testing it with custom tabs
13:36esawinRyanVM: works for me now in fennec
13:36RyanVMah, ok
13:37RyanVM(and oh god, mobile web UX is terrible w/o an ad blocker)
13:39droehesawin: ugh, yep, confirmed it's broken here now as well
13:40esawindroeh: debugging add-on integration, should be fun...
14:34rnewmangandalf: I did an en/fr build, installed it on a device set to fr-FR, did not switch locale, and the entire app is in French apart from the geolocation popup
14:36rnewmanthe strings are there, and it works fine if I switch language inside Fennec => initial OS locale isn't reflected
15:09esawinfennec has also issues with ublock when restoring tabs
15:11esawincould be a race condition that we consistently fail at with custom tabs
15:13rnewmangandalf: I'm testing your patch and mine, see if those together fix things.
15:29gandalfrnewman: did you clear data in Android for the app?
15:29gandalfbecause the reporter stated that that's what he had to do
15:47rnewmangandalf: I started from a clean install
15:50rnewmangandalf: aaand now it's back to showing the wrong locale
15:50rnewmanI'm confident in the Java code -- the logging shows that it's workign
15:51gandalfwith or without your patch?
15:52rnewmanwith my patch. I mean: I'm not sure your change to reflect OSPreferences is sufficient
15:52gandalfok, I'll test it with your and mine patches
15:52rnewmanyeah, run with that and see if everything you get from Java is as expected
16:15rnewmanFYSA: I filed Bug 1398209 to track bugs relating to showing the wrong strings when switching locales.
16:15firebot NEW, [meta] UI elements showing incorrect locale
17:33grishamcomella: liuche if I disable pocket stories from displaying in AS, will they also not be fetched as well? that would be my expectation
17:35mcomellagrisha: They aren't fetched:
17:36mcomellaBut I assume existing stories will be cached
17:36mcomella*remain cached
17:36grishagreat, thanks for confirming. not fetching is good enough for me
17:47gandalfrnewman: does your r+ on my dirtyhack for OSPreferences::Refresh indicate that you agree with the general approach to replace intl.locale.os with FFI?
17:52JanHfreesamael: there should be an option to start mochitests paused, so you could use that, connect the debugger to the already running instance and then trigger the test
18:01rnewmangandalf: no, I will review that next week
18:02rnewmanjust r+ing the "oh, guess we need to reload preferences when the preferences change" fix
18:03rnewmanIf the FFI solution is (still?) basically `BrowserLocaleManager.getInstance().systemLocale`, then I am probably in favor
18:04gandalfcool. I think it'll need a bit of guidance on how to make it also trigger OSPreferences::Refresh on the C++ side when locale changes.
18:04gandalfbut we can deal with it in 58
18:04gandalfand it would be sweet to switch from systemLocale to systemLocales :)
18:05rnewmanshould be possible
18:09gandalfok, gonna test with your patch now. If it gets the intl.locale.os updated, I think I can fix the other side
18:15gandalfyour emoji game is strong
18:15gandalfI can't even get a smiley face right from my keyboard
18:56gandalfrnewman: it works!
18:57gandalfrnewman: also, I have the patch for Strings.flush in bug 1390822 with r? on you. If you prefer to land it in your patch, feel free to close my bug
18:57firebot ASSIGNED, Gecko-side strings (Strings.browser.GetStringFromName) aren't updated after a locale change
19:54rnewmangandalf: do we always send Locale:Changed when only the OS locale has changed?
19:55rnewmanI put the flush in two places to account for that
21:20mcomellamkaply: Hey - I finished up with the specs so I just wanted to let you know. is the next bug. I don't think there's anything left to ride the trains so we don't have to deal with it right away but soon!
21:20firebotBug 1396986 NEW, Update distributions suggestedsites specs to match new AS format
21:20mcomella(there's a NI for you there)
22:10gandalfrnewman: yeah, I thought about it, but decided that since Java controls it, Java decides. In LocaleService I would chain it so that osprefs:system-locales-changed triggers potential locale change and only if the result list of locales differs I'd fire `intl:app-locales-changed`
22:19rnewmangandalf: well, browser.js is really the JS-implemented part of Fennec, rather than being part of Gecko
22:19gandalfright, but Locale::Change and Locale::OS are both coming from Java, right?
22:20rnewmanyes, and they mean different things: Locale:Changed means the user picked one in the locale picker (with null meaning "System default")
22:20rnewmanand Locale:OS means we know what locale the OS is using
22:21rnewmanso if the user elected to use the OS locale, and the OS locale changes, we will only send Locale:OS
22:21rnewmanindeed, the code running at that point doesn't already know whether the user is matching (it can find out, but right now it doesn't)
22:22rnewmanso browser.js is stuck in the middle: if it sees Locale:OS, it doesn't actually know whether it needs to invalidate its strings, because it doesn't control loading the strings
22:23rnewmanthe safe thing to do is to just flush in both cases
22:25gandalfcould Locale::Changed be fired in result of Locale:OS after it negotiated locales and identified that the change will happen?
22:25gandalfthis way Locale:OS is just informing about OS changes, and Locale:Changed about Fennec's locale changing
22:26gandalfnot that I think it's a big deal (OS locale changes and Fennec locale changes are rare, if we flush twice during it, I think it's ok)
22:27rnewmanit could, but that's a slightly more involved change
22:27gandalf(the only reason more pragmatic than code organization to clean it up would be to avoid string flushes when OS locale changes and Fennec's locale doesn't change in result)
22:27rnewmanas in, it's a change of behavior, not a fix
22:27rnewmanI'm mostly unconcerned with perf here: the only two situations in which this occurs are when Fennec is in the background or Settings is open
22:28rnewmanand the OS change is definitely always in the background
22:39gandalfthen the potential double flush shouldn't be a problem
9 Sep 2017
No messages
Last message: 12 days and 6 hours ago