[09:04:42 CDT(-0500)] <Abhinav> jhung, As quoted from Wikipedia : "The MPL has been approved as both a free software license (albeit one with a weak copyleft) by the Free Software Foundation[3] and an open-source software license by the Open Source Initiative."

[09:05:25 CDT(-0500)] <jhung> Thanks Abhinav. I see now that it is compatible with Apache License, which is what we're using elsewhere.

[09:05:50 CDT(-0500)] <Justin_o> jhung: i'd have to look at it in more detail, but i think it should be okay

[09:06:29 CDT(-0500)] <Abhinav> jhung, I believe I can make a good proposal using this. Do you have any recommendations

[09:07:30 CDT(-0500)] <Abhinav> jhung, It has around 28 basic effects on images. In addition we can integrate the desired image effects into the library

[09:08:25 CDT(-0500)] <jaugusto111> Hello

[09:08:37 CDT(-0500)] <Justin_o> jaugusto111: hello

[09:08:46 CDT(-0500)] <jhung> Abhinav: as long as it satisfies the project goals, you are free to use what you think is needed. It's good that the library you are looking at is MPL - we like open source!

[09:09:12 CDT(-0500)] <Abhinav> jhung, Alternatively I can also create a subset of this library and integrate our own effects to form a customised JS library suitable for the project

[09:10:06 CDT(-0500)] <Abhinav> jhung, Any advice you would like to give me as I read on the GSOC FAQ that we should interact with the mentors as much as possible.

[09:10:59 CDT(-0500)] <Abhinav> jhung, O also have a strong motivation for this particular project as my future work will involve dealing with images and other forms of multimedia

[09:12:36 CDT(-0500)] <jhung> Abhinav, that's great! I think at this point it's good to get your proposal in. Be sure to mention the different features you have in mind and how you would implement it. Also a demo would be helpful to demonstrate your ability and ideas.

[09:13:06 CDT(-0500)] <jaugusto111> where are the metores?

[09:13:20 CDT(-0500)] <Abhinav> jhung, How would you like me to provide a demo?

[09:13:32 CDT(-0500)] <Justin_o> jaugusto111: which mentors are you looking for?

[09:15:15 CDT(-0500)] <jhung> Abhinav, you can host the demo and provide a link to it, or you can send us the source code. The demo doesn't have to be big - just enough to demonstrate your ability and ideas. If you can do that in 1 or 2 features than that is great!

[09:15:41 CDT(-0500)] <jaugusto111> jhung, I have an idea and wanted to submit to GoSC2012. It works on the detection of digital activism on Twitter.

[09:16:42 CDT(-0500)] <Abhinav> jhung, I can show you the demo of the library right away

[09:17:00 CDT(-0500)] <jaugusto111> Justin_o I have an idea and wanted to submit to GoSC2012. It works on the detection of digital activism on Twitter. You is Mentor?

[09:21:13 CDT(-0500)] <Abhinav> jhung, Is it fine if I have no knowledge about Fluid Infusion?

[09:21:29 CDT(-0500)] <Abhinav> colinclark, Thank you sir

[09:25:48 CDT(-0500)] <Justin_o> Abhinav: you should try to start familiarizing yourself with it. We understand that you won't likely know it ahead of time, but we'd expect you to make use of it for the project.

[09:26:47 CDT(-0500)] <Abhinav> Justin_o, I will get to that right away. Is the Image Editor supposed to be integrated into the project?

[09:28:03 CDT(-0500)] <Justin_o> Abhinav: not right away, although depending on how it is, we may use it in Decapod and/or other projects

[09:29:21 CDT(-0500)] <Abhinav> Justin_o, So should I start to familiarize myself with any particular Fluid Project?

[09:30:31 CDT(-0500)] <Justin_o> Abhinav: Start looking at Fluid Infusion… It's an application framework and widget set built on top of jQuery… we use it in many of our projects

[09:31:05 CDT(-0500)] <Abhinav> Justin_o: Sure

[10:26:27 CDT(-0500)] <am33sh> jhung : i want to submit a patch for the fluid bug FLUID-4066... can you tell me how to submit it... or any documentation regarding it

