Re: Deprecation of NS_NewNamedThread

2020-03-02 Thread David Teller
That's cool!

I wonder if there is (or will be) a way to somehow preserve the naming
part of NS_NewNamedThread, which is sometimes precious for debugging,
i.e. somehow attach to the background thread a debugging information in
addition to the stack that would let us analyze what the thread was
attempting to do in case of crash.

Is anything like this planned?

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


Re: Deprecation of NS_NewNamedThread

2020-03-02 Thread Nicholas Alexander
Kris, others working on this,

On Mon, Mar 2, 2020 at 6:51 AM Kris Wright  wrote:

> *tl;dr: To create new one-off threads using NS_NewNamedThread, you need to
> add them to an allowlist. Lots of cases of async work can be done on the
> background thread pool.*
>



I've been watching this progress for a while and I'm thrilled to see it
land.  The proliferation of threads has lots of impacts; the one I know
about impacts performance and the shape of pageload profiles that we see on
mobile.  Thanks for making that a little easier to reason about, now and in
the future!

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


Intent to ship: Web Animations Animation timelines (without the setter of Animation.timeline)

2020-03-02 Thread Boris Chiou
Hi,

We intend to turn on the preference of the Animation timelines this week.
* dom.animations-api.timelines.enabled

This preference enables Animation.timeline getter, Document.timeline, and
DocumentTimeline and AnimationTimeline interfaces.

This feature has been implemented in WebKit and Blink in their nightly
version, but
they haven't shipped this to their release channels yet. We expect this
will happen
soon in the next version of Safari and shortly after in Chrome.

We implemented and enabled this (together with mutable Animation.timeline)
at least
3 years ago, and recently we added a build flag to enable mutable
Animation.timeline
only on Nightly version, so we can easily ship read-only Animation.timeline
and others
by the pref. WebKit and Blink are ready to ship this feature recently, so
we would like
to ship it too in Firefox 75.

Bug to turn this on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1619178

There is no specific intent to prototype these features. They have been
implemented as part of the ongoing work on the Web Animations API.

There are various web-platform-tests which use the getter of
Animation.timeline,
Document.timeline in
web-an

imations/timing-model/timelines

and a lot of places in web-an

imations/interfaces/

.
And there are some web-platform-tests for
AnimationTImeline/DocumentTimeline in
web-animations/interfaces/DocumentTimeline.


Please let me know if you have any concerns.

Best regards,
Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Security Severity Changes

2020-03-02 Thread Tom Ritter
Hi all,

In Berlin we realized that our Bug Severity page is confusing and that
sec-critical and sec-high don't have a good distinction. We
endeavoured to fix this, and think we have.  We have:

1) Split the Web and Client Severity page into separate pages. (And
updated them.)
2) Clarified the definition of sec-critical and sec-high
3) Clarified guidance on what we would like, and would not like, people to do.



1) The new pages are at:
https://wiki.mozilla.org/Security_Severity_Ratings/Client
https://wiki.mozilla.org/Security_Severity_Ratings/Web



2) sec-critical doesn't have a clear meaning today and it's often
contradictorily assigned and interpreted. Going forward, sec-critical
and sec-high will have no distinction in terms of type of bug
technically speaking; but sec-critical indicates "urgent security
issues that present an ongoing or immediate danger to users."

It would include:
 - actively exploited or publicly disclosed vulnerabilities
 - vulnerabilities that are worm-able or exceptionally easy to exploit

One detail - and change - of this redefinition is that vulnerabilities
that would otherwise be a sec-high, but are publicly disclosed or
fixed in an upstream third party library would be marked as critical.
However, because many of these are not actually reachable in
Firefox, once investigated and confirmed as such they will be
re-classified.



3) As is the case currently, we ask that
sec-critical/high/moderate/low as well as sec-other and sec-vector
only be assigned by those with experience evaluating vulnerabilities
in coordination with the security team (historically dveditz, Tyson,
mccr8, jesup, tjr). (This is not intended to hamper teams (e.g.
fuzzing) who work on security 'things' that need to hide them from
assigning sec-other though.)

sec-want and sec-audit are NEVER to be used for an actual, identified
vulnerability - that should be a separate bug with an actual
sec-critical/high/moderate/low rating. Otherwise; however, sec-audit
and sec-want are encouraged to be assigned by anyone on anything they
think those keyword applies to. (Including public bugs.) For example:
"This code pattern is dangerous, we should review existing stuff'
would be a private sec-audit bug. sec-want can apply both to client
security ("Create a wrapper of foo() that performs security checks")
and web security ("We should implement [new web security header]").

The csectype- keywords indicate the root cause of a vulnerability;
e.g. csectype-intoverflow or csectype-priv-escalation .  If you think
you can identify a root cause of a bug; feel free to do so!

We have a few whiteboard tags we're trying to promote the use of.
[pixel-stealing] for side-channel attacks that leak user history or
same-origin policy violations. [bad-ram?] for crashes suspected of
hardware problems; and [fingerprinting] for privacy concerns relating
to it.  If you have security or privacy-related whiteboard tags you
use today (or think should exist) please reply so we know about them
and we can potentially add it to more bugs and get it on the page.



Finally, as an additional note, we are performing a 'Security Bug
Re-Triage' effort where we are looking at all security bugs in the
platform, trying to close invalid ones, and re-raising particularly
concerning ones for consideration. If you are a Triage Owner and want
to know when we may come knocking, please email me.

As part of this, we have opened a #critsmash channel on Slack that is
a good avenue to ask questions like "Would you consider re-rating this
security bug?" and raise concerns like "This is a sec-high but it
involves months of work and we won't be able to get it done in a
timely manner."

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


Deprecation of NS_NewNamedThread

2020-03-02 Thread Kris Wright
*tl;dr: To create new one-off threads using NS_NewNamedThread, you need to
add them to an allowlist. Lots of cases of async work can be done on the
background thread pool.*

In order to improve our overall threading picture, we're working on
reducing the number of one-off threads spun up in Firefox. Part of that
work is converting existing one-off threads to use the background thread
instance. In light of this change, I've made an analyzer (Bug 1613440
) that prevents new,
unallowed instances of NS_NewNamedThread.

*What does this mean? *Existing uses of NS_NewNamedThread are already
allowed with a list that the static analyzer reads in. It checks for files
it wants to ignore entirely and thread names that it wants to allow. If it
finds a new use of NS_NewNamedThread, it will throw an error.

*When does this checker run?* This is a static analyzer that runs with
clang-plugin, meaning that it runs in automation and on builds with the
--enable-clang-plugin flag.

*Can I still use NS_NewNamedThread? *Technically yes, but you need to have
your new thread's name added to the allow list. Consider if the work can be
done by the background thread pool

instead.

*How do I get my new thread added to the allow list? *There are two lists -
ThreadAllows.txt

and ThreadFileAllows.txt
.
The difference is very simple - ThreadAllows takes *thread names* which are
declared as string literals, but not all uses of NS_NewNamedThread pass a
string literal. If this is your case, the analyzer might not be able to
read your thread name - so you would add your *file name* to
ThreadFileAllows.txt to tell the analyzer to ignore the whole file. It's
better to use the thread name rather than the file name when you can, in
case another named thread is added to the same file later on.

*I want to use the background thread pool / convert my existing instance of
NS_NewNamedThread to use the background pool. *The meta bug for this work is
Bug 1595241 . I
always encourage new conversions to the background pool. :)

For more information about the checker and how to use it, I wrote a post
here

that you can look at.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to ship: Web Animations implicit to/from keyframes and auto-removing redundant filling animations

2020-03-02 Thread Brian Birtles
Hi,

As of some time next week (week of Mar 2) I intend to turn on the following
two Web Animations API features by default for release channels:

* Implicit to/from keyframes (e.g. elem.animate({ opacity: 0 }, 500) to
fade out an element).
* Automatically removing filling animations that have been replaced by
other indefinitely filling animations.

These two features are shipping together because we originally did not ship
the former because of concerns that authors might use it in a manner that
effectively leaks memory. The latter behavior was introduced to address
that concern.

They have been developed behind the
dom.animations-api.implicit-keyframes.enabled and
dom.animations-api.autoremove.enabled prefs, respectively.

These two features have both been implemented in WebKit and Blink but have
yet to ship to their respective release channels. We expect that to happen
in the next version of Safari and shortly after in Chrome.

They have been enabled by default in Nightly for quite some time (about
Firefox 53 for the former and Firefox 69 for the latter) but we have been
waiting for WebKit and Blink to implement before shipping.

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1618773

There is no specific intent to prototype these features. They have been
implemented as part of the ongoing work on the Web Animations API.

There are various web-platform-tests for these features, particularly under
https://wpt.fyi/results/web-animations/animation-model/keyframe-effects .

Please let me know if you have any concerns.

Best regards,

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


Soft code freeze for Firefox 75 starts March 5

2020-03-02 Thread Julien Cristau
Hi all,

With Firefox 74 RC shipping today, we are nearing the end of the Nightly 75
cycle.

In order to avoid invalidating the testing we get out of late Nightly and
to ensure that we can roll out Beta 75 to a wider audience with confidence,
we'd like to ask that any risky changes be avoided from Thursday March 5th
until after the version bump to 76 on March 9th.

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,
Julien & the Release Management team
___
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

2020-03-02 Thread 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/wjbzdf2.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: about:logins
* NEW - https://bugzil.la/1618179 - [about:logins] Hover effect for 
[Sort by] button triggered of wrong element
* NEW - https://bugzil.la/1618525 - about:logins - remove hover effect 
for [Sort by] login-sort dropdown button if it is disabled


Firefox: Bookmarks & History
* NEW - https://bugzil.la/1618184 - The New folder input field is 
overextended if previously a long title one was created


Firefox: Protections UI
* NEW - https://bugzil.la/1618123 - [Protections Panel] Tracking 
Protection UI is overlapped in tracking content panel


Firefox: Theme
* NEW - https://bugzil.la/1617920 - [macOS] Improve visibility of the 
separators on bookmarks toolbar when in dark theme


Core: DOM: Service Workers
* NEW - https://bugzil.la/1618546 - Blank page is displayed when 
inspecting some pages from Service workers


Core: ImageLib
* NEW - https://bugzil.la/1617623 - Popular image formats are not 
detected in Save as Type field


Core: Layout
* NEW - https://bugzil.la/1617563 - [Ubuntu] Missing padding on Title 
bar with the window resized


Core: Permission Manager
* NEW - https://bugzil.la/1618895 - Firefox receives cookies for a 
website that was set as blocked in the permission section


Toolkit: Application Update
* RESOLVED WONTFIX - https://bugzil.la/1618850 - Crash in [@ xul.dll | 
mozglue.dll | xul.dll | nss3.dll | xul.dll]


Toolkit: Form Autofill
* NEW - https://bugzil.la/1618205 - Various fields are not auto filled 
on certain websites
* NEW - https://bugzil.la/1618208 - Scroll appears in autofill dropdown 
the first time it's opened

* NEW - https://bugzil.la/1618212 - Autofill doesn’t work on www.cdw.com

Toolkit: Notifications and Alerts
* NEW - https://bugzil.la/1618891 - Pop-up window still showing up even 
after being blocked


Toolkit: Password Manager
* NEW - https://bugzil.la/1618899 - Password save prompt is received for 
a website that was added as blocked in the exceptions list


DevTools: CSS and Themes
* NEW - https://bugzil.la/1618505 - DevTools - no select indicator for 
Settings - options when using keyboard TAB navigation


DevTools: Debugger
* NEW - https://bugzil.la/1617833 - Debugger - tabs in editor panel are 
not contained in the tab-area
* NEW - https://bugzil.la/1617860 - Zoom by CTRL + mouse scroll not 
picked up in Debugger editor


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


Regards,
Mihai Boldan


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