/irc-logs / mozilla / #accessibility / 2012-02-29 / end

Options:

  1. # Session Start: Wed Feb 29 00:00:00 2012
  2. # Session Ident: #accessibility
  3. # [00:16] <@firebot> jh@junetz.de set status-firefox11 to fixed on bug 718235.
  4. # [00:17] <@firebot> jh@junetz.de set status-firefox12 to fixed on bug 718235.
  5. # [00:17] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=718235 maj, --, ---, nobody, NEW, [SeaMonkey] "a11y/accessible/events/test_focus_general.html | Doubled event { event type: focus, tar
  6. # [01:20] * Joins: Delo (Delo@C44ED466.ADB1091F.4C07D37A.IP)
  7. # [01:22] * khuey is now known as khuey|away
  8. # [01:23] * Parts: Delo (Delo@C44ED466.ADB1091F.4C07D37A.IP)
  9. # [01:25] * Joins: surkov (surkov@D5570440.C1645F5A.34044A7F.IP)
  10. # [01:25] * ChanServ sets mode: +o surkov
  11. # [01:27] * Quits: satdav (satdav@moz-1ECB932B.cable.virginmedia.com) (Quit: Leaving)
  12. # [01:51] * Quits: @jprmc (jprmc@F2D29657.F60B0462.67AC9B1.IP) (Ping timeout)
  13. # [02:00] <@tbsaunde> surkov: wouldn't it make more sense for nsCOreUtils::GetDOMElementFor() to return a dom::Element? or can we just use some sort of method that content provides to do what it does?
  14. # [02:01] <@surkov> tbsaunde: it makes sense
  15. # [02:03] <@eeejay> surkov, yo?
  16. # [02:03] <@surkov> eeejay: yo!
  17. # [02:04] <@eeejay> surkov, hello from san diego. what did you mean when you said "it sounds like those are empty changesets"?
  18. # [02:04] <@surkov> eeejay: open that link and look at changeset
  19. # [02:04] <@surkov> both are empty (no changes)
  20. # [02:05] <@eeejay> surkov, doh!
  21. # [02:05] <@eeejay> surkov, i get it :)
  22. # [02:05] <@surkov> :)
  23. # [02:06] * Quits: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP) (Input/output error)
  24. # [02:07] * khuey|away is now known as khuey
  25. # [02:14] <@tbsaunde> surkov: think its worth a bug
  26. # [02:15] <@surkov> tbsaunde: ok, I will
  27. # [02:21] * Joins: jprmc (jprmc@A6CB2BBF.5BCEC6DB.DA78B690.IP)
  28. # [02:21] * ChanServ sets mode: +o jprmc
  29. # [02:26] <@tbsaunde> surkov: err, that was meant as a question if it wasn't clear
  30. # [02:26] <@surkov> ok, anyway :)
  31. # [02:31] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
  32. # [02:42] <@tbsaunde> surkov: how would you feel about the TextAttrMgr having two constructors one for each use case tht call a private member function?
  33. # [02:48] <@surkov> tbsaunde: Im not sure I follow you
  34. # [02:48] <@tbsaunde> surkov: I mean currently the manager has a constructor with a bunch of optional args and it expects to get either non or all right?
  35. # [02:49] <@surkov> ah, I see, I'd say this make sense
  36. # [02:49] <@tbsaunde> my suggestion was that we just have two different constructors
  37. # [02:49] <@surkov> put that into bug, I'll address this
  38. # [02:49] <@surkov> gotta go
  39. # [02:49] * Quits: @surkov (surkov@D5570440.C1645F5A.34044A7F.IP) (Quit: surkov)
  40. # [02:49] <@tbsaunde> ok, I'll comment in bug then
  41. # [03:07] * Quits: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com) (Quit: nhirata)
  42. # [03:21] * Quits: @jprmc (jprmc@A6CB2BBF.5BCEC6DB.DA78B690.IP) (Ping timeout)
  43. # [04:13] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  44. # [04:15] * Joins: jprmc (jprmc@moz-7F2FF3EB.cpe.net.cable.rogers.com)
  45. # [04:15] * ChanServ sets mode: +o jprmc
  46. # [04:34] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Ping timeout)
  47. # [04:34] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  48. # [05:58] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
  49. # [05:59] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  50. # [06:29] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Client exited)
  51. # [06:31] * Joins: Mark_Capella (chatzilla@moz-DD0C7E4F.twcny.res.rr.com)
  52. # [07:22] * Joins: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP)
  53. # [07:33] * khuey is now known as khuey|away
  54. # [07:37] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
  55. # [07:38] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  56. # [08:07] <@firebot> masayuki@d-toybox.com requested review from limi@mozilla.com for attachment 601536 on bug 728103.
  57. # [08:07] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=728103 nor, --, ---, masayuki, NEW, Shouldn't we change modifier for HTML accesskey from Control to Control + Option?
  58. # [08:08] <@firebot> masayuki@d-toybox.com requested review from bugs@pettay.fi for attachment 601537 on bug 728103.
  59. # [08:16] * Joins: victorporof (victorporo@B61018A3.6465CCD9.79933D60.IP)
  60. # [08:36] * khuey|away is now known as khuey
  61. # [08:36] * Joins: surkov (surkov@3F544E90.26ED71FF.34044A7F.IP)
  62. # [08:36] * ChanServ sets mode: +o surkov
  63. # [09:19] * Quits: Mark_Capella (chatzilla@moz-DD0C7E4F.twcny.res.rr.com) (Connection reset by peer)
  64. # [09:19] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Ping timeout)
  65. # [09:20] * Joins: Mark_Capella (chatzilla@moz-DD0C7E4F.twcny.res.rr.com)
  66. # [09:21] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  67. # [09:56] * khuey is now known as khuey|away
  68. # [10:58] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
  69. # [11:54] * Quits: victorporof (victorporo@B61018A3.6465CCD9.79933D60.IP) (Ping timeout)
  70. # [12:19] * Quits: @surkov (surkov@3F544E90.26ED71FF.34044A7F.IP) (Quit: surkov)
  71. # [12:40] * Joins: askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es)
  72. # [12:40] * ChanServ sets mode: +o askalski
  73. # [12:40] <@askalski> hi tbsaunde, is surkov here?
  74. # [13:28] * Joins: surkov (surkov@3F544E90.26ED71FF.34044A7F.IP)
  75. # [13:28] * ChanServ sets mode: +o surkov
  76. # [13:39] * Quits: @jprmc (jprmc@moz-7F2FF3EB.cpe.net.cable.rogers.com) (Ping timeout)
  77. # [13:40] <@askalski> hi surkov
  78. # [13:40] <@askalski> got a minute?
  79. # [13:40] <@surkov> askalski: hi, sure
  80. # [13:40] <@askalski> ok
  81. # [13:40] <@askalski> so I've been embedding this LED algorithm
  82. # [13:41] <@askalski> and I noticed, there is no event for "substitute"
  83. # [13:41] <@askalski> right?
  84. # [13:41] <@askalski> David told me, you use two events instead ("delete" + "add") right?
  85. # [13:41] <@askalski> (TextUpdater)
  86. # [13:42] <@surkov> askalski: that's correct
  87. # [13:42] <@surkov> I didn't have a time to implement it
  88. # [13:42] <@askalski> surkov, ok. so is there a plan to add this 'substitute' event or not?
  89. # [13:42] <@askalski> because if not, that we should change the algorithm
  90. # [13:42] <@surkov> yes
  91. # [13:43] <@askalski> ok. is it something I can do?
  92. # [13:43] <@surkov> sure you can if you want :)
  93. # [13:43] <@surkov> that'd be nice
  94. # [13:44] <@askalski> ok. because now it's sub optimal
  95. # [13:44] <@askalski> and if we don't have 'substitute' event, we should use LCS instead of LED
  96. # [13:45] <@askalski> so I spoke with David, it seemed like we should do LCS
  97. # [13:45] <@askalski> but if I can use 'substitute' event then we can stay with LED
  98. # [13:45] <@askalski> David told me it's your call
  99. # [13:46] <@surkov> it's always better one event than two, APIs provide text updated event so that's the way to go
  100. # [13:46] <@askalski> LCS = Longest Common Subsequence, the metric equals to LED while 'substitute' is either illegal or costs twice as much
  101. # [13:47] <@surkov> so I'd say you should go with LED
  102. # [13:54] <@askalski> surkov, OK. So I'll just add third event like "add" and "delete" and call it "substitute", it seems like all do the same thing
  103. # [13:55] <@surkov> askalski: do you talk about event type or event class?
  104. # [13:56] <@askalski> surkov, method, they all just call
  105. # [13:56] <@askalski> AccTextChangeEvent
  106. # [13:57] <@askalski> right?
  107. # [13:57] <@surkov> ok, then you need to fit AccTextChangeEvent for substitutions
  108. # [13:57] <@surkov> but wouldn't you want to keep that separately and map substitute to insert and delete pair as we do now?
  109. # [13:57] <@askalski> surkov, well, insert and delete look precisely the same...
  110. # [13:58] <@surkov> anyway, I meant to not tweak AccTextChangeEvent for now
  111. # [13:58] <@surkov> otherwise your patch will be more complicated
  112. # [13:58] <@askalski> surkov, OK... so I can separate it into two patches
  113. # [13:59] <@surkov> and maybe in two bugs :)
  114. # [13:59] <@askalski> but we'll end-up with suboptimal solutions before that gets fixed
  115. # [13:59] <@askalski> *until
  116. # [13:59] <@surkov> yep, but if you're on that way then it's ok
  117. # [13:59] <@askalski> I mean LED will promote non-optimal transformations
  118. # [14:00] <@askalski> well, I can write anything. that's why I ask you
  119. # [14:00] <@surkov> we need to try to get it fixed on the same release'
  120. # [14:00] <@askalski> yesterday I thought I just implement CLS instead
  121. # [14:00] <@askalski> *LCS
  122. # [14:00] <@askalski> ok. and below this AccTextChangeEvent, is there a real support for substitution in devices we comunicate with?
  123. # [14:00] <@askalski> because if there's not, it's pointles
  124. # [14:01] <@surkov> IA2 has text_update event
  125. # [14:01] <@surkov> I think ATK has the same
  126. # [14:01] <@askalski> surkov, ok, so what we want to optimise for?
  127. # [14:02] <@askalski> I mean
  128. # [14:02] <@askalski> minimize the number of events
  129. # [14:02] <@surkov> yes
  130. # [14:02] <@askalski> or minimize the summaric range of text that we call it for
  131. # [14:03] <@askalski> well, if just events, then the cap is always 1 or 2, because we can always say "everything has been replaced ,refresh"
  132. # [14:03] <@askalski> if summaric range, then either LED or LCS
  133. # [14:03] <@askalski> depending on whether there is underlying support for substitution or not
  134. # [14:03] <@surkov> right, but that's should reflect some real life :)
  135. # [14:04] <@askalski> well yes, but if the underlying application will invalidate entire region anyway, that would be optimal, right?
  136. # [14:04] <@surkov> we might have different behavior depending on where the user are, if it goes from focused control then we want to be preceise
  137. # [14:04] <@surkov> if it goes form somewhere then we might want to fire less events
  138. # [14:05] <@askalski> so should I write more methods to text updater?
  139. # [14:05] <@surkov> askalski: underlying application is supposed to announce the change sometimes
  140. # [14:05] <@surkov> and in this case that'll be strange
  141. # [14:05] <@askalski> because the example I gave David yesterday is following
  142. # [14:05] <@askalski> we have string aabababa changing to 8*a
  143. # [14:06] <@askalski> we can either fire 3 substitutions (as 6 events now) or just two
  144. # [14:06] <@surkov> in this case this is likely replace :)
  145. # [14:06] <@askalski> what do you mean?
  146. # [14:07] <@surkov> I mean one substitution event
  147. # [14:07] <@surkov> any way, I don't have good answer and probably nobody has. Can we code two options?
  148. # [14:07] <@surkov> so we can switch between them on case by case basis
  149. # [14:09] <@surkov> so if we talk about app buffer update then result should be correlated depending on the string and events number
  150. # [14:09] <@surkov> through that's not evident and might not true
  151. # [14:12] <@askalski> there is no problem with implementing multiple options
  152. # [14:13] <@askalski> so what options should I implement LED and LCS? Or some heurestics that - for example - aggregates close changes into single event (with closeness factor as argument)?
  153. # [14:14] <@surkov> events aggregation is different from having or not having a substitutetion event option?
  154. # [14:15] <@askalski> it's the example I gave you in 3 b's
  155. # [14:15] <@askalski> we can either consider them different entities
  156. # [14:15] <@askalski> or say 'update babab to aaaaa' as single substitution, or pair 'delete' and 'add'
  157. # [14:15] <@surkov> I'd say to go with substitution approach, for optimization, I'd wanted to see two options: aggregate events and not aggregate events
  158. # [14:15] <@askalski> so 1, 2, 3 or 6 operations, depending on substitution support and aggregation
  159. # [14:16] <@askalski> aggregation with substitution (variant for LED) would be absolutely thoughtest to implement I guess
  160. # [14:16] <@surkov> what is thoughtest?
  161. # [14:17] <@askalski> well, generally LCS is the oldest problem, best recognized, and easiest to code
  162. # [14:17] <@askalski> two - LED is though, but I hacked it already
  163. # [14:17] <@askalski> aggregation is something I'd have too look for, but generally, "fuzzy" matching is complex
  164. # [14:18] <@askalski> it's used for example in DNA comparison, so it's developing right now
  165. # [14:18] <@askalski> so there are algorithms, but internet is not yet full of example implementations, rather some fresh papers on the subject
  166. # [14:19] <@surkov> ok, I see, we can do that later
  167. # [14:19] <@surkov> you just should keep in mind that when you cod
  168. # [14:19] <@surkov> e
  169. # [14:20] <@surkov> do I understand that LED is faster on substations and you implemented it already?
  170. # [14:20] <@surkov> if so then what's disadvantages of it?
  171. # [14:21] <@askalski> if we have no substitution operation, it's just emulated with pair 'delete' and 'add'
  172. # [14:21] <@askalski> LED will promote sub-optimal matches
  173. # [14:21] <@askalski> thus generating more events
  174. # [14:21] <@askalski> not much more
  175. # [14:21] <@askalski> but more
  176. # [14:21] <@askalski> LCS on the other hand would find best possible matches
  177. # [14:22] <@askalski> and possibly work a little bit faster, as it has easier definition
  178. # [14:22] <@surkov> I see
  179. # [14:22] <@askalski> my guess is
  180. # [14:23] <@askalski> that the answer sholud be made basing on capabilities of underlying APIs
  181. # [14:23] <@surkov> they are capable as I said
  182. # [14:23] <@surkov> not sure about OS X though
  183. # [14:23] <@askalski> so they both have a single 'text_update' event?
  184. # [14:24] <@askalski> ok, another quick question
  185. # [14:24] <@askalski> there are calls to Acc, with "text update event" and range, right?
  186. # [14:24] <@surkov> ATK and IA2 yes
  187. # [14:25] <@askalski> ok
  188. # [14:25] <@surkov> iirc text and range
  189. # [14:25] <@askalski> but if I remove/delete even a single character
  190. # [14:25] <@surkov> that's a text update you mean?
  191. # [14:25] <@askalski> then everything after this character is shifted, therefore we can say, that all positions after has changed
  192. # [14:26] <@askalski> I am talking specifically about new AccTextChangeEvent(mHyperText, mTextOffset + aAddlOffset, aText, true);
  193. # [14:26] <@surkov> that's ok, but why would we need to say this?
  194. # [14:26] <@surkov> you provide the text and its offsets
  195. # [14:28] * Joins: jprmc (jprmc@7641BDDC.5BCEC6DB.DA78B690.IP)
  196. # [14:28] * ChanServ sets mode: +o jprmc
  197. # [14:28] <@askalski> ok, I provide a substring (either added or deleted, methods are the same)
  198. # [14:28] <@askalski> and that's it
  199. # [14:28] <@askalski> right?
  200. # [14:29] <@askalski> I mean a part of old or new string that have been either added or deleted,
  201. # [14:29] <@askalski> respectively
  202. # [14:29] <@surkov> yes
  203. # [14:29] <@askalski> ok. what should I put in, if I write this substitute?
  204. # [14:31] <@surkov> askalski: sorry, rephrase please
  205. # [14:31] <@askalski> imagine I embedded LED into TextUpdate
  206. # [14:32] <@askalski> as we decided, that substitution is an advantage, not a loss
  207. # [14:32] <@askalski> then
  208. # [14:32] <@askalski> I need to create new method in TextUpdater.h
  209. # [14:32] <@askalski> say inline void FireSubstituteEvent(const nsAString& aText, PRUint32 aAddlOffset, nsTArray<nsRefPtr<AccEvent> >& aEvents)
  210. # [14:33] <@askalski> (by analogy)
  211. # [14:33] <@surkov> ok
  212. # [14:33] <@askalski> that basically wraps nsRefPtr<AccEvent> event =
  213. # [14:33] <@askalski> new AccTextChangeEvent(mHyperText, mTextOffset + aAddlOffset,
  214. # [14:33] <@askalski> aText, true);
  215. # [14:33] <@askalski> aEvents.AppendElement(event);
  216. # [14:33] <@surkov> you need to change AccTextChangeEvent
  217. # [14:34] <@askalski> into what?
  218. # [14:34] <@askalski> ah, ok,
  219. # [14:34] <@askalski> let me look at it
  220. # [14:34] <@askalski> got it
  221. # [14:34] <@askalski> EVENT_TEXT_CHANGED = 48U,
  222. # [14:34] <@askalski> EVENT_TEXT_INSERTED = 49U,
  223. # [14:34] <@askalski> EVENT_TEXT_REMOVED = 50U,
  224. # [14:34] <@askalski> EVENT_TEXT_UPDATED = 51U,
  225. # [14:35] <@askalski> I should expand it with support for either 48 or 51 u, right?
  226. # [14:36] <@surkov> 51U
  227. # [14:36] <@surkov> we need to remove EVENT_TEXT_CHANGED I think
  228. # [14:36] <@surkov> but that's separate
  229. # [14:36] <@askalski> should I fill the bug for that as well?
  230. # [14:37] <@askalski> ok, and with "updated" I should pass a substring of an old string, or new string?
  231. # [14:37] <@surkov> if we don't have then please
  232. # [14:37] <@surkov> both
  233. # [14:38] <@askalski> so I would need to refactor AccTextChangeEvent and all it's calls, right?
  234. # [14:38] <@surkov> yes
  235. # [14:38] <@askalski> OK
  236. # [14:38] <@surkov> thus I said you should deal with it separately
  237. # [14:39] <@askalski> so let me summarize it: we're going with LED, adding substitution support by refactoring and filling some minor bug reports
  238. # [14:39] <@askalski> sound like a good week plan
  239. # [14:39] <@askalski> I will work it in separate bugs
  240. # [14:40] <@askalski> is this OK?
  241. # [14:43] <@askalski> surkov, ^
  242. # [14:44] <@surkov> yes
  243. # [14:45] <@surkov> askalski: there's possible underground problem: some ATs might not listen text update event :)
  244. # [14:45] <@askalski> surkov, ok. is it something I should think of while doing the stuff above right now?
  245. # [14:45] <@surkov> askalski: so in general having substituion means lesser events than insert/delete?
  246. # [14:46] <@surkov> I means LED vs LCS
  247. # [14:46] <@askalski> surkov, in general - yes, say aba -> aca
  248. # [14:46] <@askalski> but there will be special cases
  249. # [14:46] <@surkov> ok, so, it could be then we won't enable text update events for a while until ATs picked it up
  250. # [14:47] <@askalski> when LED would promote substitution, and if we replace substitution with two calls, this - summarized - will be suboptimal than what LCS would find knowing that substitution is costly
  251. # [14:47] <@askalski> surkov, yes, but then again
  252. # [14:48] <@askalski> if it's really just about informing AT that some text has been updated
  253. # [14:48] <@askalski> why do we bother about calculating precise change-ranges in the first place?
  254. # [14:48] <@askalski> can't we just fire event common_prefix_end - common_suffix_beginning
  255. # [14:48] <@askalski> single event, all information there
  256. # [14:49] <@askalski> no additional computation
  257. # [14:49] <@surkov> in general no, but we care about to report them about user input - we can't do that so we do a guess on our side and we should try to do a best guess
  258. # [14:49] <@askalski> hmm
  259. # [14:49] <@askalski> so maybe
  260. # [14:50] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  261. # [14:50] <@askalski> (I know it's a long shot)
  262. # [14:50] * Quits: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP) (Input/output error)
  263. # [14:50] <@askalski> divide text modification into two possibilites
  264. # [14:50] <@askalski> one is user input, which is always just input events
  265. # [14:50] <@askalski> aggregate them in some buffer and send each time AT picked up
  266. # [14:50] <@askalski> and second would be some java-inferred changes
  267. # [14:50] <@askalski> or total CTRL-A, CTRL-V
  268. # [14:51] <@askalski> I mean, this is like parsing input results to deduce about input
  269. # [14:51] <@askalski> if that's the only option - ok, let's do it
  270. # [14:51] <@askalski> but otherwise...
  271. # [14:51] <@surkov> when we get text was maybe updated notification then we don't know whether it was from user input or not
  272. # [14:52] <@askalski> surkov, ok. maybe we should complain about it on Bugzilla, so someday this information will be available?
  273. # [14:52] <@surkov> if we won't implement it then it won't be :)
  274. # [14:52] <@surkov> until we have a solution it doesn't make a big sense
  275. # [14:53] <@askalski> solution to what?
  276. # [14:53] <@surkov> how to fix that
  277. # [14:53] <@askalski> I mean lack of information whether the change is user-made or other?
  278. # [14:53] <@askalski> * you mean ... ?
  279. # [14:54] <@surkov> yes, that's layout stuffs and any a11y thing integrated into layout is hard to get
  280. # [14:54] <@surkov> anyway current algorithm looks like it gives good results for user input
  281. # [14:55] <@askalski> surkov, OK. I guess I might be overthinking this
  282. # [14:55] <@surkov> maybe nobody tested it hardly :)
  283. # [14:55] <@askalski> is common for game developers
  284. # [14:55] <@askalski> :)
  285. # [14:55] <@askalski> (I mean engine-side)
  286. # [14:55] <@askalski> so I'll go with this assignment we discussed above
  287. # [14:55] <@askalski> and then we will se
  288. # [14:55] <@askalski> *see
  289. # [14:55] <@askalski> ok?
  290. # [14:55] <@surkov> considerino all possibilities is good characteristics not only for game developers
  291. # [14:56] <@surkov> yes
  292. # [14:56] <@askalski> ok
  293. # [14:56] <@askalski> thanks
  294. # [14:57] <@askalski> I'll ask for your review of first patch somewhere around weekend
  295. # [14:58] <@surkov> ok
  296. # [15:00] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  297. # [15:04] * Quits: @askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es) (Quit: Wychodzi)
  298. # [15:04] * Joins: davidb (davidb@F2D29657.F60B0462.67AC9B1.IP)
  299. # [15:04] * ChanServ sets mode: +qo davidb davidb
  300. # [15:05] <@davidb> hi surkov, need about 20 minutes ok?
  301. # [15:05] <@davidb> before chatting
  302. # [15:05] <@surkov> ok
  303. # [15:08] * Quits: @jprmc (jprmc@7641BDDC.5BCEC6DB.DA78B690.IP) (Ping timeout)
  304. # [15:18] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  305. # [15:21] <@firebot> pppx@i.com.ua changed the Status on bug 381070 from UNCONFIRMED to RESOLVED.
  306. # [15:21] <@firebot> pppx@i.com.ua set the Resolution field on bug 381070 to WORKSFORME.
  307. # [15:21] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=381070 nor, --, ---, nobody, RESO WORKSFORME, Control Right after Home key (sometimes) does not move caret.
  308. # [15:22] <@firebot> pppx@i.com.ua changed the Status on bug 381071 from UNCONFIRMED to RESOLVED.
  309. # [15:22] <@firebot> pppx@i.com.ua set the Resolution field on bug 381071 to WORKSFORME.
  310. # [15:22] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=381071 nor, --, ---, nobody, RESO WORKSFORME, MSAA caret position mis-reported
  311. # [15:36] * khuey|away is now known as khuey
  312. # [15:44] * Joins: thiessenp (thiessenp@moz-BC938049.ebuddy.com)
  313. # [15:53] * Joins: jprmc (jprmc@F2D29657.F60B0462.67AC9B1.IP)
  314. # [15:53] * ChanServ sets mode: +o jprmc
  315. # [16:06] * Quits: thiessenp (thiessenp@moz-BC938049.ebuddy.com) (Quit: thiessenp)
  316. # [16:10] <@davidb> surkov: we don't have a synthTab right?
  317. # [16:11] <@davidb> i guess i should write a custom invoker
  318. # [16:12] <@davidb> surkov: I'm going to write a synthTabKey - sound good?
  319. # [16:13] <@davidb> oh found it!
  320. # [16:13] * @davidb facepalms
  321. # [16:14] <@davidb> grep fail
  322. # [16:15] <@surkov> davidb: we do
  323. # [16:15] <@surkov> oh, I see
  324. # [16:16] <@surkov> look at other examples, I think all you need is to pass focusChecker object to it
  325. # [16:16] <@davidb> yep
  326. # [16:16] <@davidb> easy
  327. # [16:19] * Quits: @jprmc (jprmc@F2D29657.F60B0462.67AC9B1.IP) (Quit: Leaving)
  328. # [16:19] * Joins: jprmc (jprmc@F2D29657.F60B0462.67AC9B1.IP)
  329. # [16:19] * ChanServ sets mode: +o jprmc
  330. # [16:20] <@davidb> surkov: http://people.mozilla.com/~dbolter/canvas-events.diff
  331. # [16:20] * Quits: @surkov (surkov@3F544E90.26ED71FF.34044A7F.IP) (Ping timeout)
  332. # [16:30] * Joins: victorporof (victorporo@9D98A5C0.6465CCD9.79933D60.IP)
  333. # [16:39] <@davidb> !seen askalski'
  334. # [16:39] <@firebot> I've never seen an 'askalski'', sorry.
  335. # [16:39] <@davidb> !seen askalski
  336. # [16:39] <@firebot> askalski was last seen 1 hour, 42 minutes and 41 seconds ago, saying 'I'll ask for your review of first patch somewhere around weekend' in #accessibility.
  337. # [17:00] * Joins: surkov (surkov@99C0F2C1.B3F96E9C.3AF1D72D.IP)
  338. # [17:00] * ChanServ sets mode: +o surkov
  339. # [17:04] <@firebot> bolterbugz@gmail.com requested review from surkov.alexander@gm ail.com for attachment 601614 on bug 495912.
  340. # [17:04] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=495912 nor, --, ---, bolterbugz, NEW, Expose alternative content in Canvas element to ATs
  341. # [17:04] * Joins: askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es)
  342. # [17:04] * ChanServ sets mode: +o askalski
  343. # [17:04] <@askalski> hi davidb
  344. # [17:04] <@askalski> we can do our 1:1
  345. # [17:04] <@davidb> hi askalski - ok great, give me 5 mins
  346. # [17:05] <@askalski> ok
  347. # [17:16] <@firebot> surkov.alexander@gmail.com granted review for attachment 601614 on bug 495912.
  348. # [17:16] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=495912 nor, --, ---, bolterbugz, NEW, Expose alternative content in Canvas element to ATs
  349. # [17:26] * Joins: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP)
  350. # [17:28] <@davidb> surkov: I do my html editing in visual studio, and it really likes the /> :)
  351. # [17:29] * @davidb tries to change that
  352. # [17:29] <@surkov> HTML doesn't like this
  353. # [17:29] <@surkov> sometimes you get different results than you expected
  354. # [17:29] <@davidb> interesting
  355. # [17:30] <@davidb> surkov: regarding the tree indent, i found it uglier the other way in this case, but fine with me
  356. # [17:31] <@davidb> (because of the text leafs)
  357. # [17:42] <@davidb> mind hurricane :)
  358. # [17:43] <@davidb> how the heck to i get visual studio to stop using windows line endings
  359. # [17:43] <@davidb> surkov: ^
  360. # [17:43] <@surkov> davidb: stop vc using :)
  361. # [17:43] <@davidb> heh
  362. # [17:44] <@davidb> VIM forever
  363. # [17:44] <@davidb> khuey: do you know how to get Visual Studio to quit it with the windows line endings?
  364. # [17:44] <@surkov> sorry that's a windows they aren't friendly to unix line endings
  365. # [17:44] <@davidb> yeah
  366. # [17:45] <@davidb> i guess i can install eclipse here as well
  367. # [17:45] <khuey> it's complicated
  368. # [17:46] <@davidb> ok forget it
  369. # [17:46] <khuey> there's an addon that does it I think
  370. # [17:51] <@tbsaunde> I thought there was just a setting somewhere, but I've only used vs2008 2 years ago
  371. # [17:52] <@tbsaunde> or you could just do find accessible/test/ -exec tr -d '\r' {} \; before doing things with the patch
  372. # [17:53] <@tbsaunde> but I seem to remember when I went to import a project one of the questions the wizard thing asked was what do with line endings
  373. # [17:57] * khuey is now known as khuey|away
  374. # [18:01] <@davidb> yeah it is a mess
  375. # [18:01] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
  376. # [18:10] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  377. # [18:10] <@davidb> surkov: landed
  378. # [18:10] <@surkov> davidb: congrats!
  379. # [18:11] <@davidb> thanks
  380. # [18:11] <@davidb> bz helped a lot
  381. # [18:30] * Quits: @surkov (surkov@99C0F2C1.B3F96E9C.3AF1D72D.IP) (Quit: surkov)
  382. # [18:32] * khuey|away is now known as khuey
  383. # [18:41] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
  384. # [18:42] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  385. # [18:47] * Quits: @askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es) (Quit: Wychodzi)
  386. # [19:13] * Joins: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com)
  387. # [19:43] * Quits: Mark_Capella (chatzilla@moz-DD0C7E4F.twcny.res.rr.com) (Quit: ChatZilla 0.9.88 [Firefox 13.0a1/20120228045336])
  388. # [20:09] * Joins: askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es)
  389. # [20:09] * ChanServ sets mode: +o askalski
  390. # [20:10] <@askalski> davidb, to speed up things, can I consider implementation of "substitute" as done?
  391. # [20:12] * Quits: victorporof (victorporo@9D98A5C0.6465CCD9.79933D60.IP) (Connection reset by peer)
  392. # [20:13] * Joins: victorporo (victorporo@9D98A5C0.6465CCD9.79933D60.IP)
  393. # [20:13] <@askalski> davidb, because in my implementation I store info basing on diagonals, so it's easiest to me to slide on diagonal, which corresponds to substituing. I can proove that this way one of the shortest path is traversed anyway, but as long as there is no substitute event, I might end up generating actually more than original
  394. # [20:14] <@davidb> i think so, be sure to comment in the bug.
  395. # [20:14] <@davidb> gotta run
  396. # [20:15] <@askalski> davidb, bye
  397. # [20:15] <@davidb> ciao
  398. # [20:16] <@askalski> tbsaunde, is it OK to use a std:vector<> ?
  399. # [20:16] * Quits: @davidb (davidb@F2D29657.F60B0462.67AC9B1.IP) (Quit: davidb)
  400. # [20:16] <@askalski> tbsaunde, I have a situation in which I can't predict how much memory the alg will use (the bad case is rare)
  401. # [20:17] <@askalski> tbsaunde, and std:vector looks handy
  402. # [20:27] <@tbsaunde> askalski: nsTArray is probably preferable
  403. # [20:27] <@tbsaunde> using std:: is tricky since we don't want to require new libstdc++
  404. # [20:30] <@firebot> mbrubeck@mozilla.com changed the Status on bug 473576 from ASSIGNED to RESOLVED.
  405. # [20:30] <@firebot> mbrubeck@mozilla.com set the Resolution field on bug 473576 to FIXED.
  406. # [20:30] <@firebot> mbrubeck@mozilla.com changed the Target Milestone on bug 473576 from --- to mozilla13.
  407. # [20:30] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=473576 nor, --, ---, surkov.alexander, ASSI, font-family text attribute should expose actual font used
  408. # [21:00] <@askalski> nsTArray is like vector?
  409. # [21:00] <@askalski> tbsaunde, nsTArray is like vector?
  410. # [21:00] <@tbsaunde> askalski: I think so
  411. # [21:01] <@tbsaunde> I'm not rally familiar with libstdc++
  412. # [21:01] <@askalski> tbsaunde, ok. I'll look into it
  413. # [21:01] <@askalski> thanks
  414. # [21:01] <@tbsaunde> np
  415. # [21:06] * Joins: davidb (davidb@471D72E.2257F909.F30C9E9E.IP)
  416. # [21:06] * ChanServ sets mode: +qo davidb davidb
  417. # [21:13] * khuey is now known as khuey|away
  418. # [21:40] * Quits: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com) (Ping timeout)
  419. # [21:54] * Quits: clown (clown@67828CC7.C1A51174.9D42CF23.IP) (Ping timeout)
  420. # [21:54] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  421. # [22:04] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
  422. # [22:10] <@firebot> johan.charlez@gmail.com requested review from gavin.sharp@gmail.c om for attachment 601727 on bug 713052.
  423. # [22:10] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=713052 nor, --, ---, johan.charlez, NEW, Add preference for disabling ALT-clicks to save links.
  424. # [22:11] * Joins: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com)
  425. # [22:13] <@firebot> gavin.sharp@gmail.com cancelled feedback?(gavin.sharp@gmail .com) for attachment 597458 on bug 713052.
  426. # [22:14] <@firebot> gavin.sharp@gmail.com granted review for attachment 601727 on bug 713052.
  427. # [22:25] <@firebot> johan.charlez@gmail.com requested review from gavin.sharp@gmail.c om for attachment 601735 on bug 713052.
  428. # [22:25] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=713052 nor, --, ---, johan.charlez, NEW, Add preference for disabling ALT-clicks to save links.
  429. # [22:26] <@firebot> gavin.sharp@gmail.com granted review for attachment 601735 on bug 713052.
  430. # [22:29] * khuey|away is now known as khuey
  431. # [22:41] * Quits: @askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es) (Ping timeout)
  432. # [22:43] * Joins: askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es)
  433. # [22:43] * ChanServ sets mode: +o askalski
  434. # [23:08] * Quits: @askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es) (Quit: Wychodzi)
  435. # [23:12] * Parts: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  436. # [23:14] * Quits: @jprmc (jprmc@F2D29657.F60B0462.67AC9B1.IP) (Ping timeout)
  437. # [23:39] * Quits: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com) (Quit: nhirata)
  438. # [23:45] * Joins: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com)
  439. # Session Close: Thu Mar 01 00:00:00 2012

The end :)