[Moonlight-list] [PATCH] Removal of MOON_A11Y_INTERNAL_HACK

Sebastien Pouliot sebastien.pouliot at gmail.com
Mon Nov 30 14:43:53 EST 2009


On Mon, 2009-11-30 at 19:08 -0500, "Andrés G. Aragoneses" wrote:
> To summarize, the requested revisions to backport are:
> 
> * r146790+r146791
> * r147098+r147107
> * r147111

r147115 will be needed too, otherwise the bots will fail (wrong smcs
used, loading old mscorlib.dll...)

Sebastien

> Thanks.
> 
> 
> Sebastien Pouliot escribió:
> > 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
> > 
> > _______________________________________________
> > Moonlight-list mailing list
> > Moonlight-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/moonlight-list
> 
> _______________________________________________
> Moonlight-list mailing list
> Moonlight-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/moonlight-list




More information about the Moonlight-list mailing list