[Moonlight-list] [PATCH] Removal of MOON_A11Y_INTERNAL_HACK

"Andrés G. Aragoneses" knocte at gmail.com
Mon Nov 30 13:56:16 EST 2009

Sebastien Pouliot escribió:
> On Wed, 2009-11-25 at 09:58 -0500, "Andrés G. Aragoneses" wrote:
>> Hi,
>> Sebastien Pouliot escribió:
>>> Hello,
>>> The only extra thing worth mentioning is that today MoonAtkBridge works
>>> only with the XPI (i.e. it won't be considered platform code otherwise,
>>> so it just won't be able to work). Now that's likely not a big issue for
>>> most users - at least until some distro begin to ship their own
>>> packages. 
>> I think we'll work to get the non-XPI initialization at some point, but
>> it's not a priority for the first release.
>>> Except it also means that no moonlight developers will be using it "day
>>> to day", like when running most of the tests. Which in turns means that
>>> any breaking change will go unnoticed... until someone in a11y
>>> finds/report the issue. But that's a limitation I have no problem living
>>> with ;-)
>> It's a limitation that was present as well when we did the work on
>> Windows.Forms
> Yep, same limitation but a very different context. We're running
> untrusted code in the plugin so crashes in any fully-trusted code, like
> MoonAtkBrigde, is way more problematic than a (fully-trusted) MFW-based
> app is.

You mean crashes in MoonAtkBridge could open security back doors?

>>  (or are you telling me any of the people in the Mono team
>> enabled accessibility to run the tests? ;)
> Can't say for others - but I admit I never used it (not that I worked
> on, or used much, MWF myself ;-).
>> Anyway, we have a pretty competent QA team and our automated-test suites
>> are run in a continious integration system (if you need more info, ask
>> Stephen Shaw) all the time.
> I have no doubt it's tested. However I can't recall many reports that
> detected Moonlight's own, full or partial, build failures (but it's
> entirely possible I could have missed them).

We have detected them sometimes, but didn't announce in the channel
because we thought you got already buildbot infrastructure to detect
them as well.

> Now I'm pretty sure some failures have make it impossible to run a11y
> tests (generally because our own could not execute). That makes me
> wonder how long it would take to catch a moonlight bug affecting *only*
> a11y...
> But like I said "that's a limitation I have no problem living with"
>>> Some comments on the patch itself...
>>> On Tue, 2009-11-24 at 20:55 -0500, "Andrés G. Aragoneses" wrote:
>> <snip/>
>>>> Index: class/Moon.Windows.Desktop/Makefile.am
>>>> ===================================================================
>>>> --- class/Moon.Windows.Desktop/Makefile.am      (revisión: 146453)
>>>> +++ class/Moon.Windows.Desktop/Makefile.am      (copia de trabajo)
>>>> @@ -17,12 +17,6 @@
>>>>  CSCFLAGS = /codepage:65001 -d:SANITY -d:NET_1_1 -d:NET_2_0
>>>> -d:MOONLIGHT -debug+ -noconfig -r:System -r:System.Core -r:System.Xml
>>>> -d:AGCLR -unsafe
>>>> -## this hack will be dropped once we get this working:
>>>> -##
>>>> http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading
>>>> -endif
>>>> -
>>>>  GMCS = MONO_PATH="../lib/moonlight:$$MONO_PATH" gmcs $(CSCFLAGS)
>>>> -lib:../lib/moonlight -d:NET_3_0
>>>>  GACUTIL = gacutil /gacdir $(DESTDIR)$(prefix)/lib /root
>>>> $(DESTDIR)$(prefix)/lib
>>> Was that a copy/paste of another assembly ? (I don't think the variable
>>> is used inside this directory) or is A11Y meant to be supported on the
>>> desktop (without firefox) ?
>> No, we're not testing a11y for now out of the browser, so I guess the
>> inclusion of those lines in that Makefile.am was a mistake.
>>>> Index: class/System.Windows/Assembly/AssemblyInfo.cs
>>>> ===================================================================
>>>> --- class/System.Windows/Assembly/AssemblyInfo.cs       (revisión:
>>>> 146453)
>>>> +++ class/System.Windows/Assembly/AssemblyInfo.cs       (copia de
>>>> trabajo)
>>>> @@ -101,6 +101,4 @@
>>>>  [assembly: InternalsVisibleTo ("System.Windows.Browser,
>>>> PublicKey=002400000480000094000000060200000024000052534131000400000100010079159977d2d03a8e6bea7a2e74e8d1afcc93e8851974952bb480a12c9134474d04062447c37e0e68c080536fcf3c3fbe2ff9c979ce998475e506e8ce82dd5b0f350dc10e93bf2eeecf874b24770c5081dbea7447fddafa277b22de47d6ffea449674a4f9fccf84d15069089380284dbdd35f46cdff12a1bd78e4ef0065d016df")]
>>>>  [assembly: InternalsVisibleTo ("Moonlight.Gtk,
>>>> PublicKey=002400000480000094000000060200000024000052534131000400001100000005E62DA51722818A2ADC73D5CE64289260012A442031582E808F5C290EF155F10AB93441F92A7A59736D3481245ED4E0E864F5E1ACCADD217D53EE0263E6E3852FE94AB6B708984C6C69BA79F40A0896E1FFF820B7C55D4968C8F41CAE2AABC136B16B8AF83D013946CE190BC03C2A6C8DE8C0CB135ED656F46BF9A2D03E8188")]
>>>>  #endif
>>>>  [assembly: InternalsVisibleTo ("MoonAtkBridge,
>>>> PublicKey=00240000048000009400000006020000002400005253413100040000110000004bb98b1af6c1df0df8c02c380e116b7a7f0c8c827aecfccddc6e29b7c754cd608b49dfcef4df9699ad182e50f66afa4e68dabc7b6aeeec0aa4719a5f8e0aae8c193080a706adc3443a8356b1f254142034995532ac176398e12a30f6a74a119a89ac47672c9ae24d7e90de686557166e3b873cd707884431a0451d9d6f7fe795")]
>>>> -#endif
>>> Like previous. If this is for firefox *only* then it should be inside
>>> the NET_2_1 define (and not present for NET_3_0).
>> We may be interested in providing a11y in the desktop at some point, but
>> for now I'll use the NET_2_1 define.
>>>> Index: class/System.Windows/Makefile.am
>>> Great work BTW. I'm glad to see this going on the "by default" road :-)
>> Thanks! So, can the patch go in with your comments addressed?
> Yes, you can commit on HEAD when* everything builds and test fine
> Thanks,
> Sebastien
> *afaik it should not work, otherwise I have another bug to fix ;-)

What do you mean? It's working for me with r146453 and my patches.
Should I wait to commit until you fix that bug? Let's chat about this on



More information about the Moonlight-list mailing list