Experimental Features in about:preferences

[Jared Wein (Mozilla)]

Hello,

The Firefox Preferences (about:preferences) is gaining a new section called
"Firefox Experiments" ("Nightly Experiments" on Nightly builds). This
section will list features that are in-development or otherwise awaiting
some kind of feedback before being enabled by default.

Experimental features can be displayed based on release channel (Nightly,
DevEdition, Beta, Release) and platform (Windows, macOS, Linux). This work
is based on FeatureGates[1] as implemented by the Normandy team.

As of bug 1648223 this work is now enabled by default in Firefox Nightly
builds, and may ship with Firefox 79 though could be held back to Firefox
80 if we want to get a larger list of experimental features.

If you have a feature that you would like wider testing of, please file a
bug in Firefox::Preferences and add your feature to
toolkit/components/featuregates/Features.toml. See the documentation[1] for
details on feature definitions. Bug 1648223 is on autoland now and includes
some updates to the documentation.

A new section, "Experimental Features", has been added to about:support to
list the state of the features to help with bug reports. Bug 1644544 is on
autoland to annotate crash-stats with the state of the enabled Experimental
Features and there is planned work to allow engineers to optionally disable
their features when in Safe Mode.

Thank you for reading this far. Please let me know if you have any
questions,
Jared

[1]
https://firefox-source-docs.mozilla.org/toolkit/components/featuregates/featuregates/index.html

-- 
Jared Wein
Staff Software Engineer, Firefox
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can someone give me the files for Firefox marketplace?

[Jeff Muizelaar]

The various pieces of source are linked to from here:
https://marketplace.readthedocs.io/en/latest/topics/overview.html

On Thu, Jun 25, 2020 at 9:50 PM <10alldayr...@gmail.com> wrote:
>
> I would like to make a firefox os clone but I don't have the marketplace. So 
> if any staff member of Mozilla could give me the files or open source them 
> that would benefit the community.:)
> ___
> 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 unship: TLS 1.0 and TLS 1.1

[yuhongbao_386]

> [6] https://sql.telemetry.mozilla.org/queries/64283#164115 shows values for
> Release, which puts TLS 1.0 between 0.46% and 0.68% depending on the time
> of week.  TLS 1.1 is virtually non-existent at 0.02%, we could have removed
> that already if it weren’t for the fact that this isn’t how TLS version
> negotiation works.
I just notice that this threshold seems to be low.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Can someone give me the files for Firefox marketplace?

[10alldayrblx]

I would like to make a firefox os clone but I don't have the marketplace. So if 
any staff member of Mozilla could give me the files or open source them that 
would benefit the community.:)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200624.1)

https://bugzil.la/1643821 : Add code to generate_conduit_data.pl to create an 
oauth2 client for Phabricator when used for development
https://bugzil.la/1645455 : Can't attach some text, 500 internal server error
https://bugzil.la/1646559 : Phabricator to BMO OAuth2 authentication fails to 
work properly due to CSP protections

David Lawrence
d...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Shutting down legacy Taskcluster deployment

[Chris Cooper]

Hey all,

You may recall that last fall we redeployed Taskcluster into two
distinct clusters, one to support Firefox CI and another to handle
Community projects[1]. We left the legacy deployment running to
provide access to CI artifacts that would only be reachable via the
old taskcluster.net interface.

It turns out that we (Mozilla) don't access the legacy data very
often: we are storing close to a petabyte of older artifacts in AWS
and yet we access less than 25 GB of it. It costs us thousands of
dollars every month for that storage, and several hundred dollars more
to continue running the services to access it, so we've made a
decision to decommission the legacy Taskcluster deployment a few
months earlier than planned.

We'll be shutting down the legacy services on July 3rd, 2020. That's
one week from today. A week later on July 10, we will begin deleting
the old artifacts.

If you are one of the few individuals who does access artifacts from
the legacy cluster and haven't already spoken to us about
alternatives, please reach out before next Thursday.

Note: this will *not* affect day-to-day CI on either the Firefox CI or
Community clusters at all.

Thanks,
--
Chris Cooper
Manager, Taskcluster @ Mozilla


1. https://groups.google.com/g/mozilla.dev.platform/c/QhZFDhlQjxU/m/ngk8z6j1AgAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship : HTML5 element (Nightly Only)

[Sean Feng]

Yeah, agreed.

I just filed https://github.com/whatwg/html/issues/5678 for moving the
focus back to what had focused before when the dialog is dismissed.

On Wed, Jun 24, 2020 at 4:19 PM James Teh  wrote:

