What is the future of XMLHttpRequest.mozAnon ?

[john.bieling--- via dev-platform]

Is mozAnon going to stay or are you thinking about removing that in the future?

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/mozAnon

Thanks for your time,
John
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Fetch API] Headers.get("WWW-Authenticate") does not return anything, if server sends more than one such header

[john.bieling--- via dev-platform]

I created a bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1491010
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Changes to BMO-Phabricator integration

[Mark Côté]

(apologies: this was sent out to firefox-dev and dev.platform yesterday but
for some reason appears not to have made it to the latter)


To reduce confusion and a growing maintenance burden, the Engineering
Workflow team plans to remove two pieces of Phabricator-Bugzilla
integration:


   1.

   The setting of r+ flags on the stub attachments in that link to
   Phabricator revisions (https://bugzilla.mozilla.org/
   show_bug.cgi?id=1490687).
   2.

   The Phabricator table in Bugzilla’s “My Requests” page (
   https://bugzilla.mozilla.org/show_bug.cgi?id=1487422
   ).


We plan on adding one more piece of integration: a panel on bug views
(show_bug.cgi) that shows the status of Phabricator revisions in
Phabricator’s terms, similar to the old MozReview table (
https://bugzilla.mozilla.org/show_bug.cgi?id=1489706).

The “stub attachments” will remain for the time being in order to
facilitate tracking non-review attachment flags (checkin-needed, etc).

# Rationale and background

There have been a lot of questions about our decisions surrounding
Bugzilla–Phabricator integration. We’ve expounded on those in various
threads over the last year and a half, but I will try to go into more
specifics.

At the start of the Phabricator project, having learned a lot from
MozReview, we consciously decided to limit the amount of integration to
Bugzilla. This not only reduces upfront costs and maintenance burden but
also avoids the complexity and ambiguity inherent in mixing two different
systems together. Aside from necessary linkages like authentication,
accounts, and security groups, the only other integration we implemented
was the setting of r+ statuses on stub attachments and, later, adding
Phabricator requests to BMO’s “My Dashboard”.

Unfortunately both of these have had bugs and caused confusion. Since
comments aren’t mirrored, the plain r+s were sometimes misleading if the
revisions (or Phabricator’s email notifications) weren’t also consulted
before landing. The requests view on “My Dashboard” suffered from bugs that
resulted in missing requests and was further impacted by our experiments
with reviewer groups that have no real analog in Bugzilla.

# Differing models

The central problem is that the models behind the two systems—Bugzilla’s
attachments and flags, Phabricator’s revisions and reviews—are very
different. Phabricator’s revisions have a much richer and more complex set
of metadata than Bugzilla attachments. It is essentially impossible to
represent Phabricator states as Bugzilla flags while preserving anything
close to the expected semantics of the latter; consulting Phabricator would
often be needed to make sense of any translated representation in Bugzilla.
Further, Phabricator’s model is also subject to changes and additions (for
example, the draft revision state, which is still being modified), which
creates additional fragility and maintenance burden. Finally, not all the
details we need are even exposed through APIs, in part because they are in
flux.

# Adding revision statuses to bugs

That said, we realize that seeing at a glance the state of revisions
associated with a given bug is very useful. We are building support into
Bugzilla to view revision data without translation into Bugzilla’s terms to
avoid any confusion as to the true state of revisions.

While we could also dump data from Phabricator’s dashboard into Bugzilla’s
“My Dashboard”, it would be much more work and more difficult to maintain,
since Phabricator’s dashboard itself is being updated. Furthermore, as all
code reviews are transitioned to Phabricator, the importance of this
dashboard will grow, and the number of requests in Bugzilla will shrink.
Thus relying on Phabricator to do what it does best is the better solution
for the future.

# Acknowledging difficulties

We are aware that splitting code review out into a separate system is a
huge change. We realize that, with our new tools and the decisions we have
made around integration, we are asking you to change your workflows by
setting up different email rules, looking in different places for the data
you need, communicating with other Mozillians in different ways, and
perhaps even establishing new practices and norms around code review. It
will take time to adapt. However we are already seeing benefits in terms of
automation that we haven’t previously been able to do (just one example: a
user set up Herald rules to notify of changes that impact localization),
and we will continue to build on this framework to accomplish goals that
have been talked about for many years. Allowing the tools to do what they
are best at lets us focus on new functionality, including suggested
reviewers, Try support for Lando, Lando notifications, fully automated
landings, and other items on our road map (https://wiki.mozilla.org/
Engineering_Workflow/Road_Map).

We appreciate your feedback and support as we work to improve the tools you
use 

Re: [Fetch API] Headers.get("WWW-Authenticate") does not return anything, if server sends more than one such header

[Ehsan Akhgari]

On Thu, Sep 13, 2018 at 9:40 AM john.bieling--- via dev-platform <
dev-platform@lists.mozilla.org> wrote:

> I encountered something strange. I am on TB60 trying to use the Fetch API.
>
> I create a GET or POST request without authentication and get back a 401
> from the server and use
>
>response.headers.get("WWW-Authenticate")
>
> to eval the allowed authentication methods. This works fine, if the server
> sends only one such header. If however he sends two or more,
> Headers.get("WWW-Authenticate") returns null.
>
> I only observe this for the WWW-Authenticate header, other headers - if
> send multiple times - will simply be returned as a list (joined by colon).
>
> Is this a bug? Am I doing something wrong?
>
> This is a example set of headers, that is not accessible:
>
> WWW-Authenticate: Negotiate
> WWW-Authenticate: Basic realm="Contact and Calendar data"
>

Hmm, this may be a bug.  When there are multiple WWW-Authenticate headers,
we have a special case for merging them (with a newline character instead
of a comma):
https://searchfox.org/mozilla-central/rev/a23c3959b62cd3f616435e02810988ef5bac9031/netwerk/protocol/http/nsHttpHeaderArray.h#268
so it's possible something in the fetch code fails to handle this.  If you
have a test case, I suggest filing a bug so that someone can debug this.


> Also: Why was Headers.getAll() dropped after Gecko 52? The digest auth
> header includes colons himself and if it is returned joined into a list
> together with some other auth method, it will be very difficult to parse
> that.
>

See https://bugzilla.mozilla.org/show_bug.cgi?id=1278275.  That was a
non-standard method which was removed.

An interesting question is what we return from Headers.get() for
WWW-Authenticate, given that the fetch spec calls for pasting the multiple
header values together with ", " but Gecko internally pastes them together
with "\n"...

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

[Fetch API] Headers.get("WWW-Authenticate") does not return anything, if server sends more than one such header

[john.bieling--- via dev-platform]

I encountered something strange. I am on TB60 trying to use the Fetch API.

I create a GET or POST request without authentication and get back a 401 from 
the server and use 

   response.headers.get("WWW-Authenticate")

to eval the allowed authentication methods. This works fine, if the server 
sends only one such header. If however he sends two or more, 
Headers.get("WWW-Authenticate") returns null.

I only observe this for the WWW-Authenticate header, other headers - if send 
multiple times - will simply be returned as a list (joined by colon).

Is this a bug? Am I doing something wrong?

This is a example set of headers, that is not accessible:

WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Contact and Calendar data"

Also: Why was Headers.getAll() dropped after Gecko 52? The digest auth header 
includes colons himself and if it is returned joined into a list together with 
some other auth method, it will be very difficult to parse that.

Thanks for your help,
John
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform