Intent to ship: "JS BigInt to I64 integration" WebAssembly proposal

[Asumu Takikawa]

# Intent to ship: "JS BigInt to I64 integration" WebAssembly proposal

This feature allows I64 values in WebAssembly to be exported to JavaScript
as a BigInt value, or imported from JS from a BigInt.

With this proposal implemented, all four value types in the WebAssembly MVP
can be passed through the Wasm<->JS boundary, allowing for easier
interoperation between the languages.

## Tracking bugs

Implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1608770
Shipping: https://bugzilla.mozilla.org/show_bug.cgi?id=1631702

## Standard

https://github.com/WebAssembly/JS-BigInt-integration

https://webassembly.github.io/JS-BigInt-integration/js-api/index.html

The proposal very recently entered "phase 4" in the WebAssembly
standardization process:

  https://github.com/WebAssembly/meetings/blob/master/2020/CG-05-12.md

## Platform coverage

All

## Devtools support

N/A. BigInts are displayed fine in the debugger.

## Restricted to secure contexts

No.  (Not a worry as no additional capabilities granted.)

## Is this feature enabled by default in sandboxed iframes?

Yes.  (Not a worry as no additional capabilities granted.)

## Estimated or target release

78 (soft freeze 28 May, train leaving 1 June)

## Support in other browser / JS engines

Chrome / V8 implements the proposal.  Staged in September 2019, not
shipped yet: https://bugs.chromium.org/p/v8/issues/detail?id=7741

Support in emscripten: https://github.com/emscripten-core/emscripten/pull/10860

## Upstream test coverage

There are good tests in the proposal repository, which are not merged upstream
into WPT yet but likely will be in the near future:

  https://github.com/WebAssembly/JS-BigInt-integration/tree/master/test

## Where to send your bugs

Asumu Takikawa (:asumu).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing the XUL grid implementation

[Philipp Kewisch]

Also a big thanks to the Thunderbird team on pushing forward to make the 
platform more modern. Great work everyone!

Philipp 

> On 24. Apr 2020, at 8:15 PM, Jared Wein (Mozilla)  wrote:
> 
> 
> Congrats! This is a major accomplishment and required a lot of work. Nice job 
> to all!
> 
>> On Fri, Apr 24, 2020 at 1:34 PM Tim Nguyen  wrote:
>> Hello folks,
>> 
>> After a year of work, all XUL grid usages have been removed from Firefox! 
>> The Thunderbird team also has been doing a lot of hard work on their side.
>> 
>> This means the XUL grid implementation can now be removed: 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1525737
>> 
>> I'm planning to remove the XUL grid implementation at the beginning of the 
>> Firefox 78 cycle to leave time to address potential regressions from the 
>> last removal and for the Thunderbird team to remove their last usage.
>> 
>> Thanks to everyone who reviewed my grid removal patches and to Daniel 
>> Holbert and Emilio Cobos Àlvarez for the platform work that made this 
>> possible!
>> 
>> Please let me know if you have any questions or concerns.
>> 
>> Cheers,
>> Tim
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
> 
> 
> -- 
> Jared Wein
> Staff Software Engineer, Firefox
> Mozilla Corporation
> ___
> 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

Firefox Security Newsletter - 2020 Q1

[Frederik Braun]

Firefox Security & Privacy Newsletter 2020-Q1

Here comes our second edition of the Firefox Security & Privacy Newsletter.

The shareable link for this newsletter and the back issues is at
https://wiki.mozilla.org/Firefox_Security_Newsletter. This link also
promises readable and stable markup across transports ;-)

Note: Some of the bugs linked below might not be accessible to the general
public and are still restricted to specific work groups. We de-restrict
fixed security bugs after a grace-period
,
until the majority of our user population have received their updates. If a
link does not work for you, please accept this as a precaution for the
safety of all of our users.
Privacy

Preventing tracking and online surveillance

The Anti-Tracking team shipped fingerprinting protections

as part of the Firefox 72 release. This is following a long period of
evaluating
and fixing website breakage
, so it’s a big
milestone for the team.

Erica landed our initial implementation of purging tracking cookies
 in Nightly. This
will enable ETP to better protect against so-called bounce trackers that
track users through first-party redirections.

The first pieces of dynamic first-party isolation
 (DFPI) landed in
Nightly. DFPI is an experimental approach to isolating all third party
cookies and storage, similar to FPI (which is enabled by default in the Tor
Browser and is also supported by Firefox). The most important difference
between DFPI and FPI is that DFPI will adhere to exceptions granted through
the storage access API and thus ensure better web compatibility.

Se-Yeon implemented versioning

for our Shavar blocklists that power Enhanced Tracking Protection (ETP),
Fingerprinting and Cryptomining protections.
Core Security

Securing/hardening the Firefox Platform

Freddy started enumerating flags and prefs that would dramatically reduce
Firefox security. We’re collecting and removing them one by one to kill
exploit chains that require just a single-byte overwrite in bug 1602485
. First patches have
already landed, kudos to volunteer Masatoshi Kimura [:emk] for his
excellent work!

This January, Security Researchers from Qihoo 360 ATA identified an active
attack against Firefox users. With their test case and great help from the
JavaScript team we could ship a security release as Firefox 72.0.1
 on the
next day. Kudos to our Engineers, Release Managers and Security staff for
jumping on this issue so quickly!

We’ve also made some progress to hinder patch gapping. We know that
attackers frequently watch commit logs of popular open source software to
find vulnerabilities that have been fixed but not yet shipped to our end
users. Minimizing this gap has long since been part of our practices for
fixing security bugs in Firefox
.
To help leak data and metadata about security vulnerabilities, Tom has
implemented a hook for hg.mozilla.org
 that disallows
pushing patches for security bugs to Continuous Integration. Furthermore,
Bugzilla has also started hiding security bugs in dependency and regression
fields if a user does not have access (bug 1591549
), but more to come.

The Firefox site isolation project “Fission” is almost ready for testing in
Firefox Nightly. There are some known issues with mixed content blocking
, but you can enable
fission  by
setting the prefs “fission.autostart” and “gfx.webrender.all” to true.

Bugs worth highlighting:

We removed a very, very old testing API called enablePrivilege
, that gave normal
web pages extra privileges beyond Web APIs. The API was used in exploit
chains and made attacks easier than they should have been.

Firefox is no longer going to use ShellExecuteByExplorer
 when launching
executable files in the download folder, this helps protect against
attackers placing malicious DLLs in the same folder.

Folks from the JS team have disabled JIT optimizations for JavaScript in
Proxy Auto Configuration (PAC)
 files as they are
currently run in the parent process.

Gecko Web Platform Update (2020-05-15)

[Mike Conca]

In an effort to work more openly and foster cross-functional communication,
the Gecko Web Platform Product Team is going to make an effort to send out
bi-weekly updates covering the major component areas. These updates will be
very brief, please reach out if you have any questions.


   -

   Accessibility [Asa Dotzler]
   -

  Updated accessibility triage plan
   to account for new
  Bugzilla triage guidelines.
  -

  Discussion of forced-color-adjust
   with heycam,
  jteh, and sean.
  -

  MacOS a11y work
  
  progressing. Refactoring and basic VoiceOver support. Mac progress
  blog
  

  posted.
  -

  Experiment to switch to lazily turning a11y services on/off when
  using accessibility panel landed
  -

   Layout [Martin Balfanz]
   -

  Printing: Meeting with desktop team, clarifying on different work
  streams and decided next steps + owners
  -

  Discussing SVG in Powerpoint
   issues.
  -

   Graphics [Martin Balfanz]
   -

  Jessie prepared a WebRender-until-end-of-year overview for Desktop
  -

   Media [Adam Stevenson]
   -

  Web Audio Worklets shipped in Firefox 76. Read about the technical
  details in our blog post
  

  .
  -

  Work continues to make improvements to WebRTC in Firefox, supporting
  work from home use cases.
  -

 Transport-CC and RTX have landed in Firefox, two features
 requested by Jitsi and other services.
 -

   DOM [Adam Stevenson]
   -

  Google Sheets bug
   fix should be
  deployed now
  -

   Workers and Storage [Adam Stevenson]
   -

  Planned for Fx 78: Ship SharedArrayBuffer (and atomics) to Release
  
  -

 I.e., globalThis.Atomics, WebAssembly.Memory({ shared:true, ...
 }), and with globalThis.SharedArrayBuffer returning undefined.
 -

  Planning to enable Service Workers for ESR78
  
  -

   JavaScript [Mike Conca]
   -

  Program review of SmooshMonkey completed
  -

  Hoping the new RegExp engine
   lands and
  sticks in 78 Nightly
  -

   WebAssembly [Mike Conca]
   -

  SIMD x86 support landing in 78 Nightly for baseline
   and Ion
   backends
  -

  Multi-value  is
  riding the trains to 78
  -

   Networking [Mike Conca]
   -

  Plan to start rollout SameSite=lax change in Beta 79
  -

  Lots of progress on preload


Mike Conca
Group Product Manager, Firefox Web Technologies
___
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/y7qogtfb.
Bugs logged by Desktop Release QA in the last 7 days:

Firefox: Address Bar
* NEW - https://bugzil.la/1638275 - The search panel one offs container is
not hidden after removing several search engines

Firefox: Installer
* RESOLVED FIXED - https://bugzil.la/1637285 - In high contrast mode stub
installer progress bar shows 10% even with internet connection disabled
* RESOLVED WONTFIX - https://bugzil.la/1637294 - Tab key selector has white
dotted lines instead of black dotted lines

Firefox: New Tab Page
* NEW - https://bugzil.la/1637598 - The card is not dismissed after it's
archived to pocket and the browser is restarted

Firefox: Security
* NEW - https://bugzil.la/1637170 - Confirm Auth prompt is not displayed if
the tab is duplicated

Firefox: Toolbars and Customization
* NEW - https://bugzil.la/1637574 - Flexible space is wrongly positioned in
Customize menu after dragging the Search bar on the left side

Core: DOM: Core & HTML
* NEW - https://bugzil.la/1638318 - [e10s] Unable to paste images from
drive in imgur

Core: Graphics: WebRender
* NEW - https://bugzil.la/1636856 - Flashing lines while zooming inside
windy.com website
* NEW - https://bugzil.la/1637876 - Animations are very laggy while
scrolling on Kaipoche site (NSFW)

Core: Layout: Scrolling and Overflow
* NEW - https://bugzil.la/1637861 - Location names on JetLag site are cut
off

Toolkit: Notifications and Alerts
* NEW - https://bugzil.la/1636897 - [Ubuntu] The Insecure Form Submit
prompt is NOT correctly displayed after resizing the browser
* NEW - https://bugzil.la/1636949 - While resizing the text is too close to
the scroll bar in Tab Modal Prompts
* NEW - https://bugzil.la/1636950 - The scroll thumb disappears in Tab
Modal Prompts while resizing the browser
* NEW - https://bugzil.la/1637187 - [Ubuntu] The Auth Required prompt is
resized on all the screen (even if the browser window is minimized)

DevTools: Console
* NEW - https://bugzil.la/1637883 - [Instant Evaluation] Firefox becomes
unresponsive after using an infinite loop twice while visiting about:config
page

DevTools: Inspector: Compatibility
* NEW - https://bugzil.la/1637535 - Compatibility panel - Settings close
[x] button has double focus rings applied on tab-select

This is available as a Bugzilla bug list as well:
https://tinyurl.com/y98z7hlg.
Regards,
Mihai Boldan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

ESNI + webproxy not working: nsSocketTransport::ResolveHost()

[Amritanshu]

Hello Firefox-Dev,
I hope this the right place to ask this query?

I am trying to make ESNI work with a web-proxy, what I am observing is that
although the tunnel is TLSv1.3 the SNI is still going in plain text. While
looking at logs for the bad case and based on the very limited
understanding I could build about the code here is what I was able to
conclude.

In nsSocketTransport::ResolveHost() (where we also compute the ESNI keys),
the problem is on Line number 1080 where esniHost.Append(SocketHost()); it
ends up picking the ProxyAddress instead of the host see[0],  ultimately
leading to a lookup for _esni.127.0.0.1 or whatever is there in the proxy
instead of _esni.some.encryptedsnihost.com in the DNS cache.

Looking up ESNI for the proxy is bad for multiple reasons, best case the
ESNI keys are not found and the TLS tunnel is "degraded" but in the worst
case, the proxy itself has an ESNI key present, where the TLS HELLO packet
gets encrypted with the wrong key.

Probably, there is more to it. Let me know what you think?
TIA,
Amritanshu

[0]
https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsSocketTransport2.h#308
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Additions to ResultExtensions.h and mozilla::Result

[Simon Giesecke]

Hi,

as part of https://bugzil.la/1637605 I recently made some additions to
the mozilla::Result integration available from
mozilla/ResultExtensions.h.

It adds several overloads of a ToResultInvoke function template, which
kind of combines ToResult and std::invoke. It allows to call a XPCOM
style function with a nsresult return value and an output parameter of
type V as the last parameter, and adapts that to returning a
mozilla::Result instead. (Note that not all functions
with nsresult return type adhere to this convention, and those cannot
be used with ToResultInvoke. Also, functions with multiple output
parameters are not yet supported.)

The examples below make use of auto, but of course you can also
explicitly specify the resulting type explicitly.

The general version requires specifying the return type explicitly, e.g.

auto res = ToResultInvoke(, objectStoreName);

The result type is mozilla::Result then.
Functions without an output parameter will adapt to
mozilla::Result.

For member functions, a simplified syntax is available that also
allows deduction of the success type V:

auto res = ToResultInvoke(file, ::Exists);

which yields a res of type mozilla::Result.

This also works for polymorphic output parameters and returning a nsCOMPtr, e.g.

auto res = ToResultInvoke>(NS_NewLocalFile, name, true);

However, this doesn't work (yet) with the simplified syntax for member
functions but requires using std::mem_fn in that case:

auto res =
  ToResultInvoke>(
std::mem_fn(::Open), channel);

E.g. this can be used in connection with mozilla::Result::andThen to
compose a sequence of calls.

You can find more example uses in mfbt/tests/gtest/TestResultExtensions.cpp

If you have any questions or suggestions about this, please let me know.

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

Re: Cargo.lock in hg repository?

[ISHIKAWA,chiaki]

I have rebased and the changes are gone.

Thank you for keeping the tree in good shape.

Chiaki

On 2020/05/19 18:35, Emilio Cobos Álvarez wrote:

On 5/19/20 3:11 AM, ISHIKAWA,chiaki wrote:
Thank you for the feedback. So I am not alone in seeing this. I will 
ignore the anomaly for now although there are a few strange local 
changes due to this now.


You shouldn't see it anymore if you rebase:

  https://hg.mozilla.org/mozilla-central/rev/6db4b71d0c20

 -- Emilio



Chiaki

On 2020/05/18 1:08, Emilio Cobos Álvarez wrote:
I see this too, I think it's a rebase messup between bug 1631630 and 
bug 1636068.


 -- Emilio

On 5/17/20 2:44 PM, ISHIKAWA,chiaki wrote:

I am developing TB patches locally on my linux PC.

Have anyone noticed mozilla/Cargo.lock seems to be in mercurial 
repository and that it got updated

during development?
That is, as far as *I* am concerned, I never tough it directly.
But, it seems |mach clobber|, |mach configure|, |mach build| and 
other |mach| invocations and the subsequent commands invoked within 
during configure and compilation/build seemed to
change the file, mozilla/Cargo.lock. And during local hg update 
(applying my patches, etc.), hg commands suddenly states
that there is a local diff and refresh my repository before 
proceeding.

Surprised, I check what changed. The changed file is Cargo.lock.
This happened twice over the weekend.
(I updated the source tree from the M-C and C-C repository a few 
times. Each time the update worked OK. Only after a compilation and 
I tried to apply my local patch, this happened. My using hg MQUEE 
feature should not be a problem, though...)


The changes I noticed seem to be just the relocations of version 
information of some tools/packages in different part of Cargo.lock.
(Simple deletion/addition of same block in different parts of the 
file.)


This is so strange, and I wonder if there is something wrong with 
my setup.


I thought this is the first time it happened on my PC, but a close 
check of local patches revealed
something like this happened last August (Aug. 2019). Back then, I 
was trying very hard to accommodate the source tree layout change 
(C-C now having become the subtree of ./mozilla as mozilla/comm, 
and there were many local patches and locally crafted scripts  I 
needed to update and it seems that I simply accepted Cargo.lock 
change as part of the big tree layout and never bothered about it 
until today.)


Again, has anyone seen Cargo.lock being modified without direct 
user intervention on their PC?


TIA


___
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

___
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: Cargo.lock in hg repository?

[Emilio Cobos Álvarez]

On 5/19/20 3:11 AM, ISHIKAWA,chiaki wrote:
Thank you for the feedback. So I am not alone in seeing this. I will 
ignore the anomaly for now although there are a few strange local 
changes due to this now.


You shouldn't see it anymore if you rebase:

  https://hg.mozilla.org/mozilla-central/rev/6db4b71d0c20

 -- Emilio



Chiaki

On 2020/05/18 1:08, Emilio Cobos Álvarez wrote:
I see this too, I think it's a rebase messup between bug 1631630 and 
bug 1636068.


 -- Emilio

On 5/17/20 2:44 PM, ISHIKAWA,chiaki wrote:

I am developing TB patches locally on my linux PC.

Have anyone noticed mozilla/Cargo.lock seems to be in mercurial 
repository and that it got updated

during development?
That is, as far as *I* am concerned, I never tough it directly.
But, it seems |mach clobber|, |mach configure|, |mach build| and 
other |mach| invocations and the subsequent commands invoked within 
during configure and compilation/build seemed to
change the file, mozilla/Cargo.lock. And during local hg update 
(applying my patches, etc.), hg commands suddenly states

that there is a local diff and refresh my repository before proceeding.
Surprised, I check what changed. The changed file is Cargo.lock.
This happened twice over the weekend.
(I updated the source tree from the M-C and C-C repository a few 
times. Each time the update worked OK. Only after a compilation and I 
tried to apply my local patch, this happened. My using hg MQUEE 
feature should not be a problem, though...)


The changes I noticed seem to be just the relocations of version 
information of some tools/packages in different part of Cargo.lock.

(Simple deletion/addition of same block in different parts of the file.)

This is so strange, and I wonder if there is something wrong with my 
setup.


I thought this is the first time it happened on my PC, but a close 
check of local patches revealed
something like this happened last August (Aug. 2019). Back then, I 
was trying very hard to accommodate the source tree layout change 
(C-C now having become the subtree of ./mozilla as mozilla/comm, and 
there were many local patches and locally crafted scripts  I needed 
to update and it seems that I simply accepted Cargo.lock change as 
part of the big tree layout and never bothered about it until today.)


Again, has anyone seen Cargo.lock being modified without direct user 
intervention on their PC?


TIA


___
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

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