Re: Status of Ubuntu 20.04 as a development platform

[Kyle Huey]

On Tue, Nov 10, 2020 at 3:48 AM Henri Sivonen  wrote:
>
> Does Ubuntu 20.04 work properly as a platform for Firefox development?
> That is, does rr work with the provided kernel and do our tools work
> with the provided Python versions?

rr works. I use 20.04 personally.


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

Re: hg.mozilla.org SSL Certificate Renewal

[Kyle Huey]

Has FALLBACK_FINGERPRINT (in taskcluster/scripts/run-task) been
updated for this change?

- Kyle

On Thu, Oct 8, 2020 at 4:00 PM Connor Sheehan  wrote:
>
> tldr; run `mach vcs-setup` to update the pinned SSL certificate in your hgrc 
> files.
>
> hg.mozilla.org’s x509 server certificate (AKA an “SSL certificate”) will be 
> rotated on Monday, October 12th. Bug 1670031 tracks this change.
>
> You may have the certificate’s fingerprint pinned in your hgrc files. 
> Automated jobs may pin the fingerprint as well. If you have the fingerprint 
> pinned, you will need to take action otherwise Mercurial will refuse the 
> connection to hg.mozilla.org once the certificate is swapped.
>
> The easiest way to ensure your pinned fingerprint is up-to-date is to run 
> `mach vcs-setup` from a Mercurial checkout (it can be from an old revision). 
> Both the old and new fingerprints will be pinned and the transition will 
> “just work.” Once the new fingerprint is enabled on the server, run mach 
> vcs-setup again to remove the old fingerprint.
>
> Fingerprints and details of the new certificate (including hgrc config 
> snippets you can copy) are located at Bug 1670031. From a certificate level, 
> this transition is pretty boring: just a standard certificate renewal from 
> the same CA.
>
> The Matrix channel for this operational change will be #vcs. Fallout in 
> Firefox CI should be discussed in #ci. Please track any bugs related to this 
> change against Bug 1668017.
> ___
> 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: Opt your try pushes into Pernosco

[Kyle Huey via dev-platform]

On Mon, Nov 25, 2019 at 10:16 AM Valentin Gosu 
wrote:

> On Mon, 25 Nov 2019 at 18:29, Andrew Halberstadt  wrote:
>
>> Hi everyone,
>>
>> As of now, you can opt-in to Pernosco <https://pernos.co/> analysis on
>> your
>> try pushes by running:
>>
>> $ ./mach try fuzzy --pernosco
>>
>> or:
>>
>> $ ./mach try chooser --pernosco
>>
>> For those who are unaware, Pernosco is a debugging service built on top of
>> rr. It will analyze your try push for failures, attempt to record the
>> failures
>> with rr, then e-mail you a link to a live debugging session. Allow a few
>> hours
>> after your task has finished for the Pernosco recording to complete.
>>
>> There are several limitations:
>>
>> 1. It only works with Linux x64 debug tests
>> 2. Failure should be reproducible (otherwise the recording might not
>> capture it)
>> 3. An @mozilla.com e-mail address is required to log-in to the service
>> (./mach
>> try will fail early if you don't have this)
>>
>
> I only have push permissions on my @gmail account, not on my @mozilla.com
> one.
> Does this mean I can't trigger a --pernosco try build, or that I need to
> log with my @moz email in order to use Pernosco?
>

The latter. To log into Pernosco you need to have your @mozilla.com email
address listed on your Github account (doesn't have to be public). We can
whitelist people for whom that poses an issue if necessary.

- Kyle


>
>
>> 4. Artifact builds are not yet supported (see bug 1598142
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1598142>)
>>
>> Previously we were using a whitelist of developers to control which pushes
>> were
>> analyzed. For now this whitelist continues to exist. If you are on it, you
>> can opt
>> out of Pernosco by passing in `--no-pernosco`.
>>
>> Thanks to Kyle Huey for updating the Pernosco infrastructure to support
>> this
>> flag.
>>
>> Let me know if you have any questions.
>> Cheers,
>> Andrew
>> ___
>> 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: Please use nsGlobalWindow{Inner,Outer}

[Kyle Huey]

On Fri, Nov 10, 2017 at 8:41 AM, Nika Layzell  wrote:
> Hey,
>
> Bug 1414974 (https://bugzilla.mozilla.org/show_bug.cgi?id=1414974) is in
> mozilla-central, and it introduces the nsGlobalWindowInner and
> nsGlobalWindowOuter types. These represent inner and outer nsGlobalWindow
> objects, and can be cast from the nsPIDOMWindowInner/Outer objects using
> nsGlobalWindowInner/Outer::Cast.
>
> Please avoid introducing new code which uses nsGlobalWindow directly,
> instead using the specific types, as it is going away soon™.
>
> Thanks!
> Nika
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Nice to see that this is still moving forward!

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

Re: nsIAtom has been deCOMtaminated and is now called nsAtom

[Kyle Huey]

Awesome!

You couldn't get to mozilla::Atom?

- Kyle

On Oct 8, 2017 7:27 PM, "Nicholas Nethercote" 
wrote:

> Greetings,
>
> I have been deCOMtaminating nsIAtom over the past two months:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1392883.
>
> A big step that landed over a week ago was the devirtualization of nsIAtom,
> which means it is no longer a subclass of nsISupports:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1400459.
>
> And I just landed (on autoland) the final step of renaming nsIAtom as
> nsAtom. This is tracked at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1400460.
>
> Apologies for any conflicts or problems caused in outstanding patches. For
> patches less than 1.5 weeks old (i.e. post-devirtualization) it's very
> likely that simply replacing all nsIAtom occurrences with nsAtom will
> suffice. For patches older than that here is a summary of changes that
> might be required.
>
> - nsIAtom --> nsAtom
>
> - nsCOMPtr --> RefPtr
>
> - nsCOMArray --> nsTArray
>   - Count() --> Length()
>   - ObjectAt() --> ElementAt()
>   - AppendObject() --> AppendElement()
>   - RemoveObjectAt() --> RemoveElementAt()
>
> - ns*Hashtable -->
>   ns*Hashtable
>
> - nsInterfaceHashtable --> nsRefPtrHashtable
>
>   # If the array contains atoms.
> - nsCOMPtr --> nsTArray
>   - nsArrayBase::Create() --> nsTArray()
>   - GetLength() --> Length()
>   - do_QueryElementAt() --> operator[]
>
> Nick
> ___
> 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: Web IDL review checklist updated

[Kyle Huey]

On Mon, Apr 3, 2017 at 9:07 AM, Boris Zbarsky  wrote:
> I just updated https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist to
> remove some no-longer relevant bits and add various new parts.
>
> The primary audience for this document are people doing Web IDL reviews
> (bcced; you can see the list at
> ),
> but obviously anyone _requesting_ such review should consider running
> through the list before doing so.
>
> Suggestions for further additions (or just edits of the page!) are much
> appreciated.
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

There should probably be something about checking that the spec is
something other vendors are interested in, or that Mozilla has a good
reason to go ahead without them.

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

Re: Runnable labeling for Quantum DOM

[Kyle Huey]

On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky  wrote:
> P.S.  This is awesome.  ;)

Indeed.  So glad this is finally happening.

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

Re: Windows XP and Vista Long Term Support Plan

[Kyle Huey]

On Fri, Oct 21, 2016 at 3:05 AM,   wrote:
> My point for the above paragraph is that even if Mozilla stops security 
> updates for ESR 52, these computers will still need to get around on the 
> Internet. These machines will still need to do log ins and banking. The world 
> isn't the same as back in the day when Netscape 4 roamed the web or even in 
> 2008 when Mozilla dropped support for Windows 98 SE with 2.0.0.20. Part of 
> securing the web means making sure that every server has a digital 
> certificate with Let's Encrypt. But that part only works if the browser has 
> up to date TLS and digital certificates. What happens to Vista and XP on ESR 
> 52 or even OSX 10.6-10.8 on ESR 45 when a POODLE style attack drives everyone 
> from TLS 1.2 to TLS 1.3 with no fall back? What happens when older 
> certificates are found to have been compromised by a third party like a crime 
> syndicate or government intelligence agency? Do ESR 52 and ESR 45 get stuck 
> with corrupted certificates while the latest versions of Firefox get their 
> certificates refresh
 ed
>  ?

No.  These machines should not be on the Internet anymore.  If the
operating system vendor is no longer supporting their product with
security releases an out of date TLS stack is a minor problem compared
to the remote code execution that's going to pwn the machine.

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

Re: removing about:bloat

[Kyle Huey]

On Mon, Oct 10, 2016 at 2:07 PM, Andrew McCreight
 wrote:
> In bug 1308652, I'm planning on removing about:bloat. It disables XPCOM
> leak tracking while it is running, so running it can cause false negative
> leaks (bug 1271182). I don't think anybody uses it much any more, so I'm
> going to remove it.

Wow.  Hats off to you for tracking that down.

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

Re: Getting rid of already_AddRefed?

[Kyle Huey]

On Mon, Sep 12, 2016 at 10:53 AM, Daniel Holbert  wrote:
> On 08/12/2014 07:59 AM, Benjamin Smedberg wrote:
>> But now that nsCOMPtr/nsRefPtr support proper move constructors, [...]
>> Could we replace every already_AddRefed return value with a nsCOMPtr?
>
> I have a variant of bsmedberg's original question here. He asked about
> return values, but I'm wondering:
> Could we replace every already_AddRefed *function-parameter* with a move
> reference to a RefPtr/nsCOMPtr?
>
> (Sorry if this was answered in this thread; I skimmed through it &
> didn't find a definitive answer immediately. It seems like this might be
> a strictly easier thing to fix up, as compared to return values.)
>
> As a concrete example, at this usage site...
> https://dxr.mozilla.org/mozilla-central/rev/1851b78b5a9673ee422f189b92e5f1e86b82a01c/dom/base/nsDOMMutationObserver.h#468
> ...is there any benefit to us using
> already_AddRefed&& aOwner, instead of
> nsCOMPtr&&?
>
> (I believe we have the "already_AddRefed as a parameter" pattern in our
> code in order to avoid an extra addref/release when ownership is being
> transferred into a function.  But, RefPtr/nsCOMPtr with move references
> would let us do that just as well, more concisely & less arcanely.)

There's an important semantic difference: something that takes a move
reference to a smart pointer is not obligated to accept the reference.
If I do smartptr.forget() I know afterwards that smartptr is empty and
the reference that used to exist in it is Not My Problem (TM), whereas
if I call something with a move reference to smartptr I may have to
handle the error case, depending on what the callee does.

Those sorts of non-local effects, IMHO, make code harder to read.

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

Re: Non-standard stuff in the /dom/ directory

[Kyle Huey]

On Tue, Aug 16, 2016 at 8:56 PM,   wrote:
> I'm wondering, would it be worth while cleaning up the dom/ directory to move 
> non-standard stuff out of there?
>
> There is a bunch of legacy stuff from B2G that could be moved out to, say, 
> b2g/apis or some such for historical reasons.
>
> It would make searching/working-with for standardized DOM related stuff much 
> easier.

s/moved out/deleted/

This is a complicated subject caught in a variety of internal
politics.  I suggest you raise it with your management chain ;)

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

Re: How to name our JSContext getter(s): let the bikeshed begin

[Kyle Huey]

On Sun, May 29, 2016 at 6:21 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 5/29/16 6:17 PM, Kyle Huey wrote:
>>
>> Do we really need the ForThread part?
>
>
> I wanted to make it clear that we're getting something that's OK to use
> without synchronization, but maybe that's redundant and we can just have a
> dom::GetJSContext() or something.  dom::JSContext() would have ambiguity
> issues, of course.  I don't have super-strong opinions here.
>
>> Is the long term plan to merge
>> JSRuntime and JSContext, or are they going to remain distinct
>> indefinitely?
>
>
> Unclear.  See discussion the SpiderMonkey folks are having starting at
> https://bugzilla.mozilla.org/show_bug.cgi?id=650361#c27

Segregating the thread-specific and thread-agnostic parts into
separate classes seems like a good idea.

Given that it only makes sense to use a thread-specific object on that
thread, and it only makes sense to get the thread-agnostic object here
*from TLS* on one thread, I don't think we need any "thread" naming.

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

Re: How to name our JSContext getter(s): let the bikeshed begin

[Kyle Huey]

Do we really need the ForThread part?  Is the long term plan to merge
JSRuntime and JSContext, or are they going to remain distinct
indefinitely?

- Kyle

On Sun, May 29, 2016 at 6:10 PM, Boris Zbarsky  wrote:
> We currently have the following functions in nsContentUtils for getting
> various JSContexts:
>
> GetSafeJSContext()
> GetDefaultJSContextForThread()
> RootingCx()
> RootingCxForThread()
>
> We also have workers::GetCurrentThreadJSContext() for use on workers only.
>
> Now that we're about to move to only having one JSContext per thread (see
> bug 1276276) I think we should do some consolidating and renaming here.  In
> particular, we should stash the unique JSContext for the thread in the
> CycleCollectedJSRuntime and have only one accessor to get it, which goes
> through CycleCollectedJSRuntime::Get().  This does mean a TLS lookup in some
> cases in which right now we just do a pointer-chase, but has the benefit of
> simplicity.  And if we ever add non-worker threads with DOM stuff on them
> (which we're talking about anyway), we'd want this no matter what.
>
> My proposal is that we name this accessor something like
> JSContextForThread().  We can put this in nsContentUtils, in the
> "mozilla::dom' namespace, or the "xpc" namespace...  I don't have a strong
> preference here.
>
> If we _really_ want to we can keep a RootingCxForThread() around which
> returns exactly the same thing as JSContextForThread() but makes it clear
> that we plan to use it for rooting only.  I think we should nix RootingCx().
>
> Thoughts?
>
> -Boris
> ___
> 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: Windows 7 tests in AWS

[Kyle Huey]

On Fri, May 13, 2016 at 11:07 AM, Chris AtLee  wrote:

> I'm very happy to let you know that we've recently started running some of
> our Windows 7 tests in AWS. Currently we're running these suites in Amazon
> for all branches of gecko 49 and higher:
> * Web platform tests + reftests
> * gtest
> * cppunit
> * jittest
> * jsreftest
> * crashtest
>
> Since these are now working in AWS, it means we can scale up the number of
> machines with load. This should mean a big improvement in getting test
> results back for Windows 7!
>

<3


> Work is being tracked in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1271355.
>
> If you find any issues, please reach out in #releng, or file a bug and link
> it to the one above.
>
> Thanks in particular to jmaher and Q for helping to get this work done.
>
> Cheers,
> Chris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

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

Chromium and XPCOM event queues are now unified

[Kyle Huey]

On inbound (and soon central), for Chromium MessageLoops that belong to an
XPCOM thread (either the main thread, or created via the thread manager)
posting tasks now calls through to the underlying XPCOM thread's dispatch
implementation.  This could cause subtle breakage because event ordering
has changed, so if you see weirdness starting today please let me know,
particularly if its in APZ, plugins, or media, which make the heaviest use
of the chromium event queue.

You can check out bug 1269056 for more details.

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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Kyle Huey]

