Re: Intent to implement: Feature Policy
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 policy determination (headers, inheritance from parents, etc). > Agreed, seems like at least it's worth having a bug on file and reaching out to the devtools team to see if they can help with this. We also have https://bugzilla.mozilla.org/show_bug.cgi?id=1449501 open to display the CSP policy, perhaps it might make sense to expose both in similar ways (or at least for similar contexts, e.g. iframes). -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebRender on in Firefox Nightly for Windows 10 Nvidia
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 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, but generally nothing serious. We have quite a few staff >> and volunteers who have been using WebRender for months without major >> issues. >> >> If you're on this hardware and you see a problem please file a bug. >> You can check if you're using WebRender by looking at the Compositing >> section of about:support. Further, WebRender should be generally >> usable on all platforms other than Android right now so if you want to >> be keen you can try it out now with the gfx.webrender.all pref. >> >> -Jeff > > Congrats on the milestone. > > That said, I do want to report that my attempt to try it failed miserably. > > I installed the new nightly. Upon first opening, I noticed that the welcome > page was having minor glitches, white lines flickering when scrolling. > > Testing on one of my own pages (some arguably complex in compositing) I see > several misplaced pixels, shadows breaking, etc. The browser then crashed, > then froze up all of Windows for a few minutes. > > After shutting down Nightly via task manager, I opened up Developer Edition, > my go-to browser. It seems the Nighty crash took down all of that too. I've > tried several restarts but it failed to launch. I had to start from a new > profile, and lost all my optimizations, add-ons, history, passwords. > > Maybe I'm just terribly unlucky. I'm on Windows 10 using a Nvidia GTX1070. I > allowed the sending of crash reports when it crashed. > > ___ > 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
Re: WebRender on in Firefox Nightly for Windows 10 Nvidia
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, but generally nothing serious. We have quite a few staff > and volunteers who have been using WebRender for months without major > issues. > > If you're on this hardware and you see a problem please file a bug. > You can check if you're using WebRender by looking at the Compositing > section of about:support. Further, WebRender should be generally > usable on all platforms other than Android right now so if you want to > be keen you can try it out now with the gfx.webrender.all pref. > > -Jeff Congrats on the milestone. That said, I do want to report that my attempt to try it failed miserably. I installed the new nightly. Upon first opening, I noticed that the welcome page was having minor glitches, white lines flickering when scrolling. Testing on one of my own pages (some arguably complex in compositing) I see several misplaced pixels, shadows breaking, etc. The browser then crashed, then froze up all of Windows for a few minutes. After shutting down Nightly via task manager, I opened up Developer Edition, my go-to browser. It seems the Nighty crash took down all of that too. I've tried several restarts but it failed to launch. I had to start from a new profile, and lost all my optimizations, add-ons, history, passwords. Maybe I'm just terribly unlucky. I'm on Windows 10 using a Nvidia GTX1070. I allowed the sending of crash reports when it crashed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Feature Policy
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). -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: Feature Policy
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 define feature policies for nested contexts. * a WebIDL interface that allows querying the features. My implementation covers all these 3 aspects. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 Link to standard: https://wicg.github.io/feature-policy/ Platform coverage: everywhere. Estimated or target release: I would like to enable this feature only in nightly for a cycle after landing. This would probably be 65. Preference behind which this will be implemented: dom.security.featurePolicy.enabled Is this feature enabled by default in sandboxed iframes? Yes, it is DevTools bug: No devtools support. Do other browser engines implement this? Chromium, since 63. Safari since 11.1 (partially - only 'allowed' attributed is supported). web-platform-tests: There are several policy WPTs features. With my patches we are almost green everywhere, ignoring payment API and picture-in-picture. Is this feature restricted to secure contexts? No, it isn’t. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
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 because of the current behavior [= returning a \n-joined list] is not advised Since it was brought up already in this topic, how can I eval cert errors with fetch()? For XHR I can get the underlying channel and request a nsresult: xhr.channel.QueryInterface(Components.interfaces.nsIRequest).status Is there a way to do something like this with a fetch() response? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
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
Re: What is the future of XMLHttpRequest.mozAnon ?
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 getting off-topic :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
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 it's a bug in XMLHttpRequest caused by Necko's API: https://bugzilla.mozilla.org/show_bug.cgi?id=1491010. XMLHttpRequest and fetch() should be equivalent when it comes to headers. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
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 here. 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. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
> 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". Since a digest auth header includes "," itself, XHR is for me the better option here. Also I have not yet been able to eval cert errors on connections with fetch(), which I can do with XHR. For fetch() I just get a general network error. Maybe there is a way, but I have not found it yet. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
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.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
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 :-) Thanks for your time, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