> While this doesn't need to block shipping in Nightly, I think we should
> consider advocating for the focus behaviour to be changed (and changing it
> in Firefox if we can get it into the spec) before we ship to release.
>
> The currently specified behaviour (and what both Firefox and Chrome
> implement) is to focus the first focusable element in the dialog. However,
> there are a few major problems with this, including:
> 1. This means a tabindex="-1" element could get focus, which is focusable
> but not in the tab order. That's particularly strange if this gets focus in
> preference to something which *does* participate in the tab order.
> 2. The first focusable element could be a long way down the page; e.g. a
> dialog with a lot of preamble text and a form field or button after that
> text. That is particularly problematic for screen reader users because that
> will direct their reading cursor to the focused control, so they will
> potentially not realise they're missing content above it. It might even
> cause the page to scroll visually.
>
> What I (and others in the accessibility community) am proposing is that
> the dialog element itself should get focus, unless something within the
> dialog has autofocus set, in which case we should focus that. There's a
> spec issue for this, but it stalled:
> https://github.com/whatwg/html/issues/1929
>
> Another concern is that when the dialog is dismissed, focus gets thrown
> back to the document. Instead, I think it should be returned to the element
> which had focus before the dialog was shown, which is the recommended
> pattern for good accessibility of dialogs. I don't think there is a spec
> issue for this yet.
>
> Jamie
>
> On Thu, Jun 25, 2020 at 6:04 AM Sean Feng  wrote:
>
>> Intent to Ship (Nightly Only) : Dialog Element
>> ​
>> Hi All,
>> ​
>> In bug 1645046 , I
>> intend to turn html5  element on by default in Nightly. It has
>> been developed behind the dom.dialog_element.enabled preference.
>> ​
>> Meta Tracking Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>> ​
>> This is Nightly only because two things needs adjustment in our
>> implementation.
>> ​
>> 1. The inert element isn't supported (bug 921504 -
>> https://bugzilla.mozilla.org/show_bug.cgi?id=921504).
>>
>>   - For modal dialog, elements that are not part the dialog should be
>> mark as inert, so these elements gain the inert-ness and can't be
>> focused. Since we don't have inert supported yet, users could use tab to
>> move focus out of the dialog, which is not expected.
>>
>>   - Next Step: The implementation of inert element is going to be
>> started soon (I think), and we can also discuss to support the
>> inert-ness without the supporting of inert element
>> ​
>> 2. We currently use a temporary solution for the layout of modal dialog.
>> (bug 1637310 - https://bugzilla.mozilla.org/show_bug.cgi?id=1637310).
>>
>>- Currently the spec defines modal dialog as an absolute element,
>> along with some weird calculation requirement to make the element
>> centered. This modal dialog layout felt like a hack to us, so we didn't
>> follow it, and instead, we used a temporary solution
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1642364) to make the modal
>> dialog as a centered fixed element.
>>
>>- Next Step: The CCSWG agreed to switch modal dialog to be a centered
>> fixed element
>> (https://github.com/w3c/csswg-drafts/issues/4645#issuecomment-642130060),
>>
>> which is the same as the temporary solution we applied in bug 1642364.
>> So the temporary solution may become a permanent solution after things
>> have been finalized in spec.
>> ​
>> *Status in other browsers*
>> Chrome has it enabled by default since Release 37
>> https://www.chromestatus.com/feature/5770237022568448
>>
>> *web-platform-tests*:
>>
>> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/interactive-elements/the-dialog-element,
>>
>> We have them all enabled and passing except for those layout and inert
>> related ones.
>>
>> *Spec* - https://html.spec.whatwg.org/multipage/#the-dialog-element
>>
>> This feature was previously discussed in
>>
>> https://groups.google.com/d/msg/mozilla.dev.platform/vTPGW1aJq24/JnEnoH3BEAAJ
>>
>> ___
>> 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: Please don't use functions from ctype.h and strings.h

[Henri Sivonen]

On Wed, Jun 24, 2020 at 10:35 PM Chris Peterson  wrote:
>
> On 8/27/2018 7:00 AM, Henri Sivonen wrote:
> > I think it's worthwhile to have a lint, but regexps are likely to have
> > false positives, so using clang-tidy is probably better.
> >
> > A bug is on file:https://bugzilla.mozilla.org/show_bug.cgi?id=1485588
> >
> > On Mon, Aug 27, 2018 at 4:06 PM, Tom Ritter  wrote:
> >> Is this something worth making a lint over?  It's pretty easy to make
> >> regex-based lints, e.g.
> >>
> >> yml-only based lint:
> >> https://searchfox.org/mozilla-central/source/tools/lint/cpp-virtual-final.yml
> >>
> >> yml+python for slightly more complicated regexing:
> >> https://searchfox.org/mozilla-central/source/tools/lint/mingw-capitalization.yml
> >> https://searchfox.org/mozilla-central/source/tools/lint/cpp/mingw-capitalization.py
>
>
> Bug 1642825 recently added a "rejected words" lint. It was intended to
> warn about words like "blacklist" and "whitelist", but dangerous C
> function names could easily be added to the list:
>
> https://searchfox.org/mozilla-central/source/tools/lint/rejected-words.yml
>
> A "good enough" solution that can find real bugs now is preferable to a
> cleaner clang-tidy solution someday, maybe. (The clang-tidy lint bug
> 1485588 was filed two years ago.)

Thanks. Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1648390

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform