On 25.07.2017 02:04, Kris Maglione wrote:
The only remaining in-tree references to the XP_OS2 macros are in NSPR
and NSS, which are technically separate projects, and have their own
sets of supported platforms.
In esr52 there's a bit more:
gfx/2d/DrawTargetCairo.cpp
gfx/cairo/cairo/src/cairo-
Hi all,
recently in couple of bugs there has been requests to add Gecko specific APIs
for extensions.
It isn't clear to me why, and even less clear to me is what the plan is there.
I thought WebExtensions should work in several browsers, but the more we add
Gecko specific APIs, the less likely
In my mind at least the concept is to share the API across all browsers
where we can, but WebExtensions should not be limited to APIs that are
accepted and implemented by all browser vendors. Google extensions have
some Google app specific API that we might never implement because of
technical limi
On Tue, Jul 25, 2017 at 4:04 AM, Enrico Weigelt, metux IT consult
wrote:
> On 25.07.2017 02:04, Kris Maglione wrote:
>
>> The only remaining in-tree references to the XP_OS2 macros are in NSPR
>> and NSS, which are technically separate projects, and have their own
>> sets of supported platforms.
>
In light of using PRxx formatting macros from inttypes.h, what is the
right approach to printf size_t types (like our nsTArray::Length()) ?
Not sure if to use "%zu" directly.
Thanks.
-hb-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
h
We have a mozilla/SizePrintfMacros.h header which defines "PRIuSIZE"
for this purpose.
Cheers,
Botond
On Tue, Jul 25, 2017 at 12:43 PM, Honza Bambas wrote:
> In light of using PRxx formatting macros from inttypes.h, what is the right
> approach to printf size_t types (like our nsTArray::Length()
Thanks! OTOH, I think we no longer need it. Since VS2015 (our minimal
toolchain version on Win) supports %z modifier. Only VS2013 and down
only defines %I.
-hb-
On 7/25/17 7:03 PM, Botond Ballo wrote:
We have a mozilla/SizePrintfMacros.h header which defines "PRIuSIZE"
for this purpose.
Ch
I filed bug 1384233 for removing the header and unnecessary defines.
On Tue, Jul 25, 2017 at 2:13 PM, Honza Bambas wrote:
> Thanks! OTOH, I think we no longer need it. Since VS2015 (our minimal
> toolchain version on Win) supports %z modifier. Only VS2013 and down only
> defines %I.
> -hb-
>
>
Based on product plans I've heard, this sounds like the right approach. We
should try to limit the scope of such browser-specific APIs but it's likely
necessary in some cases (e.g., in the devtools.)
On Tue, Jul 25, 2017 at 2:44 AM, Gabor Krizsanits
wrote:
> In my mind at least the concept is t
Should we moz-prefix moz-specific extensions?
On 25/07/17 20:45, Jet Villegas wrote:
> Based on product plans I've heard, this sounds like the right approach. We
> should try to limit the scope of such browser-specific APIs but it's likely
> necessary in some cases (e.g., in the devtools.)
>
>
>
On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote:
> Should we moz-prefix moz-specific extensions?
We have been trying not to do that for Web-exposed APIs but maybe the
extensions case is different?
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guiding_Principles
Op 7/23/2017 om 2:12 AM schreef Andrew Swan:
> On Fri, Jul 21, 2017 at 12:32 AM, Jörg Knobloch wrote:
>
>> Since you're saying that we're still using the old interface, in fact
>> Andrew said: "old add-on install
>> confirmation dialog, that dialog includes a note about the certificate",
>> would
On Tue, Jul 25, 2017 at 08:13:17PM +0200, Honza Bambas wrote:
> Thanks! OTOH, I think we no longer need it. Since VS2015 (our minimal
> toolchain version on Win) supports %z modifier. Only VS2013 and down only
> defines %I.
Are you sure? Because that's not listed on MSDN:
https://msdn.microsoft
On Wednesday, July 26, 2017 at 8:21:23 AM UTC+12, Andrew Overholt wrote:
> On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote:
>
> > Should we moz-prefix moz-specific extensions?
>
>
> We have been trying not to do that for Web-exposed APIs but maybe the
> extensions case is different?
> https
I believe that Gabor's response to the original question nicely captures
the thinking and plans of everybody working on WebExtensions day-to-day.
The questions about formally defining a policy for what to expose to
extensions and about how to (or if we should) distinguish Firefox-specific
APIs from
On Wed, Jul 26, 2017 at 11:07 AM, wrote:
> I think that such an API could be spec'd such that it is portable, with
> the output being flexible enough that we can put Mozilla-specific
> information in there. E.g.: A fixed API to get the data, and a minimal
> structure for the output, but say, each
Experience from Web content standards probably informs the situation here...
On Wed, Jul 26, 2017 at 11:46 AM, Andrew Swan wrote:
> For handling cross-platform versus Firefox-specific APIs, I don't think the
> right outcome is perfectly clear. Of course we should learn from how
> web-exposed AP
On 25.07.2017 21:34, Mike Hommey wrote:
Why not just adding GNU-style printf()+friends to nspr
(perhaps even w/ printk() extensions) and use that everywhere,
instead of having special cases or complex for fmt string
construction everywhere ?
--mtx
On 25.07.2017 14:28, Jeff Muizelaar wrote:
The cairo stuff is from an upstream project and not worth removing.
The bundled cairo pieces are quite far away from upstream
and ancient.
Perhaps we should kick out the bundled stuff and use the original
package (from distro) instead.
--mtx
_
On 7/25/17 1:04 AM, Enrico Weigelt, metux IT consult wrote:
On 25.07.2017 02:04, Kris Maglione wrote:
The only remaining in-tree references to the XP_OS2 macros are in NSPR
and NSS, which are technically separate projects, and have their own
sets of supported platforms.
In esr52 there's a bit
On 7/25/2017 7:28 AM, Jeff Muizelaar wrote:
The only remaining in-tree references to the XP_OS2 macros are in
NSPR and NSS, which are technically separate projects, and have
their own sets of supported platforms.
The cairo stuff is from an upstream project and not worth removing.
Likewise fo
On Tue, Jul 25, 2017 at 11:25 PM, Steve Wendt wrote:
> On 7/25/2017 7:28 AM, Jeff Muizelaar wrote:
>
The only remaining in-tree references to the XP_OS2 macros are in
NSPR and NSS, which are technically separate projects, and have
their own sets of supported platforms.
>>
>>
>> The
Tue, Jul 25, 2017 at 8:25 PM, Steve Wendt wrote:
> Likewise for libvpx and libffi?
>
libvpx is maintained upstream and updated periodically, so there's no point
making changes if they're not also accepted upstream. I don't know about
libffi; our vendored copy is a minor release behind upstream
On 7/25/2017 8:40 PM, Ralph Giles wrote:
libvpx is maintained upstream and updated periodically, so there's no
point making changes if they're not also accepted upstream.
The remaining OS/2 users would definitely not appreciate a crusade to
kill support for that platform in upstream projects
On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholt wrote:
> On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote:
>> Should we moz-prefix moz-specific extensions?
>
> We have been trying not to do that for Web-exposed APIs but maybe the
> extensions case is different?
I don't think that it is. If
Enrico Weigelt, metux IT consult wrote:
On 25.07.2017 02:04, Kris Maglione wrote:
The only remaining in-tree references to the XP_OS2 macros are in NSPR
and NSS, which are technically separate projects, and have their own
sets of supported platforms.
In esr52 there's a bit more:
gfx/2d/DrawT
26 matches
Mail list logo
