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

Options:

  1. # Session Start: Thu Feb 09 00:00:00 2012
  2. # Session Ident: #accessibility
  3. # [00:05] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
  4. # [00:10] * Quits: shorlander (shorlander@moz-853043D6.dhcp.insightbb.com) (Ping timeout)
  5. # [00:10] * jimm is now known as jimm-bbiab
  6. # [00:10] * Joins: shorlander_ (shorlander@moz-853043D6.dhcp.insightbb.com)
  7. # [00:13] * Quits: skyler_brungardt (skyler@3459447D.62BEB748.75EC3910.IP) (Ping timeout)
  8. # [00:14] <WeirdAl> oh, I see what you mean
  9. # [00:17] * Joins: frogoid (frogoid@moz-6F9F653A.dsl.bell.ca)
  10. # [00:19] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  11. # [00:24] * Joins: hub (hub@83874EA1.EB7C1AF9.6F478678.IP)
  12. # [00:24] * ChanServ sets mode: +o hub
  13. # [00:28] * Joins: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net)
  14. # [00:32] <WeirdAl> jimm-bbiab: does accessibility have the concept of a "retry" response, a la "I'm busy right now, call me back in a moment"?
  15. # [00:32] <WeirdAl> err, s/accessibility/ipc
  16. # [00:39] * khuey is now known as khuey|1on1
  17. # [00:40] * jimm-bbiab is now known as jimm
  18. # [00:40] <jimm> WeirdAl: not really.
  19. # [00:40] <jimm> the problem here is that one of the processes is stuck in a modal loop that isn't processing windowing events.
  20. # [00:41] <jimm> that can happen on the fx or plugin-container side
  21. # [00:41] <jimm> it's a problem with our implementation on windows.
  22. # [00:41] <WeirdAl> mmm
  23. # [00:41] <jimm> supposedly content processes are supposed to address it somewhat.
  24. # [00:42] <WeirdAl> but somehow we found a way past all those barriers
  25. # [00:43] <jimm> not sure if we did, I think our suggestion was that people using accessibility software should disable out of process plugins
  26. # [00:43] <jimm> davidb would know if that's still the case
  27. # [00:45] <WeirdAl> even so, the fact we're using these API's makes it a little harder to do that
  28. # [00:45] <WeirdAl> numbers-wise, I mean
  29. # [00:46] <jimm> btw, why is Ask using accessibility apis?
  30. # [00:46] <WeirdAl> our code definitely has to be smarter
  31. # [00:46] <WeirdAl> I don't know the answer to that. Brian knows, but he signed off a few hours ago
  32. # [00:47] <jimm> well I need to do some more dubugging on our end so I cvan get a clear picture of what's going on.
  33. # [00:47] <WeirdAl> my best guess is we didn't know any alternatives to do a little screen-scraping
  34. # [00:48] <WeirdAl> ... I personally think we need to hire someone on our side to speak loudly on how browser vendors like Mozilla will react
  35. # [00:48] <WeirdAl> my voice doesn't carry enough weight
  36. # [00:50] <jimm> WeirdAl: what location do you work out of? Mtn View?
  37. # [00:50] <WeirdAl> jimm: I work for Ask, in Oakland
  38. # [00:50] <jimm> that's what I mean, was just curious where Ask was head quartered.
  39. # [00:51] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
  40. # [00:51] <WeirdAl> we have offices in NY, and here in Oakland
  41. # [00:52] * Quits: frogoid (frogoid@moz-6F9F653A.dsl.bell.ca) (Ping timeout)
  42. # [00:53] <WeirdAl> btw, jimm, did you have a chance to write up that detailed analysis for 719561?
  43. # [00:54] <jimm> ah, no I want to do some more debugging first.
  44. # [00:55] <WeirdAl> ok
  45. # [00:56] <jimm> you guys caught me in the middle of another project today.
  46. # [00:56] <@hub> I wonder how much bug 627699 will have in relation to a11y.
  47. # [00:56] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=627699 nor, --, ---, stransky, ASSI, Port GTK2 to GTK3
  48. # [00:56] <WeirdAl> I appreciate your help on all this, jimm, seriously
  49. # [00:56] <jimm> np
  50. # [01:03] * khuey|1on1 is now known as khuey
  51. # [01:13] <Jamie> jimm: WeirdAl: the IPC problem is still an issue, but for some reason, we rarely see it now
  52. # [01:13] <Jamie> We'd need to find a page that causes a lot of IPC traffic and load to reproduce it
  53. # [01:14] * Jamie doesn't have out-proc plugins disabled. Occasionally see a11y fail, but not often enough for it to irritate me
  54. # [01:17] <Jamie> jimm: I assume bug 667883 doesn't actually apply to normal trunk builds, only e10s-enabled ones?
  55. # [01:17] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=667883 nor, --, mozilla8, mounir, RESO FIXED, Implement nsAttrAndChildArray::SizeOf()
  56. # [01:17] <Jamie> err
  57. # [01:17] <Jamie> bug 677883
  58. # [01:17] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=677883 maj, --, mozilla10, jmathies, RESO FIXED, [e10s] WM_GETOBJECT regularly fails on content process windows in anything but the first tab
  59. # [01:24] * Joins: frogoid (frogoid@moz-6F9F653A.dsl.bell.ca)
  60. # [01:28] <jimm> no idea on 667883
  61. # [01:29] <jimm> oh
  62. # [01:29] <jimm> sorry, was looking at the first firebot msg
  63. # [01:29] <jimm> so that fix only "kicks in" if oopp is enabled.
  64. # [01:45] * Quits: frogoid (frogoid@moz-6F9F653A.dsl.bell.ca) (Ping timeout)
  65. # [01:50] * Joins: muralisr92 (chatzilla@moz-511DFF61.spnp.nus.edu.sg)
  66. # [01:52] <Jamie> jimm: oopp = out of process plugins = applies in current nightlies?
  67. # [01:54] <Jamie> jimm: if so, that fix should solve that WM_GETOBJECT failure you were discussing above re a11y tools
  68. # [01:59] * Quits: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net) (Quit: skyler_brungardt)
  69. # [01:59] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Connection reset by peer)
  70. # [02:00] <jimm> it fixes the specific problem we had there where those events were getting mysteriously dropped.
  71. # [02:00] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
  72. # [02:02] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Ping timeout)
  73. # [02:04] * Quits: WeirdAl (chatzilla@moz-D461843.ask.info) (Quit: ChatZilla 0.9.88 [Firefox 10.0/20120129021758])
  74. # [02:04] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
  75. # [02:09] * Joins: surkov (surkov@E3B837DE.44A4068D.222B27F0.IP)
  76. # [02:09] * ChanServ sets mode: +o surkov
  77. # [02:16] * Quits: @surkov (surkov@E3B837DE.44A4068D.222B27F0.IP) (Ping timeout)
  78. # [02:16] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
  79. # [02:18] * Joins: surkov (surkov@E3DF49AD.6EAE5E0.5D3F4C44.IP)
  80. # [02:18] * ChanServ sets mode: +o surkov
  81. # [02:19] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
  82. # [02:19] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
  83. # [02:21] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
  84. # [02:23] <Jamie> hey surkov :)
  85. # [02:25] <@surkov> hey, Jamie!
  86. # [02:28] * Quits: @davidb (davidb@moz-A4A01B28.eng.wind.ca) (Ping timeout)
  87. # [02:29] * Joins: davidb (davidb@moz-6F9F653A.dsl.bell.ca)
  88. # [02:29] * ChanServ sets mode: +qo davidb davidb
  89. # [02:29] <@davidb> ishi all
  90. # [02:31] <@surkov> hi, davidb
  91. # [02:33] * Quits: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP) (Input/output error)
  92. # [02:34] <@hub> hi
  93. # [02:39] * Quits: muralisr92 (chatzilla@moz-511DFF61.spnp.nus.edu.sg) (Quit: ChatZilla 0.9.88 [Firefox 10.0/20120129141257])
  94. # [02:50] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
  95. # [02:52] * Quits: Mook_as (mook@moz-1FCC0032.activestate.com) (Quit: ChatZilla 0.9.88-rdmsoft [XULRunner 1.9.2.13/20101203074205])
  96. # [02:53] * khuey is now known as khuey|away
  97. # [02:53] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
  98. # [02:53] * Quits: tty234 (telex@moz-F9058B8A.net) (Ping timeout)
  99. # [03:01] <Jamie> hey davidb :0
  100. # [03:01] <@davidb> hi Jamie
  101. # [03:02] * Joins: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP)
  102. # [03:09] * Quits: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com) (Quit: nhirata)
  103. # [03:10] * Quits: jimm (jmathies@moz-7F164CA1.pn.at.cox.net) (Quit: )
  104. # [03:19] * Quits: shorlander_ (shorlander@moz-853043D6.dhcp.insightbb.com) (Quit: Quit)
  105. # [03:21] <@davidb> guys
  106. # [03:21] <@davidb> https://lists.mozilla.org/listinfo/accessibility
  107. # [03:21] <@davidb> surkov: ^
  108. # [03:21] <@hub> is that new?
  109. # [03:22] <@davidb> yes
  110. # [03:22] <@hub> sub'd
  111. # [03:22] <@davidb> good
  112. # [03:22] <@davidb> google seems slow to archive
  113. # [03:23] <@davidb> related bug is bug 721388
  114. # [03:23] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=721388 nor, --, ---, dgherman, RESO FIXED, New discussion forum: mozilla.accessibility
  115. # [03:23] <@surkov> davidb: what is this mail list for?
  116. # [03:23] <@davidb> surkov: sort of a long story, but everything to do with accessibility and the web
  117. # [03:24] <@surkov> ok
  118. # [03:24] <@davidb> i wish we had our own archives
  119. # [03:26] <@davidb> we might see Ken Saunders show up on channel one day soon
  120. # [03:26] <@davidb> he's going to help grow accessibility contribution at mozilla
  121. # [03:26] <@davidb> especially web sites contribution i think
  122. # [03:27] <@davidb> there is also satdav that will be overlapping i think
  123. # [03:27] <@davidb> i'll know more after the next meeting with David Boswell
  124. # [03:31] <Jamie> davidb: hmm. aren't there plenty of general web access lists around already? :)
  125. # [03:31] <@davidb> i expect these comments to come :)
  126. # [03:31] <Jamie> davidb: not that it really matters, just curious
  127. # [03:31] <Jamie> i.e. the motivation for creating a new one
  128. # [03:33] <@davidb> part of it is confusion
  129. # [03:33] <@davidb> we have some community members who want a list and were confused/ put off by "dev-"
  130. # [03:34] <@davidb> i know it is a bit funny
  131. # [03:34] <Jamie> davidb: sure, but surely that's Mozilla specific, no?
  132. # [03:34] <Jamie> as opposed to "general a11y"
  133. # [03:34] <@davidb> which?
  134. # [03:35] * khuey|away is now known as khuey
  135. # [03:35] <Jamie> davidb: It's just that "general" lists tend to end up being a forum for questions like "this web site is inaccessible, how do we fix it" and end up becoming less useflu than originally intended
  136. # [03:35] <Jamie> I'm sure you've already had all of these thoughts yourself, though :)
  137. # [03:35] <@davidb> that might happen
  138. # [03:35] <@davidb> an example discussion we might see on accessibility@mozilla is "support.mozilla.com needs a11y overhaul"
  139. # [03:35] <Jamie> davidb: Mm, I mean you said you had community members wanting an a11y list and didn't like dev-, but surely they were mozilla specific questions
  140. # [03:36] <Jamie> davidb: whereas this list is "general a11y"
  141. # [03:36] <@davidb> is it?
  142. # [03:36] <@davidb> i hope web related.
  143. # [03:36] <Jamie> err, ok, web a11y
  144. # [03:36] <Jamie> but not mozilla specific, unless I'm just misinterpreting
  145. # [03:36] <@davidb> i'm not sure how it will evolve
  146. # [03:37] <Jamie> "This is an informal forum for web accessibility topics. Please be excellent to each other." - I didn't see the word mozilla in there, hence my query
  147. # [03:37] <@davidb> ah!
  148. # [03:37] <@davidb> I can add one :)
  149. # [03:37] <Jamie> heh, woops. maybe we're on the same page now :)
  150. # [03:38] <@davidb> wow i didn't realize people actually read mailing list descriptions
  151. # [03:38] <Jamie> well, I guess you figured the fact that it's on lists.mozilla.org was enough. I misread because I know Mozilla are also open to making things better in general, not just for Mozilla
  152. # [03:38] <Jamie> davidb: haha. I am a perfectionist/thorough
  153. # [03:39] <@davidb> we are
  154. # [03:39] <Jamie> and a bit obsessive about efficiency, so I tend to read this stuff before I act
  155. # [03:39] <@davidb> open
  156. # [03:39] <@davidb> so in the back of my mind is the w3c wanting a list
  157. # [03:39] <Jamie> davidb: sure, I know, but my point was that that was why I wasn't sure what the list was for without the phrase "Mozilla and web accessibility" ro similar
  158. # [03:39] <@davidb> i suggested wai-xtech but meh
  159. # [03:40] <@davidb> Jamie: updated
  160. # [03:40] <Jamie> davidb: got it. clear. :)
  161. # [03:40] <@davidb> sorta
  162. # [03:41] <Jamie> davidb: sorry, wasn't being difficult, was quite sincerely confused
  163. # [03:41] <@davidb> maybe people will think it is just for mozilla websites now
  164. # [03:41] <Jamie> heh
  165. # [03:41] <@davidb> but let's see how it evolves
  166. # [03:41] <Jamie> so it's not just for mozilla web sites? :)
  167. # [03:41] * Jamie chuckles
  168. # [03:41] <Jamie> this ought to be interesting
  169. # [03:42] <@davidb> lol
  170. # [03:44] <Jamie> damn, found another bug in caret offset stuff
  171. # [03:45] * Jamie wishes fixing bugs was as easy as finding them
  172. # [03:46] <@davidb> caret is on my mind these days
  173. # [03:47] <Jamie> oh goody, it's not a firefox bug
  174. # [03:47] <Jamie> it's an NVDA bug
  175. # [03:47] <@davidb> i would have lost that bet
  176. # [03:47] * Jamie laughs
  177. # [03:48] <Jamie> No disrespect meant, but so would I
  178. # [03:48] <@davidb> lol
  179. # [03:48] <Jamie> firefox and caret just don't seem ot get along so well as firefox and other things a11y :)
  180. # [03:48] <@davidb> caret bugs are mostly in our layout module
  181. # [03:48] * Quits: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP) (Input/output error)
  182. # [03:52] * Joins: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP)
  183. # [03:53] <@davidb> surkov: do you have thoughts on bug 675685?
  184. # [03:54] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=675685 nor, --, ---, askalski, NEW, TextUpdater::DoUpdate computes Levenshtein Edit Distance inefficiently
  185. # [03:55] <@surkov> I didn't look yet
  186. # [03:59] <@davidb> shibby
  187. # [03:59] * Quits: @davidb (davidb@moz-6F9F653A.dsl.bell.ca) (Quit: davidb)
  188. # [03:59] * Joins: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net)
  189. # [04:39] * Joins: nhirata (nhirata.bu@moz-2A9C9106.hsd1.ca.comcast.net)
  190. # [05:11] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
  191. # [05:11] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  192. # [05:12] * Joins: aaronlev (chatzilla@moz-9058091D.bstnma.fios.verizon.net)
  193. # [05:24] <@firebot> surkov.alexander@gmail.com granted review for attachment 595422 on bug 721947.
  194. # [05:24] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=721947 nor, --, ---, hub, NEW, don't use nsIWeakShell
  195. # [05:25] * Quits: aaronlev (chatzilla@moz-9058091D.bstnma.fios.verizon.net) (Quit: ChatZilla 0.9.88 [Firefox 12.0a2/20120208042017])
  196. # [05:31] <@firebot> surkov.alexander@gmail.com granted review for attachment 595486 on bug 706134.
  197. # [05:31] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=706134 nor, --, ---, askalski, NEW, ARIA listitem shouldn't expose selectable state and pick up aria-selected and aria-checked
  198. # [05:38] <@firebot> surkov.alexander@gmail.com granted review for attachment 595446 on bug 539694.
  199. # [05:39] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=539694 nor, --, mozilla11, jigneshhk1992, ASSI, accessible objects should have private copy constructor
  200. # [05:45] * khuey is now known as khuey|away
  201. # [06:28] * Quits: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net) (Quit: skyler_brungardt)
  202. # [06:39] * Quits: @hub (hub@83874EA1.EB7C1AF9.6F478678.IP) (Input/output error)
  203. # [06:48] * Joins: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net)
  204. # [07:11] * Joins: MarcoZ (marco.zehe@moz-44FC024.dip.t-dialin.net)
  205. # [07:11] * ChanServ sets mode: +o MarcoZ
  206. # [07:12] <@MarcoZ> Good morning all!
  207. # [07:15] <Jamie> MarcoZ: hi.
  208. # [07:15] <Jamie> MarcoZ: I can't reproduce your bug :(
  209. # [07:15] <Jamie> MarcoZ: however, I suspect it might be specific to the braille table you're using.
  210. # [07:16] <Jamie> MarcoZ: if it is, it's a bug in liblouis
  211. # [07:19] <@MarcoZ> Jamie: It's the German 8 dot braille table.
  212. # [07:22] <Jamie> MarcoZ: re gmail: I'll be it's another instance of bug 677154
  213. # [07:22] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=677154 nor, --, ---, nobody, NEW, Detached document accessibility tree
  214. # [07:22] <Jamie> bet*
  215. # [07:22] <Jamie> that bug is really serious and I'm seeing more and more of it
  216. # [07:22] <@MarcoZ> Jamie: I agree! Surkov, any progress in reproducing it with Jamie's profile?
  217. # [07:23] <@surkov> I didn't tried yet, sorry
  218. # [07:23] <@MarcoZ> surkov: If it is at all possible, please try it SOON. I believe this is a lurking problem that somehow gains exposure. :(
  219. # [07:24] * @MarcoZ updates the blog post.
  220. # [07:24] <@surkov> yes, I know
  221. # [07:25] <Jamie> MarcoZ: how do I repro this gmail problem?
  222. # [07:25] <Jamie> MarcoZ: I'll have a quick snoop
  223. # [07:27] <Jamie> MarcoZ: err, I still can't repro with german 8 dot
  224. # [07:27] <@MarcoZ> Jamie: Strange! I'll watch out for that braille problem and see if I find other STR to repro.
  225. # [07:27] <@MarcoZ> Jamie: Log into gmail, standard view, and allow it to switch to the newest version of their layout.
  226. # [07:28] <@MarcoZ> Jamie: For me, the last thing shown is the iframe where the search is in. Below it, the v buffer ends.
  227. # [07:28] <Jamie> MarcoZ: can you still repro with about: right now? as in... is it always reproable?
  228. # [07:28] <@MarcoZ> Jamie: Interesting enough, Dominic pointed out, and I have yet to verify this, if you turn off Google's single-letter keystrokes, the bug goes away.
  229. # [07:30] <Jamie> MarcoZ: yup, that's bug 6775COMError: (-2147418113, 'Catastrophic failure', (None, None, None, 0, None))
  230. # [07:31] <Jamie> err
  231. # [07:31] <Jamie> that's bug 677154
  232. # [07:34] <@firebot> New Core - Disability Access APIs bug 725572 filed by hub@mozilla.com.
  233. # [07:34] <@firebot> Bug 725572 was not found.
  234. # [07:43] * Quits: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net) (Quit: skyler_brungardt)
  235. # [07:44] <@MarcoZ> Jamie: Thanks, I just updated the bug with this info and bumped priority and importance.
  236. # [07:44] * Joins: hub (hub@moz-E2FCA694.figuiere.net)
  237. # [07:44] * ChanServ sets mode: +o hub
  238. # [07:52] * Quits: @hub (hub@moz-E2FCA694.figuiere.net) (Ping timeout)
  239. # [08:39] <@firebot> New Core - Disability Access APIs bug 725581 filed by surkov.alexander@gmail.com.
  240. # [08:39] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725581 nor, --, ---, nobody, NEW, caretOffset for textarea should be -1 when textarea doesn't have a focus
  241. # [08:42] <@firebot> surkov.alexander@gmail.com requested review from trev.saunders@gmail .com for attachment 595669 on bug 725581.
  242. # [08:42] <@firebot> surkov.alexander@gmail.com changed the Status on bug 725581 from NEW to ASSIGNED.
  243. # [08:49] <@firebot> jigneshhk1992@gmail.com requested review from trev.saunders@gmail .com for attachment 595671 on bug 724452.
  244. # [08:49] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=724452 nor, --, ---, jigneshhk1992, NEW, use nsFocusManager::GetFocusManager() more
  245. # [09:03] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  246. # [09:11] * Quits: Jamie (jamie@moz-CA26021.jantrid.net) (Quit: bye all)
  247. # [10:07] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
  248. # [10:35] * Joins: Mark_Capella (chatzilla@moz-DD0C7E4F.twcny.res.rr.com)
  249. # [10:41] * Quits: @tbsaunde (tbsaunde@moz-9DECD0.pc.cs.cmu.edu) (Ping timeout)
  250. # [10:44] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  251. # [10:44] * Joins: tbsaunde (tbsaunde@moz-9DECD0.pc.cs.cmu.edu)
  252. # [10:45] * Quits: Mark_Capella (chatzilla@moz-DD0C7E4F.twcny.res.rr.com) (Quit: ChatZilla 0.9.88 [Firefox 13.0a1/20120208175111])
  253. # [10:57] * Joins: muralisr92 (chatzilla@moz-8D846020.dynip.nus.edu.sg)
  254. # [11:02] <muralisr92> marcoz: can i ask you some doubts regarding bug 702560 now??
  255. # [11:02] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=702560 nor, --, ---, murali.sr92, NEW, add a11y mochitest for HTML 5 contextmenu
  256. # [11:03] * ChanServ sets mode: +o tbsaunde
  257. # [11:08] * Parts: muralisr92 (chatzilla@moz-8D846020.dynip.nus.edu.sg)
  258. # [11:19] <@firebot> surkov.alexander@gmail.com granted review for attachment 595463 on bug 725178.
  259. # [11:19] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725178 nor, --, ---, tobbi.bugs, ASSI, get rid ensureAccessibleTree of common.js
  260. # [11:43] * Quits: @surkov (surkov@E3DF49AD.6EAE5E0.5D3F4C44.IP) (Ping timeout)
  261. # [11:51] * Joins: surkov (surkov@EB9D20A1.F78D7EEB.34044A7F.IP)
  262. # [11:51] * ChanServ sets mode: +o surkov
  263. # [11:55] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Ping timeout)
  264. # [11:56] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  265. # [11:56] * Quits: a-865 (fmcz@moz-A5D13CA.cable.mindspring.com) (Ping timeout)
  266. # [11:57] * Quits: JulienP (julien.pic@moz-DFEC0675.opera.com) (Ping timeout)
  267. # [11:58] * Joins: JulienP (julien.pic@moz-DFEC0675.opera.com)
  268. # [11:58] * Joins: a-865 (fmcz@moz-A5D13CA.cable.mindspring.com)
  269. # [12:43] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Connection reset by peer)
  270. # [12:44] * Joins: jprmc (jprmc@moz-7F2FF3EB.cpe.net.cable.rogers.com)
  271. # [12:44] * ChanServ sets mode: +o jprmc
  272. # [13:08] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Connection reset by peer)
  273. # [13:18] * Quits: @MarcoZ (marco.zehe@moz-44FC024.dip.t-dialin.net) (Quit: Reboot.)
  274. # [13:20] * Joins: MarcoZ (marco.zehe@moz-44FC024.dip.t-dialin.net)
  275. # [13:20] * ChanServ sets mode: +o MarcoZ
  276. # [13:31] * Joins: askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es)
  277. # [13:31] * ChanServ sets mode: +o askalski
  278. # [13:31] <@askalski> hi everyone!
  279. # [13:51] * Quits: ehsan (ehsan@F0B20A8D.8458880F.57F33CED.IP) (Input/output error)
  280. # [14:09] <@tbsaunde> hi a-865
  281. # [14:20] <@askalski> surkov, I wrote an email to older friend from University who PHDd on text algorithms, I wait for his answer on LED
  282. # [14:20] <@askalski> surkov, he will probably list me all options and we'll pick among them, ok?
  283. # [14:20] <@surkov> askalski: thanks for looking in deep
  284. # [14:20] <@surkov> that'd be great
  285. # [14:20] <@askalski> surkov, my pleasure
  286. # [14:51] * Quits: @askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es) (Ping timeout)
  287. # [14:52] * Joins: askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es)
  288. # [14:52] * ChanServ sets mode: +o askalski
  289. # [15:08] * Joins: davidb (davidb@F2D29657.F60B0462.67AC9B1.IP)
  290. # [15:08] * ChanServ sets mode: +qo davidb davidb
  291. # [15:08] <@davidb> hi all!
  292. # [15:12] <@MarcoZ> Hi davidb!
  293. # [15:13] <@askalski> davidb, hi!
  294. # [15:19] <@askalski> surkov, I patched the ARIA patch, should I add you to review again or not?
  295. # [15:20] <@surkov> aleiva: no, just upload the patch and I will land it
  296. # [15:22] <@tbsaunde> askalski: ^
  297. # [15:22] <@askalski> tbsaunde, yeah, got it
  298. # [15:22] <@askalski> surkov, done.
  299. # [15:22] <@surkov> thx
  300. # [15:23] <@surkov> thx, tbsaunde :)
  301. # [15:24] <@MarcoZ> davidb: With the mozconfigs now in central and other places, do we still need local .mozconfigs, or can we just specify some command line param to say "build me nightly"?
  302. # [15:25] <@davidb> good question!
  303. # [15:25] <@MarcoZ> davidb: OK, I'll ask in #build.
  304. # [15:25] <@tbsaunde> we should have fwer people in here so tabcomplete is easier =p
  305. # [15:25] <@davidb> :)
  306. # [15:25] <@davidb> tbsaunde: you are an op...
  307. # [15:26] <@surkov> askalski: please mark old patches as obsolette
  308. # [15:27] <@askalski> surkov, yeah, I forgot. is there a way to back to edition?
  309. # [15:27] <@surkov> click to details and then edit
  310. # [15:28] <@surkov> askalski: and please specify your name and comment when you upload the patch
  311. # [15:29] <@surkov> next time I mean
  312. # [15:29] <@askalski> name? in comment or where?
  313. # [15:30] <@surkov> askalski: if you use queues then do qref -m "commit comment" -u "your name <email>"
  314. # [15:30] <@MarcoZ> davidb: Got an answer, just point MOZCONFIG env variable to one that's in the repo.
  315. # [15:30] <@davidb> neat
  316. # [15:35] <@askalski> davidb, I am waiting for e-mail answer from some guys who phd in text algorithms towards LED. I can either start to implement my best idea or give them a day-two for answering and do something else in meanwhile. which one you prefer?
  317. # [15:36] <@davidb> askalski: what is LED?
  318. # [15:36] <@MarcoZ> Levenstein distance.
  319. # [15:36] <@askalski> Levenshteind distance
  320. # [15:36] <@davidb> ah
  321. # [15:36] <@davidb> askalski: hold off for the reply
  322. # [15:36] <@davidb> and yeah do something else :)
  323. # [15:37] <@davidb> got anything on your plate?
  324. # [15:37] <@askalski> davidb, ok, I'll look on ahoy and give you some propositions.
  325. # [15:37] <@askalski> davidb, no, two landing, two pending for consensus
  326. # [15:37] <@davidb> askalski: you don't have to restrict yourself to first bugs
  327. # [15:37] <@askalski> davidb, a script to loop mochitest 80% done
  328. # [15:37] <@davidb> surkov: do you have anything else in mind for askalski? ^
  329. # [15:38] * @davidb resists temptation to suggest caret bugs
  330. # [15:38] <@askalski> ok, I was planning to look for a bug on ahoy
  331. # [15:38] <@askalski> caret bugs?
  332. # [15:38] <@davidb> don't ask :)
  333. # [15:38] <@surkov> davidb: bug?
  334. # [15:38] <@davidb> surkov: yes a bug.
  335. # [15:39] <@davidb> i don't have a particular bug in mind yet
  336. # [15:39] <@surkov> davidb: sure, win64 bit support, implement 32bit unique ids
  337. # [15:39] <@davidb> good one!
  338. # [15:40] <@surkov> askalski: bug 606080
  339. # [15:40] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=606080 nor, --, ---, nobody, NEW, (64bit) fix unique id casting to NS_PTR_TO_INT32 issue
  340. # [15:43] * khuey|away is now known as khuey
  341. # [15:45] <@MarcoZ> Yeah that's a good one, and I believe 64-bit versions that will actually be released are coming closer...
  342. # [15:48] <@askalski> MarcoZ, you're telling me that f. ex. ubuntu still ships 32?
  343. # [15:48] <@askalski> (in 64 version)
  344. # [15:51] <@MarcoZ> askalski: I'm not sure whether this bug applies to all platforms or Windows only. I'd have to re-read the whole thing, but believe it specifically applies to the Windows version.
  345. # [15:51] <@MarcoZ> askalski: I think tbsaunde once mentioned that Firefox on GNOME is generally 64 bit, but better ask him ourselves again...
  346. # [15:51] <@askalski> surkov, to your last comment to this bug *606080 - you mention linear search?
  347. # [15:51] <@MarcoZ> askalski: Mac builds are definitely 64 bit.
  348. # [15:51] <@askalski> MarcoZ, thanks
  349. # [15:53] <@surkov> askalski: sounds so
  350. # [15:54] <@askalski> surkov, I guess that provided with some amount of memory I can construct some kind of partially ordered set to make put/lookup in log(n) time
  351. # [15:54] * Quits: victorporof (victorporo@C092FEB2.1C233438.79933D60.IP) (Connection reset by peer)
  352. # [15:56] <@surkov> yes, that's nice
  353. # [15:57] * Joins: victorporof (victorporo@C092FEB2.1C233438.79933D60.IP)
  354. # [15:57] <@surkov> askalski: can you estimate required memory for that, that could be bottleneck because we are going to keep there all objects
  355. # [15:59] <@askalski> surkov, let me think. I'll iterate among my ideas and come back to you ASAP. what time you finish today?
  356. # [16:00] <@surkov> askalski: I'm not sure, when I fall asleep :) just put into bug and I'll read it
  357. # [16:03] * Joins: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net)
  358. # [16:03] <@askalski> surkov, I guess it will be linear, though we would need to do some overallocation like in vectors, so we don't pay reallocation penalty too often
  359. # [16:03] <@askalski> surkov, I can fight for getting constant as low as possible
  360. # [16:04] <@surkov> that's what we want, penalty should be small as possible because now AT gets these 32bit unique ids "for free"
  361. # [16:04] <@surkov> and I bet they can use it a lot
  362. # [16:04] <@askalski> surkov, the basic approach would be (size of data + sizeof(index)*amount of data), but I think it might be advisable to fight for cache optimisation
  363. # [16:05] <@askalski> surkov, AVL trees or black-red is the obvious solution, right?
  364. # [16:06] <@surkov> maybe not for me :)
  365. # [16:06] <@firebot> New Core - Disability Access APIs bug 725647 filed by sgautherie.bz@free.fr.
  366. # [16:06] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725647 maj, --, mozilla13, markcapella, ASSI, [SeaMonkey] mochitest-a11y: test_embeds.xul needs to support non-Firefox applications too
  367. # [16:07] <@firebot> sgautherie.bz@free.fr granted in-testsuite on bug 707654.
  368. # [16:07] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=707654 nor, --, mozilla12, surkov.alexander, RESO FIXED, embeds relation on root accessible can return not content document
  369. # [16:08] <@surkov> askalski: anyway, put some summary of your ideas into bug so I can get learn some necessary background if needed
  370. # [16:09] <@askalski> surkov, http://en.wikipedia.org/wiki/AVL_tree
  371. # [16:10] <@askalski> surkov, I think about creating a pair of such trees to provide two way mapping
  372. # [16:10] <@surkov> sounds good
  373. # [16:10] <@askalski> surkov, tell me where to place it and where to take memory from (probably not just wild alloc(), right?)
  374. # [16:11] <@askalski> surkov, all I need is alloc, realloc and free
  375. # [16:11] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  376. # [16:11] <@surkov> askalski: put new files under msaa folder
  377. # [16:12] <@askalski> surkov, I was talking about function calls :)
  378. # [16:13] * @tbsaunde sees interesting happening ut got to stay away till 1200 :/
  379. # [16:14] <@surkov> askalski: we need some testing so probably they should live in base directory and then you can extend nsIAccessible to make them visible from js
  380. # [16:14] <@surkov> and then we can start to use that in MSAA
  381. # [16:14] <@askalski> surkov, btw, I can also use red-black trees, like STL does
  382. # [16:14] <@surkov> askalski: what's difference in two words?
  383. # [16:14] <@askalski> surkov, I am not sure if implementing log(n) mapping is nor reinventing the wheel
  384. # [16:15] <@askalski> surkov, AVL trees are more rigidly balanced than red-black trees, leading to slower insertion and removal but faster retrieval. (wiki) + AVL has lower memory footprint
  385. # [16:15] <@surkov> do you mean in gecko?
  386. # [16:15] <@surkov> always a trade
  387. # [16:17] * Joins: tty234 (telex@moz-F9058B8A.net)
  388. # [16:18] <@surkov> maybe we should prefer fast insertion and removal
  389. # [16:18] <@surkov> since that's going to happen everytime
  390. # [16:19] <@askalski> surkov, tbsaunde, I can either implement the mapping 64 <-> 32 with log(n) in all operations and log(n) memory usage OR create this pool of freeID as proposed by Trevor, I think also log(n) everything and O(n) space
  391. # [16:19] <@askalski> surkov, red-black are twice as much memory consuming
  392. # [16:20] <@askalski> surkov, acting pretty much as fast/slow as std::map
  393. # [16:20] * davidb is now known as davidb|mtg
  394. # [16:20] <@askalski> surkov, because this is the way it's implemented to my knowledge
  395. # [16:21] <@askalski> surkov, OR we can just use two std::map<int32, int64> and std::map<int64, int32> as mapping solution, two lines, no brainer
  396. # [16:24] <@surkov> askalski: btw, gecko has own hash tables, you might want to look
  397. # [16:24] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  398. # [16:24] <@askalski> surkov, ok, I think that the problem is about having this reuse-pool
  399. # [16:24] <@askalski> I wrote such thins several years ago, I'll propose something
  400. # [16:24] <@surkov> ok
  401. # [16:26] <@askalski> surkov, tbsaunde, I'll write it now, and then I'd like someone to tutor me where to attach it to get the bug fixed, ok?
  402. # [16:26] <@surkov> sure
  403. # [16:29] * Joins: aaronlev (aaronlev@moz-CDA191A6.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com)
  404. # [16:30] * clown is now known as clown_mtg
  405. # [16:33] * Quits: skyler_brungardt (skyler@moz-9FA3C392.washdc.fios.verizon.net) (Quit: skyler_brungardt)
  406. # [16:48] <@tbsaunde> askalski: yeah, I think my idea there was generally constant time in good cases no idea about what real world performance wuld end up looking like
  407. # [16:49] <@tbsaunde> askalski: you could also consider splay trees :|
  408. # [16:49] * Joins: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP)
  409. # [16:49] <@askalski> tbsaunde, right now I was hacking about Interval Tree
  410. # [16:49] <@askalski> splay tree... which one was that
  411. # [16:49] <@tbsaunde> askalski: I'm really not sure what the right solution is, but if you propose something I can help with problems you have
  412. # [16:50] <@tbsaunde> rinterval tree?
  413. # [16:50] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
  414. # [16:50] <@tbsaunde> askalski: they are ... a bit weird read wikipedia
  415. # [16:50] <@askalski> tbsaunde, why?
  416. # [16:50] <@tbsaunde> they have the zig zag zig zag thing to move most recent used element to top
  417. # [16:51] <@askalski> ok
  418. # [16:51] <@tbsaunde> askalski: I don't remember the details
  419. # [16:57] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  420. # [16:58] <@tbsaunde> askalski: btw I think a free pool can be O(1) creation of an id and then O(1) amortized for freeing an id
  421. # [16:58] <@askalski> tbsaunde, I see no such option yet
  422. # [16:58] <@askalski> splay trees you say?
  423. # [16:59] <@askalski> tbsaunde, to wikipedia, they amortise to log(n)
  424. # [17:00] <@tbsaunde> askalski: I think that's how you spell it
  425. # [17:00] <@tbsaunde> I thought they had something that was log(log(n))
  426. # [17:01] <@tbsaunde> askalski: I'm pretty sure I'm write about the bounds on a free pool
  427. # [17:01] <@askalski> tbsaunde, my idea right now is to enrich red-black trees with interval information as described in CORMEN
  428. # [17:01] <@tbsaunde> askalski: I see
  429. # [17:02] <@askalski> tbsaunde, is it OK? or should I dig more
  430. # [17:02] <@tbsaunde> askalski: if I'm write about the constant time bounds on a free pool I think it may be the right answer
  431. # [17:02] <@tbsaunde> askalski: I think a tree is fine if you tell me why you don't believe constant time free pool will work
  432. # [17:03] <@askalski> tbsaunde, balancing after deletion of empty nodes
  433. # [17:03] <@askalski> tbsaunde, I see no option to avoid this
  434. # [17:03] * khuey is now known as khuey|away
  435. # [17:03] <@tbsaunde> askalski: you don't need to balance them
  436. # [17:03] <@tbsaunde> askalski: you just have an array
  437. # [17:03] <@tbsaunde> and a min used number
  438. # [17:04] <@askalski> tbsaunde, en.wikipedia.org/wiki/Splay_tree
  439. # [17:04] <@tbsaunde> err, max used
  440. # [17:04] <@askalski> we
  441. # [17:05] <@askalski> tbsaunde, we're talking about a struct that has operations pick(), free(int) and that's it, right?
  442. # [17:05] <@tbsaunde> askalski: for a free pool yes, I'd call them allocate and free though
  443. # [17:06] <@tbsaunde> askalski: yes, that was the tree I was thinking of
  444. # [17:06] <@askalski> tbsaunde, so the first sentence states it's logarithmic and balanced
  445. # [17:06] * clown_mtg is now known as clown
  446. # [17:06] <@tbsaunde> ok
  447. # [17:07] <@tbsaunde> askalski: note I am not suggesting using a tree for a free pool since there is no reason to
  448. # [17:07] <@askalski> tbsaunde, but then they write it's used in garbage collectors etc, so sounds familiar...
  449. # [17:08] <@tbsaunde> askalski: well, the fast access for recently used nodes is a good feature
  450. # [17:08] <@tbsaunde> askalski: so, do you think my time bounds on a free pool using an array are correct?
  451. # [17:08] <@askalski> tbsaunde, do we need to ensure that the ID are as small as possible?
  452. # [17:08] <@tbsaunde> askalski: no
  453. # [17:09] <@askalski> tbsaunde, or just unique
  454. # [17:09] <@tbsaunde> askalski: just unique
  455. # [17:09] <@tbsaunde> how you deal with 2^32 + 1 objects is unclear
  456. # [17:09] <@askalski> tbsaunde, sure, just adding a element to the "free pool" is easy
  457. # [17:10] <@askalski> tbsaunde, yeah, but you can decrease it only by half at the best day, right?
  458. # [17:10] <@askalski> tbsaunde, because the worst case scenario is 1) allocate all 2) free all odd
  459. # [17:10] <@askalski> tbsaunde, and whatever you do, you're with 2^31 singletons
  460. # [17:11] <@tbsaunde> askalski: well, you can only decrease the pool size when you free the highest number
  461. # [17:11] <@tbsaunde> askalski: singletons?
  462. # [17:11] <@askalski> tbsaunde, set of size 1
  463. # [17:12] <@askalski> tbsaunde, the word singleton means set with single member in group theory
  464. # [17:12] <@askalski> tbsaunde, anyway, whatever we do, this worst case scenario kills it
  465. # [17:13] <@tbsaunde> askalski: yeah, I knew that just didn't understand what you meant
  466. # [17:13] <@tbsaunde> I see now
  467. # [17:13] <@askalski> tbsaunde, it's still pesimistic linear memory
  468. # [17:13] <@tbsaunde> askalski: true, do we care about that case though?
  469. # [17:14] <@askalski> tbsaunde, not really sure.
  470. # [17:15] <@davidb|mtg> speed!
  471. # [17:15] * davidb|mtg is now known as davidb
  472. # [17:15] <@davidb> speed speed speed
  473. # [17:15] <@tbsaunde> I tend to think not, but I'm uncomfortable just guessing
  474. # [17:15] <@askalski> davidb|mtg, we can do really miracles if we spend some more memory
  475. # [17:15] <@davidb> how much memory we talking?
  476. # [17:15] <@askalski> there are two options
  477. # [17:15] <@davidb> also i haven't read scrollback
  478. # [17:16] <@tbsaunde> askalski: on the other hand it has better memory size if the pool stays small
  479. # [17:16] <@askalski> either we go with 2*maxN
  480. # [17:16] <@askalski> so 32-64 mb...
  481. # [17:16] <@askalski> and it's deamn fast
  482. # [17:16] <@davidb> uhm
  483. # [17:16] <@askalski> or we go with balanced tree that removes non used nodes
  484. # [17:16] <@askalski> that is smaller for most of the time
  485. # [17:16] <@askalski> but worst case scenario is still as bad
  486. # [17:16] <@askalski> and we consume some time balancing tree
  487. # [17:18] <@askalski> or I can try to do some magic with shared-prefixes, but to such small sequences I would waste a lot of time (both computation and programming )and got not much in return
  488. # [17:18] <@tbsaunde> askalski: I wonder how hard it would be to write a free pool hook it in and see what it is like in real life browsing
  489. # [17:18] <@askalski> we're talking about worst case scenario, so 2^32 objects existing
  490. # [17:19] <@askalski> so if for example our object have some decent size, the machine would froze anyway
  491. # [17:19] * Quits: drexler (chatzilla@moz-2C2B7D1F.hsd1.vt.comcast.net) (Quit: ChatZilla 0.9.88 [Firefox 10.0/20120129021758])
  492. # [17:19] <@tbsaunde> askalski: well, the worst case is more than that many accessibles in which case we are sort of screwed
  493. # [17:20] <@askalski> to be honest
  494. # [17:20] <@askalski> while considering only worst case scenarios
  495. # [17:20] <@askalski> your solution is optimal :)
  496. # [17:20] <@tbsaunde> askalski: well, for that worst case
  497. # [17:20] <@askalski> yes. I can do some savings in pool
  498. # [17:21] <@tbsaunde> but in the case you creat 2^32 accessibles and then free all but the last one its pecimal
  499. # [17:21] <@askalski> storing freed IDs in ranges
  500. # [17:21] <@askalski> or even storing all available IDs in ranges and keep the invariant
  501. # [17:21] <@askalski> of balancing the tree
  502. # [17:22] <@askalski> I don't know. we would use some info on what is the average number of objects
  503. # [17:22] <@tbsaunde> askalski: I'm not sure I understand what your suggesting
  504. # [17:23] <@askalski> my first idea was to keep a balanced tree representing free ranges (or occupied, no difference), and allow modifying it by "take" and "put" operation
  505. # [17:23] <@tbsaunde> askalski: life cycle patterns would also help
  506. # [17:23] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Ping timeout)
  507. # [17:23] <@askalski> this can be done in log(n) where n is the number of objects
  508. # [17:23] <@askalski> (operations actually)
  509. # [17:23] <@askalski> (no, objects in tree)
  510. # [17:23] * Joins: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP)
  511. # [17:24] <@askalski> having a tree gives me some footprint
  512. # [17:24] <@tbsaunde> askalski: well, the worst case for that is that each id is its own range
  513. # [17:24] <@askalski> true. then you have number of singleton + tree struct of linear size
  514. # [17:24] <@tbsaunde> if you keep the tree sorted merging ranges is easy other wise its slow
  515. # [17:25] <@askalski> I need to keep it sorted in all cases to have sub-linear deletion
  516. # [17:25] <@tbsaunde> true
  517. # [17:26] <@askalski> I have another idea
  518. # [17:26] <@askalski> most cases, the IDs will be freed in bunches
  519. # [17:26] <@askalski> like "101 objects removed"
  520. # [17:26] * Quits: nhirata (nhirata.bu@moz-2A9C9106.hsd1.ca.comcast.net) (Quit: nhirata)
  521. # [17:27] <@tbsaunde> askalski: well, yes sorrt of
  522. # [17:27] <@askalski> not necessarily they will be a valid range
  523. # [17:27] <@askalski> but there are data structures that allow fast melding to sets
  524. # [17:27] <@askalski> *two sets
  525. # [17:27] <@tbsaunde> we'll terar down a document when it goes away and that will cause a bunch of accessibles to go away, but we won't really know n accessibles with ids x y and z are going away
  526. # [17:27] <@askalski> I could use such struct to store all available numbers, producing more lazily if necessairy
  527. # [17:29] <@tbsaunde> askalski: this is union find?
  528. # [17:30] <@askalski> tbsaunde, no ,binomial heaps
  529. # [17:30] <@tbsaunde> oh hm
  530. # [17:30] <@askalski> find and union does not support divie
  531. # [17:30] <@askalski> *divide
  532. # [17:31] <@askalski> I was thinking of something like "ok, let's have a pool of 2046 free id's. if you need more, I'll lazily produce more"
  533. # [17:31] <@askalski> and also "oh, over 100 IDs have been freed, I guess I'll merge that bunch with a pool"
  534. # [17:31] <@tbsaunde> I see
  535. # [17:31] <@askalski> everything lazily, but with public triggers "ok, merge it now"
  536. # [17:32] <@askalski> that might be super fast, because the freed tree will be always kept small
  537. # [17:32] <@askalski> thus log(small) time footprint
  538. # [17:32] <@askalski> the tricky part is to get addressing function right, because binomial heaps are non-trivial
  539. # [17:33] <@tbsaunde> askalski: addressing function?
  540. # [17:33] <@askalski> tbsaunde, to have a tree in an array instead of pointers
  541. # [17:33] <@tbsaunde> I don't really remember if binomial heaps are different from a standard one
  542. # [17:33] <@askalski> it's easy in balanced-ary
  543. # [17:34] <@askalski> http://en.wikipedia.org/wiki/Binomial_heap
  544. # [17:34] <@askalski> I am talking about having two heaps each representing a pool of free numbers. one is the original and other is freed
  545. # [17:34] <@askalski> take new-id is "deletemin" on any of these
  546. # [17:34] <@askalski> release id is "add to smaller one"
  547. # [17:35] <@askalski> produce more is "create next subheap and merge it with bigger one"
  548. # [17:35] <@askalski> and "relax" is "merge small with big"
  549. # [17:35] <@askalski> it's sick complicated, but might be fast
  550. # [17:36] * Joins: shorlander (shorlander@moz-853043D6.dhcp.insightbb.com)
  551. # [17:36] <@tbsaunde> askalski: I see, that might be reasonable
  552. # [17:36] <@tbsaunde> but its complicated
  553. # [17:37] <@askalski> tbsaunde, I figured a problem
  554. # [17:37] <@askalski> tbsaunde, I need to remember which number haven't been produced yet, and it's only partially ordered
  555. # [17:37] <@askalski> but ... that can be done, just create them ordered
  556. # [17:37] <@askalski> I'll think about it more
  557. # [17:37] <@askalski> now I need to go for a lunchs
  558. # [17:37] <@askalski> *lunch
  559. # [17:37] <@tbsaunde> askalski: ok
  560. # [17:38] <@askalski> you can ask someone to review this idea
  561. # [17:38] <@tbsaunde> askalski: well, surkov should is reasonable
  562. # [17:39] <@askalski> surkov, can you read my idea from <askalski> I was thinking of something like "ok, let's have a pool of 2046 free id's. if you need more, I'll lazily produce more
  563. # [17:39] <@askalski> ?
  564. # [17:39] <@askalski> I am going now
  565. # [17:39] <@askalski> bye
  566. # [17:39] <@surkov> tbsaunde: do we have any telemetry data about amount of objects? no, right?
  567. # [17:40] <@tbsaunde> surkov: when I proposed that you said no ;p
  568. # [17:40] * khuey|away is now known as khuey
  569. # [17:40] <@tbsaunde> :)
  570. # [17:40] <@surkov> askalski: hard to say, but that's ok for the start
  571. # [17:40] <@surkov> tbsaunde: yep, right :)
  572. # [17:40] <@tbsaunde> surkov: but shouldn't be hard
  573. # [17:40] <@surkov> I said we need memory not amount
  574. # [17:40] <@surkov> maybe it makes sense to do
  575. # [17:41] <@surkov> at least temporary
  576. # [17:41] <@tbsaunde> surkov: yeah, just turns out those are fiarly coorilated
  577. # [17:41] <@tbsaunde> modulo doc accessibles being a lot bigger
  578. # [17:43] * Quits: webben (benjamin@moz-BA505DDD.static.cloud-ips.com) (Ping timeout)
  579. # [17:43] <@tbsaunde> surkov: askalski my one concern is if this is worth the extra time to implement
  580. # [17:44] <@surkov> tbsaunde: are you about pool or telemtry
  581. # [17:44] <@surkov> ?
  582. # [17:45] <@tbsaunde> surkov: about askalski's idea for a pool
  583. # [17:46] <@tbsaunde> surkov: telemetry is easy, though waiting for data will take a while
  584. # [17:46] <@surkov> well, I didn't follow you unfortunately to be helpful
  585. # [17:49] <@tbsaunde> surkov: ok
  586. # [17:52] * khuey is now known as khuey|away
  587. # [17:52] * Joins: hub (hub@83874EA1.EB7C1AF9.6F478678.IP)
  588. # [17:52] * ChanServ sets mode: +o hub
  589. # [17:52] * khuey|away is now known as khuey
  590. # [17:57] * Joins: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com)
  591. # [17:59] * khuey is now known as khuey|away
  592. # [17:59] * khuey|away is now known as khuey
  593. # [18:01] <@MarcoZ> Good morning hub!
  594. # [18:01] * @MarcoZ is totally stumped by the discussion between askalski and tbsaunde. I must admit this went waaaaay over my head. LOL
  595. # [18:01] * @MarcoZ noticed he's getting old, with his computer science studies being 15 years behind him.
  596. # [18:02] <@hub> MarcoZ: I finished CS in university in 1995
  597. # [18:03] * Quits: jhk (jiggy@8E6C34C1.A3F9767A.1C37C358.IP) (Ping timeout)
  598. # [18:03] <@MarcoZ> hub: What year were you born?
  599. # [18:05] <@firebot> marco.zehe@googlemail.com changed the Status on bug 723833 from RESOLVED to VERIFIED.
  600. # [18:05] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=723833 nor, --, mozilla13, surkov.alexander, RESO FIXED, IAccessibleText::setCaretOffset on location or search bar causes focus to jump
  601. # [18:15] <@firebot> hub@mozilla.com changed the Target Milestone on bug 672504 from --- to mozilla13.
  602. # [18:15] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=672504 nor, --, mozilla13, hub, ASSI, Don't keep pointer to weak presshell in accessible
  603. # [18:15] <@firebot> hub@mozilla.com changed the Target Milestone on bug 673405 from --- to mozilla13.
  604. # [18:15] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=673405 cri, --, mozilla13, hub, NEW, Rename GetDocAccessible() to Document()
  605. # [18:16] <@firebot> hub@mozilla.com changed the Target Milestone on bug 721947 from --- to mozilla13.
  606. # [18:16] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=721947 nor, --, mozilla13, hub, NEW, don't use nsIWeakShell
  607. # [18:16] * Quits: @askalski (akuda@moz-4C8A107E.pool85-48-91.dynamic.orange.es) (Quit: Wychodzi)
  608. # [18:23] * @MarcoZ crosses fingers
  609. # [18:36] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
  610. # [18:38] * Joins: webben (benjamin@moz-BA505DDD.static.cloud-ips.com)
  611. # [18:46] * Quits: @surkov (surkov@EB9D20A1.F78D7EEB.34044A7F.IP) (Quit: surkov)
  612. # [18:53] * Joins: mib_jdp4rw (Mibbit@moz-211991B3.broadband10.iol.cz)
  613. # [18:54] <@tbsaunde> man, a minion would be great
  614. # [18:54] <khuey> srsly
  615. # [18:56] <@hub> MarcoZ: crossing even more fingers as the try build I had last night was carrying other patches from inbound and it was a bit orange.
  616. # [18:56] <@hub> I'm confident
  617. # [18:56] * @hub knock on wood
  618. # [19:00] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
  619. # [19:00] * Joins: drexler (chatzilla@moz-2C2B7D1F.hsd1.vt.comcast.net)
  620. # [19:01] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
  621. # [19:03] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
  622. # [19:03] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
  623. # [19:04] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
  624. # [19:04] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
  625. # [19:05] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
  626. # [19:06] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
  627. # [19:06] * Quits: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp) (Client exited)
  628. # [19:06] * Joins: mike5w3c (MikeS@moz-DAFE1A45.tokyo.ocn.ne.jp)
  629. # [19:08] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
  630. # [19:10] * Joins: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net)
  631. # [19:17] <@MarcoZ> hub: We'll see what happens! At least it didn't burn the tree, meaning it seems to compile OK! Now it just needs to pass tests without the leaks. :)
  632. # [19:23] <@firebot> bmo@edmorley.co.uk changed the Status on bug 539694 from ASSIGNED to RESOLVED.
  633. # [19:23] <@firebot> bmo@edmorley.co.uk set the Resolution field on bug 539694 to FIXED.
  634. # [19:23] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=539694 nor, --, mozilla11, jigneshhk1992, RESO FIXED, accessible objects should have private copy constructor
  635. # [19:35] * @MarcoZ is off for the evening. See you!
  636. # [19:35] * Quits: @MarcoZ (marco.zehe@moz-44FC024.dip.t-dialin.net) (Quit: night!)
  637. # [19:36] * Parts: mib_jdp4rw (Mibbit@moz-211991B3.broadband10.iol.cz)
  638. # [19:36] <@firebot> New Firefox - Disability Access bug 725725 filed by sokiawri@wegwerfemail.de.
  639. # [19:36] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725725 nor, --, ---, nobody, UNCO, Javascript Security Error 1000 blocks functionalities like opening links in many website (including
  640. # [19:45] <@firebot> longsonr@gmail.com changed the Status on bug 725725 from UNCONFIRMED to RESOLVED.
  641. # [19:46] <@firebot> longsonr@gmail.com set the Resolution field on bug 725725 to DUPLICATE of bug 725634.
  642. # [19:46] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=725634 cri, --, ---, nobody, NEW, Google Search results not working when cookies disabled
  643. # [19:48] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
  644. # [19:52] <@hub> Linux is green
  645. # [20:10] * Quits: @hub (hub@83874EA1.EB7C1AF9.6F478678.IP) (Ping timeout)
  646. # [20:49] * Joins: hub (hub@21B7B9F2.B87E9213.6E712CE2.IP)
  647. # [20:49] * ChanServ sets mode: +o hub
  648. # [20:52] <@hub> apparently Windows leak. I have no idea why this time
  649. # [20:52] <@hub> it is not in a11y
  650. # [20:52] <@tbsaunde> hub: if its not in mochitest-a11y it almost certainly isn't your fault
  651. # [20:53] <@tbsaunde> search bugzilla or wait for someone who has time to star it
  652. # [20:58] <@hub> yeah that'
  653. # [20:58] <@hub> what I think
  654. # [20:59] <@hub> it is on inbound anyway so the sheriffs will take care of it
  655. # [20:59] <@hub> cool
  656. # [20:59] <@hub> it got starred by philor
  657. # [21:00] <@hub> and android is bonkers, but that's almost expected
  658. # [21:06] <@davidb> looks like it stuck
  659. # [21:06] <@davidb> nice
  660. # [21:07] * @davidb reads about nsHTMLReflowState
  661. # [21:11] <@hub> now if I had a solution for my notifications on Mac :-/
  662. # [21:12] <@hub> trying to figure out what we do wrong
  663. # [21:12] <@tbsaunde> now we get to see how the weak ref to the doc does
  664. # [21:12] <@hub> tbsaunde: yeah that's why I wanted to land it
  665. # [21:12] <@tbsaunde> hub: what events does safari fire?
  666. # [21:12] <@tbsaunde> have you looked at what events webkit fires?
  667. # [21:15] <@hub> tbsaunde: yeah and I fire them too. they seems to not be taken into account
  668. # [21:24] <@tbsaunde> hub: weird
  669. # [21:26] <@tbsaunde> hub: can you build webkit on mac if so is it accessible and do the right thing?
  670. # [21:29] * Quits: ptheriault (ptheriault@moz-4BE034AB.ptr.us.xo.net) (Quit: ptheriault)
  671. # [21:32] <@firebot> bolterbugz@gmail.com requested feedback from bzbarsky@mit.edu for attachment 594239 on bug 495912.
  672. # [21:32] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=495912 nor, --, ---, bolterbugz, NEW, Expose alternative content in Canvas element to ATs
  673. # [21:55] * khuey is now known as khuey|away
  674. # [22:41] * Quits: @davidb (davidb@F2D29657.F60B0462.67AC9B1.IP) (Quit: davidb)
  675. # [22:47] * khuey|away is now known as khuey
  676. # [22:53] * Joins: aaronlev_ (chatzilla@moz-CDA191A6.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com)
  677. # [23:00] * Parts: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  678. # [23:14] * Quits: victorporof (victorporo@C092FEB2.1C233438.79933D60.IP) (Quit: Linkinus - http://linkinus.com)
  679. # [23:16] * Quits: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com) (Ping timeout)
  680. # [23:18] * Joins: nhirata (nhirata.bu@moz-BBE3ABD.mv.mozilla.com)
  681. # [23:22] * Joins: satdav (satdav@moz-1ECB932B.cable.virginmedia.com)
  682. # [23:23] <satdav> !seen davidb
  683. # [23:23] <@firebot> davidb was last seen 2 hours, 15 minutes and 58 seconds ago, saying '* davidb reads about nsHTMLReflowState' in #accessibility.
  684. # [23:23] <satdav> hey guys does anyone know if hes still about in the office
  685. # [23:26] <@hub> i'm not in Toronto
  686. # [23:27] <satdav> hub what one you in
  687. # [23:40] * Joins: Jamie (jamie@moz-CA26021.jantrid.net)
  688. # [23:42] <satdav> has anyone suscribed to the new mailing list
  689. # [23:43] <@hub> satdav: I'm in Vancouver.
  690. # [23:43] <@hub> and yes I subscribed to that list
  691. # [23:43] <satdav> OK
  692. # [23:43] <satdav> same
  693. # [23:49] * Joins: davidb (davidb@moz-6F9F653A.dsl.bell.ca)
  694. # [23:49] * ChanServ sets mode: +qo davidb davidb
  695. # [23:49] * Quits: @davidb (davidb@moz-6F9F653A.dsl.bell.ca) (Input/output error)
  696. # Session Close: Fri Feb 10 00:00:00 2012

The end :)