Quantum Flow Engineering Newsletter #16

2017-07-20 Thread Ehsan Akhgari
Hi everyone, It has been almost a month and a half since the last time that I talked about our progress in fighting sync IPC issues. So I figured it's time to prepare another Sync IPC Analysis

Re: wpt CSS tests now running on Linux

2017-07-20 Thread Gregory Szorc
On Thu, Jul 20, 2017 at 9:33 AM, James Graham wrote: > Bug 1341078 and dependencies just landed on inbound, which means we now > have the W3C/web-platform-tests CSS tests in-tree and running in > automation. This adds about 12,000 reftests for CSS features to the > web-platform-tests suite. They

Only build the Gecko-dev html parser

2017-07-20 Thread peter279k
Hi everyone, as title, I want to use the C/C++ to research the Gecko-dev html parser. Is it possible to build the Gecko-dev html parser? https://github.com/mozilla/gecko-dev/tree/e9fa5c772abe4426c5e33ffe61c438f75f990aca/parser Thanks. ___ dev-platform

Re: wpt CSS tests now running on Linux

2017-07-20 Thread James Graham
On 20/07/17 18:26, Emilio Cobos Álvarez wrote: Thanks for this James! \o/ One question, do we run the CSS test linter on automation, or are there any plans for it? Yes, that should be run as part of the W lint job (e.g. [1]), which is run on pushes (including to try) that change files under

Re: wpt CSS tests now running on Linux

2017-07-20 Thread Emilio Cobos Álvarez
Thanks for this James! \o/ One question, do we run the CSS test linter on automation, or are there any plans for it? We probably should, because otherwise we may only notice when trying to upstream, like in [1], which is more work for everyone. [1]: https://github.com/w3c/web-platform-tests/pull

wpt CSS tests now running on Linux

2017-07-20 Thread James Graham
Bug 1341078 and dependencies just landed on inbound, which means we now have the W3C/web-platform-tests CSS tests in-tree and running in automation. This adds about 12,000 reftests for CSS features to the web-platform-tests suite. They are currently enabled in CI, but only on linux*, due to lim

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

2017-07-20 Thread Frank-Rainer Grahl
I know but I don't see any comm-central code which calls the apis in question directly or uses the return values. I just searched via dxr but would probably take a deeper look at the code to understand it. Might not matter anyway in the short time. With the destruction of the classic add-on inf

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

2017-07-20 Thread Kris Maglione
On Thu, Jul 20, 2017 at 10:32:27AM +0200, Frank-Rainer Grahl wrote: Given all this, the question is do we still need this second API? Does Thunderbird or SeaMonkey use it for any reason, or can we simplify the code-base, reduce build size, etc.? I looked at the code and don't see any use outsid

Intent to Remove: Insecure use of WebCrypto

2017-07-20 Thread Tim Taubert
Summary: The WebCrypto spec [1] states that window.crypto.subtle should only be usable from a secure origin (i.e. on a domain being served over HTTPS). Currently Gecko's implementation works on insecure origins (i.e. sites served over unencrypted HTTP). To bring our implementation in line with the

Re: Proposed W3C Charter: Web Commerce Interest Group

2017-07-20 Thread Marcos Caceres
Hi Tantek, bcc: Ian Jacobs, who is the W3C Team contact and activity lead. On July 18, 2017 at 9:58:40 AM, Tantek Çelik (tan...@cs.stanford.edu) wrote: > I'd like to hear feedback from Marcos (cc'd) on how/why this group > will complement or help our work in the Web Payments WG (does not seem > t

Re: 64-bit Firefox progress report: 2017-07-18

2017-07-20 Thread Jean-Yves Avenard
Hi On Wed, Jul 19, 2017 at 9:01 AM, Mike Hommey wrote: > What's the plan for eligible people that still want to keep 32-bit > Firefox? Are they going to have to stop auto upgrades, which would get > them automatically on 64-bits and upgrade manually? This is especially > going to be a problem for

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

2017-07-20 Thread Frank-Rainer Grahl
Given all this, the question is do we still need this second API? Does Thunderbird or SeaMonkey use it for any reason, or can we simplify the code-base, reduce build size, etc.? I looked at the code and don't see any use outside of toolkit. Same for the PREF_CUSTOM_CONFIRMATION_UI/"xpinstall.cu

Re: 64-bit Firefox progress report: 2017-07-18

2017-07-20 Thread Chris Peterson
On 2017-07-19 6:58 PM, Mike Hommey wrote: I don't understand why that would be, but if so it should show in crashstats as fewer small OOMs on these devices. Does the data actually show that? I don't know. Can that be filtered? I'm not sure I'm answering the right question, but searching thro

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

2017-07-20 Thread Frank-Rainer Grahl
SeaMonkey does not use signing and does not plan to do so. It is disabled in the mozconfigs during build time in all trees with: > # Disable checking that add-ons are signed by the trusted root > MOZ_ADDON_SIGNING=0 > # Disable enforcing that add-ons are signed by the trusted root > MOZ_REQUIRE_