On Thu, May 12, 2016 at 2:46 PM, Karl Tomlinson  wrote:

> Lawrence Mandel writes:
>
> > Do we need this criteria?
> >
> > RAM - Does it hurt to move an instance that has <4GB?
>
> Yes.  OOM will be more common with 64-bit builds on systems with
> less RAM because 64-bit builds use more memory.
>

Our OOM crashes are almost always from running out of virtual memory, not
physical.

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

Re: Is Telemetry::Accumulate threadsafe?

[Kyle Huey]

Ok.
https://treeherder.mozilla.org/logviewer.html#?job_id=27652194=mozilla-inbound#L9753
seems to indicate that it is not currently threadsafe, but 1258183 adds a
lot of locks so hopefully that will help.

- Kyle

On Wed, May 11, 2016 at 11:46 AM, Georg Fritzsche <gfritzs...@mozilla.com>
wrote:

> Bug 1141565 made it thread-safe, bug 1258183 is dealing with some
> remaining TSan issues.
>
> Georg
>
> On Wed, May 11, 2016 at 7:23 PM, Kyle Huey <m...@kylehuey.com> wrote:
>
>> And if not, why is this not documented?
>>
>> - Kyle
>> ___
>> 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 Telemetry::Accumulate threadsafe?

[Kyle Huey]

And if not, why is this not documented?

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

Re: Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a OSS project!

[Kyle Huey]

Because you are *still* (as of 10 minutes ago) removing the off-topic
labels that were applied to clearly off-topic comments I have temporarily
removed your editbugs permissions.

- Kyle

On Mon, May 9, 2016 at 11:23 AM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:

> Hi!
>
> Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a
> OSS Project!
> The same mistake made Oracle with OpenOffice!
> Now the project is almost death!
> Think Mozilla should find his way back to his roots!
> Would be nice, if some people think about it!
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1114647
> I removed the marker that my comments are "Offtopic" ... (because I write
> my viewpoint to this topic!)
> ...and re-opened my attachment!
> Even if the employees are not interested how other OSS-Geeks see things
> that belong to the integration for Mozilla Products into Windows, this
> opinions of not-employees are anyway not "Offtopic", or "Spam"!
>
>
> Greets, Tobias.
> ___
> 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: Reverting to VS2013 on central and aurora

[Kyle Huey]

I think we should strongly consider just requiring SSE at this point.

- Kyle

On Fri, May 6, 2016 at 7:10 AM, Mike Hoye  wrote:

> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>
>> FWIW, the crashes we've seen so far are from incorrectly emitted movss
>> instructions. This instruction is part of the original SSE instruction
>> set,
>> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
>> by
>> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>> need
>> Firefox to run on processors manufactured in the 90s.
>>
> Per an IRC conversation with chutten, Firefox users on CPUs that do not
> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> etc), this work provides continuity of support to 0.01% of our users.
>
> - mhoye
>
>
> 09:59  So, to put it clearly and precisely, of the Firefox
> Population in release and beta who are reporting at least base telemetry
> collection on machines running supported configurations, only 0.01% cannot
> definitively say they have SSE.
> 10:00  (according to a 1% random sample as stored in the
> longitudinal dataset)
>
> ___
> 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 deprecate: MacOS 10.6-10.8 support

[Kyle Huey]

On Thu, May 5, 2016 at 8:23 PM,  wrote:

> On Tuesday, May 3, 2016 at 8:32:26 PM UTC-7, Lawrence Mandel wrote:
> > On Tue, May 3, 2016 at 11:11 PM, Xidorn Quan 
> wrote:
> >
> > > On Wed, May 4, 2016 at 9:46 AM, Lawrence Mandel 
> > > wrote:
> > >
> > >> On Tue, May 3, 2016 at 6:56 PM, Mike Hommey  wrote:
> > >>
> > >> > On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach wrote:
> > >> > > On 5/3/16 4:59 PM, Justin Dolske wrote:
> > >> > > > On 5/3/16 12:21 PM, Gregory Szorc wrote:
> > >> > > >
> > >> > > > > * The update server has been reconfigured to not serve Nightly
> > >> > > > > updates to
> > >> > > > > 10.6-10.8 (bug 1269811)
> > >> > > >
> > >> > > > Are we going to be showing some kind of notice to affected users
> > >> upon
> > >> > > > Release? That is, if I'm a 10.6 user and I update to Firefox
> 48, at
> > >> > some
> > >> > > > point should I see a message saying I'll no longer receive
> future
> > >> > > > updates?
> > >> > >
> > >> > > Even better, is there any way to get the update system to
> > >> automatically
> > >> > move
> > >> > > such users over to 45ESR?
> > >> >
> > >> > Did we introduce changes to profile data between 45 and 48? Because
> > >> > that usually breaks downgrade paths.
> > >> >
> > >>
> > >> We discussed this earlier and decided that we were not going to
> > >> automatically move users from Firefox to ESR. For one thing, the user
> has
> > >> not opted to be on this channel. A channel change also involves both
> > >> engineering and test work. It does seem prudent to test the scenario
> to
> > >> know whether users can move from 47 to ESR 45.2.0 without issue.
> > >
> > >
> > > Is it feasible to make 48 an ESR as well so that we don't need to ask
> > > users to downgrade it to ESR 45?
> > >
> >
> > I don't think so. I also don't know that we're going to recommend that
> > users migrate to ESR (need to verify that there are no incompatible
> profile
> > changes) although that is certainly an option.
> >
> > Lawrence
>
> (Note: Please see "OSX Support Cycle" below.)
>
> These are important decisions. However, expecting all end-users to be able
> to handle a manual migration to ESR, or understand what is happening or why
> is somewhat flawed. I believe downgrading should NOT be considered as an
> option, except for tech savvy users.
>
> The best option, from my perspective (supporting a wide array of users, OS
> versions, hardware), is to make the final 10.6-10.8 version be (or become)
> the next ESR with a startup page providing them with the choice and action
> buttons/links. Subsequent startups would load follow-up startup pages with
> the appropriate reminders.
>
> The pages should explain very simply and succinctly that no new features
> will be coming and only security updates/patches will be made until "X"
> date when support ends (but the browser will still be usable). The first
> page should be VERY overt and obnoxious. The 2nd, 3rd, etc. can be more
> like what Google Chrome did recently (ie. notice bar at top of the content
> area).
>
> SIDEBAR: "OSX Support Cycle"
>
> While we are on this subject, what is the plan for Firefox support of 10.9
> later this year when Apple pushes out its latest OSX? How about a year from
> now when 10.10 support ends? Where does the annual Firefox/OSX support
> depreciation end?
>
> Apple has shifted to warp speed with their rapid release cycle. Every
> version of Windows has a minimum 10 year support lifecycle (security
> patches, etc.) OSX now has 3.
>
> If Mozilla and other developers simply follow Apple's "not supported"
> timeline, there will be a growing number of end users who will be left out.
> Where do you think they will go? If they migrate to Windows there is a much
> greater chance they will stick with Edge or whatever is there and leave
> Firefox behind.
>

We *don't* follow Apple's timeline though.  Snow Leopard was dropped by
Apple back in 2013.  Mozilla's decisions are driven by considering, among
other factors, how many users remain on that platform and the engineering
difficulty of continuing to support it.

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

Re: MOZ_WARN_UNUSED_RESULT has been renamed as MOZ_MUST_USE

[Kyle Huey]

On Fri, Apr 29, 2016 at 1:46 PM, Chris Peterson 
wrote:

> On 4/29/16 5:53 AM, Nathan Froyd wrote:
>
>> This is a noble goal, but there is an enormous amount of code that
>> would need to be modified to make this feasible.  Perhaps if you
>> exempted nsresult from MOZ_MUST_USE types.
>>
>
> In theory, nsresult seems like an important type to check.
>
> That said, I once tried building Gecko with `#define NS_IMETHOD
> MOZ_WARN_UNUSED_RESULT NS_IMETHOD_(nsresult)`. There were over 10,000
> warnings for XPCOM method callers not checking nsresult return values, so
> this approach does not seem practical. :(


nsresult is required in a lot of method signatures (thanks XPIDL!) which
makes it often not an important type to check.

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

NS_New*RunnableMethod* -> New*RunnableMethod

[Kyle Huey]

NS_NewRunnableMethod has been replaced with mozilla::NewRunnableMethod.
NS_NewRunnableMethodWithArg[s] has also been collapsed into
mozilla::NewRunnableMethod.  It also now returns an already_AddRefed.

The Chromium versions of these methods have been removed.

NS_NewRunnableFunction still survives, but at some point it will be changed
too.

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

Static analysis for "use-after-move"?

[Kyle Huey]

Can we catch this pattern with a compiler somehow?

Foo foo;
foo.x = thing;
DoBar(mozilla::Move(foo));
if (foo.x) { /* do stuff */ }

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

nsRunnable is now mozilla::Runnable on trunk

[Kyle Huey]

Sometime later this week Task will become Runnable too.

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

Re: Proposal: use nsresult& outparams in constructors to represent failure

[Kyle Huey]

On Wed, Apr 20, 2016 at 9:52 PM, Kris Maglione 
wrote:

> On Thu, Apr 21, 2016 at 02:10:59PM +1000, Nicholas Nethercote wrote:
>
>> On Thu, Apr 21, 2016 at 1:23 PM, Kris Maglione 
>> wrote:
>>
>>>
>>> If we do this, can we please use |nsresult*| rather than |nsresult&|?
>>>
>>
>> I prefer a reference because of the guarantee of non-nullness. But I
>> could live with a pointer if people think it's better.
>>
>
> There isn't a strict guarantee of non-nullness for reference parameters.
> This is an extreme example, but technically valid:
>
>  T th(*(nsresult*)0);
>

IIRC this is undefined behavior, so when you do this the compiler is
allowed to format your hard drive.

Or, somewhat more likely, a function which already takes a |nsresult*|
> argument might do:
>
>  T th(*aRv);
>
> I suppose either of those are less likely than someone passing |nullptr|,
> but if we really want to guarantee non-nullness, we can do that easily
> enough with a template type like GSL's |non_null|.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

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

Re: Moving XP to ESR?

[Kyle Huey]

On Tue, Apr 19, 2016 at 1:20 PM, Ted Mielczarek  wrote:

> On Tue, Apr 19, 2016, at 04:14 PM, Nils Ohlmeier wrote:
> > The good news is that dxr does not find anything using IsXPSP3OrLater().
> > But this looks like we have a bit of version specific code in our tree:
> >
> https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN=false=true
>
> FYI, the "XP" here means "cross-platform", and XP_WIN is set whenever
> we're building for Windows.
>
>
> > And on top of that come the costs for maintaining XP machines as part of
> > the treeherder setup.
> >
> > So it is not easy to quantify, but there is a “XP tax” we pay.
>
> This is true. We hit this with toolchain support, we're actively jumping
> through hoops to continue targeting XP with newer versions of MSVC.


We jump through some hoops to support things like Linux and Mac too, and
those platforms combined have far fewer users than XP.

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

Re: Moving XP to ESR?

[Kyle Huey]

12% of our users are on Windows XP.

- Kyle

On Mon, Apr 18, 2016 at 6:04 AM, Henri Sivonen  wrote:

> XP has now gone for two years without security patches from Microsoft.
> Additionally, as of its latest release, Chrome no longer supports XP.
>
> When 46 ships, it would be a great time to make AUS advertise 45 ESR
> builds to XP (even on non-ESR) channel. This would keep XP supported
> through the ESR cycle but would put an end to the XP tax on trunk.
>
> Are we already on track to doing this? If not, why not?
>
> --
> 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: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Kyle Huey]

Why should we be the ones to take the web compat hit on this?

- Kyle
On Apr 14, 2016 1:55 AM, "Chris Peterson"  wrote:

> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> cookies without the `secure` flag as session cookies.
>
> PROS:
>
> * Security: login cookies set over non-secure HTTP can be sniffed and
> replayed. Clearing those cookies at the end of the browser session would
> force the user to log in again next time, reducing the window of
> opportunity for an attacker to replay the login cookie. To avoid this,
> login-requiring sites should use HTTPS for at least their login page that
> set the login cookie.
>
> * Privacy: most ad networks still use non-secure HTTP. Content sites that
> use these ad networks are prevented from deploying HTTPS themselves because
> of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set
> over non-secure HTTP at the end of every browser session would be a strong
> motivator for ad networks to upgrade to HTTPS, which would unblock content
> sites' HTTPS rollouts.
>
> However, my testing of Henri's original proposal shows that too few sites
> set the `secure` cookie flag for this to be practical. Even sites that
> primarily use HTTPS, like google.com, omit the `secure` flag for many
> cookies set over HTTPS.
>
> Instead, I propose treating all cookies set over non-secure HTTP as
> session cookies, regardless of whether they have the `secure` flag. Cookies
> set over HTTPS would be treated as "secure so far" and allowed to persist
> beyond the current browser session. This approach could be tightened so any
> "secure so far" cookies later sent over non-secure HTTP could be downgraded
> to session cookies. Note that Firefox's session restore will persist
> "session" cookies between browser restarts for the tabs that had been open.
> (This is "eternal session" feature/bug 530594.)
>
> To test my proposal, I loaded the home pages of the Alexa Top 25 News
> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
> cookies. Treating non-secure cookies as session cookies means that over
> 1100 cookies would be cleared at the end of the browser session!
>
> CONS:
>
> * Sites that allow users to configure preferences without logging into an
> account would forget the users' preferences if they are not using HTTPS.
> For example, companies that have regional sites would forget the user's
> selected region at the end of the browser session.
>
> * Ad networks' opt-out cookies (for what they're worth) set over
> non-secure HTTP would be forgotten at the end of the browser session.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>
> Link to standard: N/A
>
> Platform coverage: All platforms
>
> Estimated or target release: Firefox 49
>
> Preference behind which this will be implemented:
> network.cookie.lifetime.httpSessionOnly
>
> Do other browser engines implement this? No
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
> [2] http://www.alexa.com/topsites/category/Top/News
> ___
> 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: Crash signature change: signatures now include abort messages

[Kyle Huey]

Does this catch MOZ_RELEASE_ASSERT and similar?  It would be nice to
distinguish those somehow in crash-stats.

- Kyle

On Wed, Apr 6, 2016 at 2:18 PM, Benjamin Smedberg 
wrote:

> A change just landed which will change the way crash signatures are
> computed for intentional aborts. Previously the crash signature would be
> "NS_DebugAbort | ". Now the signature will be "Abort |  message up to 80 chars> | ".
>
> This should make it much easier to distinguish various classes of abort.
>
> Thanks to Adrian Gaudebert for taking this in bug 803779!
>
> --BDS
>
> --
> Benjamin Smedberg
> Engineering Manager, Firefox
> ___
> 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: Removing the Chromium event loop

[Kyle Huey]

On Thu, Mar 31, 2016 at 3:19 AM, Honza Bambas <hbam...@mozilla.com> wrote:

