[Moonlight-list] [PATCH] Removal of MOON_A11Y_INTERNAL_HACK

Sebastien Pouliot sebastien.pouliot at gmail.com
Wed Nov 25 10:47:14 EST 2009


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.

>  (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).

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
> >> -if MOON_A11Y_INTERNAL_HACK
> >> -CSCFLAGS += -define:MOON_A11Y_INTERNAL_HACK
> >> -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
> >> -#if MOON_A11Y_INTERNAL_HACK
> >>  [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 ;-)




More information about the Moonlight-list mailing list