[Moonlight-list] [PATCH] Removal of MOON_A11Y_INTERNAL_HACK

"Andrés G. Aragoneses" knocte at gmail.com
Mon Nov 30 19:08:06 EST 2009


To summarize, the requested revisions to backport are:

* r146790+r146791
* r147098+r147107
* r147111

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



More information about the Moonlight-list mailing list