Re: Intent To Require Manifests For Vendored Code In mozilla-central

this should be: https://goo.gl/QZyz4x for the full specification. This format is essentially assuming the vendored code comes from a VCS repository. We have plenty of third party code that is imported through upstream tarballs, so this should probably be accounted for. we can certainly

Re: Intent To Require Manifests For Vendored Code In mozilla-central

this should be: https://goo.gl/QZyz4x for the full specification. This format is essentially assuming the vendored code comes from a VCS repository. We have plenty of third party code that is imported through upstream tarballs, so this should probably be accounted for. we can certainly

Re: Intent To Require Manifests For Vendored Code In mozilla-central

thanks for the feedback martin, Please consider adding hg.mozilla.org to your list of things you will clone from. adding support to vendor from hg.m.o is a great suggestion, and shouldn't be problematic once the work has been proven with github. You don't permit the use of a tag for vendoring,

Re: Intent To Require Manifests For Vendored Code In mozilla-central

On Mon, Apr 9, 2018 at 9:52 PM, Mike Hommey wrote: > On Tue, Apr 10, 2018 at 02:46:40PM +1000, Martin Thomson wrote: > > This seems like a good idea. > > > > Please consider adding hg.mozilla.org to your list of things you will > > clone from. That will allow us to remove

Re: Intent To Require Manifests For Vendored Code In mozilla-central

On Tue, Apr 10, 2018 at 02:46:40PM +1000, Martin Thomson wrote: > This seems like a good idea. > > Please consider adding hg.mozilla.org to your list of things you will > clone from. That will allow us to remove some ugly hacks from the > tree for vendoring NSS and NSPR. (libffi uses the same

Re: Intent To Require Manifests For Vendored Code In mozilla-central

On Tue, Apr 10, 2018 at 12:33:27PM +0800, Byron Jones wrote: > glob wrote: > > The plan is to create a YAML file for each library containing metadata > > such as the homepage url, vendored version, bugzilla component, etc. See > > https://goo.gl/QZyz4xfor the full specification. > > this should

Re: Intent To Require Manifests For Vendored Code In mozilla-central

This seems like a good idea. Please consider adding hg.mozilla.org to your list of things you will clone from. That will allow us to remove some ugly hacks from the tree for vendoring NSS and NSPR. (libffi uses the same script, but it seems to be on GitHub now, so that seems like an easy win

Re: Intent To Require Manifests For Vendored Code In mozilla-central

glob wrote: The plan is to create a YAML file for each library containing metadata such as the homepage url, vendored version, bugzilla component, etc. See https://goo.gl/QZyz4xfor the full specification. this should be: https://goo.gl/QZyz4x for the full specification. -- glob —

Intent To Require Manifests For Vendored Code In mozilla-central

mozilla-central contains code vendored from external sources. Currently there is no standard way to document and update this code. In order to facilitate automation around auditing, vendoring, and linting we intend to require all vendored code to be annotated with an in-tree YAML file, and for

Intent to implement and ship: same-site cookies

We intend to ship same-site cookies in Firefox 61. This new cookie attribute allows sites to prevent cross-site requests from using those cookies which provides a mechanism for web sites to protect themselves against Cross-Site Request Forgery (CSRF) attacks. Specification (cookies):

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote: > Do we have a heuristic for when to /not/ include something from HTML in SVG? If it doesn't make two features which already exist in both HTML and SVG more consistent, then I wouldn't include it. > More or less, these additions to SVG just

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

Do we have a heuristic for when to /not/ include something from HTML in SVG? More or less, these additions to SVG just strike me as having solid potential risk (for both spec-interaction and implementation bugs) and negligible upside. Do we have people asking for this? Are there privacy concerns

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On Tue, Apr 10, 2018, at 7:56 AM, Jeff Gilbert wrote: > Can we not put more things into SVG? Making SVG more complicated seems > like it should be an anti-goal for the web platform. I think we should align the features and behavior of HTML and SVG . something I don't see why the

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

Can we not put more things into SVG? Making SVG more complicated seems like it should be an anti-goal for the web platform. On Mon, Apr 9, 2018 at 2:11 PM, wrote: > Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, > hreflang, type and text properties.

Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, hreflang, type and text properties. SVG anchor elements should support these properties too according to the SVG 2 specification and https://github.com/w3c/svgwg/issues/315. Bug:

Re: testing event targets for memory leaks

On Mon, Apr 9, 2018 at 3:16 PM, Randell Jesup wrote: > I'm surprises that DOMDataChannel wasn't found: > nsDOMDataChannel.h: > class nsDOMDataChannel final : public mozilla::DOMEventTargetHelper, > > perhaps you were looking for "public DOMEventTargetHelper"? > Yep.

Re: Editing a vendored crate for a try push

On Monday, April 9, 2018 at 11:39:35 AM UTC-4, Henri Sivonen wrote: > How do I waive .cargo-checksum.json checking for a crate? In bug 1449613 (part 12) I just hand-edited the .cargo-checksum.json in question, and updated the sha256 values for the modified files. That was enough to get try runs

Re: Is realloc() between bucket sizes worthwhile with jemalloc?

On Mon, Apr 9, 2018 at 4:58 AM, Henri Sivonen wrote: > My understanding is that under some "huge" size, jemalloc returns > allocations from particularly-sized buckets. > The mozjemalloc source has a decent ascii-art table [1]. > This makes me expect that realloc()

Re: Phabricator and Bugzilla

>As I indicated, those posts go into detail on why we are avoiding both >comment and more complicated flag mirroring. > >Mark There's no obvious discussion of "flags" in the linked discussions you gave; I find only a couple of references to "flag" - in a question from gps. Given how long the

Re: testing event targets for memory leaks

>Hi all, > >I recently landed some test infrastructure for testing event targets for >memory leaks. This was part of fixing my service worker memory leak in bug >1447871. I wanted to let people know this existed and also ask for help >writing tests for more event targets. > >To repeat, I need

Re: testing event targets for memory leaks

On Mon, Apr 9, 2018 at 12:32 PM, Ben Kelly wrote: > On Mon, Apr 9, 2018 at 12:06 PM, Boris Zbarsky wrote: > >> On 4/5/18 1:11 PM, Ben Kelly wrote: >> >>> 1. Make sure you set the nsIGlobalObject owner by passing it to the DETH >>> constructor or by calling

Re: Intent to implement and ship: Blocking FTP subresources

Good idea. Opened a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1452701 At least in the Chrome bug somebody was complaining that web cam page was broken by this change. Seems like the reloading image was embedded over FTP. On Mon, Apr 9, 2018 at 5:54 PM, Patrick McManus

Re: Intent to implement and ship: Blocking FTP subresources

imo, you really need to add a pref to cover this (I'm not saying make it opt-in, just preffable.). It will break something somewhere and at least you can tell that poor person they can have compat back via config. It also has a very small possibility of breaking enterprises or something we would

Re: Uint8Array in XPIDL

On Mon, Apr 9, 2018 at 1:22 AM, Henri Sivonen wrote: > In order to remove XPIDL interfaces when corresponding Web Platform > features are available, I've been trying to get our internal JS code > to switch from nsIScriptableUnicodeConverter to TextDecoder and > TextEncoder.

Re: testing event targets for memory leaks

On Mon, Apr 9, 2018 at 12:06 PM, Boris Zbarsky wrote: > On 4/5/18 1:11 PM, Ben Kelly wrote: > >> 1. Make sure you set the nsIGlobalObject owner by passing it to the DETH >> constructor or by calling BindToOwner(). >> > > Can we just enforce that by: > > 1) Removing the no-arg

Re: Editing a vendored crate for a try push

Also sprach Henri Sivonen: > What's the current status of tooling for editing vendored crates for > local testing and try pushes? > > It looks like our toml setup is too complex for cargo edit-locally to > handle (or, alternatively, I'm holding it wrong). It also seems that > mach edit-crate

Re: testing event targets for memory leaks

On 4/5/18 1:11 PM, Ben Kelly wrote: 1. Make sure you set the nsIGlobalObject owner by passing it to the DETH constructor or by calling BindToOwner(). Can we just enforce that by: 1) Removing the no-arg constructor from DETH. 2) Making the arg-taking constructors MOZ_ASSERT that the arg is

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

Hi Masayuki, First of all, thank you for taking on this task. I have a few questions. * What does the backwards compatibility story for these changes look like? Would we end up for example throwing exceptions or returning a different value from execCommand/queryCommandState/etc for one of the

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

On Thu, Apr 5, 2018 at 11:08 PM Masayuki Nakano wrote: > On 4/6/2018 2:50 AM, Ehsan Akhgari wrote: > > Hi Masayuki, > > > > First of all, thank you for taking on this task. I have a few questions. > > > > * What does the backwards compatibility story for these changes

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

> * Add new command "enableAbsolutePositionEditing" command for allowing to enable #4 There is no way to use absolute position editing on Firefox because cmd_abspos is used by comm-central only. So I guess that it might be unnecessary to add this command for Firefox and is better to add a

Re: CPU core count game!

On Sat, Mar 31, 2018 at 10:12 AM Steve Fink wrote: > Yes, sorry, a couple of people pointed that out to me privately. And I > did get that mixed up; I was assuming processors, despite the page > specifically pointing out "physical cores". > > I still think there's something to

Is realloc() between bucket sizes worthwhile with jemalloc?

My understanding is that under some "huge" size, jemalloc returns allocations from particularly-sized buckets. This makes me expect that realloc() between bucket sizes is going to always copy the data instead of just adjusting allocated metadata, because to do otherwise would mess up the

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

On 4/7/2018 12:39 AM, Ehsan Akhgari wrote: On Thu, Apr 5, 2018 at 11:08 PM Masayuki Nakano > wrote: On 4/6/2018 2:50 AM, Ehsan Akhgari wrote: > Hi Masayuki, > > First of all, thank you for taking on this task.  I have a few

Re: Intent to ship: macOS Flash NPAPI Sandbox

On Tue, Mar 20, 2018 at 10:54 AM, Haik Aftandilian wrote: > We intend to ship a process-level sandbox for the NPAPI Flash plugin on > macOS in 61. This will provide a degree of process isolation at the expense > of some lesser-used Flash functionality[1]. You can

Editing a vendored crate for a try push

What's the current status of tooling for editing vendored crates for local testing and try pushes? It looks like our toml setup is too complex for cargo edit-locally to handle (or, alternatively, I'm holding it wrong). It also seems that mach edit-crate never happened. How do I waive

[Linux/Mesa/AMDGPU] infos about GFX1 error messages

Good day, I am working on testing various Mesa versions on an AMDGPU driver based platform, because I am experiencing this problem https://youtu.be/Tt44jJ1KDdI (black / white squares on webpage view) Firefox bugreport https://bugzilla.mozilla.org/show_bug.cgi?id=1421353 Mesa bugreport

Re: incremental compilation for opt Rust builds

On 05/04/18 14:19, Henri Sivonen wrote: Can we make a particular vendored crate (encoding_rs) use -O3 while the default for Rust code remains at -O2? There’s an accepted RFC for "per-crate profiles" but it’s not implemented yet: https://github.com/rust-lang/rust/issues/48683 -- Simon Sapin

Uint8Array in XPIDL

In order to remove XPIDL interfaces when corresponding Web Platform features are available, I've been trying to get our internal JS code to switch from nsIScriptableUnicodeConverter to TextDecoder and TextEncoder. The main problem is that XPCOM streams expose binary buffers as JS strings where

Intent to implement and ship: Blocking FTP subresources

Summary: All FTP subresources in HTTPs pages (this also includes blob: etc) will be blocked. Opening FTP links as toplevel documents is still possible. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1404744 Platform coverage: All Target release: Firefox 61 (this already landed, but we forgot

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

On 4/6/2018 2:50 AM, Ehsan Akhgari wrote: Hi Masayuki, First of all, thank you for taking on this task.  I have a few questions. * What does the backwards compatibility story for these changes look like?  Would we end up for example throwing exceptions or returning a different value from

Are there some lists of web sites which use vertical writing-mode?

Hi, I'm currently reviewing bug 1358017 which tries to scroll vertical writing mode contents horizontally with vertical mouse wheel operation for some mice which have only vertical wheel and etc. https://bugzilla.mozilla.org/show_bug.cgi?id=1358017 I'd like to check actual behavior with

Intent to unship: DOMCursor

In https://bugzilla.mozilla.org/show_bug.cgi?id=1451929 I plan to remove DOMCursor. It seems to be completely unused, and probably has been since b2g code was removed. The interface object _is_ exposed to the web, which is why I'm sending this intent... There could in theory be sites using

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

On 4/6/2018 9:25 AM, Makoto Kato wrote: > * Add new command "enableAbsolutePositionEditing" command for allowing to enable #4 There is no way to use absolute position editing on Firefox because cmd_abspos is used by comm-central only.  So I guess that it might be unnecessary to add this

Re: testing event targets for memory leaks

On Thu, Apr 5, 2018 at 12:18 PM, Ben Kelly wrote: > If one of these targets falls in your area, please try to find the time to > write a small test as described above. Also, please link it against the > meta bug here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1451787

[Linux/Mesa/AMDGPU] infos about GFX1 error messages

Good day, I am working on testing various Mesa versions on an AMDGPU driver based platform, because I am experiencing this problem https://youtu.be/Tt44jJ1KDdI (black / white squares on webpage view) Firefox bugreport https://bugzilla.mozilla.org/show_bug.cgi?id=1421353 Mesa bugreport

Re: PSA: Building Firefox 61+ with GCC will soon require version GCC 6.1+

Good stuff, thanks Jeff! To be pedantic, don't you mean "start relying on *more* c++14 features"? Because we've already been able to use some C++14 features since November 2017 (see bug 1325632, landed in 59). E.g., I and others have used initialized lambda captures since then -- saving quite

testing event targets for memory leaks

Hi all, I recently landed some test infrastructure for testing event targets for memory leaks. This was part of fixing my service worker memory leak in bug 1447871. I wanted to let people know this existed and also ask for help writing tests for more event targets. To repeat, I need help