fluid-work IRC Logs-2010-12-20

Owned by Fluid IRC Log Bot
Last updated: Dec 20, 2010Version comment
16 min read

[08:33:51 CST(-0600)] <jamon> fluid-everyone: just checking in, anything require my attention? wiki and jira are both up and running ok after restarting
[08:37:40 CST(-0600)] <Justin_o> jamon: yes they both seem to be running now.. thanks
[08:37:45 CST(-0600)] <Justin_o> are you heading out on vacation now?
[08:41:24 CST(-0600)] <heidi_> justin_o the code for the grid reorderer has to change. right now it is a <ul> with <div>s instead of <li>s
[08:41:41 CST(-0600)] <heidi_> sorry, demo
[08:42:01 CST(-0600)] <Justin_o> (sad)
[08:42:10 CST(-0600)] <jamon> Justin_o: yep, photography time. enjoy your vacation tomorrow,
[08:42:26 CST(-0600)] <Justin_o> jamon: thanks... have a good time off
[08:42:36 CST(-0600)] <heidi_> justin ya view src for http://build.fluidproject.org/infusion/demos/reorderer/gridReorderer/html/gridReorderer.html
[08:42:49 CST(-0600)] <Justin_o> heidi_: i think there was a change to switch from li's to div's but i guess the parent wasn't changed properly
[08:43:00 CST(-0600)] <heidi_> yeah
[08:45:57 CST(-0600)] <Justin_o> heidi_: i wonder how the AT's will handle that
[08:46:37 CST(-0600)] <heidi_> justin_o there's also a missing closing </div> ... ill make a jira to validate it
[08:46:51 CST(-0600)] <Justin_o> heidi_: thanks
[09:23:49 CST(-0600)] <mlam> colinclark: posted patch for FLUID-3952
[09:23:59 CST(-0600)] <colinclark> mlam: Awesome, thanks
[09:24:00 CST(-0600)] <colinclark> I
[09:24:03 CST(-0600)] <colinclark> I'll commit it shortly
[09:24:07 CST(-0600)] <mlam> no problem
[09:24:08 CST(-0600)] <mlam> ok
[09:24:11 CST(-0600)] <colinclark> I'm just working on the other blocker
[09:24:19 CST(-0600)] <colinclark> amazing what a stray space can do!
[09:24:29 CST(-0600)] <mlam> i know! that's nuts. how did you manage to debug it?
[09:24:49 CST(-0600)] <colinclark> Using the debugging proxy
[09:25:04 CST(-0600)] <colinclark> i uploaded the same file with the single upload and the HTML 5 uploader, and compared the requests
[09:25:20 CST(-0600)] <colinclark> the stray space at the beginning of the boundary was pretty prominent, so it wasn't much work
[09:25:43 CST(-0600)] <mlam> ohhh
[09:26:23 CST(-0600)] <colinclark> I think that you could probably tweak generateMultiPartContent() so that it was a little shorter next time
[09:26:40 CST(-0600)] <colinclark> concatting everything together in one, many-line statement
[09:26:53 CST(-0600)] <mlam> ok
[09:27:07 CST(-0600)] <colinclark> But I think in the spirit of code freeze, we can leave it until 1.4
[09:33:23 CST(-0600)] <mlam> colinclark: for FLUID-3937 (file cap size for FF 3.6) , we would have to perform a FF 3.6 browser check to determine which file cap size to use: The queueSetting option vs. the hardcoded FF 3.6 cap? I was thinking of the start() function within the HTML5 remote.
[09:34:12 CST(-0600)] <colinclark> I think start() is too late, perhaps
[09:34:30 CST(-0600)] <colinclark> Really, I think we want to prevent the file from being added to the queue if it's true
[09:34:40 CST(-0600)] <colinclark> too large, i mean
[09:35:10 CST(-0600)] <colinclark> mlam: How large was the file you used to crash FF 3.6?
[09:35:33 CST(-0600)] <colinclark> I just did 1.75 gigs and it was really slow (due to getBinaryData() blocking) and it ate RAM, but it never crashed
[09:36:11 CST(-0600)] <mlam> wow, I remember a file being 700MB crashing my browser
[09:36:16 CST(-0600)] <mlam> maybe i had too many apps open at the time
[09:36:19 CST(-0600)] <colinclark> interesting
[09:36:33 CST(-0600)] <mlam> I was trying to upload an ISO file.
[09:37:23 CST(-0600)] <mlam> This cap is tough because a limitation also depends on the integrators hardware capabilities
[09:37:39 CST(-0600)] <colinclark> The user's hardware, even more importantly
[09:37:45 CST(-0600)] <colinclark> even the integrator most likely has no clue
[09:38:01 CST(-0600)] <colinclark> so it needs to be set small enough to not be a risk at any time
[09:38:31 CST(-0600)] <mlam> What size do you suggest? 300MB?
[09:38:40 CST(-0600)] <colinclark> maybe even 100 Mb
[09:39:06 CST(-0600)] <colinclark> Certainly that's more than enough for, say, a big image or small video
[09:39:52 CST(-0600)] <mlam> yah, i agree
[10:57:42 CST(-0600)] <jessm> fluid-everyone wiki is up
[10:57:49 CST(-0600)] <Justin_o> jessm: thanks
[11:07:31 CST(-0600)] <anastasiac> jessm, Justin_o has asked me to help finish up the testing, and he suggested I check in with you regarding what, if any, testing tasks you're planning to work on so that I can pick something else
[11:08:41 CST(-0600)] <jessm> anastasiac: you can certainly pick off the simple texts from my list
[11:08:59 CST(-0600)] <jessm> anastasiac: i ran into a bug on rich text and need to log it – and have a CFI deliverable that just came up
[11:09:18 CST(-0600)] <anastasiac> jessm, I do have some windows VMs - were you planning to do any windows testing?
[11:09:35 CST(-0600)] <jessm> anastasiac: i can only do ff and safari for mac os
[11:09:59 CST(-0600)] <anastasiac> ok, I'll try the windows work, then, jessm - if my Vm turns out to be impossibly slow, I might come back to you (wink)
[11:31:35 CST(-0600)] <anastasiac> Justin_o, FYI on that UIOptions ToC issue: http://issues.fluidproject.org/browse/FLUID-3965
[11:33:04 CST(-0600)] <Justin_o> anastasiac: thanks
[12:02:58 CST(-0600)] <heidi> justin_o is there already a jira for the render button not giving any screen reader feedback
[12:03:08 CST(-0600)] <heidi> on renderer demo
[12:03:16 CST(-0600)] <heidi> i can check
[12:18:04 CST(-0600)] <heidi> jessm we missed the fss demo instructions - they're empty
[12:19:38 CST(-0600)] <jessm> ?
[12:23:15 CST(-0600)] <heidi> justin_o i noticed we missed the instruction text for FSS demos, should i reopen http://issues.fluidproject.org/browse/FLUID-3283 ?
[12:24:49 CST(-0600)] <jessm> heidi: did you mean to ping me about FSS or Justin_o ?
[12:25:07 CST(-0600)] <heidi> jessm just letting you know, we missed the fss demos
[12:25:43 CST(-0600)] <jessm> heidi: right
[12:26:03 CST(-0600)] <jessm> i think they can get done with 1.4 but i'll leave the deciding to the decider – the king
[12:26:53 CST(-0600)] <heidi> yeah let him know
[12:27:23 CST(-0600)] <jessm> heidi: you let him know? or i should?
[12:27:50 CST(-0600)] <heidi> oops sorry, i let him know
[13:32:08 CST(-0600)] <Justin_o> heidi, jessm: i think we should probably wait till 1.4
[13:32:10 CST(-0600)] <Bosmon> Hi there heidi - could explain the thinking between trying to make our markup conform to the XHTML strict doctype?
[13:32:57 CST(-0600)] <heidi> bosmon hey, you can use transitional as well.
[13:33:41 CST(-0600)] <Justin_o> heidi: I think you filed the jiras because we were using strict instead of transitional.. is that correct?
[13:33:42 CST(-0600)] <Bosmon> I haven't looked at the errors for that demo in detail yet, but I suspect it will be impossible to make them go away....
[13:34:30 CST(-0600)] <Bosmon> There are some significant issues with the XHTML spec, which in the usual way of the W3C committee they didn't really think through properly and then just abandoned in an incomplete state
[13:35:25 CST(-0600)] <Bosmon> Let me look at this particular demo....
[13:36:14 CST(-0600)] <Bosmon> Hum... looks like the W3C validator is down (smile)
[13:36:29 CST(-0600)] <heidi> bosmon here's the validator link for the renderer: http://validator.w3.org/check?uri=http%3A%2F%2Fbuild.fluidproject.org%2Finfusion%2Fdemos%2Frenderer%2Fhtml%2Frenderer.html&amp;charset=%28detect+automatically%29&amp;doctype=Inline&amp;group=0
[13:36:31 CST(-0600)] <Bosmon> Perhaps we should get in touch with their system administrator
[13:36:39 CST(-0600)] <heidi> works for me!
[13:37:54 CST(-0600)] <Bosmon> Ok
[13:38:00 CST(-0600)] <Bosmon> Looks like the majority of these errors are genuine
[13:43:14 CST(-0600)] <heidi> bosmon switching from strict to transitional might get rid of some
[13:54:06 CST(-0600)] <heidi> mlam is it a known issue that there's an IE error loading uploader demo? "flash9Container" is null or not an object
[13:55:23 CST(-0600)] <heidi> it makes it not work. i'm guessing you and colinclark know this tho
[14:09:52 CST(-0600)] <colinclark> heidi: What platform?
[14:09:56 CST(-0600)] <colinclark> When does it happen?
[14:10:01 CST(-0600)] <colinclark> Which version of Flash?
[14:12:01 CST(-0600)] <heidi> colinclark: win xp, IE8, i think flash 9 - dble checking
[14:12:22 CST(-0600)] <colinclark> Thanks. Adobe has a site that will report the version of Flash you're running
[14:12:23 CST(-0600)] <heidi> yeah 9
[14:12:25 CST(-0600)] <colinclark> need the exact number
[14:12:35 CST(-0600)] <heidi> know the url off hand?
[14:13:08 CST(-0600)] <colinclark> no
[14:13:11 CST(-0600)] <colinclark> google for it
[14:13:14 CST(-0600)] <colinclark> it's easy to find
[14:13:53 CST(-0600)] <justin_o> heidi: just google for flash player version.. and you should be able to find it.. alternatively you can just go to any page with a flash move and right click on it and check the version number that way
[14:14:01 CST(-0600)] <heidi> k i have 9,0,115,0
[14:14:38 CST(-0600)] <heidi> ^colinclark
[14:14:43 CST(-0600)] <colinclark> thanks!
[14:14:58 CST(-0600)] <heidi> colin i'll make a jira?
[14:15:24 CST(-0600)] <colinclark> Sure
[14:18:22 CST(-0600)] <Bosmon> heidi: I think actually the only genuine error in the markup is on line 60 of the renderer demo
[14:18:33 CST(-0600)] <Bosmon> There is a "for" attribute put on a <td> element I guess just by cut n paste
[14:18:42 CST(-0600)] <Bosmon> The rest should be resolved by just applying the transitional doctype
[14:18:47 CST(-0600)] <heidi> great
[14:21:20 CST(-0600)] <heidi> colinclark : FLUID-3970
[14:27:38 CST(-0600)] <colinclark> thanks heidi
[14:34:59 CST(-0600)] <justin_o> Bosmon: it seems that we missed including the fluidRequest.js file on some pages for the tableOfContents component. What's strange though is that the pages weren't throwing any errors
[14:35:15 CST(-0600)] <justin_o> i think only IE6 threw an error
[14:35:33 CST(-0600)] <justin_o> the other browsers were just failing silently
[14:42:24 CST(-0600)] <colinclark> michelled: Here's the first Uploader patch to review...
[14:42:25 CST(-0600)] <colinclark> http://issues.fluidproject.org/browse/FLUID-3952
[14:42:35 CST(-0600)] <colinclark> This one is difficult to test, but I can show it to you on my machine
[14:42:46 CST(-0600)] <colinclark> Unless you happen to be running a PHP-ified version of Apache on your Mac
[14:42:53 CST(-0600)] <michelled> ok, I'll look at the code and you can show me the working app
[14:42:56 CST(-0600)] <colinclark> Luckily it's a super easy code review, michelled (smile)
[14:46:51 CST(-0600)] <colinclark> michelled: Here's the second patch http://issues.fluidproject.org/browse/FLUID-3937
[14:46:56 CST(-0600)] <colinclark> This one is a little more involved
[14:47:12 CST(-0600)] <colinclark> You'll see that we moved a bunch of logic related to queue and file size limits from start() to addFiles()
[14:47:19 CST(-0600)] <colinclark> meaning, we offer a somewhat improved user experience
[14:47:48 CST(-0600)] <colinclark> and added an extra option that will allow implementers to independently set a file size limit for browsers that use File.getAsBinary() (e.g. FF3.6)
[14:47:53 CST(-0600)] <colinclark> It's set by default at 100 MB
[14:48:27 CST(-0600)] <michelled> looking at it now
[14:52:52 CST(-0600)] <jessm> justin_o: king, I created a jira – it might suck and therefore need re-working: http://issues.fluidproject.org/browse/FLUID-3971
[14:53:16 CST(-0600)] <colinclark> jessm: I'm distracting the king at the moment
[14:53:17 CST(-0600)] <colinclark> bu
[14:53:20 CST(-0600)] <colinclark> but won't be long
[14:53:34 CST(-0600)] <jessm> colinclark: i don't think my need is immediate – more chronic!
[15:02:14 CST(-0600)] <justin_o> jessm: i think that's fine
[15:02:24 CST(-0600)] <justin_o> it tells you how to reproduce
[15:10:53 CST(-0600)] <colinclark> mlam: Have you had a chance to do any more Flash 9 testing?
[15:10:53 CST(-0600)] <colinclark> C
[15:11:02 CST(-0600)] <colinclark> Can you recreate heidi's issue?
[15:11:08 CST(-0600)] <mlam> I was just testing around in 10
[15:11:11 CST(-0600)] <mlam> i'll do the 9 now.
[15:15:45 CST(-0600)] <jessm> justin_o: two questions
[15:15:59 CST(-0600)] <jessm> 1. how do i know what priority to give a JIRA i create during this testing phase?
[15:16:14 CST(-0600)] <jessm> 2. how/when do we decide what needs to be completed before release?
[15:16:16 CST(-0600)] <justin_o> jessm: if you're not sure you can talk about it here
[15:16:36 CST(-0600)] <justin_o> jessm: for question 2 you mean for testing?
[15:16:41 CST(-0600)] <jessm> justin_o: this is listed as Major: http://issues.fluidproject.org/browse/FLUID-3606
[15:16:51 CST(-0600)] <jessm> i mean for deciding it must be fixed before release
[15:17:20 CST(-0600)] <justin_o> jessm: we will only fix things that are blockers or that are critical and we think will be easy to retest
[15:18:02 CST(-0600)] <jessm> ok, is 3606 a major?
[15:18:18 CST(-0600)] <mlam> colinclark: i can replicate in win XP, IE8, Flash 9
[15:18:25 CST(-0600)] <justin_o> jessm: that one could probably be made to be a higher priority... I wouldn't say it's a blocker because of the status of the richtext inline edit component.. it's sneak peek i believe
[15:18:34 CST(-0600)] <jessm> i guess it is a sneak peak component
[15:18:39 CST(-0600)] <jessm> yes
[15:18:43 CST(-0600)] <justin_o> yep
[15:18:53 CST(-0600)] <jessm> ok, i think i've got the process down
[15:19:00 CST(-0600)] <jessm> i'm happy to leave it or else defer it
[15:19:22 CST(-0600)] <justin_o> jessm: i think we can leave it for now... maybe make it critical, but i don't think we will get to it for 1.3
[15:19:33 CST(-0600)] <jessm> roger taht
[15:19:50 CST(-0600)] <justin_o> jessm: by the way i'll be leaving in about 10minutes and won't be back till the new year... did you have anything else you might need from me before then
[15:19:57 CST(-0600)] <mlam> colinclark: it's a line in the Flash 9 support file. It's strange because we're just adding a style to the container. The error is:
[15:19:57 CST(-0600)] <mlam> Message: 'flash9Container' is null or not an object
[15:19:57 CST(-0600)] <mlam> Line: 29
[15:19:57 CST(-0600)] <mlam> Char: 9
[15:19:58 CST(-0600)] <justin_o> i'll probably be online a bit later tonight
[15:20:14 CST(-0600)] <colinclark> mlam: It's clearly a real bug
[15:20:17 CST(-0600)] <jessm> justin_o: not I – I hope you and Colin chatted and passed the reindeer reigns?
[15:21:01 CST(-0600)] <justin_o> jessm: yes.. he's in charge of the sleigh now
[15:21:20 CST(-0600)] <jessm> justin_o: roger that
[15:24:48 CST(-0600)] <colinclark> fluid-everyone: The two Uploader blockers have been fixed. We're ready to start QA testing of Uploader on non-IE browsers.
[15:25:01 CST(-0600)] <colinclark> I'll let you know shortly when we're ready to start on IE as well
[15:28:20 CST(-0600)] <justin_o> fluid-everyone: will rebuild the daily sites now
[15:32:26 CST(-0600)] <Bosmon> heidi, justin_o: I made a patch for FLUID-3957.... is this a release issue or post-release?
[15:34:24 CST(-0600)] <justin_o> fluid-everyone: everything should be rebuilt now... uploader testing is good to go
[15:34:34 CST(-0600)] <colinclark> Thanks, justin_o
[15:34:47 CST(-0600)] <heidi> awesome bosmon
[15:39:55 CST(-0600)] <justin_o> Bosmon: I think it will be a post release issue... colinclark is assuming my duties while i'm off on crusade (also know as holiday)
[15:40:19 CST(-0600)] <colinclark> lol
[15:40:32 CST(-0600)] <colinclark> The King is going to his holiday villa
[15:40:34 CST(-0600)] <colinclark> estate?
[15:41:27 CST(-0600)] <heidi> justin_o happy holidays!
[15:41:33 CST(-0600)] <colinclark> Bosmon: Gimme one sec to familiarize myself with your JIRA
[15:41:37 CST(-0600)] <justin_o> heidi: thanks.. you too
[15:41:40 CST(-0600)] <colinclark> it's the validation issue, right?
[15:45:59 CST(-0600)] <justin_o> fluid-everyone: happy holidays everyone, sorry i won't be around to finish helping with the release but good luck and thanks to everyone for all the help with it
[15:46:52 CST(-0600)] <colinclark> Bosmon, heidi: I marked FLUID-3957 as fix for 1.4
[15:46:58 CST(-0600)] <colinclark> Thanks for the patch
[15:47:08 CST(-0600)] <colinclark> As soon as code freeze is lifted, you can apply it
[16:06:43 CST(-0600)] <colinclark> mlam: The Flash 9 issue is happening upon instantiation of SWFUpload
[16:07:36 CST(-0600)] <mlam> in the engine function?
[16:07:39 CST(-0600)] <colinclark> "Could not find the placeholder element"
[16:07:46 CST(-0600)] <colinclark> The classic SWFUpload error
[16:07:55 CST(-0600)] <colinclark> The markup isn't getting initialized correctly
[16:09:34 CST(-0600)] <colinclark> button_placeholder_id isn't getting set correctly
[16:11:19 CST(-0600)] <mlam> this must be something we introduced?
[16:37:47 CST(-0600)] <colinclark> Bosmon, mlam, jessm: Need your help
[16:37:55 CST(-0600)] <mlam> sure
[16:37:58 CST(-0600)] <jessm> yep
[16:37:58 CST(-0600)] <colinclark> Heidi reported a bug in our Flash 9 support for Uploader
[16:38:07 CST(-0600)] <colinclark> In short, Flash 9 doesn't work, at all.
[16:38:21 CST(-0600)] <colinclark> Now, our support for Flash 9 is now officially deprecated
[16:38:35 CST(-0600)] <colinclark> so, one could argue that this isn't a blocker
[16:38:48 CST(-0600)] <colinclark> but it is a clear and simple regression in our code (my bug) when we split Flash 9 support out from the rest
[16:38:50 CST(-0600)] <colinclark> http://issues.fluidproject.org/browse/FLUID-3970
[16:38:56 CST(-0600)] <colinclark> I've debugged it and created a patch
[16:39:17 CST(-0600)] <colinclark> This code is completely separate from the HTML 5 support, so it's quite isolated
[16:39:29 CST(-0600)] <colinclark> So, here's what I need:
[16:39:34 CST(-0600)] <colinclark> 1. Shall we go ahead and fix it?
[16:39:42 CST(-0600)] <colinclark> 2. Bosmon and mlam, can you give it a review if so?
[16:40:08 CST(-0600)] <colinclark> I've tested the patch in both Flash 9 and Flash 10 on IE, as well as (just in case) on FF 3.6 using the HTML 5 strategy
[16:40:27 CST(-0600)] <mlam> I would go for the fix and I can help test it out
[16:40:37 CST(-0600)] <colinclark> This is one of those "conflict of kingly interest" things where advice is appreciated (wink)
[16:40:44 CST(-0600)] <colinclark> thanks, mlam
[16:40:49 CST(-0600)] <colinclark> jessm and Bosmon?
[16:41:43 CST(-0600)] <jessm> colinclark: can you roll it back if it causes undue hurt?
[16:42:06 CST(-0600)] <colinclark> jessm: Yep
[16:42:19 CST(-0600)] <jessm> colinclark so it's like sprinkles on uploader – i say go for it
[16:42:25 CST(-0600)] <Bosmon> hi
[16:42:32 CST(-0600)] <colinclark> It's like non-error sprinkles on Uploader
[16:42:55 CST(-0600)] <colinclark> Bosmon: Any thoughts?
[16:43:26 CST(-0600)] <Bosmon> Looking at the patch now
[16:43:49 CST(-0600)] <colinclark> thanks
[16:43:52 CST(-0600)] <Bosmon> It looks pretty harmless, other than some peculiar line wrapping at the beginning (tongue)
[16:44:08 CST(-0600)] <Bosmon> Looks sort of like what Eclipse would do to Java back in 2001 (tongue)
[16:44:49 CST(-0600)] <colinclark> I can't imagine it's any more peculiar than some of the line wrapping I've seen elsewhere (wink)
[16:44:56 CST(-0600)] <Bosmon> (smile)
[16:45:03 CST(-0600)] <colinclark> Let me double check that it passes Crockford
[16:45:11 CST(-0600)] <colinclark> in which case, we can agree to disagree (wink)
[16:45:16 CST(-0600)] <Bosmon> Can you talk is quickly through why this patch changes what it changes?
[16:45:31 CST(-0600)] <colinclark> Bosmon: Sure
[16:45:44 CST(-0600)] <Bosmon> The changes look all local
[16:45:59 CST(-0600)] <Bosmon> And per the discussion before, it looks like knowing the id of the flash button is somehow crucial
[16:46:18 CST(-0600)] <colinclark> Unfortunately SWFUpload is just horribly evil
[16:46:36 CST(-0600)] <colinclark> 1. We were using the wrong nickname to grab styles... I had done a refactoring where the styles option moved and I didn't update the demands block
[16:46:44 CST(-0600)] <Bosmon> ah yes
[16:46:57 CST(-0600)] <colinclark> 2. Even in Flash 9, SWFUpload demands to have an ID on an element that it will replace with the Flash movie
[16:47:16 CST(-0600)] <Bosmon> Just to have one at all, or to also know what it is?
[16:47:16 CST(-0600)] <colinclark> And I had erroneously remove that piece of logic from the Flash 9 implementation
[16:47:21 CST(-0600)] <colinclark> reasoning at the time that it wasn't necessary
[16:47:42 CST(-0600)] <colinclark> Bosmon: The ID has to be there, and it needs to know it ahead of time
[16:48:20 CST(-0600)] <colinclark> So, my patch here just moves that ID assignment into
[16:48:25 CST(-0600)] <colinclark> "general" code
[16:48:34 CST(-0600)] <colinclark> i.e. into code that's shared by both Flash 9 and 10
[16:48:48 CST(-0600)] <Bosmon> ok
[16:49:20 CST(-0600)] <Bosmon> I guess I'm not sure that "options.styles" belongs any better on a thing called a "strategy" than on a thing called an "engine" but I guess that stuff is still pending further refactoring in the next release
[16:49:51 CST(-0600)] <colinclark> Bosmon: Well, in this case I didn't actually move the location of "options.styles"
[16:49:58 CST(-0600)] <colinclark> I simply corrected an incorrect demands block
[16:50:05 CST(-0600)] <Bosmon> ah, it was never right?
[16:50:07 CST(-0600)] <colinclark> yes
[16:50:09 CST(-0600)] <colinclark> exactly
[16:50:10 CST(-0600)] <Bosmon> ok
[16:50:12 CST(-0600)] <colinclark> blatant bugginess
[16:50:36 CST(-0600)] <colinclark> The reason I've got it on the strategy is that it's really the only part of "Flash-ness" that an ordinary user ever need interact with
[16:50:59 CST(-0600)] <colinclark> the existence of any of this other stuff, including the horrendously named "engine" is now really irrelevant to anyone who isn't us
[16:51:04 CST(-0600)] <Bosmon> I guess as we get more and more ambitious with IoC trees we will have to start reviewing our policy on nicknames and their uses in particular scopes
[16:51:09 CST(-0600)] <colinclark> yes
[16:51:11 CST(-0600)] <colinclark> that is true
[16:51:24 CST(-0600)] <Bosmon> I'm pretty sure that the current nickname resolution system is inadequate
[16:52:10 CST(-0600)] <Bosmon> But I guess we will need to gather experience "in the field" a bit more
[16:52:20 CST(-0600)] <colinclark> Makes sense to me
[16:52:25 CST(-0600)] <Bosmon> CollectionSpace will be the front-runner, being currently the largest IoC tree yet in existence
[16:52:40 CST(-0600)] <Bosmon> I had an idea for sort of "firebreaks" in the tree that would form barriers to resolution
[16:52:56 CST(-0600)] <Bosmon> Anyway
[16:53:01 CST(-0600)] <Bosmon> I think this patch looks good
[16:53:13 CST(-0600)] <Bosmon> Assuming it does what it seems it is meant to, I'm happy to sign it off for review
[16:58:02 CST(-0600)] <colinclark> mlam is still doing some testing
[16:58:17 CST(-0600)] <colinclark> He is finding other errors
[16:58:21 CST(-0600)] <colinclark> unrelated to initialization
[16:58:26 CST(-0600)] <colinclark> I can't reproduce
[16:58:33 CST(-0600)] <colinclark> so I'm tempted to commit it anyway
[16:58:57 CST(-0600)] <Bosmon> I guess Uploader as a whole is being held back from QA so far?
[16:59:41 CST(-0600)] <colinclark> Bosmon: Only IE
[16:59:47 CST(-0600)] <colinclark> Which is our only Flash-supported environment
[16:59:55 CST(-0600)] <colinclark> mlam just confirmed that Flash 10 support is just fine
[17:00:02 CST(-0600)] <colinclark> so I'm going to suggest we go for it, if you all agree
[17:01:09 CST(-0600)] <colinclark> mlam: what do you think?
[17:01:18 CST(-0600)] <mlam> I say we go for it. It could be an environment setting on my VM, and plus we can have heidi reconfirm for us tomorrow
[17:01:42 CST(-0600)] <colinclark> ok
[17:01:43 CST(-0600)] <colinclark> sounds great
[17:01:47 CST(-0600)] <colinclark> i'll commit and rebuild the daily
[17:01:50 CST(-0600)] <Bosmon> We don't support the Flash uploader in FF?
[17:01:50 CST(-0600)] <mlam> ok
[17:02:29 CST(-0600)] <colinclark> We only officially support Flash on IE
[17:02:46 CST(-0600)] <colinclark> On Firefox, if you're using an older browser (like FF3 or 2), you'll get the Flash version and it'll probably work nicely
[17:02:55 CST(-0600)] <colinclark> but neither of those are A-Grade anymore
[17:03:00 CST(-0600)] <colinclark> and we wanted to reduce our testing surface
[17:03:11 CST(-0600)] <colinclark> Uploader has historically been the single most complex thing to test
[17:03:21 CST(-0600)] <colinclark> having to switch between versions of Flash, etc.
[17:03:24 CST(-0600)] <Bosmon> So HTML5 is the only supported option, on those platforms where it works at all?
[17:03:35 CST(-0600)] <colinclark> The only "officially supported" option
[17:03:38 CST(-0600)] <Bosmon> ok
[17:04:00 CST(-0600)] <colinclark> An implementer could viably remove the HTML5 file and just use Flash in modern browsers
[17:04:05 CST(-0600)] <colinclark> but we strongly recommend they don't
[17:04:14 CST(-0600)] <colinclark> since Flash is horrendously inaccessible on all of those browsers
[17:05:46 CST(-0600)] <colinclark> Bosmon, mlam: I'm rebuilding the daily again
[17:05:58 CST(-0600)] <Bosmon> I guess our ARIA-labelling configuration is independent of that decision...
[17:06:01 CST(-0600)] <colinclark> mlam: If you can, I'd be curious for you to try your IE against it in a few minutes
[17:06:15 CST(-0600)] <Bosmon> Is there any likelihood NVDA is coming to the Mac?
[17:06:26 CST(-0600)] <Bosmon> I guess i don't know much about Mac accessibility
[17:06:35 CST(-0600)] <Bosmon> There's some kind of OS built-in screenreader that we test with?
[17:07:25 CST(-0600)] <colinclark> Bosmon: For Uploader, ARIA is added on all browsers, even if they don't support it
[17:07:38 CST(-0600)] <mlam> I've upgraded my Flash 9 version from 9.016 to 9.0.277 and the patch works swimmingly
[17:07:49 CST(-0600)] <colinclark> but again, a more clever demands block could probably turn it off in IE < 8 if people felt it necessary
[17:07:54 CST(-0600)] <colinclark> mlam: thanks!
[17:07:57 CST(-0600)] <mlam> anytime
[17:08:04 CST(-0600)] <colinclark> Bosmon: NVDA will probably never come to the Mac
[17:08:10 CST(-0600)] <colinclark> the AT APIs are a fair bit different
[17:08:21 CST(-0600)] <colinclark> and Apple has a built-in screenreader called VoiceOver
[17:08:23 CST(-0600)] <colinclark> it is interesting
[17:08:30 CST(-0600)] <colinclark> relatively good, though a bit behind the curve
[17:08:33 CST(-0600)] <Bosmon> And what is its ARIA support like
[17:08:46 CST(-0600)] <Bosmon> Does it announce the uploader reasonably correctly?
[17:08:54 CST(-0600)] <colinclark> quite excellent user experience--they designed it to be easy to collaborate between sighted and non-sighted users, for example
[17:08:57 CST(-0600)] <colinclark> Bosmon: I haven't tested it
[17:09:06 CST(-0600)] <colinclark> We don't officially support VoiceOver at the moment
[17:09:17 CST(-0600)] <colinclark> I think we should at some point, but our focus has been on open source ATs as much as possible
[17:09:25 CST(-0600)] <colinclark> We never quite put together a policy on AT testing
[17:09:26 CST(-0600)] <Bosmon> And there are none of those on the Mac?
[17:09:34 CST(-0600)] <colinclark> Bosmon: No
[17:09:50 CST(-0600)] <colinclark> Apple's screen reader is quite good, so I think no one has been very motivated to port something
[17:10:12 CST(-0600)] <colinclark> ARIA support is still in progress with VoiceOver...heidi does a fair bit of testing with it and finds gaps here or there
[17:10:24 CST(-0600)] <colinclark> but it's getting better with each new release
[17:10:31 CST(-0600)] <Bosmon> I guess we don't need it to support MUCH
[17:10:38 CST(-0600)] <Bosmon> aria-label and live region would do to start with
[17:10:43 CST(-0600)] <colinclark> I will try it in a sec
[17:11:07 CST(-0600)] <Bosmon> VoiceOver is free to users of the OS?
[17:12:18 CST(-0600)] <colinclark> Bosmon: Yes
[17:12:37 CST(-0600)] <Bosmon> That's cool, at least
[17:12:42 CST(-0600)] <colinclark> quite