Created attachment 573022 [details] [diff] [review] gfxPlatform.patch User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 20111104165243 Steps to reproduce: Compile external binary xpcom component linking with xul library and using Thebes api Actual results: Compilation failed because gfx/thebes/gfxPlatform.h include nsString.h which require MOZILLA_INTERNAL_API (see http://hg.mozilla.org/mozilla-central/diff/7dfa2501f151/gfx/thebes/gfxPlatform.h for change log) Expected results: Compilation should have succeeded because Thebes is defined as an exportable api for use in external components. Attached patch should make the job by including nsStringGlue.h instead of nsString.h which fallback to nsStringAPI.h if MOZILLA_INTERNAL_API is not defined
Please request a review of your patch. https://developer.mozilla.org/en/Introduction#section_9
gfxPlatform use nsString directly as arguments to method at least at two locations: http://hg.mozilla.org/mozilla-central/file/6d42793c4807/gfx/thebes/gfxPlatform.h#l202 and http://hg.mozilla.org/mozilla-central/file/6d42793c4807/gfx/thebes/gfxPlatform.h#l290 In the last one, the nsString could be easily replaced by a nsAString reference and thus preserving string api convention of using reference to abstract type. But in the first case I don't know if there could be a potential issue for passing a reference to nsTArray<nsString>. ( AFAIK the mapping of nsString between external and internal api should be preserved even in that case )
OK, I found that references to nsString in gfxPlatform were there since a long time ago before the inclusion of nsString.h, so the patch should not have any side effects on that preexistent code (note that I currently use that patch).