[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:
>> Sebastien Pouliot escribió:
>>> 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
>> 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
> 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*
> 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:
>>>> 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:
>>>> -if MOON_A11Y_INTERNAL_HACK
>>>> -CSCFLAGS += -define:MOON_A11Y_INTERNAL_HACK
>>>> GMCS = MONO_PATH="../lib/moonlight:$$MONO_PATH" gmcs $(CSCFLAGS)
>>>> -lib:../lib/moonlight -d:NET_3_0
>>>> GACUTIL = gacutil /gacdir $(DESTDIR)$(prefix)/lib /root
>>> 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:
>>>> +++ class/System.Windows/Assembly/AssemblyInfo.cs (copia de
>>>> @@ -101,6 +101,4 @@
>>>> [assembly: InternalsVisibleTo ("System.Windows.Browser,
>>>> [assembly: InternalsVisibleTo ("Moonlight.Gtk,
>>>> -#if MOON_A11Y_INTERNAL_HACK
>>>> [assembly: InternalsVisibleTo ("MoonAtkBridge,
>>> 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
> *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