> On 3/30/2016 20:21, Kyle Huey wrote:
>
>> In the department-of-paying-down-technical-debt, I'm planning to remove
>> much of the Chromium event loop over the next few months. You can follow
>> along in bug 1260828.
>>
>> The rough outline:
>>
>> Step 1: Replace Task with nsIRunnable, without changing any other
>> semantics.  This will happen in late April, after Gecko 48 branches.
>> Step 2: Either remove PostDelayedTask, or reimplement its semantics in
>> nsThread.
>> Step 3: Remove Chromium event loops using TYPE_DEFAULT and
>> TYPE_MOZILLA_NONMAINTHREAD. These are the simplest cases, because
>> TYPE_DEFAULT runs a Chromium Tasks only event loop, and
>> TYPE_MOZILLA_NONMAINTHREAD just glues delayed and idle tasks into the
>> normal XPCOM event loop.
>> Step 4: Tackle TYPE_MOZILLA_PARENT and TYPE_MOZILLA_CHILD. These run the
>> main threads of parent and content processes respectively, and aren't much
>> harder than step 3.
>>
>> The other types (TYPE_UI, TYPE_IO, and TYPE_MOZILLA_NONMAINUITHREAD)
>> involve varying levels of platform specific event loop or API integration
>> that will probably be more difficult to untangle. They also won't block my
>> long-term desire to build a scheduler for Gecko, so are lower priority.
>>
>> If you have objections, speak now or forever hold your peace.
>>
>
> Few questions:
>
> - how will this impact the IPC pumping that is based on Tasks?
>

It will be changed to not use Tasks.


> - do you have more details/ideas/bugs about your scheduler?  I may have
> similar thoughts, like adding priorities to (not only) main thread events.
> Backtrack (bug 1148204) should give hints (at least) how such a scheduler
> should behave and check if does what we want.
>

At a very high level, there will be an event queue per global and we'll
prioritize the queues for things in the foreground.  There are also
opportunities to prioritize within a given queue, according to the HTML
spec, but it's not clear how much of that is web compatible.

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

Re: Removing the Chromium event loop

[Kyle Huey]

On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd  wrote:

> On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
>  wrote:
> > I've been unhappy with the fact that our event loop uses refcounted
> objects
> > by default. *Most* runnables are pure-C++ and really don't need to be
> > refcounted/scriptable.
>
> I've been thinking about this too.  gfx has a separate thread pool
> that was created partly because of the desire to be Gecko-free and
> partly because of the overhead that nsIRunnable has.  It would be nice
> to eliminate one of those objections.  Making this change would also
> bring down bloat from vtables and essentially-useless methods.
>

Frankly, I think this is an ex-post-facto rationalization for not liking
nsIRunnable because it's XPCOMy/not new and shiny/etc. We had this same
problem with many of the same people and the same justifications with the
mfbt RefCounted class that turned out to be a nightmare to untangle.  Turns
out things our boring old stuff had like leak checking were actually
useful!  Who could have guessed?

Unless they have actual evidence showing this matters I don't care about
their objections.

*shots_fired.jpg*

> I'm asking you to consider unifying these two things by making our event
> > loop work more like chromium and just using c++ objects without a
> refcount
> > by default? Then to post a scriptable event to an event loop you'd have
> to
> > have it own a separate scriptable object.


I'll pose to you the same question I posed bsmedberg, is this actually
worth fiddling with all the existing runnables.  It's not just scriptable
stuff that needs to be changed.

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

Re: Removing the Chromium event loop

[Kyle Huey]

On Wed, Mar 30, 2016 at 11:34 AM, Benjamin Smedberg 
wrote:

> I support this plan!
>
> Mostly.
>
> I've been unhappy with the fact that our event loop uses refcounted
> objects by default. *Most* runnables are pure-C++ and really don't need to
> be refcounted/scriptable.
>
> I'm asking you to consider unifying these two things by making our event
> loop work more like chromium and just using c++ objects without a refcount
> by default? Then to post a scriptable event to an event loop you'd have to
> have it own a separate scriptable object.
>
> If that sounds like too much churn for your project, then please proceed
> with your original plan!
>
> --BDS
>

Well, it's obviously easier to move from new/delete to refcounted than the
reverse ... is there a reason to believe it's actually worth the cost of
de-refcountifying all the runnables in Gecko?

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

Removing the Chromium event loop

[Kyle Huey]

In the department-of-paying-down-technical-debt, I'm planning to remove
much of the Chromium event loop over the next few months. You can follow
along in bug 1260828.

The rough outline:

Step 1: Replace Task with nsIRunnable, without changing any other
semantics.  This will happen in late April, after Gecko 48 branches.
Step 2: Either remove PostDelayedTask, or reimplement its semantics in
nsThread.
Step 3: Remove Chromium event loops using TYPE_DEFAULT and
TYPE_MOZILLA_NONMAINTHREAD. These are the simplest cases, because
TYPE_DEFAULT runs a Chromium Tasks only event loop, and
TYPE_MOZILLA_NONMAINTHREAD just glues delayed and idle tasks into the
normal XPCOM event loop.
Step 4: Tackle TYPE_MOZILLA_PARENT and TYPE_MOZILLA_CHILD. These run the
main threads of parent and content processes respectively, and aren't much
harder than step 3.

The other types (TYPE_UI, TYPE_IO, and TYPE_MOZILLA_NONMAINUITHREAD)
involve varying levels of platform specific event loop or API integration
that will probably be more difficult to untangle. They also won't block my
long-term desire to build a scheduler for Gecko, so are lower priority.

If you have objections, speak now or forever hold your peace.

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

Introducing MOZ_ALWAYS_SUCCEEDS

[Kyle Huey]

For when you are too lazy to type MOZ_ALWAYS_TRUE(NS_SUCCEEDS(foo)).

This was added in bug 1259294, which merged to mozilla-central this morning.

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

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Kyle Huey]

On Mon, Mar 14, 2016 at 2:30 PM, Ehsan Akhgari 
wrote:

> On 2016-03-14 3:23 PM, Boris Zbarsky wrote:
> > On 9/8/15 3:21 PM, Luke Wagner wrote:
> >> On a more technical detail: WebKit and Chromium have both shipped,
> >> returning the number of logical processors where WebKit additionally
> >> clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
> >> by WHATWG text [7].  I would argue for not clamping (like Chrome),
> >
> > Given the use cases, should we clamp to our per-origin limit?
>
> I brought this up in an in person meeting about this a while ago.  It
> seems pretty hard to justify returning a number more than our per-origin
> worker limit.  To be clear, this will be a clamping different to what
> WebKit does.
>

That number is 20 or 50 or something like that though.

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

Re: On nsICancelableRunnable (or how bad decisions come back to haunt you)

[Kyle Huey]

On Fri, Mar 11, 2016 at 7:04 AM, Gabriele Svelto 
wrote:

>  Many moons ago, while we were frantically trying to make Firefox OS 1.0
> run half-decently, I introduced a derived class of nsIRunnable that
> could be canceled: nsICancelableRunnable. As with many other things that
> led to the first release of FxOS this was done in a rush and without
> much thinking. It's only goal at the time was to allow me to cancel a
> single, simple, stateless runnable that could take a while to run.
>
> Thinking about it afterwards I came to the conclusion that this was a
> terrible approach: implementing the Cancel() method was up to the user
> and there was no telling on which threads Run() and Cancel() could be
> called making it potentially racy. So I thought it could be replaced by
> adding a Cancel() method to the event queue that would just remove the
> event in a thread-safe way. This seemed a cleaner, safer approach.
>
> But then I looked into our code and discovered that
> nsICancelableRunnable has spread like a disease through the codebase and
> it's systematically used in workers to let us cancel events posted to
> them. Ouch. Some of its uses highlight its problems: in some cases its
> only purpose is to force calling the Run() method by the calling thread
> so that certain objects get destroyed on that thread (possibly to
> prevent leaks). In other cases we have patterns like this:
>
> Run() {
>   if (mDoSomething) {
> DoSomething();
>   }
> }
>
> Cancel() {
>   mDoSomething = false;
> }
>
> Which is fine if both methods are called by the same thread, but most
> likely not if they're called on different threads and the interface
> itself does nothing to prevent you from doing it.
>
> All in all I'd still like to get rid of it but I'm not sure if my
> original approach of moving the cancel functionality into the EventQueue
> is the right way to go. Which leads me to the point of this e-mail: to
> gather feedback on my idea to get rid of it. Since I don't have enough
> knowledge about all the affected areas I'd like to hear from those who
> actually used it.


On workers Run and Cancel are always called by the same thread, so there is
no race.

Much of the "disease" you see is simply support for DOM worker threads,
because every runnable that can run on those threads must be cancelable.
Workers do not guarantee one of the invariants that other XPCOM threads do:
that every runnable is eventually run after being successfully dispatched.
Instead we guarantee that every runnable is either Run() or Cancel()ed.

The disadvantage of pushing this into the event queue is that today
runnables that are dispatched from other threads to workers *must*
implement nsICancelableRunnable, which means authors of code that runs on
workers must think about this.  We do already have an exception for
NS_DispatchToCurrentThread though (via ExternalRunnableWrapper), so this
may be something we can relax.  It would generally require us to write
cleanup code (for the existing runnables and any future ones) to run from
destructors, and historically destructors could run on either the
dispatching thread or the executing thread (although that has changed
somewhat.)

Regardless, your plan should probably involve me ;)

- Kyle

PS. Subscribe to the mailing list so you don't get caught in moderation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kyle Huey]

On Fri, Mar 11, 2016 at 4:28 PM, Terrence Cole  wrote:

> We need to drop support for OSX 10.8 and Windows Vista yesterday, not next
> year. We need to cut our losses and ship E10S while we're still relevant.
> We need to be the browser that works best on Android and Windows 10, not
> the browser that happens to already be installed.
>

You do realize that you're talking about throwing away nearly 20% of our
user base, right?

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kyle Huey]

On Fri, Mar 11, 2016 at 2:03 AM, Benjamin Smedberg 
wrote:

> This is notice of an intent to deprecate support within Firefox for the
> following old versions of MacOS: 10.6, 10.7, and 10.8
>
> The motivation for this change is that we have continued failures that are
> specific to these old operating systems and don't have the resources on
> engineering teams to prioritize these bugs. Especially with the deployment
> of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> that we are not seeing elsewhere. We get very little testing of old MacOS
> versions from our prerelease testers and cannot dedicate much paid staff
> testing support to these platforms. We also have an increasingly fragile
> set of old hardware that supports automated tests on 10.6 and do not intend
> to replace this.
>
> This will affect approximately 1.2% of our current release population.
> Here are the specific breakdowns by OS version:
> 10.6
> 0.66%
> 10.7
> 0.38%
> 10.8
> 0.18%
>
> The final timeframe for this deprecation has not been finalized, but the
> current proposal is to remove support in Firefox 46. We will try and update
> existing users on old MacOS versions to the Firefox 45 ESR release stream,
> so that they stay with security update support through the end of 2016.
>
> Because of the ESR update window, I would like to finalize this decision
> by Monday. If you have questions or concerns about this plan, please reply
> to the firefox-dev mailing list immediately. Jeff Griffiths will be working
> with our communications team to coordinate more public communications such
> as post to the Future of Firefox blog.
>
> --BDS
>

Why can't we just not ship e10s to these users?  We have a number of other
populations we're not shipping to, at least for now.

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

Re: call prompt service dynamically

[Kyle Huey]

You're probably just not linking to the xpcom glue library in eclipse/gcc.

- Kyle

On Tue, Mar 8, 2016 at 8:33 PM, Tobias Wolf  wrote:

> We`re develping a PKCS11 modul in c/c++ for a custom card reader to
> support. I just want to display a simple dialog. The code below works great
> until I stay on MS Visual Studio. But our project is running on eclipse/gcc.
>
>  nsCOMPtr promptService = do_GetService("@
> mozilla.org/embedcomp/prompt-service;1"));
>  promptService->Alert(NULL, NULL, NULL);
>
> I`m getting the following error during linking, that comes because of the
> different coding convention between VS and mingw/gcc on windows.
>
> C:/download/xulrunner-41.0b9.en-US.win64.sdk/xulrunner-sdk/include/nsCOMPtr.h:514:
> undefined reference to
> `nsCOMPtr_base::assign_from_gs_contractid(nsGetServiceByContractID, nsID
> const&)'
>
> Am Montag, 7. März 2016 18:50:36 UTC+1 schrieb Benjamin Smedberg:
> > On 3/7/2016 11:17 AM, Tobias Wolf wrote:
> > > I try to call this code dynamically:
> > >
> > > nsCOMPtr promptService = do_GetService("@
> mozilla.org/embedcomp/prompt-service;1"));
> > > promptService->Alert(NULL, NULL, NULL);
> > >
> > > I do the following:
> > >
> > > nsISomeInterface* mXPTCStub;
> > > nsresult rc;
> > > nsXPTCVariant params[3];
> >
> > Why are you trying to do this? Are you writing a shim layer that
> > connects some other dynamic/scripting language to XPCOM?
> >
> > >
> > > rc = NS_GetXPTCallStub(NS_IPROMPTSERVICE_IID, proxy, );
> > >
> > > params[0].val.p = NULL;
> > > params[0].type = nsXPTType::T_VOID;
> > > params[0].flags = 0;
> > >
> > > params[1].val.p = (void*)title;
> > > params[1].type = nsXPTType::T_CHAR_STR;
> > > params[1].flags = 0;
> > >
> > > params[2].val.p = (void*)text;
> > > params[2].type = nsXPTType::T_CHAR_STR;
> > > params[2].flags = 0;
> > >
> > > rc = NS_InvokeByIndex(mXPTCStub, 1, 3, params);
> > > NS_DestroyXPTCallStub(mXPTCStub);
> > >
> > > But I don`t know how to use NS_GetXPTCallStub!
> > > What means the second and third parameter from NS_GetXPTCallStub?
> >
> > Have you read the doccomments at
> >
> http://mxr.mozilla.org/mozilla-central/source/xpcom/reflect/xptcall/xptcall.h#174
> > ?
> >
> > If you are trying to *invoke* a method, you don't need an xptcall stub
> > at all. You just need NS_InvokeByIndex.
> >
> > An XPTCall stub is used to *implement* an XPCOM object whose
> > type/interface definition isn't known at compile time, typically by
> > mirroring it to an underlying scriptable object. You would need to
> > implement a c++ class which implements nsIXPTCProxy and implements
> > CallMethod.
> >
> > --BDS
> ___
> 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: Exit code -11 must die

[Kyle Huey]

On Mon, Feb 29, 2016 at 9:03 AM, Benjamin Smedberg 
wrote:

