Re: OS/2 still supported ?

[Dave Yeo]

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/DrawTargetCairo.cpp
gfx/cairo/cairo/src/cairo-features.h.in
gfx/cairo/cairo/src/cairo-mutex-impl-private.h
gfx/cairo/cairo/src/cairo-os2-private.h
gfx/cairo/cairo/src/cairo-os2-surface.c
gfx/cairo/cairo/src/cairo-os2.h
gfx/cairo/cairo/src/cairo.h
js/src/ctypes/CTypes.cpp
js/src/ctypes/libffi/src/closures.c
js/src/ctypes/libffi/src/dlmalloc.c
js/src/ctypes/libffi/src/x86/win32.S
media/libvpx/vp8/common/threading.h
mfbt/Poison.cpp



Cairo and libffi are separate projects that still support OS/2 and are 
used by more then Mozilla.

Dave

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Martin Thomson]

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 there is any risk at all that someone
else might want to use it, then prefixing will only make our life
harder long term.  Good names are cheap enough that we don't need to
wall ours off.

See also https://tools.ietf.org/html/rfc6648
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Steve Wendt]

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 (including NSS and 
NSPR).  :-p


For what it's worth - there was a new OS/2 distribution / release just a 
couple months ago, as "ArcaOS".

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Ralph Giles]

 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 (3.1 vs 3.2.1
released in 2014).

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Jeff Muizelaar]

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 cairo stuff is from an upstream project and not worth removing.
>
>
> Likewise for libvpx and libffi?

Yes.

-Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Steve Wendt]

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 for libvpx and libffi?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Cameron Kaiser]

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 more:

gfx/2d/DrawTargetCairo.cpp
gfx/cairo/cairo/src/cairo-features.h.in
gfx/cairo/cairo/src/cairo-mutex-impl-private.h
gfx/cairo/cairo/src/cairo-os2-private.h
gfx/cairo/cairo/src/cairo-os2-surface.c
gfx/cairo/cairo/src/cairo-os2.h
gfx/cairo/cairo/src/cairo.h
js/src/ctypes/CTypes.cpp
js/src/ctypes/libffi/src/closures.c
js/src/ctypes/libffi/src/dlmalloc.c
js/src/ctypes/libffi/src/x86/win32.S
media/libvpx/vp8/common/threading.h
mfbt/Poison.cpp




I posted a heads-up in mozilla.dev.ports.os2 so they have some warning 
about the impending code removal. There is still a third-party port 
being maintained.


Cameron Kaiser
tier-3, 2-1-contact
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Enrico Weigelt, metux IT consult]

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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Correct format specifier for size_t

[Enrico Weigelt, metux IT consult]

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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Robert O'Callahan]

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 APIs evolved and avoid the need for the browser extensions
> equivalent of jquery.  On the other hand, browser extensions by their
> nature work with features that are not standardized and that differ from
> browser to browser.  For instance, we have WebExtensions APIs for working
> with containers.  There's no doubt in my mind that we should have this API
> but of course extensions that use it won't work in other browsers.  Maybe
> in this case some sort of moz- prefix would be appropriate but its not hard
> to come up with murkier examples.


You probably don't want to use a prefix there. What if some other browser
decided to support containers? Then they'd want to implement your API and
having it be prefixed is then horrible for everyone.

What about the tabs API?  It is
> currently supported in Firefox, Chrome, Edge, and Opera.  But what if one
> of the non-tab-based-browser-ui projects takes off and wants to support
> browser extensions?  If they simply don't support the tabs API then how
> should the API be named to indicate to extension developers that it isn't
> universally available?
>

It's probably best to be pessimistic about extension developers' behaviour.
In practice the tabs API, or any other API, is either universally present
in the browsers they care about, or it is not. In the former case they will
rely on it explicitly or implicitly (e.g. by having untested fallback code
paths that don't work). In the latter case they will discover the problem
and fix it. Either way naming probably doesn't help much.

Developers of your putative non-tabbed browser would have to recognize the
situation and decide what's best for them. If there are lots of extensions
that rely on the tabs API, maybe the browser developers would have to put
in some stub implementation that tries to do something sensible.

One thing that might help (and maybe you already have this?) is to have the
extension manifest contain a whitelist of the set of APIs the extension
requires. That would allow easy filtering to determine which extensions are
supported by a browser.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Robert O'Callahan]

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 log message could have a free-form
> 'data' json object, or some self-described tabular data.
>

The latter approach has generally turned out to be a mistake. Often, all it
achieves is to shift compatibility problems to a different level, where the
problems may not be recognized, or there may be no standards process to
deal with them, or the usual methods for feature detection do not work.

If you want to have Mozilla-specific extensions, be honest about it and
just add them to the WebExtensions API.

One option here might be to have an API that returns strings of
human-readable text, although that's dangerous too because people might try
to parse it.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Andrew Swan]

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 cross-platform APIs are ones that we have talked about a little
bit but we've been heads-down on our goals for the breadth, stability, and
performance of WebExtensions for 57 when we turn off legacy extensions.

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 APIs evolved and avoid the need for the browser extensions
equivalent of jquery.  On the other hand, browser extensions by their
nature work with features that are not standardized and that differ from
browser to browser.  For instance, we have WebExtensions APIs for working
with containers.  There's no doubt in my mind that we should have this API
but of course extensions that use it won't work in other browsers.  Maybe
in this case some sort of moz- prefix would be appropriate but its not hard
to come up with murkier examples.  What about the tabs API?  It is
currently supported in Firefox, Chrome, Edge, and Opera.  But what if one
of the non-tab-based-browser-ui projects takes off and wants to support
browser extensions?  If they simply don't support the tabs API then how
should the API be named to indicate to extension developers that it isn't
universally available?

We're just reaching the point where it is feasible to build interesting
cross-browser extensions and extension authors are starting to ask us to
make it easier to do so.  We've got plenty of other simple things we can do
to make their lives easier (for instance extensions APIs in Chrome all use
callbacks, in Firefox they can use Promises or callbacks, and in Edge they
only use Promises) but this problem of naming/disocvering/etc APIS is a big
architectural issue to work out.  Hopefully when the dust begins to settle
on 57 we can put some energy into this.  For anybody who's interested, we
have the dev-addons mailing list and the #webextensions IRC channel for
Mozilla-specific discussion and the w3c browserext group (
https://browserext.github.io/) for cross-vendor efforts.

Finally, to circle back once again to smaug's original question, I think we
can be more liberal with exposing APIs to extensions than we are with
exposing them to content -- enabling cross-browser extensions is an
important benefit of WebExtensions but limiting WebExtensions APIs to only
those that can run in every browser has never been a goal (in spite of what
you may have read on hacker news).  If we overdo it, we even have a draft
of a policy for deprecating APIs:
https://wiki.mozilla.org/WebExtensions/DeprecationPolicy  I think its much
more important that we take care when designing extension-facing APIs to
ensure that extensions can't do anything "dangerous" by default and that
they are granted access to sensitive parts of the browser, only when we can
explain very clearly to a user so that they can make an informed choice
whether to grant permission or not.

-Andrew


On Tue, Jul 25, 2017 at 2:14 AM, smaug  wrote:

> 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
> that will be.
>
> Could someone familiar WebExtensions clarify this a bit? Do we have some
> policy here. Should we be as strict as with web APIs, or allow some
> exceptions or do whatever people want/need?
>
>
>
>
> -Olli
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[gsquelart]

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://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guiding_Principles

Thank you Olli for starting this discussion.
For some context: Olli reviewed my initial attempt to bring some [chrome-only] 
moz-specific extensions for use in the legacy about:media extension, to a 
privilege-gated API for use in a (Web)Extension rewrite, to make it work at 
least as well as the old one.


So in my case, I'd like to get some debugging data from a  element, and 
build a useful DevTools panel from that. (Currently we have APIs like 
HTMLMediaElement.mozRequestDebugInfo() to get such data, but only extensions 
with the "debugger" or "tabs" privilege can see them; so any random webdev 
won't see these things.)

The collected data will be a kind of log that captures the changing state of 
our Media Playback stack and how data goes through it; a bit similar to what an 
unnamed competitor already does in their 'chrome://media-internals/' page -- 
but much better of course!

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 log message could have a free-form 'data' json object, or 
some self-described tabular data.

But with no experience in producing cross-browser specs, I'm scared that such a 
process would be time-consuming(?)

So in the interest of producing a useful Media DevTools Panel soon-ish I'm 
thinking of continuing with moz-specific APIs for now, as development 
progresses and I tweak these APIs...
But with the view of eventually converting them to a proper WebExtension API.
Of course the risk there is that once we have a working DevTools panel, there 
may be little incentive to Do The Right Thing and work on proper specs.


What do you all think? (in general and/or for my specific case)

Thanks,
Gerald
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Correct format specifier for size_t

[Mike Hommey]

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.com/en-us/library/56e442dc.aspx
https://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: removing "the old way" of signing add-ons

[Onno Ekker]

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 you be able to give us some exact DXR references which would save us
>> a lot of searching.
>>
> 
> The dialog I mentioned is:
> https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallConfirm.xul
> 
> The listbox in that dialog holds instances of:
> https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallItem.xml
> 
> The label in those items with the class "xpinstallItemSigned" ends up
> holding either certificate details or some default message like "Author not
> verified"
> 
> While we're on the topic, Thunderbird and Seamonkey should look at moving
> over to the doorhanger addon install flow that Firefox uses -- that xul
> dialog and everything that supports it are unused in Firefox and its days
> are numbered.
> 
> -Andrew
> 

Looks like this indeed still used by both Thunderbird and SeaMonkey:
http://i.imgur.com/Q7tQIsN.png (sorry for the Dutch screenshot).
I've also verified with DOM Inspector, that this is indeed above
mentioned dialog window.

Onno
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Andrew Overholt]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[David Teller]

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 2:44 AM, Gabor Krizsanits 
> wrote:
> 
>> 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.
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Jet Villegas]

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 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.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Correct format specifier for size_t

[Kartikaya Gupta]

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-
>
>
> On 7/25/17 7:03 PM, Botond Ballo wrote:
>>
>> 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()) ?
>>>
>>> Not sure if to use "%zu" directly.
>>>
>>> Thanks.
>>> -hb-
>>>
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Correct format specifier for size_t

[Honza Bambas]

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.

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()) ?

Not sure if to use "%zu" directly.

Thanks.
-hb-

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Correct format specifier for size_t

[Botond Ballo]

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()) ?
>
> Not sure if to use "%zu" directly.
>
> Thanks.
> -hb-
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Correct format specifier for size_t

[Honza Bambas]

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
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Jeff Muizelaar]

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 esr52 there's a bit more:
>
> gfx/2d/DrawTargetCairo.cpp
> gfx/cairo/cairo/src/cairo-features.h.in
> gfx/cairo/cairo/src/cairo-mutex-impl-private.h
> gfx/cairo/cairo/src/cairo-os2-private.h
> gfx/cairo/cairo/src/cairo-os2-surface.c
> gfx/cairo/cairo/src/cairo-os2.h
> gfx/cairo/cairo/src/cairo.h

The cairo stuff is from an upstream project and not worth removing.

-Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Gabor Krizsanits]

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 limitations, and we certainly plan to add APIs that Google will
never implement because of policy reasons for example.

I hope one day we can even have decent specs around some of the common API (
https://browserext.github.io/), and for new APIs I guess we should try to
work together with other vendors as much as possible IF that makes sense.
But if it's about an API that is needed for a popular Firefox specific
extension to be ported, and it's totally out of policy for Google
extensions anyway, then we should "only" care about security and the extra
cost it might cause for US to keep supporting it. And since we're trying to
move away from manual review http://www.agmweb.ca/2017-07-11-manual-review/
we should probably be quite conservative about what we accept.

Gabor

On Tue, Jul 25, 2017 at 11:14 AM, smaug  wrote:

> 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
> that will be.
>
> Could someone familiar WebExtensions clarify this a bit? Do we have some
> policy here. Should we be as strict as with web APIs, or allow some
> exceptions or do whatever people want/need?
>
>
>
>
> -Olli
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Extensions and Gecko specific APIs

[smaug]

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
that will be.

Could someone familiar WebExtensions clarify this a bit? Do we have some policy here. Should we be as strict as with web APIs, or allow some 
exceptions or do whatever people want/need?





-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Enrico Weigelt, metux IT consult]

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-features.h.in
gfx/cairo/cairo/src/cairo-mutex-impl-private.h
gfx/cairo/cairo/src/cairo-os2-private.h
gfx/cairo/cairo/src/cairo-os2-surface.c
gfx/cairo/cairo/src/cairo-os2.h
gfx/cairo/cairo/src/cairo.h
js/src/ctypes/CTypes.cpp
js/src/ctypes/libffi/src/closures.c
js/src/ctypes/libffi/src/dlmalloc.c
js/src/ctypes/libffi/src/x86/win32.S
media/libvpx/vp8/common/threading.h
mfbt/Poison.cpp


--mtx

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing MozillaBuild 3.0 Release

[Frank-Rainer Grahl]

> This means some people on older hardware or OSes aren't able build Firefox,
This currently means that about 50% of the current users are not being able to 
build in the future. With Win 7 and 8.1 market share together we are not 
speaking about Vista here. I am building in a vm anyway so can set up a Win 10 
one too but limiting choices to force using an operating system which treats 
its users like dirt is not what I would call a good move. So as long as the 
compilers are supported on other OS than 10 I strongly disagree with this.

FRG

Mike Hoye wrote:

On 2017-07-22 3:13 AM, Frank-Rainer Grahl wrote:
Personally I find this a bad idea. Windows 7 and 8.1 are still supported 
till 2020 and 2023. As long as the compilers are supported too on them these 
should also be fully supported as a build environment. 
Unfortunately we have to build _for_ a number of our supported operating 
systems without being able to build _on_ those operating systems. That's been 
true for some time now; while we still support 32-bit systems, for example, 
you can't build Firefox on 32-bit systems at all due to memory constraints, 
and the new MozillaBuild system is 64-bit only due to a variety of dependencies.


This means some people on older hardware or OSes aren't able build Firefox, 
that's true, but it doesn't mean they have no way to contribute to Firefox, 
and restricting ourselves to only shipping a product that we can build 
directly on those older systems means giving every single person who relies on 
those systems a crap experience and a substandard product.


It'd be nice in some abstract sense to be able to bootstrap a Firefox 
executable on every system we support, but the tradeoffs we'd need to accept 
to do that (support costs, development velocity, actual as-delivered product 
quality and a lot more) are _so_ egregiously bad for everyone involved that 
there's no reasonable, much less responsible, way we can invest any time or 
effort making that happen.




- mhoye


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform