On Fri, Sep 14, 2018 at 2:25 PM Boris Zbarsky wrote:
> On 9/14/18 1:58 PM, Andrea Marchesini wrote:
> > DevTools bug: No devtools support.
>
> Seems like devtools might be useful for answering questions like "what
> is the feature policy for this page and why?" given the complexity of
> feature p
Can you reproduce this? Either way, you can reply to me off list and
we can try to figure out what's going on.
-Jeff
On Fri, Sep 14, 2018 at 4:04 PM, wrote:
> On Wednesday, September 12, 2018 at 10:07:20 PM UTC+2, Jeff Muizelaar wrote:
>> In bug 1490742 I have enabled WebRender in Nightly on no
On Wednesday, September 12, 2018 at 10:07:20 PM UTC+2, Jeff Muizelaar wrote:
> In bug 1490742 I have enabled WebRender in Nightly on non-laptop
> Windows 10 Nvidia (~17% of our Nightly audience). This is a rewrite of
> much the graphics backend in Firefox. We expect some edge-case
> regressions, bu
On 9/14/18 1:58 PM, Andrea Marchesini wrote:
DevTools bug: No devtools support.
Seems like devtools might be useful for answering questions like "what
is the feature policy for this page and why?" given the complexity of
feature policy determination (headers, inheritance from parents, etc).
Summary: FeaturePolicy spec allows developers to enable or disable features
(browser features ad APIs) for their website and for 3rd party contexts.
FeaturePolicy consists in 3 mayor parts:
* a HTTP header with the policy, similar to CSP header
* an 'allowed' attribute for HTMLIFrameElements to de
So to summarize this topic and all the things that are currently going on:
- mozAnon is not to stay forever, because XHR is superseded by fetch() wich has
an option for that as well
- XHR.getResponseHeader() is going to be adjusted to match fetch() [= returning
a comma-joined list] so using XHR
N!
You may fix fetch() to support multiple auth headers again, but do not change
how XHR returns them :-)
What have I done ...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
I do not think they will change that. RFC 7230 defines that behavior and the
digest auth header is actually not a valid header in that respect. The mozilla
impl. actually had a "getAll" method, which returned an array instead of a
list. But that was non-standard and got removed. But we are getti
On Fri, Sep 14, 2018 at 12:50 PM Gijs Kruitbosch
wrote:
> This seems like an issue with the fetch spec (
> https://fetch.spec.whatwg.org/#concept-header-value-combined ) that you
> could report to them ( https://github.com/whatwg/fetch ) if that hasn't
> already been done.
FWIW, I'm pretty sure i
On 14/09/2018 10:34, john.biel...@googlemail.com wrote:
For example, if multiple www-authenticate headers are send, fetch will return them as a list joined by
"," while XHR returns them as a list joined by "\n". Since a digest auth header includes
"," itself, XHR is for me the better option her
> Isn't this the same as supplying the crossOrigin:anonymous option to
> fetch()?
That is true, that is why I wrote "in other features".
For example, if multiple www-authenticate headers are send, fetch will return
them as a list joined by "," while XHR returns them as a list joined by "\n".
On 14.09.2018 10:08, john.bieling--- via dev-platform wrote:
>... mozAnon XHR has advantages in other features over fetch().
Isn't this the same as supplying the crossOrigin:anonymous option to
fetch()?
___
dev-platform mailing list
dev-platform@lists
CromeOnly means, I can continue to use from (Thunderbird) AddOns, but not from
a website? That would be ok.
But removing it altogether would be a loss, because (with that mozAnon option)
XHR has advantages in other features over fetch().
If I could vote, I would like to +1 for keeping it :-)
T
13 matches
Mail list logo