> On 2/27/2016 9:06 PM, Randell Jesup wrote:
>
>> months until recently it popped up a bit).  Note that this failure
>> *never* results in a crashdump, and I've never seen it locally, just in
>> Automation.
>>
>
> What we do know:
>
>  * Exit code -11 is evidence a SIGSEGV (crash).
>
> This I don't know, but somebody may know (+ted):
>
>  * Are we sure that the crash is happening in firefox.exe? Or is it
>possible that some other process is crashing and taking down our
>test harness with it?
>  * Can somebody point to exactly what line of code in the test harness
>collects the -11 code?
>  * Is there no crash dump because the crash reporter is turned off?
>  o If it's turned on, is the crash reporter itself crashing? Or is
>the test harness not picking up the crash dump?
>
>
> We *need* to find some solution to it -- even if it's to decide it's a
>> (safe) artifact of some underlying problem outside of our control.
>>
>
> Is "we" you? Are you asking somebody else to help you with this, or own
> the problem completely?
>
>I'd
>> far rather find a true cause and either fix or wallpaper it.  But right
>> now it's stopping me from landing some important code changes.
>>
>> On the plus side, I have a nice Try run which will cause it 100% of the
>> time - though when I tried to provoke it on a loaner Test VM after
>> painfully emulating what's needed to run tests, it wouldn't fail -- but
>> I don't trust that was a well-setup recreation of a real Try run.
>>
>> https://treeherder.mozilla.org/#/jobs?repo=try=b2eb01359621
>>
>> IIRC, there was recently a post about how you can submit a try job and
> have the VM stay alive afterwards for postmortem debugging. I don't
> remember/can't find the details right now
>
> Can we also submit a try job with rr enabled, and get a recording of the
> failure? That combination could lead to a pretty quick cause diagnosis of
> this, since it's Linux.
>
> Also, does this failure happen if you disable all the tests except for the
> one which is permafailing
> (dom/media/tests/mochitest/identity/test_setIdentityProviderWithErrors.html)?
> If so, that would make it easier to record and debug.
>

If these are running on EC2 we can't throw rr at it.

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

Intent to implement and ship: IDBKeyRange.includes()

[Kyle Huey]

*Summary*: This simple API allows one to test whether a given key is
included in an IDBKeyRange
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1251498
*Link to standard*: http://w3c.github.io/IndexedDB/#dom-idbkeyrange-includes
*Platform coverage*: All platforms
*Estimated or target release*: Firefox 47
*Preference behind which this will be implemented*: No preference
Do other browser engines implement this? Blink is planning to implement and
ship this per discussions with Joshua Bell.

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

Re: rr chaos mode update

[Kyle Huey]

rr runs fine under VMWare ;)

- Kyle

On Mon, Feb 15, 2016 at 6:18 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:

> On Mon, Feb 15, 2016 at 6:15 PM, Kyle Huey <m...@kylehuey.com> wrote:
>
>> Seems like a good thing to expect developers to do locally today.
>>
>
> I don't think that's realistic for developers who aren't on Linux.
>
>
>>
>> - Kyle
>>
>> On Mon, Feb 15, 2016 at 6:08 PM, Justin Dolske <dol...@mozilla.com>
>> wrote:
>>
>> > On 2/14/16 9:25 PM, Bobby Holley wrote:
>> >
>> > How far are we from being able to use cloud (rather than local) machine
>> >> time to produce a trace of an intermittently-failing bug? Some
>> one-click
>> >> procedure to produce a trace from a failure on treeherder seems like it
>> >> would lower the activation energy significantly.
>> >>
>> >
>> > And with that... At some point, what about having all *new* tests be
>> > battle-tested by X runs of rr-chaos testing?  If it passes, it's
>> allowed to
>> > run in the usual CI automation. If it fails, it's not (and you have a
>> handy
>> > recording to debug).
>> >
>> > Justin
>> >
>> > ___
>> > 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
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[Kyle Huey]

Seems like a good thing to expect developers to do locally today.

- Kyle

On Mon, Feb 15, 2016 at 6:08 PM, Justin Dolske  wrote:

> On 2/14/16 9:25 PM, Bobby Holley wrote:
>
> How far are we from being able to use cloud (rather than local) machine
>> time to produce a trace of an intermittently-failing bug? Some one-click
>> procedure to produce a trace from a failure on treeherder seems like it
>> would lower the activation energy significantly.
>>
>
> And with that... At some point, what about having all *new* tests be
> battle-tested by X runs of rr-chaos testing?  If it passes, it's allowed to
> run in the usual CI automation. If it fails, it's not (and you have a handy
> recording to debug).
>
> Justin
>
> ___
> 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: rr chaos mode update

[Kyle Huey]

On Sun, Feb 14, 2016 at 9:37 PM, L. David Baron <dba...@dbaron.org> wrote:

> On Sunday 2016-02-14 21:26 -0800, Kyle Huey wrote:
> > On Sun, Feb 14, 2016 at 9:16 PM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
> > > Over the last few days we have had a lot of positive experiences
> > > reproducing bugs with rr chaos mode. Kyle tells me that, in fact, he's
> been
> > > able to reproduce every single bug he tried with enough machine time
> thrown
> > > at it.
> >
> > Of five or so, but yes.
>
> How many of those were intermittents that were never actually
> reported on Linux on our test infrastructure (i.e., reported only on
> other platforms), but that you were able to reproduce in rr's chaos
> mode on Linux?
>

At least one, bug 1150737, had only appeared in any great quantity on 10.6,
and may never have appeared on non-Mac tests in automation.  Chaos mode
reproduced it in a minute or two on Linux.

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

Re: rr chaos mode update

[Kyle Huey]

On Sun, Feb 14, 2016 at 9:16 PM, Robert O'Callahan 
wrote:

> Over the last few days we have had a lot of positive experiences
> reproducing bugs with rr chaos mode. Kyle tells me that, in fact, he's been
> able to reproduce every single bug he tried with enough machine time thrown
> at it.
>

Of five or so, but yes.

At this point the limiting factor is getting developers to actually debug
> and fix recorded test failures. Anyone should be able to set up a VM on
> their local machine, build Firefox, record some failures and fix them. For
> best results, run just one test that's known intermittent, or possibly the
> whole directory of tests if there might be inter-test dependencies. Use
> --shuffle and --run-until-failure. The most convenient way to run rr with
> chaos mode is probably to create a script rr-chaos that prepends the
> --chaos option, and use --debugger rr-chaos.
>

You can generally pass --debugger=/path/to/rr --debugger-args="record -h"
to mach to get things working.

Lots of tests have been disabled for intermittency over the years. Now we
> have the ability to fix (at least some of) them without much pain, it may
> be worth revisiting them, though i don't know how to prioritize that.
>

FWIW, every failure that I've debugged to completion so far has been a bug
in the test (although I have two fatal assertion bugs I'm working through
that will obviously be flaws in Gecko).  I think one of the things we
really want to get a feeling for is how often we find actual bugs in the
product.

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

Re: Using rr chaos mode to find intermittent bugs

[Kyle Huey]

On Thu, Feb 11, 2016 at 11:35 AM, Robert O'Callahan 
wrote:

> On Thu, Feb 11, 2016 at 11:55 PM, Nicolas B. Pierron <
> nicolas.b.pier...@mozilla.com> wrote:
>
> > On 02/10/2016 08:04 PM, Robert O'Callahan wrote:
> >
> >> Background:
> >> http://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html
> >>
> >> I just landed on rr master support for a "-h" option which enables a
> chaos
> >> mode for rr recording. This is designed to help reproduce intermittent
> >> test
> >> failures under rr. […]
> >>
> >
> > Thanks Roc, I will give it a try.
> >
> > On the other hand, I used to rely more on the "-c" option to achieve a
> > similar thing in the past, instead of the "-e" option.
> >
> > The reason I did so being that the thread I am interested in does a few
> > syscalls compared to the rest of the program.  Thus I felt that using
> "-e"
> > option would give it an unfair large time slices compared to what is
> > supposed to happen if the threads are running concurrently.
>
>
> The -e option is gone now because the new scheduler (with or without chaos
> mode) does not take system calls into account when calculating the length
> of a timeslice. We only count conditional branches.
>

So we context switch at a syscall now only when the current thread happens
to become unschedulable?

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

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Are you using it from JS or C++?  If you're using it from JS, nothing has
changed.

- Kyle

On Wed, Feb 10, 2016 at 4:32 PM, Devan Shah  wrote:

> Hello
>
> nsIDOMWindow is deprecated now according to:
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindow
> is there an alternative for this interface. I am using a lot of functions
> from this interface and also using nsIPromptFactory which relies on
> nsIDOMWindow a lot for all of it functions.
>
> Is there any way to get an alternative with the same functionality which
> requires minimal changes or is there a way that I can get the nsIDOMWindow
> interface and all of its functionality back by adding the interface locally
> and implementing the functions locally.
>
> Thanks
> Devan Shah
> ___
> 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: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Ok ... ignoring the question of how you're using it from C++ since binary
addons are gone, many of the methods on nsIDOMWindow moved to nsPIDOMWindow
and then to nsPIDOMWindowInner/Outer, depending on what version of Gecko
you're using.  Today on trunk nsIPromptFactory takes a mozIDOMWindowProxy,
which is a base interface of nsPIDOMWindowOuter.  You can look at
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsPIDOMWindow.h to
see what's there.  Some methods on nsIDOMWindow that were unused were
removed completely, though I don't think there were many.

- Kyle

On Wed, Feb 10, 2016 at 4:40 PM, Devan Shah <devan.sha...@gmail.com> wrote:

> I am using it from c++
>
> On Wed, Feb 10, 2016 at 7:38 PM, Kyle Huey <m...@kylehuey.com> wrote:
>
>> Are you using it from JS or C++?  If you're using it from JS, nothing has
>> changed.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 4:32 PM, Devan Shah <devan.sha...@gmail.com>
>> wrote:
>>
>>> Hello
>>>
>>> nsIDOMWindow is deprecated now according to:
>>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindow
>>> is there an alternative for this interface. I am using a lot of functions
>>> from this interface and also using nsIPromptFactory which relies on
>>> nsIDOMWindow a lot for all of it functions.
>>>
>>> Is there any way to get an alternative with the same functionality which
>>> requires minimal changes or is there a way that I can get the nsIDOMWindow
>>> interface and all of its functionality back by adding the interface locally
>>> and implementing the functions locally.
>>>
>>> Thanks
>>> Devan Shah
>>> ___
>>> 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: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

[Kyle Huey]

What's wrong with AsWidgetEvent? We do AsFoo a fair bit.

- Kyle
On Feb 10, 2016 8:58 PM, "Aidin Gharibnavaz"  wrote:

> In Bug 1235830 , I'm
> going to rename this method to something more meaningful. I need suggestion
> about what the name should be.
>
> Summary of the discussion so far:
>
> * WidgetEvent() can't be used, since it's also the name of a type.
> * GetWidgetEvent() is good, but may suggests that method can return
> nullptr.
> * AsWidgetEvent() don't have this ambiguousness, but is not a good name.
>
> Any other ideas?
> ___
> 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: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Yes, you need to QueryInterface between nsIDOMWindow and nsPIDOMWindow.

What are you actually doing with the Firefox SDK?

- Kyle

On Wed, Feb 10, 2016 at 5:03 PM, Devan Shah <devan.sha...@gmail.com> wrote:

> I tried to use nsPIDOMWindow, but issues is that functions like:
>
> Function GetContentDOMWindow in nsIWebBrowser is expecting: NS_IMETHOD
> GetContentDOMWindow(nsIDOMWindow * *aContentDOMWindow) = 0;
> (firefox-45.0b4\firefox-sdk\include\nsIWebBrowser.h)
> Function: NS_IMETHOD GetPrompt(nsIDOMWindow *aParent, const nsIID & iid,
> void **result) = 0; from nsIPromptFactory
>
> So makes it all not compatible.
>
> Is there any way I can rebuild the Firefox SDK with the old nsIDOMWindow
>
> On Wed, Feb 10, 2016 at 7:51 PM, Kyle Huey <m...@kylehuey.com> wrote:
>
>> Yeah, ok, nsPIDOMWindow then.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 4:49 PM, Devan Shah <devan.sha...@gmail.com>
>> wrote:
>>
>>> Version 45, I am using the SDK from
>>> https://ftp.mozilla.org/pub/firefox/releases/45.0b4/win32/en-US/firefox-45.0b4.sdk.zip.
>>> Which I still see the nsIPromptFactory has
>>>
>>>   /* void getPrompt (in nsIDOMWindow aParent, in nsIIDRef iid, [iid_is
>>> (iid), retval] out nsQIResult result); */
>>>   NS_IMETHOD GetPrompt(nsIDOMWindow *aParent, const nsIID & iid, void
>>> **result) = 0;
>>>
>>>
>>>
>>> <https://ftp.mozilla.org/pub/firefox/releases/45.0b4/win32/en-US/firefox-45.0b4.sdk.zip>
>>>
>>> On Wed, Feb 10, 2016 at 7:43 PM, Kyle Huey <m...@kylehuey.com> wrote:
>>>
>>>> Ok ... ignoring the question of how you're using it from C++ since
>>>> binary addons are gone, many of the methods on nsIDOMWindow moved to
>>>> nsPIDOMWindow and then to nsPIDOMWindowInner/Outer, depending on what
>>>> version of Gecko you're using.  Today on trunk nsIPromptFactory takes a
>>>> mozIDOMWindowProxy, which is a base interface of nsPIDOMWindowOuter.  You
>>>> can look at
>>>> http://mxr.mozilla.org/mozilla-central/source/dom/base/nsPIDOMWindow.h
>>>> to see what's there.  Some methods on nsIDOMWindow that were unused were
>>>> removed completely, though I don't think there were many.
>>>>
>>>> - Kyle
>>>>
>>>> On Wed, Feb 10, 2016 at 4:40 PM, Devan Shah <devan.sha...@gmail.com>
>>>> wrote:
>>>>
>>>>> I am using it from c++
>>>>>
>>>>> On Wed, Feb 10, 2016 at 7:38 PM, Kyle Huey <m...@kylehuey.com> wrote:
>>>>>
>>>>>> Are you using it from JS or C++?  If you're using it from JS, nothing
>>>>>> has changed.
>>>>>>
>>>>>> - Kyle
>>>>>>
>>>>>> On Wed, Feb 10, 2016 at 4:32 PM, Devan Shah <devan.sha...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> nsIDOMWindow is deprecated now according to:
>>>>>>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindow
>>>>>>> is there an alternative for this interface. I am using a lot of 
>>>>>>> functions
>>>>>>> from this interface and also using nsIPromptFactory which relies on
>>>>>>> nsIDOMWindow a lot for all of it functions.
>>>>>>>
>>>>>>> Is there any way to get an alternative with the same functionality
>>>>>>> which requires minimal changes or is there a way that I can get the
>>>>>>> nsIDOMWindow interface and all of its functionality back by adding the
>>>>>>> interface locally and implementing the functions locally.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Devan Shah
>>>>>>> ___
>>>>>>> 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: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Right, that will work, although you could nsCOMPtr to make it a lot
prettier:

void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
{
  nsCOMPtr window = do_QueryInterface(aDOMWindow);
  nsCOMPtr docShell;
  if (window)
window->GetDocShell(getter_AddRefs(docShell));
  nsIWebShell* rootWebShell = 0;
  NS_IF_RELEASE(rootWebShell);
//return status;
}

- Kyle

On Wed, Feb 10, 2016 at 5:22 PM, Devan Shah <devan.sha...@gmail.com> wrote:

> Do you happen to have a QueryInterface example,
>
> Would something like the following work:
>
> void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
> {
>   nsPIDOMWindow* window = 0;
>   nsresult status = aDOMWindow->QueryInterface(NS_GET_IID(nsPIDOMWindow),
> (void**));
>   nsIDocShell* docShell = 0;
>   if (window)
> window->GetDocShell();
>   nsIWebShell* rootWebShell = 0;
>   NS_IF_RELEASE(rootWebShell);
>   NS_IF_RELEASE(docShell);
>   NS_IF_RELEASE(window);
> //    return status;
> }
>
> On Wed, Feb 10, 2016 at 8:16 PM, Kyle Huey <m...@kylehuey.com> wrote:
>
>> Alright, just QueryInterface between nsIDOMWindow and nsPIDOMWindow when
>> you have one and need the other and you should be fine.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 5:15 PM, Devan Shah <devan.sha...@gmail.com>
>> wrote:
>>
>>> Currently I just want to get it up and running again on FF 45 again,
>>> with out making too much changes because we plan to deprecate this feature
>>> mid this year or so.
>>>
>>> Just need to get it working on Firefox 45, currently works perfectly on
>>> Firefox 38.
>>>
>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Yeah, ok, nsPIDOMWindow then.

- Kyle

On Wed, Feb 10, 2016 at 4:49 PM, Devan Shah <devan.sha...@gmail.com> wrote:

> Version 45, I am using the SDK from
> https://ftp.mozilla.org/pub/firefox/releases/45.0b4/win32/en-US/firefox-45.0b4.sdk.zip.
> Which I still see the nsIPromptFactory has
>
>   /* void getPrompt (in nsIDOMWindow aParent, in nsIIDRef iid, [iid_is
> (iid), retval] out nsQIResult result); */
>   NS_IMETHOD GetPrompt(nsIDOMWindow *aParent, const nsIID & iid, void
> **result) = 0;
>
>
>
> <https://ftp.mozilla.org/pub/firefox/releases/45.0b4/win32/en-US/firefox-45.0b4.sdk.zip>
>
> On Wed, Feb 10, 2016 at 7:43 PM, Kyle Huey <m...@kylehuey.com> wrote:
>
>> Ok ... ignoring the question of how you're using it from C++ since binary
>> addons are gone, many of the methods on nsIDOMWindow moved to nsPIDOMWindow
>> and then to nsPIDOMWindowInner/Outer, depending on what version of Gecko
>> you're using.  Today on trunk nsIPromptFactory takes a mozIDOMWindowProxy,
>> which is a base interface of nsPIDOMWindowOuter.  You can look at
>> http://mxr.mozilla.org/mozilla-central/source/dom/base/nsPIDOMWindow.h
>> to see what's there.  Some methods on nsIDOMWindow that were unused were
>> removed completely, though I don't think there were many.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 4:40 PM, Devan Shah <devan.sha...@gmail.com>
>> wrote:
>>
>>> I am using it from c++
>>>
>>> On Wed, Feb 10, 2016 at 7:38 PM, Kyle Huey <m...@kylehuey.com> wrote:
>>>
>>>> Are you using it from JS or C++?  If you're using it from JS, nothing
>>>> has changed.
>>>>
>>>> - Kyle
>>>>
>>>> On Wed, Feb 10, 2016 at 4:32 PM, Devan Shah <devan.sha...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello
>>>>>
>>>>> nsIDOMWindow is deprecated now according to:
>>>>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindow
>>>>> is there an alternative for this interface. I am using a lot of functions
>>>>> from this interface and also using nsIPromptFactory which relies on
>>>>> nsIDOMWindow a lot for all of it functions.
>>>>>
>>>>> Is there any way to get an alternative with the same functionality
>>>>> which requires minimal changes or is there a way that I can get the
>>>>> nsIDOMWindow interface and all of its functionality back by adding the
>>>>> interface locally and implementing the functions locally.
>>>>>
>>>>> Thanks
>>>>> Devan Shah
>>>>> ___
>>>>> 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: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Ok.  I thought we killed binary components in extensions ...

There will be a lot of changes around windows and their XPIDL interfaces in
Gecko over the next while so you should expect to have to update this code
fairly frequently if you're actually calling methods on nsIDOMWindow.

- Kyle

On Wed, Feb 10, 2016 at 5:10 PM, Devan Shah  wrote:

> I was using the xulrunner SDK, but that is no longer created any more so
> using the firefox SDK.
>
> I am using it to create a plugin which can be used to launch a web browser
> which communicates with a proxy server which can be used to capture all the
> http traffic.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Alright, just QueryInterface between nsIDOMWindow and nsPIDOMWindow when
you have one and need the other and you should be fine.

- Kyle

On Wed, Feb 10, 2016 at 5:15 PM, Devan Shah  wrote:

> Currently I just want to get it up and running again on FF 45 again, with
> out making too much changes because we plan to deprecate this feature mid
> this year or so.
>
> Just need to get it working on Firefox 45, currently works perfectly on
> Firefox 38.
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

You get the nsIDOMWindow, and then QueryInterface to nsPIDOMWindow to call
GetTop on it.

- Kyle

On Wed, Feb 10, 2016 at 5:35 PM, Devan Shah <devan.sha...@gmail.com> wrote:

> In the below code i use aWebProgress to and then GetDOMWindow on that,
> however GetDOMWindow only allows nsIDOMWindow, would the QueryInterface
> accommodate for this for this
>
> NS_IMETHODIMP WebBrowserChrome::OnLocationChange(nsIWebProgress*
> aWebProgress,
> nsIRequest* aRequest,
> nsIURI *location,
> uint32_t aFlags)
> {
> PRBool isSubFrameLoad = PR_FALSE; // Is this a subframe load
> if (aWebProgress) {
> nsCOMPtr  domWindow;
> nsCOMPtr  topDomWindow;
> aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
> if (domWindow) { // Get root domWindow
> domWindow->GetTop(getter_AddRefs(topDomWindow));
> }
> if (domWindow != topDomWindow)
> isSubFrameLoad = PR_TRUE;
> }
> if (!isSubFrameLoad)
> CWebBrowserChromeUI::UpdateCurrentURI(this);
> return NS_OK;
> }
>
> On Wed, Feb 10, 2016 at 8:30 PM, Kyle Huey <m...@kylehuey.com> wrote:
>
>> Yes, SizeToContent is only accessible to JS now.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 5:28 PM, Devan Shah <devan.sha...@gmail.com>
>> wrote:
>>
>>> yep
>>>
>>> This is how I was using nsIDOMWindow before:
>>>
>>> NS_IMETHODIMP WebBrowserChrome::OnLocationChange(nsIWebProgress*
>>> aWebProgress,
>>> nsIRequest* aRequest,
>>> nsIURI *location,
>>> uint32_t aFlags)
>>> {
>>> PRBool isSubFrameLoad = PR_FALSE; // Is this a subframe load
>>> if (aWebProgress) {
>>> nsCOMPtr  domWindow;
>>> nsCOMPtr  topDomWindow;
>>> aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
>>> if (domWindow) { // Get root domWindow
>>> domWindow->GetTop(getter_AddRefs(topDomWindow));
>>> }
>>> if (domWindow != topDomWindow)
>>> isSubFrameLoad = PR_TRUE;
>>> }
>>> if (!isSubFrameLoad)
>>> CWebBrowserChromeUI::UpdateCurrentURI(this);
>>> return NS_OK;
>>> }
>>>
>>> So here just changing nsCOMPtr to nsCOMPtr
>>> and using QueryInterface should do the trick right?
>>>
>>> Also I am using a function called SizeToContent() from nsIDOMWindow
>>> which I do not see exists any more in nsPIDOMWindow either was this one
>>> removed completly.
>>>
>>> On Wed, Feb 10, 2016 at 8:24 PM, Kyle Huey <m...@kylehuey.com> wrote:
>>>
>>>> Right, that will work, although you could nsCOMPtr to make it a lot
>>>> prettier:
>>>>
>>>> void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
>>>> {
>>>>   nsCOMPtr window = do_QueryInterface(aDOMWindow);
>>>>   nsCOMPtr docShell;
>>>>   if (window)
>>>> window->GetDocShell(getter_AddRefs(docShell));
>>>>   nsIWebShell* rootWebShell = 0;
>>>>   NS_IF_RELEASE(rootWebShell);
>>>> //return status;
>>>> }
>>>>
>>>> - Kyle
>>>>
>>>> On Wed, Feb 10, 2016 at 5:22 PM, Devan Shah <devan.sha...@gmail.com>
>>>> wrote:
>>>>
>>>>> Do you happen to have a QueryInterface example,
>>>>>
>>>>> Would something like the following work:
>>>>>
>>>>> void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
>>>>> {
>>>>>   nsPIDOMWindow* window = 0;
>>>>>   nsresult status =
>>>>> aDOMWindow->QueryInterface(NS_GET_IID(nsPIDOMWindow), (void**));
>>>>>   nsIDocShell* docShell = 0;
>>>>>   if (window)
>>>>> window->GetDocShell();
>>>>>   nsIWebShell* rootWebShell = 0;
>>>>>   NS_IF_RELEASE(rootWebShell);
>>>>>   NS_IF_RELEASE(docShell);
>>>>>   NS_IF_RELEASE(window);
>>>>> //return status;
>>>>> }
>>>>>
>>>>> On Wed, Feb 10, 2016 at 8:16 PM, Kyle Huey <m...@kylehuey.com> wrote:
>>>>>
>>>>>> Alright, just QueryInterface between nsIDOMWindow and nsPIDOMWindow
>>>>>> when you have one and need the other and you should be fine.
>>>>>>
>>>>>> - Kyle
>>>>>>
>>>>>> On Wed, Feb 10, 2016 at 5:15 PM, Devan Shah <devan.sha...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Currently I just want to get it up and running again on FF 45 again,
>>>>>>> with out making too much changes because we plan to deprecate this 
>>>>>>> feature
>>>>>>> mid this year or so.
>>>>>>>
>>>>>>> Just need to get it working on Firefox 45, currently works perfectly
>>>>>>> on Firefox 38.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Splitting inner and outer windows

[Kyle Huey]

This has landed (and stuck) on inbound.

- Kyle

On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey <m...@kylehuey.com> wrote:

> Early in the next release cycle I plan to land a patch that will remove
> nsPIDOMWindow in favor of two separate types for inner and outer windows
> (fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter)  I'll also make
> changes to the XPIDL interface hierarchy (effectively removing nsIDOMWindow
> and introducing two new base interfaces for inner and outer windows) to
> support this.  When the dust settles places that today use nsPIDOMWindow or
> nsIDOMWindow will instead use a type that specifies, at compile time,
> whether we have an inner or outer window.
>
> The actual methods exposed on nsPIDOMWindow will be carried over in almost
> all cases.  Splitting the interface itself, or nsGlobalWindow, apart will
> happen later.
>
> You can follow along in bug 1241764.
>
> - Kyle
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug Program Next Steps

[Kyle Huey]

On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries  wrote:

> We believe that the number of outstanding, actionable bugs is the best
> metric of code quality available, and that how this number changes over
> time will be a strong indicator of the evolving quality of Firefox.
>

Why do we believe that?

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

Re: IndexedDB access in third-party iFrames disabled or not?

[Kyle Huey]

We changed this in bug 1147821.  It looks like the documentation hasn't
been updated.

- Kyle

On Mon, Jan 25, 2016 at 10:26 AM,  wrote:

> Is IndexedDB supposed to be accessible in third-party iFrames? From what I
> understand, the MDN documentation says IndexedDB is *not* accessible in
> third-party iFrames, but from my own tests, I have been fully able to use
> IndexedDB in third-party iFrames.
>
> The MDN documentation link:
> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Security
> Search for "It's important to note that IndexedDB doesn't work for content
> loaded into a frame"
>
> MDN links to RESOLVED FIXED Bugzilla 595307:
> https://bugzilla.mozilla.org/show_bug.cgi?id=595307
>
> I guess I don't really understand what the status is. I'm able to use
> IndexedDB in third-party iFrames, but maybe I shouldn't be able to? What
> are Firefox's plans for IndexedDB in third-party iFrames?
>
> If necessary, I can upload some test code. Hopefully this is the right
> place to ask, thanks for reading this!
> ___
> 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: IndexedDB access in third-party iFrames disabled or not?

[Kyle Huey]

Awesome, thanks.

- Kyle

On Mon, Jan 25, 2016 at 10:56 AM, Chris Mills <cmi...@mozilla.com> wrote:

> Whoops, sorry about that. I’ve updated it now, and made sure that we don’t
> repeat this erroneous point in any other docs.
>
> Chris Mills
>  Senior tech writer || Mozilla
> developer.mozilla.org || MDN
>  cmi...@mozilla.com || @chrisdavidmills
>
> > On 25 Jan 2016, at 18:35, Kyle Huey <m...@kylehuey.com> wrote:
> >
> > We changed this in bug 1147821.  It looks like the documentation hasn't
> > been updated.
> >
> > - Kyle
> >
> > On Mon, Jan 25, 2016 at 10:26 AM, <ja...@onesignal.com> wrote:
> >
> >> Is IndexedDB supposed to be accessible in third-party iFrames? From
> what I
> >> understand, the MDN documentation says IndexedDB is *not* accessible in
> >> third-party iFrames, but from my own tests, I have been fully able to
> use
> >> IndexedDB in third-party iFrames.
> >>
> >> The MDN documentation link:
> >>
> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Security
> >> Search for "It's important to note that IndexedDB doesn't work for
> content
> >> loaded into a frame"
> >>
> >> MDN links to RESOLVED FIXED Bugzilla 595307:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=595307
> >>
> >> I guess I don't really understand what the status is. I'm able to use
> >> IndexedDB in third-party iFrames, but maybe I shouldn't be able to? What
> >> are Firefox's plans for IndexedDB in third-party iFrames?
> >>
> >> If necessary, I can upload some test code. Hopefully this is the right
> >> place to ask, thanks for reading this!
> >> ___
> >> 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
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Splitting inner and outer windows

[Kyle Huey]

On Fri, Jan 22, 2016 at 11:24 AM, Bobby Holley <bobbyhol...@gmail.com>
wrote:

>
>
> On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey <m...@kylehuey.com> wrote:
>
>> Early in the next release cycle I plan to land a patch that will remove
>> nsPIDOMWindow in favor of two separate types for inner and outer windows
>> (fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter)  I'll also make
>> changes to the XPIDL interface hierarchy (effectively removing
>> nsIDOMWindow
>> and introducing two new base interfaces for inner and outer windows) to
>> support this.  When the dust settles places that today use nsPIDOMWindow
>> or
>> nsIDOMWindow will instead use a type that specifies, at compile time,
>> whether we have an inner or outer window.
>>
>
> Huzzah!
>
>
>> The actual methods exposed on nsPIDOMWindow will be carried over in almost
>> all cases.  Splitting the interface itself, or nsGlobalWindow, apart will
>> happen later.
>>
>
> Is the nsGlobalWindow split likely to happen soon, or is it being
> indefinitely postponed? We have a fair amount of code that uses it directly
> to avoid virtual calls.
>
>
>>
>> You can follow along in bug 1241764.
>>
>> - Kyle
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
My long term plan of sorts is to move "outer" windows into docshell rather
than actually splitting it.

I don't expect to work on that part myself anytime soon though.

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

Re: Splitting inner and outer windows

[Kyle Huey]

They will continue to implement nsIDOMWindow just like they do
nsIDOMWindowInternal.  We're simply not going to use it for anything.

- Kyle

On Fri, Jan 22, 2016 at 7:53 AM, Dave Townsend <dtowns...@mozilla.com>
wrote:

> Does this mean that window objects will no longer implement
> nsIDOMWindow (at least as far as JS is concerned)? Querying for
> nsIDOMWindow is something add-ons do a lot and I'd expect to see a lot
> of add-ons break if we changed that.
>
> On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey <m...@kylehuey.com> wrote:
> > Early in the next release cycle I plan to land a patch that will remove
> > nsPIDOMWindow in favor of two separate types for inner and outer windows
> > (fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter)  I'll also make
> > changes to the XPIDL interface hierarchy (effectively removing
> nsIDOMWindow
> > and introducing two new base interfaces for inner and outer windows) to
> > support this.  When the dust settles places that today use nsPIDOMWindow
> or
> > nsIDOMWindow will instead use a type that specifies, at compile time,
> > whether we have an inner or outer window.
> >
> > The actual methods exposed on nsPIDOMWindow will be carried over in
> almost
> > all cases.  Splitting the interface itself, or nsGlobalWindow, apart will
> > happen later.
> >
> > You can follow along in bug 1241764.
> >
> > - Kyle
> > ___
> > 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

Splitting inner and outer windows

[Kyle Huey]

Early in the next release cycle I plan to land a patch that will remove
nsPIDOMWindow in favor of two separate types for inner and outer windows
(fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter)  I'll also make
changes to the XPIDL interface hierarchy (effectively removing nsIDOMWindow
and introducing two new base interfaces for inner and outer windows) to
support this.  When the dust settles places that today use nsPIDOMWindow or
nsIDOMWindow will instead use a type that specifies, at compile time,
whether we have an inner or outer window.

The actual methods exposed on nsPIDOMWindow will be carried over in almost
all cases.  Splitting the interface itself, or nsGlobalWindow, apart will
happen later.

You can follow along in bug 1241764.

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

Re: Proposal to stop revving UUIDs when changing XPIDL interfaces

[Kyle Huey]

As the XPIDL module owner, I support this.

- Kyle

On Fri, Jan 15, 2016 at 7:58 AM, Ehsan Akhgari 
wrote:

> Historically we have enforced updating the XPIDL interface UUIDs when you
> made any changes to it.  This was needed because of two reasons:
>
> * Backwards compatibility with binary extensions.  Since many changes to
> XPIDL interfaces caused the underlying v-table layout to change, revving
> the UUID enabled previously compiled extensions to fail getting the
> interface through QueryInterface() in the first place, preventing crashes
> when they try to use the interface.
>
> * Incremental builds.  Our build system used to not repack the compiled
> XPT file unless it detected a change in the UUID, which would manifest as
> weird issues when you landed code changing an interface without changing
> its UUID, in that in incremental builds the XPT file would be outdated, but
> in clobbered builds it would be correct.
>
> We have created Mercurial hooks that enforce a UUID change when an idl
> file is touched because of these requirements.
>
> Ever since Firefox 41, we have stopped supporting binary components in
> extensions, so the first reason doesn’t apply any more.  And since
> yesterday I have fixed bug 977464 which fixes the second issue.  So as far
> as I can tell, there is no reason to keep revving UUIDs any more. Therefore
> I would like to propose that we should remove the Mercurial hook (bug
> 1170718) and relax this requirement on trunk, and let this ride the trains.
>
> Three points worth mentioning here.
>
> * Thunderbird still supports binary components in extensions.  In <
> https://bugzilla.mozilla.org/show_bug.cgi?id=977464#c31> Kent said that
> Thunderbird is OK with change.
>
> * My proposal has no bearing on whether changes to XPIDL interfaces needs
> to be considered as part of the uplift approval process, as such changes
> can still have an impact on JS extension compatibility. Therefore under my
> proposal we’d reword the approval canned questionnaire on Bugzilla to talk
> about changes to XPIDL interfaces in addition to string changes, in lieu of
> mentioning UUID changes.
>
> * UUIDs are still the unique identifiers used in QueryInterface()
> implementations and you'd still need to tag the interface with a UUID when
> you create a new XPIDL interface.
>
> Please let me know if you have any questions or concerns.
>
> Cheers,
> Ehsan
> ___
> 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: Dominator tree memory analysis now in Nightly

[Kyle Huey]

This is awesome.  We've talked about how much we've wanted this since the
early days of MemShrink back in 2011.  Thanks to everyone who was involved.

- Kyle

On Thu, Jan 14, 2016 at 1:50 PM, Nick Fitzgerald 
wrote:

> Hi folks!
>
> Dominator trees give you fine-grained insight into memory retention.
>
> In a graph rooted by some node R, a node A is said to dominate B iff every
> path to B starting from R passes through A. In the context of a heap graph,
> another way to say this would be that A is retaining B: if the garbage
> collector found A to be unreachable and eligible for reclaiming, than B
> would also be unreachable and eligible for reclaiming.
>
> We also use this to calculate the "true" memory cost of a node in the heap
> graph. This is the "retained size" and contrasts with the naive "shallow
> size". For example, imagine a large binary tree where there are no outside
> references into subtrees, only to the root. The root node itself has a
> small shallow size: a left branch pointer, a value, and a right branch
> pointer. However, it is retaining the whole rest of this large tree's
> structure, and so its retained size is significant.
>
> Here is a screenshot of the dominator tree (combined with allocation stack
> tracking) in action to debug the memory overhead of loading large source
> files in a CodeMirror editor: http://i.imgur.com/sGsVJb9.png
>
> And here is a reminder of how to enable to memory tool within the
> devtools: http://i.imgur.com/hEPTqrT.png
>
> If you would like to use this tool for the whole runtime rather than
> scoped to a single tab, use the browser toolbox. Here are instructions for
> enabling and using the browser toolbox:
> https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox
>
> Please try it out, give me your feedback, and file bugs in the "Firefox"
> product and "Developer Tools: Memory" component!
>
> My thanks to the folks who reviewed patches for this feature: Jordan
> Santell, Steve Fink, Boris Zbarsky, and Jim Blandy.
>
> Cheers,
>
> Nick
>
> ___
> 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: Feedback needed on proposal to add a web primitive for queuing microtasks

[Kyle Huey]

In principle, I don't see any reason not to do this.

- Kyle

On Wed, Jan 13, 2016 at 1:59 PM, Boris Zbarsky  wrote:

> Please see https://github.com/whatwg/html/issues/512
>
> Right now this is in the "does anyone have an objection to the basic
> idea?" stage.  So if someone does, please speak up!
>
> I've already noted a possible concern about abuse, but Promise and
> MutationObserver kinda allow that already; it just takes a bit of skill to
> do it.  I haven't thought of other problems with it thus far.
>
> -Boris
> ___
> 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

dump() calls now available in NSPR logging

[Kyle Huey]

In Bug 1059469 I added a logging module for calls to dump() on Window
and WorkerGlobalScope.  You can enable it with
NSPR_LOG_MODULES="Dump:5".  This is really handy when you're using
other logging modules and want to see how content script execution
fits into the logging output.

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

Re: nsThread now leaks runnables if dispatch fails

[Kyle Huey]

On Mon, Jan 4, 2016 at 4:10 PM, Randell Jesup <rje...@jesup.org> wrote:
>>Kyle Huey writes:
>>
>>> (This is a continuation of the discussion in bug 1218297)
>>>
>>> In bug 1155059 we made nsIEventTarget::Dispatch take an
>>> already_AddRefed instead of a raw pointer.  This was done to allow the
>>> dispatcher to transfer its reference to the runnable to the thread the
>>> runnable will run on.  That solves a race condition we've had
>>> historically where the destructor of a runnable can run on either the
>>> dispatching thread or the executing thread, depending on whether the
>>> executing thread can run the event to completion before the
>>> dispatching thread destroys the nsCOMPtr on the stack.
>>
>>IIUC solving the race condition wasn't the goal of the change in
>>API, but something that was done to retain existing workarounds
>>for leaks.
>
> Solving the "who knows what thread this will be released on" was a
> primary goal.  See comment 0, and the discussion here it references.
>
> Independently, bsmedberg wanted to make Dispatch infallible (at least
> normally), thus making the pattern of "avoid leak in the case of
> Dispatch failing" irrelevant (once done, which it hasn't been).

This seems like the best path forward.

> I started the conversion of Dispatch(rawptr) in the tree to
> Dispatch(already_AddRefed<>); xidorn took over finishing it but hasn't
> yet.  We should re-energize that.

>From the perspective of bug 1218297, that change doesn't actually
affect anything.

> There's considerable discussion in the bug of when leaks occur and also
> the assumed behavior of DispatchToMainThread (which is especially
> failure-prone because of how XPCOM dispatch works - even when MainThread
> still exists, that can fail in shutdown).

Ok, cool.  I didn't want to read the entire thing :)

>>> In bug 1218297 we saw a case where dispatch to a thread (the socket
>>> transport service thread in this case) fails because the thread has
>>> already shut down.  In our brave new world, nsThread simply leaks the
>>> runnable.
>
> Yup.  In cases where we anticipate a possible Dispatch failure (which is
> supposed to become impossible, but isn't currently) you can use the
> (still-existing) raw ptr interface and handle Dispatch failure
> explicitly to release the (leaked) reference, if it's safe.  Not all
> cases are safe to release in that case (which is what drove the initial
> bug filing, where it tried to release JS objects on Dispatch failure off
> mainthread).  Leaking is better than crashing/sec-bugs.

No, you can't.  If you can the raw ptr interface today Dispatch will
create its own reference and pass that to the already_AddRefed version
which then leaks it.  There's no way for the caller to handle this
safely.  Again, as karlt points out, Dispatch leaks today even if the
caller does everything correctly.

Leaking is better than crashing/sec-bugs, but that doesn't mean that
we get to introduce leaks to fix crash/sec-bugs, especially when it's
possible to fix the bug through other means.

> If the problem is that when this happens, a leak is reported by infra,
> then we could ping the leak-checker that there was a dispatch failure
> and leaks are expected.  Even better but maybe not possible would be
> annotate the root of the leak and suppress anything tied to it.

The problem is not that a leak is reported, the problem is that we
leak.  Automatically hiding our bugs is not good engineering practice.

>>> It can't release the reference it holds, because that would
>>> reintroduce the race condition we wanted to avoid, and it can't
>>> release the reference on the correct thread so it's already gone away.
>>> But now we have a new source of intermittent leaks.
>>>
>>> Was this anticipated when designing bug 1155059?  I don't think
>>> leaking is acceptable here, so we may need to back that out and return
>>> to living with that race condition.
>>
>>I agree this approach is not going to work out.  Short term, I
>>think the situation could be improved and most of those changes
>>kept by adding a DispatchOrLeak() variant that can be used by the
>>callers that want to leak.  Then we still have the leaks we had
>>prior to 2265e031ab97 but the new ones are resolved.
>>
>>For the remaining (old) leaks I can think of two options:
>>
>>1) Never call Dispatch() when it might fail and assert that it
>>   does not.
>>
>>2) Keep and additional reference to the runnable in the caller if
>>   it doesn't want Dispatch() to release the last reference.
>>
>>With the former, the caller 

Re: nsThread now leaks runnables if dispatch fails

[Kyle Huey]

The "race condition" here is the question of which thread the runnable
destructor runs on.  If the executing thread is already shut down the
destructor still runs on the "wrong" dispatching thread (or not at
all).  Since the point of fixing the original race is to guarantee
that the destructor runs on the executing thread it's useful to
consider this an extension of the original race.

- Kyle

On Mon, Jan 4, 2016 at 10:39 PM, Ting-Yu Chou  wrote:
>
>> In bug 1218297 we saw a case where dispatch to a thread (the socket
>> transport service thread in this case) fails because the thread has
>> already shut down.  In our brave new world, nsThread simply leaks the
>> runnable.  It can't release the reference it holds, because that would
>> reintroduce the race condition we wanted to avoid, and it can't
>> release the reference on the correct thread so it's already gone away.
>
>
> I am a bit confused with this, if the executing thread has already shut
> down,
> why would releasing the reference dispatching thread holds reintroduce the
> race
> condition? Who is racing with dispatching thread?
>
> Ting
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

nsThread now leaks runnables if dispatch fails

[Kyle Huey]

(This is a continuation of the discussion in bug 1218297)

In bug 1155059 we made nsIEventTarget::Dispatch take an
already_AddRefed instead of a raw pointer.  This was done to allow the
dispatcher to transfer its reference to the runnable to the thread the
runnable will run on.  That solves a race condition we've had
historically where the destructor of a runnable can run on either the
dispatching thread or the executing thread, depending on whether the
executing thread can run the event to completion before the
dispatching thread destroys the nsCOMPtr on the stack.  So far, so
good.

In bug 1218297 we saw a case where dispatch to a thread (the socket
transport service thread in this case) fails because the thread has
already shut down.  In our brave new world, nsThread simply leaks the
runnable.  It can't release the reference it holds, because that would
reintroduce the race condition we wanted to avoid, and it can't
release the reference on the correct thread so it's already gone away.
But now we have a new source of intermittent leaks.

Was this anticipated when designing bug 1155059?  I don't think
leaking is acceptable here, so we may need to back that out and return
to living with that race condition.

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

Re: Question: why an external DTD is accessed (or not)? (svg11.dtd)

[Kyle Huey]

Bug 994305 is on file for this.

- Kyle

