Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 52 Next »

[01:02:05 EST(-0500)] * famicom (n=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
[03:46:05 EST(-0500)] * famicom_ (n=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
[05:27:59 EST(-0500)] * famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
[08:20:16 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[09:03:13 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[09:09:41 EST(-0500)] <Justin_o> jessm, Bosmon: are you able to send e-mails to the fluid-work?
[09:10:06 EST(-0500)] <Justin_o> mine keep getting rejected
[09:10:17 EST(-0500)] <jessm> lemme try
[09:10:23 EST(-0500)] <Justin_o> thanks
[09:11:50 EST(-0500)] <jessm> bounced
[09:11:55 EST(-0500)] * athena7 (n=athena7@99.164.85.168) has joined #fluid-work
[09:11:58 EST(-0500)] <jessm> Justin_o: can you send your bounce to Nakul?
[09:12:11 EST(-0500)] <Justin_o> sure will do thanks for checking
[09:12:12 EST(-0500)] <jessm> and let him know it's bouncing for others as well
[09:12:20 EST(-0500)] <Justin_o> for sure
[09:35:49 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:55:11 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:02:23 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:23:07 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:27:08 EST(-0500)] <colinclark> Justin_o: So it's bug parade week, eh?
[10:29:06 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[10:30:28 EST(-0500)] <colinclark> Justin_o: Remind me of the process for bug parade-related commits?
[10:32:18 EST(-0500)] <Justin_o> colinclark: Hello, the gist of the process is that commits are only allowed against jiras which are in the bug parade list
[10:32:45 EST(-0500)] <Justin_o> since there is an issue with the mailing list currently you can view the list of bug parade issues in this jira filter
[10:32:46 EST(-0500)] <Justin_o> http://issues.fluidproject.org/secure/IssueNavigator.jspa?mode=hide&amp;requestId=10129
[10:35:59 EST(-0500)] <anastasiac> Justin_o, the explanation of committing during Bug Parade at http://wiki.fluidproject.org/display/fluid/Coding+and+Commit+Standards says that commits must go through a review before the issue is closed. Who should do the reivew? Should we be emailing the list or asking in the channel for a tech review of the code changes? Or would you review them yourself for functinality?
[10:37:36 EST(-0500)] <Justin_o> good question anastasiac... and you are right on all account really. The code itself should be reviewed by another developer and marked as such on the jira. I will also test it where need be to ensure functionality before closing it.
[10:37:58 EST(-0500)] <colinclark> anastasiac: Review requests on list or in the channel seem reasonable.
[10:38:05 EST(-0500)] <colinclark> Either is fine.
[10:40:27 EST(-0500)] <Justin_o> anastasiac: i have updated the wiki about needing code review and testing
[11:04:28 EST(-0500)] <Justin_o> the fluid-work mailing list seems to be working again
[11:33:13 EST(-0500)] <anastasiac> Justin_o, the uPortal community has been asking us to upgrade jQuery UI. Can we put FLUID-1922 on the bug parade, to ensure that this issue is addressed for 0.6?
[11:35:55 EST(-0500)] <Justin_o> okay i'll add it to the bug parade is this something that should be done before the other bugs...
[11:36:12 EST(-0500)] <Justin_o> are looked at... meaning will it have affects on other possible fixes
[11:43:04 EST(-0500)] <athena7> anastasiac: i think it would make things a little easier because we could bundle 1.6 w/ 3.1.0 rather that adding it in a dot release, but it's by no means a requirement
[11:43:14 EST(-0500)] <athena7> if it makes life hard for you guys, it's really OK
[11:44:43 EST(-0500)] <anastasiac> Justin_o, that's a good point - the 'upgrade to 1.5.3' part of FLUID-1922 should probably be done before other things, just in case
[11:44:55 EST(-0500)] <anastasiac> but the 'test against 1.6' could be later
[11:45:07 EST(-0500)] <anastasiac> in fact, might be better later, after other bugs are fixed
[11:45:50 EST(-0500)] <Justin_o> okay
[11:46:10 EST(-0500)] <Justin_o> anastasiac: thanks... i'm going to bump 1922 up to a blocker then
[11:47:17 EST(-0500)] <anastasiac> athena7, we won't be actually upgrading to 1.6, since it's only at rc2, but we will be testing against their trunk
[11:47:24 EST(-0500)] <athena7> oh ok
[11:47:26 EST(-0500)] <athena7> that makes sense
[11:47:46 EST(-0500)] <Bosmon> (sad)
[11:47:52 EST(-0500)] <Bosmon> I have missed everything
[11:48:06 EST(-0500)] <colinclark> Bosmon: ?
[11:48:07 EST(-0500)] <anastasiac> Bosmon - what have you missed?
[11:48:25 EST(-0500)] <Bosmon> There are a zillion things I need to do this week that are not on the bug parade...
[11:48:29 EST(-0500)] <Bosmon> I thought it was next week (sad)
[11:48:49 EST(-0500)] <colinclark> athena7: So we'll do our best to qualify against 1.6 so all you'll have to do, once it's released, is drop the new version and run the build scripts.
[11:48:58 EST(-0500)] <colinclark> Bosmon: Yes, I've asked Justin_o to check in with you about that.
[11:49:22 EST(-0500)] <athena7> sounds pretty cool
[11:49:31 EST(-0500)] <colinclark> There are a couple of immediate things that should be added to the parade, particularly the issue of moving rich and dropdown -related code into InlineEdit.js.
[11:49:38 EST(-0500)] <Bosmon> ok, cool
[11:49:41 EST(-0500)] <Bosmon> THat was one thing
[11:49:45 EST(-0500)] <colinclark> We'll have to make a call about whether or not to back our your Pager changes.
[11:49:53 EST(-0500)] <colinclark> You'll have to talk to the King about where those fall.
[11:50:08 EST(-0500)] <colinclark> Bosmon: You've already got one bug parade blocker filed for the refresh() bug that athena7 discovered.
[11:50:12 EST(-0500)] <Bosmon> yes
[11:50:42 EST(-0500)] <colinclark> Not the end of the world if we have to back the Pager changes out, but you can also talk with Justin_o here about what would be involved in prepping it for release.
[11:50:45 EST(-0500)] <athena7> and i am watching it now!
[11:51:11 EST(-0500)] <colinclark> Justin_o: You were also going to file a blanket "improve test coverage" issue for the parade, too, right?
[11:51:36 EST(-0500)] <Justin_o> colinclark: yes, I have filed it already... let go find the jira number
[11:52:17 EST(-0500)] <Justin_o> http://issues.fluidproject.org/browse/FLUID-1939
[11:52:21 EST(-0500)] <colinclark> Wicked, thanks.
[11:52:29 EST(-0500)] <Justin_o> no problem
[11:54:28 EST(-0500)] <colinclark> King, I have an issue...
[11:54:34 EST(-0500)] <Justin_o> sure
[11:54:54 EST(-0500)] <colinclark> I was slightly hasty in resolving my "add progressive enhancement" JIRA on Friday.
[11:55:05 EST(-0500)] <colinclark> The bug is fixed, but there are a few last Ts to cross and Is to dot.
[11:55:38 EST(-0500)] <colinclark> I have a patch that cleans up the license files, includes a non-minified version of the swfobject.js library, and updates the build scripts to ensure any new files are included in the build.
[11:55:54 EST(-0500)] <colinclark> I will create a new JIRA issue for it momentarily and send it along to the channel.
[11:56:15 EST(-0500)] <colinclark> Then you can decide if you approve of me committing against it while trunk is so slushy.
[11:56:18 EST(-0500)] <colinclark> (smile)
[11:57:11 EST(-0500)] <Justin_o> sure... i'll check the jira... while you are doing that do you mind taking a look at FLUID-1940 i'm not sure if it is actually fixable or not
[11:57:19 EST(-0500)] <colinclark> Sure, no problem.
[11:57:30 EST(-0500)] <Justin_o> thanks
[12:01:00 EST(-0500)] <colinclark> Justin_o: FLUID-1940 should be fixable. Good catch!
[12:02:46 EST(-0500)] <Bosmon> I'm receiving an awful lot of "Facebook spam" this week
[12:02:55 EST(-0500)] <Bosmon> It looks like some critical number of people have uncovered me...
[12:02:55 EST(-0500)] <Justin_o> thanks...
[12:03:07 EST(-0500)] <colinclark> Bosmon: Jim Eng just recommended you as a Facebook friend to me. (tongue)
[12:03:09 EST(-0500)] <colinclark> Who knew you were really there lurking.
[12:03:18 EST(-0500)] <Bosmon> I am NOT really there (tongue)
[12:03:24 EST(-0500)] <colinclark> (smile)
[12:03:33 EST(-0500)] <colinclark> Justin_o: I can fix this as part of the bug parade if you want.
[12:03:41 EST(-0500)] <colinclark> Or someone can. It's really straightforward, I think.
[12:04:54 EST(-0500)] <Justin_o> colinclark: i'm in the process of some internal debate as to wether this should be in the bug parade or not
[12:04:55 EST(-0500)] <Bosmon> colinclark:
[12:05:00 EST(-0500)] <Bosmon> What ARE we going to do about FLUID-1616
[12:05:04 EST(-0500)] <Bosmon> (tongue)
[12:05:20 EST(-0500)] <colinclark> Lemme take a look.
[12:06:13 EST(-0500)] <anastasiac> the patch I created for FLUID-1616 simply renamed our 'selectable' to 'focusable'
[12:06:30 EST(-0500)] <Bosmon> Aha
[12:06:36 EST(-0500)] <Bosmon> It's a nasty name
[12:07:16 EST(-0500)] <colinclark> focusable?
[12:07:18 EST(-0500)] <colinclark> selectable?
[12:07:21 EST(-0500)] <anastasiac> yes, I remember we had some discussion, and at the time, couldn't come up with anything better
[12:07:29 EST(-0500)] <anastasiac> but we're certainly open to suggestions!
[12:07:42 EST(-0500)] <colinclark> Short-term, I think that's fine. I was sitting in the car the other day, brainstorming a real fix for this.
[12:07:44 EST(-0500)] <Bosmon> Perhaps we will simply have to give up on FLUID-539 and FLUID-861
[12:07:58 EST(-0500)] <Bosmon> They have come round for a few Bug Parades now
[12:08:11 EST(-0500)] <Bosmon> I mean, they are really serious
[12:08:21 EST(-0500)] <Bosmon> But I still can't think of any way of addressing them
[12:08:37 EST(-0500)] <colinclark> Ultimately jQuery needs namespaces for their plugins, and the UI strategy for doing this is insane. We can probably work something out so that our functions hang off a $().fluid.foo();
[12:08:48 EST(-0500)] <colinclark> Bosmon: Lemme remind myself of these issues.
[12:09:01 EST(-0500)] <Bosmon> You remember, the "tab black hole" issue
[12:09:02 EST(-0500)] <colinclark> They are clearly vintage based on their numbers.
[12:09:07 EST(-0500)] <Bosmon> Mainly on Firefoxes
[12:09:15 EST(-0500)] <Bosmon> We looked at it for a while when I was out there
[12:09:24 EST(-0500)] <colinclark> Ah yes
[12:09:34 EST(-0500)] <colinclark> Those are amazing issues.
[12:09:55 EST(-0500)] <Bosmon> We should probably try and find a way to escalate FLUID-861 to Mozilla
[12:10:04 EST(-0500)] <Bosmon> It looks like whatever they have done, 539 is gone "by itself"
[12:10:51 EST(-0500)] <colinclark> Bosmon: In FF3, you mean?
[12:11:06 EST(-0500)] <Bosmon> Yes
[12:11:18 EST(-0500)] <colinclark> Interesting.
[12:11:18 EST(-0500)] * hydee (n=hydee@bas10-ottawa23-1177650188.dsl.bell.ca) has joined #fluid-work
[12:11:25 EST(-0500)] <Bosmon> ok, yes, I like $().fluid.selectable
[12:11:54 EST(-0500)] <colinclark> Bosmon: Yes, exactly. Unless you find yourself with copious spare time, I think we're going to have to leave that particular approach for 0.8.
[12:12:14 EST(-0500)] <Bosmon> I can't think it would take long
[12:12:24 EST(-0500)] <Bosmon> And it is a Bug Parade issue
[12:12:38 EST(-0500)] <Justin_o> colinclark: i think for Fluid-1940 I'll leave it off for now until some of the other uploader bugs are cleared off the bug parade
[12:12:47 EST(-0500)] <colinclark> Bosmon: You don't have a lack of those, though. (wink)
[12:12:56 EST(-0500)] <Bosmon> I have some
[12:13:02 EST(-0500)] <Bosmon> I feel many of them are not actually resolvable (tongue)
[12:13:11 EST(-0500)] <colinclark> Talk through how you would implement this...
[12:13:29 EST(-0500)] <Bosmon> What would be hard about it?
[12:13:32 EST(-0500)] <colinclark> I'm just wondering whether anastasiac may have some time to implement it if you can guide her through the process a bit.
[12:13:47 EST(-0500)] <Bosmon> We would just write a slightly more bulky equivalent of the basic "fluid || {}" approach
[12:14:00 EST(-0500)] <colinclark> Bosmon: Ensuring correct scoping is key.
[12:14:05 EST(-0500)] * anastasiac is putting out a peptalk fire today
[12:14:13 EST(-0500)] <Bosmon> What do you mean?
[12:14:17 EST(-0500)] <Bosmon> JQuery has no sensible scoping
[12:14:22 EST(-0500)] <colinclark> Bosmon: (smile)
[12:14:25 EST(-0500)] <Bosmon> We could hardly make the situation worse over what it is now
[12:14:34 EST(-0500)] <Justin_o> colinclark: sorry don't remember if i mentioned this but I added FLUID-1942 to the bug parade
[12:14:50 EST(-0500)] <colinclark> At the moment, our code-like any plugin-expects that "this" points to the current jQuery instance.
[12:15:27 EST(-0500)] <colinclark> this will change if we hang our functions off a fluid object.
[12:15:31 EST(-0500)] <colinclark> no pun intended (wink)
[12:15:54 EST(-0500)] <colinclark> I suppose we could simply change that assumption. (smile)
[12:16:33 EST(-0500)] <colinclark> Bosmon: Go for it if you feel like you can tackle it.
[12:17:38 EST(-0500)] <Bosmon> Why will it change?
[12:17:44 EST(-0500)] <Bosmon> Well ok, it need not change
[12:17:51 EST(-0500)] <Bosmon> You're right that we have an option
[12:19:41 EST(-0500)] <colinclark> Bosmon: All bug parade issues need to go through a bit of code review before commit. I will be happy to review this one. (smile)
[12:20:59 EST(-0500)] <Bosmon> There are actually no references to "this" in our plugin
[12:21:01 EST(-0500)] <Bosmon> What a surprise (tongue)
[12:21:10 EST(-0500)] <Bosmon> Oh wait sorry
[12:21:13 EST(-0500)] <Bosmon> i hit the wrong key (tongue)
[12:21:26 EST(-0500)] <colinclark> Bosmon: There are!
[12:21:35 EST(-0500)] <colinclark> Fortunately, it is only at the top level.
[12:21:59 EST(-0500)] <colinclark> Any methods added to jQuery's prototype will reference this.
[12:22:03 EST(-0500)] <colinclark> "this"
[12:22:06 EST(-0500)] <colinclark> this
[12:27:47 EST(-0500)] <Bosmon> The word "prototype" just makes my head swim
[12:30:46 EST(-0500)] <colinclark> (smile)
[12:30:49 EST(-0500)] <Bosmon> Don't you think they will despise us, if we adopt a namespaced approach?
[12:31:56 EST(-0500)] <colinclark> Bosmon: I don't really know.
[12:32:01 EST(-0500)] <colinclark> I think it's something we really need.
[12:32:23 EST(-0500)] <colinclark> My sense is that our plugin will not be adopted wholesale and in its current form in ui.core.
[12:32:38 EST(-0500)] <Bosmon> Well, that is interesting
[12:32:41 EST(-0500)] <Bosmon> And somewhat exciting
[12:32:47 EST(-0500)] <colinclark> (smile)
[12:32:48 EST(-0500)] <Bosmon> What do you think is inhibiting its adoption?
[12:33:00 EST(-0500)] <Bosmon> Other than, of course, colliding head-on with the name of a now-existing plugin?
[12:33:00 EST(-0500)] <colinclark> Yeah, the tabindex code is now in ui.core.js
[12:33:08 EST(-0500)] <colinclark> As for inhibiting adoption, I'm not sure.
[12:33:10 EST(-0500)] <Bosmon> what?
[12:33:21 EST(-0500)] <colinclark> It's actually being picked up by a number of independent jQuery users.
[12:33:42 EST(-0500)] <colinclark> But, judging from comments on my blog post about it, the main barrier to adoption is lack of good documentation and sample code.
[12:33:46 EST(-0500)] <Bosmon> Does this mean we can abolish it?
[12:33:57 EST(-0500)] <colinclark> The tabindex code? Not yet, unfortunately.
[12:34:03 EST(-0500)] <colinclark> As far as I know, it won't be released until 1.7.
[12:34:07 EST(-0500)] <Bosmon> I see
[12:34:07 EST(-0500)] <colinclark> So we'll have to wait awhile.
[12:34:18 EST(-0500)] <Bosmon> Well, I guess this only enhances the pressure to namespace it
[12:34:20 EST(-0500)] <colinclark> Bosmon: As I think about this, our addition of a namespace has one major downside:
[12:34:24 EST(-0500)] <Bosmon> Since at that release, THAT will collide too
[12:34:28 EST(-0500)] <colinclark> how can we ensure backwards compatibility?
[12:34:46 EST(-0500)] <Bosmon> With what?
[12:34:46 EST(-0500)] <colinclark> We are essentially changing an API, and because UI has stolen our name, we have no recourse but to just do it.
[12:35:01 EST(-0500)] <Bosmon> With our own code?
[12:35:14 EST(-0500)] <Bosmon> How could we want to ensure backwards compatibility?
[12:35:27 EST(-0500)] <colinclark> Well, all code that used to call $("foo").selectable(...) will now have to change to call $("foo").fluid.selectable(...)
[12:35:36 EST(-0500)] <Bosmon> Yes
[12:35:39 EST(-0500)] <colinclark> Bosmon: Well, I guess that's my point.
[12:35:43 EST(-0500)] <Bosmon> How could we want backwards compatibility
[12:35:49 EST(-0500)] <Bosmon> Given that all code will break in any case
[12:35:49 EST(-0500)] <colinclark> We are forced to not want backwards compatibility.
[12:35:55 EST(-0500)] <Bosmon> Yes
[12:36:00 EST(-0500)] <colinclark> Ordinarily, we would never just change an API like this, on the fly.
[12:36:07 EST(-0500)] <Bosmon> Ordinarily not, no
[12:36:10 EST(-0500)] <colinclark> We'd at least deprecate the old method and keep it around for awhile.
[12:36:13 EST(-0500)] <colinclark> But in this case, we just can't.
[12:36:14 EST(-0500)] <colinclark> (sad)
[12:36:18 EST(-0500)] <Bosmon> But we have faced an Architectural Disaster (TM)
[12:36:23 EST(-0500)] <colinclark> Yes, exactly!
[12:37:37 EST(-0500)] <Bosmon> The Collapse of Civilization
[12:37:43 EST(-0500)] <colinclark> ha
[12:37:55 EST(-0500)] <colinclark> It's just proof of how jQuery plugins should have an option for using a namespace.
[12:38:01 EST(-0500)] <colinclark> Otherwise, people steal stuff.
[12:38:02 EST(-0500)] <colinclark> (wink)
[12:38:08 EST(-0500)] <Bosmon> OK
[12:38:14 EST(-0500)] <Bosmon> I will sit and think about this a little
[12:38:25 EST(-0500)] <colinclark> And $("foo").fluid("selectable") is just an intolerable solution. (tongue)
[12:38:36 EST(-0500)] <Bosmon> Yes, it is intolerable
[12:38:40 EST(-0500)] <Bosmon> We will refuse to tolerate it
[12:39:14 EST(-0500)] <Bosmon> Although I am becoming afraid again that a really good solution to this issue will rely on the Missing Javascript Feature....
[12:40:23 EST(-0500)] <Bosmon> I can think of a way of doing it with $("foo").fluid().selectable(stuff)
[12:40:27 EST(-0500)] <Bosmon> But that is not vastly better
[12:40:35 EST(-0500)] <colinclark> Bosmon: That's as far as I had gotten as well.
[12:40:37 EST(-0500)] <colinclark> (smile)
[12:40:39 EST(-0500)] <Bosmon> (smile)
[12:41:41 EST(-0500)] <Bosmon> Perhaps Javascript is not really Cool after all
[12:50:34 EST(-0500)] * ecochran (n=ecochran@adsl-70-137-176-52.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[12:58:42 EST(-0500)] <Bosmon> Well, do you have any other suggestions?
[13:16:32 EST(-0500)] <colinclark> Bosmon: I suppose we could resort to some sort of trickery, overriding the constructor and calling our own setup code at the end.
[13:19:56 EST(-0500)] <Bosmon> the constructor?
[13:20:08 EST(-0500)] <Bosmon> Which one?
[13:23:56 EST(-0500)] <colinclark> Bosmon: Sorry... jQuery's constructor.
[13:24:16 EST(-0500)] <colinclark> This is a terribly underhanded approach.
[13:26:13 EST(-0500)] <Bosmon> ouch
[13:26:33 EST(-0500)] <Bosmon> Do you really think we should do that?
[13:27:19 EST(-0500)] <colinclark> Bosmon: I'm not necessarily advocating for it, just exploring the space...
[13:27:33 EST(-0500)] <colinclark> Aside from a primeFluid() method or something, it may be our only option.
[13:32:06 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined #fluid-work
[13:33:15 EST(-0500)] <Bosmon> I suspect if we do anything that causes an extra construction for every jQuery construction, this would be unacceptable
[13:34:33 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[13:38:21 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[13:39:09 EST(-0500)] <Justin_o> I'll be adding two more jiras (numbers to come) to address the merging of dropdown and rich text inline edit into the component
[13:39:31 EST(-0500)] <Justin_o> we will need to set up appropriate demo pages to test on, as well
[13:40:09 EST(-0500)] <Bosmon> (18:34:34) Antranig: And there is a bit of an issue on making them testable
[13:40:09 EST(-0500)] <Bosmon> (18:34:45) Antranig: Which relates to where in our tree we put the underlying libraries
[13:40:09 EST(-0500)] <Bosmon> (18:34:51) Antranig: FCKEdit and TinyMCE etc.
[13:40:57 EST(-0500)] <Justin_o> Bosmon: thanks... I'll incorporate your comments into the jira
[13:45:57 EST(-0500)] <Justin_o> I have added FLUID-1944 and FLUID-1945 to the bug parade
[13:46:18 EST(-0500)] <Bosmon> Did anybody yet notice this function in jQuery.js?
[13:46:20 EST(-0500)] <Bosmon> // Evalulates a script in a global context
[13:46:20 EST(-0500)] <Bosmon> globalEval: function( data ) {
[13:46:27 EST(-0500)] <Bosmon> It appears to do exactly what we want...
[13:46:40 EST(-0500)] <Bosmon> Well, very nearly
[13:47:01 EST(-0500)] <Bosmon> I am just re-reading the Jquery source again to see if there is conceivably any solution to our problem...
[13:47:11 EST(-0500)] <Bosmon> But it seems there can't be
[13:47:17 EST(-0500)] <Bosmon> globalEval is still pretty interesting though
[13:54:38 EST(-0500)] <Justin_o> Bosmon: please let me know if you are still having trouble viewing the bug parade e-mail. If so, I'll attach a .txt version with the next update
[13:54:55 EST(-0500)] <Justin_o> i just sent out version 3 of the bug parade
[13:57:00 EST(-0500)] <Bosmon> Thanks, yes, it is completely unreadable (smile)
[13:58:03 EST(-0500)] <Justin_o> okay... i'll send add the .txt version...
[14:03:29 EST(-0500)] <Justin_o> Bosmon: I just sent out the .txt version of the bug parade... i hope that works.
[14:09:38 EST(-0500)] <Bosmon> Thanks
[14:23:41 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[14:24:22 EST(-0500)] <colinclark> Bosmon: I haven't seen globalEval before!
[14:24:30 EST(-0500)] <colinclark> I will have to look at its implementation.
[14:27:56 EST(-0500)] <Bosmon> Well, I guess we are going to have to bite the bullet somehow
[14:28:13 EST(-0500)] <Bosmon> $().fluid("selectable")?
[14:28:24 EST(-0500)] <Bosmon> $().fluid().selectable()?
[14:28:35 EST(-0500)] <Bosmon> $().fluid_selectable()?
[14:28:55 EST(-0500)] <Bosmon> We can go with $().focusable for now, but it doesn't help us with the general problem
[14:28:59 EST(-0500)] <Bosmon> That this is just going to happen again
[14:29:09 EST(-0500)] <colinclark> Bosmon: Yeah
[14:33:15 EST(-0500)] <colinclark> I'd rather change the API once and not several times...
[14:33:30 EST(-0500)] <colinclark> so .focusable() is probably short-sighted.
[14:33:47 EST(-0500)] <colinclark> .fluid-selectable() is one option.
[14:33:51 EST(-0500)] <colinclark> .fluid("selectable") is just dismal.
[14:34:05 EST(-0500)] <colinclark> .fluid().selectable() is a bit odd, but not tremendously bad.
[14:36:39 EST(-0500)] <ecochran> colinclark: working on 1936
[14:36:41 EST(-0500)] <Bosmon> fluid_selectable certainly involves little work
[14:36:48 EST(-0500)] <colinclark> So ecochran and I were just talking about an interesting potential browser bug related to Uploader.
[14:37:10 EST(-0500)] <colinclark> Bosmon: I prefer dashes to underscores. (tongue) But yes, I agree that it's the path of least resistance.
[14:37:33 EST(-0500)] <colinclark> ecochran: So you're saying that in order to get the click event on the Stop Upload Button once you've shown it, you need to mouse out first, and then click?
[14:37:43 EST(-0500)] <ecochran> yes, it's very odd
[14:38:01 EST(-0500)] <colinclark> So shouldn't we be able to see that behaviour even with the fact that currently clicking just causes an error?
[14:38:16 EST(-0500)] <ecochran> I'm still trying to figure out what's happening there, because in Uploader1 we were hiding and showing buttons all the time
[14:38:20 EST(-0500)] <ecochran> with out a problem
[14:38:53 EST(-0500)] <ecochran> yes, although there is another problem with the Stop Upload button in the current checking
[14:38:57 EST(-0500)] <ecochran> checkin
[14:39:02 EST(-0500)] <ecochran> it throws an error
[14:39:05 EST(-0500)] <Bosmon> colinclark: dashes are characters that would require quoting
[14:39:28 EST(-0500)] <colinclark> ecochran: Right, but that error is caused a result of the click event, doesn't it?
[14:39:35 EST(-0500)] <ecochran> yes
[14:39:39 EST(-0500)] <ecochran> which is interesting
[14:39:46 EST(-0500)] <colinclark> Bosmon: Ugh. Duh. Yes.
[14:40:08 EST(-0500)] <Justin_o> ecochran: i'm a little confused about what the behaviour your seeing is... is it different from the bug or the same
[14:40:17 EST(-0500)] <colinclark> ecochran: Let me play around here for a second and see if I can recreate it.
[14:40:17 EST(-0500)] <ecochran> let me look at build and see what's happening
[14:40:19 EST(-0500)] <Bosmon> colinclark: Our existing use of namespace is not all that great in our plugin anyway
[14:40:24 EST(-0500)] <Justin_o> by bug i meant the jira you mentioneed
[14:40:35 EST(-0500)] <Bosmon> For example, we have selectNext, selectPrevious, currentSelection
[14:40:43 EST(-0500)] <Bosmon> Which are all pretty implicitly tied to the fact this is a "selectable"
[14:40:57 EST(-0500)] <Bosmon> If we are going to have a 100% breaking change, we may as well do something rational about this too....
[14:42:19 EST(-0500)] <Justin_o> ecochran: by the way, which browser are you using
[14:42:31 EST(-0500)] <ecochran> I'm FF
[14:42:38 EST(-0500)] <colinclark> ecochran: I can't reproduce this, at least on FF2, even when I bind the click event to something that doesn't throw an error
[14:42:38 EST(-0500)] <Justin_o> 2 or 3
[14:42:39 EST(-0500)] <ecochran> the behavior seems inconsistent
[14:43:07 EST(-0500)] <ecochran> I don't seem to have to mouse off but at the same time the click doesn't seem to register
[14:43:09 EST(-0500)] <colinclark> Bosmon: I think that's reasonable, yes.
[14:43:12 EST(-0500)] <ecochran> all the time
[14:43:23 EST(-0500)] <colinclark> ecochran: 2 or 3?
[14:43:26 EST(-0500)] <ecochran> 3
[14:44:25 EST(-0500)] <colinclark> Interesting.
[14:44:35 EST(-0500)] <colinclark> I don't seem to be able to get my click event to work at all in FF3.
[14:44:39 EST(-0500)] <colinclark> Something odd is happening, for sure.
[14:44:56 EST(-0500)] <Justin_o> it worked the first time for me, but not after i looked at the error in firebug
[14:45:55 EST(-0500)] <ecochran> hmm, this could be another Firebug foo
[14:46:04 EST(-0500)] <ecochran> I get a lot of them
[14:46:14 EST(-0500)] <colinclark> Justin_o, ecochran: The button also doesn't seem to be in the tab order.
[14:46:19 EST(-0500)] <ecochran> I'm getting more events today than I was Friday
[14:46:24 EST(-0500)] <ecochran> it probably isn't
[14:46:25 EST(-0500)] <colinclark> Do you think it's possible that this is quirkiness related to buttons with no hrefs?
[14:46:38 EST(-0500)] <Justin_o> i too am not able to tab to it
[14:47:15 EST(-0500)] <ecochran> buttons don't have hrefs do they?
[14:47:57 EST(-0500)] <ecochran> the browse button isn't a real button, it's a <a> tag
[14:48:08 EST(-0500)] <ecochran> the Upload and Stop Upload are real buttons
[14:48:16 EST(-0500)] <ecochran> don't ask why... I don't remember
[14:48:22 EST(-0500)] <Justin_o> Okay i tried it in FF3 in vista, after it threw the first error i couldn't tab to it or get a click event
[14:48:29 EST(-0500)] <ecochran> I should have centered on one
[14:48:48 EST(-0500)] <colinclark> ecochran: Yes, of course. Sorry, I was thinking of links without hrefs.
[14:49:17 EST(-0500)] <colinclark> It seems to me that they should be in the tab order.
[14:49:21 EST(-0500)] <colinclark> Something very odd is happening.
[14:50:11 EST(-0500)] <ecochran> hold on, there may be some bad markup
[14:50:17 EST(-0500)] <ecochran> we're not validating
[14:50:25 EST(-0500)] <ecochran> let me poke at that for a minute
[14:51:12 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[14:53:42 EST(-0500)] <Justin_o> not sure if this helps at all but i suspended my firebug and i was able to tab to the stop upload button again, when i re-enabled it, i was no longer able to tab to the stop upload button
[14:55:59 EST(-0500)] <colinclark> Justin_o: !!!
[14:56:02 EST(-0500)] <colinclark> !!!!!!
[14:57:09 EST(-0500)] <ecochran> one moment, I need to feed Hannah
[15:00:56 EST(-0500)] <ecochran> back
[15:01:24 EST(-0500)] <ecochran> the lack of validation was because of stray thead and tfoot tags that have been removed
[15:01:31 EST(-0500)] <ecochran> but I don't think that they're going to change
[15:01:34 EST(-0500)] <ecochran> anything

  • No labels