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

[Byron Jones]

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 support tarballs at a later stage.  i've expanded the 
comment for the url field to indicate it can point any location, with 
the limitations applying to automated vendoring.



How does this fit with rust vendoring? Most if not all the information
from your proposed moz.yaml is available in Cargo.toml. Do we need to
duplicate this? Does mach vendor rust need to create moz.yaml files from
Cargo.toml when it does the vendoring?
i don't think there's a need to duplicate the information that's in 
Cargo.toml.  if this pans out to be problematic moz.yaml generation 
during rust vendoring sounds viable.


--
glob — engineering workflow — moz://a

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

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

[Byron Jones]

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 support tarballs at a later stage.  i've expanded the 
comment for the url field to indicate it can point any location, with 
the limitations applying to automated vendoring.



How does this fit with rust vendoring? Most if not all the information
from your proposed moz.yaml is available in Cargo.toml. Do we need to
duplicate this? Does mach vendor rust need to create moz.yaml files from
Cargo.toml when it does the vendoring?
i don't think there's a need to duplicate the information that's in 
Cargo.toml.  if this pans out to be problematic moz.yaml generation 
during rust vendoring sounds viable.


--
glob — engineering workflow — moz://a

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

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

[glob]

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, is that intentional?

to echo gps and mike's responses use of a sha to is preferred over tags.



--
glob — engineering workflow — moz://a

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

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

[Gregory Szorc]

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 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 assuming
> > even that libffi still uses that script.)  We could use the NSS GitHub
> > mirror, but NSPR doesn't have one yet and those can't be the only
> > projects that we have using mercurial.  Of course, if that is the
> > case, then don't worry, we'll just have to talk more seriously about
> > moving NSS to GitHub.
> >
> > You don't permit the use of a tag for vendoring, is that intentional?
> > Tags for releases are so commonplace that you should consider it.  You
> > shouldn't need a branch AND a tag either.  More so because branches
> > move, which makes them not reliable here.
> >
> > Having a version in addition to a tag is redundant and therefore
> > likely to result in mismatches.  I'd say that the tag is enough.
>
> I'd say a revision should be mandatory. Branches and tags can change.
> Revisions can't.


I'll reaffirm this. The full hash of a revision - at least in Mercurial and
Git - means more than a branch or a tag. Both the branch name and a tag are
symbolic and can move. Even if you GPG sign a tag, someone could steal your
signing key and re-sign a new tag for a different revision and a VCS
`verify` command would happily accept it because the signature is valid! A
revision hash, however, is constant for all of time and a revision hash
cannot change out from under you to refer to different content.

Or at least that's the theory. Hash collisions /could/ occur. However, the
actual probability of a hash collision is currently far less than the
probability that someone moves a pointer on the symbolic branch or tag name
because a SHA-1 preimage attack is currently far more difficult than
running VCS operations [that Mercurial or Git let you run out of the box]
which let you update a symbolic name.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Mike Hommey]

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 script, but it
> seems to be on GitHub now, so that seems like an easy win assuming
> even that libffi still uses that script.)  We could use the NSS GitHub
> mirror, but NSPR doesn't have one yet and those can't be the only
> projects that we have using mercurial.  Of course, if that is the
> case, then don't worry, we'll just have to talk more seriously about
> moving NSS to GitHub.
> 
> You don't permit the use of a tag for vendoring, is that intentional?
> Tags for releases are so commonplace that you should consider it.  You
> shouldn't need a branch AND a tag either.  More so because branches
> move, which makes them not reliable here.
> 
> Having a version in addition to a tag is redundant and therefore
> likely to result in mismatches.  I'd say that the tag is enough.

I'd say a revision should be mandatory. Branches and tags can change.
Revisions can't.

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

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

[Mike Hommey]

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 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.

How does this fit with rust vendoring? Most if not all the information
from your proposed moz.yaml is available in Cargo.toml. Do we need to
duplicate this? Does mach vendor rust need to create moz.yaml files from
Cargo.toml when it does the vendoring?

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

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

[Martin Thomson]

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 assuming
even that libffi still uses that script.)  We could use the NSS GitHub
mirror, but NSPR doesn't have one yet and those can't be the only
projects that we have using mercurial.  Of course, if that is the
case, then don't worry, we'll just have to talk more seriously about
moving NSS to GitHub.

You don't permit the use of a tag for vendoring, is that intentional?
Tags for releases are so commonplace that you should consider it.  You
shouldn't need a branch AND a tag either.  More so because branches
move, which makes them not reliable here.

Having a version in addition to a tag is redundant and therefore
likely to result in mismatches.  I'd say that the tag is enough.

(FWIW, NSS does some of its own vendoring for test runs, so maybe you
could look at https://searchfox.org/nss/source/fuzz/config/git-copy.sh
- vendoring git repos without pulling history turned out to have a few
gotchas.)

On Tue, Apr 10, 2018 at 2:25 PM, glob  wrote:
> 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
> the vendoring process to be standardised and automated.
>
>
> 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/QZyz4x for the full specification.
>
>
> We will work with teams to add moz.yaml files where required, as well as
> adding the capability for push-button vendoring of new revisions.
>
>
> Please address comments to the dev-platform list.
>
> --
> glob — engineering workflow — moz://a
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Byron Jones]

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 — engineering workflow — moz://a

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

Intent To Require Manifests For Vendored Code In mozilla-central

[glob]

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 the vendoring process to be standardised and automated.



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.



We will work with teams to add moz.yaml files where required, as well as 
adding the capability for push-button vendoring of new revisions.



Please address comments to the dev-platform list.

--
glob — engineering workflow — moz://a

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

Intent to implement and ship: same-site cookies

[Francois Marier]

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):
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=795346

Platform coverage: all

Gating preference: network.cookie.same-site.enabled

Devtools support: https://bugzilla.mozilla.org/show_bug.cgi?id=1452715

Developer documentation:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives

Web Platform Tests: http://rfc6265.biz/tests/ (until
https://github.com/w3c/web-platform-tests/issues/8581 is fixed)

Secure contexts: not restricted to secure contexts since cookies are
already available in non-secure contexts

Other browsers:
- Chrome shipped this feature in 51.
- Safari: https://bugs.webkit.org/show_bug.cgi?id=159464
- Edge: https://github.com/MicrosoftEdge/Status/issues/201

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

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

[Cameron McCormack]

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 strike me as having solid
> potential risk (for both spec-interaction and implementation bugs) and
> negligible upside. Do we have people asking for this?

I don't know of people asking for this, but I would hope that we could share 
the implementations of these properties between HTMLAnchorElement and 
SVGAElement.  The closer the two  elements are in behavior, and the more we 
can share implementation between them, the lower the risk for bugs between the 
two.  (Ignoring the general risk of bugs from touching code at all.)

> Are there privacy concerns from embedding pings (et al) in images? I
> suppose we better have been handling CORS requests from within SVGs
> properly already, so it should Just Work?

SVG as images don't have scripting and can't be interacted with to activate 
links, so I don't think it's a concern there.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jeff Gilbert]

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 from embedding pings (et al) in images? I
suppose we better have been handling CORS requests from within SVGs
properly already, so it should Just Work?

On Mon, Apr 9, 2018 at 6:26 PM, Cameron McCormack  wrote:
> 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 two DOM objects for the HTML  and SVG  should 
> behave substantially differently.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Cameron McCormack]

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 two DOM objects for the HTML  and SVG  should behave 
substantially differently.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jeff Gilbert]

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. SVG anchor elements should support these 
> properties too according to the SVG 2 specification and 
> https://github.com/w3c/svgwg/issues/315.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1451823
>
> Platform coverage: All
> Target release: Firefox 61
> Preference behind which this will be implemented: None
> Is this feature enabled by default in sandboxed iframes: Yes, enabled 
> everywhere
> DevTools bug: None
> Do other browser engines implement this? Microsoft are working on an 
> implementation for Edge. They have created web platform tests for this.
> web-platform-tests: https://github.com/w3c/web-platform-tests/pull/10275
> Secure contexts: n/a
> ___
> 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

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

[longsonr]

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: https://bugzilla.mozilla.org/show_bug.cgi?id=1451823

Platform coverage: All
Target release: Firefox 61
Preference behind which this will be implemented: None
Is this feature enabled by default in sandboxed iframes: Yes, enabled everywhere
DevTools bug: None
Do other browser engines implement this? Microsoft are working on an 
implementation for Edge. They have created web platform tests for this.
web-platform-tests: https://github.com/w3c/web-platform-tests/pull/10275
Secure contexts: n/a 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: testing event targets for memory leaks

[Ben Kelly]

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.  That was indeed my lame search.


>
> I also find nsScreen and nsDOMOfflineResourceList using
> mozilla::DOMEventTargetHelper
>
> Are there any events implemented in JS that we need to worry about?  For
> example, there are a lot of events (and a number of objects) defined for
> WebRTC as part of dom/media/PeerConnection.js
>

Having test coverage would be prudent, I think.  I'm not sure what can
break in the js event target world.

Thanks.

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

Re: Editing a vendored crate for a try push

[twisniewski]

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 going (though the debug builds do show related failures, they 
still built and ran my tests).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Eric Rahm]

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() between bucket sizes is going to
> always copy the data instead of just adjusting allocated metadata,
> because to do otherwise would mess up the bucketing.
>

Sure, but not all reallocs are between bucket sizes. You can realloc from
1KB to 1.99KB and end up in the same bucket.


> Is this so? Specifically, is it actually useful that nsStringBuffer
> uses realloc() as opposed to malloc(), memcpy() with actually
> semantically filled amount and free()?
>
> Upon superficial code reading, it seems to me that currently changing
>
the capacity of an nsA[C]STring might uselessly use realloc to copy
> data that's not semantically live data from the string's point of view
> and wouldn't really need to be preserved. Have I actually discovered
> useless copying or am I misunderstanding?
>

In this case I think you're right. In the string code we use a doubling
strategy up to 8MiB so they'll always be in a new bucket/chunk. After 8MiB
we grow by 1.125 [2], but always round up to the nearest MiB. Our
HugeRealloc logic always makes a new allocation if the difference is
greater than or equal to 1MiB [3] so that's always going to get hit. I
should note that on OSX we use some sort of 'pages_copy' when the realloc
is large enough, this is probably more efficient than memcpy.

-e

[1]
https://searchfox.org/mozilla-central/rev/7ccb618f45a1398e31a086a009f87c8fd3a790b6/memory/build/mozjemalloc.cpp#59-88
[2]
https://searchfox.org/mozilla-central/rev/7ccb618f45a1398e31a086a009f87c8fd3a790b6/xpcom/string/nsTSubstring.cpp#88-119
[3]
https://searchfox.org/mozilla-central/rev/7ccb618f45a1398e31a086a009f87c8fd3a790b6/memory/build/mozjemalloc.cpp#3811-3874

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

Re: Phabricator and Bugzilla

[Randell Jesup]

>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 thread is (52 posts), perhaps you can point to
something more specific?  Thanks

