How to generate compatible firefox for all versions of linux system?

[acnataraj6]

Hi all, 

I had built a firefox on ubuntu 16.04 with GCC 5.4.0 and Glibc 2.23  from 
Mozilla-central. Exported the package using "./mach package".  

firefox version 72.0a1.en

When  I try to launch the  exported firefox from another ubuntu machine with 
same config   ubuntu 16.04, GCC 5.4.0 I was getting  an error   


""" 
XPCOMGlueLoad error for file /home/test/Documents/firefox/libxul.so:
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found 
(required by /home/test/Documents/firefox/libxul.so)
Couldn't load XPCOM
"""

This requires me to upgrade GCC in that machine in order to launch the browser 
without errors.

I tried Firefox Nightly from Mozilla official releases works fine without 
depending on the Glibc version. 


What should I do to configure and build to make the exported firefox work on 
other machines without upgrading the GCC version? 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [IMPORTANT] Submit your PI Requests and technical documentation for Firefox 73 QA feature testing by Dec 13

[Tom Grabowski]

Hi,

This is a reminder that the deadline for PI Requests and technical
documentation for Firefox 73 is this Friday, December 13th. Please log your
PI Request tickets as soon as possible, and provide the required technical
docs.

Thank you,
Tom


On Wed, Dec 4, 2019 at 6:59 PM Tom Grabowski  wrote:

> Similar to what QA did for previous Firefox feature testing prioritization
> ,
> we would like to do the same for Fx73. In order to help with the process,
> please *submit your PI-Request
> *
> and* Feature
> Technical Documentation
> 
> *by *Friday, December 13*. This is needed to assure QA will be involved
> in your feature development work for the 73 cycle. For *features that
> require Nightly testing*, please provide documentation *as soon as
> possible*. QA cannot start working on your feature without documentation.
> Along with these, please create corresponding feature trello cards in
> Firefox  board by Dec 13th.
>
> Kindly ensure to update the *Priority of the PI request *(Highest, High,
> Medium, Low, Lowest) as during feature prioritization process, this will be
> factored in to ensure critical features have sufficient resources assigned.
>
> *Q: What happens after the deadline?*
> A: After the deadline QA will come back with a prioritized list of work
> that represents what we are committing to for the next cycle. We want to
> ensure this list matches eng and product expectations.
>
> * Q: What if I miss the deadline?*
> A: We reserve the right to say that we can't pick up work for late
> requests in the current cycle. You can still develop and execute your own
> test plan or defer the work to the following cycle.
>
>
> * Q: What about unknown or unexpected requests? What if there is a
> business reason for a late request?*
> A: In order to remain flexible, we will keep some percentage of time open
> for requests like these.
>
> *Q: There's no way I'm going to remember to do this.*
> A: Do it now! I'll also send out a reminder next week.
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How best to do async functions and XPCOM?

[Geoff Lankow]

Thanks to all who replied, including Kris whose reply seems to have not 
made it back to the list. As per usual when I ask for help I've been 
immediately distracted by something more urgent and not got back to the 
problem at hand. :-/


As some pointed out this would be a lot easier if I was exclusively in 
JS-land or in C++-land, but I'm not. Nor am I starting something new 
from scratch, which also be easier.


I'm modernising some existing components while trying to avoid wholesale 
rewriting of major parts of the program. There are multiple pieces in 
both languages and they all interact. Also some of this code is *really* 
old in Mozilla terms, which is, um, helpful…


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

Re: How best to do async functions and XPCOM?

[Kris Maglione]

On Sun, Dec 08, 2019 at 11:40:52PM -0500, Joshua Cranmer 🐧 wrote:
The problem with MozPromise is that it doesn't integrate well if you 
use XPIDL interfaces, so you have this annoying issue that if you want 
to use XPIDL integration, you have to use mozilla::dom::Promise, which 
is annoying to use from C++.


In what way is dom::Promise annoying to use from C++? The entire purpose of 
dom::Promise is to make JS promises easy to use from C++.

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

Re: Intent to Prototype: Constructable Stylesheet Objects

[rcaliman]

> 
> DevTools Bug: TBD what, if anything, is needed.
> 

In principle, if Constructable Stylesheets are included in the same APIs used 
to get and listen to regular stylesheets, DevTools should support them 
out-of-the box.

An overview of the continued API support to handle stylesheets in DevTools, as 
well as a way to track whether Constructable Stylesheets are supported by 
DevTools: https://bugzilla.mozilla.org/show_bug.cgi?id=1602535


The bug is explicitly about support in the Inspector, but the Style Editor uses 
the same APIs.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype and ship: IDBTransaction.commit

[Simon Giesecke]

*Summary*: IDBTransaction objects will gain a commit() function that
explicitly marks a transaction as not accepting further requests.
Currently, IndexedDB only commits a transaction after all associated
requests have had their completion event handlers executed, and no new
requests have been queued by the event handlers. Developers can use the
explicit commit() functionality to shave a few event loop cycles off of the
latency of their transactions. A diagram showcasing the semantics of
commit() is available at
https://github.com/w3c/IndexedDB/pull/242#issuecomment-446421869

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1497007
*Standard*: Added to the spec via https://github.com/w3c/IndexedDB/pull/242
*Platform coverage*: All platforms.
*Preference*: This will be added without a preference.
*DevTools bug*: None. Specific support in DevTools is probably not
necessary.

*Other browsers*:

Chrome: shipped (since version 76)

Opera: shipped (since version 63)

Edge: considering (
https://github.com/w3c/IndexedDB/pull/242#issuecomment-428385752)

Safari: considering (
https://github.com/w3c/IndexedDB/issues/234#issuecomment-391109023)

*web-platform-tests*: Available at
https://github.com/web-platform-tests/wpt/blob/master/IndexedDB/idb-explicit-commit.any.js

*Secure contexts*: Chrome/Blink shipped this without [SecureContext].
There was some discussion about Blink adding [SecureContext], but it didn't
happen.  It's not clear whether we should mark it as [SecureContext] given
that commit is feature-detectable, or whether browser consistency is
desirable and okay given that no part of the IndexedDB API is behind a
feature flag.  A concern would be that if code is written that assumes the
commit method exists and it is called inside an IndexedDB callback, the
resulting thrown exception would cause the underlying IndexedDB transaction
to abort.


*Is this feature enabled by default in sandboxed iframes? *

The feature is available wherever IndexedDB is available.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How best to do async functions and XPCOM?

[Andreas Tolfsen]

Also sprach Joshua Cranmer:

> The problem with MozPromise is that it doesn't integrate well if you use 
> XPIDL interfaces, so you have this annoying issue that if you want to use 
> XPIDL integration, you have to use mozilla::dom::Promise, which is annoying 
> to use from C++. A third wrinkle, especially now that async functions has 
> landed in Rust, is if you want to try to use std::future::Future in Rust, 
> which isn't going to convert terribly well to either form.

In this context it should also be mentioned that the Rust XPCOM bindings do not 
support DOM promises quite yet:

https://bugzilla.mozilla.org/show_bug.cgi?id=1512319

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

Re: Local Windows builds to use clang-cl by default

[bstylessj]

On Tuesday, 21 August 2018 20:42:44 UTC+1, David Major  wrote:
> Hi,
> 
> Local Windows builds will use clang-cl and lld-link by default as of
> bug 1483835. This will make your builds match what has been shipping
> on Nightly for the last several weeks, and help avoid the occasional
> MSVC bustage that sneaks in now that those builds are tier-2.
> 
> If you already ran `mach bootstrap` for the recent cbindgen changes,
> you'll already have an up-to-date clang and there's no further action
> required.
> 
> If you need to revert to the Microsoft toolchain, you can put one or
> both of these lines in your mozconfig (but please get in touch and
> tell me why you needed to):
> export CC=cl
> export LINKER=link
> 
> Thanks!

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

Re: How best to do async functions and XPCOM?

[Kris Maglione]

On Fri, Dec 06, 2019 at 11:20:12AM +1300, Geoff Lankow wrote:

Hi all

I'm redesigning a bunch of Thunderbird things to be asynchronous. I'd 
like to use Promises but a lot of the time I'll be far from a JS 
context so that doesn't really seem like an option. The best 
alternative I've come up with is to create some sort of listener 
object and pass it to the async function:


interface nsIFooOperationListener : nsISupports {
 void onOperationComplete(
   in nsresult status,
   [optional] in string errorMessage
 );
};

...

void fooFunction(..., in nsIFooOperationListener listener);

This works fine but I wonder if there's a better way, or if there's 
some established prior art I can use/borrow rather than find out the 
pitfalls myself.


In general, if you're thinking about using an XPIDL interface for something, 
you're probably going down the wrong track. If you're only going to be 
dealing with C++, then you should generally use a pure C++ interface 
(probably just MozPromise in this case). If you're going to need to interact 
with JS at any point, you should probably just use dom::Promise. You can 
always use AutoJSAPI to get a JSContext, and create the Promise in the 
shared JSM global.

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

Re: Proposed W3C Charter: Web of Things Working Group

[Benjamin Francis]

Hi,

I'd like to provide Mozilla IoT  team feedback on
this charter, the content of which has already been modified slightly based
on our earlier feedback  to the
Working Group during the drafting stages.

We are happy overall with the contents of the charter and recommend
approving it (with comment), but the Working Group are aware that we still
have reservations in some areas, which we would like to note.

We would like to join the WoT Working Group under its new charter (we are
already members of the Interest Group, but made a formal objection
 to the
previous charter for the Working Group in 2016). Our comments on the new
charter are as follows.

We welcome the "interoperability profiles" and "discovery" work items which
we hope may improve interoperability by defining a common cross-domain
default protocol binding, and we note the progress which has been made with
regard to privacy and security considerations.

We still have some areas of concern around the scope of the charter,
specifically:

   1. The work item to continue to define protocol bindings for non-web
   protocols makes the scope unreasonably large and makes ad-hoc
   interoperability very challenging
   2. Thing Description Templates are an unnecessary complication and
   overlap in use cases with interoperability profiles and capability schemas
   defined through semantic annotations
   3. We think that the WoT Architecture specification should really be a
   non-normative note in order to reduce the number of normative
   specifications needed for implementers
   4. Non-normative deliverables for WoT Scripting, Management and
   Packaging also have the potential to unnecessarily increase scope further
   in future and could benefit from further incubation in the WoT Interest
   Group rather than being Working Group deliverables

However, we have found the core Thing Description specification produced by
the Working Group to be very useful and have implemented a (modified
version of) this specification in Mozilla's IoT platform
 which has now been in production for two years.
We have gradually been converging our implementation with the Working
Group's specification over time. We would therefore like to support the
continued work of this Working Group to further improve that specification.

On Tue, 3 Dec 2019 at 14:59, L. David Baron  wrote:

> The W3C is proposing a revised charter for:
>
>   Web of Things Working Group
>   https://www.w3.org/2019/11/proposed-wot-wg-charter-2019.html
>   https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0005.html
>
> The differences from the previous charter are:
>
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F12%2Fwot-wg-2016.html&doc2=https%3A%2F%2Fwww.w3.org%2F2019%2F11%2Fproposed-wot-wg-charter-2019.html
>
> Mozilla has the opportunity to send comments or objections through
> Tuesday, December 17.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -David
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
> ___
> 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: Intent to prototype: Character encoding detector

[Boris Zbarsky]

On 12/9/19 6:24 AM, Henri Sivonen wrote:

Good point. I'll use tentative WPTs for end-to-end automated tests.


Thank you!

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