date:20200206

Some changes to how errors are thrown from Web IDL methods

2020-02-06 Thread Boris Zbarsky


Hello all,

I just checked in some improvements to how we report exceptions on 
ErrorResult and in promise rejections [1].  Summary:


1) The public ThrowDOMException method that takes an nsresult and a 
string is gone.  Instead, there are methods like ThrowIndexSizeError, 
ThrowHierarchyRequestError, etc, matching the error names defined at 
.  So 
whenever the spec says to "throw an SecurityError exception" or whatnot, 
you call ThrowSecurityError.  These methods can take either a string 
literal ("foo") or any nsACString.  nsPrintfCString can be used to 
produce error messages that depend on the input to the DOM method.


2) The public Promise::MaybeRejectWithDOMException method is gone. 
Instead there are MaybeRejectWithIndexSizeError, etc, methods.  Again, 
these just take the string to use for the message as input.


3) While ErrorResult::Throw taking just an nsresult still exists, it is 
deprecated and new code should not be adding new calls to it if that can 
be avoided.  Callsites that pass a constant nsresult value can be 
changed to use the above methods with meaningful error messages; I will 
be doing some of that, but would appreciate help from subject matter 
experts who can probably write better error messages than I can.  Same 
thing for ErrorResult::operator=(nsresult).


4) Promise::MaybeReject(nsresult) still exists, but is deprecated. 
Please try to convert to one of the above methods or taking an 
ErrorResult that had a meaningful exception thrown on it.


I would really like to get to the point where when web developers see 
errors in their console they don't have to guess what caused those 
errors, and having meaningful messages is the simplest way to get there.


-Boris

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

IPCError-browser | ShutDownKill signatures are about to change

2020-02-06 Thread Gabriele Svelto

[cross-posting to dev-platform]

IPCError-browser | ShutDownKill crashes are the second most common ones
after OOMs and generally not actionable because we've been lumping
together a bunch of different stacks under the same signature.

These crashes represent a snapshot of a content process taking too long
to shut down. The affected content process is killed right after the
crash report is generated.

Bug 1612569 [1] will change those signatures soon. The new signatures
will include one or more function names after `IPCError-browser |
ShutDownKill` coming from the stack of the content process.

This will allow us to find common causes of slowness (or deadlocks) that
prevent content processes from shutting down rapidly and hopefully act
on them.

 Gabriele

[1] Improve IPCError-browser | ShutDownKill signatures
https://bugzilla.mozilla.org/show_bug.cgi?id=1612569



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: updated values for text-decoration properties

2020-02-06 Thread Jonathan Kew

There have been some recent changes to the CSS spec for the 
text-decoration-thickness, text-underline-offset, and 
text-underline-position: support for percentage values (based on the 
font-size) is added to the -thickness and -offset properties, as an 
alternative to using absolute lengths; and the from-font value is moved 
from text-underline-offset to -position.


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

Standard:
https://drafts.csswg.org/css-text-decor-4/#text-decoration-width-property
https://drafts.csswg.org/css-text-decor-4/#text-underline-position-property
https://drafts.csswg.org/css-text-decor-4/#underline-offset

Testing: web-platform/tests/css/css-text-decor/

Cross-browser support:
Safari partially supports these properties (it does not yet support 
percentages or the from-font value), while Chrome supports -position 
(without from-font) but not -offset or -thickness. Apple people have 
been involved in the recent spec changes, so I think we can expect to 
see Safari, at least, update its implementation to align with the new 
spec fairly soon.


Platform coverage: All

Restricted to secure contexts:
No; this is an adjustment to existing CSS properties that are available 
everywhere.


Target Release: 74

Preferences behind which this will be implemented:
None. (But note that the CSS properties involved are each gated on 
individual prefs from their original implementations:

layout.css.text-decoration-thickness.enabled
layout.css.text-underline-offset.enabled
layout.css.text-underline-position.enabled
These are enabled by default already.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Soft code freeze for Firefox 73 starts February 4

2020-02-06 Thread Pascal Chevrel

Hi all,

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

In order to avoid invalidating the testing we get out of late Nightly
and to ensure that we can roll out Beta 74 to a wider audience with
confidence, we'd like to ask that any risky changes be avoided from
today until after the version bump to 74 on February 10.

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

-- 
Pascal Chevrel
Firefox Release Manager 
+ Firefox Nightly community management

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

PSA: Hang Reports in tests now have the correct crash signature

2020-02-06 Thread Kristen Wright

[Cross-posting to stability]
In tests, the crash report now correctly reflects the hanging or crashing
process. With Bug 1605328
 fixed, the crashing
process .dmp file will be sorted at the top of the list and therefore
output the hanging crashing process stack trace first. This will lead to a
difference in what order they show up in Treeherder, because your process
stack traces will output in a different order. The benefit of this is that
bugs filed from the report now reflect the hanging or crashing process
instead of using the main process. This means that new bugs on existing
crashes may now be filed with the correct signatures.
___
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-02-06 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/yfwt3p5x.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: about:logins
NEW - https://bugzil.la/1612056 - [lockwise] Tooltip for Show/Hide 
password button is missing in about:logins page


Firefox: Preferences
NEW - https://bugzil.la/1612049 - Provide a tooltip message on hover for 
the NextDns option


Firefox: Search
NEW - https://bugzil.la/1612122 - Copy / Cut options from context menu 
are available on empty searchbar


Core: DOM: Service Workers
NEW - https://bugzil.la/1612300 - Queued notifications should no longer 
be displayed after the service worker is unregistered


Core: Networking
NEW - https://bugzil.la/1611907 - Crash in [@ 
mozilla::net::nsHttpChannel::AssertNotDocumentChannel]


Core: Privacy: Anti-Tracking
NEW - https://bugzil.la/1612522 - Tracking Protection Shield inactive 
after going back to a previous page


Core: Widget: Gtk
RESOLVED WONTFIX - https://bugzil.la/1611939 - [Linux] Last button on a 
pop-up not highlighted when using Tab navigation


DevTools: Console
NEW - https://bugzil.la/1612327 - Browser console cannot be reopened if 
closed too fast


Toolkit: Find Toolbar
NEW - https://bugzil.la/1612566 - [OSX] The search term is kept in 
normal and private window


OPEN - #1508  - 
The image is not displayed for the first resolved breach on a newly 
created profile


OPEN - #1509  - On 
the resolved breaches page there is a scroll bar that controls the page 
beneath


OPEN - #1510  - A 
scrollbar is needed in order to access all the buttons from the resolved 
breaches page when it's zoomed in


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


Regards,
Mihai Boldan


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

Intent to Deploy: ThreadSanitizer

2020-02-06 Thread Christian Holler

Data races in C/C++ code are a class of bugs that can severely impact
stability of the product while being hard to reproduce and debug.
Furthermore, data races are undefined behavior and can lead to
unforeseeable code behavior once compilers exploit this fact for better
optimizations. We have evidence that data races can cause intermittent
crashes and use-after-free memory safety violations that are hard to detect
by the existing sanitizers (e.g. AddressSanitizer) due to their
intermittent behavior.

ThreadSanitizer (TSan)
is another sanitizer, specifically aimed at detecting data races and
related problems (e.g. mutex ordering issues, potential deadlock
situations, etc).

One of the problems with deploying ThreadSanitizer in CI is that we have a
fair amount of existing data races that orange pretty much every test we
have. In order to solve this situation, we are currently working on the
following strategy:

Add a Linux TSan build as Tier1 to avoid build regressions (done in bug
1590162 )
2.

Run a set of tests and generate a runtime suppression list

for all of the existing issues.
3.

File the existing issues so we can track them (tracking bug is bug 929478
).
4.

Enable now-green tests to avoid further regressions (tracked in bug
1612711 ).

As part of this process is to file existing race reports, you might already
have seen related bug reports in your component. There is no need to
immediately react to these reports, but we would of course very much
appreciate it if they could eventually be triaged and fixed (Many of you
have done so already, thank you!). Keep in mind that some of these reports
might point to potential sources of instability and other intermittent
misbehavior, so there might be potential to eliminate some nasty bugs. In
fact, we have already identified several major issues in our codebase just
from running tests. If you identify such a case, we would also ask for you
to indicate this somehow in the bug, as we track such bugs separately to
assess the value of the tool.

It is also likely that you will see benign race reports (or at least
reports that look benign). Unfortunately, it is incredibly hard to tell if
a race is really benign or not [1][2][3][4], so if an issue is easy to fix,
we suggest just fix it and not spend too much time on the analysis. There
might be cases where fixing a confirmed-benign race is not worth the
investment. In this case, we can add a permanent suppression. Since every
suppression costs some performance, we should try to use these carefully
though.

Overall we hope that this tool will make it easier for all of us to produce
more stable and secure code, debug existing issues more effectively and
maybe even move the needle when it comes to inexplicable crashes in
crash-stats.

[1]
https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong

[2]
https://blog.mozilla.org/nfroyd/2015/02/20/finding-races-in-firefox-with-threadsanitizer/

[3]
https://blog.mozilla.org/nnethercote/2015/02/24/fix-your-damned-data-races/
[4] https://www.usenix.org/legacy/events/hotpar11/tech/final_files/Boehm.pdf
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Upgrading to Node 10 early Nightly 75 (week of February 10th)

2020-02-06 Thread Ed Lee

dmose is planning to upgrade [1] from Node 8 to Node 10 in build and
test environments next week. This should fix / avoid a number of test
failures as various dependencies rely on newer features, e.g., for
await...of.

For some additional history, the build system already supports [1]
both Node 8 and Node 10, and the previous Node version change [2]
bumped the minor version to 8.17 back in December. Both seem to have
landed quite smoothly, although here we're changing the major version,
so please respond if you have concerns.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1547823
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1611201
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1604295

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

Try pusher? Rebase your stack or get test failures

2020-02-06 Thread Sebastian Hengst

Because some certificates stored in the source code directory needed 
renewal, pushes to Try based on older revisions than the latest commit 
("tip") for all mozilla-* repositories and autoland will yield many test 
failures.


Please rebase your patch stack before pushing to Try.

Sebastian Hengst
Code Sheriffing Lead
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

GC rooting hazard analysis "presentation" from Berlin All-Hands

2020-02-06 Thread Steve Fink

See http://hotsphink.github.io/sfink-tools/doc/hazards.html for the 
autogenerated HTML from my presentation on the static analysis. It 
contains technical detail that I didn't cover, as well as details on 
potential future analyses such as can-run-script and iterator 
invalidation. Ask me anything.



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

Re: Volunteers needed for nightly crash triage rotation