[Moonlight-list] [PATCH] Removal of MOON_A11Y_INTERNAL_HACK

Sebastien Pouliot sebastien.pouliot at gmail.com
Mon Nov 30 08:29:45 EST 2009


Hello Andrés,

On Mon, 2009-11-30 at 13:56 -0500, "Andrés G. Aragoneses" wrote:
> 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?

Yes, crashes occurring in platform(managed)/plugin(unmanaged) code can
lead to exploits driven by application(untrusted/managed) code. As such
you cannot compare MoonAtkBridge to what is provided for MWF.

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

Heh, that's exactly my point below :)

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

^^^ I now wonder even more ;-)

> > 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 ;-)
> 
> What do you mean? It's working for me with r146453 and my patches.
> Should I wait to commit until you fix that bug? 

No. Update to moon HEAD and if this works (all the build + moon-unit
tests for you locally) then it's my own bug, so please commit. I'll
check the bot results and fix my bug.

Thanks,
Sebastien



More information about the Moonlight-list mailing list