mozilla :: #accessibility

9 Jan 2017
07:38MarcoZHi there! :-) Back. :-)
07:38MarcoZJamie: Ping?
07:39Jamiemarcoz: supervising child in bath right now... but can probably answer a simple question. :)
07:41MarcoZJamie: OK, are you seeing a massive increase in focus losses and focus landings on Unknown accessibles starting in the January 4, 2017 build and newer? I hadn't seen this before that build, but am seeing it since then, and it renders Nightly literally unuseable. And I want to sanity-check if it's just me or if this is widespread.
07:41MarcoZJamie: I basically only need to arrow through Gmail's inbox a few times to start seeing this, but it's not confined to Gmail. And it seems to be with both E10S off and on.
07:44Jamiemarcoz: I haven't yet, but it's extremely likely that my nightly is out of date; I don't let it auto-update. If you wouldn't mind shooting me an email reminder, I 'llupdate and verify. I assume you're thinking a Firefox update, not NVDA?
07:44Jamiemarcoz: oddly, this sounds like the 32 bit positive id problem.
07:45JamieBut I think that's probably coincidental; don't see how that could occur now
07:45Jamiemarcoz: Also, if you could include NVDA dev info for one of these unknowns, that might be useful
07:48MarcoZJamie: Correction: It happens much much more with E10s Off than On. On works better in this regard. And I think I'm on the 64 bit version. I'll send an e-mail.
07:56MarcoZJamie: E-Mail sent.
08:36MarcoZJamie: The regression window is wrong, haven't found the right one yet, but the problem actually goes further back for me than the January 4, 2017 build. So my first concerns is to know whether you're seeing this at all, too, or if it's something whacky on my system.
10:31firebotNew Core - Disability Access APIs bug 1329616 filed by mzehe@mozilla.com.
10:31firebothttps://bugzil.la/1329616 NEW, nobody@mozilla.org Massive increase of focus loss and Unknown Accessibles problems with E10S turned off starting in 201
10:32MarcoZJamie: Filed bug 1329616, found the exact regression range.
14:04firebotNew Core - Disability Access APIs bug 1329644 filed by mozillamarcia.knous@gmail.com.
14:04firebothttps://bugzil.la/1329644 NEW, nobody@mozilla.org Crash in mozilla::a11y::DocAccessibleParent::CheckTopDoc
14:13GijsMarcoZ: did the container tabs get renamed to "Environmental" tabs?
14:14GijsLooks like no, maybe you're using German Nightly? :)
14:14GijsMarcoZ: anyway, thanks for the clear bug :)
14:19MarcoZGijs: Ah, thanks, Container tabs was the word I was missing! In German, which is the default I'm using, the word for environment is being used. Feel free to adjust the bug summary. :-)
14:21GijsMarcoZ: done :)
14:44MarcoZWondering if I'll ever see the day where at Mozilla, nobody will ever say to me again "We haven't allocated time for those -- although it's been on my list."
14:44MarcoZReferring, of course, to a11y UI bugs.
15:43davidbthe battle is infinite
17:16firebotNew Core - Disability Access APIs bug 1329697 filed by yzenevich@mozilla.com.
17:16firebothttps://bugzil.la/1329697 NEW, nobody@mozilla.org Assertion failure: found, at c:/gecko-dev/ipc/mscom/Interceptor.cpp:119
19:57tbsaundeyzen: oh aklotz was mentioning the other day after you left you need to register the typelib in the parent process as well as the child to get QI to work
19:58yzentbsaunde ah i see, is that similar to how accessible.tlb is registered both in Platform.cpp and PlatformChild
19:58yzen?
19:59yzeni guess it is
20:02tbsaundeI guess so
20:08yzentbsaunde thanks
22:33tbsaundesmaug: ping
22:34smaugtbsaunde: pong
22:34tbsaundesmaug: so some fun with tab child shutdown
22:35tbsaundewe can call DocAccessible::Shutdown() from TabChild::RecvDestroy()
22:35tbsaundewhich sends a shutdown message to the parent doc accessible actor
22:36tbsaundebut that message can not happen until after the runnable posted from TabChild::RecvDestroy() runs
22:36tbsaundein which case we can send messages from the parent to the child doc accessible actor which is nolonger around
22:39tbsaundedoes it make sense to just "mostly" shutdown the doc accessible parent actor before we send the destroy message to the tab child?
22:39smaugwhy "but that message can not happen until after the runnable posted from TabChild::RecvDestroy() runs" ?
22:39smaugI was just going to suggest that
22:39tbsaundesmaug: I mean its possible it can not happen
22:40tbsaundeok if that seems reasonable I'll just go ahead with it
22:40smaugI was going to suggest that TabParent tells to DocA11yParent that it is about to be shutdown
22:40smaugyeah
22:40smaugI wonder if we have similar issues with other protocols managed by PBrowser
22:42tbsaundesmaug: maybe, though PDocAccessible has a similar business where child sends shutdown message to parent, and then parent sends __delete__ back
22:42tbsaundethough hrm I guess even sending __delete__ from the child wouldn't fix this
10 Jan 2017
No messages
   
Last message: 76 days and 14 hours ago