Re: nsresult code lookup via IRC (mrgiggles bot)

[Kris Maglione]

If you're not in an IRC channel with mrgiggles, and happen to 
have a Firefox or xpcshell instance, you can also just evaluate  
`Components.Exception("", 0x80630001)`, which will generally 
work with anything other than NSS error codes (which are 
special, and have their own special lookup mechanism).


On Fri, Mar 29, 2019 at 04:41:53PM -0700, Steve Fink wrote:
If you're in an IRC channel with mrgiggles, the query "what is 
0x806e000b?" will return the corresponding nsresult code(s), together 
with any associated comments heuristically parsed from the 
ErrorList.py source. The comments are sometimes helpful:


 what is 0x804B0046?
 0x804b0046 as nsresult is NS_ERROR_DOCUMENT_NOT_CACHED 
from the NETWORK module, commented:
    Error passed through onStopRequest if the document could not be 
fetched from the cache.


and sometimes not so much:

 what is 0x80630001?

 0x80630001 as nsresult is NS_ERROR_STORAGE_BUSY from the 
"STORAGE" module, commented:


    To add additional errors to Storage, please append entries to the 
bottom of the list in the following format:

    NS_ERROR_STORAGE_YOUR_ERR, FAILURE(n)
    where n is the next unique positive integer. You must also add an 
entry to js/xpconnect/src/xpc.msg under the code block beginning with 
the comment 'storage related codes (from mozStorage.h)', in the 
following format: 'XPC_MSG_DEF(NS_ERROR_STORAGE_YOUR_ERR, "brief 
description of your error")'


If mrgiggles does not subscribe to your favored channel, or you're the 
quiet unassuming sort, `/msg mrgiggles what is 0x80630001?` anywhere 
on moznet will also work.


Reverse lookup also works:

 what is NS_RDF_ASSERTION_REJECTED?
 NS_RDF_ASSERTION_REJECTED is 0x4f0003 from the RDF module, 
commented as:
Returned from nsIRDFDataSource::Assert() and Unassert() if the 
assertion not willing to record the statement.


I'm not entirely sure why that last one is a success code rather than 
an error code, but thankfully I do not need to know. mrgiggles will 
update every couple of hours or so, except when I break it and don't 
notice.


Web-based nsresult lookup services include Mossop's 
https://www.oxymoronical.com/nsresult/ and the older 
https://james-ross.co.uk/mozilla/misc/nserror


Note that this output is only for numbers that happen to be nsresult 
codes; mrgiggles has other numeric lookup tricks too:


 what is 0xfffe6b887ea990a0?
 sfink: (as PUNBOX64) ObjectValue(0x6b887ea990a0)
 what is 0xe5e5e5f7?
 e5e5e5f7 is 18 bytes after the magic value e5e5e5e5
    0xe5 is jemalloc freed memory
    if you're seeing a crash with this pattern, you may have a 
use-after-free on your hands
    and you'd better fix it. They tend to be security bugs! (Or we 
might just have not initialized that memory after allocating it.)


I don't normally post about new mrgiggles tricks, but the nsresult 
stuff seems generally useful and undiscoverable.



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


--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation

It is the mark of an educated mind to be able to entertain a thought
without accepting it.
--Aristotle

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

nsresult code lookup via IRC (mrgiggles bot)

[Steve Fink]

If you're in an IRC channel with mrgiggles, the query "what is 
0x806e000b?" will return the corresponding nsresult code(s), together 
with any associated comments heuristically parsed from the ErrorList.py 
source. The comments are sometimes helpful:


 what is 0x804B0046?
 0x804b0046 as nsresult is NS_ERROR_DOCUMENT_NOT_CACHED from 
the NETWORK module, commented:
    Error passed through onStopRequest if the document could not be 
fetched from the cache.


and sometimes not so much:

 what is 0x80630001?

 0x80630001 as nsresult is NS_ERROR_STORAGE_BUSY from the 
"STORAGE" module, commented:


    To add additional errors to Storage, please append entries to the 
bottom of the list in the following format:

    NS_ERROR_STORAGE_YOUR_ERR, FAILURE(n)
    where n is the next unique positive integer. You must also add an 
entry to js/xpconnect/src/xpc.msg under the code block beginning with 
the comment 'storage related codes (from mozStorage.h)', in the 
following format: 'XPC_MSG_DEF(NS_ERROR_STORAGE_YOUR_ERR, "brief 
description of your error")'


If mrgiggles does not subscribe to your favored channel, or you're the 
quiet unassuming sort, `/msg mrgiggles what is 0x80630001?` anywhere on 
moznet will also work.


Reverse lookup also works:

 what is NS_RDF_ASSERTION_REJECTED?
 NS_RDF_ASSERTION_REJECTED is 0x4f0003 from the RDF module, 
commented as:
Returned from nsIRDFDataSource::Assert() and Unassert() if the assertion 
not willing to record the statement.


I'm not entirely sure why that last one is a success code rather than an 
error code, but thankfully I do not need to know. mrgiggles will update 
every couple of hours or so, except when I break it and don't notice.


Web-based nsresult lookup services include Mossop's 
https://www.oxymoronical.com/nsresult/ and the older 
https://james-ross.co.uk/mozilla/misc/nserror


Note that this output is only for numbers that happen to be nsresult 
codes; mrgiggles has other numeric lookup tricks too:


 what is 0xfffe6b887ea990a0?
 sfink: (as PUNBOX64) ObjectValue(0x6b887ea990a0)
 what is 0xe5e5e5f7?
 e5e5e5f7 is 18 bytes after the magic value e5e5e5e5
    0xe5 is jemalloc freed memory
    if you're seeing a crash with this pattern, you may have a 
use-after-free on your hands
    and you'd better fix it. They tend to be security bugs! (Or we 
might just have not initialized that memory after allocating it.)


I don't normally post about new mrgiggles tricks, but the nsresult stuff 
seems generally useful and undiscoverable.



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

Intent-to-Unship: DH algorithm support for WebCrypto

[J.C. Jones]

Our WebCrypto implementation supports using DH as an algorithm in
generateKey, which is not one of the recognized algorithms in the
published specification [0]. It doesn't even appear on MDN [2].

I intend to remove it from Firefox. However, before I do that, I am
landing telemetry [1] to determine whether it’s seeing use, at least
among our Nightly population. Given the relatively small sample, if we
get very low usage, that tells us nothing. However, if we do see
significant usage, we’ll have to be more careful in our plans.

My guess, since DH support is Firefox-only, is that after gathering
telemetry in the 68 cycle, we will unship in 69, unless further
information from Beta 68 causes us to revise course. I’ll plan to
update this thread as we learn more.

[0] https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539578
[2] https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/generateKey
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [IMPORTANT] Submit your PI Requests for Firefox 68 QA feature testing by March 29

[Tom Grabowski]

Hi,

Just a reminder that the deadline for Fx68 PI Requests is today. If you
have not done it yet, please log your PI request as soon as possible.

- Tom


On Fri, Mar 22, 2019 at 11:40 PM Tom Grabowski 
wrote:

> Similar to what QA did for previous Firefox feature testing prioritization
> ,
> we would like to do the same for Fx68. In order to help with the process, 
> *please
> submit your pi-request
>  by March 29. *This
> is needed to assure QA will be involved in your feature development work
> for the 68 cycle.
>
> As you are probably aware, starting with Fx68, the release process and
> schedule are changing. Full description of changes can be found here
> .
> By default, all PI requests are to be considered for testing in Beta cycle
> only. Project teams can request if they need Nightly testing, which is now
> optional.
>
> Please note that the *feature technical documentation needs to be ready
> before April 12*, so that QA has enough time to design the test plan.
> Please make sure your documentation follows these guidelines: Feature
> Technical Documentation Guidelines
> .
> For *features that require Nightly testing*, please provide documentation
> as soon as possible. QA cannot start working on your feature without
> documentation.
>
>
>
> *Q: What happens after the deadline?*
> A: After the deadline QA will come back with a prioritized list of work
> that represents what we are committing to for the next cycle. We want to
> ensure this list matches eng and product expectations.
>
> *Q: What if I miss the deadline?*
> A: We reserve the right to say that we can't pick up work for late
> requests in the current cycle. You can still develop and execute your own
> test plan or defer the work to the following cycle.
>
> *Q: What about unknown or unexpected requests? What if there is a business
> reason for a late request? What do we do with experiments and System
> Add-ons?*
> A: In order to remain flexible, we will keep some percentage of time open
> for requests like these.
>
> *Q: There's no way I'm going to remember to do this. *
> A: Do it now! I'll also send out a reminder next week.
>
> Thanks,
> Tom
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform