Please aim to add informative messages to your exceptions

[Boris Zbarsky]

Hello,

ErrorResult has two kinds of exception-throwing APIs on it: the older 
ones that don't allow specifying a custom message string, and newer ones 
that do.  People should use the newer ones where possible.


That means not using the following when throwing nsresults/DOMExceptions:

  ErrorResult::Throw(nsresult)
  ErrorResult::operator=(nsresult)

and instead using:

  ErrorResult::ThrowDOMException(nsresult, const nsACString&)

which allows passing a message string that explains why the exception is 
being thrown.  Web developers will thank you and not post tweets like 
https://twitter.com/sebmck/status/1155709250225573889


When throwing TypeError or RangeError, ThrowTypeError/ThrowRangeError 
already require a message string, though I am making some changes in 
https://phabricator.services.mozilla.com/D45932 to make it a bit simpler 
to pass in custom message strings there.


Thank you all for making web developers' lives better,
Boris

P.S. We currently have a _lot_ of uses of the 
no-informative-error-message APIs.  Some of these might be things we 
don't really expect web pages to hit (e.g. exceptions when in the wrong 
type of global).  But generally speaking all ~560 uses of 
operator=(nsresult) are code smells, as are the ~1000 uses of 
Throw(NS_ERROR_DOM_*).

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

Re: [IMPORTANT] Submit your PI Requests for Firefox 71 QA feature testing by Sep 13

[Tom Grabowski]

Hi,

Just a reminder that the deadline for Fx71 PI Requests is today. Please log
your requests ASAP if you have not done so yet.

- Tom


On Wed, Sep 11, 2019 at 4:59 PM Tom Grabowski 
wrote:

>
> Similar to what QA did for previous Firefox feature testing prioritization
> ,
> we would like to do the same for Fx71. In order to help with the process,
> please *submit your pi-request
> *
> by *September 13*.
> This is needed to assure QA will be involved in your feature development
> work for the 71 cycle. Kindly ensure to update the *Priority of the PI
> request *(Highest, High, Medium, Low, Lowest) as during feature
> prioritization process, this will be factored in to ensure critical
> features have sufficient resources assigned.
>
> Please note that the *Feature technical documentation* for *features
> require beta testing* needs to be ready before *September 27*. Please
> follow the Feature Technical Documentation Guidelines Template
> 
> and share the information with the QA owners or add the link in the PI
> request in JIRA. 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. If the work is critical
> please follow the Exception approval process
> 
>
> * 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*
> A: In order to remain flexible, we will keep some percentage of time open
> for requests like these. Such requests need to follow the Exception
> approval process
> 
>
> *Q: There's no way I'm going to remember to do this.*
> A: Do it now!
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

[dilyan.palau...@aegee.org]

Hello,

On Tuesday, 10 September 2019 16:19:01 UTC, Honza Bambas  wrote:
> There is no official or standardized way to "force" authentication, 
> because this is really a non-standard thing you do.

Can you ellaborate on this and why is it off-standard?  What shall have been 
written in the standards, in order to support this use-case?

RFC 7235 says “A user agent that wishes to authenticate itself with an origin 
server -- usually, but not necessarily, after receiving a 401 (Unauthorized)  
-- can do so by including an Authorization header field with the request.”

So if the user insists to authenticate, the server does not have to reply with 
401.  The way to get the supported schemas, apart from sending an invalid 
username with random password, is to make an OPTIONS call (on my server, which 
happens to be also semi-standard):

curl -D-  -XOPTIONS https://mail.aegee.org/dav

HTTP/2 200 
content-length: 0
cache-control: no-cache
www-authenticate: Basic realm="AEGEE.ORG"
www-authenticate: Negotiate
allow: OPTIONS, GET, HEAD

Now, is the problem in the core of firefox/thunderbird, in the standards, in 
the sevrer or in the addon?  In particular, does the core really refuse to deal 
with the authentication once the addon inserts an Authentication header?  This 
makes it practically impossible to switch later to Negotiate: GSS-SPNEGO after 
inserting a fake Authentication header, as doing this negotiation for an addon 
is way too much.

Regards
  Дилян
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Web IDL constructor syntax

[Boris Zbarsky]

On 9/13/19 3:54 AM, Christopher Mills wrote:

I've updated the MDN WebIDL guide to include a section on the new syntax:


Chris,

Thank you!

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

Re: Intent to unship: TLS 1.0 and TLS 1.1

[Henri Sivonen]

On Fri, Sep 13, 2019 at 3:09 AM Martin Thomson  wrote:
>
> On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen  wrote:
>>
>> Do we know what the situation looks like for connections to RFC 1918 
>> addresses?
>
> That's a hard one to even speculate about, and that's all we really have 
> there.  Our telemetry doesn't really allow us to gain insight into that.

I see.

> The big question being enterprise uses, where there is some chance of having 
> names on servers in private address space.  Most use of 1918 outside of 
> enterprise is likely still unsecured entirely.

I was thinking of home printer, NAS and router config UIs that are
unsecured in the sense of using self-signed certificates but that
still use TLS, so that TLS matters for practical compatibility. I
don't know of real examples of devices that both use TLS exclusively
and don't support TLS 1.2. (My printer redirects http to https with
self-signed cert but supports TLS 1.2.)

--
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Web IDL constructor syntax

[Christopher Mills]

Thanks Boris.

I've updated the MDN WebIDL guide to include a section on the new syntax:

https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#New_constructor_syntax

(and the new Chrome-only syntax you talked about in your other mail:
https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#Available_only_in_system_code
)

Chris Mills
MDN content lead & writers' team manager
Mozilla Developer Network 
@chrisdavidmills 


On Fri, Sep 13, 2019 at 1:25 AM Boris Zbarsky  wrote:

> As of today, the syntax for Web IDL constructors no longer involves an
> extended attribute on the interface.  There's now something that looks
> more like a method named "constructor" with no explicitly-defined return
> type.
>
> So this:
>
>[Constructor(DOMString str)]
>interface MyInterface {};
>
> is now written like so:
>
>interface MyInterface {
>  constructor(DOMString str);
>};
>
> This means we can now specify extended attributes on the constructor,
> and therefore we no longer assume that all constructors throw.  If yours
> does, you can use [Throws] in the usual way to indicate that:
>
>interface ThrowingConstructor {
>  [Throws] constructor();
>};
>
> It may take some time for specifications to update to the new syntax
> because not all of the tooling is updated yet; see
> https://github.com/heycam/webidl/issues/778 which tracks that.  So in
> the meantime, including new spec IDL that uses constructors may require
> some hand-editing to get it into the new form.
>
> -Boris
> ___
> 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