Intent to ship: the Cross-Origin-Resource-Policy header

[Valentin Gosu]

I'm shortly intending to turn on support for the
Cross-Origin-Resource-Policy header
This feature was developed behind the preference
"browser.tabs.remote.useCORP".

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)

Other UAs shipping this feature:
* Blink/Chrome - in Blink 73
https://www.chromestatus.com/feature/4647328103268352

Bug to enable by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1602363

This is header is required for shipping Cross-Origin-Embedder-Policy
https://mikewest.github.io/corpp/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visibility of disabled tests

[Botond Ballo]

On Sat, Jan 11, 2020 at 10:38 AM James Graham  wrote:
> So in addition to the specific changes for intermittent handling, can we
> document how one nominates a bug for retriage in general (or point me at
> those docs if they already exist)

My understanding is that clearing the "priority" field is a way to
nominate a bug for retriage, since triage dashboards like [1] use the
presence of a specified priority as an indication that a bug has been
triaged.

Cheers,
Botond

[1] https://mozilla.github.io/triage-center/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Searchfox at All-Hands: Who's interested?

[Jan-Erik Rediger]

Yup, consider me interested.
Also considering that I’d like one of our projects to be available on searchfox 
too.

— Jan-Erik 

> On 9. Jan 2020, at 19:43, Andrew Sutherland  
> wrote:
> 
> Are people interested in a session(s) at the All-Hands on Searchfox?  If 
> you're interested in any of the following things, please email me here or at 
> as...@mozilla.com or let me know via other channels, and let me know which of 
> the following you'd be interested in.  My goal is to get a rough count so I 
> can try and book a room if there's interest.
> 
> 
> 1. Contributing to Searchfox.  Want to improve something about Searchfox?  
> You can!
> 
> We can help you get set up with a local VM and credentials to try your 
> changes on mozilla-central in the cloud without your laptop melting down!  
> Already tried contributing and tried to melt your own laptop down out of 
> frustration with setting up VirtualBox?  We can help with that too!  (Also, 
> you can now use libvirt and save yourself a bundle in new laptops!)
> 
> Already have the VM setup and appreciate the extensive Searchfox 
> documentation at https://github.com/mozsearch/mozsearch/ and 
> https://github.com/mozsearch/mozsearch-mozilla/ but want some guidance on how 
> to implement the thing you want to do?  We can help with that double too!
> 
> 
> 2. Talking Searchfox UX, especially as it relates to upcoming 
> features/possibilities on the "fancy" branch.
> 
> I've been doing some hacking to support a more structured representation of 
> data to support creating diagrams[1] for both documentation purposes and to 
> make code exploration and understanding easier.
> 
> This potentially opens up a bunch of new features like 
> https://clicky.visophyte.org/files/screenshots/20190820-174954.png 
> demonstrates, providing both the type of a thing you've clicked on, plus 
> being able to see its documentation or uses without having to click through.  
> But the more features you try and cram into something, the more potential for 
> them to get in the way of what the user actually wanted to do.  For example, 
> the helpful popup also probably hides the code you were trying to look at. 
> Should the information be in a big box at the bottom of the screen like 
> cs.chromium.org?  The top?  Configurable?
> 
> Also, for the diagrams, how to make them most accessible.  My current 
> approach[2] attempts to leverage the inherent hierarchy into a ul/li 
> tree-structure that directly mirrors the clustering used in the graphviz 
> diagram, with in and out edges indicated at each node.  Planned work includes 
> figuring out how to best get NVDA to make those edges traversable so that the 
> traversal is possible with more than manually using ctrl-f.
> 
> 
> 3. Talking Searchfox data exposure for your own tools, especially as it 
> relates to the new data available on the "fancy" branch.
> 
> Do you have a tool that uses Searchfox and wish its result format wasn't 
> clearly just a data structure pre-baked for presentation purposes that the 
> receiving JS perform a light HTML-ization on?
> 
> 
> Andrew
> 
> 
> 1: Here are some examples of diagrams created during prototyping:
> 
> - Manually creation by clicking on calls/called-by edges in iterative search 
> results exploration: 
> https://clicky.visophyte.org/files/screenshots/20190503-133733.png
> - Automatic diagram from heuristics based on local same-file control flow: 
> https://clicky.visophyte.org/files/screenshots/20190821-165907.png
> - Blockly based diagramming without rank overrides or colors applied: 
> https://clicky.visophyte.org/files/screenshots/20191231-214320.png
> 
> 2: 
> https://github.com/asutherland/mozsearch/blob/00a60f899936559ed4d158999278660eb5c98df5/ui/src/grokysis/frontend/diagramming/class_diagram.js#L480
> 
> ___
> 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

[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/yfwt3p5x.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: Menus
* NEW - https://bugzil.la/1607677 - Black square appears on first window 
Hamburger’s Menu when a drop down is presented on the second window


Firefox: Tabbed Browser
* VERIFIED FIXED - https://bugzil.la/1607465 - Pinned tabs are jumping 
out of their normal position while being dragged


Firefox: Toolbars and Customization
* ASSIGNED - https://bugzil.la/1608106 - [macOS] Disabled drag space 
label (ie when title bar is enabled) inside Customize page is barely 
visible with dark OS theme


Core: Layout: Scrolling and Overflow
* NEW - https://bugzil.la/1607709 - [mac] Scroll bar disappear on 
scrolling inside bookmarks and history menus (with permanent scroll bar 
turned on in system preferences)


Core: Layout: Text and Fonts
* RESOLVED FIXED - https://bugzil.la/1607672 - [mac] Combination of 
unicode flower symbols displays profile names half-height for ✿❀✾❀✿ / 
improper glyphicons


Core: WebRTC: Audio/Video
* NEW - https://bugzil.la/1608412 - The video from Screen capture on 
getUserMedia test page hangs


Toolkit: Video/Audio Controls
* NEW - https://bugzil.la/1608425 - The picture-in-picture button is 
hidden beneath other buttons that are present on the page on twitch.tv
* NEW - https://bugzil.la/1608434 - Facebook - PIP - Play/Pause if not 
working first time watching a video in news Feed


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


Regards,
Mihai Boldan


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

Update of the Code review bot: CI-breaking issues are now reported

[Bastien Abadie]

tl;dr: The Code Review Bot will now warn you about CI-breaking issues on
Phabricator

Hello,

We have just released a new version of the code review bot that changes
slightly how lint issues are reported on Phabricator:

   -

   Issues breaking the CI are now reported as Phabricator lint results.
   Those are unignorable, contrary to inline comments.
   We are highlighting them because, if landed, such patches would be
   backed-out by the sheriffs.
   They are displayed at the top of the revision, and in the patch. They
   also are automatically removed on new diffs.
   -

   Ignorable lint issues (warnings) and static analysis results are still
   reported as inline comments.


This will help you know when your patch has issues which would cause a
back-out.

You can view a demonstration of such an error report here:
https://phabricator.services.mozilla.com/D59862

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

Intent to implement: AVIF (AV1 Image Format) support

[Jon Bauman]

AVIF is an image format based on the AV1 video codec [1] from the Alliance
for Open Media [2]. AV1 support shipped in release 55 [3] and is currently
supported in Chrome, but not Safari. There is an open issue for AVIF
support in Chrome [4].

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=avif

Standard: https://aomediacodec.github.io/av1-avif/

Platform coverage: All

Restricted to secure contexts: No. There's currently no mechanism to
enforce this for image formats, but we can revisit this before enabling
this by default. The same goes for CORS.

Target Release: 76

Preference behind which this will be implemented: image.avif.enabled,
turned off by default.

[1] https://en.wikipedia.org/wiki/AV1
[2] https://aomedia.org/
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=av1
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=960620
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Searchfox at All-Hands: Who's interested?

[Marco Castelluccio]

I'd be interested too, in particular about 1 as we'd like to integrate
more things into Searchfox (code coverage, static analysis and linting
issues to name a few).

- Marco.


Il 09/01/20 19:43, Andrew Sutherland ha scritto:
> Are people interested in a session(s) at the All-Hands on Searchfox? 
> If you're interested in any of the following things, please email me
> here or at as...@mozilla.com or let me know via other channels, and
> let me know which of the following you'd be interested in.  My goal is
> to get a rough count so I can try and book a room if there's interest.
>
>
> 1. Contributing to Searchfox.  Want to improve something about
> Searchfox?  You can!
>
> We can help you get set up with a local VM and credentials to try your
> changes on mozilla-central in the cloud without your laptop melting
> down!  Already tried contributing and tried to melt your own laptop
> down out of frustration with setting up VirtualBox?  We can help with
> that too!  (Also, you can now use libvirt and save yourself a bundle
> in new laptops!)
>
> Already have the VM setup and appreciate the extensive Searchfox
> documentation at https://github.com/mozsearch/mozsearch/ and
> https://github.com/mozsearch/mozsearch-mozilla/ but want some guidance
> on how to implement the thing you want to do?  We can help with that
> double too!
>
>
> 2. Talking Searchfox UX, especially as it relates to upcoming
> features/possibilities on the "fancy" branch.
>
> I've been doing some hacking to support a more structured
> representation of data to support creating diagrams[1] for both
> documentation purposes and to make code exploration and understanding
> easier.
>
> This potentially opens up a bunch of new features like
> https://clicky.visophyte.org/files/screenshots/20190820-174954.png
> demonstrates, providing both the type of a thing you've clicked on,
> plus being able to see its documentation or uses without having to
> click through.  But the more features you try and cram into something,
> the more potential for them to get in the way of what the user
> actually wanted to do.  For example, the helpful popup also probably
> hides the code you were trying to look at. Should the information be
> in a big box at the bottom of the screen like cs.chromium.org?  The
> top?  Configurable?
>
> Also, for the diagrams, how to make them most accessible.  My current
> approach[2] attempts to leverage the inherent hierarchy into a ul/li
> tree-structure that directly mirrors the clustering used in the
> graphviz diagram, with in and out edges indicated at each node. 
> Planned work includes figuring out how to best get NVDA to make those
> edges traversable so that the traversal is possible with more than
> manually using ctrl-f.
>
>
> 3. Talking Searchfox data exposure for your own tools, especially as
> it relates to the new data available on the "fancy" branch.
>
> Do you have a tool that uses Searchfox and wish its result format
> wasn't clearly just a data structure pre-baked for presentation
> purposes that the receiving JS perform a light HTML-ization on?
>
>
> Andrew
>
>
> 1: Here are some examples of diagrams created during prototyping:
>
> - Manually creation by clicking on calls/called-by edges in iterative
> search results exploration:
> https://clicky.visophyte.org/files/screenshots/20190503-133733.png
> - Automatic diagram from heuristics based on local same-file control
> flow: https://clicky.visophyte.org/files/screenshots/20190821-165907.png
> - Blockly based diagramming without rank overrides or colors applied:
> https://clicky.visophyte.org/files/screenshots/20191231-214320.png
>
> 2:
> https://github.com/asutherland/mozsearch/blob/00a60f899936559ed4d158999278660eb5c98df5/ui/src/grokysis/frontend/diagramming/class_diagram.js#L480
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

SpiderMonkey Newsletter #2

[Jan de Mooij]

(This newsletter is also available on our blog
.)

Happy new year from the SpiderMonkey team!

Heads up: the next newsletter will likely cover both Firefox 74 and Firefox
75 due to the shorter release cycles this year.
JavaScript New features

   - The relatedYear field type for
   Intl.DateTimeFormat.prototype.formatToParts is now part of the spec so
   André Bargull made it
    ride the trains.

Project Visage

Project Visage is a project to write a new frontend (parser and bytecode
emitter) for JavaScript in Rust that’s more maintainable, modular,
efficient, and secure than the current frontend. The team (Jason Orendorff,
Nicolas Pierron, Tooru Fujisawa, Yulia Startsev) is currently experimenting
 with a parser generator
that generates a custom LR parser.

There’s a fork of mozilla-central
 where passing
--rust-frontend to the shell makes it try the new frontend, falling back on
the C++ frontend for scripts it can’t handle (currently almost everything).
LibFuzzer is used as a way to identify issues where the new parser accepts
inputs which are currently rejected by the current parser.

Jason also improved 
most of our bytecode documentation

.

(Jason pronounces it “VIZZ-udge”, like the English word, but you can say
whatever you want.)
JSScript/LazyScript unification

Ted Campbell fixed 
the parser to avoid saving trivial data between syntax parsing and the
eventual delazification. This saves memory and brings us closer to being
able to reconstruct a lazy script directly from its non-lazy version.

The js::BaseScript

type now contains the fields it needed to represent lazy and non-lazy
scripts. This is an important milestone on the path to unifying JSScript
and LazyScript.
Project Stencil

As the GC-free parser work continues, Project Stencil aims to define a
meaningful data format for the parser to generate. This paves the way to
integrating a new frontend (Visage) and allows us to modernize the bytecode
caches and improve page-load performance. We call it ‘stencil’ because this
data structure is the template from which the VM’s JSScript will be
instantiated.

   - Matthew Gaudet started fuzzing the deferred allocation path in the
   front end. The hope is that we will enable this code path by default early
   in the Firefox 74 cycle. The end goal of turning this on by default is to
   avoid having to maintain two allocation paths indefinitely.
   - The LazyScript unification work continues to simplify (and clarify)
   the semantics of internal script flags that the parser must generate. These
   flags will become part of the stencil data structures.

Regular expression engine update

Iain Ireland is writing a shim layer to enable Irregexp, V8’s regexp
engine, to be embedded in SpiderMonkey with minimal changes relative to
upstream. He is currently working on rewriting the existing regular
expression code to call the new engine.
Bytecode and IonBuilder simplifications

The previous newsletter mentioned some large IonBuilder code
simplifications landing in Firefox 72. This cycle Jan de Mooij changed
 all loops to have
the same bytecode structure so IonBuilder can use the same code for all of
them. This also allowed us to remove
 more source notes
and JIT compilation no longer has to look up any source notes.

These changes help the new frontend because it’s now easier to generate
correct bytecode and also laid the groundwork for more Ion cleanup work
this year. Finally, it ended up fixing some performance cliffs: yield*
expressions
,
for example, can be at least 5x faster
.
toSource/uneval removal

Tom Schuster is investigating
 removing the
non-standard toSource and uneval functions. This requires fixing a lot of
code and tests in Firefox
 so as a first step
we may do this only for content code. André Bargull helped out
 by fixing
SpiderMonkey tests to stop using these functions.
Debugger

Logan Smyth rewrote 
debugger hooks to use the exception-based implementation for forced
returns. This ended up removing and 

Re: Visibility of disabled tests

[Botond Ballo]

On Sat, Jan 11, 2020 at 10:38 AM Geoffrey Brown  wrote:
> It might be helpful if we explicitly consider some special cases. If the
> sheriffs have needinfo'd for "needswork" and that needinfo has been
> cleared, do we  want to set needinfo again when disabling? Always? If the
> triage owner has a huge needinfo queue, still needinfo? ...

The test's author, if still active on the project, may be a good
alternative person to needinfo.

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

Preference name change for experimental addon development

[Shane Caraveo]

This is an FYI for developers who develop experimental APIs.

tl;dr

In Firefox 74 you will need to use extensions.experiments.enabled 
instead of extensions.legacy.enabled.  This should land soon in bug 1524327.


What is this?

This preference is used to enable to features for developers in Nightly, 
Developer Edition and unbranded builds.  It allows testing of 
experimental APIs without signing an extension, as well as testing 
privileged APIs when loading the extension through about:debugging.


History and reason

When we were making the change from the legacy xul/xpcom extensions to 
webextensions, we had a build flag and preference to continue allowing 
the use of legacy extensions.  The ability to load legacy extensions has 
long been removed from Firefox, but the flag was also used for these 
features and has remained to support them.


The name change will clarify what the preference does and allow us to 
remove some remaining bits of code that supported legacy extensions.


Since the preference is used by a very small community we do not feel 
the need for a transitional period with the preference change.


If you have any questions let me know.

Shane

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

Intent to ship: native rendering of outline-style: auto

[Emilio Cobos Álvarez]

Hi,

In bug 1031664 I plan to enable the themed rendering of outline-style: auto.

Standard: https://www.w3.org/TR/css-ui/#outline-style (sorry for the TR 
version, but I have problems to access the current draft without 
building it locally :/)


Platform coverage: Linux, Mac, Windows

Preference: layout.css.outline-style-auto.enabled

DevTools bug: N/A (works fine with existing tools)

Status in other browsers is:

 * EdgeHTML: Doesn't parse the value at all.
 * Safari: Supports the value as intended, by using the platform theme.
 * Chromium: Parses the value, and outputs a fixed-width outline in 
chromium with a slight radius (at least on Linux and Windows, not sure 
about Mac). It respects outline-color which is a bit weird.
 * Epiphany: Uses 1px dotted outline instead, with some weird effects 
if you change outline-width. Also respects outline-color.


Without this patch, our current behavior is that we just treat auto as 
solid, respecting width (unlike other browsers), and color (unlike 
Safari, but like Chrome).


With this patch our behavior would match Safari's, effectively.

web-platform-tests: This is pretty hard to test in WPT, as it is 
platform and browser-dependent behavior.


Secure contexts: This is not restricted to secure contexts, like other 
CSS features, and features that other browsers ship in insecure contexts.


Addendum:

I want to use the auto value as the default for our form controls, so 
that I can fix bugs like [1] by omitting its rendering for themed form 
controls.


That is not _theoretically_ blocked by this change, I guess, as we have 
the auto value in the computed style anyway, but it'd be nice to show 
the native outline even if the form control is not themed. Also falling 
back to solid for form controls may not be great (other focused things 
use dotted outlines).


If we find any compat issues / developer or user complaints due to this 
(specially on Windows / Linux), we should probably reconsider and take 
an approach more similar to Chromium / Epi's and remove the 
widget-specific implementations. But I think it'd be nice to do what the 
feature was intended for, I think.


That being said, given the (clearly sub-standard) compat situation, let 
me know if you think it's better to keep it turned this on only for 
Nightly / Beta for a release or two. We're early in the cycle but...


If you find any rendering problems with them or pages looking worse 
because of them, please file a bug blocking bug 1031664 and needinfo me 
or such.


Thank you,

 -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1311444
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform