Re: Intent to unship: DTLS 1.0 for WebRTC

[Martin Thomson]

This is somewhat more aggressive than our plans for HTTPS.  The usage rate
is significantly higher (that's about 3x) and we don't have DTLS 1.3 yet,
though the spec is now close to publication.

On balance, this is still justifiable given the nature of this feature.

On Fri, Nov 8, 2019 at 5:29 PM Nils Ohlmeier  wrote:

> With the intent to unship TLS 1.0 and 1.1
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/8EFRYDR3N1c <
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/8EFRYDR3N1c>
> we don’t want to leave Firefox users left with the old DTLS 1.0 when using
> WebRTC.
>
> The latest draft on WebRTC security architecture (which soon going to be
> published as an RFC) requires all implementations to support DTLS 1.2
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#section-6.5
> <
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#section-6.5
> >
>
> In Firefox 71 we landed user prefs which enables developers to test their
> WebRTC services with DTLS 1.2 only.
>
> Chrome has announced to also turn off DTLS 1.0 for WebRTC in M81
> https://groups.google.com/forum/?utm_medium=email_source=footer#!topicsearchin/discuss-webrtc/dtls;context-place=searchin/discuss-webrtc/PSA$3A/discuss-webrtc/Dsq_14_WoUk
> <
> https://groups.google.com/forum/?utm_medium=email_source=footer#!topicsearchin/discuss-webrtc/dtls;context-place=searchin/discuss-webrtc/PSA$3A/discuss-webrtc/Dsq_14_WoUk
> >
>
> Last time when we measured DTLS 1.0 usage was 1.88% in Firefox 68 Beta
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2019-06-18_spill=0=__none__!__none__!__none___channel_version=beta%252F67=WEBRTC_DTLS_PROTOCOL_VERSION_channel_version=null=*=Firefox=0_by_value=0_keys=submissions_date=2019-03-10=0=0_submission_date=0
> <
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2019-06-18_spill=0=__none__!__none__!__none___channel_version=beta%2F67=WEBRTC_DTLS_PROTOCOL_VERSION_channel_version=null=*=Firefox=0_by_value=0_keys=submissions_date=2019-03-10=0=0_submission_date=0
> >
>
> We want to disable DTLS 1.0 in WebRTC together with TLS 1.0 and 1.1 in
> March 2020.
>
> Disabling DTLS 1.0 is tracked at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1506392 <
> https://bugzilla.mozilla.org/show_bug.cgi?id=1506392>
>
> Best
>   Nils Ohlmeier
>
> ___
> 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 Implement- Double-keyed HTTP cache

[Anne van Kesteren]

On Wed, Aug 21, 2019 at 7:40 PM Sebastian Streich  wrote:
> Estimated or target release: Firefox 70

The plan is to enable this on Firefox 72 Nightly to see if there's any
fallout that needs addressing. It will not ride the trains. This is
tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=1594004.

As network caches in general are a privacy and security concern, we're
tracking isolating all of them using the top-level origin in
https://bugzilla.mozilla.org/show_bug.cgi?id=1590107. If there are
further caches that could use such isolation, please do file a bug
blocking that bug.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: heading levels

[Anne van Kesteren]

Unfortunately, this was not a success (too many h1s got adjusted to be
h2s) so we've removed this code and abandoned this particular plan for
dealing with heading levels in HTML:
https://bugzilla.mozilla.org/show_bug.cgi?id=1590366.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Experimenting with JavaScript type safety in mozilla-central

[Greg Tatum]

I was getting ready to write up some updates, but was waiting for some of
my most recent type work to land. I'll go ahead since there is interest. So
far the experience of working in devtools/client/performance-new [0] has
been really positive. It's a bit challenging getting the TypeScript module
system to work with our variants of loaders, but I've made progress to get
it working in at least one our smaller folder. It will take a broader
effort to really teach TypeScript about Gecko, but it seems doable, and
seems like something that could be done as an incremental improvement.

The profiler front-end (which is on GitHub, and is profiler.firefox.com)
uses a different type system (Flow), and we've really leaned in hard to it
to trust that our code is working as expected using the type system. We've
been using Flow there for nearly 3 years. So far, TypeScript seems to be
able to do most all of the things that we've been relying on in
profiler.firefox.com, but inside of Gecko. I'm feeling a lot more confident
making changes to the code, and being able to understand the interfaces I'm
consuming while writing and reading code. In the next month or two we will
be heavily refactoring the profiler popup code, so hopefully the types will
help with that work, and let us move quicker.

Here are things I've gotten types working with:

 * Profiler popup panel
 * React Component (landing now)
 * A frame script, and its environment
 * JSM files
 * Test files (only locally so far)
 * DevTools module loading system
 * Somewhat hacky with Chrome.import, and Cc["module"] style imports.

So far I'm treating the rest of Gecko like it's a foreign world that I
can't touch. However, it should be possible to make the types work with
more "modules" in the rest of the codebase. For instance, I could see
teaching IDL files to spit out TypeScript declaration files and automating
some of this process.

As for the test runner, right now it's a simple command to run from the
terminal [1], but we could hook it into a mach command, and integrate it
with our try services. I did an experiment earlier to demonstrate that this
was feasible [2]. Right now, I'm mostly relying on in-editor hints, as VS
Code loads the config files by default, and provides in-editor hints [3]

I know from the folks talking about types earlier, we're definitely
interested in other teams adopting some TypeScript comments in their own
areas of the codebase, so we can gather more feedback. If anyone is
interested in experimenting, I'd be happy to help guide some initial setup.

Next, I believe we are planning on continuing to experiment with real code
in tree, and evaluate what the next steps look like, e.g. official mach
runners, and try server integration.

[0]:
https://searchfox.org/mozilla-central/source/devtools/client/performance-new
[1]:
https://github.com/mozilla/gecko-dev/blob/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/client/performance-new/typescript.md
[2]:
https://treeherder.mozilla.org/#/jobs?repo=try=201f27967c8c6f26c6a4430fb1307478769762f7=devtools=266879166
[3]: https://giphy.com/gifs/VJkwziVsCYGvOGNsv0







On Tue, Nov 12, 2019 at 2:13 PM Andreas Tolfsen  wrote:

> +gtatum
>
> Also sprach Dave Townsend:
>
> > A first experiment towards understanding this has just landed (
> > https://hg.mozilla.org/integration/autoland/rev/1dd081553a3a).
> Specifically
> > Greg Tatum has added TypeScript  type
> > annotations and configuration to the JavaScript code in the
> > devtools/client/performance-new directory.
>
> As mconley said, this really is great work!  Any step we can take
> to make using JavaScript safer should be applauded.
>
> We’d be interested in providing stronger type hints in the new
> remote protocol in development under remote/, as I understand
> adding types retroactively to existing code can be challenging.
>
> > For the time being the perf tools team will just be checking the types
> > locally before committing. This will give us an idea of the benefits on
> > real in-tree code without any impact outside of the team.
>
> Has any progress been made since to include this in our lint checks?
>
> If not, what instructions do I need for running the manual checks?
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[desktop] Bugs logged by Desktop Release QA in the last 7 days

[Mihai Boldan]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team in the last 7 days.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/y2atdpjj.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: Bookmarks & History
* RESOLVED WONTFIX - https://bugzil.la/1593968 - Bookmark dropdown is 
offset on New Tab page


Firefox: Disability Access
* NEW - https://bugzil.la/1593737 - No visible selection inside 
Permission panels with high contrast theme


Firefox: Menus
* RESOLVED FIXED - https://bugzil.la/1594025 - "This isn't a deceptive 
site..." hamburger menu item is unreadable


Firefox: PDF Viewer
* NEW - https://bugzil.la/1595083 - The mouse pointer disappears in 
presentation mode while using the inspect element feature


Firefox: Protections UI
* ASSIGNED - https://bugzil.la/1594662 - [RTL builds] The Celebration 
Toast banner is not displayed
* NEW - https://bugzil.la/1594663 - [RTL builds] The number of blocked 
trackers is not displayed correctly in the Privacy Panel
* NEW - https://bugzil.la/1595039 - [Win7] The upper part of the 
Celebration Toast notification has a lighter contrast


Firefox: Toolbars and Customization
* RESOLVED FIXED - https://bugzil.la/1595029 - Search text from the 
search bar in Customize menu is not centered


Core: Audio/Video: Playback
* NEW - https://bugzil.la/1594409 - [Windows] The video turns darker 
when interacting with the seekbar on linkedin.com


Core: DOM: UI Events & Focus Handling
* NEW - https://bugzil.la/1594045 - mailto button loads infinite number 
of tabs if firefox is set as default mail app


Core: Panning and Zooming
* NEW - https://bugzil.la/1595013 - Flickering scrollbar on a certain 
Windows 7 configuration on page with multiple scrollbars
* NEW - https://bugzil.la/1595064 - Displayed inconsistent zoom level 
between zoom level from pdf page and browser zoom controls


Core: Web Painting
* NEW - https://bugzil.la/1594011 - Partially translucent context menu 
when zoom level is increased on theme page


Core: Window Management
* NEW    - https://bugzil.la/1594037 - [Win]Firefox min-width not set so 
hover on buttons jumps out of view


DevTools: Console
* NEW - https://bugzil.la/1594406 - Inconsistent behavior when using 
browser console buttons


DevTools: Debugger
* NEW - https://bugzil.la/1594374 - Debugger - Log on Events 
text_description not centered with the button
* NEW - https://bugzil.la/1594382 - Debugger - Event listener section 
can be toggled after clicking on log on Events checkbox


DevTools: General
* ASSIGNED - https://bugzil.la/1594359 - DevTools can be shrinked past 
the point it's no longer visible


DevTools: Netmonitor
* NEW - https://bugzil.la/1594749 - Requests blocking - Blocked elements 
get reset if internal about: pages are accessed


Toolkit: Startup and Profile System
* NEW - https://bugzil.la/1594007 - Youtube playback doesn't work on a 
temporary install on a macOS


Toolkit: Video/Audio Controls
* NEW - https://bugzil.la/1595015 - Gray out the audio button for videos 
with audio disabled by default


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/thwtvln.


Regards,
Mihai Boldan


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

Re: Intent to prototype: re-enabling SharedArrayBuffer

[Anne van Kesteren]

On Thu, Aug 29, 2019 at 1:47 PM Anne van Kesteren  wrote:
> We might ship 1 and 2 on Nightly to see what kind of breakage that
> gives. A risky part of this plan is that folks will have to test for
> postMessage() rather than SAB support going forward.

Enabling the prototype on Nightly can be tracked using
https://bugzilla.mozilla.org/show_bug.cgi?id=1594748. It appears to be
on track for 72. (It will not ride the trains. There'll be an intent
to ship when that happens.)

We also created a non-Release preference
dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled
that can be used for playing with SharedArrayBuffer without requiring
these new HTTP headers to be set (you'll also need to enable
SharedArrayBuffer via javascript.options.shared_memory). (At some
point we probably need to create a more holistic strategy for our
various insecure preferences, that also involves DevTools.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Experimenting with JavaScript type safety in mozilla-central

[Andreas Tolfsen]

+gtatum

Also sprach Dave Townsend:

> A first experiment towards understanding this has just landed (
> https://hg.mozilla.org/integration/autoland/rev/1dd081553a3a). Specifically
> Greg Tatum has added TypeScript  type
> annotations and configuration to the JavaScript code in the
> devtools/client/performance-new directory.

As mconley said, this really is great work!  Any step we can take
to make using JavaScript safer should be applauded.

We’d be interested in providing stronger type hints in the new
remote protocol in development under remote/, as I understand
adding types retroactively to existing code can be challenging.

> For the time being the perf tools team will just be checking the types
> locally before committing. This will give us an idea of the benefits on
> real in-tree code without any impact outside of the team.

Has any progress been made since to include this in our lint checks?

If not, what instructions do I need for running the manual checks?

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

Announcing MozillaBuild 3.3 Release

[glob]

MozillaBuild 3.3 is a minor update to version 3.2 mostly focusing on 
updating a few of the bundled components to newer versions.

https://ftp.mozilla.org/pub/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe

Important changes since version 3.2:
* If Git is installed it will now be available to the MozillaBuild shell
* Removed nodejs
* Updated Python2 to version 2.7.16 and Python3 to version 3.7.4
* Updated emacs to 26.3
* Other updates to various included components.

Full Release Notes:
https://docs.google.com/document/d/1sIjCoqpRQqb-MbcZ7m6uLnlVSPh_CbQt2LfPYiqCfPc


-glob
--
glob — engineering workflow — moz://a

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

Re: Intent to Ship: Require user interaction for notification permission prompts

[Daniel Veditz]

You could, but we're making this change because our user studies show users
respond negatively to unexpected and unwanted prompts. If the users don't
associate their triggering interaction with a desire to accomplish the task
for which you're requesting permission they're still going to say "No" and
hate your site.

On Sat, Nov 9, 2019 at 2:25 PM  wrote:

> Let‘s assume that I want to show the notification prompt on my website as
> soon as possible. If I register event handlers for all click, tap, and key
> press events on the page, I should be able to trigger the notification
> prompt on the first such event from within the event handler, correct?
>
> In other words, I’m waiting for *any* interaction from the person (e.g.,
> clicking some text to select it, or a video play button, or a Like button),
> yes?
> ___
> 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 Implement and Ship: Make MOZ_QUIET the default, require opt-in for DOMWINDOW/DOCSHELL logs

[Eric Rahm]

This sounds great. Is there a reason we can't just use MOZ_LOG for the
docshell/domwindow logging?

-e


On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter  wrote:

> In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
> remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default.
> It will automatically be enabled in browser-chrome tests where it is
> needed. (It actually will no longer be possible to disable it when running
> those tests also.)
>
> Once this lands, MOZ_QUIET will no longer do anything, and if you want this
> output you will need to explicitly set a new env var.  (Current idea is
> MOZ_LOG_WINDOWS_DOCSHELLS but feel free to tell me what color for the
> bikeshed in phabricator, I have no preference.)
>
> I'm sending this before I finish the requested changes in phabricator to
> give folks an opportunity to raise objections; I hope to land it mid/late
> next week.
>
> -tom
> ___
> 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