Re: Intent to unship: Application Cache API

[Valentin Gosu]

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 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 the API for
> > Nightly and Early beta [2] followed by an eventual disabling and
> > removal in Release [3]. The  removal in Release is expected to happen
> > after Chrome's origin trial is completed [4].
> >
> > The risk associated with removing this API is slightly higher than
> > with disabling the storage from appCache due to the greater chance it
> > could cause JS exceptions to be thrown if websites don't check if the
> > API exists.
> > However, we have successfully unshipped this from insecure origins in
> > the past so we don't expect major issues.
> >
> > The current use stats for the window.applicationCache in Beta 86
> > (2021/01/25 - 2021/02/17) are as follows:
> > 018.91B (99.51%) - Not used
> > 1244.32M (0.49%) - Used
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1619673
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1677719
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1677718
> > [4] https://web.dev/appcache-removal/
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Application Cache API

[Valentin Gosu]

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 the API for
Nightly and Early beta [2] followed by an eventual disabling and
removal in Release [3]. The  removal in Release is expected to happen
after Chrome's origin trial is completed [4].

The risk associated with removing this API is slightly higher than
with disabling the storage from appCache due to the greater chance it
could cause JS exceptions to be thrown if websites don't check if the
API exists.
However, we have successfully unshipped this from insecure origins in
the past so we don't expect major issues.

The current use stats for the window.applicationCache in Beta 86
(2021/01/25 - 2021/02/17) are as follows:
018.91B (99.51%) - Not used
1244.32M (0.49%) - Used

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1619673
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1677719
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1677718
[4] https://web.dev/appcache-removal/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: FTP protocol implementation

[Valentin Gosu]

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 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]
> >
> > Are we also stopping advertising the capability to act as an ftp: URL
> > handler to operating systems? Currently, if I try to follow an ftp:
> > URL in Gnome Terminal, it tries to launch Firefox. Is that something
> > we advertise to Gnome or something that Gnome just knows and needs to
> > be patched to stop knowing?
>
> I /think/ this comes from the .desktop file, which in most cases, comes
> from the distro.
>

We have this bug on file:
https://bugzilla.mozilla.org/show_bug.cgi?id=1667468
We should definitely stop registering Firefox as an ftp handler.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: FTP protocol implementation

[Valentin Gosu]

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.mozilla.org/show_bug.cgi?id=1691890
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=333943#c66
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1574475

Thanks!


On Mon, 27 Apr 2020 at 13:40, Michal Novotny 
wrote:

> SFTP was never supported by Firefox.
>
> On 4/27/20 12:59 PM, nikunjbhat...@gmail.com wrote:
> > There is no information about sFTP in this page. Will sFTP work in
> Firefox? Or all FTP related functionality will be removed? Will users be
> able to list files and directories in Firefox from sFTP server?
> >
> > On Thursday, March 19, 2020 at 5:54:50 AM UTC+5:30, Michal Novotny wrote:
> >> We plan to remove FTP protocol implementation from our code. This work
> >> is tracked in bug 1574475 [1]. The plan is to
> >>
> >> - place FTP behind a pref and turn it off by default on 77 [2]
> >> - keep FTP enabled by default on 78 ESR [3]
> >> - remove the code completely at the beginning of 2021
> >>
> >> We're doing this for security reasons. FTP is an insecure protocol and
> >> there are no reasons to prefer it over HTTPS for downloading resources.
> >> Also, a part of the FTP code is very old, unsafe and hard to maintain
> >> and we found a lot of security bugs in it in the past. After disabling
> >> FTP in our code, the protocol will be handled by external application,
> >> so people can still use it to download resources if they really want to.
> >> However, it won't be possible to view and browse directory listings.
> >>
> >>
> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1574475
> >> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1622409
> >> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1622410
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Using MOZ_LOG for Rust code

[Valentin Gosu]

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 few things to keep in mind:

1. When parsing modules in MOZ_LOG, the ones containing :: are considered
to be rust modules, so those are the ones we enable logging for. So if you
want to log everything in a top module like neqo_transport, you will have
to specify it as neqo_transport::*

Example:
*MOZ_LOG=timestamp,sync,nsHostResolver:5,neqo_transport::*:5,proxy:5*

If you're logging things in a submodule for example neqo_transport::recovery
you don't need the ::* at the end, but if it's there it will still work.
So these are both accepted
MOZ_LOG=timestamp,sync,neqo_transport::recovery:5
MOZ_LOG=timestamp,sync,neqo_transport::recovery::*:5

2. Due to us setting the release_max_level_info feature messages logged
with debug! or  trace! will not show up in non-debug builds. The way we
fixed that for neqo code was to add a separate macro that logs regardless
of the release_max_level.
See 1611990  for more
info.

3. When using both MOZ_LOG and RUST_LOG, modules that are specified in
MOZ_LOG will not appear in RUST_LOG.

Please try it out and let me know if you run into any issues.

Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship AppCache

[Valentin Gosu]

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, in case
there's a critical use case for it (we could add an enterprise policy for
it, or re-enable it if needed) but that's unlikely to happen.
Starting with 79 we can start removing the code that backs appcache, such
as the old and slow .
The intention for now is to leave the dom property window.applicationCache
and the “OfflineResourceList” interface in place for the foreseeable future
in order to avoid websites breaking.

Note that appcache use is still very low [2].
Assuming Chrome keeps to their plan [3][4] they should also be disabling
this around the end of June.
As stated in the previous email, appcache is a progressive enhancement, so
removing it doesn't break the web.

Thanks!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1619673
[2]
https://georgf.github.io/usecounters/index.html#kind=page=OFFLINERESOURCELIST=beta=75
[3] https://www.chromestatus.com/features/6192449487634432
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=582750#c47

On Fri, 30 Aug 2019 at 00:30, Jonathan Kingston  wrote:

> I spoke to some folks who work on Chrome and they suggested because of
> their larger usage numbers there wasn't a concrete timeline that they were
> working towards, however they think there is an active plan to exchange
> appcache for service worker on some Google products they have which will
> aid in it's removal in the browser.
>
> Due to the code freeze we should increase all those version numbers by one
> in my original email, however I believe we should continue with this plan:
> - As our usage numbers are much lower.
> - Appcache is unique feature in that it's largely a progressive
> enhancement, so removing it doesn't break the web as a whole.
> - Removing this code is a bigger benefit to Firefox users from a
> performance and security standpoint.
>
> Thanks
>
> On Thu, Aug 22, 2019 at 2:45 PM Andrew Overholt 
> wrote:
>
> > It's been a long time coming :) Do you know if Chrome plans to drop
> > support, too?
> >
> > On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston 
> wrote:
> >
> >> The design of AppCache brings many problems to the web platform from a
> >> performance and security perspective. Service workers have long solved
> the
> >> same use cases as AppCache.
> >>
> >> Removal of this code would bring a large reduction of code and
> complexity
> >> that is largely unmaintained.
> >>
> >> History
> >>
> >> Four years ago, in Firefox 44, we marked the API as deprecated[1].
> >>
> >> Back last year in Firefox 62, we disabled insecure AppCache and Chrome
> >> followed suit[2].
> >>
> >> Safari 11.1 added support for Service Workers, which are a replacement
> >> technology [3].
> >>
> >> Metrics
> >>
> >> Chrome measures a few different metrics here which suggest 2.3%[4] of
> >> secure page loads attempt to use the document visible API whilst only
> >> 0.27%[5] actually use the offline cache.
> >>
> >> Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
> >> however we don’t have a distinct metric for the API usage.
> >>
> >> The last blocker for a removal was usage of AppCache by some Microsoft
> >> online products.  I’m enquiring into if this is still applicable and
> also
> >> want to ensure with this rollout plan that we don’t break these when the
> >> user has an online connection.
> >>
> >> Implementation
> >>
> >> Bug where the code will be implemented[7].
> >>
> >> Plan
> >>
> >>-
> >>
> >>In Firefox 70, Remove the previous preference
> >>“browser.cache.offline.insecure.enable” and related code, forcing all
> >> of
> >>the APIs to only ever be available over Secure Contexts despite user
> >>choice. Due to the insecure nature of insecure context AppCache it
> is a
> >>good time now to remove this fully.
> >>
> >>
> >>-
> >>
> >>Create a new preference that disables only the storage and use of
> >>AppCache data whilst permitting access to the dom property
> >>window.applicationCache and the “OfflineResourceList” interface.
> >>-
> >>
> >>   Disable access in Nighty and beta for 70 for two releases before
> >>   disabling for all other releases in 72.
> >>   -
> >>
> >>   Once storage is disabled in all releases:
> >>   -
> >>
> >>  Disable the API access in Nightly and beta via the existing
> >>  preference (browser.cache.offline.enable) in version 72.
> >>  -
> >>
> >>  Wait two releases and then disable in all releases in Firefox
> 74.
> >>
> >>
> >> This staged removal of AppCache is to reduce the risk of web
> compatibility
> >> issues of the API being accessible to page scripts. Despite the API
> >> presence it won’t have any ability to use the cache. We may 

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

[Valentin Gosu]

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/Chrome - in Blink 73
https://www.chromestatus.com/feature/4647328103268352

Bug to enable by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1602363

This is header is required for shipping Cross-Origin-Embedder-Policy
https://mikewest.github.io/corpp/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Valentin Gosu]

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/d1e33e3e11f559952d7d80e722d26a6cf5dd80ac/dom/xhr/XMLHttpRequestMainThread.cpp#1826-1828

Cheers!

On Sat, 14 Sep 2019 at 09:45, john.bieling--- via dev-platform <
dev-platform@lists.mozilla.org> wrote:

> I am working on a wrapper for nsIHttpChannel with the interface of
> MLHttpRequest. Mainly to be able to use the codeBbasePrincipal (or
> ContextPrincipal as it is called now I think) with XHR requests, but
> without authors having to rewrite their code.
>
> This is for Thunderbird Add-Ons, which still can access nsIHttpChannel.
>
> I am pretty far and it is working nicely.
>
> However, I was not able to find a place in the nsIHttpChannel
> specification, which I could map to
>
> XMLHttpRequest.overrideMimeType()
>
> Is there any option/requirement to manually overide the MimeType of
> responses received via a nsIStreamListener or a nsIStreamLoaderObserver.
>
> The wrapper is here, if you want to have a look:
>
> https://gitlab.com/jobisoft/CardBook/blob/Thunderbird67+/chrome/content/cardbookHttpRequest.js
>
> Thanks for any help,
> John
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NS_NewURI is now thread-safe

[Valentin Gosu]

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 scheme to Gecko you should do
> so in NS_NewURI in
> > nsNetUtil.cpp
>
> Here "special" is in the sense of "Parsed as anything other than a basic
> nsSimpleURI"?
>

