Re: Deprecating XUL in new UI

On Monday, January 23, 2017 at 12:03:35 PM UTC-8, Eric Shepherd wrote: > It seems to me, anyway, that the ideal solution would be to enhance HTML > (ideally in the spec) with the features needed to build a full-fledged > desktop UI. That would be fabulous not just for Firefox making the

Re: Aarch64 as higher than tier-3?

On Mon, Jan 23, 2017 at 9:00 PM, Kevin Brosnan wrote: > AArch64 (ARMv8) has been shipping on Android phones since Q3 2014. Furthermore, the flagships all seem to have 4 GB of RAM now. It's not clear to me if ARMv7 userland processes on AArch64 Android kernel get 2 GB or 3 GB

Re: Status of support for Android on ARMv7 without NEON

On Mon, Jan 23, 2017 at 8:03 PM, Nicholas Alexander wrote: > On Mon, Jan 23, 2017 at 9:58 AM, Henri Sivonen wrote: >> >> Do we support Android on ARMv7 without NEON? > > > Ralph Giles told me just a few days ago that yes, we support ARMv7 with and >

Re: PSA: sysconf(_SC_NPROCESSORS_ONLN) is apparently not reliable on Android / ARM

There are plans to move the js/src/threading primitives into MFBT, so I don't think the core count is out of scope. On Mon, Jan 23, 2017 at 11:53 AM, Gabriele Svelto wrote: > On 23/01/2017 18:44, Gian-Carlo Pascutto wrote: > > If only we had some crossplatform runtime that

Re: Intent to disable service workers and push in 52 ESR

We disabled some features (iirc Hello and Pocket) in ESR45. The preference is to keep ESR inline with what's in the mainline release but we're also supporting ESR on a best effort basis. I think the rationale in this thread for disabling service workers and push in ESR52 makes sense if we're not

Re: Intent to disable service workers and push in 52 ESR

Any time something is disabled or removed from ESR, please be sure the developer docs team knows about it, because that’s something that has to be reflected in our documentation. I’m not aware of many (if any) documentation that says something exists in version X but not in ESR version X;

Re: Deprecating XUL in new UI

It seems to me that the XUL to HTML transition is a big job that needs to be done with care. Would it make sense to try to work toward additions to HTML and/or additions of prefixed attributes and the like to add the needed behaviors to HTML wherever possible before trying to hack out a

Re: PSA: sysconf(_SC_NPROCESSORS_ONLN) is apparently not reliable on Android / ARM

On 23/01/2017 18:44, Gian-Carlo Pascutto wrote: > If only we had some crossplatform runtime that abstracted such system > specifics away from us > (https://bugzilla.mozilla.org/show_bug.cgi?id=663970) then maybe we > wouldn't have to re-fix the same bugs every 5 years. On this topic, I've heard

Re: Emoji and Bugzilla

Yeah, we’re *so* going to start seeing bugs that are done entirely in emoji. I don’t look forward to decoding them, although I’m sure they’ll be incredibly clever and fun. :) > On Jan 17, 2017, at 10:01 PM, Emma Humphries wrote: > > As the BMO team announced earlier, we're

Sandboxing plans for Media, WebRTC and Networking

Since some discussions at the all-hands around audio sandboxing and mtransport's blocking linux sandbox tightening, and discussions with the necko team, I decided to explore the options available to us, before we got too far down a path-of-least-resistance. The following is the result of that

Re: Aarch64 as higher than tier-3?

On 1/23/2017 1:00 PM, Henri Sivonen wrote: Are there any plans to support Aarch64 as a tier higher than tier-3? For Android or the upcoming Aarch64 flavor of Windows 10 maybe? Is Google shipping a 64-bit Android emulator for aarch64 yet? Last I knew, they only supported x86 for their 64-bit

Re: Aarch64 as higher than tier-3?

On 23-01-17 19:21, Benjamin Smedberg wrote: > I expect that Android arm64 is similar, but I don't have any context at > all: are aarch64 phones shipping or expected to ship? Most new high end Android models are AArch64 AFAIK. -- GCP ___ dev-platform

Re: Aarch64 as higher than tier-3?

I've started an discussion about the arm64 windows version, but we don't have any news/decision yet. We may need to for market reasons, but the cost in terms of release engineering, release testing and to some extent feature testing is not trivial. I expect that Android arm64 is similar, but I

Re: Status of support for Android on ARMv7 without NEON

On 23-01-17 18:58, Henri Sivonen wrote: > Do we support Android on ARMv7 without NEON? > > Does the answer differ for our different API level builds? I believe that as of currently, we do fully support this. All our code that has NEON codepaths uses runtime detection for NEON presence. In the

Re: Status of support for Android on ARMv7 without NEON

On Mon, Jan 23, 2017 at 9:58 AM, Henri Sivonen wrote: > Do we support Android on ARMv7 without NEON? > Ralph Giles told me just a few days ago that yes, we support ARMv7 with and without NEON. This is relevant to the Oxidation project. I may have been incorrect; I'm

Aarch64 as higher than tier-3?

Are there any plans to support Aarch64 as a tier higher than tier-3? For Android or the upcoming Aarch64 flavor of Windows 10 maybe? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org

Status of support for Android on ARMv7 without NEON

Do we support Android on ARMv7 without NEON? Does the answer differ for our different API level builds? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: PSA: sysconf(_SC_NPROCESSORS_ONLN) is apparently not reliable on Android / ARM

On 23-01-17 17:27, Lars Hansen wrote: > sysconf(_SC_NPROCESSORS_ONLN) is used a number of places in the tree to get > a core count for parallel algorithms. The web says that that phrase does > not really return the number of available cores on ARM Linuxish systems in > general, including Android

PSA: sysconf(_SC_NPROCESSORS_ONLN) is apparently not reliable on Android / ARM

sysconf(_SC_NPROCESSORS_ONLN) is used a number of places in the tree to get a core count for parallel algorithms. The web says that that phrase does not really return the number of available cores on ARM Linuxish systems in general, including Android - because the return value does not account

Re: Deprecating XUL in new UI

On 1/23/17 10:31 AM, David Bolter wrote: Should (can) it die in the Quantum development timeframe? In my opinion, no. What does that do to shipping risk? Makes it super-high. I realize churn creates risk, but I seem to recall XBL is getting in the way for Quantum styling? Not as much

Re: Deprecating XUL in new UI

On Tue, Jan 17, 2017 at 12:55 PM, Bobby Holley wrote: > On Tue, Jan 17, 2017 at 8:56 AM, Boris Zbarsky wrote: > > > On 1/16/17 4:28 PM, Matthew N. wrote: > > > >> Does it just work from XHTML documents? > >> > > > > Yes, as far as I know. > > > > Is our

Re: Deprecating XUL in new UI

Hi all, so as not to leave this hanging: On Tue, Jan 17, 2017 at 9:24 AM, Axel Hecht wrote: > Am 16/01/2017 um 21:43 schrieb Dave Townsend: > >> >> What other features do we depend on in XUL that I haven't listed? >> >> > Accessibility? Not sure how big the difference is there

[Firefox Desktop] Issues found: January 16th to January 20th

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA Team last week, January 16 - January 20 (week 3). Additional details on the team's priorities last week, as well as the plans for the current week are available at: