Zotonic
Zotonic
zotonic@conference.zotonic.com
Friday, 8 February 2013< ^ >
arjan has set the subject to: Zotonic - the Erlang Content Management Framework
Room Configuration

GMT+1
[07:18:53] Jeff Bell leaves the room
[07:19:21] Jeff Bell joins the room
[07:36:45] Jeff Bell leaves the room
[07:37:28] Jeff Bell joins the room
[08:52:45] Andreas Stenius joins the room
[09:02:52] Arjan joins the room
[09:11:44] Arjan leaves the room
[09:13:47] Arjan joins the room
[10:46:01] <Andreas Stenius> Hey, when I hit /logoff, z_auth:logoff/1 is called (rightly so), the thing is, as soon as z_auth is done, mod_authentication makes sure that we don't stay on the logoff.tpl page by sending a z_reload() to all pages for the session (including the websocket one).. what? why? how? I don't want that... how does the facebook sign out work?
[10:49:09] <Arjan> Hmm am afraid I cant help you with that
[10:49:26] <Arjan> Im experiencing something strange myself
[10:49:43] <Arjan> postbacks taking about 4 seconds to complete
[10:49:46] <Arjan> pretty trivial postbacks
[10:49:50] <Arjan> machine is not doing anything
[10:49:51] <Andreas Stenius> ah..
[10:50:00] <Andreas Stenius> sounds weird
[10:50:03] <Arjan> freebsd
[10:51:08] <Arjan> hmm I also see the browser falling back to comet
[10:51:23] <Arjan> does nginx do websockets?
[10:52:20] <Arjan> nope it doesnt
[10:57:22] Maas joins the room
[10:59:31] <Maas> What browser? Chrome? Maybe there is a problem in the handshake...
[11:00:08] <Maas> The handshake matches domains names.
[11:08:37] <Maas> Yesterday I saw that it switches over to comet when running on 127.0.0.1. It looked like m_site:get(hostname, Context) didn't return anything in that case. That was for the zotonic status site.
[11:09:53] <Andreas Stenius> Aha, facebook sign off doesn't work as intended either!
[11:11:19] <Andreas Stenius> Marc!! ;)
[11:11:30] <Andreas Stenius> busy busy.. :p
[11:17:21] <Maas> Aha, just osx safari with that problem hybi17 doesn't do the hostname check anymore.
[11:39:29] <Andreas Stenius> Hey maas, you're a bit of a websocket expert, right? :)
[11:39:38] <Andreas Stenius> I'm looking at z_websocket_start()
[11:40:01] <Andreas Stenius> in z_ws.onclose, there's a retry in case z_ws_opened == true
[11:40:26] <Maas> It doesn't retry very often :-)
[11:40:39] <Andreas Stenius> the comment says, try to reopen once.. but I don't see it's limited to only once..
[11:41:05] <Andreas Stenius> oh, well, of course if it is an error, z_ws_opened will not be true again..
[11:41:15] <Maas> yup.
[11:41:23] <Andreas Stenius> but what about when you leave the page, doesn't the browser close it then
[11:41:33] <Andreas Stenius> what then?
[11:41:51] <Maas> When you move to another page with a stream a new ws is opened
[11:42:06] <Andreas Stenius> yeah, but I have an issue
[11:42:21] <Maas> It starts over from scratch
[11:42:24] <Andreas Stenius> when I move to a new page, the old ws gets a z_reload() request, and reloads my new page
[11:42:43] <Andreas Stenius> or rather, reloads to my old page
[11:42:59] <Andreas Stenius> so the new request is logged as cancelled
[11:43:37] <Andreas Stenius> look at the request processing done for /logoff when you're logged in using facebook
[11:44:29] <Andreas Stenius> the code is done to send a logout request to facebook from the logoff.tpl, but that doesn't get called, as we're reloading back to the previous page
[11:44:32] <Maas> So, what happens, z_reload(...) comes in via ws and is evalled
[11:44:44] <Andreas Stenius> yeah, and that is wrong, in this case
[11:44:51] <Andreas Stenius> but I don't know how to avoid it
[11:45:12] <Andreas Stenius> the culprit is in mod_authentication.erl
[11:45:22] <Andreas Stenius> reload_other_pages(Context) ->
Pages = z_session:get_pages(Context),
ContextPush = z_render:wire({reload, []}, z_context:new(Context)),
{Script, _} = z_script:split(ContextPush),
[ z_session_page:add_script(Script, Pid) || Pid <- Pages, Pid /= Context#context.page_pid ].
[11:45:49] <Andreas Stenius> so it doesn't send a reload to the current page, but the old page that we just left is still open..
[11:46:20] <Andreas Stenius> I'm thinking that maybe we should have a z_stream_stop() call on page leave...
[11:46:26] <Maas> Nice asynchronous stuff
[11:46:33] <Andreas Stenius> heh :p
[11:46:53] <Maas> Happening all the time. :-)
[11:47:10] <Andreas Stenius> I'd suppose the browser would have to not eval data on sockets from pages that we're no longer on.. ! bah
[11:47:32] <Maas> How does it know you are no longer on the page :-)
[11:47:45] <Andreas Stenius> since it's requesting a new page :D
[11:48:16] <Maas> It is not that simple....
[11:49:00] <Andreas Stenius> but, as you said, "When you move to another page with a stream a new ws is opened".. I'd just like to add: and close the old ws streams.
[11:49:22] <Andreas Stenius> oh, wait. what do you mean with: "with a stream"
[11:49:49] <Maas> {% stream %}
[11:49:58] <Andreas Stenius> ah, ok
[11:50:25] <Andreas Stenius> but still, when we load another page, regardless of ws streams or not, the ws stream from the old page ought to be closed, right?
[11:50:57] <Andreas Stenius> I only think that it ought to close it (or at least don't process data from it) when a request for another page has begun
[11:50:59] <Maas> It will eventually be closed, but you don't have much control over that. You have to shoot your script at the correct page.
[11:51:26] <Andreas Stenius> yeah, so the page unload event it is, then ;)
[11:51:29] <Maas> It could be that if you quickly press back you well still have the page there.
[11:52:27] <Maas> It can take quite a bit of time before you see it happening.
[11:52:28] <Andreas Stenius> we have to shoot the websocket before moving on
[11:52:41] <Maas> Better not rely on that.
[11:53:07] <Andreas Stenius> well, since it's running, it ought to have it's javascript state too, so setting a flag to not process any more data ought to work... ?
[11:53:35] <Andreas Stenius> or check window.location and see if we're still on the same page?
[11:53:46] <Maas> z_pageid
[11:54:02] <Maas> Every page will have a different one.
[11:54:06] <Andreas Stenius> yeah, but I haven't got the new page id yet (when the z_reload comes in)
[11:54:25] <Maas> No but the reload is for the old page.
[11:54:53] <Andreas Stenius> yes, but it reloads to the old page, /discarding/ the new page
[11:56:33] <Maas> Huh, you have two operations a reload and a redirect
[11:56:40] <Maas> or?
[11:57:23] <Maas> You don't want to reload?
[11:59:47] <Andreas Stenius> I don't want to reload
[11:59:55] <Maas> Sessions are weird.
[12:00:09] <Andreas Stenius> and there's no redirect, I click on a link (or type in /logoff in the adress bar)
[12:00:45] <Maas> aha, so the browser does its default action too... navigating....
[12:00:50] <Andreas Stenius> yeah
[12:01:13] <Andreas Stenius> exactly. I'm navigating, and then the ws connection from the previous page interferes with taht
[12:01:13] <Maas> You can do cancel default.
[12:01:21] <Maas> Then the browser stops doing that.
[12:01:39] <Andreas Stenius> no, the navigation should happen... wait, I'll have to look at z_reload..
[12:02:02] <Maas> There are an unbelievable number of ways to move from one page to the other.
[12:02:39] <Andreas Stenius> indeed.. but when you do, the dead pages shouldn't come after you, grabbing your ankles! :p
[12:03:34] <Maas> hehe :-) welcome to the web ;-)
[12:03:58] <Maas> The page isn't as dead as you think it is.
[12:04:05] <Andreas Stenius> hehe
[12:04:33] <Andreas Stenius> well, now I know that, and that I can check if it is supposed to be dead in z_reload and just don't reload..
[12:04:34] <Maas> During implementing of cobrowsing the a tag is quite a problem.
[12:04:59] <Andreas Stenius> yeah, I wouldn't dare try to implement what you did ;)
[12:05:14] <Maas> Pretty hard to find out if it is a normal browser navigate, or that some js is tied to it
[12:05:37] <Maas> I've even found pages where the navigation was done with form posts.
[12:05:51] <Maas> All a tags where tied to an onsubmit on an hidden form.
[12:06:11] <Maas> it grabbed the href and then did a submit
[12:06:25] <Andreas Stenius> yikes.
[12:06:38] <Maas> currently all pages are packed with user tracking stuff
[12:06:41] <Andreas Stenius> found a better spot to intercept data to a dead page, in z_comet_data
[12:07:20] <Maas> I think the init_postback form can go to.
[12:07:48] <Maas> Can be done with on quite easily
[12:08:05] <Maas> $.on I mean so you don't have to bind it all the time
[12:08:49] <Maas> It will also work then for dynamically added postback forms in popups.
[12:09:55] <Andreas Stenius> what? didn't get any of that...
[12:10:33] <Andreas Stenius> nice viewer when sharing chrome network info from the dev tools: http://ericduran.github.com/chromeHAR/
[12:12:53] <Maas> after jquery 1.7 .on is actually preferred over bind.
[12:13:32] <Maas> Maybe we have to check mod_base for the jquery stuff.
[12:13:40] <Andreas Stenius> I was thinking of hooking into the unload event: http://www.w3schools.com/jquery/event_unload.asp
[12:13:42] <Maas> Some things can be done a lot easier.
[12:14:05] <Andreas Stenius> The unload event is triggered when:
a link to leave the page is clicked
a new URL is typed in the address bar
the forward or back buttons are used
the browser window is closed
the page is reloaded
[12:14:07] <Maas> That is a goffie event.
[12:14:11] <Maas> goofie
[12:14:16] <Andreas Stenius> how so?
[12:14:41] <Maas> Well it isn't always fired, and you can't use it to call something on the server anymore.
[12:15:02] <Maas> So no quickly sending something that the page is closed...
[12:15:09] <Andreas Stenius> I don't need to call the server from it, only set some variable in javascript
[12:15:28] <Andreas Stenius> that it was triggered, to stop z_comet_data() from eval'ing any more
[12:15:50] <Andreas Stenius> I'm more concerned about it not always being fired..
[12:15:57] <Maas> Nice note also...
[12:16:05] <Maas> it might work differently....
[12:16:09] <Andreas Stenius> yeah :p
[12:16:30] <Andreas Stenius> wonder how it could work differently... either it works, or it doesn't
[12:17:00] <Maas> just try it ;-)
[12:17:49] <Maas> If only there where a js event to tell that the browser is actually navigating away....
[12:18:47] <Andreas Stenius> well, there is <body onunload="moving_out()">...
[12:18:55] <Andreas Stenius> but I have conflicting info about it:
[12:19:03] <Andreas Stenius> The onunload event is supported in IE, Firefox, and Safari, but not supported properly in Chrome or Opera.
[12:19:11] <Andreas Stenius> The onunload event attribute is supported in all major browsers.
[12:19:13] <Maas> hehe
[12:19:31] <Andreas Stenius> funny thing is both those came from the same site..!
[12:19:49] <Andreas Stenius> http://www.w3schools.com/jsref/event_onunload.asp
[12:19:54] <Andreas Stenius> http://www.w3schools.com/tags/ev_onunload.asp
[12:20:38] <Maas> quircksmode is pretty good.
[12:20:56] <Maas> http://www.quirksmode.org/compatibility.html
[12:21:40] <Maas> http://www.quirksmode.org/dom/events/load.html
[12:22:01] <Arjan> changed 11 months ago
[12:22:03] <Arjan> ancient.. :)
[12:22:14] <Arjan> this one is better imho, http://caniuse.com/
[12:22:32] <Maas> Didn't know that one yet.
[12:22:34] <Maas> Thanks
[12:22:37] <Andreas Stenius> right, I've seen caniuse before.. forgot about it thou
[12:25:03] <Maas> I've a module which sents notifcations when it detects somebody left a page with a stream on it.
[12:25:32] <Maas> going out for lunch
[12:25:33] <Andreas Stenius> how does it detect it (and how soon after the event?)
[12:25:44] Arjan leaves the room
[12:26:04] <Andreas Stenius> ah, how do you greet some one a good lunch in english...
[12:26:16] <Andreas Stenius> well, that'll have to do :p
[12:27:51] Arjan joins the room
[12:44:11] <Andreas Stenius> I be damned. The browser is able to request a new page from the server, receive some ajax response back of websocket and process that, before the browser fires the onunload event.. bah!
[13:09:13] <Maas> It monitors page sessions, so when that goes some checks are made. It can take upto a minute before the notification is fired.
[15:28:32] <Maas> ffing js
[17:20:14] <Maas> Happy... found a way to properly lex js without using a parser...
[17:22:28] <Maas> http://stackoverflow.com/questions/5519596/when-parsing-javascript-what-determines-the-meaning-of-a-slash
[17:35:19] Maas leaves the room
[17:47:46] Arjan leaves the room
[20:25:46] Arjan joins the room
[20:55:00] simon.smithies joins the room
[21:01:43] maas.maarten.zeeman joins the room
[21:33:28] Arjan leaves the room
[21:36:41] Arjan joins the room
[22:33:56] simon.smithies leaves the room
[22:36:26] Arjan leaves the room
[22:48:03] Andreas Stenius leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!