[10:58:59] Hey everyone [10:59:14] The jQuery Mobile meeting will start in a minute [10:59:20] hi [11:00:01] This is for team member only, so please feel free to listen but don't jump in with support requests. #jquery-mobile is the right place for that [11:00:08] Agenda docs here: [11:00:10] https://docs.google.com/document/d/18FwdwDV3-z6ecgSE2sKnZissug7qUGxzF1Al9D5TYqc/edit [11:00:32] Roll call, who do we have here [11:00:40] here [11:00:42] her [11:00:43] e [11:00:50] <- me [11:01:01] sounds like the gang's all here [11:01:26] so first off beta 1 went out on Monday and the response has been overwhelmingly positive [11:01:40] so thanks to everyone here for your hard work [11:01:58] Great job, everyone. Big improvements all around, I think :) [11:02:36] You bet! [11:03:04] So there is always some fallout from a release so the first thing I wanted to do is identify any issues or regressions that popped out of Beta 1 so we can track 'em [11:03:22] looking for issue #'s and links [11:03:41] We're getting a lot of the duplicate click type issues being filed [11:04:03] yeah. removing that vclick+click binding fixed that [11:04:07] but it's post-beta [11:04:24] when is beta 2? [11:04:26] so that is probably the biggest thing we need to discuss [11:04:39] do we need a Beta 1.1? [11:05:00] beta 2 should happen in 4 weeks max [11:05:07] so that is a question [11:05:37] we need to get that fix out asap to stop the issues [11:05:40] kin/scott - can you summarize the vclick issue right now so everyone is up to speed? [11:06:01] if backbtn is disabled, it only shows up in dialog close buttons [11:06:27] Firefox desktop, and Safari desktop, go back 2 steps when clicking the generated "fake" back buttons [11:06:39] in a nutshell [11:06:42] so, they're disabled by default now, but dialogs still have them [11:07:17] we can't listen to both vclick and click [11:07:18] which makes sense to add them to dialogs, right? [11:07:22] issue # ? [11:07:57] right. the following commit closes the issue: [11:08:17] https://github.com/jquery/jquery-mobile/commit/c227535bd7c5d7e60b535eaba178cf6aa5af7389 [11:08:50] 2 issues here. One is that Kin identified a touch target bug in Android 2.1 [11:09:06] I'm not sure if that one's avoidable on our end [11:09:30] stranger issue is when that occurs, it often makes a blank page. That part I don't understand. [11:10:07] kin - any theories on the blank page? [11:10:09] it'd be one thing if 2.1 sometimes went to the wrong page, due to their own touch target bugs [11:10:30] but going to a blank page suggests something is wrong with the path on the incorrect target... right? [11:10:38] Not sure about the blank page thing... I'd have to see it [11:10:50] the bottom line is that *ALL* webkit variants [11:11:07] have situations where the touch target sometimes doesn't match the mouse/click target [11:11:35] that was the main reason we backed off of performing the main action on vclick [11:11:40] for alpha 4.1 [11:11:59] doing so really did reduce the number of times this situation rears its head [11:13:23] So scott, the main reason for the move was something to do with the location bar [11:13:42] do you know what the exact event is that you need to prevent that causes it to drop? [11:13:47] well, is there any way to bind to vclick ONLY to preventDefault, but then return? And let real click handle the transition? [11:13:59] touchend catches it early enough [11:14:11] if you prevent default on touchend, no address bar [11:14:26] ok so it's the touchend event [11:14:33] sure, any really [11:14:41] but touchstart is too dangerous [11:14:53] prevents scrolling, etc :) [11:15:05] prevents scrolling only on Android [11:15:17] prevents form elements and mouse events on all platforms [11:15:17] you sure? [11:15:26] we'll need to check on that [11:15:34] yeah all platforms prevent scrollin on touchmove [11:15:41] kin did a lot of event testing [11:15:43] android is the only one that requires touchstart to be preventdefault [11:15:58] to kill a scroll [11:16:16] sure. we're talking about different things [11:16:35] Well what I'm wondering is if we can just listen for touchend [11:16:38] I was just saying if we preventDefault on any touch event (start, move, end) it'll prevent address bar [11:16:42] yep [11:16:50] and perform the preventDefault there, versus moving the action execution to vclick (aka touchend) [11:17:20] yep. only drawback is we'll go back to the delay in page requests we had before [11:17:22] so I have a test case you can use to see what the impact of a preventDefault is [11:17:31] but I understand that's probably necessary [11:17:45] scottjehl: yeah, but that's the only way to avoid all these problems [11:17:52] right [11:18:10] for 4.1 we decided to give feedback right away [11:18:23] but live with the delayed action to guaranteed accuracy [11:18:38] okay, so I started work on this before. Basically we just need the logic for "is this going to be used for ajax?" to be abstracted out [11:19:00] ?? [11:19:41] should we have a quick skype call after this to hash this out? [11:19:43] then we can add it to our existing vclick handler and preventDefault there. But we also need to use it in the click handler [11:19:51] seems like this is tough to do here [11:20:42] also, I was finding that if I called preventDefault in the vclick handler that we use for setting active state, it wasn't doing anything for address bar hiding. [11:20:51] toddparker: yeah maybe that'd be best [11:20:56] Kin? [11:21:02] sure [11:21:05] skype [11:21:13] ok, can y'all try to paste in a bunch of related issues into the agenda on this? [11:21:30] feel like there are a bunch of duplciates because this manifests itself in a few ways [11:21:41] yeah [11:21:53] https://docs.google.com/document/d/18FwdwDV3-z6ecgSE2sKnZissug7qUGxzF1Al9D5TYqc/edit [11:21:57] ok [11:22:01] I closed a couple already [11:22:10] lets list the closed ones too [11:22:16] so other than this whole shebang, have you all heard any other major issues in beta 1? [11:22:23] BB5 [11:22:26] kinblas -ggood idea [11:22:27] adambiggs [11:22:30] but I guess we need to move back to click on that [11:22:38] ok yeah bb5 [11:22:55] issue #? [11:23:01] * kinblas tries to dig up issue number [11:23:19] 1907 and 1908 [11:23:21] #1907? [11:23:22] https://github.com/jquery/jquery-mobile/issues/1907 [11:24:26] I wish I had a BB5 [11:24:41] I have one here I think [11:24:45] let me check [11:24:54] kinblas - did you get the emulator working? [11:25:12] since BB5 devices don't have touchscreens, it's not too bad to test on [11:25:20] except when it doesn't match, like here [11:25:25] @toddparker: the emulator works but the MDS emulator I need with it to allow for internet access doesn't [11:25:25] :) [11:25:50] right this is device only [11:25:56] works fine in emulator [11:26:04] see this comment at the end of 1908 [11:26:04] Figured out, jQuery.support.cors value depends xhr and it depends on browser. so that's true, we should add it in js. [11:26:20] toddparker: I have a BB labelled BB5 and it has touchscreen, is it mislabelled? [11:26:36] https://github.com/jquery/jquery-mobile/issues/1908 [11:26:46] ah, no [11:26:53] does it have a clicky touchscreen? [11:26:59] yes [11:27:06] that's 5 [11:27:08] we have that too [11:27:13] ok [11:27:39] so is BB5 9000 a specific device? [11:28:24] yep [11:28:34] they all have number and names [11:28:39] so are these issues tied up with the fact that we kick bb5 out of ajax? [11:28:41] oh ok its the bold [11:28:49] this sounds like something to document for phonegap-specific use cases? [11:29:27] 1908 might be [11:29:36] but I'm not sure if 1907 is phonegap specific [11:29:48] right [11:29:52] 1908 seems like it could just be documented or added if it doesn't cause issues [11:29:57] 1908 sounds it [11:29:58] yep [11:29:58] he posted a jsbin so I'm assuming that means its just browser related [11:29:58] tiny bit of code [11:30:28] Kin, should that setting always be used in PhoneGap apps? Or just in BB5 PhoneGap? [11:30:29] where is the jsbin? [11:30:39] I don't even know what that option does [11:30:51] it's just to always allow cross-domain even if the status is 0 right? [11:31:12] ...I feel like we ran into this one a while back maybe [11:31:26] for #1907: http://jsbin.com/ukewu3/83 [11:32:32] so, do local pages work when ajax is disabled? That's question 1 [11:32:37] ah, thanks gseguin [11:32:49] np [11:33:06] they seemed to...remember we tested that on opera mini and bb5 about a week ago? [11:33:08] looks like kin tried that and found it works [11:33:14] lemme check [11:33:17] as it should [11:33:33] file:// loading and http/https loading all works [11:33:40] when you cross domains via phonegap it all works [11:33:49] and I've never set that .cors option [11:34:05] sorry, referring to the local pages app [11:34:56] hmmm good question [11:35:05] that .cors option goes back to this ticket: http://bugs.jquery.com/ticket/8122 [11:35:13] scottjehl: you moved that ajaxenabled check up top? [11:35:44] where? [11:35:55] in click? [11:36:10] I thought I saw that for BB5 [11:36:22] when you refactored the settimeout code for resetting that active class [11:36:33] oh yes. otherwise the regexp was crashing it [11:36:43] we need to fix the regexp thing [11:36:58] we can't return early if we know ajax is disabled? [11:37:23] we should only return if the page being referenced [11:37:28] is not an internal one [11:37:43] for that we need to run the regexp [11:37:44] otherwise the default browser handling will try to scroll the page to the item with that id [11:38:19] btw - i just tested the multi-page boilerplate in opera mini (ajax disabled) and it works fine. I can nav around, back button works, etc. [11:38:36] okay. so the issue was after running the regexp just one time, bb5 would throw an error that the page was too large to load [11:39:05] returning early worked around that, but it sounds like we'll need to reapproach it again [11:39:40] yeah probably should find out whhy its doing that [11:39:45] this reminds me [11:39:49] of a bug I noticed [11:40:24] hmmm I'll need to walk though it in my head to make sure it is a bug [11:40:39] but it has to do with the fact that we reset the base tag [11:40:59] ok [11:41:07] if we return to let the browser handle [11:41:11] page loading [11:41:22] relative links are resolved relative to the *CURRENT* base tag [11:41:39] I have a hunch the blank pages in 2.1 are not getting the proper base tag too [11:41:41] maybe related [11:41:55] so it seems that we need to make sure we set the base tag to the current page path [11:42:03] whenever we show pages [11:42:16] that way it interprets relative links properly [11:42:21] right. I thought we already do that [11:42:35] well we do that because we are manually resolving [11:42:37] otherwise, images and such wouldn't load [11:42:45] so it turns out [11:42:49] that the image data is cached [11:42:57] we only manually resolve in ff3.6 and others tho [11:42:58] if you ask the image for its path [11:43:02] afterwards [11:43:11] it will give you a path resolved against the current base [11:43:23] i just tested the multi-page boilerplate template on our 9930 Curve (BB5) and it is broken. Clicking on a link does nothing. [11:43:35] So opera mini works but not BB5 [11:43:50] just on local pages [11:44:03] external pages are fine in bb5 [11:44:18] don't use multipages! :) [11:44:32] ...or nested lists [11:46:23] ok, i feel like this is an issue, but not that important [11:46:40] if we can get multi-page to be navigable in BB5, cool [11:46:49] I guess the question is if this is a regression. [11:46:59] but history will still be broken so this is less-than-ideal set up for this platform [11:47:28] if you're building an spp for BB5 like he is, single page isn't a great solution b/c the back button is broken [11:47:32] even if we fix this [11:47:45] i'm guessing it is a regression [11:47:55] that [11:48:10] is why getting it to work is probably a good thing [11:48:22] i just don't see this as a priority compared to other things on our plate [11:49:59] I have a test case with the nav utils (regexp included) that is separated out [11:50:12] it would be good if we could load that and see if that is actually the problem [11:50:36] that way we can rule out other jqm things [11:50:38] i just moved down the priority on this and commented [11:50:59] so kin, if you want to look at this when you get time, cool [11:51:12] any other regressions fo rbeta 1? [11:51:15] I don't have a BB5 device [11:51:22] I can see if I can get one [11:51:27] cool [11:51:29] true [11:51:35] guess it's on us [11:51:39] i'd like to plan out beta 2 in the next 10 minutes... [11:52:32] I'm out for all of beta 2 ... I may be able to sneak some work time in but I wouldn't count on it [11:53:02] right, so when are you leaving kin? [11:53:13] i'd like to prioritize to best use your time [11:53:13] it's hard working on a beach ... sand gets in the hard drives and the humidity .... [11:53:18] heh [11:53:22] I'm out July 1st - 31st [11:53:23] what beach? [11:53:41] Any beach on Guam [11:53:46] nice [11:53:46] so we have 1 week of your time left? [11:53:55] yeah [11:54:03] I'm not in next Friday [11:54:21] ok [11:54:24] so.... [11:54:34] so I've been splitting time between looking at various regression floating in [11:54:45] and starting on the page loading hooks [11:55:18] so folks can load things other than html and pre/post process content at known times [11:55:34] issues i have for beta 2 so far [11:55:34] https://github.com/jquery/jquery-mobile/issues?sort=created&direction=desc&state=open&page=1&milestone=6 [11:55:46] is the page loading extensibility hooks in there? what # [11:56:03] ya. #1872, right? [11:56:09] https://github.com/jquery/jquery-mobile/issues/1872 [11:56:26] yeah [11:56:28] 1872 [11:56:49] so the big tickets are the asks we always get [11:57:03] Function for enhancing a page [11:57:06] caching [11:57:18] transitions [11:58:40] so enhancing a page is tagged to scott [11:58:45] same with caching [11:58:58] transitions might be the other thing to get you looking at [11:59:08] just sent a solution around this morning for delaying page init - is that what you mean? [11:59:10] since you've been so deep in it [11:59:14] or enhancing partial page content? [11:59:24] good Q [11:59:47] delayed init needs a unit test. I can't figure out how to test it yet [11:59:49] works fine [11:59:54] pretty frustrating [11:59:56] heh [12:00:15] Folks have been asking for a way to enhance content they've dynamically pulled into a page [12:00:22] yeah ok [12:00:31] not necessarily a brand new page [12:00:35] but new content *IN* the page [12:00:36] so I've got that included in the decoupled-widgets branch [12:00:44] yep [12:00:56] basically, all widgets bind to pagecreate and a new event called "enhance" to self-init themselves [12:01:01] I still think we really need to re-think our initialization scheme [12:01:17] setting config flags on a callback seems wierd [12:01:18] you'd call enhance on the fragment that's appended [12:01:37] scottjehl: right [12:01:54] if you have ideas on different config - all for it [12:02:31] maybe post 'em to that ticket [12:02:46] one option could be to use the new delayed init option to init the framework yourself, passing in config options [12:02:48] https://github.com/jquery/jquery-mobile/issues/1871 [12:03:16] turn off auto init, call it yourself with a hash of options as argument [12:03:31] I think the issue we had was that some plugins initialize on initial execution of the file they are in [12:04:23] we should probably have a formal init component event or something like that and tell plugin developers to init their internals that rely on configs at that point [12:04:58] that way we can allow folks to just include a file after jquerymobile.js that just sets configuration parameters etc [12:05:18] but the framework needs to execute immediately [12:05:28] does it? [12:05:44] do you want to ask people to init it themselves every time? [12:05:52] no, no [12:06:08] we have to turn off autoinit then, to override it later. right? [12:06:20] can we have a global config object [12:06:33] that's what the core team didn't like initially [12:06:35] that can be defined before our script is pulled in [12:06:46] and will override default behavior [12:06:48] but that's not very different from what we do now [12:07:18] scottjehl this init component event [12:07:29] would happen prior to the framework auto stuff kicking in [12:08:05] I think I outlined this in basecamp one time [12:08:13] a few months back [12:08:15] I'll dig it up [12:08:16] or have a data-jqm-config on the script tag [12:08:17] ok, let's discuss later [12:08:45] json in attributes? [12:08:48] not sure [12:08:49] yep [12:09:15] that's way harder than mobileinit [12:09:30] +1 [12:09:48] ok so before we go too far over time, let's recap [12:09:58] and find a time to chat on skype [12:10:20] kin - can you look at extensibility and maybe transitions in this week? [12:10:38] those are two big complaints right now [12:10:59] for talking, do people have time later today for a skype call? [12:11:14] sure [12:11:22] kinblas? [12:11:24] transitions: in what sense? I thought gseguin had it [12:11:30] after 2pm PDT [12:11:38] I'm free after 2pm PDT [12:11:43] hmmm [12:11:51] I don't know if I really have it [12:11:54] maybe tomorrow? i need to leave earlier today [12:12:02] that's fin [12:12:04] fine [12:12:05] ok [12:12:10] I thought I was just a placeholder [12:12:14] just so I'm straight [12:12:28] checkout the proposed transitions plugin [12:12:28] but I don't mind looking into it [12:12:31] i think we need a plan on transitions, then can figure out who [12:12:51] let's talk tomorrow about vclick and transitions [12:12:53] what time? [12:13:40] kinblas: preferred time? [12:14:00] I'm free anytime up until 2pm PDT, and then free after 3pm [12:14:20] those times were for tomorrow btw [12:14:26] ok [12:14:38] meeting 10-10:15am PDT for me [12:15:09] we're free from 9-1 EST tomorrow [12:15:41] so this is on Skype? [12:15:42] how about 10am EST / 1pm PDT [12:15:45] yep [12:15:57] works for me [12:15:58] isnt that backwards? [12:16:05] right [12:16:12] oh oops [12:16:18] 10am PDT / 1pm EST [12:16:26] I'll join late [12:16:28] wait, that doesn't work for gseguin [12:16:50] we should use tungle.me next time ;) [12:16:55] ? [12:17:05] http://tungle.me [12:17:25] so 10:15 PDT / 1:15 EST - 45 minutes [12:17:33] alright [12:17:38] cool [12:17:38] okie dokie [12:17:46] BTW I'm ghislain.seguin on skype [12:17:47] * kinblas_ pencils it in [12:18:48] invite sent! [12:18:52] ok, thanks guys! [12:19:00] over and out