[10:27:22 CDT(-0500)] <am33sh> jhung : or should i just attach the file in comment

[10:27:31 CDT(-0500)] <jhung> ^justin_o or anastasiac can help you with that question am33sh.

[10:27:44 CDT(-0500)] <am33sh> jhung : okay

[10:28:42 CDT(-0500)] <am33sh> anastasiac, justin_o : can i get any help regarding submitting the patch

[10:41:29 CDT(-0500)] <jaugusto111> I work with Online Social Networks

[10:41:56 CDT(-0500)] <greggy> your was the twitter idea?

[10:42:01 CDT(-0500)] <greggy> yours

[10:42:14 CDT(-0500)] <jaugusto111> yes

[10:43:35 CDT(-0500)] <greggy> you would need to find a mentor who is interested in the project first. Discuss the possibilities with regard to the projects participating ATutor or Fluid, then with input from the mentor create a proposal….

[10:45:13 CDT(-0500)] <jaugusto111> Where can I find other mentors?

[10:46:19 CDT(-0500)] <greggy> my first look at your proposal, I'm not sure where it fits. If you can make it usable in ATutor, or perhaps using Fluid technologies to implement it, its more likely a mentor will find it interesting...

[10:46:52 CDT(-0500)] <greggy> All mentor can be found here or in the #atutor channels, though they are online at different times during a day

[10:47:43 CDT(-0500)] <jaugusto111> what deadline for submition of proposals?

[10:47:51 CDT(-0500)] <codercube> hi fluid-work team, on GSoC page of IDI there's some info about contributing to jQuery UI, what exactly did you help with? just curious

[10:48:28 CDT(-0500)] <jhung> colinclark, avtar: Just spotted this press release from Logitech this morning. A business conferencing Webcam with remotecontrollable camera, speaker and mic. No idea how good the mic is - since we're pretty picky about those. http://www.logitech.com/en-ca/172/9812

[10:48:31 CDT(-0500)] <codercube> jaugusto111: you have 2 weeks

[10:48:43 CDT(-0500)] <greggy> jaugusto111: april 6 is the deadline, but you will want to have something together before that is you want feedback

[10:50:07 CDT(-0500)] <greggy> codercube: which project are you referring to?

[10:50:09 CDT(-0500)] <colinclark> codercube: We've contributed accessibility features and testing to jQuery UI, including ARIA and keyboard navigation features

[11:03:57 CDT(-0500)] <NickMayne> Has anyone looked in to ugprading the Fluid project to use jQuery 1.7.1 yet?

[11:04:12 CDT(-0500)] <NickMayne> I am running in to issues with the inline editor.

[11:04:13 CDT(-0500)] <yura> logiclord: this sort of stuff is very flexible, main goal is to have the ebum reader keyboard and screen reader accessible, as well as customizable to user preferences. adding comments was one of the examples of adding additional features. I brought up comments just because they are actually mentioned in epub spec

[11:04:57 CDT(-0500)] <colinclark> Hi NickMayne: Not that I know of, but you're definitely welcome to give it a try and we can help you with any issues you encounter

[11:05:19 CDT(-0500)] <NickMayne> The problem is the .ally stuff

[11:05:36 CDT(-0500)] <NickMayne> sorry I meant the ToolTip stuff

[11:05:38 CDT(-0500)] <logiclord> yura : And how do we expect to get epub files ... we expect user to upload them or choose from a library ?

[11:05:59 CDT(-0500)] <NickMayne> mouseover removes the lines

[11:06:02 CDT(-0500)] <NickMayne> not sure why yet.

[11:17:45 CDT(-0500)] <colinclark> NickMayne: Let me know if you dig up anymore details and we'll take a look

[11:19:46 CDT(-0500)] <NickMayne> I have a base working, it might be best if I push it up to a mecurial instance

[11:19:59 CDT(-0500)] <NickMayne> I have make it the inline editing option for Orchard CMS

[11:20:02 CDT(-0500)] <NickMayne> as a module.

[11:20:18 CDT(-0500)] <NickMayne> So will let you know what other issues I run in to.

