/irc-logs / mozilla / #accessibility / 2013-09-27 / end
Options:
- # Session Start: Fri Sep 27 00:00:00 2013
- # Session Ident: #accessibility
- # [00:11] * Quits: brambles (xymox@moz-969AAE9B.barwen.ch) (Ping timeout)
- # [00:11] * Joins: brambles (xymox@moz-969AAE9B.barwen.ch)
- # [00:12] * Quits: Gijs (gijs@moz-C11B0461.dsl.alice.nl) (Quit: sleep)
- # [00:41] * Joins: rednaks (rednaks@38827678.7B2CFADA.55FFA9B4.IP)
- # [00:46] * Quits: brambles (xymox@moz-969AAE9B.barwen.ch) (Ping timeout)
- # [00:47] * Joins: brambles (xymox@moz-969AAE9B.barwen.ch)
- # [01:02] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
- # [01:02] * ChanServ sets mode: +o surkov
- # [01:11] * Joins: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca)
- # [01:33] * Quits: victorporof (victorporo@77FE7E86.477C3F8E.79933D60.IP) (Quit: victorporof)
- # [01:36] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
- # [01:44] * Quits: rednaks (rednaks@38827678.7B2CFADA.55FFA9B4.IP) (Ping timeout)
- # [01:46] * Quits: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca) (Quit: Leaving.)
- # [01:46] * Joins: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca)
- # [01:47] * Joins: rednaks (rednaks@2525BBDB.7D9D6404.55FFA9B4.IP)
- # [01:50] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
- # [01:50] * ChanServ sets mode: +o surkov
- # [02:10] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
- # [02:24] * Quits: rednaks (rednaks@2525BBDB.7D9D6404.55FFA9B4.IP) (Quit: Téléportation !)
- # [02:33] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
- # [02:33] * ChanServ sets mode: +o surkov
- # [02:55] <@firebot> bugs@pettay.fi denied review for attachment 810779 on bug 915558.
- # [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.
- # [03:01] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
- # [03:08] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
- # [03:08] * ChanServ sets mode: +o surkov
- # [03:10] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
- # [03:46] <@firebot> ryanvm@gmail.com changed the Resolution on bug 920844 from --- to FIXED.
- # [03:46] <@firebot> ryanvm@gmail.com changed the Status on bug 920844 from NEW to RESOLVED.
- # [03:46] <@firebot> ryanvm@gmail.com changed the Target Milestone on bug 920844 from --- to mozilla27.
- # [03:46] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=920844 nor, --, mozilla27, eitan, RESO FIXED, [AccessFu] Support listbox options
- # [03:50] <@firebot> ryanvm@gmail.com changed the Resolution on bug 920547 from --- to FIXED.
- # [03:50] <@firebot> ryanvm@gmail.com changed the Status on bug 920547 from NEW to RESOLVED.
- # [03:51] <@firebot> ryanvm@gmail.com changed the Target Milestone on bug 920547 from --- to mozilla27.
- # [03:51] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=920547 nor, --, ---, surkov.alexander, NEW, create generic accessibles for mathml elements
- # [03:51] * khuey is now known as khuey|away
- # [04:07] * khuey|away is now known as khuey
- # [04:15] * Joins: surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP)
- # [04:15] * ChanServ sets mode: +o surkov
- # [04:30] * Quits: @surkov (surkov@74F7CB6C.E80E6317.6BEEAEBD.IP) (Quit: surkov)
- # [04:36] * Quits: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca) (Quit: Leaving.)
- # [04:50] * Joins: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca)
- # [04:52] * Quits: maxli (maxli@moz-A607CA26.student.cs.uwaterloo.ca) (Ping timeout)
- # [05:40] * Tomcat|afk is now known as Tomcat|sheriff
- # [06:00] * khuey is now known as khuey|away
- # [06:17] * Joins: fxa (fxa90id@moz-3DACD1A4.nvidia.com)
- # [07:08] * Quits: peteb-away (ptbrunet@moz-B51E1692.austin.res.rr.com) (Client exited)
- # [07:18] * khuey|away is now known as khuey
- # [07:20] * Joins: icaaq (Adium@moz-2EB07EA7.cust.bredbandsbolaget.se)
- # [07:21] * Quits: fxa (fxa90id@moz-3DACD1A4.nvidia.com) (Quit: Leaving)
- # [07:22] * Tomcat|sheriff is now known as Tomcat|sheriffduty
- # [08:25] * Joins: cabanier (cabanier@moz-F663EC4A.hfc.comcastbusiness.net)
- # [08:26] <cabanier> all, I'm working on adding support for hit regions in canvas 2s
- # [08:26] <cabanier> 2d
- # [08:26] <cabanier> sorry, focus rings
- # [08:27] <cabanier> I've wired up all the code to make DrawCustomFocusRing and DrawSystemFocusRing work
- # [08:28] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
- # [08:28] <cabanier> but I also have to tell the accessiblity part of firefox about the region that the focus ring is covering
- # [08:28] <cabanier> does anyone know how to do that?
- # [09:25] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
- # [09:35] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
- # [10:05] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
- # [10:36] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
- # [11:16] * Joins: victorporof (victorporo@77FE7E86.477C3F8E.79933D60.IP)
- # [11:19] * Joins: zippo^ (zippo@83DFF9AD.BE77C4D.C91DDA08.IP)
- # [11:37] <@firebot> cbook@mozilla.com changed the Resolution on bug 921109 from --- to FIXED.
- # [11:37] <@firebot> cbook@mozilla.com changed the Status on bug 921109 from NEW to RESOLVED.
- # [11:37] <@firebot> cbook@mozilla.com changed the Target Milestone on bug 921109 from --- to mozilla27.
- # [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)
- # [11:46] * Joins: Gijs (gijs@moz-C11B0461.dsl.alice.nl)
- # [12:04] * Quits: victorporof (victorporo@77FE7E86.477C3F8E.79933D60.IP) (Quit: victorporof)
- # [12:12] * Parts: zippo^ (zippo@83DFF9AD.BE77C4D.C91DDA08.IP) (Textual IRC Client: www.textualapp.com)
- # [12:14] * khuey is now known as khuey|away
- # [12:47] * Joins: victorporof (victorporo@8AB918FF.D4B9BCD.9B1E38F4.IP)
- # [13:31] * Joins: marcoz (marco.zehe@moz-2FD1930A.dip0.t-ipconnect.de)
- # [13:31] * ChanServ sets mode: +o marcoz
- # [13:42] * Joins: scott_gonzalez (scott_gonz@moz-91C81A39.hrbgpa.fios.verizon.net)
- # [13:58] * Joins: surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP)
- # [13:58] * ChanServ sets mode: +o surkov
- # [14:05] <SteveF> surkov: hi I have done some more work on the dialog issue
- # [14:06] <@surkov> SteveF: all in the bug?
- # [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
- # [14:07] <@surkov> ok
- # [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
- # [14:08] <SteveF> surkov: this proposed soluton removes need for aria-hidden stuff
- # [14:08] <@surkov> I see
- # [14:09] <@surkov> I'm curious though if aria-disabled is a good description of inert
- # [14:09] <@surkov> like does it make sense to distinguish disabled control under inert area
- # [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
- # [14:11] <@surkov> right, anyway it doesn't necessary need to map HTML to ARIA, right?
- # [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
- # [14:12] <SteveF> surkov: right, aria is a useful shorthand in some circumstances where it makes ssnse
- # [14:12] <@surkov> btw, do IE propagate unavailable state to all accessible objects?
- # [14:13] <SteveF> surkov: as far as I can tell so far, no
- # [14:13] <@surkov> only element having inert attribute?
- # [14:14] <SteveF> surkov: don't think IE supports inert, nor does FF as far as i know
- # [14:15] <@surkov> SteveF: anyway it'd be good if we got some feedback from IA2 and ATK groups
- # [14:15] <SteveF> surkov: yes
- # [14:15] <@surkov> right, I didn't find a bug about inert
- # [14:15] <@surkov> would you like to send emails?
- # [14:23] * Quits: Gijs (gijs@moz-C11B0461.dsl.alice.nl) (Ping timeout)
- # [14:24] * Joins: Gijs (gijs@moz-C11B0461.dsl.alice.nl)
- # [14:31] <SteveF> surkov: emails to?
- # [14:31] <@surkov> SteveF: to groups
- # [14:32] <SteveF> surkov: i am not on those lists
- # [14:32] <@surkov> ok, I can do that
- # [14:47] <SteveF> surkov: thanks can you cc me?
- # [14:47] * khuey|away is now known as khuey
- # [14:53] <@surkov> sure
- # [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. "
- # [15:19] <@surkov> which ancestor and descendants?
- # [15:19] <@surkov> of dialog element?
- # [15:22] <SteveF> surkov: the subject is the dialog element
- # [15:22] <@surkov> SteveF: and ancestors and descendants of dialog element?
- # [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
- # [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
- # [15:25] <@surkov> I checked w3c and whatwg have same wording
- # [15:35] * khuey is now known as khuey|away
- # [15:42] * Joins: peteb-away (ptbrunet@moz-B51E1692.austin.res.rr.com)
- # [15:43] * Quits: @marcoz (marco.zehe@moz-2FD1930A.dip0.t-ipconnect.de) (Quit: Leaving.)
- # [15:43] <SteveF> surkov: seems that way
- # [15:43] <@surkov> ok, should I file bugs or?
- # [15:44] <@surkov> SteveF: if I want the change then should I file bugs against w3c and whatwg both? How things work?
- # [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 :-)
- # [15:45] <@surkov> SteveF: ok, I see, how can I do this?
- # [15:45] <@surkov> a link if you have
- # [15:46] * Joins: neilio (neilio@moz-C38AD494.macowner.com)
- # [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
- # [15:47] <SteveF> that way I can track it
- # [15:48] <SteveF> surkov: make sense?
- # [15:48] <@surkov> ok
- # [15:48] <@surkov> htx
- # [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...
- # [15:52] <SteveF> surkov: when it works NVDA announces unavailable for each element outside dialog (voiceover says dimmed)
- # [15:52] <@surkov> I see
- # [15:53] <@surkov> so you can traverse them
- # [15:53] <@surkov> by defualt
- # [15:53] <@surkov> then probably unavailable is not really right
- # [15:53] <SteveF> yes
- # [15:53] <SteveF> but was is a state that can be set that stops traversal?
- # [15:54] <SteveF> my thinking is that the acc tree is marked with unavailable stuff which AT could hide from user
- # [15:55] <SteveF> otheriwse we are back to aria-hidden...
- # [15:58] * Quits: @surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP) (Ping timeout)
- # [15:59] * Joins: surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP)
- # [15:59] * ChanServ sets mode: +o surkov
- # [16:04] * Tomcat|sheriffduty is now known as Tomcat
- # [16:04] * Tomcat is now known as Tomcat|afk
- # [16:12] * Quits: icaaq (Adium@moz-2EB07EA7.cust.bredbandsbolaget.se) (Ping timeout)
- # [16:13] * Joins: icaaq (Adium@moz-2EB07EA7.cust.bredbandsbolaget.se)
- # [16:15] <@surkov> SteveF: aria-hidden probably is a good option, but probably we should have something new
- # [16:16] <@surkov> let's get some ia2/atk guys thinking
- # [16:16] <SteveF> surkov:ok :-)
- # [16:18] <@firebot> surkov.alexander@gmail.com granted in-testsuite on bug 466481.
- # [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
- # [16:23] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
- # [16:42] <@tbsaunde> surkov: so what in DocAccessible::cacheChildren() prevents us from caching the body?
- # [16:43] <@surkov> tbsaunde: just body element is accessible
- # [16:44] <@surkov> GetOrCreateAccesible return null for it
- # [16:44] <@surkov> afaik
- # [16:44] <@surkov> until it's focusable
- # [16:45] <@surkov> SteveF: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23381
- # [16:45] <@tbsaunde> surkov: so, maybe we should just pull that logice out of GetOrCreateAccessible into IsAccessibleChild on document?
- # [16:46] <@surkov> dunno, but it's different issue?
- # [16:46] <@surkov> (I don't remember why it's not accessible)
- # [16:46] <@surkov> i.e. what prevents it from being accessible
- # [16:46] <@tbsaunde> surkov: huh?
- # [16:47] <@surkov> I meant I don't recall why body element doesn't have an accessible
- # [16:47] <@surkov> what if statement in GetOrCreateAccessible makes us to reutnr null for it
- # [16:47] <SteveF> surkov: thanks cloned
- # [16:47] <@surkov> cool, thansk
- # [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
- # [16:51] <@surkov> right, just no accessible type associated with its frame
- # [16:52] <@tbsaunde> surkov: huh?
- # [16:53] <@surkov> each frame has associated accessible type (AccType)
- # [16:53] <@surkov> body frame doesn't have it
- # [16:53] <@surkov> so we GetAccessibeleByFrame returns null for it
- # [16:53] <@surkov> then if it's not focusable then we skip it (event if it has role attribute)
- # [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
- # [16:57] <@surkov> tbsaunde: that's right, this part is fallback part to create a generic accessible
- # [16:58] <@tbsaunde> sure, but that's not my question
- # [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
- # [17:07] * Quits: cabanier (cabanier@moz-F663EC4A.hfc.comcastbusiness.net) (Quit: Leaving.)
- # [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?
- # [17:29] <@firebot> Bug 921504 nor, --, ---, nobody, NEW, implement the html5 inert attribute
- # [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)
- # [17:30] <SteveF> surkov: cool
- # [17:30] <@surkov> tbsaunde: so do you say body is accessible in that case, correct?
- # [17:31] <@surkov> can you put a break point for body element is see why it gets an accessible?
- # [17:32] <@tbsaunde> surkov: old body get nsBlockFrame not special body frame so AccessibleType on it is eHyperTextType and so it gets accessible
- # [17:32] <@surkov> ah, is it for every document or is it specific to this case?
- # [17:32] <@surkov> (I'm curious how does it happen that mochitest doesn't cover this)
- # [17:33] <@tbsaunde> surkov: I'd guess that since its not primary body layout treats it specially
- # [17:33] <@surkov> ah
- # [17:34] <@surkov> that should be right
- # [17:34] <@surkov> after new body is inserted, new body is body, old body is just another element
- # [17:34] <@surkov> correct?
- # [17:34] <@tbsaunde> I think so
- # [17:35] <SteveF> surkov: thanks for cc!
- # [17:36] <@surkov> yep, I'll copy it to ATK guys
- # [17:36] <@tbsaunde> surkov: and nsBlockFrame::AccessibleType() has really slow check for this case
- # [17:37] <@tbsaunde> surkov: so, does adding DocAccessible::AcceptableChild() that returns false for body elements make sense
- # [17:37] <@surkov> I see
- # [17:38] <@surkov> for all body elements?
- # [17:38] <@surkov> one is true body, another one is not :)
- # [17:38] <@tbsaunde> surkov: yeah for all bodies
- # [17:39] <@tbsaunde> I thought you said you don't see reason for old body to be accessible
- # [17:39] <@surkov> that'd be possible wrong
- # [17:39] <@surkov> yeah, technically yes
- # [17:39] <@surkov> what if role attribute is on old body
- # [17:40] <@surkov> it won't be picked up by document accessible so it should have an accessible
- # [17:40] <@tbsaunde> "screw you for doing something insane"?
- # [17:41] <@tbsaunde> I guess I should check spec before actually saying that though :)
- # [17:44] <@tbsaunde> surkov: do you have other ideas on fixing this?
- # [17:46] <@surkov> let me think :)
- # [17:47] * Joins: fxa (fxa90id@moz-3DACD1A4.nvidia.com)
- # [18:03] <@tbsaunde> surkov: so, any interesting ideas that aren't slow?
- # [18:03] <@surkov> tbsaunde: sorry I didn't think yet, sometimes it makes some time to start :)
- # [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
- # [18:06] <@surkov> like accessible is responsible to create its subtree? how does it help?
- # [18:07] * Joins: cabanier (cabanier@CEB4A2B.BCADA2FD.835A5368.IP)
- # [18:09] <@tbsaunde> surkov: the body with accessible will cache the accessible children for its child content
- # [18:09] <@tbsaunde> not absolutely sure that will fix things, but it should atleast mean we don't have hanging accessibles after EnsureChildren() call
- # [18:09] <@surkov> I see
- # [18:09] <@tbsaunde> which I think will fix things
- # [18:10] <@surkov> I don't really like hanging accessibles
- # [18:12] <@surkov> so you suggest to combine DocAccessible::CacheChildrenInSubtree and Accessible::CacheChildren
- # [18:12] <@surkov> how does it help to not have hanging accessibles?
- # [18:13] <@surkov> and as far as I remember InvalidateChildren always accompanied by CacheChildren
- # [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
- # [19:05] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
- # [19:12] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
- # [19:38] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
- # [20:18] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
- # [20:22] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
- # [20:26] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
- # [20:30] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
- # [20:32] * Quits: fxa (fxa90id@moz-3DACD1A4.nvidia.com) (Ping timeout)
- # [20:34] <@firebot> trev.saunders@gmail.com requested review from bugs@pettay.fi for attachment 811273 on bug 915558.
- # [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.
- # [20:36] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
- # [20:39] <@tbsaunde> surkov: any thoughts on the body thing yet?
- # [20:39] <@surkov> sorry, I still didn't started
- # [20:45] <@tbsaunde> surkov: would be nice if you did, would you take a patch to ignore all bodies for now?
- # [20:46] <@surkov> tbsaunde: rather not, I know that's the edge case but it's wrong way
- # [20:46] <@surkov> I will, I promise :)
- # [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
- # [20:51] <@tbsaunde> yeah, I suppose that's true
- # [20:52] <@tbsaunde> on other case when parent of inaccessible thing isn't document we just blow up the whole sub tree right?
- # [20:52] <@surkov> your recursive approach should help here
- # [20:52] <@surkov> but it'd be good if we got rid that potentially hanging accessibles
- # [20:52] <@tbsaunde> surkov: well, I could try the recursive thing and see what breaks
- # [20:53] <@tbsaunde> I'm just worried about perf
- # [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?
- # [20:53] <@surkov> tbsaunde: shouldn't it be the same? because CacheChildreninSubtree also recursive?
- # [20:54] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
- # [20:54] <@surkov> basically you just replace CacheChildrenInSubtree by CacheChildren
- # [20:54] <@tbsaunde> surkov: but we don't always call CacheChildrenInSubtree
- # [20:54] <@tbsaunde> what array thing
- # [20:54] <@surkov> or you can make UpdateChildren smart instead
- # [20:55] <@surkov> so you copy existing children and then
- # [20:55] <@surkov> 1) if new child is in old array then do nothing (not recursive walk)
- # [20:55] <@surkov> 2) if new child is not an array then just add it
- # [20:55] <@surkov> 3) if no new child of old array elm then shutdown old array element
- # [20:56] <@surkov> 2) just add it and do recursive walk
- # [20:57] <@surkov> maybe not so simple
- # [20:58] <@tbsaunde> yeah not really simple
- # [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
- # [20:59] <@tbsaunde> hrm, I wonder why DocAccessible.cpp:1852 isn't doing what we need
- # [21:01] <@surkov> before UpdateTree() step for inserted new body you've got hanging div element accessible under old body accessible
- # [21:02] <@surkov> so what should it do?
- # [21:02] <@surkov> it just process that body, looks through its children for accessibles and that's all
- # [21:02] <@surkov> that div element is not touched
- # [21:02] <@surkov> if I get it right
- # [21:03] * Joins: fxa (fxa90id@moz-3DACD1A4.nvidia.com)
- # [21:05] <@tbsaunde> surkov: no, CacheChildrenInsubtree() calls aRoot->EnsureChildren() so it should walk through content looking for accessibles it should make children
- # [21:13] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
- # [21:16] <@surkov> yep, strange, debugging should help :)
- # [21:19] <@tbsaunde> yeah, running gdb again
- # [21:23] <@surkov> yep, you are master of tough things :)
- # [21:23] <@surkov> like a nutcracker :)
- # [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
- # [21:33] <@surkov> tbsaunde: so we don't update children of document accessible?
- # [21:34] <@tbsaunde> surkov: no, look at ProcessContentInserted(), it calls doc->UpdateChildren() then UpdateTree(doc, newbody, true);
- # [21:35] <@surkov> I see
- # [21:46] * Quits: fxa (fxa90id@moz-3DACD1A4.nvidia.com) (Ping timeout)
- # [21:47] <@tbsaunde> surkov: how do you feel about http://paste.debian.net/46845/ ?
- # [21:48] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
- # [21:48] <@surkov> tbsaunde: not very happy 1) we keep those accessible hanging until insertion 2) It releases InvalidateChildren from UpdateChildren cell
- # [21:49] <@surkov> that InvalidateChldren is not robust at all, I'd like to get rid it
- # [21:50] <@tbsaunde> surkov: wrapping in it another function does really help with that though
- # [21:51] <@surkov> like UpdatedChildrenInSubtree() ? :)
- # [21:51] <@tbsaunde> surkov: what do you men keep hanging? they hang in the same way things usually hang with INvalidateChildren
- # [21:51] <@surkov> that's right and that's why I say I don't like InvalidateChildren
- # [21:51] <@tbsaunde> s/sdoesdoesn't/
- # [21:51] <@tbsaunde> err, s/does/doesn't/
- # [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
- # [21:54] <@surkov> it's like gin, safer to keep in the buttle
- # [21:54] <@surkov> bottle
- # [21:54] <@tbsaunde> the bottle is just an ilussion
- # [21:55] <@surkov> wouldn't you want to make the tree correct on UpdateChildren call instead?
- # [21:57] <@surkov> and your patch would make an extra work by traversing the created tree, right?
- # [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
- # [21:57] <@surkov> whenever UpdateChildren is called we are in danger of hanging kids
- # [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
- # [21:58] <@surkov> get some time to invent something?
- # [21:59] <@surkov> I'd be much more happier if we had UpdateChildren working correct
- # [21:59] <@tbsaunde> I'd be happier if we removed it :)
- # [21:59] <@surkov> that possibly wouldn't be huge rewrite but something smart is needed
- # [22:00] <@tbsaunde> which probably isn't hard, I think ProcessInvalidationList() can just call CachChildrenInSubtree() and then its dead
- # [22:00] <@tbsaunde> but I'd rather do that part later
- # [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
- # [22:05] <@surkov> though that must be slower
- # [22:05] <@surkov> probably not mcuh
- # [22:05] <@tbsaunde> than what have yes, but anything correct must be slower than what we do today
- # [22:05] <@surkov> but then we don't really need CacheChildrenInSubtree in UpdateTreeInternal
- # [22:06] <@tbsaunde> and I'd rather fix things incrementally
- # [22:06] <@surkov> yeah being correct might be not fast :)
- # [22:08] * Joins: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com)
- # [22:09] * Quits: cabanier (cabanier@CEB4A2B.BCADA2FD.835A5368.IP) (Quit: Leaving.)
- # [22:09] * Joins: cabanier (cabanier@CEB4A2B.BCADA2FD.835A5368.IP)
- # [22:11] * Quits: SteveF (chatzilla@moz-3F778890.cable.virginmedia.com) (Ping timeout)
- # [22:11] * Quits: cabanier (cabanier@CEB4A2B.BCADA2FD.835A5368.IP) (Quit: Leaving.)
- # [22:24] <@tbsaunde> surkov: can you think of how ProcessInvalidationList() might need to call InvalidateChildren()
- # [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
- # [22:30] <@tbsaunde> surkov: why won't it accept new hcildren?
- # [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
- # [22:33] <@tbsaunde> oh, just calling CacheChildren() doesn't work because it will cache all the children some of them again bleh
- # [22:33] <@tbsaunde> I guess I should resserect that think to make CacheChildren() incremental
- # [22:38] <@surkov> ok, heading home, will be back in one hour
- # [22:39] * Quits: @surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP) (Quit: surkov)
- # [22:53] * Joins: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP)
- # [22:55] * Parts: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
- # [23:02] * Quits: rednaks (rednaks@2BFFE0C9.74C6FD40.360EF119.IP) (Ping timeout)
- # [23:08] * Quits: icaaq (Adium@moz-2EB07EA7.cust.bredbandsbolaget.se) (Quit: Leaving.)
- # [23:23] * Joins: cabanier (cabanier@6575908F.3778D849.1D6E592A.IP)
- # [23:49] * Joins: fxa (fxa90id@moz-3DACD1A4.nvidia.com)
- # Session Close: Sat Sep 28 00:00:00 2013
The end :)