Re: Intent to unship: Application Cache API

I don't think so. On Tue, 23 Feb 2021 at 14:50, Jeff Muizelaar wrote: > > Is the list of sites that have enrolled in Chrome's reverse origin trial > public? > > -Jeff > > On Tue, Feb 23, 2021 at 7:11 AM Valentin Gosu wrote: > > > > The storage backing for Appl

Intent to unship: Application Cache API

The storage backing for Application Cache has been completely disabled starting with Firefox 84 [1]. That means the current window.applicationCache object is not really useful and only exists for backward compatibility. The plan is to remove it. We intend to do this in two stages: First we

Re: Intent to unship: FTP protocol implementation

On Wed, 10 Feb 2021 at 09:57, Mike Hommey wrote: > On Wed, Feb 10, 2021 at 10:45:53AM +0200, Henri Sivonen wrote: > > On Wed, Feb 10, 2021 at 10:37 AM Valentin Gosu > wrote: > > > FTP support is currently disabled on Nightly. > > > Our current plan is for th

Re: Intent to unship: FTP protocol implementation

Hi everyone, FTP support is currently disabled on Nightly. Our current plan is for the pref flip to ride the trains with Firefox 88 to beta and release [1], meaning we would be disabling FTP a week after Chrome [2] Firefox 89 is supposed to remove the FTP code completely [3] [1]

Using MOZ_LOG for Rust code

Hi everyone, Bug 1624090 and bug 1636888 which just landed added the possibility to forward rust logging into the Gecko logger, so it can now be captured using MOZ_LOG and MOZ_LOG_FILE A

Re: Intent to unship AppCache

Hi everyone, Jonathan is unfortunately not with the company anymore so I wanted to follow-up and clarify our current timeline for disabling appcache. It is my intention to land bug 1619673 [1] in Firefox 77 and let it ride the trains. We would keep the pref off in 78 because that's an ESR

Intent to ship: the Cross-Origin-Resource-Policy header

I'm shortly intending to turn on support for the Cross-Origin-Resource-Policy header This feature was developed behind the preference "browser.tabs.remote.useCORP". https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP) Other UAs shipping this feature: *

Re: Equivalent for XMLHttpRequest.overrideMimeType() in the world of nsIHttpChannel

The implementation of XMLHttpRequest.overrideMimeType() is here: https://searchfox.org/mozilla-central/rev/d1e33e3e11f559952d7d80e722d26a6cf5dd80ac/dom/xhr/XMLHttpRequestMainThread.cpp#3086-3090 You probably want to do something like this:

Re: NS_NewURI is now thread-safe

On Mon, 10 Jun 2019 at 22:25, Boris Zbarsky wrote: > On 6/10/19 4:07 PM, Valentin Gosu wrote: > > which means nsIURI > > can now be safely used and created on any thread via NS_NewURI. > > That's awesome news! > > > and if you want to add any other special sche

NS_NewURI is now thread-safe

Hello everyone, nsIURI has been immutable for a few releases now, meaning once you had one it was safe to use it on any thread (even change it using nsIURIMutator). But until recently you couldn't create a new URI off the main thread (unless you already knew the type of the URI). A few days ago I

Re: Process Priority Manager enabled on Nightly for Windows (only)

On Tue, 29 Jan 2019 at 20:33, Mike Conley wrote: > (cross-posted to dev-platform and firefox-dev) > > Hi folks, > > Just a heads up that in bug 1476981 > , I just autolanded > a patch that, when hopefully merged, will enable the Process

Re: New CEnum enumeration type in XPIDL

