fluid-work IRC Logs-2010-12-07

[09:03:56 CST(-0600)] <justin_o> mlam: thanks for the update on the jiras...
[09:04:12 CST(-0600)] <justin_o> mlam, colinclark: you guys are still working out of a branch in the incubator?
[09:04:26 CST(-0600)] <colinclark> at the moment, justin_o, yes
[09:04:28 CST(-0600)] <colinclark> I can merge any time
[09:04:35 CST(-0600)] <colinclark> I've just been avoiding it
[09:04:37 CST(-0600)] <colinclark>
[09:04:56 CST(-0600)] <justin_o> okay.. just wondering when that was going to happen
[09:05:01 CST(-0600)] <justin_o> no rush today though
[09:07:09 CST(-0600)] <colinclark> I'll try to do it asap
[09:24:51 CST(-0600)] <heidi> jhung so pager working ok for you? need me to test anything?
[09:25:32 CST(-0600)] <jhung> heidi: yeah so far. I may need your help looking into an odd hovering issue in the table headers. I'll send up a patch.
[09:25:42 CST(-0600)] <heidi> jhung cool ping me when its ready
[09:36:45 CST(-0600)] <jhung> justin_o: heidi is having the same problem with pager that I was having on my laptop @ work.
[09:37:01 CST(-0600)] <heidi> justin_o i can show you on screen share if you'd lik
[09:37:05 CST(-0600)] <heidi> it shows only on record
[09:37:10 CST(-0600)] <heidi> *one
[09:40:06 CST(-0600)] <justin_o> heidi: sure.. are you using firefox by any chance?
[09:40:40 CST(-0600)] <heidi> justin_o yep
[09:41:23 CST(-0600)] <justin_o> heidi: there is an ajax call there... so it's probably your security settings in firefox
[09:41:42 CST(-0600)] <heidi> justin_o what should i change?
[09:42:01 CST(-0600)] <jhung> justin_o: is that something new?
[09:42:10 CST(-0600)] <justin_o> if you type about:config into the address bar... agree that you will be careful... do a search for "security" and set the strict origin policy thing to false
[09:42:13 CST(-0600)] <justin_o> that should do it
[09:42:34 CST(-0600)] <heidi> justin_o seems sort of strange to have to do this to get a demo working, ya?
[09:42:54 CST(-0600)] <justin_o> yes
[09:43:27 CST(-0600)] <justin_o> I'm not a big fan of having ajax calls in our demos because of this...
[09:43:46 CST(-0600)] <justin_o> colinclark was thinking of switching it to use jsonp instead... maybe we should switch to that..
[09:44:40 CST(-0600)] <heidi> justin_o yeah that did it
[09:44:52 CST(-0600)] <heidi> yeah seems odd to have to edit ff config
[09:45:11 CST(-0600)] <heidi> cos it looks pretty broken without doing that
[09:45:21 CST(-0600)] <justin_o> heidi: yah.. it's just for local ajax.. ff doesn't think people should do ajax calls to their own machine...
[09:45:40 CST(-0600)] <justin_o> but agreed... we should think of a strategy for this
[09:45:42 CST(-0600)] <jhung> justin_o: colinclark was working on jasonp, but was broken before. We suspected it had something to do with the old Sakai data file.
[09:46:00 CST(-0600)] <jhung> justin_o: we have since changed the data file, so maybe it's worth visiting this issue again.
[09:46:11 CST(-0600)] <justin_o> jhung: oh the jsonp didn't work?
[09:46:16 CST(-0600)] <justin_o> with the old data that is
[09:47:22 CST(-0600)] <jhung> justin_o: that what we thihnk. There was invalid markup in the data. The new datafile should be cleaner.
[09:47:50 CST(-0600)] <justin_o> ah i see
[09:58:46 CST(-0600)] <heidi> justin_o is it something we want on bug parade? or is it too involved
[09:59:08 CST(-0600)] <justin_o> heidi: hmm.. i don't think we'd want to bug parade it for this release...
[09:59:16 CST(-0600)] <justin_o> but something we may want to talk about for later
[09:59:21 CST(-0600)] <heidi> k do we have that security fix mentioned somewhere?
[10:00:15 CST(-0600)] <justin_o> I think it's on the wiki somewhere but i can't remember.. it may have just been on list
[10:01:37 CST(-0600)] <justin_o> did a quick look on the wiki and didn't see anything.. so i'm going to guess if it was documented anywhere it will be in the list archives.. somewhere... we may want to get this in the wiki
[10:15:14 CST(-0600)] <heidi> justin_o yeah, or in the release notes? is there an infusion readme
[10:15:29 CST(-0600)] <justin_o> heidi: there is
[10:16:09 CST(-0600)] <justin_o> it's in top directory in trunk i think
[10:16:45 CST(-0600)] <heidi> justin_o maybe pager ff security note should go there
[10:17:59 CST(-0600)] <justin_o> heidi: i guess we could add a note about it... there are other components that do local ajax calls too...so we might want to have a section for it
[10:18:12 CST(-0600)] <heidi> ya
[10:18:16 CST(-0600)] <heidi> for sure
[10:18:56 CST(-0600)] <justin_o> heidi: could you please remind me about this on thursday... that'w when we will be doing our big push to get all these general type issues done
[10:19:13 CST(-0600)] <heidi> justin_o sure. would help to make a jira about it?
[10:19:33 CST(-0600)] <justin_o> there should be a jira about the readme file.. and you could comment on that...
[10:19:37 CST(-0600)] <justin_o> i'll see if i can find it
[10:20:04 CST(-0600)] <heidi> that works
[10:25:06 CST(-0600)] <justin_o> heidi: okay.. had to make one... here it is http://issues.fluidproject.org/browse/FLUID-3879
[10:25:17 CST(-0600)] <heidi> justin_o sweet
[10:43:12 CST(-0600)] <justin_o> fluid-everyone: here's my standup update
[10:45:09 CST(-0600)] <justin_o> trying to keep track of all that's going on for bug parade. Working FLUID-3288... trying to write a unit test for it.. also noticed that the fix looks like it has broken other unit tests.. will have to investigate
[10:45:34 CST(-0600)] <justin_o> then going to look at FLUID-3831 and try to get the tooltip wrapped
[10:45:54 CST(-0600)] <justin_o> I'll be offline sometime between 3 and 4 today
[10:46:03 CST(-0600)] <jessm> justin_o: cool-io
[11:50:05 CST(-0600)] <anastasiac> Bosmon2, I just noticed a comment you added in FluidIoC.js: "NON_API function." Is this what we described as "not guaranteed to remain consistent from release to release but visible out of courtesy to developers" ?
[11:53:34 CST(-0600)] <Bosmon2> Yes - well, in this case it's not even clear whether the reason it is visible is as a "courtesy"
[11:53:36 CST(-0600)] <Bosmon2> I guess it is
[11:53:57 CST(-0600)] <Bosmon2> I guess I should put a few more such comments around before we go to final release
[11:54:17 CST(-0600)] <Bosmon2> There are some options, for example, on "initRendererComponent" that I don't want considered part of our delivered functionality since they are not yet properly thought out
[11:57:14 CST(-0600)] <anastasiac> Bosmon2, regarding the options: you mean don't document them yet, right? If so, then yes, some comments to that effect would be helpful More helpful, feel free to edit the documentation
[11:58:22 CST(-0600)] <anastasiac> Bosmon2, regarding the NON-API functions: I think we'd decided to call them "unsupported" - it seemed a reasonably meaningful description. If you're editing comments, maybe you could change that?
[12:04:47 CST(-0600)] <Bosmon2> ok
[12:22:22 CST(-0600)] <mlam> justin_o: FLUID-3874 resolved.
[12:22:33 CST(-0600)] <justin_o> mlam: thanks
[12:23:12 CST(-0600)] <justin_o> mlam, colinclark: what is left for uploader?
[12:23:17 CST(-0600)] <colinclark> A few things
[12:23:27 CST(-0600)] <colinclark> I'm trying to wrap up progressive enhancement
[12:23:31 CST(-0600)] <jhung> heidi, justin_o: do either of you know if there is a jira for the IE FSS focus issue (black 2px outline appears around every focusable element).
[12:23:37 CST(-0600)] <colinclark> Bosmon2 was a big help with suggesting a new strategy for that
[12:23:57 CST(-0600)] <colinclark> I want to put something in for options backwards compatibility
[12:24:05 CST(-0600)] <colinclark> but will merge with trunk as soon as prog enhance is in
[12:24:19 CST(-0600)] <colinclark> justin_o: I was hoping when that happens we could get some people here to help mlam and I with testing
[12:24:57 CST(-0600)] <justin_o> colinclark: okay... makes sense
[12:25:13 CST(-0600)] <colinclark> heidi: I was hoping you'd help with some Uploader tesing
[12:25:29 CST(-0600)] <colinclark> You were keen to see it work progressively (like in IE, etc), and we're really close
[12:25:44 CST(-0600)] <justin_o> jhung: not sure... heidi do you remember if you filed one after talking to the uPortal folks
[12:30:31 CST(-0600)] <heidi> jhung i'm not sure - i didn't create one yet, but there might be one about fss reset
[12:30:48 CST(-0600)] <heidi> colinclark can help testing - ping me when its ready!
[12:30:59 CST(-0600)] <jhung> heidi: looking now...
[12:31:33 CST(-0600)] <jhung> heidi: nope. Nothing. I'll create a new Jira.
[12:31:44 CST(-0600)] <heidi> sounds good
[12:38:33 CST(-0600)] <jhung> offtopic: Google Chrome live event - http://www.youtube.com/user/googlechrome
[12:47:17 CST(-0600)] <justin_o> colinclark, michelled: I've posted another patch to FLUID-3288 which was the issue about having to double tap in safari to move an item
[12:48:08 CST(-0600)] <colinclark> jhung: Can you summarize anything interesting that comes out of the event?
[12:48:08 CST(-0600)] <justin_o> I tried writing a unit test for this, but i am unable to get a proper test case because the issue is that a blur event was being called during the move
[12:48:14 CST(-0600)] <colinclark> I'm pretty curious but don't have time to watch
[12:48:55 CST(-0600)] <jhung> colinclark: so far - speed. Hardware acceleration. WebGL. Streamline UI design...
[12:52:40 CST(-0600)] <jhung> heidi, justin_o: FSS reset focus issue http://issues.fluidproject.org/browse/FLUID-3880
[12:52:53 CST(-0600)] <heidi> k
[12:54:22 CST(-0600)] <justin_o> jhung: thanks
[13:05:13 CST(-0600)] <anastasiac> Bosmon2, a quick question about the 'operate()' function on the object returned by fluid.fetchResources(): What was the thinking behind attaching it to the component? What use case do you envision for the user invoking it?
[13:09:45 CST(-0600)] <jhung> they're announcing new Chrome app store and Kindle for the web. Lots of HTML 5 stuff there.
[13:18:08 CST(-0600)] <Bosmon2> anastasiac - it is just a method exposed so that there is a name attached to this operation that is different to other names
[13:18:36 CST(-0600)] <Bosmon2> You could also consider that an "unsupported" function... even though it clearly operates the whole business of fluid.fetchResources()
[13:18:54 CST(-0600)] <Bosmon2> But it is certainly not anything that could probably successfully be called "again"
[13:20:00 CST(-0600)] <anastasiac> Bosmon2, thanks for the clarification. We'll have to give some thought to how to document these things - "This is a function that you can see, but we don't expect you to ever use it - don't even bother to try"
[13:28:06 CST(-0600)] <heidi> mlam i finally figured out why the empty inline edits look weird in IE - fss reset strikes again. it adds a 1em bottom padding to all p's
[13:28:33 CST(-0600)] <mlam> ohhh nice catch
[13:28:46 CST(-0600)] <heidi> phew, patch up soon
[13:28:50 CST(-0600)] <mlam> sweet
[13:28:51 CST(-0600)] <heidi> then i can move on with my life!
[13:28:53 CST(-0600)] <mlam> i'll test it out
[13:28:54 CST(-0600)] <mlam> hahaha
[13:41:39 CST(-0600)] <justin_o> jhung: is FLUID-3731 ready for review again?
[13:41:49 CST(-0600)] <jhung> justin_o: yep.
[13:41:56 CST(-0600)] <justin_o> jhung: thanks
[13:44:50 CST(-0600)] <colinclark> Bosmon2: So I'm fuzzy on this fetchResources situation, then
[13:45:21 CST(-0600)] <colinclark> We return a value from a call to fetchResources, containing a bunch of the information used to set it up, and then this operate() function
[13:45:33 CST(-0600)] <colinclark> You're saying that operate() can't be used to re-fetch some resources?
[13:45:46 CST(-0600)] <colinclark> Why return this value at all? What's the intention there?
[13:46:46 CST(-0600)] <colinclark> anastasiac: In cases where we really need to have these sorts of things, I think the best choice is to not document their existence
[13:48:17 CST(-0600)] <heidi> mlam http://issues.fluidproject.org/browse/FLUID-3860
[13:48:18 CST(-0600)] <anastasiac> colinclark, that's what I was wondering. It would be good to have a convention for commenting these functions - not sure what to recommend... "non-public" ? "undocumented" "this isn't really public so please don't use it" ?
[13:48:42 CST(-0600)] <colinclark> anastasiac: Is this not our category of things we are calling Unsupported?
[13:49:10 CST(-0600)] <anastasiac> no, unsupported was for "not guaranteed to remain consistent from release to release but visible out of courtesy to developers" which seems different to me
[13:49:16 CST(-0600)] <mlam> heidi: thanks...testing it out
[13:49:51 CST(-0600)] <colinclark> anastasiac: How is it different?
[13:51:31 CST(-0600)] <anastasiac> well, my take on 'unsupported' was: "we don't mind if you use it, feel free - it might even be useful; just don't count on it always being called that, or even always being there"; whereas this 'operate' functions seems more "we don't expect you to use this - you shouldn't ever have to, and if you do we're not quite sure what would happen"
[13:51:37 CST(-0600)] <anastasiac> my take might be wrong, of course
[13:53:32 CST(-0600)] <colinclark> I'm not sure the definition is so clear that you could be wrong, anastasiac
[13:54:00 CST(-0600)] <Bosmon2> Well... fetchResources I'm not sure even used to return a value at all.... if it does return a value, this is again largely as a "courtesy"
[13:54:12 CST(-0600)] <Bosmon2> Since the principal function of the whole activity occurs in the callback
[13:54:17 CST(-0600)] <colinclark> So that certainly falls into the category of "unsupported"
[13:54:30 CST(-0600)] <Bosmon2> However it is possible that the "that" which is returned might in future be elaborated with further operations that are actually useful
[13:54:46 CST(-0600)] <colinclark> It struck me that it has the potential for that, Bosmon2
[13:54:50 CST(-0600)] <Bosmon2> For example, meeting the "disposable AJAX" requirements of things like autocompletes and typeaheads etc.
[13:55:18 CST(-0600)] <Bosmon2> This is one important use case for AJAX that we have not yet subsumed into any useful framework functionality
[13:55:28 CST(-0600)] <colinclark> So, anastasiac I think this argues for the return value of fluid.fetchResources() being unsupported
[13:55:40 CST(-0600)] <colinclark> and thus only sparsely documented, if at all
[13:55:57 CST(-0600)] <Bosmon2> I guess it's pretty interesting that this discussion is revealing that any part of any structure may independently be labelled as "unsupported"
[13:55:58 CST(-0600)] <colinclark> Have we come to a decision about the extent to which we will even have any documentation references to unsupported APIs?
[13:56:23 CST(-0600)] <colinclark> Bosmon2: Ideally we can avoid such cases
[13:56:24 CST(-0600)] <Bosmon2> Including members of options blocks, "last arguments", methods, and now we see return values
[13:56:39 CST(-0600)] <mlam> heidi: works really well. good stuff
[13:56:43 CST(-0600)] <mlam>
[13:56:44 CST(-0600)] <anastasiac> so it seems to me that we are coming around to two forms of 'unsupported' things: those which are really better left undocumented, and those that we do want documented. Is this impression correct?
[13:57:07 CST(-0600)] <colinclark> Are there unsupported things that we do want to document, anastasiac?
[13:57:09 CST(-0600)] <colinclark> What's an example?
[13:57:13 CST(-0600)] <heidi> mlam and so simple. sheesh
[13:57:13 CST(-0600)] <Bosmon2> Well... we might "choose" to document unsupported things
[13:57:28 CST(-0600)] <Bosmon2> But I'm not sure that that necessarily means that there is a condition in which we "want them documented"
[13:58:22 CST(-0600)] <mlam> heidi: one thing i did notice, but i'm not sure if this is an issue....the text size of the empty inline is the size of the browser's default text size. but when you enter edit mode, the inline edit has the 2em size
[13:58:27 CST(-0600)] <anastasiac> colinclark, I don't know of any particular examples off the top of my head. The whole topic started when a bunch of inline edit stuff "went public"; I could be wrong, but I seem to remember that in the ensuing discussions, you expressed that some of these should certainly be documented - but I might have misunderstood
[13:59:07 CST(-0600)] <heidi> mlam yeah the empty line is set to 16px
[13:59:21 CST(-0600)] <heidi> not sure if we can get the text size value and use that instead?
[13:59:24 CST(-0600)] <mlam> ahhh ok
[13:59:45 CST(-0600)] <colinclark> anastasiac: Are there parts of Inline Edit that determined would be public but unsupported?
[14:00:11 CST(-0600)] <Bosmon2> We may "accidentally" document some unsupported functions just in order to communicate amongst ourselves... but I can't see that this would be a matter of "public policy"
[14:00:32 CST(-0600)] <mlam> heidi: i'll ask justin_o when he gets back this afternoon
[14:00:46 CST(-0600)] <colinclark> Bosmon2: I imagine we're more likely to do that in code, rather than on our official documentation site?
[14:00:50 CST(-0600)] <anastasiac> colinclark, I never did get a direct indication of which of the functions would be considered unsupported; I'd have to check logs and notes
[14:01:10 CST(-0600)] <justin_o> mlam: what did you need to ask me.. i'm here now but will be leaving in about 30 min
[14:01:19 CST(-0600)] <justin_o> and won't be back till tomorrow in the office
[14:01:22 CST(-0600)] <colinclark> anastasiac: That makes sense. And check in with justin_o and mlam for the specifics if there are gaps
[14:01:22 CST(-0600)] <mlam> oh ok
[14:01:44 CST(-0600)] <anastasiac> it was discussed in the dev meeting Nov. 3, so maybe no written record
[14:02:28 CST(-0600)] <anastasiac> so, am I wrong about "unsupported but documented" and "unsupported and not documented"? does unsupported === undocumented?
[14:03:17 CST(-0600)] <mlam> justin_o: when we set the default view text to be "" in the demo, the size of the input is the browser's default text size in display mode. when we enter edit mode, the size of the edit field becomes the size set out in the CSS which happens to be a 2em. Is this something we need to concerned with?
[14:04:06 CST(-0600)] <justin_o> maybe... what does james say about it?
[14:04:21 CST(-0600)] <colinclark> anastasiac: I was going to defer to you for a final decision on that topic
[14:04:25 CST(-0600)] <colinclark> What is your advice?
[14:04:46 CST(-0600)] <justin_o> mlam: is james around to ask him what he thinks of the interaction?
[14:04:55 CST(-0600)] <colinclark> My first thought is that "unsupported" === "not officially documented in our wiki," at very least
[14:04:58 CST(-0600)] <mlam> yah, i'll ask him now
[14:07:15 CST(-0600)] <anastasiac> colinclark, it seems to me that it would simplify things if we considered 'unsupported' things to be un-documented; more specifically, we need to think about any function we put into the public namespace. If we expect our users might want to use it, then it should be supported, commented in the code and publicly documented; if we don't expect anyone would or should use it, it should be tagged as "unsupported"
[14:08:10 CST(-0600)] <colinclark> anastasiac: Ok, so to clarify
[14:08:21 CST(-0600)] <colinclark> We know that all unsupported stuff should be tagged as such in the source code
[14:08:45 CST(-0600)] <colinclark> We should suggest to justin_o that this actually become a stage in the "general tasks" of the post-freeze period of a release
[14:09:00 CST(-0600)] <colinclark> So, something that is marked in source code as unsupported...
[14:09:05 CST(-0600)] <colinclark> does it have any mention in the documentation?
[14:09:12 CST(-0600)] <colinclark> Let's say I have uploader.foo()
[14:09:18 CST(-0600)] <colinclark> and foo() is unsupported
[14:09:50 CST(-0600)]

[14:09:53 CST(-0600)] <colinclark> and then what?
[14:09:59 CST(-0600)] <justin_o> colinclark: that makes sense... to add it to the general section of the bug parade
[14:10:20 CST(-0600)] <colinclark> Second example would be that uploader.foo() returns a "bar" object, which is unsupported, but foo() itself is supported.
[14:10:35 CST(-0600)] <anastasiac> I would say foo has no documentation. If you think it should be documented (i.e. as the developer, you're thinking "users really should know what foo() is"), then you should be re-thinking why it's unsupported
[14:10:38 CST(-0600)] <justin_o> anastasiac: if you could file a jira for it after you've got all the details worked out... i'll add it on tomorrow
[14:11:13 CST(-0600)] <anastasiac> justin_o, will do
[14:11:16 CST(-0600)]

<colinclark> presumably in code I would do something like this: /** Foo is a great method that you will love @return bar this return value is unsupported */ that.foo()

Unknown macro: { return bar }

;

[14:11:23 CST(-0600)] <colinclark> then what?
[14:11:37 CST(-0600)] <mlam> justin_o: heidi: just spoke to james, and yes, we'll have to adjust the container size in display mode to match that of the edit field in edit mode
[14:11:38 CST(-0600)] <colinclark> anastasiac: Okay, I think that's reasonable for the first case
[14:12:00 CST(-0600)] <justin_o> mlam: okay...
[14:12:12 CST(-0600)] <justin_o> any idea how you'll do that?
[14:12:20 CST(-0600)] <mlam> not yet
[14:12:43 CST(-0600)] <mlam> i'm assuming this won't be a blocker for the release?
[14:12:59 CST(-0600)] <anastasiac> colinclark, I think it would hold for the second case as well: the fact that foo returns bar should not be mentioned in the docs. If you're thinking it should be documented, then you should re-think why it's unsupported
[14:13:21 CST(-0600)] <colinclark> justin_o: I'm curious to hear what you think
[14:15:24 CST(-0600)] <colinclark> So, anastasiac's documentation proposal for Unsupported APIs is that they make no appearance in our official documentation whatsoever. In the source code, we include a comment mentioning that the method/function/option/argument/return value is unsupported, and perhaps an explanation of why. But that in the docs, we just don't tell people about these things.
[14:15:30 CST(-0600)] <colinclark> I think this seems like a reasonable approach.
[14:15:46 CST(-0600)] <colinclark> fluid-everyone: ^
[14:16:35 CST(-0600)] <Bosmon2> I agree
[14:16:45 CST(-0600)] <anastasiac> this would apply to: functions in the public namespace; options; data members on a 'that' object; return values from functions - anything else?
[14:17:19 CST(-0600)] <colinclark> Yes
[14:17:53 CST(-0600)] <colinclark> Public free functions, methods and instance variables, options, and return values seems like it covers everything
[14:21:36 CST(-0600)] <heidi> mlam is it easy to get that value ?
[14:21:56 CST(-0600)] <colinclark> in absence of -1s, anastasiac, I'm thinking silence means yes
[14:22:10 CST(-0600)] <colinclark> Let's go for it
[14:22:15 CST(-0600)] <anastasiac> I'll file the JIRA
[14:22:28 CST(-0600)] <anastasiac> and send an email to the list summarizing the plans
[14:22:38 CST(-0600)] <colinclark> if justin_o turns out to have a different opinion, he can change the JIRA himself when he adds it to bug parade, in a Kingly sort of way
[14:22:42 CST(-0600)] <colinclark> anastasiac: Thanks so much
[14:22:52 CST(-0600)] <anastasiac> thanks for helping sort it out
[14:23:19 CST(-0600)] <justin_o> colinclark: seems reasonable
[14:25:00 CST(-0600)] <yura_> hi justin_o, I was wondering if it is possible to include one JIRA into a bug parade that already has a patch with test cases ?
[14:25:33 CST(-0600)] <justin_o> yura_: what's it about?
[14:26:33 CST(-0600)] <yura_> in particular i mean http://issues.fluidproject.org/browse/FLUID-2578 "expander.array" patch. Currently the renderer only handles trees with a single expander inside, this patch upgrades it to be able to handle an expander array with more than one expander.
[14:26:54 CST(-0600)] <yura_> It's kind of inspired by the way you can configure decorators, as an object or as an array of objects
[14:29:28 CST(-0600)] <mlam> heidi: i'm not sure yet
[14:29:41 CST(-0600)] <justin_o> yura_: how necessary is this for the 1.3 release?
[14:31:53 CST(-0600)] <justin_o> yura_: if it gets in can you help anastasiac write the docs for it?
[14:32:11 CST(-0600)] <anastasiac> yes, please
[14:32:37 CST(-0600)] <yura_> justin_o: well at the current state renderer's functionality for expanders is significantly incomplete since there are cases were it is simply impossible to express things with only one expander
[14:33:29 CST(-0600)] <anastasiac> justin_o, I've filed a JIRA for commenting on unsupported things: http://issues.fluidproject.org/browse/FLUID-3881
[14:35:07 CST(-0600)] <justin_o> anastasiac: thanks... do you have time to update the release process page with that as one of the jiras we have to do before release?
[14:35:18 CST(-0600)] <anastasiac> sure
[14:35:45 CST(-0600)] <justin_o> yura_: okay... so will you be able to assist anastasiac in writing the documentation
[14:35:53 CST(-0600)] <yura_> justin_o: certainly
[14:36:18 CST(-0600)] <justin_o> yura_: just to double check you said you had already written the test cases for it?
[14:36:28 CST(-0600)] <yura_> yes
[14:36:43 CST(-0600)] <justin_o> okay then
[14:36:43 CST(-0600)] <Bosmon2> I have already "pre-reviewed" the patch and found it sound
[14:36:46 CST(-0600)] <mlam> heidi: the symptoms of the empty inline edit sizing are only present in IE8 (or course). all other browsers are fine
[14:36:50 CST(-0600)] <jamon> h craop
[14:36:51 CST(-0600)] <justin_o> i'll add it to the parade
[14:36:52 CST(-0600)] <Bosmon2> So it can be committed and closed in one step
[14:37:07 CST(-0600)] <justin_o> Bosmon2: after i add it, do you mind doing the commit and close
[14:37:28 CST(-0600)] <heidi> mlam yeah. and what's possibly weird is that changing that padding-top value could creep into how ff looks... if it's much bigger
[14:38:13 CST(-0600)] <Bosmon2> Yes, I will take care of that, thanks
[14:38:21 CST(-0600)] <justin_o> Bosmon2: it's on...all yours
[14:38:48 CST(-0600)] <anastasiac> justin_o, just to double-check: this pag? http://wiki.fluidproject.org/display/fluid/Release+Process
[14:39:09 CST(-0600)] <justin_o> anastasiac: yep that's the page
[14:39:16 CST(-0600)] <anastasiac> k
[14:40:19 CST(-0600)] <colinclark> justin_o: I think this issue is too broad to be on the bug parade
[14:40:23 CST(-0600)] <colinclark> Sorry, I should have caught this sooner
[14:40:29 CST(-0600)] <colinclark> I know you need to go, so I can be your proxy king if you want
[14:40:40 CST(-0600)] <colinclark> I'm thinking yura should file a specific JIRA that describes the work he's done
[14:41:04 CST(-0600)] <colinclark> make it a subissue of FLUID-2578, and then we can add it to the bug parade
[14:41:10 CST(-0600)] <Bosmon2> Ah ok, that sounds better
[14:41:16 CST(-0600)] <colinclark> yura_: Are you cool with that?
[14:41:29 CST(-0600)] <yura_> colinclark: yes ill make a jira right now
[14:41:36 CST(-0600)] <colinclark> I should have noticed this, since I filed the original "umbrella" issue and got a notice when you attached your patch
[14:41:39 CST(-0600)] <colinclark> Thanks
[14:41:55 CST(-0600)] <colinclark> justin_o: If you're okay to delegate to me, I can swap the Bug Parade tags on these issues
[14:42:30 CST(-0600)] <justin_o> colinclark: thanks.. please do, you're correct.. this is much to general and probably more about a different issue
[14:42:56 CST(-0600)] <justin_o> colinclark: i have to run to my next doctors appointment now.. so i'll leave it up to you to adjust that if you don't mind
[14:43:12 CST(-0600)] <colinclark> justin_o: No problemo
[14:43:14 CST(-0600)] <colinclark> have a good afternoon
[14:43:22 CST(-0600)] <justin_o> thanks... see you tomorrow
[14:43:47 CST(-0600)] <yura_> justin_o: FLUID-3882
[14:44:01 CST(-0600)] <colinclark> yura_: Is that your new one?
[14:44:07 CST(-0600)] <yura_> colinclark: yes
[14:44:10 CST(-0600)] <colinclark> l
[14:44:11 CST(-0600)] <colinclark> k
[14:44:15 CST(-0600)] <colinclark> one of those letters
[14:45:04 CST(-0600)] <colinclark> yura_: Can you slap the patch on this one?
[14:45:09 CST(-0600)] <colinclark> It'll make more sense that way
[14:45:12 CST(-0600)] <colinclark> Sorry to add extra work
[14:45:15 CST(-0600)] <yura_> yes it's being attached slowly
[14:45:28 CST(-0600)] <yura_> ok it's there
[14:45:50 CST(-0600)] <heidi> hey harriswong i'm having trouble applying your patch for http://issues.fluidproject.org/browse/FLUID-3848 , do i need to apply a different patch first?
[14:46:56 CST(-0600)] <heidi> or both of them?
[14:48:09 CST(-0600)] <heidi> all files but Pager.js get patched
[14:48:51 CST(-0600)] <colinclark> yura_, Bosmon2: http://issues.fluidproject.org/browse/FLUID-3882
[14:48:53 CST(-0600)] <colinclark> You're good to go
[15:07:46 CST(-0600)] <anastasiac> jhung, do you want to resolve FLUID-3731 now that you've removed the last demo? then I'll give it a review and close it
[15:09:40 CST(-0600)] <jhung> anastasiac: Done.
[15:11:49 CST(-0600)] <harriswong> Bosmon2: Hi Antranig, are you working on http://issues.fluidproject.org/browse/FLUID-3707?
[15:15:20 CST(-0600)] <colinclark> mlam: Just got progressive enhancement working in Uploader
[15:15:31 CST(-0600)] <colinclark> on all call, so I don't want to commit it until I get off and can check it all over
[15:15:32 CST(-0600)] <colinclark> but it works!
[15:16:09 CST(-0600)] <mlam> wicked!
[15:18:09 CST(-0600)] <anastasiac> jhung, would you agree that the lib folder in the standalone-demos folder can now be deleted as part of 3731?
[15:18:40 CST(-0600)] <jhung> anastasiac: let me see
[15:20:19 CST(-0600)] <jhung> anastasiac: Have you checked the HTML and JS files to ensure nothing else is referencing it? I can check now if needed.
[15:20:39 CST(-0600)] <anastasiac> jhung, I did check, but I was hoping you could double-check
[15:21:11 CST(-0600)] <jhung> sure thing.
[15:21:14 CST(-0600)] <jhung> give me a sec
[15:22:17 CST(-0600)] <heidi> harriswong your patch works awesome for voiceover
[15:22:33 CST(-0600)] <heidi> on safari. will test IE8 w/ nvda when you figured out the test
[15:22:58 CST(-0600)] <Bosmon2> harriswong: I haven't specifically looked at 3707, no - do you have a patch for it?
[15:23:02 CST(-0600)] <heidi> but i think this adds a lot
[15:23:06 CST(-0600)] <Bosmon2> Is it as simple as just having 1 line that applies the correct role?
[15:23:16 CST(-0600)] <Bosmon2> Have we decided it should be universally applied, or just to some Reorderers?
[15:23:52 CST(-0600)] <Bosmon2> yura_ - the patch for FLUID-3882 is now committed and the issue closed - thanks for looking at this so quickly and putting together a good patch
[15:24:13 CST(-0600)] <yura_> Bosmon2: thanks for committing it so promptly
[15:24:28 CST(-0600)] <jhung> anastasiac: everything seems good. Should I go ahead and delete the lib directory now?
[15:24:41 CST(-0600)] <anastasiac> jhung, thanks - that'd be great
[15:24:57 CST(-0600)] <harriswong> Bosmon2: yea, i think it's just one line fix similar to the Pager.js. I tried applying the same technique to Reorderer.js and it seems to work. Not sure if this is the best approach so I wanted to check with you before posting the patch on the JIRA.
[15:25:06 CST(-0600)] <harriswong> heidi: thanks!
[15:25:23 CST(-0600)] <heidi> harriswong yeah doesn't work with nvda yet
[15:25:51 CST(-0600)] <harriswong> heidi: only for IE8 right?
[15:26:08 CST(-0600)] <heidi> right
[15:26:41 CST(-0600)] <harriswong> heidi: thanks. looking into it~ I am not sure why the attribute is not switching on IE8. Debugging.
[15:27:04 CST(-0600)] <jessm> jhung: where's all the grid stuff? is there a url?
[15:29:44 CST(-0600)] <Bosmon2> harriswong - thanks for the patch, that is great
[15:30:11 CST(-0600)] <heidi> harriswong ff on win w/ nvda is a little different in that after you use the sort link, it rereads the page from the top
[15:30:16 CST(-0600)] <Bosmon2> I just closed FLUID-3771... I never dreamed it could be got through as early as this
[15:30:40 CST(-0600)] <jhung> jessm: it exists as a patch for Jira http://issues.fluidproject.org/browse/FLUID-3870 at the moment.
[15:30:48 CST(-0600)] <jhung> Waiting review.
[15:32:17 CST(-0600)] <jessm> anastasiac: just looking through Bug Parade email # 63
[15:32:39 CST(-0600)] <jessm> there are two documentation blockers that aren't in Review – do you know where they stand?
[15:32:47 CST(-0600)] * anastasiac checks
[15:33:41 CST(-0600)] <jessm> is everyone taking a look at that email?
[15:33:45 CST(-0600)] <jessm> one more day to freeze
[15:33:56 CST(-0600)] <jessm> heidi: how are you doing? you on inline edit?
[15:34:11 CST(-0600)] <anastasiac> jessm, thanks for catching that. FLUID_3773 should probably be in Review - it's resolved and I've passed it on to Bosmon2 for review - justin_o, is that right?
[15:34:11 CST(-0600)] <jessm> mlam: i'm not even going to bother you – there are two uploader blockers
[15:34:19 CST(-0600)] <harriswong> heidi: yep, i think it re-read the summary, then the column info
[15:34:35 CST(-0600)] <anastasiac> the other one can't really be finished till after code freeze, since the code is still changing and the docs need to reflect that
[15:34:35 CST(-0600)] <heidi> jessm no thankfully past inline edit. am testing harris's pager patch
[15:34:45 CST(-0600)] <jessm> heidi: ah
[15:34:51 CST(-0600)] <heidi> harriswong ah, weird. with voice over it just re-reads the sort link, which is awesome
[15:35:01 CST(-0600)] <mlam> jessm: the blockers will be unblocked
[15:35:05 CST(-0600)] <anastasiac> ah, justin_o is not here - I'll email him, jessm
[15:35:23 CST(-0600)] <jessm> heidi: can you check justin's email to list to make sure all the inlinedit jira you've patched are marked as review? and if not then send justin an email?
[15:35:28 CST(-0600)] <jessm> anastasiac: thanks!
[15:35:29 CST(-0600)] <jhung> anastasiac: lib is gone. Closing Fluid-3731 now
[15:35:38 CST(-0600)] <jessm> mlam: i like your resolve!
[15:35:45 CST(-0600)] <anastasiac> jhung, you resolve, let me close
[15:35:52 CST(-0600)] <jhung> k
[15:36:09 CST(-0600)] <jhung> anastasiac: you can check now.
[15:36:23 CST(-0600)] <heidi> jessm they're in the review list
[15:36:26 CST(-0600)] <anastasiac> yep, it's in my juggling stack
[15:38:16 CST(-0600)] <heidi> mlam jhung any guesses for how to get past http://issues.fluidproject.org/browse/FLUID-3811 ?
[15:38:40 CST(-0600)] <heidi> can we check for cached data somehow?
[15:38:46 CST(-0600)] <harriswong> heidi: maybe that should be noted, i am not sure which is the preferred way. I think the pager behaved this way back then as well; upon sort, it reads out the Table info, then column and then Member Columns, and then Member Links.
[15:39:08 CST(-0600)] <heidi> harriswong. ill note it in the jira!
[15:39:24 CST(-0600)] <heidi> any luck fixing IE8?
[15:39:41 CST(-0600)] <jessm> heidi: do you know anything about these three unpatched jiras for inline edit?
[15:40:19 CST(-0600)] <harriswong> heidi: okay! thanks. IE8 oh ie8... not yet, i am not sure why the 2nd "click()" action doesn't change the attribute to descending on IE8.
[15:40:33 CST(-0600)] <jhung> heidi: I'm looking into that now. Apparently there are META properties we can set that can prevent caching?
[15:41:38 CST(-0600)] <heidi> jessm sounds like jhung is working on 3811 and the other two are NVDA issues that should be looked into on a real windows machine. tricky to test with certainty on my VM
[15:41:54 CST(-0600)] <heidi> but ill be in the office tomorrow and can check a win machine then
[15:42:09 CST(-0600)] <jessm> heidi: cool
[15:42:19 CST(-0600)] <jhung> heidi: I'll be in tomw too, so we can bang on this together.
[15:42:26 CST(-0600)] <heidi> cool
[15:42:47 CST(-0600)] <heidi> harriswong any code i can help look at ?
[15:42:59 CST(-0600)] <jhung> heidi: btw, caching dealio here. Will need to experiment a bit to see which one solved our problem with FLUID-3811. http://support.microsoft.com/kb/234067
[15:44:49 CST(-0600)] <harriswong> heidi: mm i just checked the DOM tree on IE8 after I clicked on each column, it seems to work. It's just the testcases that are not grabbing the correct aria-sort.
[15:45:35 CST(-0600)] <harriswong> heidi: you may want to look at tests/component-tests/pager/js/PagerTests.js, line 392~393. We can break point on these and see if it's returning the correct values
[15:45:41 CST(-0600)] <jessm> heidi: jhung: thanks y'all
[15:46:18 CST(-0600)] <heidi> harriswong nvda w/ ie8 isn't reading the sort info
[15:46:26 CST(-0600)] <heidi> so not just the tests...
[15:47:42 CST(-0600)] <harriswong> heidi: you are right.. mm. thinks
[15:48:45 CST(-0600)] <jhung> see you all tomorrow.
[15:49:29 CST(-0600)] <harriswong> heidi: did you set the mode to application on IE8?
[15:49:48 CST(-0600)] <harriswong> heidi: when you were testing on IE8 with NVDA, did you do caps+space?
[15:50:58 CST(-0600)] <heidi> harriswong it's possible that's my problem. i can't seem to switch modes effectively on my mac/VM
[15:51:06 CST(-0600)] <harriswong> heidi: i think i know why. I have talked to Justin about this problem, we didn't have a solution.
[15:51:13 CST(-0600)] <heidi> but tests stll failing?
[15:51:15 CST(-0600)] <heidi> ok
[15:52:31 CST(-0600)] <harriswong> heidi: when i use keyboard to sort with 'enter' key consecutively, the focus will get reset. Maybe this affect the testcase as well.
[15:53:18 CST(-0600)] <heidi> hmm. what is the test doing exactly? how does refocus change things?
[15:54:52 CST(-0600)] <harriswong> heidi: the test runs through all sortable column headers, and runs click() on them. After each click(), the tester runs through all column headers to test if aria-sort is set properly, and also checks if the anchor title have been set. Columns that didn't get sort also get checked because their attribute shouldn't have changed.
[15:56:01 CST(-0600)] <heidi> harriswong so the error is basically that the anchor title isn't changing on clicked headers
[15:56:09 CST(-0600)] <heidi> but you said it is in the DOM?
[15:56:53 CST(-0600)] <harriswong> heidi: After that, the tester rerun itself again for a second click() for a check on descending order, and randomly (50%) runs a third click()
[15:57:31 CST(-0600)] <heidi> i wonder if we should separate the tests out, so less is going on in each one
[15:57:44 CST(-0600)] <heidi> is that possible if they run in sequence anyway?
[15:57:59 CST(-0600)] <harriswong> heidi: looking at the errors, i think the click() doesn't go through at all because both "aria-sort" and "anchor title" haven't been set. But yes, i rebuilt the DOM tree after i clicked, and IE8 said that the attributes have been set.
[15:58:47 CST(-0600)] <harriswong> heidi: Well, the test was setup to run a click on column A, then click on column A again to see if it swaps from ascending to descending. Then repeat this for all columns.
[15:59:15 CST(-0600)] <heidi> hard to narrow down where the issue lies
[15:59:43 CST(-0600)] <harriswong> heidi: I can try running just 3 consecutive clicks on 1 column and see what happens
[15:59:58 CST(-0600)] <heidi> k
[16:01:46 CST(-0600)] <harriswong> heidi: ran on column Member, click(), ok. click(), failed on the clicked column.
[16:02:15 CST(-0600)] <heidi> so it renames it fine the first time, but fails when doing it the second?
[16:02:21 CST(-0600)] <harriswong> and IE8 isn't making my life easier to trace this
[16:02:28 CST(-0600)] <heidi> i hear ya
[16:02:29 CST(-0600)] <harriswong> yes
[16:02:37 CST(-0600)] <heidi> that's so strange
[16:02:46 CST(-0600)] <heidi> cos it's not much different than the first click - right?
[16:02:48 CST(-0600)] <harriswong> then it passes on the third click, well, cause it dind't get changed at all
[16:03:04 CST(-0600)] <harriswong> no. it's the same jQuery click() function
[16:03:22 CST(-0600)] <heidi> does it check for the current val or anything? what line of code is it again?
[16:03:51 CST(-0600)] <harriswong> heidi: PagerTest.js; line 388~404 = test output/comparisons
[16:04:08 CST(-0600)] <harriswong> heidi: PagerTest.js; line 406~421 = mimic clicks
[16:04:50 CST(-0600)] <harriswong> heidi: i changed line 407 to loop only once so it runs on the 1st column only. (by changing it to currentHeaders.length - 2)
[16:05:02 CST(-0600)] <heidi> k
[16:05:19 CST(-0600)] <harriswong> heidi: i also commented out the third click, which is 417~420
[16:06:05 CST(-0600)] <heidi> harriswong where does aria_index get a value
[16:06:06 CST(-0600)] <heidi> for if (aria_index === j) {
[16:06:41 CST(-0600)] <harriswong> heidi: parameter of the function line 38, which was fed from line 411, 414
[16:07:00 CST(-0600)] <harriswong> heidi: aria_index is the column index of which aria should be set in
[16:07:23 CST(-0600)] <harriswong> heidi: in the modified test now, it should always be 0, which is the Member column
[16:07:50 CST(-0600)] <heidi> maybe see if it is?
[16:07:58 CST(-0600)] <harriswong> ok
[16:08:28 CST(-0600)] <heidi> howcome 396 and 397 are the same
[16:08:48 CST(-0600)] <harriswong> :O
[16:09:06 CST(-0600)] <heidi> hehe i don't think it's causing any trouble just curios
[16:09:39 CST(-0600)] <harriswong> i believe line 397 is repeated....
[16:10:17 CST(-0600)] <heidi> so is aria_index correct?
[16:12:50 CST(-0600)] <harriswong> heidi: yes it is.. but on IE8, if you change that testcase to asyncTest
[16:13:28 CST(-0600)] <harriswong> heidi: then reload page, scroll all the way down, you will see a table with headers: category, breed, origin
[16:13:43 CST(-0600)] <harriswong> heidi: try clicking on "Category" twice in a row, you will notice the 2nd click won't fire
[16:14:15 CST(-0600)] <harriswong> heidi: same behavior on demo
[16:14:39 CST(-0600)] <harriswong> heidi: but if you give it a 1s pause, the second click will be fine.
[16:14:51 CST(-0600)] <heidi> oh bizarre
[16:18:24 CST(-0600)] <harriswong> heidi: i am not sure if that's the reason..
[16:18:44 CST(-0600)] <heidi> harriswong - i'm about to sign off for the day but ill be in the office tomorrow. can help then?
[16:19:09 CST(-0600)] <harriswong> heidi: sure, thanks a lot heidi! i am going inform the king about this finding...
[16:19:15 CST(-0600)] <harriswong> going to*
[16:19:20 CST(-0600)] <heidi> cool. see you tomorrow!
[16:19:26 CST(-0600)] <heidi> btw, do i need boots in toronto?
[16:19:43 CST(-0600)] <harriswong> Mmm... i don't thikn so yet
[16:19:50 CST(-0600)] <heidi> k ... lots of snow here
[16:19:55 CST(-0600)] <heidi> see ya!
[16:19:59 CST(-0600)] <harriswong> o we had some but i tihnk it' sall gone now
[16:20:03 CST(-0600)] <harriswong> see you tmw!