On Sat, Nov 21, 2015 at 10:57 AM, ISHIKAWA,chiaki  wrote:
> Hi,
>
> I have been puzzled at a pair of strange warning messages over the last few
> years, but can't hold the curiosity any longer.
>
> So here is my question.
>
> During the invocation of TB |make mozmill| test suite by running locally
> produced DEBUG version of C-C test, I have seen the following error messages
> in the log.
> Below, 35 is the number of times the error was seen in the latest run.
> The next [4482] is a sample of the process ID and should be ignored.
>
>  35 [4482] WARNING: Failed to open external DTD: publicId "-//W3C//DTD
> SVG 1.1//EN" systemId "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;
> base
> "file:///NREF-COMM-CENTRAL/comm-central/mail/themes/linux/mail/tabs/selected-start.svg"
> URL "resource://gre/res/dtd/svg11.dtd": file
> /NREF-COMM-CENTRAL/comm-central/mozilla/parser/htmlparser/nsExpatDriver.cpp,
> line 705
>
>  35 [4482] WARNING: Failed to open external DTD: publicId "-//W3C//DTD
> SVG 1.1//EN" systemId "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;
> base
> "file:///NREF-COMM-CENTRAL/comm-central/mail/themes/linux/mail/tabs/selected-end.svg"
> URL "resource://gre/res/dtd/svg11.dtd": file
> /NREF-COMM-CENTRAL/comm-central/mozilla/parser/htmlparser/nsExpatDriver.cpp,
> line 705
>
> It seems that the  TB binary seems to try to access external DTD and
> failed(?).
>
> From what I read in the past, W3C's position seems to be that
> the web resource of W3C should not be accessed during the runtime for
> obvious performance reasons, and the application is encouraged to have
> a local copy anyway.
> But if my reading of the code was correct, it was as if TB by way of mozilla
> library was doing just that (?)
> Or is it simply TB's packaging forgets to place svg11.dtd in the expected
> place?
>
> Any sensible explanation why this is happening (or not) and why we have
> this pair of warning messages printed during the execution of the DEBUG
> version of C-C TB is appreciated.
>
> These messages were visible in January 2013 and possibly earlier.
> I have deleted the log due to space reasons :-(
>
> Actually, I see another failure of opening external DTD, but it occurs just
> once, so it is not THAT disturbing.
> I can wait for the explanation for *THAT*: xhtml11.dtd.
> (Maybe the explanation for the pair of messages would solve the puzzle for
> this one, too.)
>
>   1 [5300] WARNING: Failed to open external DTD: publicId "" systemId
> "resource:///res/dtd/xhtml11.dtd" base
> "moz-nullprincipal:{e2a85fc4-28dc-412e-befa-2feaea7c9705}" URL
> "resource://gre/res/dtd/xhtml11.dtd": file
> /NREF-COMM-CENTRAL/comm-central/mozilla/parser/htmlparser/nsExpatDriver.cpp,
> line 705
>
> The last message started to appear in my local log in March 2013 for the
> first time. Maybe it might have something to do with moz-nullprincipal
> thingy (for security hardening).
>
>
> TIA
>
>
>
> ___
> 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: mozilla::RefPtr is dead, long live ::RefPtr

[Kyle Huey]

Huzzah!

When are you going to do nsCOMPtr? ;)

- Kyle

On Sun, Oct 18, 2015 at 7:43 AM, Nathan Froyd  wrote:
> Hi all,
>
> Bug 1207245 has landed on mozilla-central.  Its main purpose in life is to
> unify mozilla::RefPtr and nsRefPtr (both of which live in MFBT) into a
> single RefPtr class.  This new RefPtr class, like nsRefPtr, lives at the
> *global* scope, not in the mozilla:: namespace.  Follow-up patches or ideas
> on how to fix this welcome; I have brute-force ideas on how to do it, but
> they require large quantities of machine time.
>
> The new RefPtr works exactly the same as the old nsRefPtr: getter_AddRefs,
> interoperation with nsCOMPtr, etc.  It's worth noting that if you used
> byRef with mozilla::RefPtr for (XP)COM outparam semantics, you'll have to
> use getter_AddRefs now instead.  Please note that getter_AddRefs zeroes out
> the pointer prior to passing it as an outparam (as it has always done),
> which byRef did *not* do.  (You should not have been depending on this
> behavior, but if you were...)
>
> Updating patches/commits affected by these changes should be as simple as
> running:
>
> perl -p -i -e 's#mozilla/nsRefPtr.h#mozilla/RefPtr.h#'
> perl -p -i -e 's#mozilla::RefPtr#RefPtr#'
> perl -p -i -e 's#nsRefPtr<#RefPtr<#'
> perl -p -i -e 's#byRef#getter_AddRefs#'
>
> over the affected files.
>
> As a side-effect of these changes, mozilla::RefCounted and
> mozilla::external::AtomicRefCounted have moved to their own header,
> mozilla/RefCounted.h.
>
> Happy hacking,
> -Nathan
> ___
> 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: mozilla::RefPtr is dead, long live ::RefPtr

[Kyle Huey]

I meant removing the ns prefix (i.e. s/nsCOMPtr/COMPtr/), which is the
net effect of this change for places that previous used nsRefPtr,
AIUI.

- Kyle

On Sun, Oct 18, 2015 at 8:24 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 10/18/15 11:11 AM, Kyle Huey wrote:
>>
>> When are you going to do nsCOMPtr? ;)
>
>
> Are we sure there is no codesize hit when moving from nsCOMPtr (which tries
> to share implementation via nsCOMPtr_base) to RefPtr?
>
> -Boris
>
> ___
> 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 ship: IDB getAll/getAllKeys/openKeyCursor

[Kyle Huey]

I intend to ship the following features in Gecko 44:

IDBObjectStore.getAll
IDBObjectStore.getAllKeys
IDBObjectStore.openKeyCursor
IDBIndex.getAll
IDBIndex.getAllKeys

These features will be available on all platforms and are specced at
[0].  The bug tracking this work is [1].  Some of these features are
available today behind the dom.indexedDB.experimental preference,
while others have unconditionally exposed prefixed versions.  We have
achieved spec agreement and interop with Blink, who also intends to
release these early next year.

- Kyle

[0] https://w3c.github.io/IndexedDB/
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1196841
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Kyle Huey]

How much time does it save?

- Kyle

On Thu, Oct 1, 2015 at 10:10 PM, Gregory Szorc  wrote:
> Currently, the Firefox build system builds C++ tests by default. This adds
> extra time to builds for something that a significant chunk of developers
> don't care about because they don't run them.
>
> An easy way to get faster builds is to disable C++ tests by default
> (requiring a mozconfig entry to enable them - which would be enabled in
> automation, of course). A more involved solution is to build them on
> demand, when tests are executed (unless a build option says to build them
> like today).
>
> I was curious if Gecko developers (the audience I perceive that cares about
> them the most) would be generally opposed to disabling building C++ tests
> by default. If not, we can go with an easy solution (and require people who
> care to add a mozconfig entry). If so, we go with the harder solution.
>
> Is disabling building C++ tests by default a reasonable change?
> ___
> 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: CloseFile() latency on Windows

[Kyle Huey]

We recently dealt with something similar in Gecko.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=1152046

- Kyle

On Mon, Sep 28, 2015 at 2:41 PM, Gregory Szorc  wrote:
> As part of profiling a Python process on Windows using Process Monitor.exe,
> I noticed that closing file handles using CloseFile() takes 1+ms. Contrast
> this with other I/O related system calls like WriteFile() that tend to take
> ~1us. (I /think/ it only takes a longer time if the file has been written
> to.) This is on Windows 10 running natively (no VM) when writing to an SSD.
> Files are opened with _fopen() in "a+" mode if it matters. I can also repro
> in "a" mode.
>
> When writing thousands of files in rapid succession, this 1+ms pause
> (assuming synchronous I/O) piles up. Assuming a 1ms pause, writing 100,000
> files spends 100s in CloseFile()! The process profile also shows the bulk
> of the time in CloseFile(), so this is a real hot spot.
>
> Both Mercurial and the Firefox build system need to write thousands of
> files in rapid order. Both are using Python. Both should experience
> significant performance improvements if we find a more efficient way to do
> bulk file writing (which currently is over 2x slower than Linux and OS X).
>
> Short of going full overlapped I/O (which will be a PITA with Python), the
> best I can think of is to perform CloseFile() on a background thread or
> pool of background threads.
>
> I was curious if anyone has dug into optimizing the writing of thousands of
> files on Windows and can share any insights so we can make the Firefox
> build system and Mercurial significantly faster on Windows.
>
> gps
> ___
> 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: MozPromises are now in XPCOM

[Kyle Huey]

On Tue, Aug 18, 2015 at 8:17 PM, Bobby Holley bobbyhol...@gmail.com wrote:
 I gave a lightning talk at Whistler about MozPromise and a few other new
 tools to facilitate asynchronous and parallel programming in Gecko. There
 was significant interest, and so I spent some time over the past few weeks
 untangling them from dom/media and hoisting them into xpcom/.

 Bug 1188976 has now landed on mozilla-central, MozPromise (along with
 TaskQueue, AbstractThread, SharedThreadPool, and StateMirroring) can now be
 used everywhere in Gecko.

 I also just published a blog post describing why MozPromises are great and
 how they work: http://bholley.net/blog/2015/mozpromise.html

 Feedback is welcome. These tools are intended to allow developers to easily
 and safely run code on off-main-thread thread pools, which is something we
 urgently need to do more of in Gecko. Go forth and write more parallel code!

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

Does MozPromise have the same skipping the event loop behavior that
JS promises have?  Or is that limited just to StateMirroring?

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

Re: MozPromises are now in XPCOM

[Kyle Huey]

On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley bobbyhol...@gmail.com wrote:
 On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey m...@kylehuey.com wrote:

 Does MozPromise have the same skipping the event loop behavior that
 JS promises have?


 They do not.


 Or is that limited just to StateMirroring?


 Correct, as well as StateWatching. StateMirroring uses StableState to
 dispatch the atomic state updates, and StateWatching uses it to run
 notifications.

 bholley


Good.  This should be clearly documented, as its a subtle but
important distinction from JS promises, which people are likely to be
familiar with.

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

Re: MozPromises are now in XPCOM

[Kyle Huey]

On Wed, Aug 19, 2015 at 5:23 PM, Bobby Holley bobbyhol...@gmail.com wrote:
 On Wed, Aug 19, 2015 at 2:12 PM, Kyle Huey m...@kylehuey.com wrote:

 On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley bobbyhol...@gmail.com
 wrote:
  On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey m...@kylehuey.com wrote:
 
  Does MozPromise have the same skipping the event loop behavior that
  JS promises have?
 
 
  They do not.
 
 
  Or is that limited just to StateMirroring?
 
 
  Correct, as well as StateWatching. StateMirroring uses StableState to
  dispatch the atomic state updates, and StateWatching uses it to run
  notifications.
 
  bholley
 

 Good.  This should be clearly documented, as its a subtle but
 important distinction from JS promises, which people are likely to be
 familiar with.


 Done: https://hg.mozilla.org/integration/mozilla-inbound/rev/db24d3cda834


3

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

Re: Use of 'auto'

[Kyle Huey]

On Sun, Aug 2, 2015 at 2:56 AM, Hubert Figuière h...@mozilla.com wrote:
 On 02/08/15 04:55 AM, smaug wrote:
 A new type of error 'auto' seems to cause, now seen on m-i, is
 auto foo = new SomeRefCountedFoo();

 That hides that foo is a raw pointer but we should be using nsRefPtr.

 So please, consider again when about to use auto. It usually doesn't
 make the code easier to read,
 and it occasionally just leads to errors. In this case it clearly made
 the code harder to read so that
 whoever reviewed that patch didn't catch the issue.

 Shouldn't we, instead, ensure that SomeRefCountedFoo() returns a nsRefPtr?

How do you do that with a constructor?

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

Re: Stop using PL_strchr/strstr et al for parsing - use mozilla::Tokenizer

[Kyle Huey]

On Wed, Jul 29, 2015 at 7:15 AM, Honza Bambas hbam...@mozilla.com wrote:
 I've recently introduced a class making parsing string inputs much safer and
 simpler.  Please see xpcom/ds/Tokenizer.h.  It's simplification of a lexical
 analyzer and it successfully hides boundary checks on the input buffer from
 consumers.  From now on this simple parser class should be used instead of
 any complicated strstr/strchr/Find/Substring unreadable and dangerous
 constructions.

 Tokenizer is simply constructed with a string.  It then automatically cuts
 and converts the input for you to words, numbers, white spaces and special
 characters as you read it, be it a simple while loop or a complex recursive
 descent.

 For details and examples see my post at
 http://www.janbambas.cz/string-parsing-made-simple-with-mozillatokenizer/

 It's brand new, any suggestions on its API greatly welcomed :)

 Cheers
 -hb-

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

Can we rewrite nsCharSeparatedTokenizer on top of this?

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

Re: Hash table iterators, and a call for help

[Kyle Huey]

On Mon, Jul 13, 2015 at 1:36 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
 Hi,

 Last week I landed patches that remove PL_DHashTableEnumerate() from
 the tree (https://bugzilla.mozilla.org/show_bug.cgi?id=1180072). You
 should now use PLDHashTable::Iterator if you want to iterate over a
 PLDHashTable. The iterator is *so* much nicer -- there's none of that
 bundle up an environment as a |void*| pointer and pass it in with a
 function pointer annoyance.

 I have also added Iterator classes to each of nsTHashtable and
 nsBaseHashtable (https://bugzilla.mozilla.org/show_bug.cgi?id=1181445)
 and I would like to also eventually remove the enumerate functions
 from these classes. However, there are 500+ calls to those enumerate
 functions so it's going to take a while.

 For now, I've filed bugs to get rid of all the
 nsTHashtable::EnumerateEntries() calls, which account for ~160 of
 those 500+. They're all blocking
 https://bugzilla.mozilla.org/show_bug.cgi?id=1181443. If you find
 yourself in the mood for some not-too-taxing refactoring, please feel
 free to take on one or more of the unassigned bugs. The number of
 calls to replace in each bug ranges from one or two up to 21. If you
 have any questions please ask. Thank you.

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

Is there a reason the iterator methods are named GetKey(), GetData(),
etc instead of just Key(), Data(), etc?

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

Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)

[Kyle Huey]

On Thu, Jul 16, 2015 at 5:08 PM, Boris Zbarsky bzbar...@mit.edu wrote:

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

 APIs to be removed: mozRequestAnimationFrame, mozAnimationStartTime,
 mozCancelAnimationFrame.

 As of today, they are not used in our tree.


There are a handful of uses in Gaia.  None of them look like they will
break, but we should still clean them up.

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

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Kyle Huey]

On Tue, Jul 14, 2015 at 6:57 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:

 On 2015-07-13 3:07 PM, Jeff Gilbert wrote:

 On Sun, Jul 12, 2015 at 6:45 PM, Thomas Zimmermann 
 tzimmerm...@mozilla.com
 wrote:

  Am 08.07.2015 um 16:36 schrieb smaug:

 Do you actually have any data how many % of Gecko devs would prefer
 not using aFoo?


 I strongly prefer 'aFoo' over 'foo' for the extra context that it gives
 to the variable. If we want to change anything we should rather
 introduce a separate prefix for output parameters.


 Which part of this extra context is useful?


 Repeating what Kats said elsewhere in the thread which seems to have been
 completely ignored in the pile of messages here:

 When debugging in a text based debugger such as gdb, sometimes you have a
 variable called aFoo which has the wrong value, and with the existing
 naming convention, you can quickly run up in the debugger to go to caller
 frames looking for the first time the argument is called something without
 an 'a' prefix, and then you look to see where the value was computed.  If
 we remove this naming convention, you would have to do that work in every
 frame, which would make debugging the same scenario much more time
 consuming.

 Note that if you mostly use a graphical debugger such as Visual Studio,
 you may not rely on this because the debugger would show you more of the
 code in each frame, but I believe graphical debuggers are a niche among
 Mozilla developers.


That assumes that the 'Foo' of aFoo is stable across function boundaries,
which is not always the case.

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

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

[Kyle Huey]