That's absolutely correct.

nsSimpleURI is the default parser for unknown schemes, and at the moment it
has the downside of not having a hostname. So if need URIs of a certain
scheme to have a hostname, you probably need to add code to create the
correct type - probably an nsStandardURL.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

NS_NewURI is now thread-safe

[Valentin Gosu]

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 closed bug 922464
, which means nsIURI
can now be safely used and created on any thread via NS_NewURI. It also
means nsIProtocolHandler.newURI no longer exists, and if you want to add
any other special scheme to Gecko you should do so in NS_NewURI in
nsNetUtil.cpp

Most of the work happened in bug 1536744
. This unblocks work
to make make nsIPrincipal thread safe in bug 1443925
.
I've noticed there are some places that keep URIs around as strings. If
those strings are regularly used to create nsIURIs, I strongly encourage
you to do so from the beginning.

There is still work to be done in order to reduce the number of
implementations we have for nsIURI and resolve our incompatibilities with
the URL spec. Stay tuned.

Let me know if you uncover any issues, or if you have any questions.

Cheers!
-- 
Valentin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Valentin Gosu]

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 Priority
> Manager for Firefox Desktop on Nightly on Windows.
>
> The Process Priority Manager lowers the OS-level process priority for any
> content processes that host *only* background tabs. As soon as one tab in
> a content process is brought to the foreground, the priority is brought
> back to the normal level.
>
> This should allow foreground tabs to get more CPU cycles dedicated to
> them, which we hope will let users get more things done more quickly in
> those foreground tabs.
>
> The pref is holding on Nightly to help us shake out bugs. If you notice
> any, bug 1522879 
> is the right metabug to block.
>
> If you have questions or concerns, please respond to this thread on
> dev-platform (to centralize the conversation).
>

Do we know if this will impact video or audio playing in the background
tabs?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New CEnum enumeration type in XPIDL

[Valentin Gosu]

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 interfaces with
> lots of similarly named consts, that are usually passed around in C++ as
> uint32_t's, though sometimes we redefine them as enums in C++ too and then
> mix everything together. This can get extremely confusing, especially in
> situations involving multiple enums from multiple interfaces.
>
> Having run into this problem while doing docshell work, I talked to Nika
> about adding enums to XPIDL. With copious amounts of help from her since
> this is my first foray into the XPIDL parser, I've now managed to land a
> new type, called CEnums.
>
> CEnums are exactly what they sound like, c-style enums in XPIDL. For C/C++,
> they'll turn into enums on the Interface class type. In Javascript, they'll
> continue to be constants on the interface, and should not require any
> changes to code referring to the enum values. Enum member value assignment
> follows the C/C++ specs, where any unspecified value is incremented from
> the value of the previous enum member.
>
> There are examples of how CEnums look and work in our tests:
>
>
> https://searchfox.org/mozilla-central/rev/b096dcf0ea226af628fe03f7e7acb56a25853533/js/xpconnect/tests/idl/xpctest_cenums.idl
>
> https://searchfox.org/mozilla-central/rev/b096dcf0ea226af628fe03f7e7acb56a25853533/js/xpconnect/tests/components/js/xpctest_cenums.js
>
> https://searchfox.org/mozilla-central/rev/b096dcf0ea226af628fe03f7e7acb56a25853533/js/xpconnect/tests/components/native/xpctest_cenums.cpp
>
> Note that the type names differ between C++ and XPIDL. In C++, the enum
> name is the type, within in the interface class. When referring to the enum
> type in XPIDL, the format is [interface]_[enum], e.g.
> nsIXPCTestCEnums_testFlagsExplicit when passed as an interface method
> argument in xpctest_cenums.idl.
>
> I'll have the XPIDL MDN pages updated with this information soon.
>
> There is a metabug at https://bugzilla.mozilla.org/show_bug.cgi?id=1503630
> for converting const lists to CEnums.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: PerformanceServerTiming

[Valentin Gosu]

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, meaning we
>> are targeting Firefox 61.
>>
>> Chromium bug: https://bugs.chromium.org/p/ch
>> romium/issues/detail?id=702760
>>
>> This affects web-compat, since per our "restrict new features to secure
>> origins policy" the serverTiming attribute will be undefined on unsecure
>> origins.
>> There is a bug on the spec to address this issue:
>> https://github.com/w3c/server-timing/issues/54
>>
>> Link to the spec: https://w3c.github.io/server-timing/
>>
>
> What's the wpt test situation for this feature, and how do our results
> compare to other browsers?
>

The WPT tests pass when run over HTTPS:
https://w3c-test.org/server-timing/test_server_timing.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: PerformanceServerTiming

[Valentin Gosu]

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 new features to secure
origins policy" the serverTiming attribute will be undefined on unsecure
origins.
There is a bug on the spec to address this issue:
https://github.com/w3c/server-timing/issues/54

Link to the spec: https://w3c.github.io/server-timing/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: nsIURI implementations are now threadsafe

[Valentin Gosu]

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 implementations, and a bunch more
>> protocol handlers.
>>
>> https://github.com/valenting/gecko/wiki/Threadsafe-URIs-prog
>> ress#protocol-handler-implementations
>>
>
> I wonder if it would be worth adding something like:
>
> NS_ThreadsafeNewURI()
>
> That returns an error code if it detects that the URL does not match any
> of the threadsafe URL implementations.  This would allow code to try
> threadsafe parsing first and only fall back to a main thread bounce if its
> an oddball URL.  Right now we hardcode a bunch of http/https/nsStandardURL
> things in various places to accomplish this.
>
>

I think that's a pretty good strategy. It allows us to progressively move
things from nsIProtocolHandler.newURI to NS_ThreadsafeNewURI.



>
>>
>> On 26 March 2018 at 15:24, Ben Kelly <bke...@mozilla.com> wrote:
>>
>>> Do we have any plan to be able to use NS_NewURI() off-main-thread?  I
>>> thought that was included here, but I see now that it is not.  The initial
>>> URL parse OMT is important for truly being able to remove all our "bounce
>>> to the main thread for 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 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 them off the
>>>> main
>>>> thread.
>>>>
>>>> If you need to change a nsIURI, you should use the nsIURIMutator
>>>> interface
>>>> (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
>>>> <https://searchfox.org/mozilla-central/source/netwerk/test/g
>>>> test/TestURIMutator.cpp#22>
>>>> helper class (in C++).
>>>>
>>>> More info here:
>>>> https://wiki.mozilla.org/Necko/nsIURI
>>>>
>>>> If you find any bugs, make them block bug 922464 (OMT-nsIURI)
>>>>
>>>> I'd like to thank everyone who helped review the patches, especially
>>>> Honza
>>>> Bambas who reviewed most of my patches.
>>>>
>>>> Cheers!
>>>> ___
>>>> dev-platform mailing list
>>>> dev-platform@lists.mozilla.org
>>>> https://lists.mozilla.org/listinfo/dev-platform
>>>>
>>>
>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: nsIURI implementations are now threadsafe

[Valentin Gosu]

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

https://github.com/valenting/gecko/wiki/Threadsafe-URIs-progress#protocol-handler-implementations


On 26 March 2018 at 15:24, Ben Kelly <bke...@mozilla.com> wrote:

> Do we have any plan to be able to use NS_NewURI() off-main-thread?  I
> thought that was included here, but I see now that it is not.  The initial
> URL parse OMT is important for truly being able to remove all our "bounce
> to the main thread for 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 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 them off the
>> main
>> thread.
>>
>> If you need to change a nsIURI, you should use the nsIURIMutator interface
>> (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
>> <https://searchfox.org/mozilla-central/source/netwerk/test/g
>> test/TestURIMutator.cpp#22>
>> helper class (in C++).
>>
>> More info here:
>> https://wiki.mozilla.org/Necko/nsIURI
>>
>> If you find any bugs, make them block bug 922464 (OMT-nsIURI)
>>
>> I'd like to thank everyone who helped review the patches, especially Honza
>> Bambas who reviewed most of my patches.
>>
>> Cheers!
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: nsIURI implementations are now threadsafe

[Valentin Gosu]

On 23 March 2018 at 21:06, Ben Kelly <bke...@mozilla.com> wrote:

> This is so great.  Thank you!
>
> One question that comes to mind, though, is there any chance this could be
> uplifted to 60?  As we start doing more OMT nsIURI stuff its going to
> become difficult to uplift code to 60ESR.
>

Certainly doable.
Most of the code landed in 60. Only 5 bugs related to this were landed in
61, 1442239 <https://bugzilla.mozilla.org/show_bug.cgi?id=1442239>, 1442242
<https://bugzilla.mozilla.org/show_bug.cgi?id=1442242>, 1447190
<https://bugzilla.mozilla.org/show_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...@gmail.com>
> 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
>> 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 them off the
>> main
>> thread.
>>
>> If you need to change a nsIURI, you should use the nsIURIMutator interface
>> (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
>> <https://searchfox.org/mozilla-central/source/netwerk/test/
>> gtest/TestURIMutator.cpp#22>
>> helper class (in C++).
>>
>> More info here:
>> https://wiki.mozilla.org/Necko/nsIURI
>>
>> If you find any bugs, make them block bug 922464 (OMT-nsIURI)
>>
>> I'd like to thank everyone who helped review the patches, especially Honza
>> Bambas who reviewed most of my patches.
>>
>> Cheers!
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: nsIURI implementations are now threadsafe

[Valentin Gosu]

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 them off the main
thread.

If you need to change a nsIURI, you should use the nsIURIMutator interface
(in JavaScript - just call .mutate() on the URI) or the NS_MutateURI

helper class (in C++).

More info here:
https://wiki.mozilla.org/Necko/nsIURI

If you find any bugs, make them block bug 922464 (OMT-nsIURI)

I'd like to thank everyone who helped review the patches, especially Honza
Bambas who reviewed most of my patches.

Cheers!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Valentin Gosu]

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 have helped *this* case, but considering how
> useful https://dxr.mozilla.org/addons/ has been previously, the notion
> of there still existing out-of-tree XPCOM callers but them being dark
> matter code search-wise worries me.
>
> This was failing for quite some time, we kept ahead of the failures when
> firefox was radically changing this.
>
> I agree a test suite would help for these addons for stability going
> forward as maintaining this for containers was a hard task.
>
> I would like to re-iterate what Baku said, there was a log failure that
> wasn't picked up and was thought to be the failure. It however wasn't and
> the actual bug was in central impacting Nightly container users also.
>
> > If the file is needed for <56, why does it even run in 57 or 58?
>
> The code shouldn't run for those versions, there was an import for all
> versions which caused an error however didn't even prevent the rest of the
> file from loading which is used to make the embedded extension load.
>
> On Wed, Nov 15, 2017 at 4:31 PM, Kris Maglione 
> wrote:
>
> > On Wed, Nov 15, 2017 at 04:12:06PM +0200, Henri Sivonen wrote:
> >
> >> On Wed, Nov 15, 2017 at 3:16 PM, Andrea Marchesini
> >>
> >>> This is why we had this issue. It should not be impossible for a
> >>> 'standard'
> >>> webextension to generate such mess.
> >>>
> >>
> >> How many Mozilla-signed special extensions are there? Does an analog
> >> of https://dxr.mozilla.org/addons/ exist for searching their code? Is
> >> there a CI system testing that the continue to work?
> >>
> >
> > The situation is pretty bad at this point. Ideally, all XPCOM add-ons
> that
> > we support should run tests in treeherder on checkin, both for add-on
> > changes and m-c changes. But as of now, most system add-ons, Test Pilot
> > add-ons, and SHIELD studies are hosted on Github and do their own ad-hoc
> > testing, mostly using Node-ish testing frameworks.
> >
> > There's also no standard place to host or index all of this add-on code,
> > or even to get a list of what such add-ons exist. At one point, I asked
> for
> > all SHIELD add-ons to at least be hosted in the same Github organization.
> > The same should probably go for all other Mozilla-signed add-ons. That
> > would at least give us a single place to find any XPCOM add-on code that
> we
> > still support.
> >
> > In the mean time, though, as far as I'm concerned, the maintainers of
> > those add-ons are responsible for dealing with breakage that results from
> > not having in-tree tests and a standard place to search that code. If
> > you're removing legacy XPCOM functionality, all you should need to care
> > about is whether treeherder is green.
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Threadsafe URLs - MozURL

[Valentin Gosu]

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.
>
> What is the plan for these issues:
>
>   https://github.com/servo/rust-url/issues/163
>   https://github.com/servo/rust-url/issues/290
>
> I'm rather worried that no serious effort to align with the standard
> has taken place for close to two years. Quite a few things changed,
> especially in response to feedback from the implementations by Safari,
> Node.js, and jsdom. And also in response to work undertaken in
> Firefox.
>

This is indeed a concern, but from what I can tell the only barrier to
improving rust-url is finding the people to work on it. I intend to devote
some time to this in the next few weeks.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Threadsafe URLs - MozURL

[Valentin Gosu]

On 23 October 2017 at 16:30, Jeff Muizelaar <jmuizel...@mozilla.com> wrote:

> For the curious among us, what made nsIURI not thread safe in the first
> place?
>

One of the factors was that as an IDL nsIURI could also be implemented by
JS code in addons, which could only run on 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 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 to use the
> > URI in any way.
> >
> > A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper
> > for rust-url. While it's not yet ready to fully replace our existing URL
> > implementations, it's good enough to avoid using the hacks I just
> mentioned.
> >
> > For examples of how to use it go to the header file [1] or the gtests [2]
> >
> > Work is also under way to provide a threadsafe implementation of nsIURI
> > that we eventually hope to replace our other URI parsers, and to improve
> > the rust-url parser to be faster than our current nsStandardURL
> > implementation [3].
> >
> > [1] http://searchfox.org/mozilla-central/source/netwerk/base/MozURL.h
> > [2]
> > http://searchfox.org/mozilla-central/source/netwerk/test/
> gtest/TestMozURL.cpp
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1394906#c2
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Threadsafe URLs - MozURL

[Valentin Gosu]

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 to use the
URI in any way.

A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper
for rust-url. While it's not yet ready to fully replace our existing URL
implementations, it's good enough to avoid using the hacks I just mentioned.

For examples of how to use it go to the header file [1] or the gtests [2]

Work is also under way to provide a threadsafe implementation of nsIURI
that we eventually hope to replace our other URI parsers, and to improve
the rust-url parser to be faster than our current nsStandardURL
implementation [3].

[1] http://searchfox.org/mozilla-central/source/netwerk/base/MozURL.h
[2]
http://searchfox.org/mozilla-central/source/netwerk/test/gtest/TestMozURL.cpp
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1394906#c2
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIURI API changes - punycode domain names

[Valentin Gosu]

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 will from now on return punycode.
>>
>
> ​What do web pages do if they want to reflect a pretty URL into their
> page? Will everyone have to include script like https://stackoverflow.com/
> questions/183485/converting-punycode-with-dash-character-
> to-unicode#answer-301287 ?​
>
> ​Should decodeURI() do it automatically? Or with a new parameter? Some new
> function?
>

I don't know if changing decodeURI is the best course of action.
The URL spec used to have methods for domainToUnicode and domainToASCII,
but these were removed [1]. Perhaps it's time to revisit that decision.

[1]
https://github.com/whatwg/url/commit/2bd0f59b98024921ab90e628b7a526cca5abcb5f
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

nsIURI API changes - punycode domain names

[Valentin Gosu]

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 - GetAsciiSpec, GetAsciiHost, GetAsciiHostPort
ASCII (but preffable) - GetSpec, GetPrePath, GetHost, GetHostPort
pref is network.standard-url.punycode-host defaults to true

Bug 945240 changed the internal representation of nsStandardURL, and added
the pref to also reflect this change via the nsIURI API. Bug 1380617 flips
the pref, and also fixes the unit tests and several places in the UI that
relied on GetHost* returning UTF-8 strings.
This is a definite improvement in terms of web-compat. document.origin,
location.href, etc will from now on return punycode.
There are still places in the UI which need to be fixed, such as the
devtools (bug 1380932). If you come across something that should show the
unicode hostname, but instead shows punycode, please file a bug blocking
bug 1380617.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Actually-Infallible Fallible Allocations

[Valentin Gosu]

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 the top of the thread is here:
> http://searchfox.org/mozilla-central/rev/f0e4ae5f8c40ba742214e89aba3f55
> 4da0b89a33/netwerk/base/Dashboard.cpp#435
>
> Is Dashboard performance-sensitive?
>

Not really.
When I wrote the code I copied most of it from code automatically generated
by webidl.
Some things have changed in the meantime - such as fallible allocations -
maybe we should update to resemble something a human would write :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Race Cache With Network experiment on Nightly

[Valentin Gosu]

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. For users with slow spinning disks and a
low latency network, the result would be faster loads.

This feature is currently preffed off - network.http.rcwn.enabled
In bug 1366224, which is about to land on m-c, we plan to enable it on
nightly for one or two days, to get some useful telemetry for our future
work.

For any crashes or unexpected behaviour, please file bugs blocking 1307504.

Thanks!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=rcwn
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1366224
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Start logging at runtime (Firefox 52)

[Valentin Gosu]

I think the you can get around the issue by setting the
security.sandbox.content.level pref to 0 while you're debugging.

On 23 May 2017 at 08:32, Shih-Chiang Chien <sch...@mozilla.com> wrote:

> Which platform you're using? For windows it seems to be solved by
> https://bugzilla.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:59:27 AM UTC+13, Valentin Gosu wrote:
> > > 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 Logging section to about:networking. When a user
> > > encounters a bug, all they have to do is open that page, click on
> "Start
> > > Logging", reproduce the bug, then click on "Stop Logging" and upload
> the
> > > logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG env
> > > variables have been defined.
> > > The log modules are automatically set to the most common networking
> > > modules, but you may instruct the bug reporters to change them - just
> > tell
> > > them the string.
> > >
> > > This is very useful for bugs that are harder to reproduce once you
> > restart
> > > the browser.
> > >
> > > There are a bunch of improvements that we could make to the UI, so
> please
> > > feel free to send me your feedback and patches. Many thanks to Honza
> > > Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that
> helped
> > > with the implementation and review of this bug and its dependencies.
> > >
> > > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/
> > HTTP_logging?document_saved=true#Using_aboutnetworking
> >
> > This seems super handy, but I tried it out and it seems to only affect
> the
> > parent process, and not the sub-processes of Firefox?
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Candidate Recommendation: Performance Timeline Level 2

[Valentin Gosu]

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

On 9 December 2016 at 23:06, Boris Zbarsky  wrote:

> On 12/9/16 6:22 PM, L. David Baron wrote:
>
>>   Performance Timeline Level 2
>>   W3C TR draft: https://www.w3.org/TR/performance-timeline-2/
>>   W3C Editor's draft: https://w3c.github.io/performance-timeline/
>>   deadline: Tuesday, February 28, 2017
>>
>
> Has anyone on our end been tracking this work or implementing this?  In
> general, this is one of the specs we would be expected to implement, so we
> should make sure _someone_ looks at it
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Start logging at runtime (Firefox 52)

[Valentin Gosu]

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 Logging section to about:networking. When a user
encounters a bug, all they have to do is open that page, click on "Start
Logging", reproduce the bug, then click on "Stop Logging" and upload the
logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG env
variables have been defined.
The log modules are automatically set to the most common networking
modules, but you may instruct the bug reporters to change them - just tell
them the string.

This is very useful for bugs that are harder to reproduce once you restart
the browser.

There are a bunch of improvements that we could make to the UI, so please
feel free to send me your feedback and patches. Many thanks to Honza
Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that helped
with the implementation and review of this bug and its dependencies.

https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging?document_saved=true#Using_aboutnetworking
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Valentin Gosu]

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, next-best to
> next-best, etc?  Ah, and I see "sorted" undoes the sorting.
>

In the sorted version, it is the index of that run in the sorted array and
mostly meaningless.
The run index in the unsorted version is the index of the run in
chronological order, but the firstRun and repeatRun will share the same
index.


> I'd think displaying mean/median and std-deviation (or a bell-curve-ish)
> might be easier to understand.  But I'm no statistician. :-)  It also
> likely is easier to read when the numbers of samples don't match (or you
> need to stretch them all to the same "width"; using a bell-curve plot of
> median/mean/std-dev avoids that problem.
>

I also think it would be quite useful, but my knowledge of statistics is
pretty basic.
I tried to get the number of samples to match, but for a few domains that
didn't work. I assume there's a bug in my scripts.


>
> Thumbnails, or columns on the right for each selected browser with
> median (or mean), with the best (for that site) in green, the worst in
> red would allow eyeballing the results and finding interesting
> differences without clicking on 100 links...  (please!)  Or to avoid
> overloading the page, one page with graphs like today, another with the
> columns I indicated (where clicking on the row takes you to the graph
> page for that side).
>

What I noticed is that pages with lots of elements, and elements that come
from different sources seem to have a higher variability. So pages such as
flickr, with lots of images with various sizes, or pages that load various
ads.


>
> >--
> >Error sources:
> >
> >Websites may return different content depending on the UA string. While
> >this optimization makes sense for a lot of websites, in this situation it
> >is difficult to determine if the browser's performance or the website's
> >optimizations have more impact on the page load.
>
> Might be interesting to force our UA for a series of tests to match
> theirs, or vice-versa, just to check which sites appear to care (and
> then mark them).
>

I've tried it for a few domains and it didn't make much of a difference.
I'll try it for all the domains to see if there is a pattern we could make
out.


>
> Great!  It'll be interesting to track how these change over time as well
> (or as versions get added to the list).  Again, medians/means/etc may
> help with evaluating and tracking this (or automating notices, ala Talos)
>

I thought about doing this, but Talos is always using static content on a
local connection, whereas this goes over a real network which may vary
performance, and load real websites which may change content or optimize
for different situations. I expect it's useful for confirming certain
properties, such as if page loads are faster on Fx, Chrome or Nightly, and
by how much, but probably can't get results that make sense over a longer
period of time.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Valentin Gosu]

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 moment.
Unfortunately,  I don't think WPT tracks memory usage.


> Also just to clarify, this is WPT that runs on webpagetest.org with code
> from https://github.com/WPO-Foundation/webpagetest?
>

Yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Valentin Gosu]

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 may be caused by FUD or past performance differences
that are no longer true.

We've begun this project by doing a set of performance runs on
WebPageTest.com in order to compare Firefox's performance against Chrome on
the home pages of the Alexa 100 (the top 100 web sites worldwide). We've
made a visualization tool which plots all of the runs on a graph, so we may
easily compare them:

http://valenting.github.io/presto-plot/plot.html

- click on a domain link to see results for each site.
- you are able to view the results sorted or unsorted, or filter by the
browser version
- you can also compare metrics other than load time - such as speed
Index, number of DNS queries, etc
- you can also compare the browsers on several connectivity profiles
(Cable, 3G, Dialup)
- You can click on each individual point to go to the WPT run and view
the results in greater detail

---
Initial results:

The results consistently show that Firefox is faster than Chrome for both
of our major metrics (load time and speedIndex). On a majority of domains
Firefox is faster on both first loads and reloads. When we analyze 3G
connectivity runs, Firefox's speedup less substantial, and we encounter
additional domains where Chrome has an edge.

Dial up connectivity is a bit more difficult to analyze. Because of the
large size of most websites, browsers are unable to load the website within
5 minutes, or it might time out. Chrome seems to have more successful data
points, and faster loads on dial up, but it is difficult to reach a
conclusion based on a limited data set.

WPT also has Nightly builds - which default to e10s ON. The several data
points we have show similar performance to non-e10s builds (which is good,
considering Nightly builds have more checks and assertions)

---
Interesting metrics:

Load time - is measured as the time from the start of the initial
navigation until the beginning of the window load event (onload).

Speed Index - is the metric recommended PageSpeedTest.com. Speed index
measures how fast a page is displayed on screen. Details:
https://goo.gl/7ha6eE

Activity time - measured as the time from the start of the initial
navigation until there was 2 seconds of no network activity after Document
Complete.  This will usually include any activity that is triggered by
javascript after the main page loads.

For most metrics a lower score is better (faster).

--
Error sources:

Websites may return different content depending on the UA string. While
this optimization makes sense for a lot of websites, in this situation it
is difficult to determine if the browser's performance or the website's
optimizations have more impact on the page load.

Since we do not log onto any sites, the data here for sites which rely on
logins to display full data (Facebook, etc) are not representative of most
users' experience and will generally have a different (much more heavily JS
and XHR-based) profile in reality.

For several data sets we may observe a certain spike in the data points –
runs that take 3x-7x times longer than usual. This may be due to a number
of reasons: a higher load on the network in the data center, a higher load
on the VMs on which the browsers are running, or the fact that websites
serve variable content – different images, different ads.
It may be that some of the page loads don't load the website completely, or
encounter errors. WPT also saves a screenshot of the page, along with data
on all of the resources it loads, so we may look at really fast loads to
make sure they are complete.