OMG, this is amazing work! Thanks a lot for working on this! On Tue, 6 Nov 2018 at 19:37, Kyle Machulis wrote: > Since just about forever (no, really: > https://bugzilla.mozilla.org/show_bug.cgi?id=8781), there's not really > been > an enum type in XPIDL. This means that we have a lot of

Re: Intent to ship: PerformanceServerTiming

On 24 April 2018 at 22:44, James Graham <ja...@hoppipolla.co.uk> wrote: > On 24/04/2018 20:32, Valentin Gosu wrote: > >> Bug 1423495 <https://bugzilla.mozilla.org/show_bug.cgi?id=1423495> is set >> to land on m-c and we intend to let it ride the release train, meani

Intent to ship: PerformanceServerTiming

Bug 1423495 is set to land on m-c and we intend to let it ride the release train, meaning we are targeting Firefox 61. Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=702760 This affects web-compat, since per our

Re: PSA: nsIURI implementations are now threadsafe

On 26 March 2018 at 16:53, Ben Kelly <bke...@mozilla.com> wrote: > On Mon, Mar 26, 2018 at 10:47 AM, Valentin Gosu <valentin.g...@gmail.com> > wrote: > >> Yes, that is definitely something we want to fix, but not very >> straightforward. We have quite a few URI

Re: PSA: nsIURI implementations are now threadsafe

URL stuff" legacy code. > > On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu <valentin.g...@gmail.com> > wrote: > >> Hello everyone, >> >> I would like to announce that with the landing of bug 1447194, all nsIURI >> implementations in Gecko are now thr

Re: PSA: nsIURI implementations are now threadsafe

how_bug.cgi?id=1447190>, 1447194 <https://bugzilla.mozilla.org/show_bug.cgi?id=1447194>, 1447330 <https://bugzilla.mozilla.org/show_bug.cgi?id=1447330>. Still a fair amount of code, but it might be worth it. > On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu <valentin.g...

PSA: nsIURI implementations are now threadsafe

Hello everyone, I would like to announce that with the landing of bug 1447194, all nsIURI implementations in Gecko are now threadsafe, as well as immutable. As a consequence, you no longer have to clone a URI when you pass it around, as it's guaranteed not to change, and now it's OK to release

Re: Still-supported cases of out-of-tree XPCOM code?

Trying to land bug 1407679, which merges nsIIOService2 into nsIIOService, triggered some crashes on Android. It seems the hostutils is also affected by XPCOM changes. Bug 1415242 updated it and fixed the crashes. On 15 November 2017 at 17:35, Jonathan Kingston wrote: > > Code

Re: Threadsafe URLs - MozURL

On 23 October 2017 at 16:21, Anne van Kesteren <ann...@annevk.nl> wrote: > On Mon, Oct 23, 2017 at 4:01 PM, Valentin Gosu <valentin.g...@gmail.com> > wrote: > > A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper > > for rust-url. > &g

Re: Threadsafe URLs - MozURL

the main thread. > -Jeff > > On Mon, Oct 23, 2017 at 10:01 AM, Valentin Gosu <valentin.g...@gmail.com> > wrote: > > Hi everyone, > > > > Threadsafe URLs have been high on everybody's wishlist for a long while. > > The fact that our nsIURI implementation

Threadsafe URLs - MozURL

Hi everyone, Threadsafe URLs have been high on everybody's wishlist for a long while. The fact that our nsIURI implementations weren't thread safe meant that hacks had to be used to use a URI off the main thread, such as saving it as a string, or bouncing back to the main thread whenever you had

Re: nsIURI API changes - punycode domain names

On 9 August 2017 at 19:43, Daniel Veditz <dved...@mozilla.com> wrote: > On Wed, Aug 9, 2017 at 9:57 AM, Valentin Gosu <valentin.g...@gmail.com> > wrote: > >> This is a definite improvement in terms of web-compat. document.origin, >> location.href, etc

nsIURI API changes - punycode domain names

TL;DR: we have made some changes to the nsIURI API that affect IDN domain names Before: ASCII - GetAsciiSpec, GetAsciiHost, GetAsciiHostPort UTF-8 - GetSpec, GetPrePath, GetHost, GetHostPort Now: UTF-8 - GetDisplaySpec, GetDisplayPrePath, GetDisplayHost, GetDisplayHostPort ASCII

Re: Actually-Infallible Fallible Allocations

On 3 August 2017 at 23:12, Jim Blandy wrote: > > But my question wasn't, "is pre-reservation ever valuable?" but rather "is > it valuable in this particular code?" My assumption is that most code isn't > performance-sensitive, and so simplicity should be the priority. > >

Race Cache With Network experiment on Nightly

As part of the Quantum Network initiative we are working on a project called "Race Cache With Network" (rcwn) [1]. This project changes the way the network cache works. When we detect that disk IO may be slow, we send a network request in parallel, and we use the first response that comes back.

Re: Start logging at runtime (Firefox 52)

.mozilla.org/show_bug.cgi?id=1320458, however other > platforms are not fixed yet. > > > Best Regards, > Shih-Chiang Chien > Mozilla Taiwan > > On Tue, May 23, 2017 at 11:59 AM, Chris Pearce <cpea...@mozilla.com> > wrote: > > > On Sunday, November 27, 2016 at 5:5

Re: W3C Candidate Recommendation: Performance Timeline Level 2

I had some patches posted in bug 1263722, but then I started working on other things, and I haven't been watching the spec in the mean time. I'll try to get the patches ready to land later next week, and I'll try to see if there are any relevant changes the spec has made that affect our

Start logging at runtime (Firefox 52)

Hi everyone, (I meant to send this mail a few weeks ago but forgot it in my Drafts folder.) With the landing of Bug 1303762 (Firefox 52), we now have a way for users to enable logging without restarting the browser, and without having to know what an environment variable is. We've added a new

Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

On 12 February 2016 at 17:11, Randell Jesup wrote: > >- You can click on each individual point to go to the WPT run and view > >the results in greater detail > > What does "run index" mean in the graphs? The values appear to be > sorted from best to worst; so it's

Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

On 11 February 2016 at 19:46, Eric Rahm wrote: > Really interesting project, is this currently Windows only? It would be > great if we could get memory usage as well. > > Judging by the UA string - Windows NT 6.1; WOW64 - and the fact that we can run IE tests, it seems this is

Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

TL;DR - Firefox does pretty well when compared to Chrome. The Presto project is a Mozilla platform initiative that intends to look into any performance differences between Firefox and other UserAgents in order to highlight areas that we should look into improving and to clear any prejudice that

Re: I think XUL overlays should also ignore query strings.

On 17 August 2015 at 20:06, Philip Chee philip.c...@gmail.com wrote: On 17/08/2015 02:56, Neil wrote: Philip Chee wrote: The first question that occurs to me is what is the rationale? Can we revisit this in 2015 to see if the original reason still holds? Back then ignoring the hash

Re: Using rust in Gecko. rust-url compatibility

On 6 May 2015 at 04:58, Doug Turner do...@mozilla.com wrote: On May 5, 2015, at 12:55 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu valentin.g...@gmail.com wrote: As some of you may know, Rust is approaching its 1.0 release in a couple

Re: Using rust in Gecko. rust-url compatibility

differences. On 1 May 2015 at 20:58, Gregory Szorc g...@mozilla.com wrote: On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu valentin.g...@gmail.com wrote: As some of you may know, Rust is approaching its 1.0 release in a couple of weeks. One of the major goals for Rust is using a rust library

Re: Intent to implement: TV Manager API

On 17 October 2014 06:09, Sean Lin se...@mozilla.com wrote: Summary: The TV Manager API provides a bunch of properties and operations to allow Web apps to acquire the information of TV channels and programs, as well as to manage the native TV modules (i.e., tuners) or the services. Bug:

Re: Intent to ship: resource timing

On 24 September 2014 12:08, James Graham ja...@hoppipolla.co.uk wrote: On 24/09/14 02:11, Valentin Gosu wrote: == Test coverage == dom/tests/mochitest/general/test_resource_timing.html dom/tests/mochitest/general/test_resource_timing_cross_origin.html There is also the w3c test, which

Intent to ship: resource timing

As of next week we intend to turn on resource timing. It has been developed behind the dom.enable_resource_timing pref. == Summary == The Resource Timing API allows web applications to access timing information for resources in a document. == Platform Coverage == Resource timing works on all