Re: Intent to Implement and Ship: Large-Allocation Header

On Wed, Jan 18, 2017 at 12:21 PM, Michael Layzell wrote: > Summary: > Games implemented on the web platform using WASM or asm.js use large > contiguous blocks of allocated memory as their backing store for game > memory. For complex games, these allocations can be quite

Re: Deprecating XUL in new UI

Regarding choice of framework for HTML-backed UIs. My initial suggestion is to try not to go into a fully-opinionated stack like React. My opinion has nothing to do with React itself, it's quality or suitability, but with a generic approach of using an opinionated stack that diverges from

Re: Intent to Implement and Ship: Large-Allocation Header

This is true, but I'm not sure how this is worse than other mechanisms which can currently be used to deny other pages resources, such as allocating and leaking large amounts of memory or pegging the event loop. On Wed, Jan 18, 2017 at 4:38 PM, Martin Thomson wrote: > On Thu,

Re: Intent to Implement and Ship: Large-Allocation Header

On Thu, Jan 19, 2017 at 10:17 AM, Michael Layzell wrote: > @Martin There is a pref (dom.ipc.processCount.webLargeAllocation - default > 2) which controls the maximum number of processes which may be allocated to > Large-Allocation processes. Any requests past that number

Re: Intent to Implement and Ship: Large-Allocation Header

@Martin There is a pref (dom.ipc.processCount.webLargeAllocation - default 2) which controls the maximum number of processes which may be allocated to Large-Allocation processes. Any requests past that number (firefox-globally) will not cause new processes to be created. @Chris the

[BMO] All accounts now "Require API key authentication for API requests"

As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact us. Any service or program that uses cookies for authentication to XMLRPC/JSONRPC will no longer work and require updating to use

Re: Intent to Implement and Ship: Large-Allocation Header

On Thu, Jan 19, 2017 at 9:21 AM, Michael Layzell wrote: > Security & Privacy Concerns: none I doubt that this is true. You have provided a way for sites to gain a whole process to themselves, on request. Denial of service seems like something that would need to be

Re: Intent to Implement and Ship: Large-Allocation Header

On 1/18/2017 12:21 PM, Michael Layzell wrote: Games implemented on the web platform using WASM or asm.js use large contiguous blocks of allocated memory as their backing store for game memory. For complex games, these allocations can be quite large, sometimes as large as 1GB. In 64-bit builds,

Intent to Implement and Ship: Large-Allocation Header

Summary: Games implemented on the web platform using WASM or asm.js use large contiguous blocks of allocated memory as their backing store for game memory. For complex games, these allocations can be quite large, sometimes as large as 1GB. In 64-bit builds, we have no problem finding a large

Re: Testing Wanted: APZ Scrollbar dragging

> glitches if you scroll too fast (using vertical scroll bar) remains try > http://www.diariouno.com.ar/ and scroll fast texts/news start to blink or > dissapear. Thanks! This is a known issue, bug 1251617. Quoting from a recent post to dev-platform about this [1]: "This is hard to fix, and

Re: Testing Wanted: APZ Scrollbar dragging