On Tue, Jul 14, 2015 at 8:23 AM, Benjamin Smedberg benja...@smedbergs.us
wrote:



 On 7/8/2015 7:31 AM, Nathan Froyd wrote:

 If somebody is willing to do the formatting, I'm willing to do the
 review. I think the thread has reached the point of people repeating ad
 nauseum what was already said earlier in the thread, so it's time for a
 decision. Benjamin?


 Aww, I was avoiding getting into this thread.

 I personally have no strong preference, and our existing community is
 pretty deeply divided. I doubt we're going to come to consensus here, and
 this is a pretty tough decision to make on its own. I do believe that
 consistency trumps module/personal preference in terms of coding style.

 The argument I am most sympathetic to is that this convention is a barrier
 to new contributors. Making new contributors productive, both employees and
 volunteers, is a very good reason to choose one style over another.

 Given that premise, we shouldn't just change aArgument; we should adopt
 the Google C++ style guide wholesale:

 * names_with_underscores
 * members_with_trailing_
 * no more ns prefix

 There is good research that underscore_names are more readable, and many
 of these will be more familiar to new contributors. Also we have a fair bit
 of shared code with Google.

 If there is a decision to be made here, I'd like to make this RFC:

 * switch our codebase wholesale to the Google C++ style guide

 With the following implementation plan:

 * For now, code should continue to be written in the current style with
 aFoo, mFoo, and camelCase.
 * get our code -Wshadow clean
 * Ask poiru to investigate auto-renaming of our variables including mFoo,
 aFoo, and camelCase to the google-standard local variable names.
 * Do not make any changes to the style guide or standard practice until
 we're comfortable that we can do automatic changes.
 * Make the automatic changes and change our style guide at roughly the
 same time.
 * Go back and deal with class names (nsFoo) as a separate/later pass.

 --BDS

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


FWIW, I think the Google C++ style is terrible, but if it gets us to a
point where we can run clang-format as part of make check and never worry
about style again I am all for it.

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

Re: New requirement for tier 1 platforms: working assertion stacks

[Kyle Huey]

On Fri, Jul 10, 2015 at 10:06 AM, Andrew McCreight amccrei...@mozilla.com
wrote:

 Are we going to have tests for this? Does working include being properly
 symbolicated?


Working does include properly symbolicated.  Tests would be ideal, if
tricky ...

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

New requirement for tier 1 platforms: working assertion stacks

[Kyle Huey]

Any reason not to require this?

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

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

[Kyle Huey]

On Tue, Jul 7, 2015 at 9:59 AM, Seth Fowler mfow...@mozilla.com wrote:

 I brought this up on IRC, but I think this is worth taking to the list:

 Replacing TemporaryRef with already_AddRefed has already caused at least
 one leak because already_AddRefed does not call Release() on the pointer it
 holds if nothing takes ownership of that pointer before its destructor
 runs. TemporaryRef did do that, and this seems like a strictly safer
 approach.

 My question is: why doesn’t already_AddRefed call Release() in its
 destructor? The fact that it doesn’t seems to me to be a profoundly
 unintuitive footgun.


We have a version of already_AddRefed that automatically releases the value
it holds when it's destroyed; it's called nsCOMPtr.

I don’t think we can trust reviewers to catch this, either. The fact that
 Foo() is declared as:

 already_AddRefedBar Foo();

 won’t necessarily be obvious from a call site, where the reviewer will
 just see:

 Foo();


Foo should be MOZ_WARN_UNUSED_RESULT (or whatever that annotation is) then,
as should anything that returns an already_AddRefed.

That call will leak, and if we don’t happen to hit that code path in our
 tests, we may not find out about it until after shipping it.


Ensuring that code that is untested works is in general a hard thing to
do.  I'd prefer that people wrote tests. (yes, there may be edge cases in
which this isn't possible)

I’d prefer that already_AddRefed just call Release(), but if there are
 performance arguments against that, then we should be checking for this
 pattern with static analysis. I don’t think the situation as it stands
 should be allowed to remain for long.


There is currently a dynamic analysis (in the form of a fatal assertion) in
the already_AddRefed dtor that I added last year.

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

Re: Shutdown hangs are very common

[Kyle Huey]

On Mon, Jul 6, 2015 at 1:37 PM, Ryan VanderMeulen rya...@gmail.com wrote:

 On 7/6/2015 4:34 PM, Vladan D wrote:

 Background: Firefox shutdown hangs are turned into shutdown crashes by a
 watchdog thread [1] that forces a crash if shutdown hasn't completed within
 1 minute. Thanks to the watchdog and the Windows profile unlocker [2],
 shutdown hangs aren't as frustrating as they used to be. However, shutdown
 hangs might still be causing data loss and they are indicative of
 potentially-serious bugs in the code.


 According to this graph of Firefox crash rate history, shutdown hangs
 (crashes) make up about one third of all browser crashes [3]:


 https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/longtermgraph/?fxrel

 I've been told shutdown hangs often don't get enough attention.
 Should fixing shutdown hangs be higher priority?
 And if so, should we allow features with shutdown hangs to be released?


 Notes:
 1. Force Firefox crash if shutdown hangs
 https://bugzilla.mozilla.org/show_bug.cgi?id=1038342
 2. win32 implementation of nsIProfileUnlocker
 https://bugzilla.mozilla.org/show_bug.cgi?id=286355
 3. The graph above shows that the overall crash rate jumped up by roughly
 a third when the watchdog code shipped in Firefox 36. Hover over the 36
 box on the blue line


 Windows mochitest-bc shutdown hangs have been on of the top oranges in our
 automation for months now. See bug 1121145. Would be great if we could get
 more eyes on the problem.

 -Ryan

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


The last five logs in that bug are all hanging in QuotaClient code.  I'll
take a look.

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

Re: Shutdown hangs are very common

[Kyle Huey]

On Mon, Jul 6, 2015 at 3:05 PM, Karl Tomlinson mozn...@karlt.net wrote:

 Vladan D. writes:

  Should fixing shutdown hangs be higher priority?

 _exit() after profile-before-change notification would be the
 many-holes-with-one-plug bug to prioritize.

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


I think most of our hangs are before that.  The one RyanVM pointed out
certainly is.

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

Re: Announcing the Content Performance program

[Kyle Huey]

On Sun, Jun 28, 2015 at 5:14 PM, Nathan Froyd nfr...@mozilla.com wrote:

 On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey m...@glandium.org wrote:
 
  BTW, wasn't there an effort a few couple years ago, to move content
  event loop in different threads for different tabs? What happened to
  that?
 

 If you are referring to bug 715376 (and related), those patches are still
 in my queue, fully rebased.  We only need to decide that it's worth
 spending a significant amount of time addressing the test failures induced
 by those patches (see comment 109 in that bug, for instance) and the
 possible webcompat issues from those patches.

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


I believe he's referring to supersnappy.

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

Re: State synchronization - use cases?

[Kyle Huey]

On Fri, Jun 26, 2015 at 10:38 AM, Richard Barnes rbar...@mozilla.com
wrote:

 Hey dev.platform folks,

 Some of us in the security engineering group have been chatting with cloud
 services about making an improved way to maintain state in the browser.
 Our use cases are things like:

 - Revoked certificates (OneCRL)
 - HSTS / HPKP preloads

 We're trying to get an idea of how big a data set we might want to
 maintain, so I wanted to see if anyone else had use cases that might
 benefit from such a mechanism.  The critical properties for your data set
 to be suitable are:

 1. You want every browser to have the same set of data
 2. The data change relatively slowly (we are aiming for ~24hr deliveries)

 If anyone has use cases in addition to the above, please let me know.

 Thanks a lot,
 --Richar
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform


UA overrides?

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

Re: mozglue.dll!jemalloc_crash

[Kyle Huey]

You need to look further up the stack.  jemalloc_crash is not an
interesting stack frame.

- Kyle

On Fri, Jun 5, 2015 at 8:05 AM, Meenakshi Shankar hifromme...@gmail.com
wrote:

 Hi,

 We are using Firefox SDKS for our FF extension (libs generated after
 compiling Firefox 39 beta 2 source using start-shell-msvc2013). With our
 extension enabled in Firefox, we receive a
 mozglue.dll!jemalloc_crash(...) With reference to bugzilla 1168291 we
 used mozcrt.lib for replacing mozalloc.lib, but still we see the crash
 in mozglue.dll.

 Also similar crash reported in bugzilla 1130180 and 1114791.
 Can anyone kindly let us know if this crash is fixed.
 ___
 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: Use of 'auto'

[Kyle Huey]

On Tue, Jun 2, 2015 at 1:23 PM, L. David Baron dba...@dbaron.org wrote:

 On Tuesday 2015-06-02 22:58 +0300, smaug wrote:
  So, I'd like to understand why people think 'auto' is a good thing to
 use.
  (bz mentioned it having some use inside bindings' codegenerator, and
 sure, I can see that being rather
  valid case.)

 One context where I think it often makes sense is for integral
 types, e.g., for things like:

   auto len = aArray.Length();
   auto display = GetStyleDisplay()-mDisplay;

 It can save having to look up whether aArray.Length() returns size_t
 (I sure hope it does, though) or whether mDisplay is uint8_t or
 uint16_t.


It also makes a lot of sense in situations where the type name is noise.
e.g.

auto foo = reinterpret_castReallyLongTypeName*(bar)
auto it = map.find(stuff)

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

Re: Is that possible to port nodejs with gecko javascript engine?

[Kyle Huey]

zpao also did spidernode a few years ago before he left.

- Kyle

On Sat, May 16, 2015 at 11:14 AM, Lars Hansen lhan...@mozilla.com wrote:
 I believe JXCore has a version (listed as beta) using our JS engine.

 --lars


 On Sat, May 16, 2015 at 8:06 PM, Yonggang Luo luoyongg...@gmail.com wrote:

 I've found Microsoft already done that.
 ___
 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnables and thread-unsafe members

[Kyle Huey]

On Tue, Apr 14, 2015 at 2:39 PM, Randell Jesup rjesup.n...@jesup.org wrote:
 (was: Re: Proposal to ban the usage of refcounted objects inside C++
 lambdas in Gecko)

 tl;dr: We should make DispatchToMainThread take already_AddRefed and
 move away from raw ptrs for Dispatches in general.

Agreed.

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

Re: PSA: moz_malloc, moz_realloc, moz_calloc and moz_free are no more

[Kyle Huey]

I assume that means that we have abandoned the plan to eventually make
malloc infallible?

- Kyle

On Mon, Mar 30, 2015 at 10:59 PM, Mike Hommey m...@glandium.org wrote:
 Hi,

 In the next few weeks, there is going to be a reduction in the number of
 our memory allocator wrappers/functions, for essentially the following
 reasons:
 - we have too many of them,
 - developers rarely know which one to use, which results in:
 - developers often make mistakes[1]

 This started today with the landing of bug 1138293, which effectively
 removed moz_malloc, moz_realloc, moz_calloc and moz_free.

 They were replaced, respectively, with malloc, realloc, calloc and free,
 because that works™.

 If you have pending patches that use moz_malloc, moz_realloc,
 moz_calloc, moz_free, you can just remove the moz_ prefix.

 The infallible moz_xmalloc, moz_xrealloc and moz_xcalloc still do exist,
 and memory allocated with them can be freed with free.

 With that being said, please refrain from using any of the functions
 mentioned above. Please prefer the C++y new and delete. new is
 infallible by default (equivalent to moz_xmalloc). If you need an
 equivalent to moz_malloc, use fallible new instead:

 new (fallible) Foo()

 Please note that this shouldn't make uplifting harder. Platform patches
 using malloc/free/new/delete should apply and work just fine on beta,
 aurora and esr (with a few exceptions ; if you uplift something from
 mfbt/mozglue that uses the memory allocator, please check with me).

 Cheers,

 Mike


 1. if you look for it, you'll find cases of one family used for
allocation and another for deallocation, for possibly close to all
combinations of families (NS_Alloc, nsMemory, moz_malloc, malloc,
new).
 ___
 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: libxul liscensing

[Kyle Huey]

On Thu, Mar 26, 2015 at 6:26 AM, Jesse Nicholson ascensionsyst...@gmail.com
 wrote:

 Hi All,

 I've been googling now for a far too long trying to find definitive
 documentation about the license governing the usage and distribution of
 libxul. All I can find is a very short wiki page that states that the
 licensing of xulrunner is being discussed internally to address some
 challenges, with a hint about gpl/lgpl code being mixed in somewhere. It's
 not very clear if this is about xulrunner the executable or the contents of
 the xulrunner SDK.

 Maybe my google-fu has gotten a little weak or perhaps I'm just missing
 something, so I signed up to ask you nice folks if you could help point me
 to some documentation that would make this clearer for me. I suppose while
 I'm at it, I'll pose my second question that I also can't find answers to,
 which is, is it possible to build libxul into a series of smaller shared
 libraries instead of a monolithic 30+ meg dll?

 Thanks for taking the time to even read my questions, and thanks in advance
 for any info you can provide me. :)

 Regards,

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


libxul binaries made by Mozilla are made available under the terms of the
MPL 2.  https://www.mozilla.org/MPL/

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

Re: PSA: Network 'jank' - get your blocking IO off of STS thread!

[Kyle Huey]

Can we stop exposing the socket transport service's nsIEventTarget outside
of Necko?

- Kyle

On Thu, Mar 26, 2015 at 8:14 AM, Patrick McManus mcma...@ducksong.com
wrote:

 good catch.. looking at
 https://mxr.mozilla.org/mozilla-central/ident?i=NS_SOCKETTRANSPORTSERVICE_CONTRACTID
 the only uses I see other than the one Ehsan unearthed are expected.. so
 maybe that's the sum of the short term work.

 On Thu, Mar 26, 2015 at 10:06 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
 wrote:

 On 2015-03-26 11:00 AM, Kyle Huey wrote:

 On Thu, Mar 26, 2015 at 7:49 AM, Patrick McManus mcma...@ducksong.com
 wrote:

  Is this thread mostly just confusion from these things sounding so much
 alike? Or am I confused now?


 Most likely.

 Does anyone have actual data to show that this is a problem?


 There's some truth to it.  Looks like some code uses the *socket*
 transport service when it probably means *stream* transport service.
 Example: http://mxr.mozilla.org/mozilla-central/source/dom/
 workers/ServiceWorkerEvents.cpp#249

 But other examples such as DOM Cache are not affected as far as I can
 tell.



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

Re: Review problems

[Kyle Huey]

On Wed, Mar 18, 2015 at 8:39 AM, Gabor Krizsanits gkrizsan...@mozilla.com
wrote:

 I think I'm not the only one experienced issues with reviews from one side
 or the other.
 I'm wondering if we could do some improvements here for everyone's sake.

 Here are the issues the way I see it:
 * some parts of the code need more peers
   - we should identify the areas
   - we should select candidates
   - there should be a clear path to become a peer
 (reading up code/spec, asking for sr's first and starting with easier
 ones, etc)


Identify some areas. :)


 * reviews are not part of our goal system
   - it makes no sense to work on something if for the
   reviewer will likely take several weeks or even months
   to get to the review (for various but foreseeable reasons)
   - people who are flooded with reviews cannot focus on their
   actual goals they signed up for, or have to block people by
   not doing reviews


Not sure this is the best forum for this, since this is really a
MoCo-internal thing, but people should be setting goals that still allow
time to do reviews, critical bug fixes, etc.  This quarter is probably a
little rough because the process is different, but I would expect that to
stabilize over time.

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