fluid-work IRC Logs-2010-04-08

Owned by Fluid IRC Log Bot
Last updated: Apr 08, 2010Version comment
12 min read

[15:49:46 EDT(-0400)] <michelled> ok, Justin_o, it's checked in
[15:49:58 EDT(-0400)] <Justin_o> michelled: thanks...
[15:50:01 EDT(-0400)] <michelled> np
[15:50:26 EDT(-0400)] <Justin_o> michelled: So i can cut the beta tag now... or would you like to?
[15:50:46 EDT(-0400)] <michelled> go ahead
[15:51:00 EDT(-0400)] <michelled> svn copy from to
[16:26:27 EDT(-0400)] <Justin_o> jessm: Infusion 1.2beta1 has been tagged and a message sent to the infusion-users and fluid-work lists
[16:26:32 EDT(-0400)] * jimeng (~jimeng@141-213-171-082.vpn.umnet.umich.edu) has joined #fluid-work
[16:26:53 EDT(-0400)] <jessm> Justin_o: awesome
[17:19:01 EDT(-0400)] * clown (~clown@142.150.154.101) has left #fluid-work
[17:44:39 EDT(-0400)] * anastasiac (~team@142.150.154.193) has left #fluid-work
[02:21:32 EDT(-0400)] * kasper (~kasper@0x5552c030.adsl.cybercity.dk) has joined #fluid-work
[02:28:53 EDT(-0400)] * joost (~joost@dfki-113.dfki.uni-kl.de) has joined #fluid-work
[03:28:44 EDT(-0400)] * boyan (~boyan@62.44.101.70) has joined #fluid-work
[05:27:33 EDT(-0400)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[05:58:13 EDT(-0400)] * boyan (~boyan@62.44.101.70) has joined #fluid-work
[08:01:40 EDT(-0400)] * boyan (~boyan@62.44.101.70) has left #fluid-work
[08:07:00 EDT(-0400)] * michelled (~michelled@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[08:36:52 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[09:17:24 EDT(-0400)] * yura (~yura@142.150.154.101) has joined #fluid-work
[09:30:35 EDT(-0400)] * colinclark (~colin@bas2-toronto09-1176131835.dsl.bell.ca) has joined #fluid-work
[09:32:37 EDT(-0400)] <colinclark> justin_o: So, how'd it go yesterday?
[09:32:45 EDT(-0400)] <colinclark> No trouble tagging the beta release?
[09:33:26 EDT(-0400)] <justin_o> colinclark: that went pretty smooth... michelled sat with me... we updated the version to 1.2beta1 and modified the readme a bit. mostly pulling stuff out
[09:33:38 EDT(-0400)] <justin_o> i should probably do some jira maintenance about it...
[09:34:01 EDT(-0400)] <justin_o> colinclark: not sure if you seen antranig's e-mails about FLUID-3590
[09:34:09 EDT(-0400)] <justin_o> in short it's not looking too good
[09:34:15 EDT(-0400)] <colinclark> I have seen his email
[09:34:37 EDT(-0400)] <colinclark> My interpretation wasn't so much "not looking good" as "this is interesting"
[09:34:53 EDT(-0400)] <justin_o> ah did you see the e-mail from this morning?
[09:34:59 EDT(-0400)] <colinclark> Ah, no
[09:35:00 EDT(-0400)] <colinclark> Where is it?
[09:35:06 EDT(-0400)] <justin_o> fluid-work
[09:35:15 EDT(-0400)] <colinclark> aha!
[09:35:16 EDT(-0400)] <colinclark> Reading now
[09:35:38 EDT(-0400)] <justin_o> basically the problem seems to be that when we put focus on an element with a tabindex of -1 the browser gets confused
[09:36:10 EDT(-0400)] <justin_o> with the layoutreorderer example... the elements have a tabindex of 0, so that would be why that demo is still working
[09:36:57 EDT(-0400)] <justin_o> colinclark: i've mentioned the issue to david b. and he's going to try to take a look at it today
[09:37:27 EDT(-0400)] <colinclark> I'd feel better about this if it was isolated to FF 3.6
[09:37:34 EDT(-0400)] <justin_o> yes
[09:39:02 EDT(-0400)] <colinclark> Ok, so I understand some aspect of this
[09:39:15 EDT(-0400)] <colinclark> I'd like to go ahead prepare for a final release.
[09:39:18 EDT(-0400)] <colinclark> Where are we at with QA?
[09:39:29 EDT(-0400)] <colinclark> The other thing that occurs to me is that we need to work on some documentation
[09:40:03 EDT(-0400)] <colinclark> We need a "migrating to Infusion 1.2" tutorial, since a number of file linkages have changed.
[09:40:07 EDT(-0400)] <justin_o> colinclark: still a bunch to do... we have to redo all of the UI Options testing... we slowed down a bit because of these issues... and the uncertainty of their impact
[09:40:15 EDT(-0400)] <colinclark> ok
[09:40:22 EDT(-0400)] <justin_o> colinclark: definitely, something like what we did for 1.0 i guess
[09:40:28 EDT(-0400)] <colinclark> Let's focus on testing the rest of the application, and the writing the migration tutorial
[09:40:43 EDT(-0400)] <colinclark> I think we need to comb through each change in 1.2 and ask ourselves "will this impact our users in some way?"
[09:40:52 EDT(-0400)] <colinclark> Clearly, we haven't made breaking API changes for this release
[09:41:10 EDT(-0400)] <colinclark> But knowing about changes to physical dependencies is going to be important.
[09:41:43 EDT(-0400)] <justin_o> colinclark: okay... the one caveat i guess would be that a fix for FLUID-3590 would likely be a change to the keyboard a11y plugin, which means that if we do make a change there, we would have to retest everything that uses it.
[09:42:17 EDT(-0400)] <colinclark> justin_o: I suppose it might
[09:42:17 EDT(-0400)] <colinclark> B
[09:42:31 EDT(-0400)] <colinclark> But remember that the Reorderer doesn't actually use the keyboard-a11y plugin
[09:42:48 EDT(-0400)] <colinclark> I guess one of the things I'm keen to do is to see if we can reproduce this issue with the plugin
[09:42:57 EDT(-0400)] <colinclark> It may well be that we're missing something
[09:43:45 EDT(-0400)] <justin_o> colinclark: this problem should theoretically occur in the cabinet component as well
[09:43:57 EDT(-0400)] <justin_o> and that one does use the keyboard a11y plugin
[09:44:22 EDT(-0400)] <justin_o> however, i just noticed that there is a bug in it... that it doesn't set the tabindex of all of the anchors in the header to -1
[09:44:37 EDT(-0400)] <justin_o> so i can try to fix that and see if the problem occurs there as well
[09:45:04 EDT(-0400)] <colinclark> I'd be curious to see that, yes
[09:45:17 EDT(-0400)] <colinclark> justin_o: If you use the keyboard plugin, the tabindex changes should happen automatically for you
[09:45:30 EDT(-0400)] <colinclark> But perhaps you're setting some container as being selectable instead of the anchors?
[09:46:16 EDT(-0400)] <justin_o> colinclark: yes... the handles themselves are the ones used for the tab navigation... which are the h2's the anchors are just there to alert voiceover users that they are actionable
[09:46:21 EDT(-0400)] <colinclark> ok
[09:52:56 EDT(-0400)] * justin_o_ (~jmo@142.150.154.101) has joined #fluid-work
[09:54:06 EDT(-0400)] * mpcutter (~michael@iupr-48-018.informatik.uni-kl.de) has joined #fluid-work
[09:56:08 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[09:57:14 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[10:00:31 EDT(-0400)] * clown (~clown@142.150.154.101) has joined #fluid-work
[10:09:25 EDT(-0400)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[10:40:45 EDT(-0400)] <colinclark> jameswy: I really like your Deca 0.3 walkthrough page. Nice work on that!
[10:42:46 EDT(-0400)] <justin_o> colinclark: i've filed a jira for the problem with the cabinet and the tabindex
[10:42:47 EDT(-0400)] <justin_o> http://issues.fluidproject.org/browse/ENGAGE-542
[10:42:54 EDT(-0400)] <colinclark> ok
[10:42:59 EDT(-0400)] <justin_o> i'm going to commit a fix...
[10:43:05 EDT(-0400)] <justin_o> it looks like it has the same issue...
[10:43:09 EDT(-0400)] <justin_o> as the reorderer
[10:43:31 EDT(-0400)] <colinclark> justin_o: Can you describe real quick how to reproduce?
[10:43:51 EDT(-0400)] <justin_o> basically just try to tab through the page... it will get stuck at the first element
[10:44:06 EDT(-0400)] <colinclark> I'm looking at one of the "canonical" (read: ugly and out of date) keyboard-a11y demos, and it works fine.
[10:44:08 EDT(-0400)] <colinclark> ok
[10:44:43 EDT(-0400)] <colinclark> Can you try the Checkboxes demo in the standalone section?
[10:47:52 EDT(-0400)] <justin_o> colinclark: interesting... that one is still working, but it looks like the container doesn't push focus... the arrow keys will do that
[10:48:11 EDT(-0400)] <colinclark> What do you mean "container doesn't push focus?"
[10:48:38 EDT(-0400)] <justin_o> so in the reorderer example... as soon as you get to the container focus is pushed to one of the elements..
[10:48:45 EDT(-0400)] <justin_o> in this example the container keeps focus
[10:48:57 EDT(-0400)] <justin_o> and then when you push one of the arrow keys, focus moves to the element
[10:49:33 EDT(-0400)] <justin_o> okay.... well that is how ff 3.6 is doing it... looks like it is behaving as expected in Safari 4
[10:50:38 EDT(-0400)] <colinclark> Why am I not seeing that, justin_o?
[10:50:46 EDT(-0400)] <colinclark> Can you make me a screenshot or something?
[10:51:03 EDT(-0400)] <justin_o> colinclark: interesting thing is that the <p> has a tabindex set to -1 but the label and the input don't have it set... wonder if that has something to do with it
[10:51:07 EDT(-0400)] <justin_o> sure...
[10:51:41 EDT(-0400)] <colinclark> justin_o: You think maybe the hidden input field is doing it?
[10:52:20 EDT(-0400)] <justin_o> colinclark: thinking that's why navigation isn't broken
[10:52:29 EDT(-0400)] <justin_o> like it is in the reordeer
[10:52:56 EDT(-0400)] <colinclark> hmm
[10:53:02 EDT(-0400)] <colinclark> i guess there's only one way to find out
[10:54:09 EDT(-0400)] <justin_o> colinclark: just e-mailed you the screenshot... it shows focus on the container of the checkboxes
[10:57:07 EDT(-0400)] <colinclark> you're seeing this upon entry into the container?
[10:57:15 EDT(-0400)] <justin_o> colinclark: yep
[10:57:20 EDT(-0400)] <colinclark> Weird that I am not
[10:59:00 EDT(-0400)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[10:59:39 EDT(-0400)] <justin_o> colinclark: here is a test page that david b. made it doesn't show the error though... http://people.mozilla.com/~dbolter/triage/fluid-focus.html
[11:18:14 EDT(-0400)] <justin_o> colinclark: so i'm guessing from all of this that it has something to do with the container pushing focus onto an element that has a tab index of -1
[11:18:25 EDT(-0400)] <justin_o> i guess i should try to make a simple example of this
[11:36:28 EDT(-0400)] * boyan (~Administr@cms.studgrad.net) has joined #fluid-work
[11:41:33 EDT(-0400)] * elicochran (~elicochra@dhcp-169-229-212-66.LIPS.Berkeley.EDU) has joined #fluid-work
[11:57:38 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[12:06:17 EDT(-0400)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[12:06:24 EDT(-0400)] * michelled_ (~michelled@142.150.154.141) has joined #fluid-work
[12:22:18 EDT(-0400)] <justin_o> colinclark: check out bosmon's patch on FLUID-3590
[12:22:56 EDT(-0400)] <colinclark> i will
[12:23:25 EDT(-0400)] * yura (~yura@142.150.154.101) has left #fluid-work
[12:24:06 EDT(-0400)] * yura (~yura@142.150.154.114) has joined #fluid-work
[12:52:10 EDT(-0400)] * joost (~joost@pD9E26B89.dip.t-dialin.net) has joined #fluid-work
[12:52:31 EDT(-0400)] * joost (~joost@pD9E26B89.dip.t-dialin.net) has left #fluid-work
[13:19:35 EDT(-0400)] <justin_o> colinclark: so it looks like this patch fixes the issue, there is minor issue.. where if you arrow throw the elements pressing tab will take you to the next one instead of out of the set
[13:19:49 EDT(-0400)] <justin_o> bosmon mentioned that he might be able to tweak that
[13:21:05 EDT(-0400)] <justin_o> this will mean a complete retest for any component using keyboard reordering... i suppose just he keyboard a11y tests though
[13:21:16 EDT(-0400)] <colinclark> jameswy, justin_o: http://www.asktog.com/columns/044top10docksucks.html
[14:04:42 EDT(-0400)] * elicochran (~elicochra@dhcp-169-229-212-66.LIPS.Berkeley.EDU) has joined #fluid-work
[14:09:53 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[14:14:36 EDT(-0400)] * justin_o_ (~jmo@142.150.154.101) has joined #fluid-work
[14:20:52 EDT(-0400)] * christianv (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[14:36:25 EDT(-0400)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[14:37:32 EDT(-0400)] * athena (~athena@dhcp128036160031.central.yale.edu) has joined #fluid-work
[15:16:49 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[15:37:54 EDT(-0400)] * colinclark (~colin@2002:8e01:9302:f:223:12ff:fe55:316d) has joined #fluid-work
[16:01:30 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[16:02:01 EDT(-0400)] * justin_o (~jmo@142.150.154.101) has joined #fluid-work
[16:02:42 EDT(-0400)] * michelled (~michelled@142.150.154.141) has joined #fluid-work
[16:15:06 EDT(-0400)] * athena (~athena@adsl-99-65-194-144.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[16:20:39 EDT(-0400)] * Bosmon7 (~a@ppp-94-69-86-98.home.otenet.gr) has joined #fluid-work
[16:26:33 EDT(-0400)] <Bosmon7> I WILL NOW PROCEDE TO TALK ABOUT MY FIX FOR THE FLUID-3590 ISSUE!
[16:26:52 EDT(-0400)] <colinclark> Bosmon7: Fire away
[16:27:10 EDT(-0400)] <Bosmon7> My spelling errors signify to my drunkenness
[16:27:13 EDT(-0400)] <Bosmon7> So
[16:27:43 EDT(-0400)] * denbuzze (~anonymous@cpc1-cmbg7-0-0-cust61.cmbg.cable.ntl.com) has joined #fluid-work
[16:27:55 EDT(-0400)] <Bosmon7> In the presence or absence of science, I still continue to assert that the cause of this issue is the "bananas-going" of the "modern browsers" on being asked to move focus from an element with tabindex -1
[16:28:17 EDT(-0400)] <Bosmon7> Science has not yet determined all the conditions necessary for this failure, but I believe that a sufficient set may be that the tabindex is dynamically assigned
[16:28:55 EDT(-0400)] <Bosmon7> I have a fix which THE KING has tested in a few browsers, and +/- a few minor issues seems to be working
[16:29:03 EDT(-0400)] <Bosmon7> I have just tweaked it a bit to hopefully remove the "minor issues"
[16:29:31 EDT(-0400)] <Bosmon7> So, the strategy of the fix is based on a kind of "floating island"
[16:30:16 EDT(-0400)] <Bosmon7> Much like the one which was used to effect the Normandy landings....
[16:30:46 EDT(-0400)] <Bosmon7> We dynamically and temporarily assign a tabindex of 0 just to the one item which is currently the "selected" one out of a set of "selectables"
[16:31:20 EDT(-0400)] <Bosmon7> As focus moves amongst the items, we restore the particular tabindex value requested to "trailing items" and move the island
[16:31:28 EDT(-0400)] <Bosmon7> This, amazingly, seems to work...
[16:32:08 EDT(-0400)] <Bosmon7> The "minor issues" are, to add insult to injury on top of its existing failure, FF 3.6 seems to fail to fire "blur" events on the "trailing selectable" when we programmatically call "focus" on the new one
[16:32:09 EDT(-0400)] <colinclark> ok, lemme catch up
[16:32:21 EDT(-0400)] <colinclark> I have read up to the part where you get drunk
[16:32:22 EDT(-0400)] <Bosmon7> So we have to make fixes around the framework to make explicit calls to "blur" here and there
[16:32:42 EDT(-0400)] <Bosmon7> One location in keyboard-a11y and one location in Reorderer.js seems to cover the cases which it is possible to trigger using keyboard navigation
[16:33:12 EDT(-0400)] <Bosmon7> But really "the new keyboard navigation" in the browsers seems a bit of a travesty
[16:33:21 EDT(-0400)] <colinclark> Bosmon7: This is already an established idiom
[16:33:26 EDT(-0400)] <Bosmon7> I have to note that Opera 10.5 is so badly broken that tab navigation gets stuck even on static pages
[16:33:29 EDT(-0400)] <colinclark> I was going to suggest it this morning
[16:33:32 EDT(-0400)] <colinclark> how funny
[16:33:40 EDT(-0400)] <Bosmon7> Let me guess, it is what Dojo does? (tongue)
[16:33:41 EDT(-0400)] <colinclark> let me dig up a good blog post
[16:33:44 EDT(-0400)] <colinclark> and perhaps we can compare
[16:33:48 EDT(-0400)] <Bosmon7> Well, hadn't we often suggested things of this kind in the past?
[16:33:50 EDT(-0400)] <colinclark> I don't think it is
[16:33:52 EDT(-0400)] <colinclark> yeah, we had
[16:33:58 EDT(-0400)] <Bosmon7> And then considered that they were too devastatingly dangerous to put into practice?
[16:34:18 EDT(-0400)] <Bosmon7> I seem to remember that our experiments to date with dynamic tabindex values had proved terrifyingly hazardous...
[16:34:30 EDT(-0400)] <Bosmon7> But I think that experiment was aimed at achieving something slightly different
[16:34:44 EDT(-0400)] <Bosmon7> As I remember, we were trying to interpose an island ahead of focus, rather than behind it
[16:34:48 EDT(-0400)] <colinclark> yes, this one: http://www.yuiblog.com/blog/2009/02/23/managing-focus/
[16:34:50 EDT(-0400)] <Bosmon7> But I'm not entirely sure why
[16:35:15 EDT(-0400)] <Bosmon7> Well, this is all to the good
[16:35:21 EDT(-0400)] <Bosmon7> Proving that this approach is not completely ridiculous (tongue)
[16:35:37 EDT(-0400)] <Bosmon7> But I just remember that in the past, we had laughed off those who tried to solve problems with dynamic tabindex values...
[16:36:11 EDT(-0400)] <colinclark> I think we never really determined that dynamically adjusting tab indices was bad
[16:36:18 EDT(-0400)] <colinclark> but just that it was clearly not necessary
[16:36:26 EDT(-0400)] <Bosmon7> Perhaps the Firefox developers actually read this post... and tried to enshrine this strategy in logic, to the detriment of all others
[16:36:33 EDT(-0400)] <colinclark> "Roaming tab index"
[16:36:46 EDT(-0400)] <Bosmon7> It would be hard to explain otherwise how both Webkit and FF came to break our component in exactly the same way at the same time
[16:36:51 EDT(-0400)] <Bosmon7> Given they don't share any codebase
[16:37:02 EDT(-0400)] <Bosmon7> I imagine they did this over a few beers (tongue)
[16:37:33 EDT(-0400)] <Bosmon7> See this comment:
[16:37:36 EDT(-0400)] <Bosmon7> "Yep, I strongly recommend roaming tabindex too. Nice post.
[16:37:36 EDT(-0400)] <Bosmon7> Comment by David Bolter"
[16:37:38 EDT(-0400)] <Bosmon7> (smile)
[16:38:33 EDT(-0400)] <colinclark> Ok, so let's go ahead and make this change
[16:38:40 EDT(-0400)] <colinclark> Science be damned, it actually makes sense
[16:38:49 EDT(-0400)] <colinclark> Bosmon7, I think we had even talked about doing this at some point
[16:38:51 EDT(-0400)] <colinclark> wait, you said this
[16:38:56 EDT(-0400)] <colinclark> so, here's my key question, king
[16:38:57 EDT(-0400)] <colinclark> justin_o:
[16:39:06 EDT(-0400)] <colinclark> When did Safari begin to exhibit this behaviour?
[16:39:18 EDT(-0400)] <Bosmon7> Well, it had always seems part of our "nuclear arsenal of options"
[16:39:33 EDT(-0400)] <justin_o> good question... tabbing to anything was broken before safari 4
[16:39:58 EDT(-0400)] <justin_o> but it may have been changed in some incremental revision of safari 4 since then
[16:40:00 EDT(-0400)] <justin_o> so not sure
[16:40:21 EDT(-0400)] <colinclark> ok
[16:40:24 EDT(-0400)] <colinclark> Bosmon7: What can I do to help?
[16:41:49 EDT(-0400)] * Bosmon8 (~a@athedsl-4557998.home.otenet.gr) has joined #fluid-work
[16:41:54 EDT(-0400)] <Bosmon8> Sorry, my wireless died for a while
[16:42:37 EDT(-0400)] <colinclark> Bosmon8: What can I do to hep?
[16:42:38 EDT(-0400)] <colinclark> help
[16:42:41 EDT(-0400)] <colinclark> I think we should do this
[16:42:46 EDT(-0400)] <colinclark> Indeed, I think it will simplify our logic a bit
[16:42:52 EDT(-0400)] <colinclark> In terms of keeping track of where we last were
[16:42:56 EDT(-0400)] <colinclark> Did you already mention this?
[16:43:23 EDT(-0400)] <Bosmon8> Well, I was thinking that last night, when I didn't fully understand the issue
[16:43:31 EDT(-0400)] <Bosmon8> I don't know if that is still true
[16:43:57 EDT(-0400)] <Bosmon8> I'm not convinced it is, since we still are after asymmetric TAB/Shift-TAB behaviour
[16:44:27 EDT(-0400)] <Bosmon8> I was thinking that "Dead Man's X" based solutions would simplify that, but I'm not sure that "Roaming Tabindex" simplifies things at all
[16:44:33 EDT(-0400)] <colinclark> Well, don't we currently keep track of the last thing that was selected, once we leave the container?
[16:44:44 EDT(-0400)] <Bosmon8> It is just a slight elaboration of our existing approach
[16:44:45 EDT(-0400)] <colinclark> I imagine we no longer need to do that, since we can leave the item with tabindex of 0
[16:44:49 EDT(-0400)] <colinclark> no?
[16:44:53 EDT(-0400)] <Bosmon8> colinclark: Not easily
[16:45:11 EDT(-0400)] <Bosmon8> Since that would require us to disinguish the cases of "blur because we are moving item" from "blur because we are leaving the container"
[16:45:34 EDT(-0400)] <colinclark> really?
[16:45:36 EDT(-0400)] <colinclark> why?
[16:45:37 EDT(-0400)] <Bosmon8> As it stands, the patch doesn't distinguish these, and I don't think it would make it much simpler to tell the difference
[16:45:54 EDT(-0400)] <colinclark> ah, i think i see
[16:46:12 EDT(-0400)] <Bosmon8> Even worse, there is "blur because the browser lost focus"
[16:46:31 EDT(-0400)] <Bosmon8> The thing is, there are just "too many" causes of focus/blur for me to be confident we can reliably triage all of them (tongue)
[16:47:02 EDT(-0400)] <Bosmon8> So as it stands the patch tries to make an exact equivalence between "focus/blur on a selectable" and "tabindex 0 island"
[16:47:40 EDT(-0400)] <Bosmon8> To the extent that it even needs to fire a couple of synthetic "blur" events to paper over what looks like another browser bug (sad)
[16:47:52 EDT(-0400)] <Bosmon8> Anyway, haven't we decided that "using the DOM as our storage" is not a moral course? (smile)
[16:49:35 EDT(-0400)] <colinclark> i'll need to look at your patch
[16:49:40 EDT(-0400)] <colinclark> Is that the best next step?
[16:49:42 EDT(-0400)] <Bosmon8> My patch is attached as "FLUID-3590.patch"
[16:49:47 EDT(-0400)] <colinclark> I think we know what to do, so how can I help?
[16:50:08 EDT(-0400)] <Bosmon8> THE KING says that the approach appears to basically work in the browsers we are interested in
[16:50:17 EDT(-0400)] <Bosmon8> I think the key issue now is to try to check for "mouse droppings"
[16:50:35 EDT(-0400)] <colinclark> lol
[16:50:36 EDT(-0400)] <Bosmon8> Ways of "faking out" the container such that it leaves multiple trails of tabindex 0 behind in some kinds of situations
[16:50:38 EDT(-0400)] <colinclark> gross
[16:50:57 EDT(-0400)] <Bosmon8> I noticed that Reorderer keyboard nav is an independent cause of this to selectable keyboard nav
[16:51:03 EDT(-0400)] <Bosmon8> And there may be others I haven't found yet
[16:51:14 EDT(-0400)] <justin_o> Bosmon8: interesting...
[16:51:25 EDT(-0400)] <Bosmon8> I tried putting a blanket bit of logic inside keyboard-a11y select() - but this runs into recursion issues
[16:51:49 EDT(-0400)] <Bosmon8> Since it may be that we are servicing a true, that is a non-synthetic attempt to focus an element... in which case firing a "manual blur" never terminates
[16:52:33 EDT(-0400)] <Bosmon8> To make that approach work properly might require something like threadlocals, to "note on the stack" that we are currently already servicing a focus/blur event
[16:52:55 EDT(-0400)] <Bosmon8> Although to be honest, since we decided that "synthetic focus" is the primary means of communicating with a "selectable" the outlook for that approach is not good
[16:53:08 EDT(-0400)] <Bosmon8> That decision in the past may also have been bad, but it is certainly no longer reversible
[16:53:23 EDT(-0400)] <Bosmon8> So I think to get this code to release requires a search for "mouse droppings" (smile)
[16:54:15 EDT(-0400)] <Bosmon8> Perhaps you can think of a different approach that is "naturally mouse-dropping free"
[16:54:30 EDT(-0400)] <Bosmon8> But I was nervous about impacting any deeper code or algorithms at this stage in QA....
[16:55:09 EDT(-0400)] <justin_o> Bosmon8: thanks for all of this
[16:55:45 EDT(-0400)] <colinclark> Bosmon8: I guess the thing is that we should fix this as best we can, even at this stage of QA
[16:55:53 EDT(-0400)] <colinclark> with the caveat that we don't want to fall into a huge hole
[16:55:56 EDT(-0400)] <Bosmon8> ok
[17:01:10 EDT(-0400)] * JASIGLogBot (~PircBot@jasig.Princeton.EDU) has joined #fluid-work
[17:01:10 EDT(-0400)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 2009-11-04 08:30:00 EST(-0500)
[17:01:11 EDT(-0400)] <Bosmon8> I guess we should trim it out before release as well
[17:01:18 EDT(-0400)] <Bosmon8> It may have been left behind in exactly this refactoring
[17:02:45 EDT(-0400)] * christianv (~anonymous@cpc1-cmbg7-0-0-cust61.cmbg.cable.ntl.com) has joined #fluid-work
[17:03:41 EDT(-0400)] <colinclark> ok, I'll take a look at these issues tomorrow and see what i can do