[11:21:07 CDT(-0500)] <Abhinav> jhung: you there?

[11:21:15 CDT(-0500)] <Abhinav> Justin_o :

[11:21:17 CDT(-0500)] <colinclark> NickMayne: That's great, thanks!

[11:21:33 CDT(-0500)] <NickMayne>

[11:22:11 CDT(-0500)] <jhung> Abhinav: yup

[11:22:49 CDT(-0500)] <Abhinav> jhung, I have made a raw sample code as an illustriation. It helps in changing the brightness of the image using canvas.

[11:23:05 CDT(-0500)] <Abhinav> jhung, Its a very raw code just to show the basics

[11:24:14 CDT(-0500)] <NickMayne> How offen if the Fluid Project stuff being updated btw?

[11:24:25 CDT(-0500)] <NickMayne> Is the focus currently around the HTML5 player?

[11:24:34 CDT(-0500)] <jhung> Abhinav: okay. Did you send justin_o and I a copy?

[11:25:28 CDT(-0500)] <logiclord> yura : do we expect to get epub files ... we expect user to upload them or choose from a library ?

[11:26:27 CDT(-0500)] <yura> logiclord: epub reader would be just a widget that the implementor would use on their website. I would thing it would need to support loading epub from an url(file) on the server as well as jsonp

[11:26:51 CDT(-0500)] <colinclark> NickMayne: We try to put out Infusion releases on a regular basis. Infusion 1.4 came out about six months ago and we're pretty happy with it so far.

[11:27:46 CDT(-0500)] <colinclark> At the moment, a lot of our focus is on the UI Options component and the new HTML5 video player.

[11:27:54 CDT(-0500)] <NickMayne> @colinclark: dont get me wrong, its very good... I was looking at the commit history on GIT and there didnt appear to be much activity

[11:28:10 CDT(-0500)] <colinclark>

[11:28:43 CDT(-0500)] <colinclark> Most of the development work is currently happening in various forks and branches, which slowly migrate into master as they are fully baked

[11:28:48 CDT(-0500)] <Abhinav> jhung, just mailed to both of you.

[11:29:03 CDT(-0500)] <NickMayne> Oh, private repos?

[11:29:20 CDT(-0500)] <EricDalquist> quick question for all you JS buffs

[11:29:33 CDT(-0500)] <Abhinav> jhung, I have provided an image that loads, you have to give a numerical value to the brightness and the brightness will change accordingly.

[11:29:48 CDT(-0500)] <colinclark> We've had a fair number of framework changes; as you say, there's been less activity on some of the components in the past while

[13:12:17 CDT(-0500)] <Janani> what are the abilities you expect from this online image editor?

[13:12:42 CDT(-0500)] <Janani> i meant the functionalities of the editor?

[13:13:40 CDT(-0500)] <jhung> Janani, the context in which this will be used will be in correcting scanned images of books so they can be OCR'ed. So any image editing functionality that will help improve image quality will be useful. For example:...

[13:30:01 CDT(-0500)] <NickMayne> Hey Colin, do you know what the config values are to switch the control back?

[14:05:26 CDT(-0500)] <NickMayne> With the support events in the inline editor (http://wiki.fluidproject.org/display/fluid/Inline+Edit+API) - say I wanted to pass a unique ID (an ID for that item) back to the modelChanged event, so that I could change the value on the server, how could I go about doing that?

[14:05:45 CDT(-0500)] <NickMayne> I see the Source field... but I cant see where to populate it

[14:05:54 CDT(-0500)] <NickMayne> or even if thats the field I should be using.

[14:09:28 CDT(-0500)] <colinclark> NickMayne: The source argument probably isn't what you want. But can you tell me more about what you're trying to accomplish? Where is the ID coming from, and why do you need it each time the model changes?

[14:10:32 CDT(-0500)] <NickMayne> ColinClark: so this work im doing is for Orchard CMS

[14:10:48 CDT(-0500)] <NickMayne> Orchard CMS defines lots of 'widgets' which have there own versioning on a page

[14:11:09 CDT(-0500)] <NickMayne> When a user makes a change to a particular widget, that widget needs to be updated in the database

[14:11:23 CDT(-0500)] <NickMayne> Each widget has an id

[14:11:46 CDT(-0500)] <NickMayne> That Id is what I need to pass back to the server, along with the markup that has changed.

[14:11:52 CDT(-0500)] <colinclark> How is the widget ID communicated to the widget in the first place?

[14:12:12 CDT(-0500)] <NickMayne> It is part of a object that is pushed to the view

[14:12:23 CDT(-0500)] <NickMayne> I have the ID being rendered in the markup

[14:12:32 CDT(-0500)] <colinclark> Okay, so you've got the ID in the markup

[15:30:27 CDT(-0500)] <Bosmon> The normal behaviour we want on this is for the user's edit to be committed

[15:30:39 CDT(-0500)] <Justin_o> am33sh: also you might want to avoid using the <br /> tags, any chance you could do the same with just css

[15:30:42 CDT(-0500)] <Bosmon> You may or may not want this behaviour yourself....

[15:31:12 CDT(-0500)] <NickMayne> Yeah, that behaviour is good...

[15:31:21 CDT(-0500)] <Bosmon> Actually, to be honest, it looks like this implements the opposite behaviour

[15:31:31 CDT(-0500)] <NickMayne> Oh!

[15:31:34 CDT(-0500)] <Bosmon> It looks like this implements the behaviour of cancelling the edit rather than committing it

[15:31:44 CDT(-0500)] <am33sh> Justin_o : okay

[15:32:13 CDT(-0500)] <Bosmon> The comment before it is also noting that this behaviour is browser-dependent

[15:32:35 CDT(-0500)] <Bosmon> But one of the things that may very easily have happened between releases is that TinyMCE changed the containment structure of the markup they render for their editor

[15:32:36 CDT(-0500)] <NickMayne> I noticed / NB - this section has no effect - on most browsers no focus events

[15:32:45 CDT(-0500)] <Justin_o> am33sh: i left a comment on the jira too..

[15:32:51 CDT(-0500)] <NickMayne> True..

[15:33:17 CDT(-0500)] <Bosmon> Anyway, the reason for "deadMansBlur" is to deal with the case that the reason focus moved off the editor textarea is that it moved onto one of the components managed by the editor

[15:33:29 CDT(-0500)] <Bosmon> In this case, we want to defeat whatever the blur behaviour is

[15:33:47 CDT(-0500)] <Bosmon> But as a result of the limitations of HTML, there is no way to tell where the focus is transferring to other than by WAITING

[15:34:05 CDT(-0500)] <Bosmon> Unlike desktop focus events, you aren't notified of the new component to receive focus within the blur event

[15:34:14 CDT(-0500)] <NickMayne> ah so you jsut cancel

[15:34:25 CDT(-0500)] <Bosmon> So the idea behind deadMansBlur is to set a timer, during which we globally wait for focus events on the entire page

[15:34:45 CDT(-0500)] <Bosmon> And if we receive one within the time window, that is a focus to one of the nominated components, we cancel the effect of the bound handler

[15:34:54 CDT(-0500)] <Bosmon> Confusingly, in this case, we cancel the cancel : P

[15:35:11 CDT(-0500)] <Bosmon> But it seems that somehow with this version of TinyMCE, we lose focus, but can't recognise where it is transferred to

[15:35:31 CDT(-0500)] <Bosmon> And so we consider what has happened is that the USER changed focus, and so back out of the edit operation

[15:35:35 CDT(-0500)] <Bosmon> That is, we let the cancel continue

[15:35:43 CDT(-0500)] <NickMayne> but we do have exclusions

[15:35:47 CDT(-0500)] <Bosmon> We do

[15:35:55 CDT(-0500)] <NickMayne> Could that help?

[15:36:05 CDT(-0500)] <NickMayne> we could exclude that area?

[15:36:05 CDT(-0500)] <Bosmon> But presumably, whatever the focus event hits (assuming it even fires) doesn't fall within the exclusions

[15:36:14 CDT(-0500)] <Bosmon> Yes, if we could find where in the markup it is

[15:36:55 CDT(-0500)] <Bosmon> There may be any number of things going on here - for example, the editor may be creating the body markup later than it used to - so that when we call "getEditorBody" we are given the wrong node

[15:37:25 CDT(-0500)] <Bosmon> It might be worth putting a breakpoint at line 189 in InlineEditIntegrations to find out what markup is stored in "editorBody"

[15:37:36 CDT(-0500)] <Bosmon> You may well find that it is empty, for example

[15:37:43 CDT(-0500)] <NickMayne> okay, let me look

[15:38:51 CDT(-0500)] <NickMayne> nope it has stuff in

[15:38:59 CDT(-0500)] <Bosmon> If there is something reasonable in there, the next thing you could try is to add a listener yourself for ALL focus events on the document

[15:39:11 CDT(-0500)] <Bosmon> Actually we have a helpful utility for this in the file "DebugFocus.js" which is in our testing utils

[15:55:05 CDT(-0500)] <Bosmon> Looking at your transcript again, I am worrying that I misread it the first time.....

[15:55:09 CDT(-0500)] <anastasiac_> avtar, that line doesn't seem to be in my file

[15:55:19 CDT(-0500)] <Bosmon> I am seeing a focus event without a blur event

[15:55:26 CDT(-0500)] <NickMayne> The exclusion didnt work btw.

[15:55:32 CDT(-0500)] <anastasiac_> I have a commented line turning it on, avtar

[15:55:36 CDT(-0500)] <Justin_o> am33sh: i'm just heading out.. i can't remember in this context if that is okay, but generally that should be valid. The issue was that a <p> is a block level element and a <span> is inline.. you can't put blocks into inline elements

[15:55:46 CDT(-0500)] <Justin_o> hope that helps.. I'll be back tomorrow though if you'd like to talk more

[15:55:56 CDT(-0500)] <Justin_o> or you can send an e-mail to the fluid-work list

[15:56:48 CDT(-0500)] <am33sh> Justin_o : okay will talk tomorrow...

[15:56:50 CDT(-0500)] <NickMayne> There is a blur timer?

[15:56:57 CDT(-0500)] <Bosmon> Yes

[15:58:03 CDT(-0500)] <Bosmon> The markup refers to a module Orchard.jQuery which I don't have, but I can probably fake everything up

[15:58:33 CDT(-0500)] <NickMayne> Thats the 1.7.1 jquery

[15:58:42 CDT(-0500)] <NickMayne> want me to get you a reference?

[15:59:02 CDT(-0500)] <Bosmon> I can get it... I just thought we'd better be on the same page regarding what files we have : P

[15:59:09 CDT(-0500)] <NickMayne> sure

[15:59:12 CDT(-0500)] <NickMayne> Do you want the CSS?

[15:59:38 CDT(-0500)] <Bosmon> Does "OrchardLocal" actually exist in the filesystem? or is this already all part of the server

[15:59:38 CDT(-0500)] <NickMayne> jquery ui 1.8.16 btw

[15:59:51 CDT(-0500)] <NickMayne> thats just a virtual path

[16:00:12 CDT(-0500)] <Bosmon> It would help an awful lot if you could whip up a demo just with static files which shows the problem

[16:00:29 CDT(-0500)] <Bosmon> Or perhaps a live test site of some kind

[16:26:12 CDT(-0500)] <Bosmon> it will be through some bizarre collateral effect of DOM manipulation

[16:26:29 CDT(-0500)] <Bosmon> The fact that every browser responds to it differently indicates that it is something relatively unfathomable

[16:26:30 CDT(-0500)] <NickMayne> oh

[16:26:47 CDT(-0500)] <Bosmon> Anyway, I'm just extending the focus debugger to report focusin and focusout too, which didn't exist back in the day

[16:27:29 CDT(-0500)] <NickMayne> Do you think the team will go back and look at this older code at some point?

[16:28:02 CDT(-0500)] <NickMayne> Its a shame I didnt know you lot were doing a HTML5 editior... I was working at ITV 3 weeks ago

[16:28:02 CDT(-0500)] <Bosmon> Yes, we will

[16:28:12 CDT(-0500)] <NickMayne> HTML5 Video Player I meant

[16:28:33 CDT(-0500)] <Bosmon> For the 1.5 Infusion release we will make sure that we are up to date with all the versions of the relevant libaries

[16:28:45 CDT(-0500)] <Bosmon> But certainly what emerges from today's exercise will go into our trunk almost immediately

[16:28:55 CDT(-0500)] <NickMayne> Awesome

[16:30:29 CDT(-0500)] <Bosmon> Ok

[16:30:33 CDT(-0500)] <Bosmon> I have a full transcript now

[16:30:36 CDT(-0500)] <Bosmon> Pretty astonishing : P

[16:30:53 CDT(-0500)] <Bosmon> It seems that FF is firing a "bare focusout event"

[16:31:01 CDT(-0500)] <Bosmon> That is, a focusout event which has NO ORIGINATING BLUR

[16:31:16 CDT(-0500)] <NickMayne> why would it be doing that?

[16:31:21 CDT(-0500)] <Bosmon> Sheer insanity

[16:31:24 CDT(-0500)] <Bosmon> These things happen all the time

[16:32:24 CDT(-0500)] <NickMayne> Silly firefox!

[16:32:34 CDT(-0500)] <Bosmon> Ah, fascinating

[16:33:12 CDT(-0500)] <Bosmon> Ok, so the original cause of the event is our calling "mceFocus", the custom event from line 170 of our code

[16:33:35 CDT(-0500)] <Bosmon> The intermediate cause is the MCE implementation calling "body.focus()" on line 13187 of its own code

[16:34:04 CDT(-0500)] <Bosmon> And then the final cause is the new jquery turning this into a completely synthetic "focusout" event

[16:34:11 CDT(-0500)] <Bosmon> On line 3648 of its own code

[16:34:25 CDT(-0500)] <NickMayne> wow!

[16:34:42 CDT(-0500)] <Bosmon> It's all totally insane, and shows the kind of multiway "misunderstanding" that can occur when 3 different bodies of code start "trying to be helpful" in different ways........

[16:36:07 CDT(-0500)] <NickMayne> yeah, sometime trying to be helpful ends up with more pain for the end user

[16:36:26 CDT(-0500)] <Bosmon> And given it is a totally synthetic thing generated by jQuery, there is no requirement for it to have a "focus" which matches it, although it is pretty perverse that it doesn't

[16:39:34 CDT(-0500)] <Bosmon> Actually it's completely perverse

[16:39:42 CDT(-0500)] <Bosmon> The MCE call to "focus" DIRECTLY results in a handler for jQuery's "blur"

[16:40:13 CDT(-0500)] <NickMayne> So MCE is causing the main issue?

[16:40:19 CDT(-0500)] <Bosmon> Which is semi-reasonable, given something is being blurred

[16:40:26 CDT(-0500)] <NickMayne> oh right

[16:40:33 CDT(-0500)] <Bosmon> But the problem is, the resulting "focus" which you expect is eaten completely

[16:41:31 CDT(-0500)] <Bosmon> What MCE thinks it is doing is focusing the editor, which the browser thinks is blurring the textarea which was just created

[16:41:38 CDT(-0500)] <Bosmon> Well, it's hard to know who to blame in these situations

[16:42:48 CDT(-0500)] <NickMayne> Im finding it crazy... so many different parts!!...

[16:43:07 CDT(-0500)] <Bosmon> But here there's a quite complex race condition where MCE creates two separate blocks of markup as part of the same event, and then quickly transfers focus from one to the other

[16:47:25 CDT(-0500)] <Bosmon> There are no stack frames visible in Firebug in between the "focus" call and the "blur" handler.... but that's sort of par for the course with Firebug interacting with native FF internals

[16:48:06 CDT(-0500)] <Bosmon> So my bet is on this being an FF bug

[16:48:10 CDT(-0500)] <NickMayne> maybe its appeendind the content, then the focus is being lost?

[16:48:19 CDT(-0500)] <Bosmon> We learned long ago never to rely on raw calls to "focus" and "blur" on DOM elements

[16:48:23 CDT(-0500)] <NickMayne> appending*

[16:48:37 CDT(-0500)] <Bosmon> But always to dispatch these things through jQuery, in the very rare cases you think you want one... which is usually just for test cases

[16:49:12 CDT(-0500)] <Bosmon> But MCE isn't based on jQuery or any other recognisable base library, so it doesn't have that option

[16:51:05 CDT(-0500)] <Bosmon> But of course, the editor is then not focused!

[16:51:07 CDT(-0500)] <NickMayne> I jsut took a look at the latest tinymce and its still i nthere.

[16:51:21 CDT(-0500)] <Bosmon> AND... as a final kick in the nuts, when you DO click on the editor to focus it, it closes

[16:51:28 CDT(-0500)] <NickMayne> lol

[16:52:49 CDT(-0500)] <NickMayne> Sounds like you love tracking down these JS quirks!

[16:52:52 CDT(-0500)] <NickMayne>

[16:53:29 CDT(-0500)] <Bosmon> Interestingly, just for the same reason.... MCE creates two parallel sets of components when it constructs, firstly the "proxy textarea" which contains the editable material, and then all of its editing gubbins in a separate tree... and when you click on the gubbins, it causes a loss of focus for the textarea

[16:53:43 CDT(-0500)] <Bosmon> Well... I don't exactly love it... but I guess it is slightly more hilarious than the work I would otherwise be doing right now : P

[16:54:21 CDT(-0500)] <Bosmon> ah!

[16:54:25 CDT(-0500)] <Bosmon> Yes, I think I understand this now

[16:54:39 CDT(-0500)] <Bosmon> It stems from the religion in FF that "unfocusable elements are not focusable" : P

[16:55:23 CDT(-0500)] <Bosmon> The W3C spec insists that these are "not focusable" in the traditional sense, so FF refuses to ever generate any focus events targetted on this

[16:55:24 CDT(-0500)] <Bosmon> them

[16:55:42 CDT(-0500)] <Bosmon> Chrome and other browsers are less fastidious, and accept that if you click on SOMETHING, whatever it is, that thing should be treated as focusable

[16:56:14 CDT(-0500)] <Bosmon> So, on FF we get this annoying situation consisting of "focus transitions to nothing" when the thing you clicked on, or manually triggered a "focus" event on, consists of TinyMCE editor gubbins

[16:57:28 CDT(-0500)] <Bosmon> Oh christ

[16:57:32 CDT(-0500)] <Bosmon> I've just seen how bad this is

[16:57:39 CDT(-0500)] <Bosmon> All the MCE editor gubbins is now in an IFRAME

[16:57:42 CDT(-0500)] <NickMayne> Sounds like FF is adhering to the W3C spec

[16:57:49 CDT(-0500)] <Bosmon> What sleazebags

[16:57:53 CDT(-0500)] <NickMayne> it is?

[16:57:54 CDT(-0500)] <Bosmon> I knew there was a reason we abandoned it

[17:05:20 CDT(-0500)] <Bosmon> At least he didn't supply abuse, which is the traditional response by the manager of an open source project who is asked for some improvement : P

[17:06:19 CDT(-0500)] <NickMayne> lol

[17:06:33 CDT(-0500)] <NickMayne> True!!!

[17:07:22 CDT(-0500)] <Bosmon> The traditional response consists of i) abuse, and/or a statement that ii) the questioner is unable to understand the proper way to use the product in question

[17:08:04 CDT(-0500)] <Bosmon> I might need a loo break whilst I think about the best fix

[17:08:15 CDT(-0500)] <Bosmon> But my current thinking is that we have no alternative but to rely on Modern Means

[17:08:23 CDT(-0500)] <Bosmon> 2 or 3 years ago, this problem would have been almost unsolvable

[17:08:42 CDT(-0500)] <Bosmon> Because there's just no way at all to trap the call from MCE to "focus" before it gets dispatched to the browser and hence to jQuery

[17:09:07 CDT(-0500)] <Bosmon> And the only other approach would have been to register a FOCUS HANDLER ON EVERY OBJECT IN THE DOCUMENT the way that DebugFocus does

[17:09:13 CDT(-0500)] <Bosmon> Which is clearly a totally anti-social strategy

[17:09:36 CDT(-0500)] <Bosmon> But actually in the last few years, support for the "bubbling focus event" named "focusin" by modern browsers has become pretty good

[17:09:49 CDT(-0500)] <Bosmon> I mean, it might even work on IE8, who knows

[17:10:13 CDT(-0500)] <Bosmon> But the central problem is "how to trap a transition which consists of a blur away from a focusable element, ONTO a focus onto a nonfocusable element"

[17:10:26 CDT(-0500)] <NickMayne> Ah but does it work in IE6!?

