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

Options:

  1. # Session Start: Sun Oct 28 00:00:00 2012
  2. # Session Ident: #accessibility
  3. # [00:31] * Quits: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se) (Quit: Leaving.)
  4. # [01:29] * khuey is now known as khuey|away
  5. # [02:15] * Joins: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com)
  6. # [02:42] * Joins: surkov (surkov@D08E2EFF.E35E3D12.E17943EE.IP)
  7. # [02:42] * ChanServ sets mode: +o surkov
  8. # [03:46] <@tbsaunde> surkov: hey
  9. # [03:46] <@surkov> hello, tbsaunde
  10. # [03:57] <@tbsaunde> how goes?
  11. # [05:19] * Quits: peteb-away (ptbrunet@moz-E9B02845.austin.res.rr.com) (Client exited)
  12. # [05:29] <@firebot> ryanvm@gmail.com changed the Resolution on bug 782547 from FIXED to ---.
  13. # [05:29] <@firebot> ryanvm@gmail.com changed the Status on bug 782547 from RESOLVED to REOPENED.
  14. # [05:29] <@firebot> ryanvm@gmail.com changed the Target Milestone on bug 782547 from mozilla19 to ---.
  15. # [05:29] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=782547 nor, --, ---, enndeakin, REOP, Accessible focus not fired after dismissing modal OS dialogs (e.g. file chooser and print dialogs)
  16. # [06:52] * Quits: @surkov (surkov@D08E2EFF.E35E3D12.E17943EE.IP) (Quit: surkov)
  17. # [07:09] * Joins: ehsan (ehsan@moz-C48D29C4.cable.teksavvy.com)
  18. # [08:25] * Joins: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP)
  19. # [08:34] * Quits: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP) (Ping timeout)
  20. # [08:34] * Joins: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP)
  21. # [08:58] * Quits: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP) (Ping timeout)
  22. # [09:05] * Joins: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se)
  23. # [09:35] * Joins: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP)
  24. # [09:41] * Quits: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP) (Connection reset by peer)
  25. # [11:11] * Joins: Stevef (chatzilla@moz-CD0F47B5.cable.virginmedia.com)
  26. # [11:58] * Quits: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se) (Quit: Leaving.)
  27. # [12:54] * Joins: icaaq (Adium@475AF70D.7DCD925.CE255B90.IP)
  28. # [13:36] * Quits: icaaq (Adium@475AF70D.7DCD925.CE255B90.IP) (Quit: Leaving.)
  29. # [13:43] * Quits: Stevef (chatzilla@moz-CD0F47B5.cable.virginmedia.com) (Ping timeout)
  30. # [13:44] * Joins: icaaq (Adium@475AF70D.7DCD925.CE255B90.IP)
  31. # [13:53] * Joins: Stevef (chatzilla@moz-CD0F47B5.cable.virginmedia.com)
  32. # [13:55] * Quits: icaaq (Adium@475AF70D.7DCD925.CE255B90.IP) (Quit: Leaving.)
  33. # [13:58] * Joins: icaaq (Adium@moz-8CEEA340.cust.telenor.se)
  34. # [14:04] * Quits: icaaq (Adium@moz-8CEEA340.cust.telenor.se) (Connection reset by peer)
  35. # [14:06] * Quits: ehsan (ehsan@moz-C48D29C4.cable.teksavvy.com) (Input/output error)
  36. # [14:18] * Joins: surkov (surkov@D08E2EFF.E35E3D12.E17943EE.IP)
  37. # [14:18] * ChanServ sets mode: +o surkov
  38. # [14:19] <@firebot> surkov.alexander@gmail.com changed the Assignee on bug 786553 from nobody@mozilla.org to francesco.infante@aol.com.
  39. # [14:19] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=786553 nor, --, ---, francesco.infante, NEW, aria-relevant should be mapped to object attributes
  40. # [14:44] <@tbsaunde> surkov: so, what's up with bug 768243? does the patch still seem crazy or something?
  41. # [14:44] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=768243 is not accessible
  42. # [14:45] <@surkov> tbsaunde: it seems hacky
  43. # [14:45] <@surkov> like a workaround
  44. # [14:46] <@tbsaunde> surkov: hm, why?
  45. # [14:46] <@tbsaunde> it used to be cacheChildren always built up full children set assuming there were no existing kids
  46. # [14:46] <@firebot> surkov.alexander@gmail.com requested review from trev.saunders@gmail .com for attachment 675947 on bug 612830.
  47. # [14:46] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=612830 nor, --, ---, surkov.alexander, ASSI, make HTML document accessible work even when there's no body
  48. # [14:47] <@tbsaunde> now cacheChildren() can be called to make sure accessible has all the children it should have
  49. # [14:48] <@tbsaunde> I wouldn't mind a nicer way to figure out what needs to be added to the tree, but I think its better than what we did before
  50. # [14:48] <@surkov> in general when something wrong happens that I don't understand then I can't say how good the fix is
  51. # [14:49] <@surkov> so we have something wrong with children caching
  52. # [14:49] <@surkov> and instead of invalidation you just add to cache missed things
  53. # [14:49] <@surkov> it doesn't seem safe since I recall we were needed that InvalidateChildren in some cases
  54. # [14:50] <@tbsaunde> surkov: I'd say the problem is more with InvalidateChildren() than children caching
  55. # [14:50] <@surkov> for example, how we can guarantee that we don't add one child twice if it's index was chagned
  56. # [14:51] <@surkov> maybe I should answer in the bug
  57. # [14:52] <@surkov> to state my concern clearer
  58. # [14:52] <@tbsaunde> surkov: I'm thinking about how we preventing adding something again, but I feel like it either should work already or we can make it work
  59. # [14:53] <@tbsaunde> but I need to understand the argument so I can explain it
  60. # [14:57] <@tbsaunde> surkov: can you explain how you think you could get a child added twice?
  61. # [14:59] <@tbsaunde> I can see it happening if something has already run off the rails, but I feel like so long as you stay on the rails you keep on them
  62. # [14:59] <@surkov> tbsaunde: I just don't trust cache missed children approach, I don't have idea what exactly happens there so I assume all scenarios possible
  63. # [15:00] <@tbsaunde> surkov: I can sort of understand that
  64. # [15:02] <@tbsaunde> surkov: on the other hand what we do right now doesn't work iether so
  65. # [15:02] <@surkov> true
  66. # [15:03] <@surkov> but I would't avoid to trade bad for worse
  67. # [15:03] <@surkov> wouldn't -> would
  68. # [15:03] <@surkov> tbsaunde: is there a chance to debug and understand where exactly we get broken?
  69. # [15:03] <@tbsaunde> surkov: sure, but I'd trade bad for less bad
  70. # [15:04] <@surkov> true
  71. # [15:04] <@tbsaunde> surkov: I guess
  72. # [15:05] <@tbsaunde> surkov: but really I don't see what there is too understand lets say you have <div id=foo> <div> <div> </div> </div> </div> and you cause InvaidateChildren() to be called on foo how could that not detach a subtree?
  73. # [15:06] <@surkov> InvalidateChildren is always paired by CacheChildren, no?
  74. # [15:07] <@tbsaunde> sure, but for some time the subtree was detached right
  75. # [15:07] <@surkov> it happens sync
  76. # [15:07] <@tbsaunde> true
  77. # [15:08] <@surkov> we shouldn't do anything bad between InvalidateChildren and CacheChildren
  78. # [15:08] <@surkov> but it seems we do
  79. # [15:08] <@surkov> and what we do is a question
  80. # [15:08] <@surkov> if I understand right
  81. # [15:09] <@tbsaunde> surkov: well, suppose the dom changes something like this <div id=foo> <div> <div id=bar> </div> </div> </div> then you change it to <div id=foo> <div id=bar> </div> </div>
  82. # [15:10] <@tbsaunde> I think removal notifications should probably make that a two step thing, but
  83. # [15:10] <@tbsaunde> it seems kind of dangerious to assume that
  84. # [15:11] <@surkov> how do you change DOM to get that?
  85. # [15:11] <@tbsaunde> surkov: so I actually sort of like just ensuring all children are cached and not calling InvalidateChildren() because it seems it should make bugs where we don't get notified more apparent
  86. # [15:12] <@surkov> tbsaunde: do you have failed mochitest?
  87. # [15:12] <@tbsaunde> surkov: with my patch? only that reorder event
  88. # [15:12] <@surkov> tbsaunde: did you debugged it?
  89. # [15:13] <@surkov> did you checked accessible tree?
  90. # [15:13] <@tbsaunde> as a test case for bug no only the fuzzer thing which seems basically unreadable
  91. # [15:13] <@tbsaunde> not yet because you seemed to want to
  92. # [15:13] <@tbsaunde> but I can look into it soon
  93. # [15:14] <@surkov> that'd be good
  94. # [15:15] <@tbsaunde> yeah, ok
  95. # [15:36] * Quits: @surkov (surkov@D08E2EFF.E35E3D12.E17943EE.IP) (Quit: surkov)
  96. # [15:52] * Quits: Stevef (chatzilla@moz-CD0F47B5.cable.virginmedia.com) (Ping timeout)
  97. # [16:17] * Joins: Stevef (chatzilla@moz-CD0F47B5.cable.virginmedia.com)
  98. # [17:17] * Joins: ehsan (ehsan@moz-C48D29C4.cable.teksavvy.com)
  99. # [17:23] * Quits: Stevef (chatzilla@moz-CD0F47B5.cable.virginmedia.com) (Ping timeout)
  100. # [17:45] * Joins: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP)
  101. # [17:48] * Joins: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se)
  102. # [18:37] * Quits: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se) (Quit: Leaving.)
  103. # [18:39] * Quits: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP) (Connection reset by peer)
  104. # [18:48] * Joins: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP)
  105. # [18:50] * Quits: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP) (Connection reset by peer)
  106. # [18:50] * Joins: victor (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP)
  107. # [19:07] * Joins: margle (margle@moz-FA382099.dsl.mweb.co.za)
  108. # [19:31] * Joins: Stevef (chatzilla@moz-CD0F47B5.cable.virginmedia.com)
  109. # [19:44] * Joins: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se)
  110. # [19:55] * Quits: margle (margle@moz-FA382099.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  111. # [19:58] * Joins: margle (margle@moz-FA382099.dsl.mweb.co.za)
  112. # [20:24] * Joins: habber (habber@moz-4CC5106C.nyc.res.rr.com)
  113. # [20:30] * Quits: ehsan (ehsan@moz-C48D29C4.cable.teksavvy.com) (Connection reset by peer)
  114. # [20:40] * Quits: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se) (Quit: Leaving.)
  115. # [20:46] * Quits: Stevef (chatzilla@moz-CD0F47B5.cable.virginmedia.com) (Ping timeout)
  116. # [21:26] * Joins: ehsan (ehsan@moz-C48D29C4.cable.teksavvy.com)
  117. # [21:33] * Quits: habber (habber@moz-4CC5106C.nyc.res.rr.com) (Quit: habber)
  118. # [21:49] * Joins: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se)
  119. # [21:49] * Quits: margle (margle@moz-FA382099.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  120. # [21:52] * Joins: margle (margle@moz-FA382099.dsl.mweb.co.za)
  121. # [22:17] * Quits: margle (margle@moz-FA382099.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  122. # [22:20] * Joins: margle (margle@moz-FA382099.dsl.mweb.co.za)
  123. # [22:22] * Quits: icaaq (Adium@moz-80D0ACBE.cust.bredbandsbolaget.se) (Quit: Leaving.)
  124. # [22:24] * Quits: victor (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP) (Quit: victor)
  125. # [22:32] * Quits: margle (margle@moz-FA382099.dsl.mweb.co.za) (Quit: Computer has gone to sleep.)
  126. # [22:55] * Joins: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP)
  127. # [23:03] * Quits: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP) (Ping timeout)
  128. # [23:29] * Quits: ehsan (ehsan@moz-C48D29C4.cable.teksavvy.com) (Input/output error)
  129. # [23:31] * Joins: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP)
  130. # [23:40] * Quits: victorporof (victorporo@E84D8C5F.5E620EAC.6A4F8DA2.IP) (Ping timeout)
  131. # Session Close: Mon Oct 29 00:00:00 2012

The end :)