Accuracy of the list of Rust components in and around Firefox?

[Nicholas Nethercote]

Hi,

We have a list of Rust components at
https://wiki.mozilla.org/Oxidation#Rust_Components.

This list includes both components within Firefox and components "around"
Firefox, i.e. not shipped in Firefox but used for Firefox development or
services.

I'd like to know if this list is accurate and up-to-date. If you know about
any Rust components I would appreciate it if you could look at the list and
see if that component is listed accurately. If not, please feel free to
correct the list yourself, or let me know privately and I can update it.

Thank you.

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

Re: Intent to restrict to secure contexts: navigator.geolocation

[gordonjoe636]

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

Re: Intent to implement: CSS conic-gradient

[Jen Simmons]

I'm very glad we are doing this. It's one of the major CSS features missing 
from Firefox, but supported in most other browsers. So, excellent. Thanks.

On Sunday, February 16, 2020 at 5:46:55 AM UTC-5, Tim Nguyen wrote:
> Summary: CSS conic-gradients allow developers to specify gradients that
> start from a certain angle where color stops are placed around the
> circumference of a circle centered around a specified point.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=conic-gradients
> 
> Standard: https://drafts.csswg.org/css-images-4/#conic-gradients
> 
> Target Release: 75-76
> 
> Platform coverage: All, initially WebRender only (though it shouldn't be
> long until it's implemented for other backends)
> 
> Preference behind which this will be implemented:
> layout.css.conic-gradient.enabled,
> turned off by default until it's implemented outside of WebRender
> 
> DevTools bug: n/a, devtools could potentially add a gradient editor, but
> that's also applicable to linear/radial gradients
> 
> Other browsers: shipped since Chrome 69, Safari 12.1, Edge 79 and Opera 64
> 
> web-platform-tests:
> https://searchfox.org/mozilla-central/search?q=conic-gradient=false=false=testing%2Fweb-platform
> 
> Restricted to secure contexts: No, CSS features are usually not restricted
> to secure contexts
> 
> Is this feature enabled by default in sandboxed iframes?  Yes

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

PerDocs release

[Alex I.]

Hi everybody,

During December 2019 we released the first version of PerfDocs 
 
which initially verified if all the Raptor performance tests have a test 
description. Last week we (me [:alexandrui] and Gregory Mierzwinski 
[:sparky]) made another release that added the document generation feature.


PerfDocs 
 
was born for the need of having a centralized way for the test metadata 
(e.g. descriptions). It can be used with the command ./mach lint -l 
perfdocs and it has 2 steps: verification and generation (--fix ing). 
While the verification is performed by default, the generation requires 
passing the --fix optional argument. What it does is to search in the 
tree for any perfdocs directory that has certain content (2 files). The 
first content file is config.yml which holds the location of the 
framework's test manifests and the descriptions for the tests that are 
found by PerfDocs using the manifests. The second file that is provided 
in the folders, calledindex.rst, determines where/how the test 
information will be displayed in the mozilla source tree docs 
 (under Testing/Performance 
Testing) and lets users add extra framework information if needed. See 
here 
 
for an example folder with Raptor. You can find the documentation 
generated from that specification here 
.


One thing to note is the ./mach lint -l perfdocs linter will FAIL if any 
test/suite present in the framework manifest doesn't have an associated 
description (individual or pattern-matched). If there are no tests 
missing a description and all descriptions in perfdocs/config.yml are 
matching at least one test then the linting will pass. It will also let 
the user know if the documentation needs to be regenerated. When --fix 
is provided as an argument, then verification will be performed along 
with document (re-)generation. In the case of a linting failure, you 
will need to update config.yml.


Example:

Given tests: raptor-tp6-amazon-firefox, raptor-tp6-amazon-chrome, 
raptor-tp6-amazon-chromium and their -cold variants.


Individual matching:

raptor-tp6-amazon-firefox: "Warm desktop page-load performance test for 
amazon on firefox using WebExtension."


Pattern matching:

raptor-tp6-amazon: "Cold and warm desktop page-load performance tests 
for amazon on firefox, chrome, and chromium using WebExtension."



Many thanks to the perftest team who helped on reviewing this all along 
the way.


For any questions do not hesitate to contact us.


Alex

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

Re: Intent to prototype and ship: lazy load images

[Hiroyuki Birchill Ikezoe]

On Sat, Feb 15, 2020 at 4:48 AM Boris Zbarsky  wrote:

> On 2/6/20 5:26 PM, Hiroyuki Birchill Ikezoe wrote:
> > Is this feature enabled by default in sandboxed iframes?: no, as of now
> > there is no proposed flag to enable this feature in sandboxed iframes.
>
> But is it disabled by default there?  I would assume not, unless it's
> specifically gated on sandboxing state...
>

To be more precise, lazy loading is disabled in documents where scripting
is disabled.
Though I don't know the exact conditions where scripting is disabled, by
default lazy loading is disabled without `allow-scripts` keyword.

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

Re: Intent to Unship: in content

[Hiroyuki Birchill Ikezoe]

One caveat I should mention is that mobile viewport stuff (which is used in
RDM as well) relies on the fact that Document::IsTopLevelContentDocument
returns true.  The function actually returns true for the document of
``.  So please make sure it still returns true for the
replacement or add an equivalent function.

hiro


On Sat, Feb 15, 2020 at 4:48 AM Patrick Brosset 
wrote:

> Thanks Kris.
>
> Related to this: RDM (Responsive Design Mode, in DevTools) is one of the
> consumers of . We've been at work removing the
> dependency from RDM on this type of iframe, and are nearing the completion
> of the main bucket of work. By March this year, we should have a new, fully
> functional version of RDM that does not depend on .
> The "old" RDM will still be in the tree by this date and we might not have
> pref'd the new one on yet, but we'll be very close.
>
> A simple completion chart for this project can be found at
> https://arewefissionyet.com/devtools/ (under the RDM section).
> In bugzilla, the whiteboard flag fission-rdm-mvp tracks the project:
>
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=fission-rdm-mvp_id=15103084
>
> Patrick
>
> On Mon, Feb 10, 2020 at 9:46 PM Kris Maglione 
> wrote:
>
> >  in non-chrome documents has been unsupported
> > in production environments for some time. Maintaining support
> > for it in content processes has become increasingly difficult in
> > the light of Fission, to the point that we've decided it is time
> > to fully remove support. Since support is disabled by default,
> > and there is no user-visible way to enable it, there should be
> > no users in the wild. The only in-tree users are tests, which
> > will need to be updated by their owners or disabled.
> >
> > Bug 1614462 will track this work.
> >
> >
> > -Kris
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
> ___
> 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