fluid-work IRC Logs-2012-03-26
- Fluid IRC Log Bot
[08:52:13 CDT(-0500)] <Abhinav> Hi anybody online?
[08:54:05 CDT(-0500)] <greggy> who did you need to reach?
[08:55:05 CDT(-0500)] <Abhinav> Justin Hung
[08:55:26 CDT(-0500)] <Abhinav> Sorry I mean Jon Hung or Justin Obara
[08:55:38 CDT(-0500)] <Abhinav> None of them replying
[08:55:46 CDT(-0500)] <greggy> Justin_o: ^ use a user name as a prefix to get someones attention
[08:57:36 CDT(-0500)] <greggy> jhung: ^
[08:57:57 CDT(-0500)] <Justin_o> thanks greggy
[08:58:00 CDT(-0500)] <Justin_o> hi Abhinav
[08:58:03 CDT(-0500)] <Abhinav> jhung: ^I have some ideas to discuss about HTML5 editor
[08:58:13 CDT(-0500)] <jhung> Abhinav, sure. What do you have in mind?
[08:58:49 CDT(-0500)] <Abhinav> I researched on the web and I found a Javascript library which can help us in the impolementation
[08:59:07 CDT(-0500)] <Abhinav> It is under the open source licence so we can also edit and customise it to our own needs
[09:00:12 CDT(-0500)] <jhung> Abhinav, that's great!
[09:00:23 CDT(-0500)] <Abhinav> jhung It covers some of the features that we desire and plus we can utiliuze greater number of features
[09:00:57 CDT(-0500)] <Abhinav> jhung, I can also code new features in it and it is perfectly allowable as its under open source licence
[09:01:30 CDT(-0500)] <Abhinav> We can integrate it with the HTML5 Canvas
[09:01:36 CDT(-0500)] <jhung> Abhinav, out of curiousity, what license does it use?
[09:02:44 CDT(-0500)] <Abhinav> jhung, Mozilla Public Licence Cersion 1.1
[09:03:27 CDT(-0500)] <jhung> justin_o: I'm not familiar with that license. Do you have any thoughts?
[09:03:29 CDT(-0500)] <Abhinav> Sorry I meant Mozilla Public Licence Version 1.1
[09:03:46 CDT(-0500)] <Abhinav> jhung, http://en.wikipedia.org/wiki/Mozilla_Public_License
[09:03:54 CDT(-0500)] <Abhinav> I read about the licence from here
[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:13:37 CDT(-0500)] <Abhinav> jhung, Should I provide a sample code for 1-2 effects ?
[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:18:07 CDT(-0500)] <jhung> Abhinav: great. Can you email the code / link to jobara@ocadu.ca and jhung@ocadu.ca please?
[09:18:22 CDT(-0500)] <Abhinav> I sure will
[09:18:39 CDT(-0500)] <jhung> Thanks!
[09:19:19 CDT(-0500)] <colinclark> Abhinav: What's the library you're referring to, out of curiosity?
[09:19:52 CDT(-0500)] <Justin_o> jaugusto111: I am a mentor, but you might want to float your idea by colinclark and greggy since I take it you are talking about proposing your own project
[09:20:42 CDT(-0500)] <Abhinav> colinclark, Pixastic, http://www.pixastic.com/
[09:20:46 CDT(-0500)] <colinclark> Oh yes
[09:20:50 CDT(-0500)] <colinclark> I know Pixastic quite well
[09:21:00 CDT(-0500)] <colinclark> Good choice
[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:28:46 CDT(-0500)] <anastasiac> am33sh, have you looked at this page? http://wiki.fluidproject.org/display/fluid/Contributing+Code
[10:30:00 CDT(-0500)] <am33sh> anastasiac : thankyou
[10:31:10 CDT(-0500)] <jaugusto111> greggy you is Mentor?
[10:31:41 CDT(-0500)] <greggy> jaugusto111: I am.
[10:41:15 CDT(-0500)] <jaugusto111> greggy How do I submit my idea?
[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
[10:50:26 CDT(-0500)] <colinclark> Justin_o, these days, contributes a lot to the jQuery testing tools effort
[10:51:47 CDT(-0500)] <codercube> greggy: I don't mean exact project, I've got this info from http://wiki.atutor.ca/display/atutorwiki/Google+Summer+of+Code+2012
[10:52:10 CDT(-0500)] <logiclord> yura I have some doubts regarding "Highly customizable and accessible web based ePub reader"
[10:52:19 CDT(-0500)] <codercube> colinclark : that's really interesting
[10:52:27 CDT(-0500)] <greggy> codercube: colinclark is a good person to talk to then
[10:53:51 CDT(-0500)] <yura> logiclord: please share
[10:54:04 CDT(-0500)] <logiclord> yura What exactly is intended from editing features ??
[10:54:11 CDT(-0500)] <logiclord> Adding comments ??
[10:54:11 CDT(-0500)] <logiclord> Higlighting text ??
[10:54:11 CDT(-0500)] <logiclord> Touch support ??
[10:54:11 CDT(-0500)] <logiclord> BooKmarks ??
[10:54:53 CDT(-0500)] <logiclord> or complete text edit + indentation ?
[10:57:12 CDT(-0500)] <avtar> jhung: that looks pretty neat
[10:58:04 CDT(-0500)] <jhung> avtar: yeah. Too bad someone remote can't control the camera.
[10:58:20 CDT(-0500)] <jhung> Then we can have a virtual jessm at the idrc offices.
[10:59:35 CDT(-0500)] <avtar> that could be an arduino/lego project
[11:00:21 CDT(-0500)] <avtar> mount the cam on a robot and let allow jessm to navigate through the office
[11:01:14 CDT(-0500)] <jhung> You're thinking too terrestrial Avtar. Put it up on an AR Drone Parrot.
[11:01:20 CDT(-0500)] <Justin_o> avtar: that sounds like fun
[11:03:09 CDT(-0500)] <NickMayne> Hi All
[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
[11:29:51 CDT(-0500)] <colinclark> EricDalquist: Shoot
[11:29:58 CDT(-0500)] <EricDalquist> if http://a.com/index.html loads JS from http://b.com/foo.js can foo.js make ajax calls back to b.com?
[11:30:25 CDT(-0500)] <colinclark> No
[11:30:41 CDT(-0500)] <logiclord> yura : Is there any mailing list or wiki for this where I could post more detailed description ?
[11:31:06 CDT(-0500)] <colinclark> EricDalquist: Aside from using JSONP, all requests are limited to the origin of the web page.
[11:31:17 CDT(-0500)] <EricDalquist> ok
[11:31:25 CDT(-0500)] <EricDalquist> so for something like google analytics
[11:31:36 CDT(-0500)] <EricDalquist> they must be doing jsonp for everything?
[11:31:53 CDT(-0500)] <jhung> Thanks Abhinav. We'll take a look.
[11:32:02 CDT(-0500)] <colinclark> EricDalquist: I'd assume so, yes
[11:32:13 CDT(-0500)] <Abhinav> jhung, sure when do I get back to you?
[11:32:14 CDT(-0500)] <EricDalquist> thanks
[11:32:23 CDT(-0500)] <colinclark> Any time
[11:32:56 CDT(-0500)] <yura> logiclord: let me see
[11:32:58 CDT(-0500)] <NickMayne> Gotta shoot!... Let you know if I get stuck. Nick
[11:33:04 CDT(-0500)] <Abhinav> colinclark, could you explain EricDalquist's doubt a little more, if you are not busy.
[11:33:38 CDT(-0500)] <colinclark> Abhinav: Is there something in particular I can explain?
[11:34:10 CDT(-0500)] <jhung> Abhinav: You should work on a project proposal in the mean time. Either justin_o or I will get back to you with comments / ideas once we've had a look at the code.
[11:34:53 CDT(-0500)] <Abhinav> colinclark, You said all requests are limited to the origin page. Can tou explain a little bit more on that part.
[11:35:27 CDT(-0500)] <Abhinav> jhung, sure I will start that. You guys will get back to me through mail or through the IRC Channel?
[11:35:32 CDT(-0500)] <EricDalquist> its the javascript same origin policy
[11:35:44 CDT(-0500)] <colinclark> Abhinav: This is probably the best place to learn: http://en.wikipedia.org/wiki/Same_origin_policy
[11:35:47 CDT(-0500)] <EricDalquist> I just couldn't remember if it was the page's origin or the script's origin
[11:36:32 CDT(-0500)] <Abhinav> colinclark, Thanks a lot. I will go through this
[11:36:41 CDT(-0500)] <colinclark> No problem
[11:37:18 CDT(-0500)] <Abhinav> colinclark, I was working on a HTML5 Android App and got the same problem, so got a bit curious
[11:38:12 CDT(-0500)] <jhung> Abhinav: We'll respond via email
[11:39:16 CDT(-0500)] <Abhinav> jhung, Thank you
[11:39:31 CDT(-0500)] <jhung> no problem.
[11:42:14 CDT(-0500)] <yura> logiclord: so i think you can register on the wiki. if you do , you can add a new page links to the epub project description where you can put more details etc
[12:48:47 CDT(-0500)] <NickMayne> Hey Chaps,
[12:49:35 CDT(-0500)] <NickMayne> Is there any reason why with the inline editor in v1.2 you woere able to click to edit the content, but in the latest build you have to click the edit link?
[12:49:46 CDT(-0500)] <NickMayne> or an 'edit' link?
[12:51:27 CDT(-0500)] <colinclark> Hey again, NickMayne. That doesn't sound like the right behaviour to me
[12:51:47 CDT(-0500)] <NickMayne> Thats what I thought
[12:51:49 CDT(-0500)] <colinclark> If you try this demo, you'll see that the content itself in indeed clickable http://fluidproject.org/releases/1.4/demos/inlineEdit/simple/html/inlineEdit.html
[12:51:50 CDT(-0500)] <NickMayne> Thats in your demo
[12:52:03 CDT(-0500)] <NickMayne> Ah
[12:52:07 CDT(-0500)] <colinclark> There is a link in the default markup for Inline Edit, which helps for accessibility
[12:52:12 CDT(-0500)] <NickMayne> yes thats the behaviour I would expect
[12:53:28 CDT(-0500)] <NickMayne> here is the demo I have been working from http://build.fluidproject.org/infusion/demos/inlineEdit/rich/demo.html
[12:54:22 CDT(-0500)] <colinclark> Ah, yes, the rich text version
[12:55:07 CDT(-0500)] <colinclark> jameswy may remember the motivation for why, by default, the whole content isn't clickable
[12:55:26 CDT(-0500)] <colinclark> I believe we had design reasons why it was typically awkward to have a whole region of text be clickable
[12:55:30 CDT(-0500)] <colinclark> But ultimately, this is all configurable
[12:55:45 CDT(-0500)] <colinclark> so if it's the behaviour you want, I imagine it should be fairly straightforward for you to configure it that way
[12:56:20 CDT(-0500)] <NickMayne> Okay
[12:56:34 CDT(-0500)] <NickMayne> Any ideas on how to do that?
[12:56:48 CDT(-0500)] <NickMayne> I could try taking parts of the example you showed me
[12:58:19 CDT(-0500)] <Janani> hi all, i am interested in applying fo GSOC with "HTML5 Image Editor" project.
[12:58:51 CDT(-0500)] <Janani> can i know whom i should contact?
[12:59:28 CDT(-0500)] <Janani> is there a mailing list?
[13:00:44 CDT(-0500)] <jhung> Hi Janani. Justin_o is the mentor on that project and I am advising on it. Anything we can help with?
[13:02:36 CDT(-0500)] <Janani> thank you for your response, I am interested in that project, can you guide me how should I make the proposal?
[13:03:22 CDT(-0500)] <Justin_o> Janani: in regards to the mailing list, you can contact us not the fluid-work mailing list http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
[13:04:51 CDT(-0500)] <Janani> thank you justin, I think it will be verymuch useful.
[13:08:47 CDT(-0500)] <jhung> Janani anything else you need help with? Feel open to ask.
[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:14:41 CDT(-0500)] <jhung> erase, clone / stamp, undo / redo, orientation, skew, brightness/contrast, threshold (converting to B&W), etc.
[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
[14:12:37 CDT(-0500)] <NickMayne> yes
[14:13:12 CDT(-0500)] <NickMayne> <div id="richInlineEdit-container-8"> <span class="fl-inlineEdit-textContainer fl-inlineEdit-focus"> <div class="flc-inlineEdit-text" tabindex="-1" style="padding-right: 0px;">
[14:13:32 CDT(-0500)] <NickMayne> where 8 in the id="richInlineEdit-container-8" is the ID of the widget
[14:13:42 CDT(-0500)] <colinclark> So presumably you've also got a listener for afterFinishEdit?
[14:13:50 CDT(-0500)] <NickMayne> I can change that to anything, I have complete control of that.
[14:13:55 CDT(-0500)] <NickMayne> no?
[14:14:01 CDT(-0500)] <NickMayne> modelChanged
[14:14:06 CDT(-0500)] <colinclark> okay
[14:14:27 CDT(-0500)] <NickMayne> should it be afterfinishedit?
[14:14:31 CDT(-0500)] <colinclark> do you have some code you can pastie for me to take a look at? http://pastie.org
[14:14:37 CDT(-0500)] <NickMayne> sure
[14:16:01 CDT(-0500)] <NickMayne> http://pastie.org/3673550
[14:16:06 CDT(-0500)] <NickMayne> I posted some JS and HTML
[14:16:43 CDT(-0500)] <colinclark> So you need to post back this ID? #richInlineEdit-container-" + shapeId
[14:17:03 CDT(-0500)] <NickMayne> Yeah
[14:17:17 CDT(-0500)] <NickMayne> along with the html that has changed
[14:17:58 CDT(-0500)] <colinclark> Easiest option would be for you to store that ID in a variable, and send it along as needed
[14:18:51 CDT(-0500)] <NickMayne> a variable?
[14:19:05 CDT(-0500)] <NickMayne> How would ModelChanged know about that?
[14:19:16 CDT(-0500)] <colinclark> It would be in scope
[14:19:33 CDT(-0500)] <NickMayne> Do you mean in the HTML markup for the editor?
[14:19:57 CDT(-0500)] <colinclark> No, in the JavaScrtip
[14:20:05 CDT(-0500)] <colinclark> let me whip an example, one sec
[14:20:17 CDT(-0500)] <NickMayne> How will that work with multiple #richInlineEdit-container-" + shapeId on the page?
[14:20:32 CDT(-0500)] <NickMayne> (Sorry im a C# dev not a JS - but im trying!)
[14:21:29 CDT(-0500)] <NickMayne> oh wait
[14:21:29 CDT(-0500)] <NickMayne> lol
[14:21:32 CDT(-0500)] <Bosmon> NickMayne - your sort will be first against the wall when the revolution comes
[14:21:33 CDT(-0500)] <NickMayne> I already have it!!
[14:21:37 CDT(-0500)] <Bosmon> Actually 2nd against the wall
[14:21:40 CDT(-0500)] <Bosmon> Java devs first
[14:21:46 CDT(-0500)] <NickMayne> lol
[14:21:57 CDT(-0500)] <NickMayne> orchardInlineEditing.initRichInlineEdit = function (shapeId) {
[14:22:11 CDT(-0500)] <Bosmon> Looks like you do indeed have it, yes
[14:22:13 CDT(-0500)] <NickMayne> I was passing it in, but didnt release JS scopes worked quite that way
[14:22:37 CDT(-0500)] <NickMayne> wierd!! Majic I say!
[14:22:44 CDT(-0500)] <NickMayne> Magic*
[14:22:45 CDT(-0500)] <Bosmon> We tend to call it.... "closures" : P
[14:23:17 CDT(-0500)] <colinclark> NickMayne: http://pastie.org/3673589
[14:23:49 CDT(-0500)] <colinclark> NickMayne: They're really wonderful, closures.
[14:24:08 CDT(-0500)] <NickMayne> yeah they look useful.
[14:24:10 CDT(-0500)] <Bosmon> It's almost hard for me to remember by now how the other kind of functions worked...
[14:24:16 CDT(-0500)] <NickMayne> in C# it would fall out of scope
[14:24:28 CDT(-0500)] <Bosmon> The ones that, if they let you refer to anything, allowed you to helpfully refer to some kind of "deallocated memory" : P
[14:24:31 CDT(-0500)] <NickMayne> hence why I didnt think the value was being stored.
[14:24:36 CDT(-0500)] <NickMayne> thanks for the Pastie
[14:24:44 CDT(-0500)] <Bosmon> I thought C# had at least some form of closures....
[14:24:44 CDT(-0500)] <colinclark> Glad we could help
[14:24:58 CDT(-0500)] <NickMayne> They do... but you have to specify them
[14:25:05 CDT(-0500)] <colinclark> I guess they do
[14:25:11 CDT(-0500)] <NickMayne> they are explicit rather than implicit
[14:25:51 CDT(-0500)] <colinclark> Looks like they were added in C# 3.0
[14:26:14 CDT(-0500)] <colinclark> http://www.codethinked.com/c-closures-explained
[14:26:40 CDT(-0500)] <NickMayne> oh yes
[14:26:49 CDT(-0500)] <NickMayne> but they dont work the same way as JS ones
[14:26:53 CDT(-0500)] <Bosmon> Looks like you have to use a "delegate" or anonymous method....
[14:27:05 CDT(-0500)] <NickMayne> yup
[14:27:09 CDT(-0500)] <Bosmon> For some reason, a normal method doesn't quite cut it : P
[14:27:14 CDT(-0500)] <NickMayne> lol
[14:27:26 CDT(-0500)] <NickMayne> I like them... some people use them in overkill
[14:27:37 CDT(-0500)] <NickMayne> but they are useful for certain things.
[14:27:38 CDT(-0500)] <NickMayne> hey colin, earlier you said that the inline controls were configurable, do you know what the config values are to switch the control back to what it was like in 1.2?
[14:27:56 CDT(-0500)] <Bosmon> In a language which is mostly organised around "objects", they can be confusing in their impact
[14:28:09 CDT(-0500)] <colinclark> Maybe Bosmon remembers...
[14:28:18 CDT(-0500)] <Bosmon> Let me see if I can remember
[14:28:25 CDT(-0500)] <colinclark> NickMayne wants a rich text inline editor where the body is clickable, not just the "Edit" link
[14:28:27 CDT(-0500)] <Bosmon> After having mostly contributed heckling to this discussion so far....
[14:28:36 CDT(-0500)] <colinclark> I remember that we actually changed this behaviour due to usability concerns
[14:28:49 CDT(-0500)] <colinclark> I'm sure it's configurable, but I couldn't obviously see how it was done
[14:28:58 CDT(-0500)] <colinclark> Regular inline edit works this way, obviously
[14:29:32 CDT(-0500)] <NickMayne> I really do like this inline editor so far..
[14:30:33 CDT(-0500)] <colinclark> That's great
[14:31:03 CDT(-0500)] <colinclark> It looks like that behaviour is actually controlled in code, unfortunately
[14:31:20 CDT(-0500)] <colinclark> In the implementation of fluid.inlineEdit.richTextDisplayModeRenderer(), if I'm reading this correctly
[14:31:32 CDT(-0500)] <colinclark> You could add the behaviour back yourself with a single line of code
[14:31:43 CDT(-0500)] <colinclark> NickMayne: Does Orchard use jQuery or a toolkit?
[14:31:55 CDT(-0500)] <colinclark> I guess you've got jQuery there for sure if you're using Infusion
[14:32:09 CDT(-0500)] <NickMayne> jQuery
[14:32:54 CDT(-0500)] <Bosmon> colinclark found it before me...
[14:33:06 CDT(-0500)] <Bosmon> I got lost in this rat's maze wondering why this code is so old-fashioned : P
[14:33:12 CDT(-0500)] <colinclark> Try something like this, on the line after instantiating your inline editor:
[14:33:38 CDT(-0500)] <colinclark> tinyEditor.locate("edit").click(function () );
[14:33:50 CDT(-0500)] <colinclark> oops
[14:33:51 CDT(-0500)] <colinclark> not quite
[14:34:03 CDT(-0500)] <colinclark> tinyEditor.locate("text").click(function () );
[14:34:05 CDT(-0500)] <Bosmon> At least we made these things public
[14:34:19 CDT(-0500)] <colinclark> That will locate the text of the inline editor, and when it is clicked, call the edit() method, which will open it up and make it editable
[14:34:32 CDT(-0500)] <Bosmon> It may be safer to use the dedicated function fluid.inlineEdit.bindMouseHandlers
[14:34:47 CDT(-0500)] <colinclark> ah, interesting
[14:34:58 CDT(-0500)] <Bosmon> Since it does some extra processing to avoid triggering on native HTML controls
[14:35:06 CDT(-0500)] <colinclark> That's right
[14:35:07 CDT(-0500)] <colinclark> s
[14:35:12 CDT(-0500)] <colinclark> so it would look like this, instead:
[14:35:22 CDT(-0500)] <Bosmon> So, for example, to write fluid.inlineEdit.bindMouseHandlers(tinyEditor.container, tinyEditor.edit);
[14:35:28 CDT(-0500)] <colinclark> Bosmon beat me to it 
[14:35:49 CDT(-0500)] <NickMayne> okay where do I pop that?
[14:35:52 CDT(-0500)] <Bosmon> Or more accurately, fluid.inlineEdit.bindMouseHandlers(tinyEditor.viewEl, tinyEditor.edit);
[14:36:01 CDT(-0500)] <Bosmon> NickMayne - at any point after you have initialised the editor
[14:36:15 CDT(-0500)] <Bosmon> And assigned it to a variable named "tinyEditor" in this case : P
[14:36:32 CDT(-0500)] <Bosmon> This is actually the magic missing line of code in the initialisation sequence for a rich text editor, to a standard one
[14:36:40 CDT(-0500)] <colinclark> NickMayne: Like this, from your original paste: http://pastie.org/3673660
[14:36:49 CDT(-0500)] <Bosmon> Although unfortunately this code is so old that we have to compare these line by line to find the difference : P
[14:37:19 CDT(-0500)] <NickMayne>
[14:37:26 CDT(-0500)] <NickMayne> Wow worked like a dream
[14:37:29 CDT(-0500)] <NickMayne> Thanks guys!
[14:37:31 CDT(-0500)] <colinclark> that's great!
[14:38:45 CDT(-0500)] <NickMayne> http://pic.twitter.com/OIGGUEfP
[14:39:02 CDT(-0500)] <colinclark> Awesome, looks really nice
[14:39:13 CDT(-0500)] <NickMayne> Progress so far!! yeah it does right
[14:39:47 CDT(-0500)] <NickMayne> Dinner back in 20
[14:40:10 CDT(-0500)] <Bosmon> They obviously have incredibly short dinners over at Orchard....
[14:40:16 CDT(-0500)] <Bosmon> Protestant Work Ethic!
[14:52:25 CDT(-0500)] <NickMayne> lol
[14:52:59 CDT(-0500)] <NickMayne> Okay, another wierd issue.
[14:53:08 CDT(-0500)] <NickMayne> If you chaps are up for it?
[14:53:22 CDT(-0500)] <Bosmon> Go for it, NickMayne
[14:54:01 CDT(-0500)] <NickMayne> So when you initialy load up the page with the edit controls on the screen, and click edit
[14:54:36 CDT(-0500)] <NickMayne> The area with the edit control flickers to the correct TinyMCE view so edit mode, and then flicks stright back to view mode
[14:55:35 CDT(-0500)] <NickMayne> If you change the lazyEditView: true to lazyEditView: false, the flicker doesnt occur
[14:56:37 CDT(-0500)] <NickMayne> but then the edit control doesnt change the text back when you hit save.
[14:56:56 CDT(-0500)] <Justin_o> yura, Bosmon: is there a way to create a subcomponent without having a fluid.defaults call for that subcomponent
[14:57:11 CDT(-0500)] <Bosmon> Justin_o - no way at all, no
[14:57:15 CDT(-0500)] <Bosmon> And I advise you not to try!
[14:57:20 CDT(-0500)] <Justin_o> i need to create some small eventedComponent to manage event s and listeners
[14:57:24 CDT(-0500)] <Justin_o> okay
[14:57:26 CDT(-0500)] <Bosmon> NickMayne - I think I remember this kind of flickering, yes
[14:57:33 CDT(-0500)] <Justin_o> Bosmon: thanks for the warning
[14:57:46 CDT(-0500)] <Bosmon> I guess we haven't evaluated this kind of thing with recent versions of TinyMCE
[14:57:57 CDT(-0500)] <NickMayne> It works fine on the demo...
[14:58:09 CDT(-0500)] <Bosmon> The demo probably uses a much earlier version than you
[14:58:14 CDT(-0500)] <NickMayne> I thought that it could be the latest cut of jQuery causign the issue?
[14:58:20 CDT(-0500)] <NickMayne> causing*
[14:58:23 CDT(-0500)] <colinclark> It seems unlikely
[14:58:28 CDT(-0500)] <Bosmon> I remember that this kind of behaviour tends to be very unstable and depend on some fine details of event dispatching
[14:58:37 CDT(-0500)] <Bosmon> It's unlikely, but not completely impossible
[14:58:44 CDT(-0500)] <Bosmon> We haven't done any tests with more recent jQueries either
[14:59:11 CDT(-0500)] <NickMayne> Bummer.
[14:59:28 CDT(-0500)] <NickMayne> Any ideas if there is anything I can look at?
[14:59:32 CDT(-0500)] <Bosmon> But I'm sure we can get something working for you
[14:59:36 CDT(-0500)] <NickMayne>
[15:00:12 CDT(-0500)] <NickMayne> if we can get the UI working, the backend will be easy.
[15:01:28 CDT(-0500)] <Bosmon> The edit control doesn't change the text back when you hit save......
[15:01:33 CDT(-0500)] <Bosmon> Well
[15:01:52 CDT(-0500)] <Bosmon> I don't know if there's an easy way for you to just zip up the HTML + JS you have now and send it over?
[15:02:03 CDT(-0500)] <Bosmon> It may be easiest to fix this by taking a look directly
[15:02:13 CDT(-0500)] <Bosmon> Since it obviously depends on some awful kind of timing subtlety
[15:02:38 CDT(-0500)] <NickMayne> I can do that
[15:04:21 CDT(-0500)] <am33sh> anastasiac : sir have submitted the patch for FLUID-4066 and FLUID-4405 along with the screenshots.
[15:04:51 CDT(-0500)] <colinclark> I'm sure anastasiac_ just loves being called "sir." 
[15:05:22 CDT(-0500)] <Bosmon> NickMayne - as an initial idea, looking at InlineEditIntegrations.js line 152, I see the following
[15:05:25 CDT(-0500)] <Bosmon> fluid.inlineEdit.tinyMCE.setValue = function (editField, editor, value) {
[15:05:25 CDT(-0500)] <Bosmon> $(editField).val(value);
[15:05:25 CDT(-0500)] <Bosmon> editor.setContent(value, );
[15:05:25 CDT(-0500)] <Bosmon> };
[15:05:37 CDT(-0500)] <Bosmon> Which looks like it was trying to work around a race condition in that version of tinyMCE
[15:05:53 CDT(-0500)] <Bosmon> the comment says // without this, there is an intermittent race condition if the editor has been created on this event.
[15:06:08 CDT(-0500)] <Bosmon> Which sounds like exactly the situation you are facing....
[15:06:33 CDT(-0500)] <NickMayne> Shall I comment it out?
[15:06:46 CDT(-0500)] <am33sh> colinclark : can you look at the patch...
[15:07:02 CDT(-0500)] <Bosmon> So as a "random stab" you could just try replacing the "viewAccessor" in your configuration with the standard one
[15:07:29 CDT(-0500)] <NickMayne> okay
[15:07:33 CDT(-0500)] <NickMayne> Whats the default one?
[15:07:41 CDT(-0500)] <Bosmon> I guess as the most brutal "random stab" you could try commenting out one or other of those two lines in the function there
[15:08:41 CDT(-0500)] <Bosmon> Clearly they are sort of redundant with each other, but were necessary with TinyMCE 2.3.1
[15:08:41 CDT(-0500)] <NickMayne> giving it a go!
[15:08:54 CDT(-0500)] <Bosmon> 3.2.3.1?
[15:09:04 CDT(-0500)] <colinclark> that's a lot of dots
[15:09:12 CDT(-0500)] <Bosmon> Looks like the version in our CDN is from mid-2009
[15:09:47 CDT(-0500)] <NickMayne> 3.4.8
[15:09:52 CDT(-0500)] <NickMayne> is the one im using
[15:09:58 CDT(-0500)] <NickMayne> Yeah your is old!
[15:09:58 CDT(-0500)] <colinclark> am33sh: I'm thinking jhung and Justin_o are probably the best ones to review your patches, since they filed the issues. From a quick glance, they look very helpful
[15:10:40 CDT(-0500)] <Bosmon> Ok... if tinkering with that function makes any difference, we'll tell you how to configure it without having to patch our code
[15:10:53 CDT(-0500)] <Bosmon> If it doesn't, please send the zip over to me and I'll have a look at what seems to be causing the problem
[15:11:02 CDT(-0500)] <NickMayne> hmmm
[15:11:12 CDT(-0500)] <am33sh> cloinclark : okay, thanks
[15:11:20 CDT(-0500)] <NickMayne> nope, commented both lines out, but still happening
[15:12:20 CDT(-0500)] <am33sh> justion_o : I have fixed bug FLUID-4405. can you look at the patch please
[15:12:46 CDT(-0500)] <am33sh> jhung : I have fixed bug FLUID-4066. can you look at the patch please.
[15:13:48 CDT(-0500)] <jhung> am33sh, looking at it now.
[15:14:21 CDT(-0500)] <NickMayne> Ooooo
[15:14:22 CDT(-0500)] <am33sh> jhung : okay
[15:14:26 CDT(-0500)] <NickMayne> I found the problem line.
[15:14:57 CDT(-0500)] <NickMayne> line 193
[15:15:28 CDT(-0500)] <NickMayne> in this method fluid.deadMansBlur(that.editField,
[15:15:43 CDT(-0500)] <NickMayne> there is a handler that has this inside... that.cancel();
[15:15:57 CDT(-0500)] <NickMayne> If you comment that out (that.cancel() then it stops the flicker
[15:22:51 CDT(-0500)] <NickMayne> Bosman : any ideas?
[15:26:48 CDT(-0500)] <jhung> am33sh: Patch to FLUID-4066 looks fine to me. I'll have someone commit it to the repository. Thanks for fixing that.
[15:27:38 CDT(-0500)] <am33sh> jhung : im glab i could help, thanks
[15:28:01 CDT(-0500)] <am33sh> jung : *glad
[15:28:30 CDT(-0500)] <am33sh> justion_o : any review on patch sir.
[15:29:03 CDT(-0500)] <am33sh> Justin_o : any review on patch
[15:29:38 CDT(-0500)] <Justin_o> am33sh: i was quickly looking at your patch for FLUID-4405.. it looks the like you may have some invalid markup. I don't think you can next <p> inside of <span>
[15:29:43 CDT(-0500)] <Bosmon> NickMayne - fascinating
[15:30:07 CDT(-0500)] <Bosmon> Yes, the purpose of this method is to recognise whether the user has transferred focus out of the editor window
[15:30:07 CDT(-0500)] <NickMayne>
[15:30:15 CDT(-0500)] <colinclark> Justin_o: that's right. <span> is a line level element and <p> is block level.
[15:30:22 CDT(-0500)] <am33sh> Justin_o : okay
[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:39:29 CDT(-0500)] <Bosmon> The path is src/webapp/tests/test-core/utils/js/DebugFocus.js
[15:40:05 CDT(-0500)] <Bosmon> So, what you expect to see is a focus event following very shortly after the blur event which we are handling on the editField
[15:40:24 CDT(-0500)] <Bosmon> And that focus event will be on SOMETHING.... presumably something which is in part of the guts of the TinyMCE editor
[15:40:39 CDT(-0500)] <Bosmon> And presumably there is also some good reason why this thing is not nested within the node which you got for "editorBody" : P
[15:41:10 CDT(-0500)] <NickMayne> just getting the file now.
[15:41:37 CDT(-0500)] <Bosmon> I think all you need to do is just include the file
[15:41:44 CDT(-0500)] <Bosmon> And also call fluid.setLogging(true)
[15:42:13 CDT(-0500)] <Bosmon> Unfortunately this is the kind of thing that can only be debugged in this kind of caveman style
[15:42:29 CDT(-0500)] <Bosmon> Since any attempt to insert breakpoints into the focus/blur processing chain typically makes the browser go bananas
[15:42:59 CDT(-0500)] <Bosmon> Especially, since as is the case in many modern browsers, the debugger UI itself is a plentiful source of focus/blur events itself : P
[15:44:22 CDT(-0500)] <NickMayne> yeah an im using Firefox 12 beta 2
[15:44:39 CDT(-0500)] <NickMayne> Okay Im ready!!
[15:45:10 CDT(-0500)] <Bosmon> Well, you can imagine that, given the age of some of this code, something which counts as "modern" is probably Firefox 3.0 or later
[15:45:36 CDT(-0500)] <Bosmon> Go for it!
[15:46:41 CDT(-0500)] <Bosmon> Ok, I got your zip package, thanks
[15:46:44 CDT(-0500)] <Bosmon> I'll have a poke myself too
[15:47:14 CDT(-0500)] <NickMayne> lol
[15:47:15 CDT(-0500)] <NickMayne>
[15:47:20 CDT(-0500)] <NickMayne> Okay got soem results
[15:48:18 CDT(-0500)] <NickMayne> http://pastie.org/3674071
[15:48:28 CDT(-0500)] <NickMayne> So I get that on the first 'Edit' click
[15:48:32 CDT(-0500)] <Bosmon> I don't actually see any HTML files in the zip file you sent me.....
[15:48:55 CDT(-0500)] <NickMayne> Oh!
[15:49:22 CDT(-0500)] <Bosmon> But actually I think this transcript you sent may be enough to help
[15:49:22 CDT(-0500)] <NickMayne> The site is built up dynamically
[15:49:30 CDT(-0500)] <Justin_o> am33sh: I've merged FLUID-4066, thanks for the patch
[15:49:46 CDT(-0500)] <Bosmon> I read about this "new" approach to rich text editing on the CodeMirror guy's blog
[15:49:50 CDT(-0500)] <NickMayne> I have updated the paste bin
[15:49:50 CDT(-0500)] <NickMayne> http://pastie.org/3674071
[15:50:05 CDT(-0500)] <NickMayne> If I click n edit the second time.
[15:50:28 CDT(-0500)] <Bosmon> IT seems that the REAL textarea itself is used as the direct source of browser manipulation, rather than a "dumb proxy" as it in older styles....
[15:51:01 CDT(-0500)] <avtar> anastasiac_: are you still seeing a "sys.stdout access restricted by mod_wsgi" error when going to http://localhost:8000/authoring/new ?
[15:51:05 CDT(-0500)] <Bosmon> So, all you should need to do is to add the textarea itself to the exclusions
[15:51:19 CDT(-0500)] <Bosmon> So, for example, try something like this:
[15:51:33 CDT(-0500)] <Bosmon> at line 189,
[15:51:35 CDT(-0500)] <Bosmon> fluid.deadMansBlur(that.editField,
[15:51:36 CDT(-0500)] <Bosmon> {
[15:51:36 CDT(-0500)] <Bosmon> exclusions: ,
[15:51:45 CDT(-0500)] <Bosmon> oops
[15:51:53 CDT(-0500)] <NickMayne> thats what currently there right?
[15:52:01 CDT(-0500)] <anastasiac_> avtar, yes, but I haven't done anything to try to fix it
[15:52:03 CDT(-0500)] <Bosmon> fluid.deadMansBlur(that.editField,
[15:52:04 CDT(-0500)] <Bosmon> {
[15:52:04 CDT(-0500)] <Bosmon> exclusions: , area: $(that.editField)},
[15:52:05 CDT(-0500)] <Bosmon> ....
[15:52:19 CDT(-0500)] <Bosmon> So, that is, add an extra entry to "exclusions" to include the edit field itself
[15:52:47 CDT(-0500)] <NickMayne> okay lets give it a go!
[15:53:22 CDT(-0500)] <am33sh> Justin_o : sir, if use <p> before the <span> then that will be valid markup
[15:54:55 CDT(-0500)] <NickMayne> http://pastie.org/3674126
[15:55:00 CDT(-0500)] <NickMayne> thats the HTML markup.
[15:55:03 CDT(-0500)] <NickMayne> Want the CSS?
[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:00:53 CDT(-0500)] <NickMayne> live test site maybe easier... let me see!
[16:01:01 CDT(-0500)] <Bosmon> cool
[16:03:13 CDT(-0500)] <NickMayne> going to build the solution
[16:03:16 CDT(-0500)] <NickMayne> Zip it
[16:03:24 CDT(-0500)] <NickMayne> Do you have an FTP folder?
[16:03:45 CDT(-0500)] <Bosmon> I don't... but I can receive pretty big mails
[16:03:47 CDT(-0500)] <Bosmon> How much is it?
[16:04:01 CDT(-0500)] <NickMayne> not sure yet... its building
[16:04:45 CDT(-0500)] <avtar> anastasiac_ & michelle: here is a less rant-y piece of documentation explaining that change (option #2) http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Writing_To_Standard_Output
[16:09:43 CDT(-0500)] <NickMayne> nearly have it ready
[16:13:32 CDT(-0500)] <NickMayne> Bosmon: Sent you a site
[16:13:35 CDT(-0500)] <NickMayne> its very small
[16:13:37 CDT(-0500)] <Bosmon> Got it
[16:13:39 CDT(-0500)] <Bosmon> This should be fun
[16:13:43 CDT(-0500)] <NickMayne> but should have everyting you need in it!
[16:14:40 CDT(-0500)] <NickMayne>
[16:15:20 CDT(-0500)] <Bosmon> Interestingly it seems to work fine on Chrome....
[16:15:32 CDT(-0500)] <Bosmon> What I should see is that when I save an edit, it reverts, right?
[16:15:41 CDT(-0500)] <NickMayne> yeah let me see
[16:15:57 CDT(-0500)] <NickMayne> Hmmm yes
[16:16:02 CDT(-0500)] <NickMayne> It works fine in Chrome.
[16:16:09 CDT(-0500)] <Bosmon> Hilarious
[16:16:27 CDT(-0500)] <NickMayne> Doesnt work at all in IE!
[16:16:57 CDT(-0500)] <NickMayne> oh wait, it does... it asked me to unblock activex controls!
[16:17:01 CDT(-0500)] <Bosmon> Ok
[16:17:05 CDT(-0500)] <NickMayne> Seems like its only Firefox so far.
[16:17:09 CDT(-0500)] <Bosmon> I can promise you I'll get it working on FF
[16:17:11 CDT(-0500)] <Bosmon> All bets are off for IE
[16:17:26 CDT(-0500)] <NickMayne> At least its not IE6
[16:17:48 CDT(-0500)] <Bosmon> IE8 is bad enough - a lot of the complexity you see there in fluid.deadMansBlur is to deal with IE8
[16:18:21 CDT(-0500)] <NickMayne> Argh!!
[16:18:41 CDT(-0500)] <Bosmon> Which is capable of firing the focus event BEFORE the blur event that it corresponds to
[16:18:51 CDT(-0500)] <Bosmon> So we have to have an implementation which can REACH BACK IN TIME
[16:18:58 CDT(-0500)] <Bosmon> In order to respond to blur events before they happen....
[16:19:43 CDT(-0500)] <NickMayne> timetravel, is that what im reading?
[16:20:08 CDT(-0500)] <Bosmon> Ok, so I think the problem we are seeing here is that the focus is actually transferring to NOTHING
[16:21:33 CDT(-0500)] <Bosmon> So, on Chrome, the initial blur event doesn't actually fire at all
[16:21:45 CDT(-0500)] <NickMayne> why would that be?
[16:22:01 CDT(-0500)] <Bosmon> Well, that's actually proper... there's no really good reason for there to be a blur here
[16:22:13 CDT(-0500)] <Bosmon> Whereas it looks like whatever TinyMCE does on FF after creating its markup looks like it throws the focus off the textarea immediately after the click
[16:25:38 CDT(-0500)] <NickMayne> I amm looking at some of the tinymce change history
[16:25:48 CDT(-0500)] <NickMayne> doesnt look like they have changed much around focus
[16:26:00 CDT(-0500)] <Bosmon> No, it won't be through calling focus themselves
[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:43:41 CDT(-0500)] <Bosmon> Well, actually it doesn't transfer the focus, we do...
[16:44:00 CDT(-0500)] <Bosmon> I mean, there are lots of easy hacks to fix this, but I'm trying to understand before we start hacking, where the original focus() event goes
[16:44:17 CDT(-0500)] <Bosmon> MCE clearly thinks its trying to focus something, but somehow the focus event becomes stomped on completely
[16:44:28 CDT(-0500)] <Bosmon> Presumably through some subtle interaction between jquery and the browser
[16:45:10 CDT(-0500)] <NickMayne> Im not a project manager I prefer the proper fix!
[16:45:40 CDT(-0500)] <Bosmon> You can see the line in MCE's _refreshContentEditable
[16:45:43 CDT(-0500)] <Bosmon> It calls body.focus()
[16:45:52 CDT(-0500)] <Bosmon> But mysteriously, no focus event ever arises
[16:46:06 CDT(-0500)] <Bosmon> Only a synthetic jQuery "focusout" event corresponding to believing that someone has blurred something
[16:47:01 CDT(-0500)] <NickMayne> oh yeah
[16:47:04 CDT(-0500)] <NickMayne> I can see that code
[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:50:46 CDT(-0500)] <Bosmon> Wow... so, the situation is pretty awful
[16:50:50 CDT(-0500)] <Bosmon> I commented out our call to "focus"
[16:50:54 CDT(-0500)] <Bosmon> And naturally, the problem goes away
[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:02 CDT(-0500)] <Bosmon> So, all of the "editing gubbins" that MCE creates consists of divs, spans, etc, generally "junk DOM elements"
[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
[16:57:55 CDT(-0500)] <Bosmon> Yes, it is
[16:58:14 CDT(-0500)] <Bosmon> It's a positively medieval 1990s-style strategy : P
[16:58:23 CDT(-0500)] <NickMayne> I didnt see the iframe?
[16:58:25 CDT(-0500)] <Bosmon> So, the "unfocusable element" which FF refuses to generate a focus event for is actually of type BODY!
[16:58:52 CDT(-0500)] <Bosmon> You can see it if you tinker about in Firebug a bit, after the editor is created
[16:59:02 CDT(-0500)] <NickMayne> k will look
[16:59:25 CDT(-0500)] <Bosmon> In particular, if you set a breakpoint on line 402 of FluidView.js, you can get to see the whole stack
[16:59:31 CDT(-0500)] <NickMayne> argh oh yeah
[16:59:34 CDT(-0500)] <NickMayne> I see it
[16:59:38 CDT(-0500)] <NickMayne> I must have ignored it before
[16:59:40 CDT(-0500)] <Bosmon> At the time that the "fictitious blur event" begins to propagate
[16:59:53 CDT(-0500)] <Bosmon> If you hop down into TinyMCE's stack, you can see its thing called "body"
[16:59:55 CDT(-0500)] <Bosmon> Which really IS a body!
[16:59:59 CDT(-0500)] <Bosmon> It's the body inside the iframe
[17:00:46 CDT(-0500)] <Bosmon> Using iframes in the 2010s is just a symptom of utter laziness...
[17:00:52 CDT(-0500)] <Bosmon> Anyway, we will need to do a couple of things for a fix
[17:01:52 CDT(-0500)] <NickMayne> Okay.
[17:02:33 CDT(-0500)] <NickMayne> is doesnt look like tinymce have an option to switch iframe off
[17:02:38 CDT(-0500)] <NickMayne> it doesnt*
[17:03:11 CDT(-0500)] <Bosmon> Well, the "iframe strategy" is baked into their codebase right down to the ground
[17:03:17 CDT(-0500)] <Bosmon> They would need a 100% rewrite to get rid of it
[17:03:36 CDT(-0500)] <Bosmon> Which is probably one of the reasons it stopped being our preferred editing framework
[17:03:43 CDT(-0500)] <Bosmon> Although I can't remember that we decided on any alternative
[17:04:01 CDT(-0500)] <Bosmon> Anyway, it's current, so we should figure out how to work with it
[17:04:16 CDT(-0500)] <NickMayne> http://www.tinymce.com/forum/viewtopic.php?id=25800
[17:04:22 CDT(-0500)] <NickMayne> someone asked about removing it
[17:04:28 CDT(-0500)] <Bosmon> haha
[17:04:42 CDT(-0500)] <NickMayne> The admin basically said no
[17:04:43 CDT(-0500)] <NickMayne> lol
[17:04:59 CDT(-0500)] <Bosmon> The admin barely seemed to register the force behind the question : P
[17:05:06 CDT(-0500)] <NickMayne> I know.
[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:14:38 CDT(-0500)] <Bosmon> So detecting both genuine mouse click events, AND genuine focus events should detect everything that is worth detecting
[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.
[17:35:01 CDT(-0500)] <NickMayne> Have a good evening