/irc-logs / mozilla / #accessibility / 2013-09-27 / end

Options:

  1. # Session Start: Fri Sep 27 00:00:00 2013
  2. # Session Ident: #accessibility
  3. # [00:11] * Quits: brambles (xymox@moz-969AAE9B.barwen.ch) (Ping timeout)
  4. # [00:11] * Joins: brambles (xymox@moz-969AAE9B.barwen.ch)
  5. # [00:12] * Quits: Gijs (gijs@moz-C11B0461.dsl.alice.nl) (Quit: sleep)
  6. # [00:41] * Joins: rednaks (rednaks@38827678.7B2CFADA.55FFA9B4.IP)
  7. # [00:46] * Quits: brambles (xymox@moz-969AAE9B.barwen.ch) (Ping timeout)
  8. # [00:47] * Joins: brambles (xymox@moz-969AAE9B.barwen.ch)
  9. # [01:02] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
  10. # [01:02] * ChanServ sets mode: +o surkov
  11. # [01:11] * Joins: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca)
  12. # [01:33] * Quits: victorporof (victorporo@77FE7E86.477C3F8E.79933D60.IP) (Quit: victorporof)
  13. # [01:36] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
  14. # [01:44] * Quits: rednaks (rednaks@38827678.7B2CFADA.55FFA9B4.IP) (Ping timeout)
  15. # [01:46] * Quits: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca) (Quit: Leaving.)
  16. # [01:46] * Joins: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca)
  17. # [01:47] * Joins: rednaks (rednaks@2525BBDB.7D9D6404.55FFA9B4.IP)
  18. # [01:50] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
  19. # [01:50] * ChanServ sets mode: +o surkov
  20. # [02:10] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
  21. # [02:24] * Quits: rednaks (rednaks@2525BBDB.7D9D6404.55FFA9B4.IP) (Quit: Téléportation !)
  22. # [02:33] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
  23. # [02:33] * ChanServ sets mode: +o surkov
  24. # [02:55] <@firebot> bugs@pettay.fi denied review for attachment 810779 on bug 915558.
  25. # [02:55] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=915558 cri, P1, ---, nobody, REOP, XUL UI completely broken in Windows: Tabs, menus, etc.
  26. # [03:01] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
  27. # [03:08] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
  28. # [03:08] * ChanServ sets mode: +o surkov
  29. # [03:10] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
  30. # [03:46] <@firebot> ryanvm@gmail.com changed the Resolution on bug 920844 from --- to FIXED.
  31. # [03:46] <@firebot> ryanvm@gmail.com changed the Status on bug 920844 from NEW to RESOLVED.
  32. # [03:46] <@firebot> ryanvm@gmail.com changed the Target Milestone on bug 920844 from --- to mozilla27.
  33. # [03:46] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=920844 nor, --, mozilla27, eitan, RESO FIXED, [AccessFu] Support listbox options
  34. # [03:50] <@firebot> ryanvm@gmail.com changed the Resolution on bug 920547 from --- to FIXED.
  35. # [03:50] <@firebot> ryanvm@gmail.com changed the Status on bug 920547 from NEW to RESOLVED.
  36. # [03:51] <@firebot> ryanvm@gmail.com changed the Target Milestone on bug 920547 from --- to mozilla27.
  37. # [03:51] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=920547 nor, --, ---, surkov.alexander, NEW, create generic accessibles for mathml elements
  38. # [03:51] * khuey is now known as khuey|away
  39. # [04:07] * khuey|away is now known as khuey
  40. # [04:15] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
  41. # [04:15] * ChanServ sets mode: +o surkov
  42. # [04:30] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
  43. # [04:36] * Quits: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca) (Quit: Leaving.)
  44. # [04:50] * Joins: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca)
  45. # [04:52] * Quits: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca) (Ping timeout)
  46. # [05:40] * Tomcat|afk is now known as Tomcat|sheriff
  47. # [06:00] * khuey is now known as khuey|away
  48. # [06:17] * Joins: fxa (fxa90id@moz-3DACD1A4.nvidia.com)
  49. # [07:08] * Quits: peteb-away (ptbrunet@moz-B51E1692.austin.res.rr.com) (Client exited)
  50. # [07:18] * khuey|away is now known as khuey
  51. # [07:20] * Joins: icaaq (Adium@moz-2EB07EA7.cust.bredbandsbolaget.se)
  52. # [07:21] * Quits: fxa (fxa90id@moz-3DACD1A4.nvidia.com) (Quit: Leaving)
  53. # [07:22] * Tomcat|sheriff is now known as Tomcat|sheriffduty
  54. # [08:25] * Joins: cabanier (cabanier@moz-F663EC4A.hfc.comcastbusiness.net)
  55. # [08:26] <cabanier> all, I'm working on adding support for hit regions in canvas 2s
  56. # [08:26] <cabanier> 2d
  57. # [08:26] <cabanier> sorry, focus rings
  58. # [08:27] <cabanier> I've wired up all the code to make DrawCustomFocusRing and DrawSystemFocusRing work
  59. # [08:28] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
  60. # [08:28] <cabanier> but I also have to tell the accessiblity part of firefox about the region that the focus ring is covering
  61. # [08:28] <cabanier> does anyone know how to do that?
  62. # [09:25] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
  63. # [09:35] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
  64. # [10:05] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
  65. # [10:36] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
  66. # [11:16] * Joins: victorporof (victorporo@77FE7E86.477C3F8E.79933D60.IP)
  67. # [11:19] * Joins: zippo^ (zippo@83DFF9AD.BE77C4D.C91DDA08.IP)
  68. # [11:37] <@firebot> cbook@mozilla.com changed the Resolution on bug 921109 from --- to FIXED.
  69. # [11:37] <@firebot> cbook@mozilla.com changed the Status on bug 921109 from NEW to RESOLVED.
  70. # [11:37] <@firebot> cbook@mozilla.com changed the Target Milestone on bug 921109 from --- to mozilla27.
  71. # [11:37] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=921109 nor, --, mozilla27, surkov.alexander, RESO FIXED, Crash Report [@ mozilla::a11y::DocAccessible::UpdateTree (aContainer is null)
  72. # [11:46] * Joins: Gijs (gijs@moz-C11B0461.dsl.alice.nl)
  73. # [12:04] * Quits: victorporof (victorporo@77FE7E86.477C3F8E.79933D60.IP) (Quit: victorporof)
  74. # [12:12] * Parts: zippo^ (zippo@83DFF9AD.BE77C4D.C91DDA08.IP) (Textual IRC Client: www.textualapp.com)
  75. # [12:14] * khuey is now known as khuey|away
  76. # [12:47] * Joins: victorporof (victorporo@8AB918FF.D4B9BCD.9B1E38F4.IP)
  77. # [13:31] * Joins: marcoz (marco.zehe@moz-2FD1930A.dip0.t-ipconnect.de)
  78. # [13:31] * ChanServ sets mode: +o marcoz
  79. # [13:42] * Joins: scott_gonzalez (scott_gonz@moz-91C81A39.hrbgpa.fios.verizon.net)
  80. # [13:58] * Joins: surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP)
  81. # [13:58] * ChanServ sets mode: +o surkov
  82. # [14:05] <SteveF> surkov: hi I have done some more work on the dialog issue
  83. # [14:06] <@surkov> SteveF: all in the bug?
  84. # [14:07] <SteveF> surkov: see https://code.google.com/p/chromium/issues/detail?id=264959#c10 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=23350#c9
  85. # [14:07] <@surkov> ok
  86. # [14:07] <SteveF> surkov: in process have added mapping for inert in AAPI spec http://rawgithub.com/w3c/html-api-map/master/index.html#att-inert
  87. # [14:08] <SteveF> surkov: this proposed soluton removes need for aria-hidden stuff
  88. # [14:08] <@surkov> I see
  89. # [14:09] <@surkov> I'm curious though if aria-disabled is a good description of inert
  90. # [14:09] <@surkov> like does it make sense to distinguish disabled control under inert area
  91. # [14:10] <SteveF> surkov: no i don't think it is, thats why i have proposed that inert not mapped to aria-disabled - for a start because aria-disabled only effects controls
  92. # [14:11] <@surkov> right, anyway it doesn't necessary need to map HTML to ARIA, right?
  93. # [14:11] <SteveF> surkov: if the user can get to the control and its disabled then yes, otherwise use won't know why the control doesn't work
  94. # [14:12] <SteveF> surkov: right, aria is a useful shorthand in some circumstances where it makes ssnse
  95. # [14:12] <@surkov> btw, do IE propagate unavailable state to all accessible objects?
  96. # [14:13] <SteveF> surkov: as far as I can tell so far, no
  97. # [14:13] <@surkov> only element having inert attribute?
  98. # [14:14] <SteveF> surkov: don't think IE supports inert, nor does FF as far as i know
  99. # [14:15] <@surkov> SteveF: anyway it'd be good if we got some feedback from IA2 and ATK groups
  100. # [14:15] <SteveF> surkov: yes
  101. # [14:15] <@surkov> right, I didn't find a bug about inert
  102. # [14:15] <@surkov> would you like to send emails?
  103. # [14:23] * Quits: Gijs (gijs@moz-C11B0461.dsl.alice.nl) (Ping timeout)
  104. # [14:24] * Joins: Gijs (gijs@moz-C11B0461.dsl.alice.nl)
  105. # [14:31] <SteveF> surkov: emails to?
  106. # [14:31] <@surkov> SteveF: to groups
  107. # [14:32] <SteveF> surkov: i am not on those lists
  108. # [14:32] <@surkov> ok, I can do that
  109. # [14:47] <SteveF> surkov: thanks can you cc me?
  110. # [14:47] * khuey|away is now known as khuey
  111. # [14:53] <@surkov> sure
  112. # [15:18] <@surkov> SteveF: I don't understand phrase "An entire Document can be marked as blocked by a modal dialog subject. While a Document is so marked, every node that is in the Document, with the exception of the subject element, its ancestors, and its descendants, must be marked inert. "
  113. # [15:19] <@surkov> which ancestor and descendants?
  114. # [15:19] <@surkov> of dialog element?
  115. # [15:22] <SteveF> surkov: the subject is the dialog element
  116. # [15:22] <@surkov> SteveF: and ancestors and descendants of dialog element?
  117. # [15:24] <SteveF> surkov: that bit i took from http://www.w3.org/html/wg/drafts/html/master/editing.html#blocked-by-a-modal-dialog, unsure about whether ancestors of the dialog should be included
  118. # [15:25] <@surkov> yep, that sounds crazy: if dialog is in the middle of the document then no on element of the document should be marked inert if you follow this wording
  119. # [15:25] <@surkov> I checked w3c and whatwg have same wording
  120. # [15:35] * khuey is now known as khuey|away
  121. # [15:42] * Joins: peteb-away (ptbrunet@moz-B51E1692.austin.res.rr.com)
  122. # [15:43] * Quits: @marcoz (marco.zehe@moz-2FD1930A.dip0.t-ipconnect.de) (Quit: Leaving.)
  123. # [15:43] <SteveF> surkov: seems that way
  124. # [15:43] <@surkov> ok, should I file bugs or?
  125. # [15:44] <@surkov> SteveF: if I want the change then should I file bugs against w3c and whatwg both? How things work?
  126. # [15:45] <SteveF> surkov: for that file against the whatwg, we take most of whatwg chnages into w3c doc, its only of we disagree that we don't :-)
  127. # [15:45] <@surkov> SteveF: ok, I see, how can I do this?
  128. # [15:45] <@surkov> a link if you have
  129. # [15:46] * Joins: neilio (neilio@moz-C38AD494.macowner.com)
  130. # [15:47] <SteveF> surkov: actually file on the w3c spec and I will clone to whatwg https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=&product=HTML%20WG&component=HTML5%20spec
  131. # [15:47] <SteveF> that way I can track it
  132. # [15:48] <SteveF> surkov: make sense?
  133. # [15:48] <@surkov> ok
  134. # [15:48] <@surkov> htx
  135. # [15:51] <SteveF> surkov: FYI the chrome implementation does mark all subtree elements (not textnodes), apart from the dialog, as unavailable, but only works internittently at moment, and also appears to be issue that the tree does not refresh to remove unavailable state when the dialog is closed...
  136. # [15:52] <SteveF> surkov: when it works NVDA announces unavailable for each element outside dialog (voiceover says dimmed)
  137. # [15:52] <@surkov> I see
  138. # [15:53] <@surkov> so you can traverse them
  139. # [15:53] <@surkov> by defualt
  140. # [15:53] <@surkov> then probably unavailable is not really right
  141. # [15:53] <SteveF> yes
  142. # [15:53] <SteveF> but was is a state that can be set that stops traversal?
  143. # [15:54] <SteveF> my thinking is that the acc tree is marked with unavailable stuff which AT could hide from user
  144. # [15:55] <SteveF> otheriwse we are back to aria-hidden...
  145. # [15:58] * Quits: @surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP) (Ping timeout)
  146. # [15:59] * Joins: surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP)
  147. # [15:59] * ChanServ sets mode: +o surkov
  148. # [16:04] * Tomcat|sheriffduty is now known as Tomcat
  149. # [16:04] * Tomcat is now known as Tomcat|afk
  150. # [16:12] * Quits: icaaq (Adium@moz-2EB07EA7.cust.bredbandsbolaget.se) (Ping timeout)
  151. # [16:13] * Joins: icaaq (Adium@moz-2EB07EA7.cust.bredbandsbolaget.se)
  152. # [16:15] <@surkov> SteveF: aria-hidden probably is a good option, but probably we should have something new
  153. # [16:16] <@surkov> let's get some ia2/atk guys thinking
  154. # [16:16] <SteveF> surkov:ok :-)
  155. # [16:18] <@firebot> surkov.alexander@gmail.com granted in-testsuite on bug 466481.
  156. # [16:18] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=466481 nor, --, ---, surkov.alexander, NEW, Arabic and Hebrew characters bounds are incorrect in a11y APIs
  157. # [16:23] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  158. # [16:42] <@tbsaunde> surkov: so what in DocAccessible::cacheChildren() prevents us from caching the body?
  159. # [16:43] <@surkov> tbsaunde: just body element is accessible
  160. # [16:44] <@surkov> GetOrCreateAccesible return null for it
  161. # [16:44] <@surkov> afaik
  162. # [16:44] <@surkov> until it's focusable
  163. # [16:45] <@surkov> SteveF: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23381
  164. # [16:45] <@tbsaunde> surkov: so, maybe we should just pull that logice out of GetOrCreateAccessible into IsAccessibleChild on document?
  165. # [16:46] <@surkov> dunno, but it's different issue?
  166. # [16:46] <@surkov> (I don't remember why it's not accessible)
  167. # [16:46] <@surkov> i.e. what prevents it from being accessible
  168. # [16:46] <@tbsaunde> surkov: huh?
  169. # [16:47] <@surkov> I meant I don't recall why body element doesn't have an accessible
  170. # [16:47] <@surkov> what if statement in GetOrCreateAccessible makes us to reutnr null for it
  171. # [16:47] <SteveF> surkov: thanks cloned
  172. # [16:47] <@surkov> cool, thansk
  173. # [16:50] <@tbsaunde> surkov: I'd assume the one at line 1034, but I'm not sure why that wouldn't work for case of two bodies
  174. # [16:51] <@surkov> right, just no accessible type associated with its frame
  175. # [16:52] <@tbsaunde> surkov: huh?
  176. # [16:53] <@surkov> each frame has associated accessible type (AccType)
  177. # [16:53] <@surkov> body frame doesn't have it
  178. # [16:53] <@surkov> so we GetAccessibeleByFrame returns null for it
  179. # [16:53] <@surkov> then if it's not focusable then we skip it (event if it has role attribute)
  180. # [16:56] <@tbsaunde> surkov: I don't see how that if can ever be true if content->Tag() == nsGkAtoms::body which it clearly must be for body element
  181. # [16:57] <@surkov> tbsaunde: that's right, this part is fallback part to create a generic accessible
  182. # [16:58] <@tbsaunde> sure, but that's not my question
  183. # [16:58] <@tbsaunde> I'm trying to figure out why we do get body in this case, and obviously this if isn't at fault
  184. # [17:07] * Quits: cabanier (cabanier@moz-F663EC4A.hfc.comcastbusiness.net) (Quit: Leaving.)
  185. # [17:29] <SteveF> surkov: filed bug to implement inert https://bugzilla.mozilla.org/show_bug.cgi?id=921504 should i also file one on the acc implementation?
  186. # [17:29] <@firebot> Bug 921504 nor, --, ---, nobody, NEW, implement the html5 inert attribute
  187. # [17:29] <@surkov> SteveF: thank you, let's wait when we get some progress on inert implementation (probably assigns will take care about a11y same time)
  188. # [17:30] <SteveF> surkov: cool
  189. # [17:30] <@surkov> tbsaunde: so do you say body is accessible in that case, correct?
  190. # [17:31] <@surkov> can you put a break point for body element is see why it gets an accessible?
  191. # [17:32] <@tbsaunde> surkov: old body get nsBlockFrame not special body frame so AccessibleType on it is eHyperTextType and so it gets accessible
  192. # [17:32] <@surkov> ah, is it for every document or is it specific to this case?
  193. # [17:32] <@surkov> (I'm curious how does it happen that mochitest doesn't cover this)
  194. # [17:33] <@tbsaunde> surkov: I'd guess that since its not primary body layout treats it specially
  195. # [17:33] <@surkov> ah
  196. # [17:34] <@surkov> that should be right
  197. # [17:34] <@surkov> after new body is inserted, new body is body, old body is just another element
  198. # [17:34] <@surkov> correct?
  199. # [17:34] <@tbsaunde> I think so
  200. # [17:35] <SteveF> surkov: thanks for cc!
  201. # [17:36] <@surkov> yep, I'll copy it to ATK guys
  202. # [17:36] <@tbsaunde> surkov: and nsBlockFrame::AccessibleType() has really slow check for this case
  203. # [17:37] <@tbsaunde> surkov: so, does adding DocAccessible::AcceptableChild() that returns false for body elements make sense
  204. # [17:37] <@surkov> I see
  205. # [17:38] <@surkov> for all body elements?
  206. # [17:38] <@surkov> one is true body, another one is not :)
  207. # [17:38] <@tbsaunde> surkov: yeah for all bodies
  208. # [17:39] <@tbsaunde> I thought you said you don't see reason for old body to be accessible
  209. # [17:39] <@surkov> that'd be possible wrong
  210. # [17:39] <@surkov> yeah, technically yes
  211. # [17:39] <@surkov> what if role attribute is on old body
  212. # [17:40] <@surkov> it won't be picked up by document accessible so it should have an accessible
  213. # [17:40] <@tbsaunde> "screw you for doing something insane"?
  214. # [17:41] <@tbsaunde> I guess I should check spec before actually saying that though :)
  215. # [17:44] <@tbsaunde> surkov: do you have other ideas on fixing this?
  216. # [17:46] <@surkov> let me think :)
  217. # [17:47] * Joins: fxa (fxa90id@moz-3DACD1A4.nvidia.com)
  218. # [18:03] <@tbsaunde> surkov: so, any interesting ideas that aren't slow?
  219. # [18:03] <@surkov> tbsaunde: sorry I didn't think yet, sometimes it makes some time to start :)
  220. # [18:05] <@tbsaunde> we could maybe make CacheChildren() recursively call itself on all the kids, but I'm not sure that won't break anything or be slow
  221. # [18:06] <@surkov> like accessible is responsible to create its subtree? how does it help?
  222. # [18:07] * Joins: cabanier (cabanier@CEB4A2B.BCADA2FD.835A5368.IP)
  223. # [18:09] <@tbsaunde> surkov: the body with accessible will cache the accessible children for its child content
  224. # [18:09] <@tbsaunde> not absolutely sure that will fix things, but it should atleast mean we don't have hanging accessibles after EnsureChildren() call
  225. # [18:09] <@surkov> I see
  226. # [18:09] <@tbsaunde> which I think will fix things
  227. # [18:10] <@surkov> I don't really like hanging accessibles
  228. # [18:12] <@surkov> so you suggest to combine DocAccessible::CacheChildrenInSubtree and Accessible::CacheChildren
  229. # [18:12] <@surkov> how does it help to not have hanging accessibles?
  230. # [18:13] <@surkov> and as far as I remember InvalidateChildren always accompanied by CacheChildren
  231. # [18:13] <@tbsaunde> surkov: well, then normal tree update stuff should handle removal of old body and then insertion of content under old body under new body
  232. # [19:05] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
  233. # [19:12] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
  234. # [19:38] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
  235. # [20:18] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
  236. # [20:22] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
  237. # [20:26] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
  238. # [20:30] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
  239. # [20:32] * Quits: fxa (fxa90id@moz-3DACD1A4.nvidia.com) (Ping timeout)
  240. # [20:34] <@firebot> trev.saunders@gmail.com requested review from bugs@pettay.fi for attachment 811273 on bug 915558.
  241. # [20:34] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=915558 cri, P1, ---, nobody, REOP, XUL UI completely broken in Windows: Tabs, menus, etc.
  242. # [20:36] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
  243. # [20:39] <@tbsaunde> surkov: any thoughts on the body thing yet?
  244. # [20:39] <@surkov> sorry, I still didn't started
  245. # [20:45] <@tbsaunde> surkov: would be nice if you did, would you take a patch to ignore all bodies for now?
  246. # [20:46] <@surkov> tbsaunde: rather not, I know that's the edge case but it's wrong way
  247. # [20:46] <@surkov> I will, I promise :)
  248. # [20:48] <@surkov> can't we run into it under other scenarios, it seems to be a common thing when element having accessible children wasn't accessible but then it got an accessible
  249. # [20:51] <@tbsaunde> yeah, I suppose that's true
  250. # [20:52] <@tbsaunde> on other case when parent of inaccessible thing isn't document we just blow up the whole sub tree right?
  251. # [20:52] <@surkov> your recursive approach should help here
  252. # [20:52] <@surkov> but it'd be good if we got rid that potentially hanging accessibles
  253. # [20:52] <@tbsaunde> surkov: well, I could try the recursive thing and see what breaks
  254. # [20:53] <@tbsaunde> I'm just worried about perf
  255. # [20:53] <@surkov> tbsaunde: can we copy that array thing, and do recursive for new elements and remove accessible from old array that is not in new array anymore?
  256. # [20:53] <@surkov> tbsaunde: shouldn't it be the same? because CacheChildreninSubtree also recursive?
  257. # [20:54] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
  258. # [20:54] <@surkov> basically you just replace CacheChildrenInSubtree by CacheChildren
  259. # [20:54] <@tbsaunde> surkov: but we don't always call CacheChildrenInSubtree
  260. # [20:54] <@tbsaunde> what array thing
  261. # [20:54] <@surkov> or you can make UpdateChildren smart instead
  262. # [20:55] <@surkov> so you copy existing children and then
  263. # [20:55] <@surkov> 1) if new child is in old array then do nothing (not recursive walk)
  264. # [20:55] <@surkov> 2) if new child is not an array then just add it
  265. # [20:55] <@surkov> 3) if no new child of old array elm then shutdown old array element
  266. # [20:56] <@surkov> 2) just add it and do recursive walk
  267. # [20:57] <@surkov> maybe not so simple
  268. # [20:58] <@tbsaunde> yeah not really simple
  269. # [20:58] <@surkov> basically the idea is when we do invalidateCHildren then make sure that every child from that list is connected to something, otherwise destroy it. If we got something new then create its children recuirsively
  270. # [20:59] <@tbsaunde> hrm, I wonder why DocAccessible.cpp:1852 isn't doing what we need
  271. # [21:01] <@surkov> before UpdateTree() step for inserted new body you've got hanging div element accessible under old body accessible
  272. # [21:02] <@surkov> so what should it do?
  273. # [21:02] <@surkov> it just process that body, looks through its children for accessibles and that's all
  274. # [21:02] <@surkov> that div element is not touched
  275. # [21:02] <@surkov> if I get it right
  276. # [21:03] * Joins: fxa (fxa90id@moz-3DACD1A4.nvidia.com)
  277. # [21:05] <@tbsaunde> surkov: no, CacheChildrenInsubtree() calls aRoot->EnsureChildren() so it should walk through content looking for accessibles it should make children
  278. # [21:13] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
  279. # [21:16] <@surkov> yep, strange, debugging should help :)
  280. # [21:19] <@tbsaunde> yeah, running gdb again
  281. # [21:23] <@surkov> yep, you are master of tough things :)
  282. # [21:23] <@surkov> like a nutcracker :)
  283. # [21:32] <@tbsaunde> surkov: oh, the reason that call to CacheChildrenInSubtree() doesn't save us is that UpdateTree() is called with aChildNode being the new body not the old and the new one doesn't have any kids
  284. # [21:33] <@surkov> tbsaunde: so we don't update children of document accessible?
  285. # [21:34] <@tbsaunde> surkov: no, look at ProcessContentInserted(), it calls doc->UpdateChildren() then UpdateTree(doc, newbody, true);
  286. # [21:35] <@surkov> I see
  287. # [21:46] * Quits: fxa (fxa90id@moz-3DACD1A4.nvidia.com) (Ping timeout)
  288. # [21:47] <@tbsaunde> surkov: how do you feel about http://paste.debian.net/46845/ ?
  289. # [21:48] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
  290. # [21:48] <@surkov> tbsaunde: not very happy 1) we keep those accessible hanging until insertion 2) It releases InvalidateChildren from UpdateChildren cell
  291. # [21:49] <@surkov> that InvalidateChldren is not robust at all, I'd like to get rid it
  292. # [21:50] <@tbsaunde> surkov: wrapping in it another function does really help with that though
  293. # [21:51] <@surkov> like UpdatedChildrenInSubtree() ? :)
  294. # [21:51] <@tbsaunde> surkov: what do you men keep hanging? they hang in the same way things usually hang with INvalidateChildren
  295. # [21:51] <@surkov> that's right and that's why I say I don't like InvalidateChildren
  296. # [21:51] <@tbsaunde> s/sdoesdoesn't/
  297. # [21:51] <@tbsaunde> err, s/does/doesn't/
  298. # [21:52] <@tbsaunde> I want to get rid of it too, but making it slightly more explicit doesn't hurt that and arguably making it more explicit where its called can help us remove some calls
  299. # [21:54] <@surkov> it's like gin, safer to keep in the buttle
  300. # [21:54] <@surkov> bottle
  301. # [21:54] <@tbsaunde> the bottle is just an ilussion
  302. # [21:55] <@surkov> wouldn't you want to make the tree correct on UpdateChildren call instead?
  303. # [21:57] <@surkov> and your patch would make an extra work by traversing the created tree, right?
  304. # [21:57] <@tbsaunde> well, the only other caller is in ProcessINvalidationList() which may not need InvalidateChildren() and also I'm not sure needs the recurssion
  305. # [21:57] <@surkov> whenever UpdateChildren is called we are in danger of hanging kids
  306. # [21:58] <@tbsaunde> it would be more work than the incorrect thing we do today, but I'm not sure how to make it faster without really rewriting things
  307. # [21:58] <@surkov> get some time to invent something?
  308. # [21:59] <@surkov> I'd be much more happier if we had UpdateChildren working correct
  309. # [21:59] <@tbsaunde> I'd be happier if we removed it :)
  310. # [21:59] <@surkov> that possibly wouldn't be huge rewrite but something smart is needed
  311. # [22:00] <@tbsaunde> which probably isn't hard, I think ProcessInvalidationList() can just call CachChildrenInSubtree() and then its dead
  312. # [22:00] <@tbsaunde> but I'd rather do that part later
  313. # [22:04] <@surkov> tbsaunde: well, if you want to have a quick fix for this specific bug then if you wrap that call by some inline function (to not reveal InvalidateChildren outside more) then it should be ok
  314. # [22:05] <@surkov> though that must be slower
  315. # [22:05] <@surkov> probably not mcuh
  316. # [22:05] <@tbsaunde> than what have yes, but anything correct must be slower than what we do today
  317. # [22:05] <@surkov> but then we don't really need CacheChildrenInSubtree in UpdateTreeInternal
  318. # [22:06] <@tbsaunde> and I'd rather fix things incrementally
  319. # [22:06] <@surkov> yeah being correct might be not fast :)
  320. # [22:08] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
  321. # [22:09] * Quits: cabanier (cabanier@CEB4A2B.BCADA2FD.835A5368.IP) (Quit: Leaving.)
  322. # [22:09] * Joins: cabanier (cabanier@CEB4A2B.BCADA2FD.835A5368.IP)
  323. # [22:11] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
  324. # [22:11] * Quits: cabanier (cabanier@CEB4A2B.BCADA2FD.835A5368.IP) (Quit: Leaving.)
  325. # [22:24] <@tbsaunde> surkov: can you think of how ProcessInvalidationList() might need to call InvalidateChildren()
  326. # [22:25] <@surkov> tbsaunde: because it's running after we created the accessible tree, so it won't accept new children until you invalidate it
  327. # [22:30] <@tbsaunde> surkov: why won't it accept new hcildren?
  328. # [22:31] <@surkov> tbsaunde: children are accepted on CacheChildren if children weren't initialized, so when we put nodes into invalidation list then we create the tree, so when we process that list then all children are cached
  329. # [22:33] <@tbsaunde> oh, just calling CacheChildren() doesn't work because it will cache all the children some of them again bleh
  330. # [22:33] <@tbsaunde> I guess I should resserect that think to make CacheChildren() incremental
  331. # [22:38] <@surkov> ok, heading home, will be back in one hour
  332. # [22:39] * Quits: @surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP) (Quit: surkov)
  333. # [22:53] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
  334. # [22:55] * Parts: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  335. # [23:02] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
  336. # [23:08] * Quits: icaaq (Adium@moz-2EB07EA7.cust.bredbandsbolaget.se) (Quit: Leaving.)
  337. # [23:23] * Joins: cabanier (cabanier@6575908F.3778D849.1D6E592A.IP)
  338. # [23:49] * Joins: fxa (fxa90id@moz-3DACD1A4.nvidia.com)
  339. # Session Close: Sat Sep 28 00:00:00 2013

The end :)