[17:10:27 CDT(-0500)] <NickMayne> hehe

[17:10:46 CDT(-0500)] <Bosmon> In the old days when fluid.deadMansBlur was written, it was assumed that there was no economic way to track focus onto "every other element"

[17:10:52 CDT(-0500)] <Bosmon> So it tracked blur instead

[17:11:36 CDT(-0500)] <Bosmon> But we can have an alternative element, which considers that the complete absence of focus on any other element in the document within the window, must signify that the focus remained on the gubbins

[17:11:44 CDT(-0500)] <Bosmon> Well, it needs to be even worse than that

[17:12:05 CDT(-0500)] <Bosmon> "absence of a focus event OR a click event anywhere else in the document means that the blur must have been a transition to gubbins"

[17:13:35 CDT(-0500)] <NickMayne> Im following ya

[17:13:54 CDT(-0500)] <Bosmon> Part of the key aims of all of this stuff was to make sure everything remained keyboard accessible

[17:14:12 CDT(-0500)] <Bosmon> Which as a result of the gubbins, tinyMCE fails to be totally - BUT, it's still only possible to focus genuinely focusable elements using the keyboard

[17:14:19 CDT(-0500)] <NickMayne> absolutly, I can tell that from the docs that were written

[17:15:36 CDT(-0500)] <Bosmon> And anything which fails to generate either of those MUST be a result of attempting to focus the gubbins, either through the manual process of clicking on it, or a call to "focus" on it