WPT has a maximum load time of 5 minutes. Any page load that takes longer
than that will be recorded as a 0 – so while it may seem to load faster,
that is not the case. Other errors may also be recorded as a 0.

WPT only loads one tab page at a time, whereas the load time on a user's
may be affected by his activity in other tabs. e10s certainly helps in this
area.

We only tested the performance of the landing page. It would be possible to
simulate user activity and navigation once the landing page is loaded, but
for this we'd need to write separate scripts for each domain we test.

Location may be an issue, as the RTT to the server or the CDN may vary. All
of the tests we ran were made on the WPT datacenter in Dulles VA.

--

The stats are merely informative. All of the data is is publicly available
to anyone who has an inclination towards statistics.

Setup:
webpagetest.meteor.com - an api that returns a list of IDs in JSON
form, representing all the WPT tests run for a given domain (source and API:
https://github.com/valenting/webpagetest )

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

[Valentin Gosu]

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 or the search were equally complicated;
  nowadays ignoring the hash is relatively easy.

 Yes we now have a CloneIgnoringRef. How difficult is it to make a
 clone-ignoring-query? I mean for an experienced C++ developer and not a
 C++ Dummies like myself.


I don't know if this would solve the initial issue with XUL overlays, but
adding CloneIgnoringRef is definitely possible.
In the meantime, I think you can achieve the same result with the following
code:
nsCOMPtrnsIURL url = do_QueryInterface(uri);
url-SetQuery(EmptyCString());
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using rust in Gecko. rust-url compatibility

[Valentin Gosu]

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 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.
 
  Will this affect our ability to make nsStandardURL thread-safe?


Unfortunatelly this project does not make nsStandardURL thread safe. It is
only meant to prove Rust can be used in mozilla-central, and bring a little
extra safety to our URL parsing.


 
  Right now there are various things, mainly related to addons, that are
  forcing us to only use nsIURI on the main thread. However this is a
  major pain as we move more code off the main thread and as we do more
  IPC stuff.


This involves changing the API used to create and change URIs and would
probably require all the consumers of nsIURI to alter their code.


 
  We've made some, small, steps towards providing better addon APIs
  which would enable us to make nsIURI parsing and handling possible to
  do from any thread.
 
  Would this affect this work moving forward? Or would a Rust
  implemented URL-parser/nsIURI be possible to use from other threads
  once the other blockers for that are removed?


The rust code is meant to be a drop-in replacement for our current parsing
code. A thread safe URI implementation should be able to use the rust code
without any issues.


 Valentin, if you’re serious about this effort, lets start by collecting
 requirements of this rewrite.  Thread safety is important.  Compat and
 correctness (talk to Anne!).  Performance


Thread safety has been on Necko's wish list for a while now, but this
project isn't going to fix it.
Compatibility with our current implementation is my main concern.
Performance might also benefit from this project, as our current
implementation does multiple iterations to parse a URI. I expect a slight
improvement.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using rust in Gecko. rust-url compatibility

[Valentin Gosu]

Thank you all for your suggestions. Asserting on differences sounds good,
and I think we can annotate the crash report with a sanitized URL as well
(replace all of the alfanumerical characters with x?). Also running a
crawler on top250 should iron out most kinks.

The plan is to land this preffed off, and only build the module if the rust
compiler is available on the system.
As Gregory pointed out, it would be better if the new implementation was as
close as possible as the current Gecko parser, so we avoid any regressions.
The main goal here is to make our parser safer with little behaviour
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 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're making good progress. A
 WIP
 patch is posted in bug 1151899, while infrastructure support for the rust
 compiler is tracked in bug 1135640.

 One of the main problems in this endeavor is compatibility. It would be
 best if this change wouldn't introduce any changes in the way we parse and
 encode/decode URLs, however rust-url does differ a bit from Gecko's own
 parser. While we can account for the differences we know of, there may be
 a
 lot of other cases we are not aware of. I propose using our volunteer base
 in trying to find more of these differences by reporting them on Nightly.

 My patch currently uses printf to note when a parsing difference occurs,
 or
 when any of the getters (GetHost, GetPath, etc) returns a string that's
 different from our native implementation. Printf might not be the best way
 of logging these differences though. NSPR logging might work, or even
 writing to a log file in the current directory.

 These differences are quite privacy sensitive, so an automatic reporting
 tool probably wouldn't work. Has anyone done something like this before?
 Would fuzzing be a good way of finding more cases?

 I'm waiting for any comments and suggestions you may have.
 Thanks!


 Shipping *any* Rust component as part of Gecko is already going to be a
 long and arduous task. I think it makes sense for the first Rust component
 in Gecko to be a drop-in, behavior identical replacement. i.e. don't bloat
 scope to include behavior changes that could jeopardize the deliverable. It
 would be really unfortunate if we did all this Rust preparation work only
 to have the feature utilizing it backed out because of behavior differences.

 But this is a very high-level observation. I know others spent a lot of
 time figuring out what to Rust-ify first and URL parsing was eventually
 chosen. If you say it is the least risky part of Gecko to swap out, I trust
 that assessment.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: TV Manager API

[Valentin Gosu]

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:
  https://bugzilla.mozilla.org/show_bug.cgi?id=998872

 Link to standard:
  Currently no formal standard. Yet we've created a draft which has been
 primarily reviewed within Mozilla and discussed with some partners who are
 going to adopt B2G to some of their TV models.


 http://seanyhlin.github.io/TV-Manager-API/index.html


Samsung TV's also have a webapi to access various TV functions:
http://developer.samsung.com/samsung-web-api/technical-docs/TV-Control

I haven't personally used it, but it might have ideas that are worth
keeping in mind.
At first glance our API doesn't seem to touch any 3D functionality.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: resource timing

[Valentin Gosu]

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 presents some failures for all UAs
  because of bugs in the test.
  http://w3c-test.org/resource-timing/test_resource_timing.html

 If this test is buggy, have we submitted patches?


I have filed 3 bugs for the test:
https://bugzilla.mozilla.org/show_bug.cgi?id=1002855#c18
I intend to submit pull requests for this as soon as possible.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: resource timing

[Valentin Gosu]

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 platforms. An issue tracked in bug 1064706 is
that in e10s the performance.getEntries() will return an empty array.

== 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 presents some failures for all UAs
because of bugs in the test.
http://w3c-test.org/resource-timing/test_resource_timing.html

== Interop ==

Chrome and Opera have prefixed the webkitClearResourceTimings and
webkitSetResourceTimingBufferSize methods, and the
onwebkitresourcetimingbufferfull event handler.

== Links ==
http://www.w3.org/TR/resource-timing/
https://bugzilla.mozilla.org/show_bug.cgi?id=1002855

Thanks
-- 
Valentin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform