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 backin

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 disable

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 the pre

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] https://bugzilla.

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 release

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: * Blink/Chrom

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: https://searchfox.org/mozilla-central/rev/d1e33e3e11f5599

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 sc

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 Priori

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 interfa

Re: Intent to ship: PerformanceServerTiming

On 24 April 2018 at 22:44, James Graham 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, meaning we >> are targeting

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 "restrict

Re: PSA: nsIURI implementations are now threadsafe

On 26 March 2018 at 16:53, Ben Kelly wrote: > On Mon, Mar 26, 2018 at 10:47 AM, Valentin Gosu > wrote: > >> Yes, that is definitely something we want to fix, but not very >> straightforward. We have quite a few URI implementations, and a bunch more >> protocol handler

Re: PSA: nsIURI implementations are now threadsafe

de. > > On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu > wrote: > >> 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 >> consequenc

Re: PSA: nsIURI implementations are now threadsafe

g.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 > wrote: > >> Hello everyone, >

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 the

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 search wouldn't hav

Re: Threadsafe URLs - MozURL

On 23 October 2017 at 16:21, Anne van Kesteren wrote: > On Mon, Oct 23, 2017 at 4:01 PM, Valentin Gosu > wrote: > > A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper > > for rust-url. > > What is the plan for these issues: > > https://gi

Re: Threadsafe URLs - MozURL

; > On Mon, Oct 23, 2017 at 10:01 AM, Valentin Gosu > wrote: > > 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 t

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 t

Intent to ship: PerformanceNavigationTiming

As of the 25th of september I landed bug 1263722 which adds a PerformanceNavigationTiming entry to the existing performance API. The implementation had a few issues which were fixed in bug 1403926, which also puts this feature behind a pref: dom.enable_performance_navigation_timing Right now this

Re: nsIURI API changes - punycode domain names

On 9 August 2017 at 19:43, Daniel Veditz wrote: > On Wed, Aug 9, 2017 at 9:57 AM, Valentin Gosu > wrote: > >> This is a definite improvement in terms of web-compat. document.origin, >> location.href, etc will from now on return punycode. >> > > ​What do web p

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. > > The code Alexis cited at

Re: Race Cache With Network experiment on Nightly

On 24 May 2017 at 19:01, Nicolas B. Pierron wrote: > On 05/24/2017 03:36 PM, Valentin Gosu wrote: > >> 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

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. Fo

Re: Start logging at runtime (Firefox 52)

g.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 > wrote: > > > On Sunday, November 27, 2016 at 5:59:27 AM UTC+13, Valentin Gosu wrote: > &g

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 implementat

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 Lo

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 comparing best to best, nex

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 windows only at the

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 ma

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

On 17 August 2015 at 20:06, Philip Chee 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 or the

Re: Using rust in Gecko. rust-url compatibility

On 6 May 2015 at 04:58, Doug Turner wrote: > > > On May 5, 2015, at 12:55 PM, Jonas Sicking wrote: > > > > On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu > wrote: > >> As some of you may know, Rust is approaching its 1.0 release in a > couple of > >&

Re: Using rust in Gecko. rust-url compatibility

differences. On 1 May 2015 at 20:58, Gregory Szorc wrote: > On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu > 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 in

Using rust in Gecko. rust-url compatibility

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 in Gecko. The specific one I'm working at the moment is adding rust-url as a safer alternative to nsStandardURL. This project is still in its infancy, but we'r

Re: Intent to implement: TV Manager API

On 17 October 2014 06:09, Sean Lin 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: > https://

Re: Intent to ship: resource timing

On 24 September 2014 12:08, James Graham 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

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 pla