El miércoles, 18 de enero de 2017, 15:50:10 (UTC-3), Botond Ballo escribió: > On Wed, Jan 18, 2017 at 1:21 PM, wrote: > > Right now of FF 51 beta...it has issues/glitches if you scroll too fast > > (using scroll bar) and also Horizontal scroll bars are buged too (doesn't

Re: Testing Wanted: APZ Scrollbar dragging

On Wed, Jan 18, 2017 at 1:21 PM, wrote: > Right now of FF 51 beta...it has issues/glitches if you scroll too fast > (using scroll bar) and also Horizontal scroll bars are buged too (doesn't > scroll properly) Are you manually flipping the pref apz.drag.enabled in 51

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

On Wed, Jan 18, 2017 at 5:38 PM, Ben Kelly wrote: > Last I checked we do this all the time for new and potentially unstable > things. For example, AFAIK we do not enable e10s on ESR. I have not heard > if that will change for 52 ESR. I would expect not, though, since we are

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

On Wed, Jan 18, 2017 at 1:35 PM, Dirkjan Ochtman wrote: > API. On the other hand, sites like caniuse.com clearly advertise that > ServiceWorkers are available in Firefox (and Chrome), and then going > back and not exposing that in the ESR population seems to me that in a >

Re: Deprecating XUL in new UI

On 01/18/2017 08:11 PM, J. Ryan Stinnett wrote: Thanks for checking it out! I guess the reading from / writing to disk is only for speeding up initial load of the first window then? reading is for speeding up the initial load, and once prototype has been loaded, no new loads are needed,

Re: Testing Wanted: APZ Scrollbar dragging

El miércoles, 17 de febrero de 2016, 15:35:10 (UTC-3), Benoit Girard escribió: > Currently APZ does not cause scrollbar initiated scrolling to be async. > I've been working in fixing this and I'd like some help testing it out > before enabling it on Nightly. If you're interested please flip >

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

On Wed, Jan 18, 2017 at 5:43 PM, Ben Kelly wrote: > On Wed, Jan 18, 2017 at 10:58 AM, Till Schneidereit < > t...@tillschneidereit.net> wrote: > >> That'll mean that Windows XP/Vista users won't have them. >> >> Might be ok, but means the bar for a decision like this should be

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

On Wed, Jan 18, 2017 at 10:58 AM, Till Schneidereit < t...@tillschneidereit.net> wrote: > That'll mean that Windows XP/Vista users won't have them. > > Might be ok, but means the bar for a decision like this should be somewhat > higher than usual, I think. > Understood, but that does not change

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

> I would expect not, though, since we are >> still rolling it out to the full population. I do believe the plan is to enable e10s on 52 ESR, but with the Firefox 50 restrictions (e10s enabled by default, disabled if a11y APIs used, disabled if non-WebExtension, non-mpc=true add-ons enabled).

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

On Wed, Jan 18, 2017 at 10:58 AM, Dirkjan Ochtman wrote: > On Wed, Jan 18, 2017 at 4:49 PM, Ben Kelly wrote: > > While things have stabilized since then we are in process of making a > major > > architectural change in order to support multiple content

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

That'll mean that Windows XP/Vista users won't have them. Might be ok, but means the bar for a decision like this should be somewhat higher than usual, I think. On Wed, Jan 18, 2017 at 4:49 PM, Ben Kelly wrote: > Hi all, > > I'd like to disable service workers in 52 ESR.

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

On Wed, Jan 18, 2017 at 4:49 PM, Ben Kelly wrote: > While things have stabilized since then we are in process of making a major > architectural change in order to support multiple content processes > (multi-e10s). This will make it very difficult to uplift fixes. Once the >

Intent to disable service workers and push in 52 ESR

Hi all, I'd like to disable service workers in 52 ESR. This would also require disabling push notifications. A year ago we decided to disable service workers in 45 ESR because it was very new and unstable: https://groups.google.com/forum/#!msg/mozilla.dev.platform/yuNHtDhl3lY/VWXOa8N9AgAJ

Re: Intent to remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

On Wed, Jan 18, 2017 at 9:38 AM, Jonathan Kew wrote: > Note that the current CSS Fonts 3 spec explicitly says that UAs are required > to recognize localized font names: > > "Some font formats allow fonts to carry multiple localizations of the family > name. User agents must

Re: Intent to remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

Forgot the bug link: https://bugzilla.mozilla.org/show_bug.cgi?id=1331859 On Wed, Jan 18, 2017 at 11:38 AM, Jonathan Kew wrote: > As you've noted, Chrome does not actually support this, so there is not full > interoperability in this area; but if we decide to remove this

Intent to ship: EventSource for Dedicated Worker and Shared Worker

Summary: In Bug 1267903 I've exposed EventSource to dedicated worker and shared worker. Related Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1267903 Link to standard:

Re: Intent to remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

On 18/01/2017 07:04, Henri Sivonen wrote: I'm in the process of rewriting our encoding converter infrastructure in Rust. For a new implementation, it makes sense to support only the Web-exposed encodings, that is, the encodings specified in the Encoding Standard. Currently, Firefox supports