fluid-work IRC Logs-2008-07-25

[01:43:27 EDT(-0400)] * phiggins (n=dante@72.11.116.15) has joined #fluid-work
[01:57:49 EDT(-0400)] * phiggins (n=dante@72.11.116.15) has joined #fluid-work
[08:03:55 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has joined #fluid-work
[08:48:40 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:35:52 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[09:55:49 EDT(-0400)] * jhung (n=Administ@H33.C205.cci.switchworks.net) has joined #fluid-work
[09:57:29 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:00:59 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has left #fluid-work
[10:02:51 EDT(-0400)] <jacobfarber> Anyone had a look at this before? http://plugins.jquery.com/project/Accessible
[10:05:49 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:06:47 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:34:22 EDT(-0400)] <Justin_o> I'm trying to determine the source of a strange bug
[10:34:37 EDT(-0400)] <Justin_o> If anyone has FF3 could you please let me know if you can tab to the buttons on the uploader
[10:34:51 EDT(-0400)] <Justin_o> http://build.fluidproject.org/fluid/sample-code/uploader/inline/index.html
[10:35:24 EDT(-0400)] <Justin_o> On some machines you can, on others you can't.. I'm still trying to determine the difference
[10:37:01 EDT(-0400)] <jhung> testing now in FF3
[10:37:15 EDT(-0400)] <Justin_o> thanks
[10:38:01 EDT(-0400)] <jhung> In FF3, I can tab to all buttons when list is empty. Can't activate the Browse Files button with Enter or Space.
[10:38:13 EDT(-0400)] <jhung> wait...
[10:38:16 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:38:26 EDT(-0400)] <jhung> I think my dialog box is off the screen!
[10:39:28 EDT(-0400)] <jhung> scratch that. Browse files button doesn't seem to work using mouse or keyboard?
[10:39:46 EDT(-0400)] <jhung> I'm using the version on Build server.
[10:39:53 EDT(-0400)] <Justin_o> on windows or mac
[10:40:00 EDT(-0400)] <jhung> Win
[10:40:21 EDT(-0400)] <Justin_o> thanks for testing
[10:40:25 EDT(-0400)] <jhung> k
[10:40:33 EDT(-0400)] <colinclark> Congratulations to Bosmon on the third birthday of RSF!
[10:40:39 EDT(-0400)] <Justin_o> oh.. sorry.. just caught something..the browse file button doesn't work with mouse??
[10:40:48 EDT(-0400)] <jhung> yeah.
[10:41:10 EDT(-0400)] <jhung> Also, using the pop-up version of uploader, clicking "Add Files" doesn't do anything either.
[10:41:23 EDT(-0400)] <jhung> going to check with IE7 now
[10:42:15 EDT(-0400)] <Justin_o> oh okay.. i'll have to look at the FF3 browse button not working.. that is working on mine..
[10:42:35 EDT(-0400)] <anastasiac> Justin_o, when you have a sec, could you double-check http://issues.fluidproject.org/browse/FLUID-950? I'm not able to reproduce it. If it's fixed, it should be closed
[10:43:14 EDT(-0400)] <anastasiac> I don't think it was actively fixed, just as a by-product of other changes
[10:44:04 EDT(-0400)] <Justin_o> okay.. i'm not sure if i should close it yet.. until the other bug is fixed.. what do you think
[10:44:14 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[10:44:14 EDT(-0400)] <Justin_o> http://issues.fluidproject.org/browse/FLUID-973
[10:45:09 EDT(-0400)] <anastasiac> yes, I saw that. 973 is related to the tooltip work that Antranig did. Take that out, and it seems to work.
[10:45:30 EDT(-0400)] <Justin_o> okay
[10:45:55 EDT(-0400)] <jhung> Justin_o, in IE7 can tab to all buttons. Can't keyboard activate the Browse files button, but mouse is fine. In FF3, Browse Files doesn't seem to do anything using Inline Uploader. FF3, Add files doesn't seem to do anything using Pop-up Uploader. Could be a problem with my FF3.
[10:46:39 EDT(-0400)] <Justin_o> what version of windows are you using
[10:46:46 EDT(-0400)] <jhung> WinXP
[10:47:22 EDT(-0400)] <Justin_o> jhung: i'll try it out on the machine you use here, cause it is working okay on my vmware
[10:47:32 EDT(-0400)] <jhung> ok
[10:58:07 EDT(-0400)] <Justin_o> jhung_afk: it seems to be working here.. is your Firefox 3.0.1
[10:58:21 EDT(-0400)] <jhung> Figures.
[10:58:30 EDT(-0400)] <jhung> I'll take a look at my install.
[10:59:22 EDT(-0400)] <Justin_o> okay.. thanks.. please let me know if it is something we need to post a jira for
[11:03:44 EDT(-0400)] <jhung> can anyone access the wiki? wiki.fluidproject.org/
[11:05:45 EDT(-0400)] <Justin_o> our internet dropped for a few minutes
[11:05:49 EDT(-0400)] <Justin_o> it seems to be working now
[11:06:13 EDT(-0400)] <jhung> Ah. Ok.
[11:22:23 EDT(-0400)] <anastasiac> so Bosmon and I were just discussing FLUID-973
[11:22:29 EDT(-0400)] <Bosmon> Yes
[11:22:38 EDT(-0400)] <anastasiac> it was being caused by the tooltip plugin code being 'used' before it was actually loaded
[11:23:04 EDT(-0400)] <anastasiac> this can be addressed by either ensuring that the js files are imported in the 'right' order,
[11:23:17 EDT(-0400)] <anastasiac> or by wrapping the initialization code in the document ready() function
[11:23:31 EDT(-0400)] <Bosmon> anastasiac: Where was the site of the "usage" which was too early?
[11:24:04 EDT(-0400)] <anastasiac> in the header of the HTML file, where the js files are referenced in <script> tags...
[11:24:13 EDT(-0400)] <anastasiac> the tooltip file was listed after the inline edit file
[11:24:16 EDT(-0400)] <anastasiac> which used it
[11:24:51 EDT(-0400)] <Bosmon> Well...
[11:25:05 EDT(-0400)] <Bosmon> Surely it shouldn't actually become "used" until the point at which there is a function call into inline-edit?
[11:25:12 EDT(-0400)] <anastasiac> ugh - I take it back
[11:25:26 EDT(-0400)] <anastasiac> changing the order of the script tags doesn't address the bug
[11:25:34 EDT(-0400)] <Bosmon> OK
[11:25:39 EDT(-0400)] <Bosmon> That is both good and bad
[11:25:40 EDT(-0400)] <Bosmon>
[11:25:46 EDT(-0400)] <anastasiac> so I don't actually know what was causing the error
[11:26:04 EDT(-0400)] <anastasiac> it was discussed on the plug-in page, and recognized as a known issue
[11:26:06 EDT(-0400)] <Bosmon> Did you find anything which addressed the bug?
[11:26:14 EDT(-0400)] <Bosmon> Did putting it in document.ready actually fix it?
[11:26:19 EDT(-0400)] <anastasiac> yes, it does
[11:26:23 EDT(-0400)] <anastasiac> that was the recommended solution
[11:26:23 EDT(-0400)] <Bosmon> Well
[11:26:25 EDT(-0400)] <Bosmon> That is very poor
[11:26:31 EDT(-0400)] <Bosmon> But, at least, should be something we do in the framework
[11:26:37 EDT(-0400)] <Bosmon> Rather than forcing every user to do it themselves
[11:26:55 EDT(-0400)] <anastasiac> that might be a good idea
[11:26:57 EDT(-0400)] <Bosmon> Since "document.ready is a brood concocted by Belial"
[11:28:01 EDT(-0400)] * anastasiac looks up bach cantatas
[11:28:33 EDT(-0400)] * anastasiac doesn't find any mention of document.ready
[11:39:40 EDT(-0400)] <Bosmon>
[11:39:49 EDT(-0400)] <jhung> Standup in 5 min
[11:40:05 EDT(-0400)] <Bosmon> "Anyone who puts on hypocricy's mask/ Is wearing the devil's livery"
[11:42:31 EDT(-0400)] <anastasiac> oh, ok, well that's clearly referring to document.ready...
[11:50:30 EDT(-0400)] * ecochran (n=ecochran@adsl-70-137-135-24.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[12:11:23 EDT(-0400)] <ecochran> Should we consider trying to fix FLUID-96 > "Browse Files" and "Add More" buttons aren't activated by the keyboard in the inline version of uploader
[12:11:27 EDT(-0400)] <ecochran> for this release?
[12:11:35 EDT(-0400)] <ecochran> this is another oddity
[12:12:44 EDT(-0400)] <Justin_o> here's the link to the bug http://issues.fluidproject.org/browse/FLUID-961
[12:16:44 EDT(-0400)] <ecochran> never mind, I just fixed it, a tag with a missing href attribute which for some reason means that onclick doesn't fire for enter key
[12:17:16 EDT(-0400)] <Justin_o> so 961 is fixed?
[12:18:08 EDT(-0400)] <ecochran> Justin_o: as soon as I check it in
[12:18:17 EDT(-0400)] <Justin_o> thanks
[12:19:53 EDT(-0400)] <ecochran> Justin_o: Checked in
[12:21:06 EDT(-0400)] <Justin_o> thanks.. that's one off the list...
[12:26:55 EDT(-0400)] <ecochran> ok, I should know the answer to this but I don't, how does getSelectableContext know which items are selectable?
[12:27:16 EDT(-0400)] <ecochran> I guess this is a ? for colinclark and Bosmon
[12:27:43 EDT(-0400)] <colinclark> ecochran: I'll just catch up on the conversation here. One sec.
[12:28:00 EDT(-0400)] <ecochran> just the last two lines
[12:28:30 EDT(-0400)] <colinclark> ecochran: You've fixed 961. Awesome!
[12:28:36 EDT(-0400)] <ecochran> np
[12:28:50 EDT(-0400)] <colinclark> That one was definitely a priority. A show stopper for people even being able to use the component without a mouse.
[12:28:52 EDT(-0400)] <colinclark> This is good.
[12:28:55 EDT(-0400)] <ecochran> I just compared the markup between that one that worked and the one that didn't
[12:29:11 EDT(-0400)] <colinclark> ecochran: As for the question about the selection context...
[12:29:17 EDT(-0400)] <ecochran> tnks
[12:29:23 EDT(-0400)] <ecochran> thks
[12:29:26 EDT(-0400)] <colinclark> Here's an overview of what happens...
[12:29:43 EDT(-0400)] <colinclark> 1. You now call selectable() on the container of the selectable items.
[12:29:53 EDT(-0400)] <ecochran> yes
[12:30:02 EDT(-0400)] <colinclark> 2. There is a default selector, which can be overridden, defining how the selectable items are found.
[12:30:25 EDT(-0400)] <colinclark> 3. The plugin goes and grabs these, creates a selection context, and stores it in the DOM on the container element.
[12:31:01 EDT(-0400)] <colinclark> 4. As a result, the container essentially remembers two primary things: a) which item is currently selected, and b) the whole list of selectables.
[12:31:19 EDT(-0400)] <colinclark> ecochran: Does that answer your question?
[12:31:42 EDT(-0400)] <Bosmon> I can't actually demonstrate FLUID-1004 here
[12:31:46 EDT(-0400)] <Bosmon> I will try installing FF3...
[12:31:51 EDT(-0400)] <ecochran> colinclark: no, where does the list of selectables come from in the case of the Uploader, I find no overrides..
[12:32:18 EDT(-0400)] <ecochran> maybe I'm just missing it in the code
[12:32:32 EDT(-0400)] <colinclark> Line 945...
[12:32:39 EDT(-0400)]

[12:34:13 EDT(-0400)] <colinclark> ecochran: ^
[12:34:34 EDT(-0400)] <Justin_o> Bosmon: I'm pretty sure that Fluid-1004 and Fluid-1016 are related
[12:34:49 EDT(-0400)] <ecochran> is it a problem that the class of that element changes ... frequently?
[12:35:46 EDT(-0400)] <colinclark> ecochran: That's possible. The list of selectables is refreshed at various points.
[12:35:52 EDT(-0400)] <colinclark> So worth looking there, too.
[12:36:42 EDT(-0400)] <colinclark> ecochran: So when .refresh() is called, the whole list of selectables are re-fetched from the DOM.
[12:36:53 EDT(-0400)] <Bosmon> Ok, cool
[12:36:57 EDT(-0400)] <Bosmon> I can demonstrate it on FF3 on Windows
[12:37:03 EDT(-0400)] <colinclark> ecochran: That is done when items are added or removed from the queue.
[12:37:24 EDT(-0400)] <colinclark> One lines 162 and 189.
[12:37:36 EDT(-0400)] <ecochran> colinclark: the key question that I'm trying to figure out is how the queue knows that it is selectable
[12:37:43 EDT(-0400)] <ecochran> I'm definitely seeing the code now
[12:37:47 EDT(-0400)] <ecochran> just not that
[12:38:20 EDT(-0400)] <ecochran> also I think that when .ready is being referenced the first time, the element actually has a class of "start" not "ready"
[12:38:45 EDT(-0400)] <ecochran> I will change that selector to use the more generic fragmentSelector for that element and see if that fixes anything
[12:39:46 EDT(-0400)] <Bosmon> ecochran: Didn't you tell me that only the rows with the class of "ready" should be considered keyboard-selectable?
[12:40:11 EDT(-0400)] <ecochran> Bosmon: your right!
[12:40:38 EDT(-0400)] <colinclark> ecochran: It should definitely be using the "interesting thing" selector, rather than one that conveys a particular state like .ready.
[12:40:39 EDT(-0400)] <ecochran> Bosmon: I'm thinking about something else because I'm trying to figure out how the queue itself gets selected
[12:40:39 EDT(-0400)] <Bosmon> If you broaden the selector, I assume you will hit those wierd things like "completed files" or error messages etc.
[12:41:15 EDT(-0400)] <colinclark> Bosmon: Don't you think completed files should be still selectable?
[12:41:23 EDT(-0400)] <colinclark> Though not deletable.
[12:41:38 EDT(-0400)] <colinclark> Remember that keyboard navigation is also used to "explore" the interface.
[12:41:40 EDT(-0400)] <Bosmon> Well, don't we actually only support selectability in order to support deletability?
[12:41:42 EDT(-0400)] <Bosmon> Ah
[12:41:42 EDT(-0400)] <ecochran> colinclark & Bosmon: I can still use a configurable selector
[12:41:50 EDT(-0400)] <Bosmon> I didn't realise this...
[12:41:58 EDT(-0400)] <colinclark> So a user may will want to look through the list and hear the list of files and their status.
[12:42:03 EDT(-0400)] <colinclark> (completed, ready, etc.)
[12:42:03 EDT(-0400)] <ecochran> yes
[12:42:07 EDT(-0400)] <ecochran> I'll fix that
[12:42:39 EDT(-0400)] <colinclark> Bosmon: Keyboard navigation is a funny thing. Because it's overloaded with two different "modes."
[12:42:48 EDT(-0400)] <colinclark> And only certain sorts of users will engage in both modes.
[12:43:14 EDT(-0400)] <colinclark> A fully sighted user who has limited mobility and is using an onscreen keyboard to navigate will likely never select something just to figure out what it is.
[12:43:25 EDT(-0400)] <Bosmon> I am still boggling a bit how to support this "removal" functionality....
[12:44:07 EDT(-0400)] <colinclark> But a screenreader user, or even for someone using a screen magnifier where they only see a small portion of the screen at once, will actually use selectability as their primary means to inspect what options and states are available to them.
[12:44:15 EDT(-0400)] <colinclark> As for the ability to delete rows...
[12:44:41 EDT(-0400)] <colinclark> We'll have to ensure that only things that are completed get the activate-ability removed.
[12:44:57 EDT(-0400)] <colinclark> And to be honest, I don't know that there is an API to make something "unactivatable"
[12:44:59 EDT(-0400)] <colinclark> eek.
[12:45:57 EDT(-0400)] <colinclark> The plugin is aware of various activation handlers, so it should be able to remove them on demand.
[12:46:04 EDT(-0400)] <colinclark> Bosmon: Is this something I should implement?
[12:52:36 EDT(-0400)] <Bosmon> Yes possibly
[12:53:00 EDT(-0400)] <Bosmon> I am trying to "guess" whether the removal of the focused element counts as an "instant thoughtcrime punishable by death"
[12:53:33 EDT(-0400)] <Bosmon> Or whether the DOM will forgive you should you manage to restore focus to something in existence before the thread is released
[12:54:21 EDT(-0400)] <Bosmon> I wonder whether it's even possible to detect easily whether a given DOM node is still attached to the document?
[12:55:16 EDT(-0400)] <colinclark> lol
[12:55:24 EDT(-0400)] <colinclark> Bosmon: I have no idea.
[12:55:39 EDT(-0400)] <colinclark> Bosmon: As for DOM forgiveness, I'm going to guess that it will.
[12:55:45 EDT(-0400)] <colinclark> The only way to know is to try it and test.
[12:55:49 EDT(-0400)] <colinclark> Justin_o can help.
[12:56:24 EDT(-0400)] <ecochran> Bosmon: I can make the code smart in order to only delete .ready rows
[12:56:52 EDT(-0400)] <colinclark> ecochran: So you've worked around the code by checking for .ready inside the activation handler?
[12:57:01 EDT(-0400)] <colinclark> worked around the issue
[12:57:13 EDT(-0400)] <ecochran> colinclark: haven't done it yet
[12:57:17 EDT(-0400)] <ecochran> but that's where I am now
[12:57:42 EDT(-0400)] <colinclark> ecochran: It's a reasonable temporary fix, yes.
[12:58:03 EDT(-0400)] <ecochran> colinclark: why temporary?
[12:59:31 EDT(-0400)] <colinclark> ecochran: Well, it probably makes sense to actually unbind the event handlers when we're done with them.
[12:59:49 EDT(-0400)] <colinclark> Since a completed file can't ever become uncompleted again.
[12:59:57 EDT(-0400)] <ecochran> colinclark: ah, that's better and just as easy to do
[13:00:33 EDT(-0400)] <colinclark> ecochran: Unfortunately our plugin doesn't have the API to allow us to do that.
[13:00:37 EDT(-0400)] <colinclark> So your workaround rocks.
[13:01:41 EDT(-0400)] <ecochran> hmm, I was thinking that I would unbind from the button but that won't work, grumph
[13:02:15 EDT(-0400)] <ecochran> could the row activate code be told to click the button?
[13:02:53 EDT(-0400)] <ecochran> ah, I'm already unbinding the button... good boy~
[13:03:18 EDT(-0400)] <Bosmon> ecochran: Any idea on a method for telling whether a DOM node is "dead"?
[13:03:46 EDT(-0400)] <ecochran> Bosmon: ie. not in the DOM?
[13:04:13 EDT(-0400)] <ecochran> jQuery(elm).length === 0 would work
[13:04:32 EDT(-0400)] <Bosmon> !!!
[13:04:57 EDT(-0400)] <Bosmon> JQuery will refuse to wrap a "dead" node?
[13:08:19 EDT(-0400)] <colinclark> Bosmon: I'm not sure about that...
[13:08:44 EDT(-0400)] <Bosmon> colinclark:
[13:08:50 EDT(-0400)] <Bosmon> I am puzzled by something in the code now
[13:08:57 EDT(-0400)] <Bosmon> How does "focusNextItem" really work?
[13:09:02 EDT(-0400)] <Bosmon> It never seems to update "activeItem"
[13:09:06 EDT(-0400)] <ecochran> colinclark: ok, I rewrote the activateHandler to send a click to the Remove button
[13:09:15 EDT(-0400)] <colinclark> ecochran: Why?
[13:09:39 EDT(-0400)] <colinclark> Bosmon: I'll have to check. But I would guess that perhaps the focus handler sets the activeItem.
[13:09:41 EDT(-0400)] <ecochran> colinclark: so that the remove btn and the row will always be in sync
[13:09:59 EDT(-0400)] <ecochran> when the btn gets unbound
[13:10:28 EDT(-0400)] <ecochran> then the row will no longer delete by keyboard
[13:10:44 EDT(-0400)] <ecochran> the button gets unbound when it's state changes
[13:10:57 EDT(-0400)] <ecochran> the rows state that is
[13:11:58 EDT(-0400)] <Bosmon> colinclark: Yes, this looks like the case
[13:12:16 EDT(-0400)] * colinclark is slightly behind on responding... just walking through the bug parade with Justin.
[13:12:19 EDT(-0400)] <Bosmon> Isn't this a bit "tricksy"? Our state updates happen in two bits...
[13:12:19 EDT(-0400)] <colinclark> brb
[13:13:16 EDT(-0400)] <colinclark> Bosmon: I believe it's there by requirement. But I will have to try to remember.
[13:13:35 EDT(-0400)] <ecochran> Bosmon: no because here we're only concerned with the state of the row
[13:14:04 EDT(-0400)] <ecochran> OK, I have a fix for the queue only selecting if there are scrollbars
[13:14:16 EDT(-0400)] <Bosmon> Wow!
[13:14:19 EDT(-0400)] <ecochran> actually I think that it will fix a bunch of these bugs
[13:14:20 EDT(-0400)] <Bosmon> ecochran: impressive
[13:14:23 EDT(-0400)] <ecochran> here is the fix
[13:14:34 EDT(-0400)] <ecochran> set the queue tabindex=0
[13:14:47 EDT(-0400)] <ecochran> set the surrounding divs to tabindex=-1
[13:15:07 EDT(-0400)] <ecochran> I'm going to check it in, if everyone wants to pick it up
[13:15:19 EDT(-0400)] <ecochran> one moment while I migrate it to the pop-up as well
[13:17:21 EDT(-0400)] <ecochran> Bosmon, colinclark, Justin_o : 1016 is checked in!
[13:17:40 EDT(-0400)] <colinclark> ecochran: I'd suggest making the queue tabbable() in code as well.
[13:17:58 EDT(-0400)] <Bosmon> Mad props...
[13:17:59 EDT(-0400)] <ecochran> OK
[13:18:02 EDT(-0400)] <colinclark> I'm curious about why the surrounding divs would need a -1...
[13:18:07 EDT(-0400)] <Bosmon> For myself, I still can't think of a good way of resolving my issues...
[13:18:10 EDT(-0400)] <colinclark> Since shouldn't divs be non-focussable by default.
[13:18:33 EDT(-0400)] <ecochran> because for some reason when the div becomes scrolling, it becomes focusable
[13:18:46 EDT(-0400)] <colinclark> Bosmon: Was your earlier question about tricksy-ness directed at me or Eli?
[13:18:47 EDT(-0400)] <Bosmon> aha!
[13:18:48 EDT(-0400)] <ecochran> actually makes sense, so that keyboard users can select and scroll
[13:18:51 EDT(-0400)] <Bosmon> colinclark: To you )
[13:18:53 EDT(-0400)] <Bosmon> er
[13:18:58 EDT(-0400)] <Bosmon> Tricksy Hobbitses....
[13:19:06 EDT(-0400)] <colinclark> Bosmon: That's what I figured.
[13:19:13 EDT(-0400)] <colinclark> ecochran: Yes, that does make sense.
[13:19:20 EDT(-0400)] <colinclark> Do we have a fragementSelector for it?
[13:19:21 EDT(-0400)] <colinclark> Wouldn
[13:19:25 EDT(-0400)] <Bosmon> But the more and more I look at this component, the more I get worried by its potential for "mis-statefulness" as its list of selectables changes...
[13:19:33 EDT(-0400)] <ecochran> colinclark: yes
[13:19:39 EDT(-0400)] <ecochran> .fileQueue
[13:19:46 EDT(-0400)] <colinclark> cool
[13:20:19 EDT(-0400)] <Bosmon> We want a protocol that is easy for external users to follow, that makes sure that they can never get into this corrupt situation
[13:20:26 EDT(-0400)] <Bosmon> But I'm not quite sure how to set it up
[13:21:11 EDT(-0400)] <Bosmon> Either i) there is a "special" operation it supports called "removeSelectable" which they must invoke instead of plain "remove" when they know they are interacting with a selectable list, or ii) there is an "informer" that they trigger either a) before, or b) after the operation of removal
[13:21:37 EDT(-0400)] <colinclark> Hmm...
[13:21:48 EDT(-0400)] <Bosmon> i) doesn't seem very attractive... especially if it just so happens that the thing they want to remove isn't selected at that instant
[13:22:15 EDT(-0400)] <Bosmon> If we go with ii) I think we need to change the internal state of the component, to hold simply the "index" of the selected DOM element rather than the entire element
[13:22:45 EDT(-0400)] <Bosmon> Since otherwise it becomes hard to know what to do to "patch up" the selectable state in the event of an unknown asynchronous change
[13:23:35 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[13:24:21 EDT(-0400)] <colinclark> Bosmon: I'll need a few minutes to catch up, sorry for the delay.
[13:24:39 EDT(-0400)] <ecochran> colinclark: so you're not happy with my binding the delete key on the row to the remove button?
[13:24:59 EDT(-0400)] <colinclark> ecochran: Not unhappy. Just not certain.
[13:25:01 EDT(-0400)] <colinclark>
[13:25:18 EDT(-0400)] <ecochran> colinclark: it works, and (to me) it makes sense
[13:25:31 EDT(-0400)] <ecochran> brb... got to go get my power cord
[13:26:44 EDT(-0400)] <ecochran> back
[13:27:13 EDT(-0400)] * colinclark will respond to everyone in a few minutes.
[13:29:45 EDT(-0400)] <Justin_o> ecochran: sorry to be jumping in here late, but did the fix for Fluid-1016 also fix Fluid-1004
[13:31:36 EDT(-0400)] <ecochran> Justin_o: one moment
[13:32:07 EDT(-0400)] <Justin_o> thanks
[13:32:14 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has left #fluid-work
[13:32:19 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has joined #fluid-work
[13:33:25 EDT(-0400)] <ecochran> my Mom called
[13:34:20 EDT(-0400)] <ecochran> Justin_o: hard to tell since 1004 is hard to reproduce, but I can't reproduce it now, so I'm thinking that maybe yes
[13:34:26 EDT(-0400)] <ecochran> how was that for an answer
[13:34:55 EDT(-0400)] <Justin_o> um... hard to say
[13:35:07 EDT(-0400)] <Justin_o> 9.9
[13:35:39 EDT(-0400)] <ecochran> now that I think about it, I'll give it a definitive Yes!
[13:35:45 EDT(-0400)] <ecochran> two down!
[13:35:51 EDT(-0400)] <Justin_o> i'll be going through and re-testing these after the build site updates... so i'll look at it then..i guess
[13:36:00 EDT(-0400)] <Justin_o> oh okay.. 2 down
[13:36:54 EDT(-0400)] <ecochran> I'll update JIRA
[13:37:08 EDT(-0400)] <Justin_o> thank you...
[13:38:41 EDT(-0400)] <colinclark> Okay. ecochran, sorry for the delay. When you're free, can you walk me through the change you've made with event binding of remove on the file queue?
[13:39:33 EDT(-0400)] <ecochran> iChat
[13:39:35 EDT(-0400)] <ecochran> ?
[13:42:04 EDT(-0400)] <colinclark> Sure.
[13:50:15 EDT(-0400)] <Bosmon> OK
[13:50:23 EDT(-0400)] <Bosmon> I have done a big refactoring, and broken all the tests
[13:50:43 EDT(-0400)] <Bosmon> I need to go home for a bit, but should be able to clean this up before "code freeze"....
[13:51:16 EDT(-0400)] <Bosmon> But in the meantime, probably best to consider keyboard-a11y "off limits" unless you can think of something really urgent and/or low-impact...
[13:51:48 EDT(-0400)] <Bosmon> Oh glarg
[13:51:52 EDT(-0400)] <Bosmon> Looks like 1004 is fixed already...
[13:52:06 EDT(-0400)] <Bosmon> I guess that still leaves 1028...
[13:54:38 EDT(-0400)] <Justin_o> It looks like, 1016, 1004, and 1005 have been fixed
[13:54:54 EDT(-0400)] <Bosmon> 1005 is fixed already too!
[13:55:00 EDT(-0400)] <Bosmon> glarg...
[13:55:55 EDT(-0400)] <Bosmon> OK, this refactoring still has the potential to fix 1028
[13:56:06 EDT(-0400)] <Bosmon> Although it is probably a bit of overkill...
[13:59:39 EDT(-0400)] * ecochran (n=ecochran@adsl-70-137-135-24.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[13:59:54 EDT(-0400)] <colinclark> Bosmon; eli and I have just squashed some bugs.
[14:00:31 EDT(-0400)] <Bosmon> So I have heard
[14:00:31 EDT(-0400)] <colinclark> Bosmon: So we were binding selectability to the uploadContainer as a whole.
[14:00:45 EDT(-0400)] <Bosmon> Yes, that would have been the fix I expected for 1005
[14:00:57 EDT(-0400)] <colinclark> We caught it as Eli was touring me through his workaround.
[14:01:03 EDT(-0400)] <colinclark> We're now binding it on the fileQueue itself.
[14:01:07 EDT(-0400)] <Bosmon> yes
[14:01:26 EDT(-0400)] <colinclark> Bosmon: Cool.
[14:01:30 EDT(-0400)] <Bosmon> But the "interesting upshot" seems to be that there is actually no "fatal death" condition relating deleting the focused node?
[14:01:47 EDT(-0400)] <Bosmon> Which therefore means that 1028 and 1004 are actually unrelated?
[14:02:15 EDT(-0400)] <ecochran> I beleive that 1004 was related to 1016
[14:02:32 EDT(-0400)] * colinclark is cross-referecing behaviour with bug numbers.
[14:02:35 EDT(-0400)] <colinclark>
[14:02:42 EDT(-0400)] <ecochran> we just tripped over it because in the process of removing files, we removed the scrolling
[14:02:48 EDT(-0400)] <ecochran> colinclark: already done
[14:03:01 EDT(-0400)] <Bosmon> It helps to keep the breeze room open
[14:03:07 EDT(-0400)] <colinclark> ecochran: No, I mean, I'm trying to remember which bug corresponds with which number.
[14:03:15 EDT(-0400)] <Bosmon> Well, the deceptive thing is, I actually never see scrollbars
[14:03:17 EDT(-0400)] <colinclark> I'm following Bosmon's lead and referring to the breeze room notes.
[14:03:19 EDT(-0400)] <ecochran> ah
[14:03:20 EDT(-0400)] <Bosmon> But I still see 1004
[14:03:40 EDT(-0400)] <Bosmon> I mean, on FF3 on Windows, I can bring up a file list which is initially selectable
[14:03:41 EDT(-0400)] <ecochran> you do?
[14:03:49 EDT(-0400)] <Bosmon> I mean "saw"
[14:03:51 EDT(-0400)] <Bosmon>
[14:04:09 EDT(-0400)] <Bosmon> That is, when I saw 1004, I saw it without any scrollbars in the picture
[14:04:19 EDT(-0400)] <colinclark> This page helps, too. http://wiki.fluidproject.org/display/fluid/Fluid+0.4+Release+Status
[14:04:35 EDT(-0400)] <Bosmon> Since there were none on the initial load, but on deleting the selectable row, I then went on to a state of "completely destroyed selectability"
[14:04:37 EDT(-0400)] <ecochran> ah, you have to tab back to the file queue after the delete
[14:04:45 EDT(-0400)] <Bosmon> I couldn't actually tab back to it
[14:04:50 EDT(-0400)] <ecochran> but it is selectable, where before it wasn't
[14:04:52 EDT(-0400)] <ecochran> really
[14:04:57 EDT(-0400)] <ecochran> and you picked up my changes?
[14:05:02 EDT(-0400)] <Bosmon> No, this was before
[14:05:08 EDT(-0400)] <Bosmon> I would bet that your change had fixed it
[14:05:24 EDT(-0400)] <Bosmon> But all the same, it might be just a touch broader than just the scrollbars
[14:05:24 EDT(-0400)] <ecochran> yes, I have marked it fixed with my change
[14:05:34 EDT(-0400)] <Bosmon> That is, my guess is that 1005 is actually a bit broader than 1016
[14:05:38 EDT(-0400)] <colinclark> Everyone update!
[14:05:39 EDT(-0400)] <Bosmon> But probably still fixed by the same fix....]
[14:06:01 EDT(-0400)] <Bosmon> Fucking Javascript....
[14:06:06 EDT(-0400)] <Bosmon> OK, I will be "out" for about 3 hours
[14:06:14 EDT(-0400)] <Bosmon> But I hope to still get 1028 in before the evening
[14:06:17 EDT(-0400)] <ecochran> there is still the problem that when you delete a row, the next row isn't selected
[14:06:27 EDT(-0400)] <Bosmon> Yes, that is 1028
[14:06:46 EDT(-0400)] <ecochran> would you mind if I looked at it while you are out?
[14:06:51 EDT(-0400)] <ecochran> Bosmon: ^
[14:06:52 EDT(-0400)] <Bosmon> Not at all
[14:06:59 EDT(-0400)] <Bosmon> But it requires fixing keyboard-a11y
[14:07:05 EDT(-0400)] <ecochran> does it?
[14:07:08 EDT(-0400)] <Bosmon> Yes
[14:07:16 EDT(-0400)] <Bosmon>
[14:07:22 EDT(-0400)] <ecochran> why not just set the focus after the row remove?
[14:07:35 EDT(-0400)] <Bosmon> because this should be a natural function of keyboard-a11y
[14:07:38 EDT(-0400)] <ecochran> ok
[14:07:50 EDT(-0400)] <ecochran> then I'm probably not going to do anything with it
[14:07:59 EDT(-0400)] <Bosmon> ok
[14:08:05 EDT(-0400)] <colinclark> Bosmon: See you soon.
[14:08:07 EDT(-0400)] <Bosmon> Amazing work fixing the 90% of other bugs though
[14:08:10 EDT(-0400)] <Bosmon> A fine session
[14:08:12 EDT(-0400)] <Bosmon> See you later...
[14:08:22 EDT(-0400)] <ecochran> ciao
[14:08:33 EDT(-0400)] <ecochran> Bosmon: going dancing?
[14:08:38 EDT(-0400)] * colinclark is super impressed with our shared bug fixing sprint.
[14:09:25 EDT(-0400)] <colinclark> Justin_o: So I'm seeing some significantly improved behaviour here in FF3.
[14:09:48 EDT(-0400)] <colinclark> Biggest issue left is 1028. I'm finding that the queue is just completely not selectable after deleting a row.
[14:10:17 EDT(-0400)] * smkeesle (n=smkeesle@h137.147.40.69.dynamic.ip.windstream.net) has joined #fluid-work
[14:10:26 EDT(-0400)] * smkeesle (n=smkeesle@h137.147.40.69.dynamic.ip.windstream.net) has left #fluid-work
[14:10:51 EDT(-0400)] <Justin_o> really.. you can't tab or shift-tab back at all
[14:12:11 EDT(-0400)] <Justin_o> should we update the build site with these changes now?
[14:13:22 EDT(-0400)] <ecochran> colinclark: you picked up my changes?
[14:13:33 EDT(-0400)] <colinclark> ecochran: Yep
[14:13:41 EDT(-0400)] <ecochran> I'm not having that problem
[14:13:58 EDT(-0400)] <colinclark> Justin_o: Yes, if you know how, go ahead and update the build site.
[14:14:13 EDT(-0400)] <Justin_o> okay.. i think i remember how.
[14:14:38 EDT(-0400)] <ecochran> colinclark: no, I'm seeing it too... didn't refresh my browser
[14:14:44 EDT(-0400)] <ecochran> I think that I know what the problem is
[14:14:53 EDT(-0400)] <ecochran> give me a minute
[14:16:26 EDT(-0400)] * colinclark is on a conference call with Eli's aunt.
[14:16:33 EDT(-0400)] <Justin_o> ecochran: i'll wait till you get back on that one, to update the build site.. I don't remember the login anyways
[14:16:53 EDT(-0400)] <ecochran> colinclark: say hi for me
[14:17:00 EDT(-0400)] <colinclark> will do
[14:27:02 EDT(-0400)] <ecochran> colinclark: I have fixed it, but my fix is unsettling. Basically, after the remove and the refreshSelectable, I'm setting tabbable for the queue again, and that seems to do it. In order to see the queue focus, I've added a little visual feedback as well, although this is spurious since really the row should be focusing when the queue gets focus
[14:28:21 EDT(-0400)] <ecochran> colinclark: OK, I removed the additional setting of tabbable and I'm still seeing the fix. Confusion!
[14:29:43 EDT(-0400)] <Justin_o> i'm updating the daily build site now.. i'm guessing you haven't committed this change yet.. did you want me to do some testing on the current behaviour
[14:30:25 EDT(-0400)] <ecochran> sure
[14:30:44 EDT(-0400)] <colinclark> ecochran: distracted. listening to lois be very sensible
[14:30:46 EDT(-0400)] <colinclark>
[14:30:55 EDT(-0400)] <ecochran> she is that!
[14:30:58 EDT(-0400)] <ecochran> and a lot more
[14:31:08 EDT(-0400)] <ecochran> what's the meeting?
[14:31:28 EDT(-0400)] <ecochran> colinclark: ^
[14:32:30 EDT(-0400)] <colinclark> ecochran: Exploring Fluidic involvement in Grouper and Shibboleth.
[14:32:41 EDT(-0400)] <ecochran> ah
[14:32:44 EDT(-0400)] <colinclark> And, indeed, Stanford's interest in Fluid.
[14:33:01 EDT(-0400)] <ecochran> I am going to take a little break to clear my head.. brb
[14:33:21 EDT(-0400)] <Justin_o> ecochran: & colinclark : where did you see the error where you can't tab back to the file queue after deleting a file
[14:33:33 EDT(-0400)] <Justin_o> i.e. browser? version of uploader?
[14:33:50 EDT(-0400)] <colinclark> Justin_o: FF3.01, Leopard.
[14:33:51 EDT(-0400)] <ecochran> FF3, pop-up
[14:34:00 EDT(-0400)] <ecochran> mac
[14:34:06 EDT(-0400)] <Justin_o> okay.. i'll take a look
[14:34:09 EDT(-0400)] <colinclark> inline for me
[14:34:10 EDT(-0400)] <colinclark>
[14:34:28 EDT(-0400)] * jhung (n=Administ@H33.C205.cci.switchworks.net) has left #fluid-work
[14:40:01 EDT(-0400)] <Justin_o> ecochran: you fixed 1027 as well?
[14:41:08 EDT(-0400)] <Justin_o> for the can't tab back after remove issue...
[14:41:17 EDT(-0400)] <ecochran> Justin_o: mostly... seems that after a delete, then that behavior also gets broken
[14:41:28 EDT(-0400)] <Justin_o> oka
[14:41:32 EDT(-0400)] <colinclark> ecochran: Lois says hi and that she'll give you a call sometime.
[14:41:33 EDT(-0400)] <ecochran> I'm still working on it
[14:41:39 EDT(-0400)] <ecochran> colinclark: cool
[14:41:54 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[14:42:17 EDT(-0400)] <Justin_o> ecochran: I found that I can tab back to where the file queue is.. there is no dislpay of focus, but if you press the arrow key it will select a file..then you can tab around and get back to that file again
[14:42:39 EDT(-0400)] <colinclark> Deletion is still an interesting problem.
[14:42:43 EDT(-0400)] <ecochran> Justin_o: yeah, I'm seeing that too
[14:42:59 EDT(-0400)] <colinclark> Since I imagine the keyboard plugin holds onto an invalid state once a row has been removed...
[14:43:06 EDT(-0400)] <colinclark> thinking that the deleted row is still active.
[14:43:19 EDT(-0400)] <ecochran> colinclark: but we're refreshing it
[14:43:27 EDT(-0400)] <ecochran> but the refresh seems a little wanky
[14:43:34 EDT(-0400)] <colinclark> I really wish we had better events that would fire in the browser when DOM manipulation occurs.
[14:43:39 EDT(-0400)] <colinclark> ecochran: Hmm... Interesting.
[14:44:09 EDT(-0400)] <colinclark> ecochran: refresh() probably doesn't explicitly update its activeItem state accordingly.
[14:44:19 EDT(-0400)] <ecochran> ah
[14:44:47 EDT(-0400)] <colinclark> Once the arrow key is fired, state does get updated properly.
[14:44:59 EDT(-0400)] <ecochran> colinclark & Justin_o : I'm going to check in my very minor changes (mostly visual so you can see when the queue is focus'd
[14:45:13 EDT(-0400)] <ecochran> colinclark: also adding more items seems to refresh the state as well
[14:45:15 EDT(-0400)] <colinclark> I believe Antranig was calling this issue "tricksy." But I remember that there was a reason for all of this.
[14:45:25 EDT(-0400)] <ecochran> colinclark: it's only removing that seems troubling
[14:45:30 EDT(-0400)] <colinclark> ecochran: Interesting... I wonder why.
[14:46:23 EDT(-0400)] <Justin_o> ecochran: please let me know after you commit and i'll update the daily build site again
[14:46:43 EDT(-0400)] <ecochran> Justin_o: done
[14:46:55 EDT(-0400)] <Justin_o> thanks
[14:46:58 EDT(-0400)] <ecochran> Justin_o: seems that I should reopen 1004
[14:47:36 EDT(-0400)] <Justin_o> yes... it would appear so... oh well
[14:50:16 EDT(-0400)] <ecochran> colinclark: actually adding has the same problem, of no longer selecting a row when the file queue is focused... hmm
[14:50:37 EDT(-0400)] <ecochran> you only see the problem if you delete and then add
[14:50:42 EDT(-0400)] <ecochran> but the same problem
[14:51:08 EDT(-0400)] <ecochran> colinclark: can you confirm that you're still seeing an inability to select the file queue at all?
[14:56:26 EDT(-0400)] <colinclark> ecochran: On phone. Will check soon.
[14:56:47 EDT(-0400)] <ecochran> np
[15:02:46 EDT(-0400)] <anastasiac> You guys have been busy!!
[15:03:07 EDT(-0400)] <anastasiac> I just got back from a bloodletting, and updated my code, and the Uploader rocks!!
[15:04:24 EDT(-0400)] <anastasiac> you guys have been squashing issues like mad
[15:04:26 EDT(-0400)] <anastasiac> excellent!
[15:05:47 EDT(-0400)] <anastasiac> is JIRA being kept up to date?
[15:05:59 EDT(-0400)] <anastasiac> can I rely on it to tell me what's been fixed, and what hasn't?
[15:06:09 EDT(-0400)] <anastasiac> Justin_o ^
[15:08:07 EDT(-0400)] <Justin_o> I believe ecochran said he was updating jira.. i'll double check right now though
[15:09:26 EDT(-0400)] <Justin_o> um.. well it looks some what up-to-date... the only points being Fluid-1004 and Fluid-1027 which ecochran is working on currently
[15:10:08 EDT(-0400)] <anastasiac> ok, cool - thanks
[15:10:25 EDT(-0400)] <Justin_o> also I believe Bosmon is in the process of working on Fluid-1028 but had to step out for a bit
[15:10:34 EDT(-0400)] <ecochran> IE6 as usual looks pretty well %$#!
[15:10:37 EDT(-0400)] <anastasiac> yep, I saw that thanks
[15:14:16 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[15:22:21 EDT(-0400)] <colinclark> FLUID-1004: still come odd behavior
[15:22:25 EDT(-0400)] <colinclark> A very poetic commit log
[15:30:58 EDT(-0400)] <anastasiac>
[15:45:09 EDT(-0400)] <ecochran> unintended but I'll take the praise where I can get it
[15:50:55 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[16:11:09 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[16:11:12 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[16:20:30 EDT(-0400)] <colinclark> still come, odd behavior
[16:20:34 EDT(-0400)] <colinclark> we enjoying fixing you
[16:21:05 EDT(-0400)] <colinclark> Well everyone, the bug parade has been awfully enjoyable today.
[16:21:13 EDT(-0400)] <colinclark> But I'm going sailing.
[16:21:32 EDT(-0400)] <Justin_o> maybe you can drown some of the bugs
[16:21:47 EDT(-0400)] <colinclark> Justin_o: Strangely, bugs are attracted to my boat.
[16:21:50 EDT(-0400)] <colinclark> I have no idea why.
[16:34:24 EDT(-0400)] <Justin_o> when fixing 1028, 1029, please ensure 1024 is fixed as well
[16:41:52 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has left #fluid-work
[16:46:18 EDT(-0400)] <ecochran> pretty sure that 873 is fixed. I had trouble reproducing the bug in the first place, but I made a change that forcibly took the swf obj out of the tab rotation
[16:46:58 EDT(-0400)] * ecochran (n=ecochran@adsl-70-137-135-24.dsl.snfc21.sbcglobal.net) has left #fluid-work
[16:51:56 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[16:53:51 EDT(-0400)] <anastasiac> ecochran, that's great - if you're convinced (i.e. works in all browsers, unit tests pass) then maybe resolve the issue? Justin can close it on Monday (he's gone for the night now)
[16:56:34 EDT(-0400)] <anastasiac> I'm heading home for dinner now, but I'll get back online when I get there (half-hour, maybe 45 min)
[16:56:55 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has left #fluid-work
[17:32:18 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[17:52:36 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[17:52:46 EDT(-0400)] * anastasiac (n=stasia@74.12.144.5) has joined #fluid-work
[18:12:03 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[18:19:47 EDT(-0400)] * anastasiac (n=stasia@74.12.144.5) has joined #fluid-work
[19:07:48 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work