Intent to ship: WebAssembly bulk-memory-operations and reference-types proposals

2020-06-24 Thread Ryan Hunt
Hi all,

In bug 1528294 and bug 1637884 I intend to ship the WebAssembly
bulk-memory-operations and reference-types proposals.

The bulk-memory-operations proposal adds new instructions for common data
manipulation operations such as 'memcpy' and 'memset'. WebAssembly code using
these instructions can expect better performance than implementing their own
versions.

The reference-types proposal adds a new class of values, reference types, to
the existing primitive types (i32, i64, f32, f64) available to WebAssembly.

One of these types is called 'externref' and can hold any JS value. This allows
WebAssembly functions to receive JS values as parameters, store them in tables,
and return them as results.

This can lower the amount of JS glue code required for WebAssembly programs to
access the DOM. This proposal is also expected to form the basis of future
extensions such as the GC proposal.

These proposals are currently hidden behind a pref and have been enabled in
Nightly for over a year now. The WebAssembly CG recently has voted to advance
both of these proposals to Phase 4, and so we are now good to enable them by
default.

## Status in other browsers

Chrome shipped the bulk-memory-operations proposal in Chrome 75. Their
reference-types implementation is currently behind a flag.

## Tracking bugs

 * bulk-memory-operations: Bug 1413846
 * reference-types: Bug 1508553

## Specifications

 * https://github.com/WebAssembly/bulk-memory-operations
 * https://github.com/WebAssembly/reference-types

Let me know if there are any questions.

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


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

2020-06-24 Thread James Teh
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


Intent to Ship : HTML5 element (Nightly Only)

2020-06-24 Thread Sean Feng

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


Re: Please don't use functions from ctype.h and strings.h

2020-06-24 Thread Chris Peterson

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

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


TC39 76th meeting (June, 2020)

2020-06-24 Thread Yulia Startsev
Hi everyone, I have published the summary for the June 2020 TC39 meeting.
TC39 standardizes JavaScript. If you want to know more, but don't know how
to get started, scroll to the end of this email for some helpful links.

*Important links:*
* Proposal Summaries and Comments

* Complete Notes



*The quick version:*

At this meeting we covered a lot of ground. It was the first four day
meeting, with each meeting at 5 hours. This meeting did not see any stage 2
proposals advance to stage 3, so in terms of implementation work, we do not
have new tasks. However, we do have significant review work. One large
proposal, Temporal, will be seeking stage 3 at an upcoming meeting.
Decorators also need to be discussed again.

In terms of exciting proposals for developers, Record and Tuple are
continuing steady development, and Do notation was brought back.

*Learning more:*

If you are new to the standards world, you can take a look at the process
document [1], and this slide deck that I did to explain the process [2].
We have also built a repository explaining how tc39 works[3]. If you want a
Mozilla-specific take, I doing a stream explaining how to read the
specification and how SpiderMonkey works [4]

[1]: https://tc39.es/process-document/
[2]:
https://docs.google.com/presentation/d/1q6pCJVwgYV19gbvNdLtwMnQ6vMZKdqZY-cQ6CE5yH8Y/edit#slide=id.gc6fa3c898_0_0
[3] https://github.com/tc39/how-we-work
[4]
https://hacks.mozilla.org/2020/06/compiler-compiler-working-on-a-javascript-engine/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Soft code freeze for Firefox 79 starts June 25

2020-06-24 Thread Ryan VanderMeulen
With Firefox 78 now in the RC phase, we are nearing the end of the Nightly
79
cycle.

In order to avoid invalidating the testing we get out of late Nightly and
to ensure that we can roll out Beta 79 to a wider audience with confidence
next week, we'd like to ask that any risky changes be avoided from Thursday
June 25 until after the version bump to 80 on June 29.  This also means
that feature work targeting 79 should be complete and ready to ride the
trains as soon as possible.

Some reminders for the soft code freeze period:

Do:
- Be ready to back out patches that cause crash spikes, new crashes, severe
regressions
- Monitor new regressions and escalate merge blockers
- Support release management by prioritizing fixing of merge blockers

Do Not:
- Land a risky patch or a large patch
- Land new features (that affect the current Nightly version) — be mindful
that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to
unexpected CI results
- Flip prefs that enable new Features that were untested in the Nightly
cycle
- Plan to kick off new experiments that might impact a feature's merge
readiness

Please let us know if you have any questions/concerns.

Thanks,
Ryan & the Release Management team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to ship: returning shared memory to the web

2020-06-24 Thread Anne van Kesteren
At the end of August 2019 we expressed an intent to prototype the
re-enablement of SharedArrayBuffer[1]. Many bugs and design
iterations later, we’re happy to announce that it’s now ready. We
would like to ship this in Firefox 79 or 80.

To do this in a post-Spectre-safe manner we have worked with others
to add the cross-origin isolated primitive to the web platform, which
provides sites that opt into it with their own process that cannot
pull in non-consenting external resources. In that process they get
to use high-resolution clocks and shared memory.

To address novel attacks, we have added the ability to throttle
JavaScript execution with JSExecutionManager[2]. With more
implementation work, we could also use this capability to reduce
resource consumption and improve battery life, e.g., by enabling it
for background tabs.

Here’s a summary of the changes:

* We have already shipped[3] JavaScript’s Atomics and
  SharedArrayBuffer to release, although globalThis.SharedArrayBuffer
  returns undefined as long as the cross-origin isolated primitive is
  false. This included support for the shared:true parameter of
  WebAssembly.Memory’s constructor.
* As part of this intent we’ll ship the Cross-Origin-Opener-Policy
  and Cross-Origin-Embedder-Policy headers, that when set to the
  same-origin and require-corp values respectively, for a top-level
  document, enable its browsing context group to be cross-origin
  isolated. (Cross-Origin-Opener-Policy also helps sites close a
  security hole in the web platform by preventing themselves from
  being opened in a popup an attacker might control.)

  If a document is cross-origin isolated:

  * globalThis.crossOriginIsolated will return true.
  * globalThis.SharedArrayBuffer will no longer return undefined.
  * postMessage() can be used to message SharedArrayBuffer objects,
restricted to the agent cluster[4] (the smallest unit a browser
could isolate in a process) it was created in.
  * Agent clusters within a cross-origin isolated browsing context
group are keyed on origin rather than site: this means that 1)
shared memory is bound to a single origin (postMessage()’ing
elsewhere results in a messageerror) and 2) document.domain is
ineffective (it returns just before changing the origin, for
maximum compatibility with existing libraries that reportedly set
it a lot, but don’t really care if it works). (With Fission this
would allow us to use actual processes at the origin boundary
too, but we have not looked into that much thus far.)
  * Timers are no longer throttled, including performance.now().

Chrome plans to match this model by August 2020 for Android, March
2021 for all except sites that opt-out, and May 2021 for all without
exceptions.[5]

It’s being standardized primarily in the Fetch and HTML standards,
through a number of pull requests that are close to done:

* https://github.com/whatwg/html/pull/5334 (COOP)
* https://github.com/whatwg/html/pull/5454 (COEP)
* https://github.com/whatwg/fetch/pull/1030 (COEP)
* https://github.com/w3c/ServiceWorker/pull/1516 (COEP)
* https://github.com/whatwg/html/pull/4734 (cross-origin isolated)
* https://github.com/w3c/hr-time/issues/89 (timers; not much progress
  on this unfortunately; timers in general are a somewhat poorly
  defined piece of infrastructure)

Shipping bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1619649.

(Following this work we plan to change the header parsers from strict
byte sequence comparisons to using structured headers, which will
also pave the way for adding reporting functionality. We also plan to
eventually support cross-origin isolated for shared and service
workers and roll all of this out on mobile.[6])

In no particular order, many thanks to Nika, Tom, Valentin, Eden,
Jens, Luke, Bas, Neha, Andrew (x2), Hsin-Yi, Perry, Steve, Mike,
Lars Thomas, Jeff, Junior, Selena, Yaron, and Eric for their help
getting this done in Firefox!

[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/IHkBZlHETpA/dwsMNchWEQAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1563335
[3] 
https://groups.google.com/d/msg/mozilla.dev.platform/yl0BXW-_ou0/u9CKDvuABgAJ
[4] 
https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-agent-cluster-formalism
[5] 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/_0MEXs6TJhg/QzWOGv7pAQAJ
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1563480
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to prototype HTML:inert

2020-06-24 Thread pepelsbey
Great news! Once you have it in Nightly, please don’t forget to update the MDN 
data. I’m currently trying to fix it for existing behind-the-flag 
implementations https://github.com/mdn/browser-compat-data/pull/6323
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform