[08:33:43 CDT(-0500)] <jessm> jamon: ping, how does your time look today?
[08:42:25 CDT(-0500)] <heidi_> jameswy for the fat panel, there is no save or cancel... can you remind me how that works again?
[08:44:12 CDT(-0500)] <jameswy> heidi_: When you make a change, it applies to the content immediately.
[08:44:22 CDT(-0500)] <jameswy> There's no notion of a "save" because of that.
[08:44:41 CDT(-0500)] <jameswy> (or rather, the "save" happens with every change that's made)
[08:44:59 CDT(-0500)] <jameswy> Cancel follows the same idea. No cancel, because there's no save.
[08:45:20 CDT(-0500)] <heidi_> so if you make a change, there's no way to not apply it ... you have to manually change it back
[08:45:33 CDT(-0500)] <jameswy> heidi_: Correct.
[08:45:39 CDT(-0500)] <jameswy> All changes are applied in real-time.
[08:45:54 CDT(-0500)] <heidi_> cindyli is this going to change much for UIO code for one version of UIO to not have buttons?
[08:46:07 CDT(-0500)] <heidi_> the panel versions rather
[08:46:11 CDT(-0500)] <heidi_> thanks jameswy
[08:46:49 CDT(-0500)] <heidi_> each control is going to be its own component soon so maybe it can be an option there
[08:47:00 CDT(-0500)] <jameswy> heidi_, cindyli: btw, I can see us putting in an "undo" later on
[08:47:28 CDT(-0500)] <heidi_> jameswy undo would be good ya
[08:47:41 CDT(-0500)] <jameswy> heidi_: For the time being though, there is a hard reset function.
[08:48:05 CDT(-0500)] <heidi_> right ya
[08:48:46 CDT(-0500)] <heidi_> colinclark we're discussing the panel vs full behaviour for saving - the panels don't have buttons so each control has to trigger a save when changed. i imagine it can be an option for control-components once they happen?
[08:49:13 CDT(-0500)] <heidi_> or an option somewhere...
[08:49:47 CDT(-0500)] <colinclark> I imagine it'll be an option for UI Options as a whole
[08:50:26 CDT(-0500)] <colinclark> But yes, that makes sense
[08:50:31 CDT(-0500)] <colinclark> We'll use the ChangeApplier...
[08:50:38 CDT(-0500)] <colinclark> which will fire events every time the model changes
[08:51:03 CDT(-0500)] <heidi_> cool
[08:51:03 CDT(-0500)] <colinclark> and if we're in a panel configuration, we'll have a special listener that automatically saves the model
[08:51:16 CDT(-0500)] <colinclark> And in the full version, we just won't have that listener
[08:51:27 CDT(-0500)] <heidi_> that sounds right
[08:51:29 CDT(-0500)] <heidi_> thanks
[08:51:31 CDT(-0500)] <colinclark> Cool
[08:54:18 CDT(-0500)] <jamon> jessm: what do you have in mind
[08:57:47 CDT(-0500)] <jessm> jamon: i have a number of vids and papers that need to find their way to the IDRC site – just wondered if you could lend a hand with them?
[08:59:46 CDT(-0500)] <jamon> as in joomla jessm?
[09:00:13 CDT(-0500)] <jessm> yes, the IDRC site is in joomla
[09:01:46 CDT(-0500)] <jamon> ok let me know what you want done then
[09:02:02 CDT(-0500)] <jessm> i'll send an email
[09:03:46 CDT(-0500)] <Justin_o> jamon: hello, i'm trying to get the daily build of the builder running again.. i think i've setup a working continuum build of it, but don't see it served up anywhere. Do you know if there is anything i need to do for that?
[09:05:01 CDT(-0500)] <jamon> Justin_o: see the builder served somewhere?
[09:05:16 CDT(-0500)] <Justin_o> jamon: yes.. the daily build of it
[09:05:34 CDT(-0500)] <Justin_o> i tried the link off the daily build page but that wasn't working
[09:06:11 CDT(-0500)] <jamon> i haven't really been involved with the builder, let me look at the log to see where it goes though
[09:54:42 CDT(-0500)] <mlam> Justin_o: colinclark: so the formdata's append function won't take in a JSON object as a value for the key/value pairing. And ajaxing in a file from the filesystem will return you a document, but the constructor property is a Document, not a File. And for some crazy reason, the append function rejects this as well. Any other suggestions?
[09:55:49 CDT(-0500)] <mlam> I guess I should add some context ^^. The uploader integration tests are breaking in FF4 on a call to formData's append function.
[09:57:15 CDT(-0500)] <colinclark> ahhhhhh
[09:57:25 CDT(-0500)] <colinclark> You're trying to give the FormData object a fake file, is that it?
[09:57:51 CDT(-0500)] <mlam> Yes
[09:58:01 CDT(-0500)] <colinclark> And yes, you're right, you can't use Ajax to get something as a File pointer
[09:58:20 CDT(-0500)] <colinclark> For obvious reasons, that would be something most users wouldn't want you doing on their file systems
[09:58:43 CDT(-0500)] <colinclark> It doesn't seem crazy at all the FormData wouldn't let you randomly drop some chunk of DOM into it
[09:59:01 CDT(-0500)] <colinclark> I mean, why would it?
[09:59:10 CDT(-0500)] <mlam> I've tried searching, but I can't find a way to mimic the creation of file objects the say way that the file dialog constructs them.
[09:59:18 CDT(-0500)] <colinclark> Yeah
[09:59:44 CDT(-0500)] <colinclark> In principle, it's the kind of thing you just shouldn't be able to do programmatically
[09:59:50 CDT(-0500)] <colinclark> so I'm not surprised that in practice, it's something you can't do
[10:00:13 CDT(-0500)] <colinclark> You're going to need to mock a bit further up the stack, mlam
[10:00:23 CDT(-0500)] <colinclark> Does that make sense?
[10:00:34 CDT(-0500)] <mlam> No, what do you mean?
[10:01:04 CDT(-0500)] <colinclark> Well, clearly using a real FormData isn't going to work for you, right?
[10:01:15 CDT(-0500)] <mlam> right
[10:01:33 CDT(-0500)] <mlam> so do you think the code should be factored so that the upload function takes in a formdata as a parameter?
[10:02:01 CDT(-0500)] <mlam> and from there, I can do any kind of manipulation to the formdata?
[10:02:53 CDT(-0500)] <colinclark> you could do that
[10:03:23 CDT(-0500)] <colinclark> I guess the interesting question is what do you end up actually doing with the FormData object?
[10:04:20 CDT(-0500)] <mlam> I think in this case, nothing. We're already mocking the XHR and if you're mocking the FormData then we're not really doing anything with it
[10:05:01 CDT(-0500)] <colinclark> yeah
[10:05:47 CDT(-0500)] <colinclark> I think I'd probably create a doFormDataUpload() method for the testing context and leave it at that
[10:06:30 CDT(-0500)] <mlam> Ok, sounds good. thanks colinclark
[10:06:39 CDT(-0500)] <colinclark> np
[10:07:34 CDT(-0500)] <harriswong> justin_o: i upgraded tooltip to 1.9m4's. They changed destroy to a 'private' function and it can no longer be called, i guess i am going to have to modify tooltip.js to call destroy?
[10:11:58 CDT(-0500)] <Justin_o> harriswong: sounds like it
[10:12:29 CDT(-0500)] <Justin_o> harriswong: is the tooltip plugin still creating multiple instances of itself or will it use one per page?
[10:12:52 CDT(-0500)] <Justin_o> cindyli: i'm working on getting a daily build of the builder running again
[10:12:53 CDT(-0500)] <harriswong> justin_o: so i guess we are upgrading the tooltip? since the old one seems to dislike 1.6rc1
[10:13:12 CDT(-0500)] <Justin_o> cindyli: is it okay for me to make changes to the ant script.. and if so anything I should be looking out for
[10:13:15 CDT(-0500)] <harriswong> justin_o: how should i verify if the tooltip is still creating multiple instances of itself?
[10:13:57 CDT(-0500)] <Justin_o> harriswong: try using it on a page and see if you get a new elements added to the end of the body everytime you call a new toolitp
[10:14:02 CDT(-0500)] <Justin_o> this can be seen on the pager example i think
[10:14:17 CDT(-0500)] <cindyli> Justin_o: u certainly can make changes to the ant script. there's one thing at least at the top of my head u need to watch, let me dig out
[10:14:32 CDT(-0500)] <Justin_o> cindyli: thanks
[10:14:44 CDT(-0500)] <cindyli> np
[10:15:25 CDT(-0500)] <harriswong> justin_o: in the pager demo, tooltip seems to focus and blur fine. i see only 1 tooltip box when i move from page to page. No extra was duplicated or left unkilled
[10:17:26 CDT(-0500)] <harriswong> justin_o: i am thinking if this is a "private" function in the newer version, then we shouldn't have to call it; and i am assuming it's destroying itself automatically.
[10:17:30 CDT(-0500)] <Justin_o> harriswong: right.. but if you look at the DOM you should see that on each page link a new tooltip element is created
[10:17:45 CDT(-0500)] <Justin_o> hopefully
[10:17:47 CDT(-0500)] <Justin_o> that would be good
[10:18:59 CDT(-0500)] <harriswong> justin_o: i see a lot of div at the end of the "body" tag.
[10:19:55 CDT(-0500)] <harriswong> justin_o: and as i click through pages, the old tooltip didn't get removed.
[10:20:05 CDT(-0500)] <Justin_o> harriswong: yes.. that's it creating new markup for each tooltip..
[10:20:18 CDT(-0500)] <Justin_o> are you testing the new one?
[10:21:12 CDT(-0500)] <jessm> hey everyone, if you have TA questions please ask me
[10:21:21 CDT(-0500)] <jessm> i've got as a to-do to get in touch with you all to talk about TA
[10:22:33 CDT(-0500)] <harriswong> justin_o: yes i am using the new version of tooltip. However, it depends on the other 3 files, ui.core, ui.widget, ui.position. I am still using 1.8.11 for those.
[10:23:02 CDT(-0500)] <harriswong> justin_o: i am not sure if the ui.tooltip needs the 1.9m4 for those 3 files in order for it to work.
[10:23:14 CDT(-0500)] <Justin_o> harriswong: hmm.. good question
[10:23:39 CDT(-0500)] <Justin_o> harriswong: but if it seems to be okay.. i guess it's fine.. are you getting duplicate tooltips or ones that won't disappear at all
[10:23:42 CDT(-0500)] <harriswong> justin_o: and those 3 prob depends on the others as well as you backtrace the tree.
[10:23:58 CDT(-0500)] <Justin_o> and did you try with keyboard navigation as well as mouse to try to bring up the tooltip
[10:24:42 CDT(-0500)] <Justin_o> harriswong: yes.. that's probably true.. i guess if it works don't worry to much about it.. we were already using one of the 1.9 prelease tooltips so i guess it's okay
[10:24:53 CDT(-0500)] <harriswong> justin_o: yes, once I press enter, the tooltip remains.
[10:25:11 CDT(-0500)] <Justin_o> harriswong: yes.. so i think that's what the call to destroy was for
[10:25:35 CDT(-0500)] <Justin_o> they haven't exposed anyway of calling it eh?
[10:26:00 CDT(-0500)] <harriswong> Justin_o: a quick hack is to change _destroy back to "destroy" in ui.tooltip.js so it's public again. But i don't thikn i am allowed to do that
[10:26:36 CDT(-0500)] <harriswong> justin_o: is there a way in Tooltip.js to call the tooltip widget element so i can manaully trigger "this.tooltip.remove()"?
[10:26:50 CDT(-0500)]

<cindyli> Justin_o: in build.xml, line 7: <property file="$

Unknown macro: {home}

/infusion-builder.properties" />

[10:26:50 CDT(-0500)] <cindyli> this file is used by the daily build. it contains the db credentials. if you will have another way to provide those info, remove this line also this file from the server, otherwise, keep it intact
[10:27:12 CDT(-0500)] <Justin_o> harriswong: yes.. you'd want to avoid changing the 3rd party file.. you can change the wrapper though
[10:27:26 CDT(-0500)] <harriswong> justin_o: not that i know of on the ui.tooltip file. _destroy is not being called at all. maybe the new widget file does the destroy for all widgets.
[10:27:30 CDT(-0500)] <colinclark> Justin_o, harriswong: I'm just catching up on your discussion
[10:27:34 CDT(-0500)] <Justin_o> harriswong: i think you can call the widget.. I believe i do it in the wrapper already
[10:27:34 CDT(-0500)]

<cindyli> Justin_o: the file i referred to is "$

Unknown macro: {home}

/infusion-builder.properties"

[10:27:36 CDT(-0500)] <colinclark> Can you guys fill me in on the back story here?
[10:28:10 CDT(-0500)] <harriswong> colinclark: old tooltip failed the unit test for 1.6rc1.
[10:28:20 CDT(-0500)] <colinclark> ok
[10:28:33 CDT(-0500)] <colinclark> I guess that's because it was just some snapshot of the code we grabbed
[10:28:56 CDT(-0500)] <Justin_o> cindyli: okay.. thanks.. is there anything i need to worry about other than that between the differenet deployments.. local, server, dailybuild
[10:29:07 CDT(-0500)] <harriswong> colinclark: attr() was changed so the "" becomes "undefined" now and tooltop broke. Justin_o suggested me to try the new snapshot so i was trying it.
[10:29:20 CDT(-0500)] <colinclark> ok
[10:29:34 CDT(-0500)] <colinclark> The new snapshot being the version of Tooltip that ships with 1.9m4?
[10:29:40 CDT(-0500)] <harriswong> colinclark: and found that unit test fails and one of which was "destroy" is not called.
[10:29:56 CDT(-0500)] <harriswong> colinclark: yes, 1.9m4.
[10:30:12 CDT(-0500)] <colinclark> So, these unit tests you're referring to...
[10:30:31 CDT(-0500)] <colinclark> are these for the jQuery UI Tooltip? Or do we have a wrapper component for their widget?
[10:30:42 CDT(-0500)] <cindyli> Justin_o: no, as far as i know. let me know if anything in paticular u have concern about
[10:30:51 CDT(-0500)] <harriswong> colinclark: so after some more tracing, it seems like tooltip's "destroy" in 1.9m4 is now a private fn and can't be called externally by the Tooltip.js.
[10:31:04 CDT(-0500)] <Justin_o> cindyli: okay thanks
[10:31:15 CDT(-0500)] <cindyli> np
[10:31:34 CDT(-0500)] <harriswong> colinclark: the unit test is the one in Fluid, namely, TooltipTests.js
[10:31:45 CDT(-0500)] <colinclark> Okay, so we do have a wrapper component for jQuery UI's tooltip
[10:31:55 CDT(-0500)] <colinclark> and it implements this destroy() method
[10:32:10 CDT(-0500)] <colinclark> which calls down to the jQuery UI Tooltip's "destroy" method
[10:32:13 CDT(-0500)] <Justin_o> cindyli: the two things i might change are 1) set the permissions on the temp and cache directories to be 777, since there are permission errors at the moment on the daily build because of this 2) might add in a target to do the git checkout of infusion... although not sure about this part just yet
[10:32:15 CDT(-0500)] <colinclark> but that has been made private
[10:32:45 CDT(-0500)] <colinclark> Justin_o: Remind me why we have a component with a destroy() method? Seems somewhat unconventional.

[10:32:50 CDT(-0500)] <harriswong> colinclark: Yes.
[10:33:22 CDT(-0500)] <Justin_o> colinclark: i believe it was because the tooltip would linger around after the renderer would destroy the markup and rerender it
[10:33:36 CDT(-0500)] <Justin_o> for the pager's page links
[10:33:42 CDT(-0500)] <harriswong> colinclark: justin_o correct me if i am wrong. I think destroy() is used to delete the tooltip right after it has been created after each click.
[10:35:18 CDT(-0500)] <colinclark> Justin_o: So, an example... User hovers over a link in the pager bar, and the tooltip shows up. Then they click on that link, causing the pager bar to be rerendered.
[10:35:36 CDT(-0500)] <colinclark> The problem was that even after rerendering, the tooltip would be floating there?
[10:35:47 CDT(-0500)] <colinclark> Is that correct?
[10:35:53 CDT(-0500)] <Justin_o> colinclark: i believe so
[10:35:58 CDT(-0500)] <colinclark> Okay
[10:42:08 CDT(-0500)] <colinclark> So is that a bug in the jQuery UI Tooltip? In other words, when you click on something, shouldn't the Tooltip dismiss itself?
[10:42:22 CDT(-0500)] <colinclark> Justin_o: ^
[10:43:28 CDT(-0500)] <Justin_o> colinclark: i'm trying to remember back, but i think there was something about the fact that basically the events would unbind before it had a chance to tell it to hide itself
[10:43:53 CDT(-0500)] <colinclark> hmm
[10:45:09 CDT(-0500)] <colinclark> Okay, so
[10:45:51 CDT(-0500)] <colinclark> When you say "the events would unbind," you mean that the process of rerendering would cause the Tooltip to be unbound from its attached element, and then it would never hide itself?
[10:45:53 CDT(-0500)] <colinclark> Or something like that?
[10:46:48 CDT(-0500)] <cindyli> Justin_o: ic. nothing else i wanna warn u about

[10:47:01 CDT(-0500)] <Justin_o> colinclark: yes.. that' sounds more correct
[10:47:07 CDT(-0500)] <Justin_o> cindyli: thanks
[10:47:11 CDT(-0500)] <cindyli> np
[10:49:05 CDT(-0500)] <colinclark> Justin_o: Do you know if we have any kind of test or example that shows this particular problem?
[10:49:31 CDT(-0500)] <Justin_o> colinclark: don't remember if there is a test.. probably not...
[10:49:38 CDT(-0500)] <colinclark> Okay
[10:49:43 CDT(-0500)] <Justin_o> you can see it happen in the pager if comment out the call to destroy
[10:50:04 CDT(-0500)] <colinclark> Okay, so that sounds like it might be mission #1
[10:50:53 CDT(-0500)] <colinclark> harriswong: Is there any replacement method for "destroy" in the jQuery UI Tooltip?
[10:51:47 CDT(-0500)] <Justin_o> colinclark: here's where it is used in the pager https://github.com/fluid-project/infusion/blob/master/src/webapp/components/pager/js/Pager.js#L246-255
[10:52:16 CDT(-0500)] <harriswong> colinclark: not that i know of, that can be called externally.
[10:54:30 CDT(-0500)] <colinclark> Is there some kind of event we can register a listener for, which tell us when the tooltip has successfully closed or destroyed itself?
[10:54:35 CDT(-0500)] <colinclark> harriswong: ^
[10:56:15 CDT(-0500)] <harriswong> colinclark: in the wrapper, i see events firing for afterOpen and afterClose.
[10:56:28 CDT(-0500)] <colinclark> Sorry, I meant the jQuery UI Tooltip
[10:57:15 CDT(-0500)] <harriswong> colinclark: I don't see any obvious '.fire' in the jQuery ui tooltip.
[10:57:32 CDT(-0500)] <colinclark> jQuery UI widgets don't use fire(), harriswong
[10:57:50 CDT(-0500)] <harriswong> colinclark: oh what does it use?
[10:57:59 CDT(-0500)] <colinclark> The jQuery event system
[10:59:37 CDT(-0500)] <harriswong> colinclark: in that case, then i see some bindings. Do you think that would be it?
[11:00:01 CDT(-0500)] <harriswong> colinclark: it binds mouseout, blur to a self.close(event).
[11:00:21 CDT(-0500)] <colinclark> bind() is for listening to events
[11:01:19 CDT(-0500)] <colinclark> You're looking for calls to trigger()
[11:01:57 CDT(-0500)] <colinclark> harriswong: Here's the documentation for jQuery.trigger() http://api.jquery.com/trigger/
[11:02:17 CDT(-0500)] <colinclark> looks to me like it does fire a "close" event
[11:02:18 CDT(-0500)] <harriswong> colinclark: thank you for the helpful information.
[11:02:44 CDT(-0500)] <harriswong> seems to be triggering for show as well.
[11:02:52 CDT(-0500)] <colinclark> right
[11:06:24 CDT(-0500)] <colinclark> So, harriswong, it seems like our next step needs to be figure out whether or not the newest version of jQuery UI's Tooltip still behaves in the way Justin_o mentioned
[11:06:33 CDT(-0500)] <colinclark> If it were me, I'd be writing a unit test for this
[11:06:57 CDT(-0500)] <colinclark> But for now you could probably play around with the Pager
[11:07:14 CDT(-0500)] <colinclark> See what the behaviour is like with and without the call the Tooltip.destroy()
[11:07:33 CDT(-0500)] <colinclark> If the "bug" is gone, then we're in really good shape
[11:07:41 CDT(-0500)] <colinclark> If not, we need to come up with a somewhat different strategy
[11:08:04 CDT(-0500)] <colinclark> Which might have to be to rerender the pager bar only after the Tooltip has closed itself
[11:09:20 CDT(-0500)] <harriswong> colinclark: will do.
[11:09:24 CDT(-0500)] <colinclark> thanks
[11:09:29 CDT(-0500)] <harriswong> colinclark: thanks.
[11:23:19 CDT(-0500)] <colinclark> mlam: I have an idea...
[11:23:29 CDT(-0500)] <colinclark> I'm looking at your pull request
[11:23:38 CDT(-0500)] <colinclark> and thinking a bit about the distinction between an integration test and a unit test
[11:24:02 CDT(-0500)] <colinclark> In an integration test, we want to check that all the pieces fit together properly, resulting in a functioning Uploader
[11:24:15 CDT(-0500)] <colinclark> which your new tests in UploaderTests.js do nicely
[11:24:30 CDT(-0500)] <colinclark> A unit test is going to test a single piece of behaviour
[11:24:53 CDT(-0500)] <colinclark> With the way the Uploader is now generally factored, that probably means testing individual functions
[11:25:16 CDT(-0500)] <colinclark> I'm looking at the implementation of doFormDataUpload() and thinking there's a lot in there that we might want to test
[11:25:38 CDT(-0500)] <colinclark> Breaking it down, doFormData() does a few things:
[11:25:55 CDT(-0500)] <colinclark> 1. It appends the specified file to a FormData instance
[11:26:14 CDT(-0500)] <colinclark> 2. It takes any specified POST parameters and adds them to the FormData instance as well
[11:26:24 CDT(-0500)] <colinclark> 3. It opens the XHR with the appropriate URL
[11:26:30 CDT(-0500)] <colinclark> 4. It sends the FormData along
[11:27:12 CDT(-0500)] <colinclark> We don't have a unit test currently that checks this workflow in the HTML5Strategy tests
[11:27:29 CDT(-0500)] <colinclark> but I think it would be pretty straightforward to write
[11:27:46 CDT(-0500)] <colinclark> A mock FormData that keeps track of what's been appended to it, and in what order
[11:28:01 CDT(-0500)] <colinclark> A mock XHR that tracks the method and URL used to open it
[11:28:13 CDT(-0500)] <colinclark> And then you could assert tests on the state of the mock
[11:30:18 CDT(-0500)] <colinclark> Of course we'd get pretty much all of this for free if we could use Mockjax, but that's probably not going to happen for this release.
[11:30:30 CDT(-0500)] <colinclark> So you could roll your own little mock and write the appropriate test
[12:42:59 CDT(-0500)] <mlam> colinclark: The HTML5 Unit test makes sense. I should probably write the same type of test for sending files as binary
[12:43:10 CDT(-0500)] <colinclark> that sounds like a pretty good idea
[12:43:17 CDT(-0500)] <colinclark> go for it if you feel like it
[14:06:48 CDT(-0500)] <colinclark> Hey cindyli, how's it going for UI Options
[14:06:49 CDT(-0500)] <colinclark> ?
[14:06:54 CDT(-0500)] <colinclark> with UI Options
[14:06:56 CDT(-0500)] <colinclark>

[14:09:14 CDT(-0500)] <cindyli> ha
[14:10:07 CDT(-0500)] <cindyli> colinclark: working on image gallery today. regarding ui options, fixed some tests for ui options yesterday, still 3 fails which is my next step
[14:11:21 CDT(-0500)] <cindyli> colinclark: after that, need to fix tests for text slider, which i'm waiting for your response if we should support 2 ways to supply slider initial value, one is via js defaults block, the other is the default initial value set into text field <input>
[14:11:28 CDT(-0500)] <colinclark> oh, yes
[14:11:32 CDT(-0500)] <colinclark> sorry, I forgot about that
[14:11:50 CDT(-0500)] <colinclark> I can be very forgetful--don't hesitate to bug me again about those kinds of questions
[14:11:53 CDT(-0500)] <colinclark> rather than just waiting

[14:12:39 CDT(-0500)] <cindyli> colinclark: certainly, going to bug u when i'm back there
[14:12:41 CDT(-0500)] <cindyli>

[14:12:44 CDT(-0500)] <colinclark> lol
[14:12:45 CDT(-0500)] <colinclark>

[14:30:38 CDT(-0500)] <cindyli> mlam: colinclark, although the uploader fileType option is set to "*.gif", the jpgs are still able to get uploaded. i vaguely rmb mlam mentioned html5 controls file type by mime type, regardless of the actually specified file extensions?
[14:31:02 CDT(-0500)] <colinclark> cindyli: So there's two things at play here
[14:31:19 CDT(-0500)] <colinclark> 1. mlam has a fix for specifying fileTypes for the HTML5 version of Uploader, but it isn't yet in the project repo
[14:31:37 CDT(-0500)] <colinclark> 2. Most browsers don't currently support filtering based on file types
[14:31:39 CDT(-0500)] <colinclark> it's very bizarre
[14:31:43 CDT(-0500)] <cindyli> is ff3.6 using html5
[14:31:48 CDT(-0500)] <colinclark> Mozilla claimed it "wasn't that important"
[14:32:06 CDT(-0500)] <colinclark> Yep, the only browser that doesn't support the HTML5 version is IE
[14:32:12 CDT(-0500)] <colinclark> which uses the Flash version
[14:32:13 CDT(-0500)] <cindyli> ic
[14:33:08 CDT(-0500)] <cindyli> not sure how the #2 related to the issue?
[14:34:47 CDT(-0500)] <cindyli> colinclark: and, as u know that i'm adding "allowed file types" into image gallery so the users can play with it. wondering what's the work-around then?
[14:35:50 CDT(-0500)] <colinclark> I think there is none for the HTML5 version
[14:35:51 CDT(-0500)] <colinclark> in
[14:36:00 CDT(-0500)] <colinclark> in other words, we can add the option
[14:36:01 CDT(-0500)] <cindyli> oh ha
[14:36:18 CDT(-0500)] <colinclark> and until the browsers fix their issues, it just won't work in HTML5 browsers
[14:36:21 CDT(-0500)] <colinclark> not ideal, I know
[14:36:25 CDT(-0500)] <colinclark> but someday they will fix their bug
[14:36:32 CDT(-0500)] <colinclark> and then it'll all work without you having to update your code
[14:36:57 CDT(-0500)] <cindyli> ok, so should i remove this option from the image gallery?
[14:37:29 CDT(-0500)] <cindyli> not from the uploader init js, i mean from ui
[14:38:08 CDT(-0500)] <cindyli> colinclark?
[14:38:21 CDT(-0500)] <colinclark> no, you should include it in the UI
[14:38:42 CDT(-0500)] <colinclark> and it will only have an effect on Flash browsers for now
[14:39:15 CDT(-0500)] <cindyli> ok but, would it be weird that it doesn't work in other browsers?
[14:39:20 CDT(-0500)] <colinclark> yes, quite weird
[14:39:36 CDT(-0500)] <cindyli> alrite, will leave it in there
[14:39:52 CDT(-0500)] <colinclark> If it makes you feel any better, you could put a little note on the page explaining that some browsers don't support filtering based on file type
[14:39:57 CDT(-0500)] <colinclark> but think about it this way
[14:40:05 CDT(-0500)] <colinclark> Firefox 5 is due out in a month
[14:40:23 CDT(-0500)] <colinclark> Do you want to have to go back and update that code once it's released, assuming it fixes the issue?
[14:40:36 CDT(-0500)] <colinclark> Or would you rather have it "just work" when the new browsers come out?
[14:40:49 CDT(-0500)] <colinclark> I haven't checked recently to see what Chrome does
[14:40:52 CDT(-0500)] <colinclark> it might actually support it now
[14:49:23 CDT(-0500)] <cindyli> sounds good.
[15:03:36 CDT(-0500)] <anastasiac> heidi_, I'm looking at the changes that were made to FSS for active menu items, the new fl-activemenu class. Is it supposed to be applied to the <li>?
[15:10:20 CDT(-0500)] <heidi_> anastasiac i don't think it's new, i think it's in the documentation? it just wasn't being used by default, if i'm remembering correctly
[15:10:31 CDT(-0500)] <heidi_> i think the themes were using it
[15:12:38 CDT(-0500)] <anastasiac> heidi_, ok, I looked into that this morning: it was in the docs incorrectly. It was never in the actual base layout file
[15:12:50 CDT(-0500)] <anastasiac> the reason I'm asking is because it doesn't seem to be working for me
[15:13:04 CDT(-0500)] <anastasiac> there is a unit test for the menus, but it doesn't seem to have been updated
[15:13:08 CDT(-0500)] <heidi_> i think it's used in the themes fss demo
[15:13:10 CDT(-0500)] <heidi_> looking..
[15:13:11 CDT(-0500)] <anastasiac> it's using "fl-activeItem" for some odd reason
[15:13:38 CDT(-0500)] <anastasiac> heidi_, the old walkthrough used it, but the style was only present in the custom css file
[15:14:47 CDT(-0500)] <heidi_> anastasiac yeah <li class="fl-activemenu"> seems to be how to use it.
[15:14:59 CDT(-0500)] <anastasiac> ok, well, it's not working for me, heidi_
[15:15:08 CDT(-0500)] <anastasiac> are you able to update the unit test and see it working?
[15:15:18 CDT(-0500)] <heidi_> ok, looking...
[15:15:22 CDT(-0500)] <anastasiac> outside the context of a particular theme, that is, heidi_
[15:15:31 CDT(-0500)] <heidi_> right... let me see
[15:20:51 CDT(-0500)] <heidi_> anastasiac are you using the deprecated fl-listmenu
[15:20:56 CDT(-0500)] <heidi_> or fl-list-menu.
[15:21:00 CDT(-0500)] <heidi_> it works for me, for the latter
[15:21:36 CDT(-0500)] <anastasiac> ah, shoot - it looks like I am. Thanks, heidi_

[15:21:40 CDT(-0500)] <heidi_> np!
[15:21:50 CDT(-0500)] <anastasiac> yep, works now
[15:21:57 CDT(-0500)] <heidi_> our theme demo should be updated - it's using listmenu
[15:22:04 CDT(-0500)] <heidi_> cool

Browser not supported