>On Sat, Mar 31, 2018 at 10:14 AM, Ben Kelly  wrote:
>
>> On Sat, Mar 31, 2018, 10:09 AM Mark Côté  wrote:
>>
>>> Regarding comment and flag mirroring, we've discussed this before:
>>>
>>> https://groups.google.com/d/msg/mozilla.dev.platform/
>>> Y8kInYxo8UU/e3Pi-_FpBgAJ
>>> https://groups.google.com/d/msg/mozilla.dev.platform/
>>> Y8kInYxo8UU/tsF7UfxvBgAJ
>>>
>>> Given that Phabricator is still new, I don't see any reason to reopen
>>> that discussion at this point, aside from noting that we have work in
>>> progress to include Phabricator requests in BMO's My Dashboard and
>>> notifications indicator (https://bugzilla.mozilla.org/
>>> show_bug.cgi?id=1440828).
>>>
>>
>> What about comment mirroring?  On my mobile so I haven't read all the past
>> threads, but my recollection is that your team did not want to implement
>> that feature.  Personally, this is a huge concern for me.
>>
>> Thanks.
>>
>> Ben
>>
>>
>>> As for interdiffs, feel free to file a bug with any problems you see.  We
>>> have a good relationship with upstream and can pass those on.  Similarly
>>> with method names (which has been mentioned before but I can't find where
>>> at the moment).
>>>
>>> There is official documentation at https://secure.phabricator.
>>> com/book/phabricator/ which is linked from our Mozilla-specific docs (
>>> http://moz-conduit.readthedocs.io/en/latest/phabricator-user.html) which
>>> in turn is linked in the left-hand menu in Phabricator.  We can expand our
>>> own docs as needed if there are areas that are particularly confusing due
>>> to, say, expectations carried over from our other code-review tools.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: testing event targets for memory leaks

[Randell Jesup]

>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 writing more tests.  Please see the list of untested
>APIs at the bottom of this email.

>There are many, many event targets in the system, though.  Using searchfox
>to look for subclasses of DOMEventTargetHelper I came up with a list of
>event targets that are not currently tested.  Some of these are deprecated
>or not exposed.  But a lot of these are web exposed.  It would be really
>great to get this kind of simple leak test written for these APIs.

I'm surprises that DOMDataChannel wasn't found:
nsDOMDataChannel.h:
  class nsDOMDataChannel final : public mozilla::DOMEventTargetHelper,

perhaps you were looking for "public DOMEventTargetHelper"?

I also find nsScreen and nsDOMOfflineResourceList using
mozilla::DOMEventTargetHelper

Are there any events implemented in JS that we need to worry about?  For
example, there are a lot of events (and a number of objects) defined for
WebRTC as part of dom/media/PeerConnection.js

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: testing event targets for memory leaks

[Ben Kelly]

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 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 not
>> null.
>>
>> ?  We'd need to fix some existing code, but after that should hopefully
>> be in a better place...
>>
>
> This would be nice to do yes, but was out of scope for the time I had.  I
> also suspect, though, that the non-binding DETH constructor is used for
> objects created using the separate Init() method pattern.  Not sure if its
> fair to try to convert all of those.
>
> Also keep in mind that binding to the global on a worker thread is
> somewhat new.  Many DETH objects only try to bind nsPIDOMWindowInner, but
> it would be better to always bind nsIGlobalObject now.
>
> Anyway, we should probably file a bug to consider it.
>

Filed as:

https://bugzilla.mozilla.org/show_bug.cgi?id=1452705
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Blocking FTP subresources

[Tom Schuster]

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  wrote:
> 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 discover late, and we would want to be able to push a pref to fix
> that.
>
>
> On Mon, Apr 9, 2018 at 9:13 AM, Tom Schuster  wrote:
>>
>> 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 to send
>> this, sorry!)
>> Preference behind which this will be implemented: None
>> Is this feature enabled by default in sandboxed iframes: Yes, enabled
>> everywhere
>> DevTools bug: None
>> Do other browser engines implement this?
>> Chrome shipped in M62?
>> web-platform-tests: No
>> Secure contexts: n/a
>> ___
>> 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: Intent to implement and ship: Blocking FTP subresources

[Patrick McManus]

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 discover late, and we would want to be able to push a pref to fix
that.


On Mon, Apr 9, 2018 at 9:13 AM, Tom Schuster  wrote:

> 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 to send
> this, sorry!)
> Preference behind which this will be implemented: None
> Is this feature enabled by default in sandboxed iframes: Yes, enabled
> everywhere
> DevTools bug: None
> Do other browser engines implement this?
> Chrome shipped in M62?
> web-platform-tests: No
> Secure contexts: n/a
> ___
> 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: Uint8Array in XPIDL

[Bobby Holley]

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.
>
> The main problem is that XPCOM streams expose binary buffers as JS
> strings where the lower half of each UTF-16 code unit is a byte value
> whereas new Web Platform APIs use Uint8Array for binary.
>
> It seems that we have some Uint8Array support in XPIDL, but it
> involves rather complicated XPIDL syntax, so it's easier to figure out
> how to use ACString.
>
> Do we have the following and documentation is just lacking? If not,
> should we have these?
>
>

>  * Ability to declare Uint8Array in XPIDL with the same ease as ACString
>

We don't have this, unless you count passing a jsval. I think you're really
asking for integration with the WebIDL TypedArray C++ helpers, which allow
you to interface with a TypedArray idiomatically and ignore the fact that
it's backed by a JS Object.

Adding this would be straightforward but a bit of work. Would need a new
builtin XPIDL type and support for it in all the right places.


>  * Ability to pass a Uint8Array from JS to an XPIDL method that takes
> an ACString
>

We don't have this, but we do have code to pass a Uint8Array as an XPIDL
[array]. Reworking that same code to support an ACString target is probably
pretty easy.


>  * Have a method in nsIScriptableInputStream to read an Uint8Buffer
> with the same ease as reading the string and without the complication
> of nsIBinaryInputStream.readArrayBuffer().
>

I don't have anything useful to say on this one.


>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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: testing event targets for memory leaks

[Ben Kelly]

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 constructor from DETH.
> 2)  Making the arg-taking constructors MOZ_ASSERT that the arg is not null.
>
> ?  We'd need to fix some existing code, but after that should hopefully be
> in a better place...
>

This would be nice to do yes, but was out of scope for the time I had.  I
also suspect, though, that the non-binding DETH constructor is used for
objects created using the separate Init() method pattern.  Not sure if its
fair to try to convert all of those.

Also keep in mind that binding to the global on a worker thread is somewhat
new.  Many DETH objects only try to bind nsPIDOMWindowInner, but it would
be better to always bind nsIGlobalObject now.

Anyway, we should probably file a bug to consider it.

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

Re: Editing a vendored crate for a try push

[Andreas Tolfsen]

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 never happened.
> 
> How do I waive .cargo-checksum.json checking for a crate?

I don’t know the exact answer to your question, but it might be
possible to temporarily depend on the crate by a its path?

There are a couple of examples of this in
https://searchfox.org/mozilla-central/source/testing/geckodriver/Cargo.toml.

Remember to run "cargo update -p ".

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

Re: testing event targets for memory leaks

[Boris Zbarsky]

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 not null.

?  We'd need to fix some existing code, but after that should hopefully 
be in a better place...


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

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

[Ehsan Akhgari]

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 existing two
commands?  If there are any backwards compatibility concerns, what are your
plans for them?  Note that these two commands are extremely popular in
existing code that knows about Gecko (since it typically has to start off
by disabling this UI as you've noted.)

* Why are we *adding* a new command for enabling the absolute positioning
UI if we believe this UI is not useful and should be disabled?  Do we have
any indication that web developers want to use this UI in some cases, and
for Firefox only?  Have we heard any plans from other browser vendors that
they're interested to add support for similar UI in the future?  The Github
issue you linked to makes that sound unlikely.  Wouldn't it be better to
just disable the absolute positioning UI?

* What is our long term plan for this UI, do we want to keep them around or
is this us deprecating the UI with the ultimate intention of measuring
their usage so that we can eventually remove them?  I think removing this
UI is at least desirable from the implementation standpoint.  The way that
the native anonymous content this UI uses is hooked up (in
https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/editor/libeditor/HTMLAnonymousNodeEditor.cpp#143)
is different than everything else inside Gecko and has historically been a
source of bugs, and we've never invested any effort to improve it since we
believed the UI wasn't really worth the investment...

Thanks,
Ehsan

On Thu, Apr 5, 2018 at 11:04 AM Masayuki Nakano 
wrote:

> This incompatibility is pointed by W3C's Editing API WG:
> https://github.com/w3c/editing/issues/171
>
> Gecko has some specific editing UI of HTML editor.
> 1. Resiziers of , , absolute positioned elements.
> 2. Adding new table row/column from buttons.
> 3. Removing existing table row/column from buttons.
> 4. Grabber to move absolute positioned element.
>
> Currently, all of those UIs are not implemented by the other browsers.
> However, they are available in Gecko by default.
>
> Therefore, web app developers need to disable those features with:
> document.execCommand("enableObjectResizing",
>   false, false); // #1
> document.execCommand("enableInlineTableEditing",
>   false, false); // #2 and #3
>
> So, if web apps don't call them, only Firefox users can modify  or
>  elements as unexpected for their developers.
>
> Additionally, web apps cannot disable only #4.
>
> So, for solving this incompatibility issue, we should:
> * Disable those UI by default
> * But allow to enable those UI for backward compatibility
> * Add new command "enableAbsolutePositionEditing" command for allowing
> to enable #4
>
> I'm working on this incompatibility issue in:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1449564
>
> --
> Masayuki Nakano 
> Software Engineer, Mozilla
> ___
> 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: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

[Ehsan Akhgari]

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 look
> > like?  Would we end up for example throwing exceptions or returning a
> > different value from execCommand/queryCommandState/etc for one of the
> > existing two commands?  If there are any backwards compatibility
> > concerns, what are your plans for them?  Note that these two commands
> > are extremely popular in existing code that knows about Gecko (since it
> > typically has to start off by disabling this UI as you've noted.)
>
> It *might* be possible that a few web apps (including intranet only
> apps) may allow users to resize some elements, edit table structure
> and/or move absolute positioned elements with these built-in UI only on
> Firefox. If such apps actually exist, they can enable the Gecko specific
> UI explicitly with using execCommand.  Then, we can collect actual usage
> with telemetry.
>

If such apps don't use execCommand to explicitly enable these commands,
they will be breaking with this change, wouldn't they?  If we are
interested in knowing about whether this is a problem, there's the
possibility of collecting telemetry beforehand too.  For example, we can
collect telemetry upon the usage of these UIs (i.e., when a user interacts
with them) and record information about whether the application has called
one of these commands explicitly to enable the UI beforehand.

If we don't collect this telemetry beforehand, we're effectively assuming
that the breakage of this kind will be low enough that we are considering
its risk low and acceptable.


> > * Why are we *adding* a new command for enabling the absolute
> > positioning UI if we believe this UI is not useful and should be
> > disabled?  Do we have any indication that web developers want to use
> > this UI in some cases, and for Firefox only?  Have we heard any plans
> > from other browser vendors that they're interested to add support for
> > similar UI in the future?  The Github issue you linked to makes that
> > sound unlikely.  Wouldn't it be better to just disable the absolute
> > positioning UI?
>
> I think that Gecko specific feature may cause unexpected result for web
> apps and could cause unexpected error on some web apps, then, at worst,
> Firefox is banned by UA sniffing.


Hmm, if the risk of removing this UI is so high, then shouldn't we collect
some telemetry data that shows that removing it is safe before attempting
to do so?

(FWIW I don't understand how this UI showing and not showing can break an
editing app so badly that web developers start to ban Firefox UAs.  One way
I can imagine is if they attempt to provide their own similar UI and ours
overrides it, but since we are talking about changing things to hide the UI
that we used to show, I don't think that's the risk you have in mind.)


> Making it's disabled by default but
> making it possible to enable with execCommand, we can collect actual
> usage with telemetry as I said above.
>

I think we can collect some telemetry data today.  For example, we can
collect data on how many HTML editor instantiations see the absolute
positioning UI, and also how many of the times we display this UI the user
ends up interacting with it.

The problem with adding a new command and try to collect telemetry after
that is that you're expecting Web developers to first update their code to
use the new command before any meaningful telemetry data can be gathered,
and then our hope would be that the data would suggest that the feature is
unused so that we can tell the few Web developers who did update their code
to use the new command to update it again to remove the command once we
decide to remove this UI based on low usage.  :-)


> > * What is our long term plan for this UI, do we want to keep them around
> > or is this us deprecating the UI with the ultimate intention of
> > measuring their usage so that we can eventually remove them?  I think
> > removing this UI is at least desirable from the implementation
> > standpoint.  The way that the native anonymous content this UI uses is
> > hooked up (in
> >
> https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/editor/libeditor/HTMLAnonymousNodeEditor.cpp#143
> )
> > is different than everything else inside Gecko and has historically been
> > a source of bugs, and we've never invested any effort to improve it
> > since we believed the UI wasn't really worth the investment...
>
> I think that we'll get evidence which indicate nobody uses those Gecko
> specific feature, we can move those UI into comm-central or just remove
> them completely.
>

Hmm, if we want to keep them around for comm-central, then I'm not all that
certain if moving the code out of m-c is beneficial since this code impacts
the way 

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

[Makoto Kato]

> * 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
preference to enable it as default.

-- Makoto

On Thu, Apr 5, 2018 at 3:58 PM, Masayuki Nakano 
wrote:

> This incompatibility is pointed by W3C's Editing API WG:
> https://github.com/w3c/editing/issues/171
>
> Gecko has some specific editing UI of HTML editor.
> 1. Resiziers of , , absolute positioned elements.
> 2. Adding new table row/column from buttons.
> 3. Removing existing table row/column from buttons.
> 4. Grabber to move absolute positioned element.
>
> Currently, all of those UIs are not implemented by the other browsers.
> However, they are available in Gecko by default.
>
> Therefore, web app developers need to disable those features with:
> document.execCommand("enableObjectResizing",
>  false, false); // #1
> document.execCommand("enableInlineTableEditing",
>  false, false); // #2 and #3
>
> So, if web apps don't call them, only Firefox users can modify  or
>  elements as unexpected for their developers.
>
> Additionally, web apps cannot disable only #4.
>
> So, for solving this incompatibility issue, we should:
> * Disable those UI by default
> * But allow to enable those UI for backward compatibility
> * Add new command "enableAbsolutePositionEditing" command for allowing to
> enable #4
>
> I'm working on this incompatibility issue in:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1449564
>
> --
> Masayuki Nakano 
> Software Engineer, Mozilla
> ___
> 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: CPU core count game!

[Ehsan Akhgari]

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 be kept in mind here, though. Even
> with 4 processors (2 hyperthreaded cores or whatever), it's never
> correct to assume that running something on a different thread is a gold
> bullet for performance problems. I'm all for increasing the concurrency
> of our code as long as we ensure that it doesn't hurt in the case of low
> levels of actual parallelism.
>
> What that means in practice, I'm not entirely sure, but it does seem
> like we should be more conscious about thread priorities and global
> thread pool management. Also, lock contention is a real thing. It has
> been coming up here and there and wiping out parallelization gains.
>

We have bug 1366358 filed about properly specifying thread priorities,
which is especially important for systems with lower number of cores.

Last year during the Quantum Flow project we came across various bugs which
manifested as various threads running at a higher priority than some very
important thread (such as the compositor thread) resulting in situations
where we couldn't run any code on the compositor thread for several frames
which show up as whole-UI jank.

I think fixing the dependencies of that bug is a good systematic protection
against bad performance situations like that.


>
> On 3/28/18 10:27 AM, Ben Kelly wrote:
> > That page says "physical cores", so its not taking into account hyper
> > threading, right?  So even a high end macbook pro falls in that category?
> >
> > On Tue, Mar 27, 2018 at 5:02 PM, Mike Conley  > > wrote:
> >
> > Thanks for drawing attention to this, sfink.
> >
> > This is likely to become more important as we continue to scale up
> our
> > parallelization with content processes and threads.
> >
> > On 21 March 2018 at 14:54, Steve Fink  > > wrote:
> >
> > > Just to drive home a point, let's play a game.
> > >
> > > First, guesstimate what percentage of our users have systems
> > with 2 or
> > > fewer cores.
> > >
> > > Then visit
> > https://hardware.metrics.mozilla.com/#goto-cpu-and-memory
> >  to
> > > check your guess.
> > >
> > > (I didn't say it was a *fun* game.)
> > >
> > >
> > > ___
> > > 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  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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Is realloc() between bucket sizes worthwhile with jemalloc?

[Henri Sivonen]

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 bucketing.

Is this so? Specifically, is it actually useful that nsStringBuffer
uses realloc() as opposed to malloc(), memcpy() with actually
semantically filled amount and free()?

Upon superficial code reading, it seems to me that currently changing
the capacity of an nsA[C]STring might uselessly use realloc to copy
data that's not semantically live data from the string's point of view
and wouldn't really need to be preserved. Have I actually discovered
useless copying or am I misunderstanding?

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

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

[Masayuki Nakano]

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
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
> existing two commands?  If there are any backwards compatibility
> concerns, what are your plans for them?  Note that these two
commands
> are extremely popular in existing code that knows about Gecko
(since it
> typically has to start off by disabling this UI as you've noted.)

It *might* be possible that a few web apps (including intranet only
apps) may allow users to resize some elements, edit table structure
and/or move absolute positioned elements with these built-in UI
only on
Firefox. If such apps actually exist, they can enable the Gecko
specific
UI explicitly with using execCommand.  Then, we can collect actual
usage
with telemetry.


If such apps don't use execCommand to explicitly enable these 
commands, they will be breaking with this change, wouldn't they?


Yes, it is, of course.

If we are interested in knowing about whether this is a problem, 
there's the possibility of collecting telemetry beforehand too.  For 
example, we can collect telemetry upon the usage of these UIs (i.e., 
when a user interacts with them) and record information about whether 
the application has called one of these commands explicitly to enable 
the UI beforehand.


If we don't collect this telemetry beforehand, we're effectively 
assuming that the breakage of this kind will be low enough that we are 
considering its risk low and acceptable.


Okay, I'll change the default behavior only on Nightly before landing 
and I'll file a bug to collect telemetry data before landing the patches 
for the bug.



> * Why are we *adding* a new command for enabling the absolute
> positioning UI if we believe this UI is not useful and should be
> disabled?  Do we have any indication that web developers want to use
> this UI in some cases, and for Firefox only?  Have we heard any
plans
> from other browser vendors that they're interested to add
support for
> similar UI in the future?  The Github issue you linked to makes that
> sound unlikely.  Wouldn't it be better to just disable the absolute
> positioning UI?

I think that Gecko specific feature may cause unexpected result
for web
apps and could cause unexpected error on some web apps, then, at
worst,
Firefox is banned by UA sniffing.


Hmm, if the risk of removing this UI is so high, then shouldn't we 
collect some telemetry data that shows that removing it is safe before 
attempting to do so?
I worry about some specific cases such as using Firefox as default 
browser in organization and depending on such feature. I don't worry 
about public web apps since if those features are necessary, they need 
to implement those features by themselves anyway since the other 
browsers don't have the features.
(FWIW I don't understand how this UI showing and not showing can break 
an editing app so badly that web developers start to ban Firefox UAs.  
One way I can imagine is if they attempt to provide their own similar 
UI and ours overrides it, but since we are talking about changing 
things to hide the UI that we used to show, I don't think that's the 
risk you have in mind.)


I worry about the case, if web app vendors don't want to allow users to 
modifying sizes, positions, etc, it means that only Firefox users may 
change them if they didn't disable the UI with the Gecko specific 
commands. If related applications of such web apps do not assume such 
points are changeable, they may receive complains only from Firefox 
users. It must be annoying thing for their business manager since the 
market share isn't high.



Making it's disabled by default but
making it possible to enable with execCommand, we can collect actual
usage with telemetry as I said above.


I think we can collect some telemetry data today.  For example, we can 
collect data on how many HTML editor instantiations see the absolute 
positioning UI, and also how many of the times we display this UI the 
user ends up interacting with it.


The problem with adding a new command and try to collect telemetry 
after that is that you're expecting Web developers to first update 
their code to use the new command before any meaningful telemetry data 
can be gathered, and then our hope would be that the data would 
suggest that the feature is unused so that we can tell the few Web 
developers who did update their code to use the new command to update 
it 

Re: Intent to ship: macOS Flash NPAPI Sandbox

[Haik Aftandilian]

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 enable the sandbox now
> on Nightly, globally for all sites, by setting
> dom.ipc.plugins.sandbox-level.flash=1 and restarting the browser[2].
> Before this rides the trains, we intend to offer a per-site opt-out UI. But
> we will enable this on Nightly by default earlier to get early feedback.
>

The Mac Flash sandbox is
​now ​
enabled by default on Nightly.

​Thanks,
Haik
​

>
> If you run Firefox on Mac and depend on any Flash sites, please give the
> site a try with the sandbox enabled. And if you encounter any issues,
> please file bugs blocking bug 1433577[3].
>
> Thanks,
> Haik
>
> 1. Flash applets that attempt to write to the filesystem will be impacted
> because the plugin process has limited write access. Adobe Air installs
> triggered by Flash applets will no longer work. Printing to PDF or
> postscript, and Open in Preview from the print dialog does not work. No
> issues have been found with any Flash games.
>
> 2. The same pref is used on Windows, but the numerical levels are not
> comparable or related in any way to the Mac version.
>
> 3. https://bugzilla.mozilla.org/show_bug.cgi?id=1433577
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Editing a vendored crate for a try push

[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 never happened.

How do I waive .cargo-checksum.json checking for a crate?

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

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

[germano . massullo]

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 https://bugs.freedesktop.org/show_bug.cgi?id=104216

During my tests I found out that the problem occurs when Firefox prints the 
following error messages. What can you tell me about?

Best regards

$ LD_LIBRARY_PATH='mesa18/usr/lib64/' LIBGL_DRIVERS_PATH='mesa18/usr/lib64/dri' 
firefox
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed buffer for 0, -1, 12, 498
[GFX1-]: Failed buffer for 0, 0, 1100, 579
IPDL protocol error: [PNeckoChild] Received an invalid file descriptor!
Sandbox: bad read from pid 2691: Message too long
Sandbox: Unexpected EOF, op 0 flags 00 path 
/usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf
[GFX1-]: Failed buffer for 0, 0, 1112, 539
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
IPDL protocol error: [PNeckoChild] Received an invalid file descriptor!
IPDL protocol error: [PNeckoChild] Received an invalid file descriptor!
[Parent 2403, Gecko_IOThread] WARNING: SCM_RIGHTS message was truncated 
cmsg_len:20 fd:58: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 400
[Child 2586, Chrome_ChildThread] WARNING: pipe error (21): Connection reset by 
peer: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 353

###!!! [Child][MessageChannel] Error: 
(msgtype=0x4C0002,name=PLayerTransaction::Msg_Update) Channel error: cannot 
send/recv

[GFX1-]: Receive IPC close with reason=AbnormalShutdown
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768

###!!! [Child][MessageChannel] Error: 
(msgtype=0x4,name=PAPZCTreeManager::Msg_UpdateZoomConstraints) Channel error: 
cannot send/recv

[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: ClientLayerManager::BeginTransaction with IPC channel down. GPU 
process may have died.
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 48
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 0, 0, 1112, 539
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, 

Re: incremental compilation for opt Rust builds

[Simon Sapin]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Uint8Array in XPIDL

[Henri Sivonen]

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 the lower half of each UTF-16 code unit is a byte value
whereas new Web Platform APIs use Uint8Array for binary.

It seems that we have some Uint8Array support in XPIDL, but it
involves rather complicated XPIDL syntax, so it's easier to figure out
how to use ACString.

Do we have the following and documentation is just lacking? If not,
should we have these?

 * Ability to declare Uint8Array in XPIDL with the same ease as ACString
 * Ability to pass a Uint8Array from JS to an XPIDL method that takes
an ACString
 * Have a method in nsIScriptableInputStream to read an Uint8Buffer
with the same ease as reading the string and without the complication
of nsIBinaryInputStream.readArrayBuffer().

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

Intent to implement and ship: Blocking FTP subresources

[Tom Schuster]

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 to send
this, sorry!)
Preference behind which this will be implemented: None
Is this feature enabled by default in sandboxed iframes: Yes, enabled everywhere
DevTools bug: None
Do other browser engines implement this?
Chrome shipped in M62?
web-platform-tests: No
Secure contexts: n/a
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Masayuki Nakano]

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 execCommand/queryCommandState/etc for one of the 
existing two commands?  If there are any backwards compatibility 
concerns, what are your plans for them?  Note that these two commands 
are extremely popular in existing code that knows about Gecko (since it 
typically has to start off by disabling this UI as you've noted.)


It *might* be possible that a few web apps (including intranet only 
apps) may allow users to resize some elements, edit table structure 
and/or move absolute positioned elements with these built-in UI only on 
Firefox. If such apps actually exist, they can enable the Gecko specific 
UI explicitly with using execCommand.  Then, we can collect actual usage 
with telemetry.


* Why are we *adding* a new command for enabling the absolute 
positioning UI if we believe this UI is not useful and should be 
disabled?  Do we have any indication that web developers want to use 
this UI in some cases, and for Firefox only?  Have we heard any plans 
from other browser vendors that they're interested to add support for 
similar UI in the future?  The Github issue you linked to makes that 
sound unlikely.  Wouldn't it be better to just disable the absolute 
positioning UI?


I think that Gecko specific feature may cause unexpected result for web 
apps and could cause unexpected error on some web apps, then, at worst, 
Firefox is banned by UA sniffing.  Making it's disabled by default but 
making it possible to enable with execCommand, we can collect actual 
usage with telemetry as I said above.


* What is our long term plan for this UI, do we want to keep them around 
or is this us deprecating the UI with the ultimate intention of 
measuring their usage so that we can eventually remove them?  I think 
removing this UI is at least desirable from the implementation 
standpoint.  The way that the native anonymous content this UI uses is 
hooked up (in 
https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/editor/libeditor/HTMLAnonymousNodeEditor.cpp#143) 
is different than everything else inside Gecko and has historically been 
a source of bugs, and we've never invested any effort to improve it 
since we believed the UI wasn't really worth the investment...


I think that we'll get evidence which indicate nobody uses those Gecko 
specific feature, we can move those UI into comm-central or just remove 
them completely.


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Masayuki Nakano]

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 actual devices on web sites which 
use vertical writing-mode in real world before making it enabled in 
release channel.


Does somebody know some lists of web sites which use vertical 
writing-mode? Unfortunately, I don't know web sites which use 
writing-mode heavily even though I usually read web sites written in 
Japanese...


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: DOMCursor

[Boris Zbarsky]

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 it to detect Firefox.


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

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

[Masayuki Nakano]

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 command for Firefox and is better to add a 
preference to enable it as default.


No, try this:

1. Go to https://d-toybox.com/studio/lib/input_event_viewer.html
2. Input "div" into 
the first  next to .

3. Select the radio button labelled .
4. Click black border box under the toolbars.

Then, you'll see grabber to move the black border box at top edge of the 
box and you can move the box with dragging. That's one of the feature of 
absolutely positioned editor available even on Firefox.


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: testing event targets for memory leaks

[Ben Kelly]

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
>

Sorry to self-reply to an already long email, but...

Here are some hints to fix leaks in DOMEventTargetHelper (DETH) sub-classes:

1. Make sure you set the nsIGlobalObject owner by passing it to the DETH
constructor or by calling BindToOwner().
2. Override the DisconnectFromOwner() method to perform any cleanup.  This
is now consistently called when the window is doomed.

Failing to do (1) caused MediaQueryList to leak (bug 1450271).  We believe
failing to do (2) is causing the worker API to leak.

In the past code has had to use nsIObserver to listen for
inner-window-destroyed in order to do cleanup.  This was due to
DisconnectFromOwner() not always getting called consistently.  This should
now be fixed as of bug 1450266.  It should now be possible to replace these
old listeners with a simpler DisconnectFromOwner() override.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Germano Massullo]

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 https://bugs.freedesktop.org/show_bug.cgi?id=104216

During my tests I found out that the problem occurs when Firefox prints the 
following error messages. What can you tell me about?

Best regards
$ LD_LIBRARY_PATH='mesa18/usr/lib64/' LIBGL_DRIVERS_PATH='mesa18/usr/lib64/dri' 
firefox
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[GFX1-]: Failed buffer for 0, -1, 12, 498
[GFX1-]: Failed buffer for 0, 0, 1100, 579
IPDL protocol error: [PNeckoChild] Received an invalid file descriptor!
Sandbox: bad read from pid 2691: Message too long
Sandbox: Unexpected EOF, op 0 flags 00 path 
/usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf
[GFX1-]: Failed buffer for 0, 0, 1112, 539
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
[Parent 2403, Main Thread] WARNING: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/base/shared_memory_posix.cc,
 line 216
[GFX1-]: Failed to lock new back buffer.
IPDL protocol error: [PNeckoChild] Received an invalid file descriptor!
IPDL protocol error: [PNeckoChild] Received an invalid file descriptor!
[Parent 2403, Gecko_IOThread] WARNING: SCM_RIGHTS message was truncated 
cmsg_len:20 fd:58: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 400
[Child 2586, Chrome_ChildThread] WARNING: pipe error (21): Connection reset by 
peer: file 
/builddir/build/BUILD/mozilla-release-*cutted_by_me*/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 353

###!!! [Child][MessageChannel] Error: 
(msgtype=0x4C0002,name=PLayerTransaction::Msg_Update) Channel error: cannot 
send/recv

[GFX1-]: Receive IPC close with reason=AbnormalShutdown
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768

###!!! [Child][MessageChannel] Error: 
(msgtype=0x4,name=PAPZCTreeManager::Msg_UpdateZoomConstraints) Channel error: 
cannot send/recv

[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: ClientLayerManager::BeginTransaction with IPC channel down. GPU 
process may have died.
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 48
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 0, 0, 1112, 539
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, -1, 12, 54
[GFX1-]: Failed buffer for 0, 0, 1100, 768
[GFX1-]: Failed buffer for 1100, 0, 12, 539
[GFX1-]: Failed buffer for 0, 

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

[gsquelart]

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 a bit of boilerplate when capturing RefPtr's, and allowing capture of 
move-only things like UniquePtr.

Gerald


On Friday, April 6, 2018 at 1:00:03 AM UTC+10, Jeff Gilbert wrote:
> Bug 1444274 will bump our minimum GCC version to 6.1. GCC-7 will
> continue to work.
> 
> If you build with GCC instead of Clang on Linux, I've been told that
> the system gcc package for Ubuntu 16.04 LTS is gcc-5, so very soon
> you'll need to install a gcc-6 package to continue to build.
> 
> With a bump to GCC 6, along with the bump to vs2017, we should be able
> to start relying on c++14 features. This will help out with tracking
> upstream projects which are starting to rely in c++14, as well as
> letting us phase in new tools into our c++ toolbox. (relaxed constexpr
> is a big one)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

testing event targets for memory leaks

[Ben Kelly]

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 writing more tests.  Please see the list of untested
APIs at the bottom of this email.

To write an event target leak test you need to import this script:

  

And then call this function:

  await checkForEventListenerLeaks("Worker", useWorker);

The string is just a name to make reporting assertions easier.  The second
argument is a callback function where you exercise the API you want to test
for leaks.  In this case I'm testing the worker API:

  async function useWorker(contentWindow) {
contentWindow.messageCount = 0;
let w = new
contentWindow.Worker("data:application/javascript,self.postMessage({})");
w.onerror = _ => {
  contentWindow.errorCount += 1;
};
await new Promise(resolve => {
  w.onmessage = e => {
contentWindow.messageCount += 1;
resolve();
  };
   });
is(contentWindow.messageCount, 1, "message should be received");
  }

The callback function should add an event listener that holds the given
contentWindow alive.  Then try to leave the API in an active state to see
if its properly torn down when the test harness closes the window.

This particular test found that the Worker API leaks.  See bug 1451381.

I've written tests for a number of APIs so far:  ServiceWorker*, XHR,
Animation, MediaQueryList, EventSource, BroadcastChannel, MessageChannel,
SharedWorker, AbortSignal, WebSocket, Notification

The WebSocket and Notification tests have not landed yet because they
trigger assertions.  These look like bugs in the respective APIs.

There are many, many event targets in the system, though.  Using searchfox
to look for subclasses of DOMEventTargetHelper I came up with a list of
event targets that are not currently tested.  Some of these are deprecated
or not exposed.  But a lot of these are web exposed.  It would be really
great to get this kind of simple leak test written for these APIs.

ContentFrameMessageManager
DOMRequest
ScreenOrientation
BatteryManager
OffscreenCanvas
ConstructibleEventTarget
FetchObserver
FileReader
IDBFileHandle
IDBMutableFileHandle
IDWrapperCache (and sub classes)
DOMMediaStream
MediaDevices
MediaRecorder
MediaStreamTrack
MediaTrack
MediaTrackList
TextTrack
TextTrackCue
TextTrackList
MediaKeySession
ImageCapture
MediaSource
SourceBuffer
SourceBufferList
AudioContext
AudioNode
SpeechRecognition
SpeechSynthesis
SpeechSynthesisUtterance
MIDIAccess
MIDIPort
Connection
TCPServerSocket
TCPSocket
UDPSocket
PaymentRequest
Performance
PermissionStatus
PresentationAvailability
PresentationConnection
PresentationConnectList
PresentationRequest
VRDisplay
FontFaceSet
ChannelWrapper
StreamFilter

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

Thanks!

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