[00:01:52] [WikipediaMobile] yuvipanda force-pushed v3.1.2-iOS from 0af3bed to c11f75f: http://git.io/gsX7GQ [00:01:52] [WikipediaMobile/v3.1.2-iOS] Directly steal wesley's CSS - YuviPanda [00:01:52] [WikipediaMobile/v3.1.2-iOS] Added toggle.js with calls to doScrollHack - YuviPanda [00:01:52] [WikipediaMobile/v3.1.2-iOS] Don't scroll to top after every expansion - YuviPanda [00:02:06] Project WikipediaMobile - Nightly builds build #293: SUCCESS in 6.8 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/293/ [00:02:06] * yuvipanda: Directly steal wesley's CSS [00:02:07] * yuvipanda: Added toggle.js with calls to doScrollHack [00:02:08] * yuvipanda: Don't scroll to top after every expansion [00:02:08] * yuvipanda: Hide keyboard once search item has been clicked [00:02:09] * yuvipanda: UIWebView doesn't like upper case HTTP. Needs lower case [00:02:09] * yuvipanda: Fix issue with scrolling past bottom on iOS 4.x [00:02:09] * yuvipanda: Move to iScroll-lite [00:02:10] * yuvipanda: Reset scroll to top on opening new pages [00:08:22] yuvipanda: thankfully someone people are putting in their iOS versions for reviews [00:10:06] iOS 4.2/4.3 [00:10:14] tfinc: ok [00:11:06] whats surprising are the iPhone4's that are reporting issues [00:11:13] as they can upgrade to 5.x [00:12:30] and IIRC they get a proper OTA too [00:13:13] yes [00:19:39] Reedy: wow. i just read the reviews for the wikipedia iphone app. for the latest version, i've yet to see higher than 2/5 [00:19:40] :( [00:20:05] Reedy: mostly iOS 4.2/4.3 issues. iScroll for the fail [00:20:48] yuvipanda: so if we can't get 4.2 to work reliably we can [00:21:07] 1) drop support and move forward [00:21:23] 2) rollback to 2.2.2 and create a brand new app for 3.1.2 [00:21:43] [WikipediaMobile] yuvipanda created v3.1.2-iOS-experimental (+2 new commits): http://git.io/j55sTg [00:21:43] [WikipediaMobile/v3.1.2-iOS-experimental] Re-added full common.css - YuviPanda [00:21:43] [WikipediaMobile/v3.1.2-iOS-experimental] Just the changes wesley made. Minimizing diff - YuviPanda [00:21:46] tfinc: ^ [00:21:48] can you test this? [00:21:50] x) fix iOS for Apple. [00:21:54] note that it is a different branch [00:21:56] Project WikipediaMobile - Nightly builds build #294: SUCCESS in 6.5 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/294/ [00:22:00] sure [00:22:33] i'm trying to minimize the diff from 'sucks majorly' to 'works properly' so we can replicate that in JS [00:23:24] tfinc: not a fan of maintaining 2.2.2 as well. We should make it work at an acceptable level and drop support from next version (can't drop support now, then 4.2 users will be stuck with an app that doesn't work at all) [00:25:22] new branch works fine [00:25:32] subjectively faster [00:25:58] okay, let me narrow down the rules some more [00:26:42] Reedy: we could use some iOS 4.3 testers [00:26:59] [WikipediaMobile] yuvipanda pushed 1 new commit to v3.1.2-iOS-experimental: http://git.io/tzvOfg [00:26:59] [WikipediaMobile/v3.1.2-iOS-experimental] Re-added the zoom CSS properties - YuviPanda [00:27:02] tfinc: ^ [00:27:06] Reedy: if can get any to join irc then do invite [00:27:08] pulling [00:27:12] Project WikipediaMobile - Nightly builds build #295: SUCCESS in 6.9 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/295/ [00:27:12] yuvipanda: Re-added the zoom CSS properties [00:28:18] [WikipediaMobile] yuvipanda pushed 1 new commit to v3.1.2-iOS-experimental: http://git.io/5YJIsw [00:28:18] [WikipediaMobile/v3.1.2-iOS-experimental] Re-added pre's whitespace property - YuviPanda [00:28:31] Project WikipediaMobile - Nightly builds build #296: SUCCESS in 7 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/296/ [00:28:31] yuvipanda: Re-added pre's whitespace property [00:29:48] subjectively worse [00:30:02] tfinc: how subjectively? [00:30:05] jittery jittery bad? [00:30:08] or [00:30:10] just a bit worse? [00:30:41] also, try it now [00:30:41] the first scroll is slower and scrolling over media is slow [00:30:53] pulling [00:31:48] * yuvipanda eats more chocolae [00:33:53] subjectively better [00:33:55] :D [00:34:18] minus images and info boxes of course .. those are slow [00:34:52] ok [00:36:02] but thats been that way for this whole release [00:36:51] yuvipanda: so i've been thinking about all the complaints about the search box [00:36:54] thats an easy fix [00:36:54] tfinc: ^ [00:37:02] [WikipediaMobile] yuvipanda pushed 2 new commits to v3.1.2-iOS-experimental: http://git.io/xXi9xA [00:37:02] [WikipediaMobile/v3.1.2-iOS-experimental] Re-add !important on selectors not using a wildcard - YuviPanda [00:37:02] [WikipediaMobile/v3.1.2-iOS-experimental] Enable slightly more 'complex' selectors. No wildcards - YuviPanda [00:37:07] we just need to accelerate our work on the disappearing toolbar [00:37:09] ala kindle [00:37:15] Project WikipediaMobile - Nightly builds build #297: SUCCESS in 6.8 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/297/ [00:37:15] * yuvipanda: Re-add !important on selectors not using a wildcard [00:37:16] * yuvipanda: Enable slightly more 'complex' selectors. No wildcards [00:37:20] yes [00:37:23] then those readers can browser to their hearts content [00:37:29] its what i always wanted to do [00:37:35] I think once this fire's out we need to re-asses 1.2 a bit [00:37:38] full un obstructed reading with one tap search [00:37:43] I don't see the beta going out on Monday, for example :) [00:37:52] yes [00:38:00] tfinc: can you pull and test those? [00:38:07] intercontinental debugging loop [00:38:16] sure [00:39:09] too bad this loop blocks() like crazy ;) [00:40:34] yuvipanda: far worse [00:40:50] almost all the kinetic scrolling is gone [00:40:59] ok [00:41:03] git checkout HEAD~1 [00:41:06] then try again [00:41:13] k [00:41:27] HEAD~1 ? [00:41:36] guessing you just meant HEAD there [00:41:38] that's 'one commit before current one' [00:41:45] ahh ok [00:44:35] yuvipanda: do you have any thoughts on why it takes so long to get search focus ? [00:44:47] tfinc: has it been consistently that way? [00:44:58] not happening on my 4.3 sim [00:45:04] for 3.x yes [00:45:16] on 4.2 and 4.3? [00:45:16] it takes about 3-5 seconds to grab it [00:45:18] 4.2 [00:45:57] not particularly sure. Will need to do more console.log debugging [00:47:07] tfinc: how's HEAD~1 [00:47:09] ? [00:47:20] its fine [00:51:47] [WikipediaMobile] yuvipanda pushed 1 new commit to v3.1.2-iOS-experimental: http://git.io/O98syQ [00:51:47] [WikipediaMobile/v3.1.2-iOS-experimental] Disable a slightly more complicated selector - YuviPanda [00:51:52] tfinc: ^ [00:52:00] Project WikipediaMobile - Nightly builds build #298: SUCCESS in 6.6 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/298/ [00:52:00] yuvipanda: Disable a slightly more complicated selector [00:53:31] pulling [00:54:29] hmm .. branch merge fail .. /me goes to see what happened [00:55:48] had to switch to master, pull, then branch switch back [00:56:05] tfinc: you were on a 'headless' branch [00:56:10] hence the issue :) [00:56:18] oh git .. you always treat me something new [00:56:24] git branch would've showed you were not on any branch [00:58:28] ah yes, forgot to mention that in the email [00:59:39] tfinc: jerky? [01:00:07] yuvipanda: its fine actually [01:00:46] sweet [01:00:52] test it around and see if it is as fine as it was [01:01:25] k [01:04:59] tfinc: also atleast *some* navboxes should be 'fine' now. The rule now is much more restrictive than how it was [01:05:14] yes. i can see that [01:05:18] it seems much better [01:07:07] tfinc: browse around and see if scrolling hits anything. [01:10:25] k [01:19:38] crashed the app :D [01:19:59] heavy browsing on "Greece" and "Barack Obama" [01:23:59] tfinc: ^ [01:24:09] [WikipediaMobile] yuvipanda pushed 1 new commit to v3.1.2-iOS-experimental: http://git.io/eAwxlA [01:24:09] [WikipediaMobile/v3.1.2-iOS-experimental] Enable a single wildcard selector - YuviPanda [01:24:13] tfinc: ^ [01:24:16] k [01:24:24] Project WikipediaMobile - Nightly builds build #299: SUCCESS in 7.8 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/299/ [01:24:24] yuvipanda: Enable a single wildcard selector [01:24:26] just testing a theory. [01:25:30] building [01:25:45] * tfinc will need a day off when this settles [01:27:51] subjectively ok [01:27:56] but we need a better way to measure this [01:28:05] its getting to be too hard too tell any difference [01:28:11] tfinc: think binary [01:28:17] jerky or scrolly [01:28:21] i can do binary [01:28:24] i'm just trying to isolate what was causing us problems [01:28:27] so binary is good enough [01:28:32] so, 0 or 1? [01:28:55] jerky or scrolly? [01:29:04] scrolly [01:29:14] * yuvipanda goes to find a wall [01:29:19] looks like the problem is *not* wildcard searches [01:29:21] slightly slower on tables [01:29:36] let me delete the app and do a clean build [01:29:39] just to make sure [01:29:46] do that [01:29:48] yeah [01:31:55] jerky within info boxes and images .. fast on text [01:32:36] [WikipediaMobile] yuvipanda pushed 1 new commit to v3.1.2-iOS-experimental: http://git.io/XeDEaQ [01:32:36] [WikipediaMobile/v3.1.2-iOS-experimental] Enabling even more wildcard styles - YuviPanda [01:32:37] tfinc: pushing something now, try that. [01:32:49] Project WikipediaMobile - Nightly builds build #300: SUCCESS in 6.8 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/300/ [01:32:49] yuvipanda: Enabling even more wildcard styles [01:32:52] pulling [01:34:28] yuvipanda: jerky [01:34:34] really really jerky [01:35:30] ok [01:35:51] Is jenkinsbot working to compile .apk again yet? [01:36:14] We have a beta tester looking for the latest wiktionary app build. [01:36:54] Amgine: no, sadly it is not [01:37:14] [01:37:38] Amgine: I fixed it on my api-move branch, but that's not been merged in yet [01:37:40] [WikipediaMobile] yuvipanda pushed 2 new commits to v3.1.2-iOS-experimental: http://git.io/oyB36w [01:37:40] [WikipediaMobile/v3.1.2-iOS-experimental] Revert "Enable a single wildcard selector" - YuviPanda [01:37:40] [WikipediaMobile/v3.1.2-iOS-experimental] Revert "Enabling even more wildcard styles" - YuviPanda [01:37:52] Project WikipediaMobile - Nightly builds build #301: SUCCESS in 6.4 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/301/ [01:37:53] * yuvipanda: Revert "Enable a single wildcard selector" [01:37:53] * yuvipanda: Revert "Enabling even more wildcard styles" [01:38:40] Excellent sort of news, yuvipanda. [01:51:32] tfinc: this commit should both scroll properly *and* have proper styles [01:51:34] [WikipediaMobile] yuvipanda pushed 1 new commit to v3.1.2-iOS-experimental: http://git.io/L8mD2w [01:51:34] [WikipediaMobile/v3.1.2-iOS-experimental] Moved wildcard css selectors into wildcard js selectors - YuviPanda [01:51:41] let me test [01:51:47] Project WikipediaMobile - Nightly builds build #302: SUCCESS in 6.8 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/302/ [01:51:47] yuvipanda: Moved wildcard css selectors into wildcard js selectors [01:53:00] yuvipanda: i'll have to do a market run in about 20min [01:54:05] tfinc: ok [01:56:03] tfinc: how does this one turn up? [01:57:04] *feels* more sluggish [01:57:11] let me load some more articles [01:57:25] but as i said before .. comparisons are getting really hard [01:58:19] binary would do good [01:58:28] this *should* render navboxes properly [01:58:31] so essentially [01:58:38] 1. do navboxes which were messed up before rendering properly [01:58:45] 2. can you actually scroll? [01:59:01] yes. i have kinetic scrolling [01:59:47] if i have to do binary then i'll call this "scrolly" [01:59:56] and styles? [02:00:07] give me an article that would had been busted [02:00:10] what kind of nav [02:00:18] sacramento [02:00:23] sacrament, california [02:00:25] k [02:00:35] infobox should be bounded, not extending far to the right [02:00:42] copy pasting from your notes on the ether pad :) [02:00:57] :) [02:01:03] if you have a 5.0 device, load market release there and use them side by side for comparison [02:01:08] (or your android) [02:01:09] k [02:01:42] the info box for sacramento is *still* not correct [02:01:50] the image is centered [02:01:58] but the gray box goes way off screen [02:02:01] * tfinc goes to compare against 5.0 [02:02:36] 5.0 has the same bug [02:03:05] check safari [02:03:30] tfinc: ^ [02:03:55] safari (5.0) in our beta does *not* show the issue [02:04:00] not the beta [02:04:19] you need to opt out or use a device that had not opted in [02:04:19] let me opt it out [02:04:30] pass me a bit.ly opt out link [02:04:46] one second [02:05:30] safari (4.2) !beta renders correctly [02:06:01] damn [02:06:57] its the "nicknames" section that makes it run over [02:06:59] " [02:07:36] http://bit.ly/mobilewpoptout [02:08:51] tfinc: check other cities? [02:09:06] http://bit.ly/wmoptout … will work even better [02:09:54] tfinc: http://bit.ly/mobilewpoptout [02:09:57] err [02:10:00] http://bit.ly/wpoptout [02:10:04] there [02:10:25] hmm, should be 'm' because it is also beta across projects I guess [02:11:12] safari (5.0) !beta renders correctly [02:11:14] trying other cities [02:18:40] general were ok [02:18:45] Mumbai info is slow [02:18:49] as its pretty complex [02:20:23] no nav box problems though [02:21:27] hmm [02:21:32] sacramento is fine on android [02:22:42] [WikipediaMobile] yuvipanda pushed 1 new commit to v3.1.2-iOS-experimental: http://git.io/CYqoPg [02:22:42] [WikipediaMobile/v3.1.2-iOS-experimental] Add missing word break property to body - YuviPanda [02:22:55] Project WikipediaMobile - Nightly builds build #303: SUCCESS in 6.6 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/303/ [02:22:55] yuvipanda: Add missing word break property to body [02:22:57] ok .. time to head to the market [02:24:07] bbiab [02:26:36] ok [03:24:54] back [03:25:07] wow yuvipanda3 … have we upgraded ? [03:25:09] ;) [03:25:15] we've confused :D [03:25:29] unpacking groceries … yell if you need anything [03:25:51] haven't been able to figure out what's the issue with those. Will poke if I need you to test [03:26:17] k [03:51:10] Where's the best place to leave feedback regarding the iOS app? [03:52:02] AxelBoldt: emailing mobile-feedback-l@lists.wikimedia.org would reach the entire team [03:52:51] OK, thanks [05:14:38] tfinc: still not quite able to figure out what the sacramento deal is [05:15:01] i've tried a couple of different approaches to setting the styles, and the styles are being set. Don't seem to be affecting it though :( [05:15:17] it is, however, relatively minor and I hope jon would be able to help tomorrow [05:16:27] [WikipediaMobile] yuvipanda pushed 1 new commit to v3.1.2-iOS-experimental: http://git.io/sWIVMQ [05:16:27] [WikipediaMobile/v3.1.2-iOS-experimental] Fix stray . in addClass - YuviPanda [05:16:40] Project WikipediaMobile - Nightly builds build #304: SUCCESS in 6.9 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/304/ [05:16:41] yuvipanda: Fix stray . in addClass [05:16:43] YuviPanda: don't worry about it then [05:16:52] tfinc: the slow search bar issue [05:16:52] the delay in search focus is more annoying [05:16:55] how is that going ? [05:17:03] yeah, i've not been able to repro it on 4.3 [05:17:04] sim [05:17:14] what can i do to help you debug that? [05:17:25] does it take 3-5 seconds when you type it to when it the *character* appears? [05:17:29] or when the *result* appears? [05:17:46] or just focusing itself? [05:18:03] it takes that long to see a blinking cursor [05:18:16] and for the input box to have the orange border [05:18:30] tfinc: chrome.js delete line 250 [05:18:34] and see if that improves things? [05:18:38] there is also a delay in tying characters [05:18:43] likely the round trip for type ahead [05:18:45] k [05:19:02] well, that shouldn't stop you from *typing* them [05:19:15] #search from doFoucsHack() ? [05:21:00] yes [05:21:04] tfinc: yes [05:21:21] to clarify .. it sometime take up to 3-5 second for the *keyboard* to come up [05:21:30] building with line 250 change [05:22:04] hmm [05:24:50] no change with line 250 delete [05:25:08] hmmm [05:25:18] let me make another experimental branc [05:25:21] hand push things to you [05:25:25] intercontinental debugging [05:25:30] tfinc: also do you know if this happens on 4.3? [05:25:43] also, whats going on in the app when the loading animation stop (spinny curosr) but the article has loaded yet [05:25:51] in long articles it can take 5-10 seconds [05:26:10] s/has/hasn't [05:26:29] andrew jackson, for example. [05:26:36] tfinc: I think that's how long it takes for the webview to process that much HTML and load those into the DOM [05:26:44] (which bogs down my netbook/T10) [05:26:44] that is, IIRC, a blocking operation [05:27:08] we *could* use a css animation there which *might* continue spinning [05:27:13] but not sure, will have to check [05:27:24] solution is to use the API and populate items section by section [05:27:25] how can we speed up the actual process ? [05:27:33] thats far more useful [05:27:36] of DOM parsing? [05:28:17] yes [05:28:35] having a nice animation but still having it take 5-10seconds sucks just as much [05:29:32] tfinc: i'm not sure. [05:29:36] i'll look into it [05:30:58] I could speed it up a little bit with hacks on when the section collapsing code executes [05:31:18] but honestly, I don't want to do work on that with the MF scraper. Much better off putting those perf fixes into the API based code [05:32:27] thats fine [05:32:44] i care about making it faster [05:32:50] me too. [05:32:54] and the api needs to make that happen [05:33:01] the API already gives us per section data [05:33:11] I can do things like add it to the DOM only when expansionh appens [05:33:43] do what i suggested in the email [05:33:47] async load [05:33:59] dont block [05:34:06] we should never block if we can show a user content [05:34:07] see, the network never blocks [05:34:14] ah [05:34:17] that kinda block. [05:34:17] yes [05:34:24] that's what I meant. [05:34:32] but let's first get this fixed and pushed out [05:37:26] [WikipediaMobile] yuvipanda created v3.1.2-iOS-search (+1 new commit): http://git.io/QHSQYg [05:37:26] [WikipediaMobile/v3.1.2-iOS-search] Minor debugging statements for search issues - YuviPanda [05:37:31] tfinc: ^. Build, and look at logs [05:37:38] it'll trigger a message when focus actually hits [05:37:39] Project WikipediaMobile - Nightly builds build #305: SUCCESS in 6.8 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/305/ [05:37:43] and when keypress happens [05:37:47] k [05:37:52] tell me if the log message and you touching are instantaneous [05:37:54] same with keypress [05:37:55] * tfinc changes branch [05:39:10] * tfinc builds [05:41:53] this only captures the time of the first key input [05:42:01] so *after* the search window has focus [05:42:22] tfinc: is there latency between when you touch and when the search box has focus? [05:42:27] yes [05:42:32] thats the core issue [05:42:38] sometimes it takes 3-5 seconds [05:42:52] from the users standpoint they tap on search [05:42:58] and nothing happens for 3-5 seconds [05:43:11] is there latency between when you touched and when the message 'touch started on' occurs? [05:43:21] message on the XCode log, that is [05:43:22] yes [05:43:23] ? [05:43:26] hmmmm [05:43:31] the first message is 'Key press happening!' [05:43:37] but that only starts after the window has focus [05:43:43] there is no message before that [05:44:12] you don't get a message saying 'Touch started on search'? [05:44:14] as a message? [05:44:15] at all? [05:44:18] i do not [05:44:25] 2012-04-08 22:42:05.349 Wikipedia-iOS[1610:307] [INFO] hideAndLoad origUrl http://en.m.wikipedia.org/wiki/Reef [05:44:26] 2012-04-08 22:42:05.365 Wikipedia-iOS[1610:307] [INFO] Apparently we are connected = true [05:44:27] 2012-04-08 22:42:07.362 Wikipedia-iOS[1610:307] [INFO] navigating to http://en.m.wikipedia.org/wiki/Reef [05:44:28] 2012-04-08 22:42:07.375 Wikipedia-iOS[1610:307] [INFO] enabling language [05:44:29] 2012-04-08 22:42:14.752 Wikipedia-iOS[1610:307] [INFO] Key press happening! [05:44:45] 2012-04-08 22:42:14.752 Wikipedia-iOS[1610:307] [INFO] Key press happening! [05:44:45] 2012-04-08 22:42:14.915 Wikipedia-iOS[1610:307] [INFO] Getting search results for term: [05:44:46] 2012-04-08 22:42:15.616 Wikipedia-iOS[1610:307] [INFO] Did you mean? [05:44:47] 2012-04-08 22:42:15.629 Wikipedia-iOS[1610:307] [INFO] searchParam [05:45:21] "Key press happening" only happens once .. but thats the exact order in Xcode [05:45:26] no other messages [05:45:42] hmmm [05:45:44] that's weird [05:46:58] tfinc: try this commit? [05:46:58] [WikipediaMobile] yuvipanda pushed 1 new commit to v3.1.2-iOS-search: http://git.io/ENTF_A [05:46:58] [WikipediaMobile/v3.1.2-iOS-search] Move doFocusHack to be before DOM load - YuviPanda [05:47:11] Project WikipediaMobile - Nightly builds build #306: SUCCESS in 7 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/306/ [05:47:12] yuvipanda: Move doFocusHack to be before DOM load [05:47:26] pulling [05:49:20] no difference [05:50:23] no difference in the logs? [05:51:45] no difference [05:52:43] gah [05:52:47] * YuviPand_ checks logs [05:53:00] ok [05:53:01] nothing [05:53:10] tfinc: press the search button? [05:53:13] and see if that gets logged? [05:53:13] YuviPand_: http://mobile.slashdot.org/story/12/04/08/1432210/wikipedia-mobile-apps-switch-to-openstreetmap [05:53:19] saw that [05:54:15] search icon? [05:54:24] 2012-04-08 22:54:58.131 Wikipedia-iOS[1648:307] [INFO] Touch started on search [05:55:00] hmm [05:55:18] so touching the icon shows the status message but dot *not* get focus [05:55:30] does* [05:56:11] tfinc: try this commit? [05:56:30] * tfinc waits [05:56:31]