[17:16:52 CDT(-0500)] <Bosmon> Anyway, I'll get something working this evening and mail you

[17:17:05 CDT(-0500)] <Bosmon> Sadly it looks like it will need at least a partial rewrite or upgrade of deadMansBlur

[17:17:21 CDT(-0500)] <Bosmon> Since the current implementation isn't willing to accept "no event at all" as a case for proceeding rather than cancelling

[17:18:19 CDT(-0500)] <Bosmon> That is, right now, if it finds a blur, followed by no other event, it assumes that the blur should go on to be handled

[17:19:13 CDT(-0500)] <Bosmon> On the other hand, you could right now get a "100% manual" component working, if you comment out the deadMansBlur entirely

[17:19:20 CDT(-0500)] <Bosmon> The user just has to click save explicitly if they want to save

[17:20:01 CDT(-0500)] <NickMayne> Sorry just on a skype call

[17:20:03 CDT(-0500)] <NickMayne> be back in 5

[17:23:04 CDT(-0500)] <Bosmon> So yes, if you just get rid of the lines 189-194 in InlineEditIntegrations.js, you find that the editor works acceptably, if clunkily

[17:29:55 CDT(-0500)] <NickMayne> Back!

[17:30:15 CDT(-0500)] <NickMayne> I dont might waiting for the proper fix im in no rush as I have the backend stuff to do as well

[17:33:25 CDT(-0500)] <NickMayne> Bosmon, I have to go to bed!

[17:33:36 CDT(-0500)] <NickMayne> But i jsut wanted to say thanks for all your help tonight

[17:34:14 CDT(-0500)] <NickMayne> I have a bunch of stuff, which I dont mind logging inthe issue tracker if you guys want

[17:34:16 CDT(-0500)] <NickMayne>

[17:34:52 CDT(-0500)] <NickMayne> I pinged you my email if you want to open me an issue tracker.