/irc-logs / mozilla / #accessibility / 2012-10-17 / end

Options:

  1. # Session Start: Wed Oct 17 00:00:00 2012
  2. # Session Ident: #accessibility
  3. # [00:18] * Joins: Archaeopteryx (itsme@moz-756328DB.cust.telecolumbus.net)
  4. # [00:19] <Archaeopteryx> hi, do xul labels support for="id"? i found this only used once: http://hg.mozilla.org/mozilla-central/rev/acd5dee9dab3
  5. # [00:21] <@tbsaunde> Archaeopteryx: this probably isn't the right place to ask that
  6. # [00:42] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  7. # [00:44] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  8. # [00:46] * Quits: Archaeopteryx (itsme@moz-756328DB.cust.telecolumbus.net) (Quit: Too much information in my brain driving me insane)
  9. # [01:22] <@firebot> New Core - Disability Access APIs bug 802415 filed by eitan@monotonous.org.
  10. # [01:22] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=802415 nor, --, ---, nobody, NEW, [AccessFu] Introduce better feedback when switching tabs and focusing on content area.
  11. # [01:23] <@firebot> eitan@monotonous.org requested review from dbolter@mozilla.com for attachment 672086 on bug 802415.
  12. # [01:41] <@firebot> eitan@monotonous.org requested review from dbolter@mozilla.com for attachment 672093 on bug 801671.
  13. # [01:41] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=801671 nor, --, ---, eitan, ASSI, [AccessFu] Regression in visual tracking
  14. # [01:43] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  15. # [01:44] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  16. # [02:05] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  17. # [02:23] * Joins: surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP)
  18. # [02:23] * ChanServ sets mode: +o surkov
  19. # [02:32] * Quits: nhirata (nhirata.bu@moz-C03D0C61.vlan426.asr1.sfo1.gblx.net) (Ping timeout)
  20. # [02:32] * Joins: nhirata (nhirata.bu@moz-C03D0C61.vlan426.asr1.sfo1.gblx.net)
  21. # [02:43] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  22. # [02:45] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  23. # [02:49] * Quits: @jprmc (jprmc@2557E599.66715431.D25A875A.IP) (Ping timeout)
  24. # [02:52] * Joins: jprmc (jprmc@43CB6079.66715431.D25A875A.IP)
  25. # [02:52] * ChanServ sets mode: +o jprmc
  26. # [03:43] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  27. # [03:45] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  28. # [03:51] * Quits: nhirata (nhirata.bu@moz-C03D0C61.vlan426.asr1.sfo1.gblx.net) (Quit: nhirata)
  29. # [03:55] * Quits: @surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP) (Quit: surkov)
  30. # [03:55] <@tbsaunde> surkov: so, why don't we just merge AttributedChangedImpl() into AttributeChanged()?
  31. # [04:07] <@firebot> ryanvm@gmail.com denied in-testsuite on bug 800905.
  32. # [04:07] <@firebot> ryanvm@gmail.com changed the Resolution on bug 800905 from --- to FIXED.
  33. # [04:08] <@firebot> ryanvm@gmail.com changed the Status on bug 800905 from NEW to RESOLVED.
  34. # [04:08] <@firebot> ryanvm@gmail.com changed the Target Milestone on bug 800905 from --- to mozilla19.
  35. # [04:08] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=800905 maj, --, ---, eitan, NEW, [AccessFu] Web content in every tab but the first is no longer accessible
  36. # [04:32] * Joins: surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP)
  37. # [04:32] * ChanServ sets mode: +o surkov
  38. # [04:44] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  39. # [04:45] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  40. # [04:50] * khuey is now known as khuey|away
  41. # [04:51] * Quits: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP) (Input/output error)
  42. # [05:11] <@surkov> hi, tbsaunde
  43. # [05:11] <@tbsaunde> surkov: hey
  44. # [05:11] <@tbsaunde> surkov: what's up? did you see my question a while ago?
  45. # [05:11] <@surkov> tbsaunde: any specifics on your plate these days?
  46. # [05:12] <@surkov> tbsaunde: I guess I missed them
  47. # [05:12] <@surkov> can you resend them?
  48. # [05:12] <@tbsaunde> surkov: the spelling perf thing otherwise not really
  49. # [05:12] <@tbsaunde> <@tbsaunde> surkov: so, why don't we just merge AttributedChangedImpl() into AttributeChanged()?
  50. # [05:12] <@surkov> ok
  51. # [05:14] <@surkov> tbsaunde: I don't see a good reason to keep them separately, but we'd need to look at history to learn a reason why it was done before
  52. # [05:15] * Quits: @surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP) (Quit: surkov)
  53. # [05:21] * Quits: @jprmc (jprmc@43CB6079.66715431.D25A875A.IP) (Ping timeout)
  54. # [05:22] * Joins: ehsan (ehsan@moz-C48D29C4.cable.teksavvy.com)
  55. # [05:33] * Joins: surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP)
  56. # [05:33] * ChanServ sets mode: +o surkov
  57. # [05:34] <@tbsaunde> surkov: true checking history makes sense
  58. # [05:35] <@tbsaunde> surkov: did you want me to look at something particular?
  59. # [05:35] <@surkov> tbsaunde: I'm thinking about that HTML list issue we talked yesterday
  60. # [05:36] <@surkov> would you like to take it after that spelling perf issue?
  61. # [05:41] <@tbsaunde> surkov: I guess, I sort of want to work on making tree update more understandable in general
  62. # [05:42] <@surkov> ok
  63. # [05:42] <@surkov> btw, tbsaunde did you get any progress on bug 768243?
  64. # [05:42] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=768243 is not accessible
  65. # [05:43] <@surkov> then I need to finish that reorder event stuff
  66. # [05:43] <@surkov> asap
  67. # [05:43] <@tbsaunde> surkov: that's a big part of why I want to make tree update sane
  68. # [05:43] <@surkov> I see
  69. # [05:43] <@tbsaunde> because I don't really have any idea how to fix that other than kill InvalidateChildren()
  70. # [05:43] <@surkov> good
  71. # [05:44] <@surkov> I mean I want to kill INvalidateChildren for a long time
  72. # [05:44] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  73. # [05:44] <@tbsaunde> the problem is right I'm not really sure where to start if I can't convince you mInvalidationList in particular and probably generally lazy construction is bad / not worth having
  74. # [05:46] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  75. # [06:25] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Client exited)
  76. # [06:44] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  77. # [06:46] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  78. # [06:49] <@tbsaunde> surkov: are you aware of a case where there is a node that it makes sense to have an accessible for if and only if there is an idref pointing at it
  79. # [06:50] <@tbsaunde> ?
  80. # [06:50] <@surkov> tbsaunde: things like span?
  81. # [06:51] <@tbsaunde> surkov: full example?
  82. # [06:51] <@surkov> tbsaunde: shouldn't you start from replacing InvalidateChildren to InsertChild
  83. # [06:51] <@tbsaunde> surkov: then we have the problem that the comment on why we use InvalidateChildren now explains?
  84. # [06:52] <@surkov> tbsaunde: <span>hello</span>: text leaf; span is not accessible, but if it's referred by someone then we need to have an accessible
  85. # [06:52] <@tbsaunde> surkov: then if span isn't accessible who holds text leaf?
  86. # [06:52] <@surkov> it's parent
  87. # [06:53] <@surkov> it's -> its
  88. # [06:53] <@tbsaunde> surkov: for that case simple insert isn't enough
  89. # [06:53] <@surkov> tbsaunde: why?
  90. # [06:54] <@tbsaunde> you need to nuke any accessible who has node in subtree of non accessible node, and then recreate subtree
  91. # [06:54] <@tbsaunde> well, I guess you could avoid that if we could reparent accessibles
  92. # [06:54] <@tbsaunde> on the other hand why do we need an accessible for text leaf, why can't it be folded into parent?
  93. # [06:56] <@tbsaunde> I guess that could be interesting with something like <div><span>hello</span><input></div>
  94. # [06:57] <@tbsaunde> maybe span should get an accessible not text leaf?
  95. # [06:58] <@tbsaunde> surkov:
  96. # [06:59] <@surkov> tbsaunde: text nodes are always accessible (it was requirement of MSAA), IA2 and ATK don't need accessibles for them. Anyway they part of our internal implementation (like text interface, name calculation)
  97. # [06:59] * Joins: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se)
  98. # [07:02] <@tbsaunde> surkov: we're already talking about big changes, so that doesn't seem like enough of a reason to take the idea off the table
  99. # [07:03] <@tbsaunde> surkov: does msaa have an interface other than IAccessible?
  100. # [07:03] <@surkov> tbsaunde: no
  101. # [07:03] <@tbsaunde> surkov: so really its mostly ISimpleDOM that needs text leaves?
  102. # [07:03] <@surkov> tbsaunde: but it seems AT relies on text leaf accessibles
  103. # [07:04] <@tbsaunde> surkov: what is difference to AT between accessible for <span> and accessible for text node?
  104. # [07:04] <@tbsaunde> surkov: also which at? uia does text flattening stuff, and iirc we hide text nodes on mac / atk
  105. # [07:04] <@surkov> tbsaunde: I think it depends on props they expose
  106. # [07:05] <@surkov> tbsaunde: ask Jamie, iirc he said something about text leafs, they use them for something
  107. # [07:05] <@surkov> maybe other ATs do that
  108. # [07:05] <@surkov> anyway I wouldn't change the behavior without strong reason to do that
  109. # [07:07] <@tbsaunde> surkov: so, can you think of a reason not to always have accessible for span? or other case where there is good reason not to have accessible because we might need it?
  110. # [07:07] <@surkov> tbsaunde: it seems to me you are sure we need to get rid invalidation list and you search ways how to do that. For me it's not evident that we need to get rid it. invalidation list problems should be fixed in different way
  111. # [07:08] <@surkov> tbsaunde: yes, the reason is bug 646216 :)
  112. # [07:08] <@tbsaunde> surkov: maybe somewhat, but I also think what we are trying to to is really complicated
  113. # [07:08] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=646216 enh, --, ---, nobody, NEW, Collapse a11y tree when possible
  114. # [07:08] <@surkov> true
  115. # [07:09] <@tbsaunde> surkov: if your goal is to collapse tree then you should have accessible for span and no text leaf
  116. # [07:09] <@surkov> tbsaunde: why?
  117. # [07:09] <@tbsaunde> that way you only ever have one accessible not sometimes two
  118. # [07:09] <@surkov> :)
  119. # [07:09] <@surkov> what about empty spans? :)
  120. # [07:10] <@surkov> or span inside span inside span?
  121. # [07:10] <@tbsaunde> surkov: probably fine to just have one accessible for top span
  122. # [07:11] <@surkov> I'm not against that span may have some accessibles
  123. # [07:11] <@surkov> but I wouldn't get rid text leaf accessible to get rid invalidation list
  124. # [07:11] <@tbsaunde> well, your goal was to collapse the tree wasn't it? :)
  125. # [07:12] <@surkov> we need to shorten it, yes. for example I would not create so much accessible for div elements
  126. # [07:12] <@surkov> anyway all I want to say that text leaf accessibility is not simple decision and requires lot of investigations
  127. # [07:12] <@surkov> and actually I wouldn't do that, I would try to find another approach
  128. # [07:12] <@tbsaunde> surkov: I wouldn't be opposed to just creating accessible for all nodes, then having top nodes pull in text from children to flatten text
  129. # [07:13] <@tbsaunde> surkov: sure
  130. # [07:13] <@surkov> it seems we end up with ISimpleDOMNode :)
  131. # [07:13] <@surkov> webkit has shorten tree than we have and some at vendors likes it
  132. # [07:13] <@tbsaunde> surkov: but I'd also say we should investigate how to make what we are trying to accomplish more sane / less self contradictory, and hopefully easier to reason about
  133. # [07:14] <@surkov> iirc I was asked why we don't do the same
  134. # [07:14] <@surkov> absolutely, you dig from the start and it's good
  135. # [07:14] <@tbsaunde> surkov: well, not quiet ISimpleDOMNode since you wouldn't create accessible for the text note child of span
  136. # [07:14] <@surkov> oh yes, but it's close
  137. # [07:15] <@tbsaunde> I guess
  138. # [07:15] <@tbsaunde> trick is having text nodes and flattening tree or sort of opposite
  139. # [07:16] <@surkov> it is not opposite since we expose them already
  140. # [07:16] <@surkov> and we can reach that goal but not creating accessible for other elements
  141. # [07:17] <@tbsaunde> surkov: how is what we do related to goals be opossite? where one goal is expose text nodes, and other is have flat as possible tree
  142. # [07:17] <@surkov> tbsaunde: I'd suggest to chat with Jamie about text leaf accessibles
  143. # [07:18] <@tbsaunde> surkov: what to see what they use them for?
  144. # [07:19] <@surkov> tbsaunde: if we had a tree a -> a -> b -> b -> c -> c. We make tree shorter if we get rid 'b' and 'c' accessible but it's shorter also if we just get rid 'b' accessible leaving 'a' and 'c' accessible unchanged
  145. # [07:19] <@tbsaunde> really I don't think I'm that opposed to people using ISimpleDOM if that want to see things like text nodes (I think)
  146. # [07:19] <@surkov> formally
  147. # [07:20] <@surkov> tbsaunde: I'd set the question as whether this change breaks any existing screen readers. If it does then we must have a *good* reason for doing this
  148. # [07:20] <@tbsaunde> surkov: I'm not saying it can't be shorter and have text nodes
  149. # [07:20] <@tbsaunde> I'm saying tree without text nodes should always be as flat or flatter than tree with them
  150. # [07:21] <@surkov> you said it's opposite, I said it's not, anyway it doesn't really matter
  151. # [07:21] <@tbsaunde> true
  152. # [07:21] <@tbsaunde> how does making uia stuff fall as a reason?
  153. # [07:22] <@surkov> sorry (failed to understand last question)
  154. # [07:22] <@tbsaunde> surkov: I mean how good a reason do you think "it makes implementing uia easier / possible"?
  155. # [07:23] <@tbsaunde> anyway I guess better question is what can we do with all these insane somewhat contradictory requirements to make things better
  156. # [07:23] <@surkov> it possible then it changes things, easier is probably not good reason, since stopping text leafs being an accessible is a huge work on our side
  157. # [07:24] <@surkov> but uia express is msaa extension and msaa needs text leaf accessibles what makes me think that uia is not against text leaf accessibles
  158. # [07:25] <@tbsaunde> surkov: iirc we disucssed implementing uia text interface in a bug and it wanted flat tree
  159. # [07:26] <@surkov> tbsaunde: I need to look at that bug, before summer I had some ideas on uia text interface implementation
  160. # [07:26] <@surkov> I wanted to build it on top of our text interface
  161. # [07:27] <@tbsaunde> surkov: I se, that sounds like kind of a mess unless you plan on fixing a bunch of bugs first
  162. # [07:28] <@surkov> agree text interface is a mess
  163. # [07:30] <@tbsaunde> surkov: so, somehow we need to improve current tree update stuff, since if I can't really reason about what we have its hard to fix it, html list thing might be doable, but I don't think I can really try and remove InvalidateChildren() with the amount I understand of what we have
  164. # [07:32] <@surkov> tbsaunde: the problem of InsertChild approach is who to find the accessible by node. I did some steps on this way but I didn't get any good algorithm. I did some minor fixes to simplify the task (like image map tree stuff) but it's not finished yet
  165. # [07:32] <@tbsaunde> perhaps invalidation list isn't the best place to start with things that make it complicated, but its a fairly self contained thing (atleast in some ways) and a bit of a stretch from the way other things behave
  166. # [07:33] <@tbsaunde> surkov: so, why don't we know the know that changed from the notification we recieve?
  167. # [07:33] <@tbsaunde> I guess that doesn't really work for removals
  168. # [07:33] <@surkov> why it doesn't work for removals?
  169. # [07:33] <@tbsaunde> but we process those sync iirc so I think that doesn't actually matter
  170. # [07:34] <@tbsaunde> well, if its not sync you need to answer the question which accessible children are for nodes in removed subtree so you can remove those children
  171. # [07:35] * Quits: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se) (Quit: Leaving.)
  172. # [07:38] <@tbsaunde> surkov: anyway, if you sow me then maybe I'll have ideas, but I'm sort of blocked other than trying to rip other stuff out
  173. # [07:39] <@surkov> tbsaunde: I need to look at my wips maybe I can make something more readable from them
  174. # [07:45] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  175. # [07:46] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  176. # [08:02] <@tbsaunde> surkov: so, I'm not convinced it is even possible to have a fast algorithm to update accessible tree based on just list of nodes that were inserted if a11y tree and node tree don't map 1 to 1
  177. # [08:03] <@tbsaunde> say you have <div><span><span> <span>hello</span> <span>world</span> <span>it's me</span> </span></span></span></div>
  178. # [08:04] <@surkov> it shouldn't be slower than tree recreation
  179. # [08:04] <@tbsaunde> and you change middle span containing world by adding aria thing to point at it, or you just insert it
  180. # [08:07] <@tbsaunde> so, maybe, on other hand I don't really understand how deep trees get constructed non lazy with nsAccTreeWalker, so I can't really say I'm sure that's true
  181. # [08:12] <fxa90id> :)
  182. # [08:13] <@tbsaunde> surkov: so, its not very nice or very fast, but it occurs to me we might be able to reuse most of nsAccTreeWalker to handle the case tree is mostly constructed, but needs accessibles inserted
  183. # [08:14] <@surkov> yes
  184. # [08:17] <@tbsaunde> surkov: does it seem reasonable?
  185. # [08:17] <@tbsaunde> I guess I could try it, but it makes me sad and want to cry
  186. # [08:17] <@surkov> tbsaunde: try to implement InsertChild approach?
  187. # [08:18] <@surkov> if so why it make you sad?
  188. # [08:18] <@tbsaunde> surkov: I'm still not clear how just InsertChild would work, but maybe I don't understand your idea
  189. # [08:18] <@surkov> main problem is to find insertion point
  190. # [08:19] <@tbsaunde> surkov: I meant the modify or copy nsAccTreeWalker so it can handle inserting into partially constructed tree
  191. # [08:19] <@surkov> if we could change accTreeWalker then it's great
  192. # [08:19] <@surkov> but some accessible overrides accTreeWalker behavior
  193. # [08:19] <@surkov> for example html:table inserts caption into beginning
  194. # [08:20] <@tbsaunde> and it makes me sad because it would be basically throughing out what we know about what was inserting, and just walking whole subtree trying to create new accessibles
  195. # [08:20] <@tbsaunde> which is horribly inefficent
  196. # [08:20] <@surkov> so if it's caption in the middle and you insert after caption then you should insert the accessible after element that was previous to caption
  197. # [08:21] <@surkov> tbsaunde: that didn't seem to be origin idea
  198. # [08:21] <@tbsaunde> surkov: ok?
  199. # [08:21] * Joins: icaaq (Adium@2400A129.7DCD925.CE255B90.IP)
  200. # [08:22] <@tbsaunde> surkov: the thing about InsertChild is that while terribly ineffiecent at it nsAccTreeWalker sort of finds insertion points
  201. # [08:22] <@surkov> tbsaunde: the idea was to find insertion point, maybe we can redesign accTreeWalker to not start from the start
  202. # [08:22] <@tbsaunde> but other than that approach to find insertion point I can't think of any others given the problem
  203. # [08:23] <@surkov> if you reuse AccTreeWalker as is then I guess it'd be not very performant I agree
  204. # [08:23] <@surkov> maybe we should change AccTreeWalker
  205. # [08:23] <@tbsaunde> surkov: sure, but that sort of ignores the fact that finding the insertion point seems to be a very hard problem
  206. # [08:24] <@surkov> I don't like it's based on nsIContent::GetChildren
  207. # [08:24] <@surkov> it seems so
  208. # [08:24] <@surkov> probably that's why I didn't finish it yet :)
  209. # [08:24] <@tbsaunde> what's so bad about get GetChildren()? since it takes care of xbl / anon content?
  210. # [08:26] <@surkov> tbsaunde: I don't like it's array nature and I think we should move closer to frames tree rather than to DOM
  211. # [08:26] * Joins: margle (margle@moz-BE6AB534.dsl.mweb.co.za)
  212. # [08:26] <@tbsaunde> surkov: what's wrong with array?
  213. # [08:27] <@tbsaunde> is setup of frame tree documented somewhere?
  214. # [08:28] <@firebot> glob@mozilla.com changed the Resolution on bug 802493 from --- to INVALID.
  215. # [08:28] <@surkov> tbsaunde: at least array of explicit children is excess burden (by default it's not created) and it isn't needed for insertion point searching
  216. # [08:28] <@firebot> glob@mozilla.com changed the Status on bug 802493 from UNCONFIRMED to RESOLVED.
  217. # [08:28] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=802493 cri, --, ---, nobody, RESO INVALID, defects in disabilityaccess
  218. # [08:29] <@tbsaunde> surkov: true
  219. # [08:30] <@tbsaunde> surkov: we could probably just reimplement GetChildren() but I'm not sure how much that would help on its own
  220. # [08:30] <@surkov> we'd need to have iterators or just traverse frame tree (perhaps it will give us all what we want)
  221. # [08:31] * Joins: mdcurran (mick@moz-C48DC1F2.static.tpgi.com.au)
  222. # [08:31] <@surkov> including it might help stupid trees like <div><div style="position: absolute"></div></div>
  223. # [08:31] <@surkov> in this example we have section -> section tree
  224. # [08:31] <@surkov> but it doesn't make any sense to keep nested div as the child of the top one
  225. # [08:32] <@surkov> we'd avoid special handling of list bullets too
  226. # [08:32] <@tbsaunde> surkov: why does positioning effect how much sense there is in having child div have accesisble?
  227. # [08:32] <@surkov> tbsaunde: because we have unnice things for gechildAtPoint/getBounds
  228. # [08:34] <@tbsaunde> like what do you do if somebody has <div> <div style="position: absolute"></div> <input></div> ?
  229. # [08:35] <@tbsaunde> surkov: on the other hand it might make aria stuffs more tricky since its based on nodes
  230. # [08:37] <@surkov> it shouldn't
  231. # [08:37] <@surkov> tbsaunde: your example is ok, since position absolute is inherited
  232. # [08:38] <@tbsaunde> surkov: by siblings?
  233. # [08:38] <@surkov> tbsaunde: ah, I misread it, so we should have section and section -> input
  234. # [08:39] <@surkov> sarcasmer
  235. # [08:39] <@tbsaunde> surkov: oh, so you want the position:absolute div's accessible to a sibling of the other div's accessible?
  236. # [08:40] <@tbsaunde> surkov: ?
  237. # [08:40] <@surkov> tbsaunde: I don't know how they are related in frame tree, I assume they are siblings of root frame probably
  238. # [08:40] <@tbsaunde> surkov: is sacasmer russian or what?
  239. # [08:41] <@surkov> tbsaunde: it's verb from sarcasm
  240. # [08:41] <@surkov> it's about your "inherited by siblings"
  241. # [08:41] <@tbsaunde> ah, I see
  242. # [08:45] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  243. # [08:46] <@firebot> surkov.alexander@gmail.com granted in-testsuite on bug 637578.
  244. # [08:46] <@firebot> surkov.alexander@gmail.com changed the Target Milestone on bug 637578 from --- to mozilla19.
  245. # [08:46] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=637578 nor, --, mozilla19, surkov.alexander, ASSI, Expose how accessible name was determined
  246. # [08:47] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  247. # [08:50] * Quits: margle (margle@moz-BE6AB534.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  248. # [08:53] * Joins: margle (margle@moz-BE6AB534.dsl.mweb.co.za)
  249. # [09:10] * Quits: margle (margle@moz-BE6AB534.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  250. # [09:15] * Joins: margle (margle@moz-BE6AB534.dsl.mweb.co.za)
  251. # [09:16] * Joins: icaaq1 (Adium@2400A129.7DCD925.CE255B90.IP)
  252. # [09:16] * Quits: icaaq (Adium@2400A129.7DCD925.CE255B90.IP) (Connection reset by peer)
  253. # [09:23] * Joins: marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net)
  254. # [09:24] * Quits: marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net) (Quit: Leaving.)
  255. # [09:26] * Joins: marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net)
  256. # [09:26] * Quits: marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net) (Quit: Leaving.)
  257. # [09:26] * Joins: marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net)
  258. # [09:27] * ChanServ sets mode: +o marcoz
  259. # [09:43] <@firebot> marco.zehe@googlemail.com requested approval-mozilla-aurora from the wind for attachment 671002 on bug 800905.
  260. # [09:43] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=800905 maj, --, mozilla19, eitan, RESO FIXED, [AccessFu] Web content in every tab but the first is no longer accessible
  261. # [09:45] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  262. # [09:47] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  263. # [09:50] * Quits: icaaq1 (Adium@2400A129.7DCD925.CE255B90.IP) (Ping timeout)
  264. # [09:56] <@tbsaunde> surkov: so, we got distracted by me wanting to kill the reverse idrefs stuff, but as I said in the bug we don't need to break any of that to get rid of mInvalidationList
  265. # [09:58] <@tbsaunde> I want to break the idref in xbl case, because there doesn't seem to be a compeling reason not to when we control all the xbl so we can just arrange for there to be idrefs in both directions
  266. # [09:58] <@tbsaunde> but we could do something sort of hacky, but outside tree update so still making that simpler and keep idrefs in xbl working
  267. # [09:59] <@surkov> tbsaunde: we don't control xbl in general
  268. # [09:59] <@tbsaunde> surkov: how? bz claims its basically chrome only accept tests
  269. # [10:00] <@surkov> tbsaunde: add ons, also keep in mind ongoing xbl2
  270. # [10:01] <@tbsaunde> surkov: we break addons all the time with interface changes and changes in js stuff, so that doesn't sound like much if any of an issue
  271. # [10:01] <@surkov> tbsaunde: what do you want to change about xml?
  272. # [10:01] <@surkov> xbl?
  273. # [10:02] <@tbsaunde> surkov: if xbl2 ever actually happens it'll be legitimate, so either nsIDocumentObserver will be changed to work with it or there will probabl be some sort of real api to learn about xbl changes which makes handling it fine and nice
  274. # [10:03] <@tbsaunde> surkov: if we update the idref reverse cache on content then it doesn't get updated when the node the attribute is on is in xbl binding
  275. # [10:04] <@tbsaunde> so <content aria-labelledby="some_id">
  276. # [10:05] <@tbsaunde> so that would mean if you had that then accessible for <content> would have relation to accessible for content target, but not reverse way unless author of binding / code embeding binding made explicit reverse with equivelent of @for in xul
  277. # [10:06] <@surkov> what is a reason to stop this behavior?
  278. # [10:07] <@tbsaunde> we can ovcourse also look at addons mxr to see if any there even use aria stuff
  279. # [10:07] <@surkov> tbsaunde: couple questions: what's wrong with this behavior and what alternative do you suggest?
  280. # [10:08] <@tbsaunde> surkov: it makes our code simpler, and I think will help make tree update take less time (we bugs on it causing jankyness)
  281. # [10:09] <@tbsaunde> nothings really "wrong" with it beyond the fact of us having to do this reverse idref stuff in the first place being wrong
  282. # [10:09] <@surkov> tbsaunde: so we really spend noticeable time for xbl stuff?
  283. # [10:09] <@surkov> tbsaunde: what's wrong with reverse idref stuff?
  284. # [10:09] <@tbsaunde> surkov: noticable time doing what exactly?
  285. # [10:10] <@surkov> tbsaunde: I guess processing <content aria-labelledby="some_id"> ase
  286. # [10:10] <@surkov> case
  287. # [10:10] <@tbsaunde> surkov: its api that forces slow things?
  288. # [10:10] <@surkov> which api do you talk?
  289. # [10:11] * Joins: icaaq (Adium@2400A129.7DCD925.CE255B90.IP)
  290. # [10:11] <@tbsaunde> surkov: reverse idrefs is the api
  291. # [10:11] <@surkov> ok
  292. # [10:11] <@surkov> tbsaunde: AT needs that API I think, if we won't do then they will do that slower I think
  293. # [10:11] <@surkov> I'm not sure I follow you
  294. # [10:12] <@tbsaunde> surkov: I doubt looking at attriutes in xbl is too too bad, but I think mInvalidationList processing may take considerable time
  295. # [10:12] <@tbsaunde> surkov: web page should do it
  296. # [10:12] <@surkov> but in general I don't like to change behavior or api as side effect of not related bug
  297. # [10:13] <@surkov> tbsaunde: that should depend on the web page, pages having a lot of ARIA might be slower actually
  298. # [10:13] <@tbsaunde> surkov: webbpage / ui should do it if they can't use standard controls for whatever reason then they should have aria-labeledby=blah and blah should have aria-labelfor=firstthing
  299. # [10:14] <@tbsaunde> surkov: I don't see how this can possibly be slow for the web page
  300. # [10:15] <@surkov> unfortunately I think those API are developed to not make the author life easier (not our lives)
  301. # [10:15] <@tbsaunde> surkov: what bug you put in is just a matter of drawing lines
  302. # [10:16] <@tbsaunde> surkov: I'm not sure I understand
  303. # [10:16] <@surkov> same with me for your words :)
  304. # [10:16] <@surkov> I meant having the author to not specify reverse relations is a good thing for the author
  305. # [10:17] <@tbsaunde> surkov: except the part where they make the browser they're writing a ui for slower I suppose
  306. # [10:17] <@surkov> tbsaunde: why you don't suggest to extend HTML and add reverse attribute for @for.
  307. # [10:18] <@surkov> tbsaunde: it seems the web author doesn't so cares about his web page speed and they think the browser should take care about it
  308. # [10:18] <@tbsaunde> surkov: I think the dom already knows how to reverse @for atleast I that's the impression I got from bz
  309. # [10:18] <@surkov> tbsaunde: yes, and the same we did for a11y
  310. # [10:19] <@tbsaunde> surkov: on other hand I do think we should reverse aria-labefor / aria-ddescriptionfor
  311. # [10:19] <@tbsaunde> s/reverse/add/
  312. # [10:19] <@surkov> why?
  313. # [10:19] <@surkov> what's difference between @for and aria-labelledby?
  314. # [10:19] <@surkov> both of them don't have reverse attribute
  315. # [10:20] <@tbsaunde> surkov: isn't @for special in where you can put it? I"m not really sure
  316. # [10:20] * @surkov failed to translate
  317. # [10:21] <@surkov> tbsaunde: anyway, we have aria-labelledby and we don't have aria-labelledfor and we need to live with that
  318. # [10:21] <@surkov> we need to calculate reverse relations
  319. # [10:21] <@surkov> we can keep invalidation list or
  320. # [10:21] <@surkov> if you really want then we can replace it on something else
  321. # [10:22] <@surkov> but I wouldn't like to change any existing behavior
  322. # [10:22] <@surkov> at least as a side affect
  323. # [10:26] <@tbsaunde> surkov: we certainly need to live with reverse relations in content, I'm not sure I agree for chrome
  324. # [10:27] <@tbsaunde> surkov: mostly I just want lazy accesisble creation to stop
  325. # [10:27] <@tbsaunde> I also want to do whatever we can to only have one way for things to be done
  326. # [10:28] * Quits: icaaq (Adium@2400A129.7DCD925.CE255B90.IP) (Quit: Leaving.)
  327. # [10:29] <@tbsaunde> note that stopping lazy accessible creation seems like it will help make using accessible context from parent to create accessible
  328. # [10:29] <@surkov> I'm not sure why would chrome be different from the web
  329. # [10:30] <@tbsaunde> because now the only way to get that context is to crawl the tree instead of just use the information on the stack which we could do if parent accessible creation was always what triggers child accessible creation
  330. # [10:30] <@surkov> especially if chrome xbl comes to the web . don't think anybody (except us) will take care about api to handle ARIA (reverse relations) on web xbl)
  331. # [10:30] <@tbsaunde> surkov: either we control it or we can yell at addon developers more than we can yell at joes hardware in afganistan
  332. # [10:31] <@tbsaunde> surkov: I don't expect there will be an api for that specifically
  333. # [10:32] <@tbsaunde> but there are other things in gecko that want to know about dom changes, so if xbl is fully legit part of the web then they'll want to have api to know about changes in it
  334. # [10:32] <@surkov> so we support ARIA on XBL, you suggest to remove that support and you say because of perf
  335. # [10:33] <@surkov> does it really hit us?
  336. # [10:33] <@tbsaunde> well, remove some support
  337. # [10:33] <@surkov> reverse relations support?
  338. # [10:33] <@tbsaunde> I haven't measured
  339. # [10:34] * Quits: @marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net) (Quit: Leaving.)
  340. # [10:34] <@tbsaunde> remember that supporting this on xbl causes us to take a hit in other places too
  341. # [10:34] <@surkov> I like idea that we support ARIA on XBL and you don't need special tricks for that. It should really help in XBL widgets development (for firefox or add-on guys) and taking into account xbl2 it seems reasonable
  342. # [10:34] <@surkov> tbsaunde: what kind of hit?
  343. # [10:35] <@tbsaunde> suppose you add aria-labelledby pointing at big tree
  344. # [10:35] <@surkov> honestly I've got a feeling you wanna kill that xbl stuff because it doesn't mapped well into nsIDcoumentObserver approach
  345. # [10:35] <@tbsaunde> where top node in tree was previously inaccessible <span>
  346. # [10:36] <@tbsaunde> possibly crazy case, but small tree with <span> root seems common
  347. # [10:36] <@surkov> it's ok, web is wild
  348. # [10:36] <@surkov> tbsaunde: we do stupid stuff if we recreate whole tree, I agree with that
  349. # [10:36] <@surkov> for example you change @role attribute
  350. # [10:36] <@surkov> but your issue is dfiferent, right?
  351. # [10:37] <@tbsaunde> well, technically yes
  352. # [10:37] <@tbsaunde> be but do you think we'llfix recreation soon?
  353. # [10:38] * Joins: fxa90id_ (fxa90id@moz-4703E874.dsl.dynamic.t-mobile.pl)
  354. # [10:38] <@tbsaunde> we shouldn't cause bunch of non at users with a11y on to take a bunch of perf hits to support things we'll fix the perf some day
  355. # [10:39] <@surkov> tbsaunde: I'd spend time on real bugs than killing what we did before :)
  356. # [10:39] * Quits: fxa90id (fxa90id@moz-4703E874.dsl.dynamic.t-mobile.pl) (Ping timeout)
  357. # [10:39] <@tbsaunde> surkov: if there's another approach without lazy accessible creation that supports xbl and doesn't hurt perf too much that would be nice
  358. # [10:39] <@tbsaunde> surkov: not sure I follow
  359. # [10:39] <@surkov> tbsaunde: iirc you said some new notifications can be introduced to handle xbl
  360. # [10:39] <@surkov> but I'm not really sure why you hate so much that invalidationList
  361. # [10:40] <@surkov> does it lead to wrong tree?
  362. # [10:40] <@surkov> or does it have perf hit?
  363. # [10:40] <@surkov> or does it look just bad? :)
  364. # [10:40] <@tbsaunde> surkov: the only big problem I can think of with it is it is kind of ugly
  365. # [10:41] <@surkov> you unwind a long thread
  366. # [10:41] * Joins: icaaq (Adium@2400A129.7DCD925.CE255B90.IP)
  367. # [10:41] <@surkov> we have ugly invalidationList beucase of ugly ARIA support on XBL
  368. # [10:41] <@tbsaunde> surkov: hm?
  369. # [10:42] <@surkov> and you want to clean it up
  370. # [10:42] <@tbsaunde> true
  371. # [10:43] <@surkov> but if invalidationList doesn't have other problems than ugliness then we might be leave it for another times (especially because it needs to change behaviors)?
  372. # [10:44] <@surkov> I agree that part is not super nice
  373. # [10:44] <@tbsaunde> surkov: well, as I said with notification we don't change behavoir, but don't remove as much uglyness
  374. # [10:45] <@surkov> tbsaunde: if we don't change behavior and you want to get rid that list then I don't really mind
  375. # [10:45] <@tbsaunde> surkov: the thing is one ugly thing is fine, 2 a bit worse, but when you have enough of them then you have a total mess
  376. # [10:45] <@surkov> but you should be very careful about it since you cache idrefs by document accessible
  377. # [10:46] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  378. # [10:46] <@surkov> tbsaunde: that'd be all true if I share at 100% your opinion about ugliness :) but I have doubts
  379. # [10:46] <@tbsaunde> like if you have one piece of furnature in a room that's fine you walk around it, you have wo things in your path that's more, and eventually your path is blocked by stuff
  380. # [10:47] <@surkov> true
  381. # [10:47] <@tbsaunde> even many things is fine if they aren't intertwined
  382. # [10:47] * Quits: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP) (Ping timeout)
  383. # [10:48] <@surkov> I'm up for the things I don't have doubts about, but if I'm not sure this is a best solution then I prefer to wait until the dust settles down
  384. # [10:49] <@tbsaunde> there's mInvalidationList, here's also the way text changes can cause accessibles to be created, the way we have CacheChildrenInSUbTree() and CacheCHildren() with nsAccTreeWalker
  385. # [10:50] <@tbsaunde> and you have to think about / understand the way all these go together when you change one of them
  386. # [10:52] <@tbsaunde> surkov: btw how do you ffeel about trying to stop the text changes cause accessible creation thing? by creating the accessibles before ofcourse
  387. # [10:54] <@surkov> tbsaunde: what do they create?
  388. # [10:55] <@tbsaunde> surkov: HyperTextAccessible iirc, it was a while ago I saw it happen
  389. # [10:55] <@tbsaunde> iirc test case for bug 768243
  390. # [10:55] <@surkov> tbsaunde: HyperTextAccessible itself or HyperTextAccessible stuff?
  391. # [10:55] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=768243 is not accessible
  392. # [10:56] <@tbsaunde> surkov: I'm not sure
  393. # [10:56] <@tbsaunde> I can debug it tomorrow and see what I learn
  394. # [10:57] <@surkov> please
  395. # [10:57] <@surkov> tbsaunde: but basically I think we need to know whether we have consumers or not
  396. # [10:57] <@tbsaunde> surkov: consumer of what?
  397. # [10:58] <@surkov> event consumers
  398. # [10:58] <@tbsaunde> why does that maatter?
  399. # [10:59] * Quits: icaaq (Adium@2400A129.7DCD925.CE255B90.IP) (Ping timeout)
  400. # [10:59] <@surkov> we could try to skip text events part
  401. # [10:59] <@tbsaunde> surkov: that doesn't seem like the right fix
  402. # [10:59] <@surkov> but in general text change affects on accessible tree
  403. # [11:00] <@tbsaunde> surkov: why should they effect the tree?
  404. # [11:00] <@tbsaunde> involved certainly
  405. # [11:01] <@surkov> tbsaunde: say you have a node with whitespaces, if they aren't rendered then we don't have an accessible, if they are rendered then they are accessible
  406. # [11:01] <@tbsaunde> but isn't all tree mutation caused by text change ultimately related to some dom change?
  407. # [11:02] <@tbsaunde> that destinction seems kind of weird
  408. # [11:02] <@surkov> tbsaunde: yes but may be not restricted
  409. # [11:15] * Joins: icaaq (Adium@A337C70.7DCD925.CE255B90.IP)
  410. # [11:18] <@firebot> New Core - Keyboard: Navigation bug 802526 filed by masayuki@d-toybox.com.
  411. # [11:18] * Quits: icaaq (Adium@A337C70.7DCD925.CE255B90.IP) (Ping timeout)
  412. # [11:18] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=802526 nor, --, ---, nobody, NEW, caret shouldn't be moved to clipped area which is caused by overflow: hidden; in caret browsing mode
  413. # [11:19] * Joins: icaaq (Adium@A337C70.7DCD925.CE255B90.IP)
  414. # [11:20] * Joins: icaaq1 (Adium@D768FA14.7DCD925.CE255B90.IP)
  415. # [11:20] * Quits: icaaq (Adium@A337C70.7DCD925.CE255B90.IP) (Ping timeout)
  416. # [11:24] * Quits: @surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP) (Quit: surkov)
  417. # [11:39] * Joins: victorporof (victorporo@8AB128E5.14EB2DE0.79933D60.IP)
  418. # [12:23] * Joins: icaaq (Adium@moz-AE4E700C.cust.telenor.se)
  419. # [12:23] * Quits: icaaq1 (Adium@D768FA14.7DCD925.CE255B90.IP) (Connection reset by peer)
  420. # [12:24] * Quits: icaaq (Adium@moz-AE4E700C.cust.telenor.se) (Quit: Leaving.)
  421. # [12:33] * Joins: surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP)
  422. # [12:33] * ChanServ sets mode: +o surkov
  423. # [12:35] <@firebot> surkov.alexander@gmail.com cancelled review?(trev.saunders@gmail .com) for attachment 670368 on bug 740764.
  424. # [12:35] <@firebot> surkov.alexander@gmail.com requested review from trev.saunders@gmail .com for attachment 672237 on bug 740764.
  425. # [12:35] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=740764 nor, --, ---, surkov.alexander, NEW, Densify Accessible::GetAttributes
  426. # [12:35] * Quits: @surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP) (Quit: surkov)
  427. # [13:25] * Quits: mdcurran (mick@moz-C48DC1F2.static.tpgi.com.au) (Ping timeout)
  428. # [13:51] * Joins: marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net)
  429. # [13:52] * ChanServ sets mode: +o marcoz
  430. # [14:27] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  431. # [14:35] <@firebot> marco.zehe@googlemail.com changed the Status on bug 800905 from RESOLVED to VERIFIED.
  432. # [14:35] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=800905 maj, --, mozilla19, eitan, VERI FIXED, [AccessFu] Web content in every tab but the first is no longer accessible
  433. # [14:57] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  434. # [14:59] * Joins: davidb (davidb@F2D29657.F60B0462.67AC9B1.IP)
  435. # [14:59] * ChanServ sets mode: +qo davidb davidb
  436. # [15:03] <@marcoz> Hi davidb!
  437. # [15:10] <@davidb> hi MarcoZ!
  438. # [15:10] * Joins: Justin_o_ (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  439. # [15:11] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Ping timeout)
  440. # [15:11] * Justin_o_ is now known as Justin_o
  441. # [15:14] * @marcoz just finished reading patches for bug 801671, bug 802270, bug 802273, bug 802280, and bug 802415. I guess we want these all for Aurora, too, if I understand correctly. Except for the first, they seem to all hang together.
  442. # [15:14] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=801671 nor, --, ---, eitan, ASSI, [AccessFu] Regression in visual tracking
  443. # [15:14] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=802270 nor, --, ---, nobody, NEW, Reuse a11y hover event for a11y focus event
  444. # [15:14] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=802273 nor, --, ---, nobody, NEW, [AccessFu] Remove presentLastPivot antipattern
  445. # [15:14] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=802280 nor, --, ---, nobody, NEW, Send LayerView focus state changes to js
  446. # [15:14] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=802415 nor, --, ---, nobody, NEW, [AccessFu] Introduce better feedback when switching tabs and focusing on content area.
  447. # [15:19] <@davidb> yeah
  448. # [15:20] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  449. # [15:39] * Quits: margle (margle@moz-BE6AB534.dsl.mweb.co.za) (Ping timeout)
  450. # [15:42] * Joins: margle (margle@moz-E938CFE7.dsl.mweb.co.za)
  451. # [15:52] * Joins: surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP)
  452. # [15:52] * ChanServ sets mode: +o surkov
  453. # [16:00] * Joins: icaaq (Adium@714E29CB.13DB46CE.3B93FF6D.IP)
  454. # [16:03] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Quit: Justin_o)
  455. # [16:04] <@davidb> my brain is hurting
  456. # [16:06] * Quits: icaaq (Adium@714E29CB.13DB46CE.3B93FF6D.IP) (Quit: Leaving.)
  457. # [16:10] <@davidb> eeejay: it is your fault :)
  458. # [16:15] <@firebot> dbolter@mozilla.com granted review for attachment 672093 on bug 801671.
  459. # [16:15] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=801671 nor, --, ---, eitan, ASSI, [AccessFu] Regression in visual tracking
  460. # [16:17] * Quits: ehsan (ehsan@moz-C48D29C4.cable.teksavvy.com) (Input/output error)
  461. # [16:19] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  462. # [16:20] <@davidb> surkov: nice one (svg email to rich)
  463. # [16:20] * khuey|away is now known as khuey
  464. # [16:20] <@surkov> thx
  465. # [16:37] <@marcoz> davidb: Yeah, having a browsing screen reader embedded in the mobile version of Firefox creates some other-side-of-the-fence experiences. ;)
  466. # [16:37] <@davidb> heh, well there is that, but there is also having to get back into the code authors headspace
  467. # [16:38] <@davidb> gok heavily used atk so I'm no AT virgin :)
  468. # [16:41] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Quit: Justin_o)
  469. # [16:41] <@marcoz> I know. :) And with AccessFu, it's even a bit more involved since it translates parts of our internal API, esp the events, into Android events, bridging here and there....
  470. # [16:41] * Quits: clown (clown@67828CC7.C1A51174.9D42CF23.IP) (Quit: Leaving.)
  471. # [16:41] * Joins: jprmc (jprmc@moz-C03D0C61.vlan426.asr1.sfo1.gblx.net)
  472. # [16:41] * ChanServ sets mode: +o jprmc
  473. # [16:42] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  474. # [16:43] <@davidb> yeah
  475. # [16:43] * Quits: margle (margle@moz-E938CFE7.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  476. # [16:43] <@davidb> MarcoZ: but…. well here's an example http://mxr.mozilla.org/mozilla-central/source/accessible/src/jsat/EventManager.jsm#244
  477. # [16:47] * Joins: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP)
  478. # [16:49] * Joins: margle (margle@moz-E938CFE7.dsl.mweb.co.za)
  479. # [16:52] <@marcoz> davidb: Phew. It allows to send a message and provides a callback function if I read this correctly….
  480. # [16:53] <@marcoz> …to each presenter….
  481. # [16:54] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
  482. # [16:55] <@davidb> it's complicated
  483. # [16:55] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  484. # [16:57] * @marcoz nods.
  485. # [16:57] <@davidb> for example you have to trace … well … you eventually end up seeing content-script starts the event manager passing in … well
  486. # [16:57] <@davidb> best to discuss when eeejay is awake
  487. # [17:01] * Quits: @surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP) (Quit: surkov)
  488. # [17:03] <@marcoz> davidb: Right!
  489. # [17:03] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
  490. # [17:05] * Quits: timeless (uid4015@moz-D63BDBD0.irccloud.com) (Input/output error)
  491. # [17:06] * Joins: timeless (uid4015@moz-D63BDBD0.irccloud.com)
  492. # [17:11] * Joins: nhirata (nhirata.bu@moz-C03D0C61.vlan426.asr1.sfo1.gblx.net)
  493. # [17:19] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Quit: Justin_o)
  494. # [17:27] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  495. # [17:29] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Quit: Justin_o)
  496. # [17:31] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  497. # [17:34] * Quits: margle (margle@moz-E938CFE7.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  498. # [17:38] * Joins: margle (margle@moz-E938CFE7.dsl.mweb.co.za)
  499. # [17:42] * Joins: surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP)
  500. # [17:42] * ChanServ sets mode: +o surkov
  501. # [17:43] * khuey is now known as khuey|away
  502. # [17:44] * Joins: icaaq (Adium@714E29CB.13DB46CE.3B93FF6D.IP)
  503. # [17:44] * khuey|away is now known as khuey
  504. # [17:53] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Quit: Justin_o)
  505. # [17:55] * Quits: icaaq (Adium@714E29CB.13DB46CE.3B93FF6D.IP) (Quit: Leaving.)
  506. # [17:56] * Joins: icaaq (Adium@714E29CB.13DB46CE.3B93FF6D.IP)
  507. # [18:05] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  508. # [18:06] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Quit: Justin_o)
  509. # [18:08] * Quits: fxa90id_ (fxa90id@moz-4703E874.dsl.dynamic.t-mobile.pl) (Ping timeout)
  510. # [18:15] * Quits: margle (margle@moz-E938CFE7.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  511. # [18:21] * Joins: margle (margle@moz-E938CFE7.dsl.mweb.co.za)
  512. # [18:28] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  513. # [18:31] * Quits: margle (margle@moz-E938CFE7.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  514. # [18:36] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  515. # [18:41] * Joins: margle (margle@moz-E938CFE7.dsl.mweb.co.za)
  516. # [18:43] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
  517. # [18:45] * Quits: @surkov (surkov@4378B362.7DD25AB3.33A1AC3C.IP) (Quit: surkov)
  518. # [18:47] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Input/output error)
  519. # [18:47] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  520. # [18:52] * Quits: @marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net) (Quit: Leaving.)
  521. # [19:00] * Quits: icaaq (Adium@714E29CB.13DB46CE.3B93FF6D.IP) (Quit: Leaving.)
  522. # [19:12] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  523. # [19:12] * clown is now known as clown_mtg
  524. # [19:17] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Quit: Justin_o)
  525. # [19:22] * Quits: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP) (Connection reset by peer)
  526. # [19:23] * Joins: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP)
  527. # [19:23] <eeejay> late morning
  528. # [19:24] * Joins: hub (hub@moz-661A90AC.w86-195.abo.wanadoo.fr)
  529. # [19:24] * ChanServ sets mode: +o hub
  530. # [19:25] * Quits: margle (margle@moz-E938CFE7.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  531. # [19:26] * Joins: drexler (chatzilla@moz-CE0B60D0.hsd1.vt.comcast.net)
  532. # [19:27] * Joins: margle (margle@moz-E938CFE7.dsl.mweb.co.za)
  533. # [19:35] <@firebot> eitan@monotonous.org changed the Target Milestone on bug 801671 from --- to mozilla18.
  534. # [19:35] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=801671 nor, --, ---, eitan, ASSI, [AccessFu] Regression in visual tracking
  535. # [19:53] * Joins: fxa90id (fxa90id@moz-4703E874.dsl.dynamic.t-mobile.pl)
  536. # [19:56] <@firebot> hub@mozilla.com changed the Target Milestone on bug 801671 from mozilla18 to mozilla19.
  537. # [19:56] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=801671 nor, --, mozilla19, eitan, ASSI, [AccessFu] Regression in visual tracking
  538. # [19:57] <eeejay> hub, what if i actually meant mozilla18?
  539. # [19:58] <eeejay> not that i understand all the bz switches and flags...
  540. # [19:59] * eeejay runs an errand while b2g compiles
  541. # [20:01] <@hub> eeejay: nope. you checked in into inbound
  542. # [20:01] <@hub> you have to use the other flags to mark what is affected
  543. # [20:05] <@hub> eeejay: also according to this https://wiki.mozilla.org/Tree_Rules/Inbound
  544. # [20:05] <@hub> You do not need to set the target milestone any more (if it is set already though, please check it is correct!), since the new merge script will do that for you.
  545. # [20:05] <@hub> etc.
  546. # [20:10] * Quits: margle (margle@moz-E938CFE7.dsl.mweb.co.za) (Ping timeout)
  547. # [20:14] * @davidb nods
  548. # [20:14] <@davidb> tbsaunde: want to tell me the nasty idea now?
  549. # [20:24] <@tbsaunde> davidb: if you want
  550. # [20:25] <@davidb> tbsaunde: i will be standing next to you in 10 secs
  551. # [20:41] * Quits: clown_mtg (clown@67828CC7.C1A51174.9D42CF23.IP) (Quit: Leaving.)
  552. # [20:53] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  553. # [20:55] * Joins: marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net)
  554. # [20:55] * ChanServ sets mode: +o marcoz
  555. # [20:55] <@marcoz> Just popping in briefly.
  556. # [20:56] <@marcoz> Hi everyone!
  557. # [20:56] <@davidb> heyo
  558. # [21:01] <eeejay> yo marcoz
  559. # [21:01] <@firebot> ehsan@mozilla.com changed the Resolution on bug 637578 from --- to FIXED.
  560. # [21:01] <@firebot> ehsan@mozilla.com changed the Status on bug 637578 from ASSIGNED to RESOLVED.
  561. # [21:01] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=637578 nor, --, mozilla19, surkov.alexander, RESO FIXED, Expose how accessible name was determined
  562. # [21:01] <ehsan> oh crap
  563. # [21:01] <ehsan> firebot again
  564. # [21:01] <@firebot> ehsan: Sorry, I've no idea what 'again' might be.
  565. # [21:01] * Parts: ehsan (ehsan@F2D29657.F60B0462.67AC9B1.IP)
  566. # [21:01] <@marcoz> Hi eeejay! Great work on all those patches! I trust you know which patch needs to go in in what order! :-)
  567. # [21:01] <@marcoz> eeejay: Do we want all these bugs in Aurora, too?
  568. # [21:02] <eeejay> marcoz, no, not all
  569. # [21:02] <eeejay> marcoz, thanks for landing stuff in aurora
  570. # [21:03] * eeejay runs out for a sec
  571. # [21:04] <@marcoz> eeejay: What bug is bug 801671 a regression from? Does this also steem from the B2G multi-process work?
  572. # [21:04] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=801671 nor, --, mozilla19, eitan, ASSI, [AccessFu] Regression in visual tracking
  573. # [21:04] <eeejay> marcoz, i am not certain, tbh
  574. # [21:04] <eeejay> marcoz, i'll comment on all my patches today about what channels they should probably land in
  575. # [21:07] <@marcoz> eeejay: Great! I requested approval and put in a general comment that this is a recent regression.
  576. # [21:07] <@firebot> marco.zehe@googlemail.com requested approval-mozilla-aurora from the wind for attachment 672093 on bug 801671.
  577. # [21:08] <@marcoz> eeejay: OK, if any of the approved ones receive approval, I'll land them in the morning.
  578. # [21:08] <@marcoz> Heading out now, it's late. :)
  579. # [21:09] * Quits: @marcoz (marco.zehe@moz-EFD5D9FF.dip.t-dialin.net) (Quit: Leaving.)
  580. # [21:10] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  581. # [21:10] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Quit: Justin_o)
  582. # [21:14] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  583. # [21:25] * Joins: Justin_o_ (Justin_o@CA4758C5.A6295926.9D42CF23.IP)
  584. # [21:25] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Ping timeout)
  585. # [21:25] * Justin_o_ is now known as Justin_o
  586. # [21:28] <@davidb> eeejay: i had questions on bug 802415 FWIW
  587. # [21:28] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=802415 nor, --, ---, nobody, NEW, [AccessFu] Introduce better feedback when switching tabs and focusing on content area.
  588. # [21:34] * Joins: icaaq (Adium@714E29CB.13DB46CE.3B93FF6D.IP)
  589. # [21:35] * Quits: Justin_o (Justin_o@CA4758C5.A6295926.9D42CF23.IP) (Ping timeout)
  590. # [21:40] * Joins: Justin_o (Justin_o@CA4758C5.A6295926.9D42CF23.IP)
  591. # [21:42] * Quits: icaaq (Adium@714E29CB.13DB46CE.3B93FF6D.IP) (Quit: Leaving.)
  592. # [21:45] <@davidb> firebot: cookie
  593. # [21:45] <@firebot> Man who arrives at party two hours late will find he has been beaten to the punch.
  594. # [21:48] * Quits: drexler (chatzilla@moz-CE0B60D0.hsd1.vt.comcast.net) (Ping timeout)
  595. # [21:51] <eeejay> davidb, i'm here and sticking around this time
  596. # [21:53] * Quits: Justin_o (Justin_o@CA4758C5.A6295926.9D42CF23.IP) (Quit: Justin_o)
  597. # [21:56] * shorlander is now known as shorlander-away
  598. # [21:56] <@davidb> eeejay: oh heh, the questions are in the bug
  599. # [21:57] <eeejay> oh yea, missed that
  600. # [21:57] * shorlander-away is now known as shorlander
  601. # [21:58] * Joins: icaaq (Adium@moz-200DC1CF.customers.ownit.se)
  602. # [22:05] * Joins: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP)
  603. # [22:06] * Quits: Justin_o (Justin_o@67828CC7.C1A51174.9D42CF23.IP) (Quit: Justin_o)
  604. # [22:26] <@firebot> dbolter@mozilla.com granted review for attachment 672086 on bug 802415.
  605. # [22:26] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=802415 nor, --, ---, nobody, NEW, [AccessFu] Introduce better feedback when switching tabs and focusing on content area.
  606. # [23:11] <@davidb> tbsaunde: sort of out of nowhere, but do you agree we need our text cache?
  607. # [23:11] <@davidb> we still sometimes go directly to a frame for text
  608. # [23:12] <@davidb> iirc
  609. # [23:13] * Parts: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  610. # [23:16] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  611. # [23:19] <@tbsaunde> davidb: HyperTextAccessible text api is completely based on frames / content
  612. # [23:19] <@davidb> eeejay: someone needs to test mEnabled false once and a while i think
  613. # [23:19] <@tbsaunde> I'm not sure
  614. # [23:20] <@davidb> ok
  615. # [23:20] <eeejay> davidb, how do you mean?
  616. # [23:21] <@davidb> eeejay: my higher altitude concern is that we don't want any a11y code paths running if a11y is not required
  617. # [23:21] <@davidb> so we need to check for that
  618. # [23:21] <eeejay> davidb, still not clear, how would you change the patch, for example
  619. # [23:22] <@davidb> eeejay: what reminded me was blassey's point about mEnabled
  620. # [23:22] <@davidb> well about firing the event
  621. # [23:22] * Quits: fxa90id (fxa90id@moz-4703E874.dsl.dynamic.t-mobile.pl) (Connection reset by peer)
  622. # [23:22] <@davidb> sorry I should only pester you when I'm not juggling
  623. # [23:22] <eeejay> davidb, yeah, i think we are pretty good at not doing anything when a11y is not enabled
  624. # [23:23] <eeejay> davidb, i introduced mEnabled here to continue that trend
  625. # [23:23] * @davidb nods
  626. # [23:23] <@davidb> i just don't want surprises
  627. # [23:23] <@davidb> unless it is my birthday
  628. # [23:25] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Ping timeout)
  629. # [23:37] * Quits: icaaq (Adium@moz-200DC1CF.customers.ownit.se) (Quit: Leaving.)
  630. # [23:40] * Quits: @jprmc (jprmc@moz-C03D0C61.vlan426.asr1.sfo1.gblx.net) (Ping timeout)
  631. # [23:51] * Quits: a-865 (fmcz@moz-A5D13CA.cable.mindspring.com) (Quit: ChatZilla 0.9.89 [SeaMonkey 2.13.1/20121011090043])
  632. # [23:55] * Joins: jprmc (jprmc@moz-C03D0C61.vlan426.asr1.sfo1.gblx.net)
  633. # [23:55] * ChanServ sets mode: +o jprmc
  634. # Session Close: Thu Oct 18 00:00:00 2012

The end :)