=== Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [12:44] hi gmb [12:44] Hi bac [12:45] gmb: do we prefer Y.Event.simulate over the other ways to do mouse-y type things in yahoo.utils.actionblah? [12:46] bac: As far as I know, yes. That's what I've used in the past. [12:46] ok, i was about to head down the other path when i looked and saw no uses of it. made me wonder if simulate was new-and-improved [12:47] bac: IDK; It's fairly straightforward to use though, IIRC. [12:47] bac: Also, sorry I didn't ping you again last night; I got sidetracked with home stuff so I didn't get a chance to carry on with the overlay investigation. [12:47] np. any chance you can make some progress today? [12:47] bac: I'll take a look at it again after standup; I'm working on mute button cleanup atm and don't want to switch just yet. [12:48] understood [12:48] gmb, sorry to bother you again but i remembered the blocker i had at EOD [12:49] in tearDown, how do i clean up stuff that i've inserted into the DOM? [12:49] i want to ensure i start with a clean slate but subsequent tests already have the accordion in them [12:49] i tried 'delete this.content_node' where c_n is as you'd expect, but it didn't do anything [12:50] bac: That's a tricky one, IIRC. You could do something like: [12:51] this.content_node.get('parentNode').removeChild(content_node); [12:51] ah, good one [12:51] i'll give it a try [12:51] Cool. [13:28] halloo [13:28] bac benji gmb mumble/kanban in 2 [13:28] Yup [13:28] rt [14:44] gmb, the messages from Y.log() that arrive in my browser console seem to be all jumbled. should it be expected that they appear out of order? [14:44] bac: Only if they're part of functions that are being called asynchronously. [14:44] Are they consistently in the same wrong order? [14:44] yeah [14:45] and it looks like tearDown is being called before the method i'm trying to test completes [14:45] ! [14:45] gmb: so i'm wondering if having the 'domready' in my JS is causing loads of problems [14:46] bac: Can you push your latest changes so I can take a look? I've had problems with asynchronicity in tests before now; usually you have to do some dancing around to fix it. [14:46] gmb: sure [14:46] it is riddled with Y.log statements [14:47] Sounds like one of my tests. [14:48] gmb: pushed to lp:~bac/launchpad/yellow-accordionoverlay [14:48] Okay. Grabbing it now. [14:49] gmb: have you seen these? http://www.bhphotovideo.com/c/product/752638-REG/Canon_Mugs_NK3212_Nikon_70_200mm_Vacuum_Insulated.html [14:49] makes me wish i had a need for one [14:49] * bac eagerly awaiting the UPS man today... [14:49] :) [15:16] bac: Can you give me an example of a test where the .log() messages are jumbled and what you expect them to look like? [15:17] gmb: test_logged_in_user fails, then the tearDown is called, then you get "yoohoo" my message from within setup [15:17] * gmb looks [15:19] so tearDown is removing the DOM elements before setup gets a chance to work on them [15:24] bac: Right. Your problem is that you've got that on('domready' ...) bit, which is asynchronous, so your test completes before the domready event fires. [15:24] Ah, race conditions. Love 'me. [15:24] *'em [15:25] bac: I'm not sure how to work around this one, though, unless you extract the stuff that's in on('domready') from setup(), make it into a function on its own and call that instead of setup(). [15:25] gmb: so even if domready is true, that bit will be pushed into a separate thread [15:25] gmb: i was already thinking of testing the innards separately as you describe [15:26] bac: Yes. I think that if you register a handler after an event has taken place YUI has basically got to go and check that the event has actually fired. I'm honestly not sure how nesting handlers of the same event will behave. [15:26] gmb: can i remove the domready and just make it a requirement on the caller? [15:26] (Well, badly, obviously, but htat's not the point) [15:26] bac: That would work, yes. [15:26] *should [15:26] :) [15:26] ok. i *thought* i was doing the right thing... [15:44] gmb, can you confirm off-hand that bug.owner is the reporter? The interface says, less than helpfully, "The owner's IPerson" [15:44] Thank you Very Much [15:44] :-) [15:44] gary_poster: Yes, owner is synonymous with reporter [15:44] awesome thank you [16:27] ok, I managed to sort out a merge from ~yellow/launchpad/accordionoverlay (I need to merge more often) and am about to push it back up [16:57] gmb: YUI unit test hygiene tip: if there is anything but "Test complete" in the main browser area after the test finishes then you haven't cleaned up the dom properly. [16:58] bac: Duly noted. [16:58] (Might be worth adding that to a wiki page, if there is one for this stuff) [16:58] gmb: that was mainly for my benefit... [16:58] finally, i am now ready to start the interaction testing. my sloppy dom had prevented it until now. [16:59] but first, pastrami [16:59] * gary_poster is lunching too [17:49] bac: AHA! Behold! http://pastebin.ubuntu.com/578450/ [17:49] lp:~gmb/launchpad/yellow-accordionoverlay [17:49] U jbwq [17:49] Er [17:50] I knew there had to be an event *somewhere* that we could hook into. I was just looking a level too low. [17:50] bac: That handles clicking off the overlay and also hitting ESC. [17:51] yay :) [17:51] It doesn't handle the form cancel button, interestingly, because FormOverlay doesn't fire the cancel event when you click 'cancel'; it just hides the overlay directly. [17:51] Which is a bug. [17:51] huh [17:51] does it handle the submit button? [17:52] gary_poster: Only insofar as it hides the overlay. [17:52] There's a degree of inheriting-but-not-quite going on between Overlay and FormOverlay. [17:52] sure--I guess I meant did it make the line above your change in the pastebin superfluous [17:58] gary_poster: Ah, no. [17:58] I hoped it would, but the event is 'cancel', not 'hide' (which is what I was originally looking for). [17:58] OIC [18:05] gary_poster, bac: I'm going afk for a while now; if you've any questions please email them to me. [18:05] ack, gmb, thanks [18:05] have a nice evening [18:05] Thanks. [19:31] bac, no rush, ready when you are [19:32] gary_poster: ok, just a sec [19:33] cool [19:37] http://pastebin.ubuntu.com/578450/ [21:00] benji ready when you are [21:00] k [21:00] (but no rush) [21:44] gary_poster, anything in the TL meeting about thunderdome locale? === bac` is now known as bac [22:00] nope bac :-/ [22:00] at least not that I remember [22:00] not in minutes [22:00] damn. people got vacations to plan! [22:01] :-) sorry [22:04] bac--your "add structural subscription" menu would also include "edit structural subscriptions" (however it is spelled) yeah? Going to to try and add that tomorrow [22:04] the rough version of the edit-per-target page [22:04] that is [22:22] gary_poster: sorry, i didn't see your question. Yes, if a person has existing structural subscriptions they will get another link in the global-actions portlet for editing those subscriptions [22:22] cool thanks [22:22] a link to a page we still need to create, AFAIK, yeah? [22:23] bug 674422, on the backlog [22:23] _mup_ is sleeping