#jquerymobile-dev_20110815.txt

[01:21:33] <mazzachre> Any one alive? I have a project opening, that I hope someone will take up
[01:44:04] <mazzachre> I need a way to include facebook/g+/twitter buttons on my jqm page, it does not quite work with the current boilerplate code from these sites, and I don't have time to figure out why not. I will pay for the project and the code will be GPLed
[08:42:30] <toddparker> mazzachre - give the #jquerymobile channel a try for a question. This is the team chat. Thanks.
[08:51:39] <_nickel> hey all
[08:59:32] <kinblas> _nickel: regarding the question I had on Friday about tests ... combining some of the top-level tests into a single test/asynctest might speed things up
[08:59:58] <kinblas> I was wondering if each test for classes was separated out to get "top-billing" in the test output
[09:00:19] <kinblas> versus being stuffed under a single test description (and minimized)
[09:05:56] <_nickel> kinblas: the only disadvantage currently is that that full test suite won't report those specific failures
[09:06:08] <_nickel> other than that feel free to go for it as long as there's a description in the assertion
[09:06:45] <kinblas> eh, I can keep 'em separated ... I was more curious if there was a reason
[10:00:05] <_nickel> scottjehl: alright I'm going to take a look at the pushstate branch
[10:00:51] <_nickel> toddparker: kinblas: gseguin: unless anyone else has anything super pressing for me to work in
[10:00:54] <_nickel> *on
[10:05:58] <_nickel> actually I take that back
[10:06:15] <_nickel> I'm going to look at the failing test on FF
[10:12:13] <kinblas> _nickel: _scottjehl: regarding the pushstate branch
[10:12:23] <kinblas> I took a quick peek at how it is implemented
[10:13:05] <kinblas> I think for push state we want to do the same things we want to allow developers to do ... specifically decode the URL from a hashchange event, and encode a URL after a page change
[10:13:24] <kinblas> is there any way we can make what is on pushstate generic for developers to write their plugins to encode/decode?
[10:13:32] <kinblas> pushstate can be another one of those plugins
[10:16:44] <_nickel> I wasn't aware that we were doing that
[10:16:57] <_nickel> kinblas: ^
[10:17:18] <_nickel> I didn't take the time to grok the deferred-fu in the nav after your refactor
[10:17:21] <_nickel> I'll have to do that
[10:17:28] <_nickel> assuming its related
[10:19:27] <kinblas> _nickel: the encode/decode part is not implemented yet, that's on the to do list for beta-3
[10:19:38] <kinblas> so I was thinking push-state should be just another one of those plugins
[12:45:33] <toddparker> interesting idea kin
[12:45:58] <toddparker> do you want ti take a crack at rolling scott's pushstate into a plugin
[12:46:34] <toddparker> rwalron, i summon thee!
[12:46:45] <toddparker> rwaldron
[12:46:58] <toddparker> summoning doesn't work with typos
[12:47:00] <kinblas> toddparker: I was hoping _nickel would since he was supposed to take a look at pushstate branch :-)
[12:47:26] <toddparker> yeah, kinblas understood. seemed like he wasn't familiar with the new format
[12:47:29] <kinblas> but I can once I wrap up the transitions tests
[12:47:33] <toddparker> cool
[12:47:41] <kinblas> but where does that fall with other bug priorities?
[12:47:55] <toddparker> pushstate?
[12:48:18] <toddparker> pushstate is very high. i want to land that for beta 3
[12:48:28] <kinblas> well there's pushstate and the encode/decode URL extensibility that folks like jive need so they don't have to hack our source
[12:48:34] <rwaldron> toddparker whats crackin
[12:48:59] <toddparker> is that the biggest dev extensibility hook we need to land?
[12:49:07] <toddparker> hey rwaldron!
[12:49:37] <toddparker> i don't have your email handy and i have the dev lead at ramp.com wanting to talk to you about converting to popcorn.js
[12:49:53] <toddparker> can you shoot me an email? todd @filamentgroup.com
[12:49:56] <_nickel> toddparker: I'm going to take a look at the pushstate after I eat
[12:50:11] <toddparker> thanks _nickel
[12:50:40] <toddparker> do you feel comfortable moving this into a plugin? guess you should huddle with scottjehl on that
[12:50:43] <scottjehl> hey
[12:50:52] <scottjehl> catching up
[12:51:10] <_nickel> toddparker: yah I need to take a look at the diff first and then I can discuss plugin shtuff
[12:51:21] <_nickel> hopefully its not out of my league
[12:51:27] <_nickel> if it is I'll have many questions
[12:52:35] <rwaldron> toddparker waldron.rick@gmail.com
[12:52:35] <scottjehl> hey kinblas
[12:52:45] <kinblas> scottjehl: yo
[12:53:16] <rwaldron> toddparker sent
[12:53:50] <scottjehl> hmm... not sure I completely follow. If the pushstate URL references a valid resource, all this pushstate branch does is clean it up to no longer use a hash. What are the cases where we'd need it to do something else?
[12:54:31] <kinblas> scottjehl: in the current implementation, how do you turn it on/off?
[12:54:48] <kinblas> or is it done with support?
[12:55:32] <scottjehl> ah, well that's a good point. It's based on support, yes, but that aside, I was sortof just enabling it based on existence.
[12:55:47] <scottjehl> that is, if it's there, it does it's thing. I wasn't sure if it'd be in our build by default
[12:56:06] <scottjehl> anyway, I like your idea of adding a way to disable
[12:56:15] <kinblas> scottjehl: I guess I was looking at it from a purely, what does it do stand point
[12:56:38] <kinblas> all the code does is re-write the URL location
[12:57:05] <kinblas> and then on hashchange, it just passes on the entire URL right?
[12:57:10] <scottjehl> it takes ugly js-dependent urls and makes them internet friendly
[12:57:30] <kinblas> scottjehl: but at a basic level, is what I said above correct?
[12:57:44] <scottjehl> yeah it's just listening for hashchanges and replacing the hash-based url with a full-path regular url
[12:58:12] <kinblas> and then on pagechange it writes the URL instead of updating the hash right?
[12:58:58] <kinblas> these are the same 2 places we'll need to plug so that developers can format their own URLs
[12:59:16] <scottjehl> umm. don't think so. It's always just reacting to hash changes and cleaning them up
[12:59:35] <kinblas> hmmm ok, I'll need to read the code then
[12:59:38] <scottjehl> if the url is already working, this just sits on top of that
[13:00:03] <kinblas> I need to see how you short-circuit the pagechange hash setting code
[13:00:54] <scottjehl> I don't think i do
[13:01:02] <scottjehl> it still uses hashchange and all that
[13:01:24] <scottjehl> after the hashchange, it cleans the url to be more presentable. internal logic doesn't change
[13:01:36] <scottjehl> on hashchange, it basically just replaces the url with location.hash.replace("#","")
[13:02:03] <scottjehl> so example.com/whatever/#/foo becomes example.com/foo
[13:02:06] <_nickel> so its entirely visual at this point
[13:02:44] <_nickel> scottjehl: what about example.com/whatever/#/whatever/bar/baz
[13:02:53] <_nickel> you can tell me to just go look at the code :D
[13:02:56] <scottjehl> yeah. if you click the back button, popstate fires and we replace the url with a hash-based equivalent, then trigger hashchange. This then reruns our hashchange logic again
[13:02:59] * _nickel goes to look at the code
[13:03:12] <scottjehl> yeah that'd be example.com/whatever/bar/baz
[13:03:27] <scottjehl> if you guys have firefox or chrome open i can shoot you a demo url
[13:04:15] <_nickel> https://github.com/jquery/jquery-mobile/compare/master...replacestate-external
[13:05:09] <scottjehl> uploading
[13:06:36] <scottjehl> yeah and on that diff, really just this file is where it's at https://github.com/jquery/jquery-mobile/blob/c864dac3b1740adc521efa8b8d4a9d4fc2d4c581/js/jquery.mobile.navigation.pushstate.js
[13:07:38] <scottjehl> want to walk through?
[13:07:51] <scottjehl> it's not doing a lot really
[13:08:03] * _nickel is reading now
[13:08:07] <kinblas> scottjehl: I understand what its doing, I just read it
[13:08:10] <scottjehl> most complexity is with dialogs and nested listviews, unsurprisingly :/
[13:08:22] <kinblas> so is one of the key things here, that you need a state already there to replace it?
[13:09:28] <scottjehl> well, if you're referring to the part where it checks for the popstate data, that's for cases where it's a back/forward click
[13:09:31] <kinblas> scottjehl: i guess what I was wondering was why couldn't we just call your plugin at changepage time, giving you the URL we just loaded, and let your plugin decide how to update the URL bar ... but I'm guessing you can't use pushstate because it is broken on mobile safari
[13:09:46] <scottjehl> basically, popstate fires but hashchange doesn't
[13:10:12] <scottjehl> so we replace it with a hash url and trigger the hashchange if necessary, letting it run through our hashchange engine
[13:11:35] <kinblas> scottjehl: yeah but that seems so ... workaround-ish ... for lack of a better word.
[13:11:36] <scottjehl> oh, yeah so I was trying to do it all externally because so much logic in jqm's navigation uses hash
[13:11:40] <kinblas> is it a bug that hashchange doesn't fire?
[13:11:58] <scottjehl> no, it's not a hashchange. it's going from good url to good url in many cases
[13:12:08] <kinblas> oh duh
[13:12:10] <scottjehl> no hash involved because we already replaced it
[13:12:11] <kinblas> "hash-change"
[13:12:15] <kinblas> you're not changing a hash
[13:12:18] <kinblas> ok duh I get it
[13:12:33] <kinblas> hmmmm ok
[13:12:38] <scottjehl> yeah. I agree it's workaround ish. the problem is that iOS 4 really gets this wrong
[13:12:55] <kinblas> so remind me the problem with iOS4?
[13:13:16] <kinblas> I know it has to do with pushState versus replaceState right?
[13:13:31] <scottjehl> I found that replacing the hash and then trying to "clean it up" works, whereas calling pushState outright would lead to problems
[13:13:42] <scottjehl> no, neither work as we need them
[13:14:05] <scottjehl> what happens is, apparently these methods are only enabled within the callback of a user action
[13:14:15] <scottjehl> like a touch event
[13:14:30] <scottjehl> just calling it outright will add a history state, but won't update the address bar
[13:14:53] <kinblas> ugh
[13:15:00] <kinblas> is that fixed in iOS5?
[13:15:15] <scottjehl> yes
[13:15:25] <_nickel> worst case scenario
[13:15:33] <_nickel> supported but terribly so
[13:15:34] <scottjehl> so this branch seems to bridge that pretty well
[13:15:49] <scottjehl> it "replaces" the url, but nothing happens
[13:15:55] <_nickel> scottjehl: it looks like we do a lot of url checking for certain cases
[13:15:57] <scottjehl> in 4.3 that is
[13:16:14] <scottjehl> _nickel, yeah for non-path urls
[13:16:24] <scottjehl> dialogs and lists
[13:16:42] <_nickel> alright
[13:16:43] <scottjehl> hate those things
[13:16:54] <scottjehl> :)
[13:16:55] <_nickel> so we'll have to update any changes to that stuff in two places
[13:17:28] <_nickel> in a perfect world I think we'd rework nav to better accomodate change like this
[13:17:39] <_nickel> thats my gut reaction right now
[13:17:58] <_nickel> or at least identify the common bits and pull them out
[13:18:03] <_nickel> into methods, etc
[13:18:08] <_nickel> still reading
[13:20:44] <scottjehl> so, I'm totally open to different approaches here. Just wanted to relay where I'm at and what I've found so far.
[13:21:00] <scottjehl> btw, here's a live url so you can see it in action
[13:21:13] <scottjehl> http://filamentgroup.com/examples/pushstate/
[13:21:22] * kinblas wants to live it
[13:21:48] <kinblas> scottjehl: does pushState/replaceState work properly on Safari desktop?
[13:21:53] <kinblas> Or does it have the same mobile bugs?
[13:22:06] <kinblas> ... in terms of only working from events
[13:22:06] <scottjehl> hadn't tested it there yet
[13:22:45] <kinblas> hmmm, on desktop I see a flash of the # url
[13:22:49] <scottjehl> works great in mine
[13:22:53] <scottjehl> yep that's gonna happen
[13:23:06] <scottjehl> hashchange fires, replacestate sweeps it up
[13:24:28] <scottjehl> understandably not ideal, but it does achieve clean urls in the end
[13:25:12] <_nickel> scottjehl: kinblas: if we we're to insert into the nav it would be in how many places? click, submit, changpage
[13:25:25] <_nickel> having not looked at the code closely after the refactor
[13:25:28] <scottjehl> path,
[13:25:47] <scottjehl> path.set, path.get, etc
[13:27:22] <kinblas> path.get is only used in the ajax error condition.
[13:27:40] <scottjehl> it's public though
[13:27:54] <scottjehl> what I mean is, those methods look for hash, not href
[13:27:55] <scottjehl> right?
[13:28:07] <kinblas> $.mobile.path.get()
[13:29:29] <_nickel> toddparker: whats the timeline for beta 3 looks like ?
[13:32:16] <_nickel> scottjehl: kinblas: I'm wondering if we have time to explore fixing this on the nav side?
[13:32:21] <_nickel> maybe another branch?
[13:32:51] <_nickel> scottjehl: also, are there any other browsers out there with known pushstate issues?
[13:33:33] <scottjehl> not sure. Haven't done a ton of testing yet. The iOS one is well known
[13:34:10] <_nickel> yah
[13:34:27] <_nickel> scottjehl: it looks like FF ignores the title
[13:34:36] <_nickel> but that doesn't matter in this case since its already set
[13:35:41] <_nickel> scottjehl: https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history#The_pushState().c2.a0method
[13:35:47] <scottjehl> ah. yeah I remember that being not widely implemented yet
[13:35:51] <scottjehl> same with data maybe
[13:36:07] <_nickel> the url param
[13:36:08] <scottjehl> we might be able to get around using either of the first two args actually.
[13:36:10] <_nickel> is interesting too
[13:36:43] <_nickel> since we're using relative urls I wonder what happens with the user re-opens the browser
[13:37:59] <_nickel> scottjehl: its not entirely clear to me what that means
[15:20:21] <_nickel> scottjehl: hmm one issue I just noticed
[15:20:25] <_nickel> nested dialogs
[15:20:45] <_nickel> scottjehl: http://filamentgroup.com/examples/pushstate/docs/pages/page-dialogs.html
[15:20:48] <_nickel> down at the bottom
[15:20:53] <_nickel> "share photos..."
[15:21:13] <_nickel> clicking that and any of the blue buttons in the dialog afterward results in a double hash
[15:22:00] <_nickel> I get this feeling that there are a ton of dark corners associated with this
[15:48:20] <_nickel> scottjehl: kinblas: I'm going to take a crack at refactoring + testing this