Build System Project - Latest Update

[David Burns]

Below is a highlight of all work the build peers have done since the last
report[1].

We have reduced the time it takes to run reftests as well as the amount of
I/O that happens during the tests by disabling some features in Firefox
that are not used during the test. This has saved over 50GB of I/O in
automation. Reporting has been put in place to help monitor in automation
to help us spot issues like this in the future! We have hopefully spotted a
few and will hopefully comment in the next update.

The build peers have also been working hard on getting a distributed cache
ready for everyone to use. This means we will try get get from the globally
distributed cache before building, hopefully saving time by only building
things that have changed and the cache for everything else.

We are continuing our work to remove configure/m4 code and have removed
around 2000 lines[2] as well as working our way through the long tail of
MakeFiles. We are down to just over 100 files and few thousand lines of
code.[3]. Once we have completed enough of this work we can start looking
to move over to a more performant build backend.

Last, but not least, I want to introduce our intern for the Summer, Nathan
Hakkakzadeh [Nat on IRC]. He will be helping with various Windows build
tasks while working with us. Make sure to say Hi to him!

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/aQVrp8GElno/QbGac4drAQAJ

[2] https://plot.ly/~glandium/14/lines-vs-time/

[3] http://people.mozilla.org/~tmielczarek/makefiles/makefiles_count.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Firefox-ui-tests – Platform Operations Project of the Month

[Henrik Skupin]

Hello from Platforms Operations! Once a month we highlight one of our
projects to help the Mozilla community discover a useful tool or an
interesting contribution opportunity.

This month’s project is firefox-ui-tests!

What are firefox-ui-tests?
===

Firefox UI tests are a test suite for integration tests which are based
on the Marionette automation framework and are majorly used for user
interface centric testing of Firefox. The difference to pure Marionette
tests is, that Firefox UI tests are interacting with the chrome scope
(browser interface) and not content scope (websites) by default. Also
the tests have access to a page object model called Firefox Puppeteer.
It eases the interaction with all ui elements under test, and especially
makes interacting with the browser possible even across different
localizations of Firefox. That is a totally unique feature compared to
all the other existing automated test suites.

You can read more about it on my blog post:
http://www.hskupin.info/2016/06/02/firefox-ui-tests-platform-operations-project-of-the-month/

Update
==
Just to announce it separately, as of yesterday we bumped our test
results on Treeherder to Tier-2, which will give us more visibility to
developers on integration branches. Tests per checkin are run on
Taskcluster which means it's Linux64 only for the moment. We will expand
testing once new platforms are available.

Cheers,

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

ARIA membership and role="password"

[Jonathan Kingston]

 
Hey,

So I was just informed that Mozilla isn't a member of the ARIA working
group which shocked me, we have however had a hand in the spec over the
years (I have cc'd those mentioned).

I notice over the years some disappointment with the spec as it being a
separate module to semantics in HTML itself however I don't see a real
opposition not to be in the group. This seems more of a formality when the
group split into two working groups.

It appears that ARIA 1.1 is moving to be resolved in the next few weeks so
if we had any objections we would need to move now I have been told.

*role="password"* has been added to the spec:
https://rawgit.com/w3c/aria/master/aria/aria.html#password and I jotted my
objections in a post:
https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/

My post was largely dismissed in this mail:
https://lists.w3.org/Archives/Public/public-aria/2016May/0126.html

Is it worth us joining? Can we discuss the wider use of ARIA itself?
Rushing to standardise features seems a shame.

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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Gabriele Svelto]

On 01/06/2016 15:20, Jonathan Kew wrote:

Does this suggest that we're not sufficiently proactive about firing
memory-pressure notifications, so that we'll free up memory from various
caches, etc? It looks like we regard 128MB of available VM as "low" (see
[1]) on Windows 32-bit, but apparently we're liable to suffer small-OOM
crashes well before we reach that point. That doesn't seem like a
healthy balance.


Those values were set when the AvailableMemoryTracker was introduced 5 
years ago [1]. I'd say we should probably revisit them especially in the 
light of these findings.


That being said in Firefox OS we employed memory-pressure notifications 
quite successfully to keep processes alive when memory was running low 
but we didn't rely on a single threshold because it didn't prove very 
effective. Instead we used a floating trigger which started at a certain 
level of free memory which once passed would trigger memory-pressure 
events. Once that happened we'd lower the threshold. If we hit this new 
threshold we'd fire memory-pressure events again, if not we'd try to 
raise the threshold again to the higher level. Exponential back-off was 
used to avoid having the threshold fluctuate too much between the two 
values.


Something similar could be implemented on Windows. If there's consensus 
I'm happy to look into it.


 Gabriele

[1] On Windows, fire a memory-pressure event when the amount of 
available virtual address space or physical memory is low

https://bugzilla.mozilla.org/show_bug.cgi?id=670967

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

Re: ARIA membership and role="password"

[Alexander Surkov]

Hi, Jonathan.

As far as I can tell, no one in Mozilla is super active in ARIA
nowadays; I personally (among others I think) skim through ARIA email
threads and provide occasional feedback on feature by feature basis.

One of reasons keeping me off I think is I'm worried about direction
taken in ARIA 1.1, which looks with me as to turn ARIA into universal
markup language for web page semantics description, so that ARIA
vocabulary can be used to describe whole HTML and more. I feel like
every single feature from HTML gets added to ARIA eventually, and I
not always convinced that each requested feature has a real use case
on the web. I expressed these worries, but my voice probably wasn't
strong enough to turn the wheel back.

So I'm not confident about role='password' too. While I don't have
strong objections, but I never heard the web authors complaining about
the missing feature. I would say if we do have strong concerns, and
cannot negotiate with the group to keep the feature off the spec, then
it shouldn't mean we have to implement the feature in Gecko. After all
if the feature doesn't get two implementation, then it gets removed
from the spec afaik.

Thanks.
Alexander.

On Thu, Jun 2, 2016 at 8:55 AM, Jonathan Kingston  wrote:
> Hey,
>
> So I was just informed that Mozilla isn't a member of the ARIA working group
> which shocked me, we have however had a hand in the spec over the years (I
> have cc'd those mentioned).
>
> I notice over the years some disappointment with the spec as it being a
> separate module to semantics in HTML itself however I don't see a real
> opposition not to be in the group. This seems more of a formality when the
> group split into two working groups.
>
> It appears that ARIA 1.1 is moving to be resolved in the next few weeks so
> if we had any objections we would need to move now I have been told.
>
> role="password" has been added to the spec:
> https://rawgit.com/w3c/aria/master/aria/aria.html#password and I jotted my
> objections in a post:
> https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/
>
> My post was largely dismissed in this mail:
> https://lists.w3.org/Archives/Public/public-aria/2016May/0126.html
>
> Is it worth us joining? Can we discuss the wider use of ARIA itself? Rushing
> to standardise features seems a shame.
>
> Thanks
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Canvas CSS/SVG filters

[Tobias Schneider]

Just tested on Windows 10 and got 9fps in Firefox(Direct2D) and 5fps in
Chrome Canary. Both test were running with a canvas size of 2560 x 720.
Tats half of my monitor resolution. With a maximized window, Chrome
crashes, Firefox keeps it at 9fps.

On Wed, Jun 1, 2016 at 2:07 PM, Jeff Muizelaar 
wrote:

> Can you also get results on Windows?
>
> -Jeff
>
> On Wed, Jun 1, 2016 at 3:05 PM, Tobias Schneider 
> wrote:
>
>> I got the following numbers running
>> https://dl.dropboxusercontent.com/u/55355076/benchmark.html?filters=true
>> on my MacBook Pro (Mid 2014):
>>
>> Firefox Developer Edition: Skia-GL: 10fps
>>   Skia: 3fps
>>   CG: 10fps
>>   Cairo:8fps
>>
>> Chrome Canary 53: 3fps
>>
>>
>> On Tue, May 31, 2016 at 11:53 AM, Jeff Muizelaar 
>> wrote:
>>
>>> How does performance compare to Chrome?
>>>
>>> -Jeff
>>>
>>> On Thu, May 26, 2016 at 12:40 PM, Tobias Schneider <
>>> tschnei...@mozilla.com> wrote:
>>>
 I intend to turn Canvas CSS/SVG filters on by default on all platforms.
 It
 has been developed behind the canvas.filters.enabled preference.
 Google's
 Chrome is already shipping this in version 52.

 Related bugs:

 https://bugzilla.mozilla.org/show_bug.cgi?id=927892
 https://bugzilla.mozilla.org/show_bug.cgi?id=1173545

 Specification:


 https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-filter
 ___
 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: ARIA membership and role="password"

[David Bolter]

Hi Johnathan,

Our lack of direct W3C ARIA involvement recently is mainly due to
time/resource constraints and we have influence via proxy.

I think ARIA is best scoped as passive semantics used to describe the
reality of how web developers (ab)use HTML. It is not unreasonable to argue
that ARIA, by existing, implicitly condones this (ab)use. That said, we
made the decision a long time ago to advocate using proper semantic HTML
(and evolve HTML where it falls short), while accepting the need for a
solution/hack for the reality of what web developers are doing.

The password case is interesting though I've not followed it closely. I'm
happy to connect you with people (including Rich) if needed (feel free ping
me offline)...

Cheers,
D

On Thu, Jun 2, 2016 at 8:55 AM, Jonathan Kingston 
wrote:

> 
> Hey,
>
> So I was just informed that Mozilla isn't a member of the ARIA working
> group which shocked me, we have however had a hand in the spec over the
> years (I have cc'd those mentioned).
>
> I notice over the years some disappointment with the spec as it being a
> separate module to semantics in HTML itself however I don't see a real
> opposition not to be in the group. This seems more of a formality when the
> group split into two working groups.
>
> It appears that ARIA 1.1 is moving to be resolved in the next few weeks so
> if we had any objections we would need to move now I have been told.
>
> *role="password"* has been added to the spec:
> https://rawgit.com/w3c/aria/master/aria/aria.html#password and I jotted
> my objections in a post:
> https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/
>
> My post was largely dismissed in this mail:
> https://lists.w3.org/Archives/Public/public-aria/2016May/0126.html
>
> Is it worth us joining? Can we discuss the wider use of ARIA itself?
> Rushing to standardise features seems a shame.
>
> Thanks
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

If you want a treasure trove :), when it comes to graphics crashes, the 
“graphics critical error” field is it.  It’s a recent history of barely 
avoidable crashes and error states just before the crash actually happens.  
Very often the real cause of the crash happens prior to the line of code 
captured in the stack trace.

(It doesn’t necessarily make sense to search for the "graphics critical error” 
existence, as too many bugs will show up, but for us it’s usually the first 
step after we identify a crash to look at.)

- Milan



> On Jun 1, 2016, at 21:40 , Nicholas Nethercote  wrote:
> 
> I apologize for the sarcasm. I was frustrated with this comment:
> 
>> I looked at the query from the first post, but it's just noise to me. If it 
>> included the file that it
>> crashed from, it would suddenly be very useful, since it'd then be trivial 
>> to see if there's
>> something relevant to me.
> 
> but it wasn't a good way to respond. So I'll try again.
> 
> Most of the results in the search identify a unique string, which *is*
> trivial to look up. And while it's true that file and/or function
> names would help refine the small number of cases where distinct
> MOZ_CRASH calls, you can also do that with a simple follow-up search
> refinement, as I showed in my previous response. The required data is
> present. I would describe the presentation as "slightly suboptimal but
> still highly usable".
> 
> I've looked at a lot of crash reports recently and one thing I've
> learned is how inadequate they often are. Many are unactionable. Many
> aren't even comprehensible. In comparison, this list is a treasure
> trove, containing reports that are much more comprehensible and
> actionable than average. It's one which I intend to revisit, and I
> hope others will too.
> 
> Nick
> 
> 
> On Thu, Jun 2, 2016 at 5:22 AM, Jeff Gilbert  wrote:
>> It would be useful to have a dashboard that collates this information better.
>> 
>> PS: Sarcasm is unhelpful.
>> 
>> On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote
>>  wrote:
>>> On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert  wrote:
 
 Perhaps this isn't meant for me then? I looked at the query from the
 first post, but it's just noise to me. If it included the file that it
 crashed from, it would suddenly be very useful, since it'd then be
 trivial to see if there's something relevant to me.
>>> 
>>> Let's look at the top #3:
>>> 
>>> 
>>> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
>>> 129715  9.92 %
>>> 
>>> If you use your favourite source code search tool to look for
>>> "Shutdown too long", you'll find that this crash is occurring in
>>> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
>>> DXR link:
>>> 
>>> https://dxr.mozilla.org/mozilla-central/search?q=%22Shutdown+too+long%22&redirect=false
>>> 
>>> The line in question looks like this:
>>> 
>>> MOZ_CRASH("Shutdown too long, probably frozen, causing a crash.");
>>> 
>>> 
>>> 2  MOZ_CRASH() 25987   1.99 %
>>> 
>>> This one matches all calls to MOZ_CRASH() that don't provide a string
>>> parameter. Digging into these ones is slightly harder, requiring a new
>>> search for bugs that have "moz crash reason" set to "MOZ_CRASH()":
>>> 
>>> https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%3DMOZ_CRASH%28%29&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-signature
>>> 
>>> 
>>> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor) 21040.16 %
>>> 
>>> Searching for "working D3D9 Compositor" identifies this one as coming
>>> from gfx/layers/d3d9/CompositorD3D9.cpp.
>>> 
>>> 
>>> And so on. Searching for strings in code is a useful technique in many
>>> situations, I recommend it!
>>> 
>>> 
>>> BTW, thank you to all those who have already looked through the list
>>> and mentioned existing bugs and/or filed new bugs.
>>> 
>>> 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Milan Sreckovic]

For example, searching for “graphics critical error” containing 0x8007000e 
(Windows error code for “out of memory”) leads you to a lot of crashes/bugs 
that are not tagged as OOM (which is OK), but clearly have some aspect of 
“running out of stuff” in them.

In general, it can come in handy when the info is otherwise light (e.g., “ERROR 
NO MINIDUMP HEADER” ones :)
—
- Milan



> On Jun 2, 2016, at 13:17 , Milan Sreckovic  wrote:
> 
> If you want a treasure trove :), when it comes to graphics crashes, the 
> “graphics critical error” field is it.  It’s a recent history of barely 
> avoidable crashes and error states just before the crash actually happens.  
> Very often the real cause of the crash happens prior to the line of code 
> captured in the stack trace.
> 
> (It doesn’t necessarily make sense to search for the "graphics critical 
> error” existence, as too many bugs will show up, but for us it’s usually the 
> first step after we identify a crash to look at.)
> 
> - Milan
> 
> 
> 
>> On Jun 1, 2016, at 21:40 , Nicholas Nethercote  
>> wrote:
>> 
>> I apologize for the sarcasm. I was frustrated with this comment:
>> 
>>> I looked at the query from the first post, but it's just noise to me. If it 
>>> included the file that it
>>> crashed from, it would suddenly be very useful, since it'd then be trivial 
>>> to see if there's
>>> something relevant to me.
>> 
>> but it wasn't a good way to respond. So I'll try again.
>> 
>> Most of the results in the search identify a unique string, which *is*
>> trivial to look up. And while it's true that file and/or function
>> names would help refine the small number of cases where distinct
>> MOZ_CRASH calls, you can also do that with a simple follow-up search
>> refinement, as I showed in my previous response. The required data is
>> present. I would describe the presentation as "slightly suboptimal but
>> still highly usable".
>> 
>> I've looked at a lot of crash reports recently and one thing I've
>> learned is how inadequate they often are. Many are unactionable. Many
>> aren't even comprehensible. In comparison, this list is a treasure
>> trove, containing reports that are much more comprehensible and
>> actionable than average. It's one which I intend to revisit, and I
>> hope others will too.
>> 
>> Nick
>> 
>> 
>> On Thu, Jun 2, 2016 at 5:22 AM, Jeff Gilbert  wrote:
>>> It would be useful to have a dashboard that collates this information 
>>> better.
>>> 
>>> PS: Sarcasm is unhelpful.
>>> 
>>> On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote
>>>  wrote:
 On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert  wrote:
> 
> Perhaps this isn't meant for me then? I looked at the query from the
> first post, but it's just noise to me. If it included the file that it
> crashed from, it would suddenly be very useful, since it'd then be
> trivial to see if there's something relevant to me.
 
 Let's look at the top #3:
 
 
 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
 129715  9.92 %
 
 If you use your favourite source code search tool to look for
 "Shutdown too long", you'll find that this crash is occurring in
 toolkit/components/terminator/nsTerminator.cpp. For example, here's a
 DXR link:
 
 https://dxr.mozilla.org/mozilla-central/search?q=%22Shutdown+too+long%22&redirect=false
 
 The line in question looks like this:
 
 MOZ_CRASH("Shutdown too long, probably frozen, causing a crash.");
 
 
 2  MOZ_CRASH() 25987   1.99 %
 
 This one matches all calls to MOZ_CRASH() that don't provide a string
 parameter. Digging into these ones is slightly harder, requiring a new
 search for bugs that have "moz crash reason" set to "MOZ_CRASH()":
 
 https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%3DMOZ_CRASH%28%29&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-signature
 
 
 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor) 21040.16 %
 
 Searching for "working D3D9 Compositor" identifies this one as coming
 from gfx/layers/d3d9/CompositorD3D9.cpp.
 
 
 And so on. Searching for strings in code is a useful technique in many
 situations, I recommend it!
 
 
 BTW, thank you to all those who have already looked through the list
 and mentioned existing bugs and/or filed new bugs.
 
 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: Intent to implement: HTMLMediaElement::seekToNextFrame()

[Ehsan Akhgari]

On 2016-06-01 5:27 PM, Jet Villegas wrote:
> On Thu, May 26, 2016 at 7:49 PM, Tzu-Hao Kuo  > wrote:
>  
> 
> *Link to standard*: No standard. This API was first discussed at
> Mozlando
> and has been discussed online here(
> https://github.com/w3c/mediacapture-worker/issues/33). The
> discussion has
> been led to a stream-based design which will probably take a long
> time so
> we would like to implement the proposed
> HTMLMediaElement::seekToNextFrame()
> first for testing.
> 
> 
>  What's the plan for resolving Streams/MediaStream integration raised on
> the github issue? I read "probably take a long time" to mean we're
> working on it, but is that actually the case? This is a feature we
> definitely want interop on.

FWIW I r+ed the patch on the bug based on the assumption that we will
not be shipping the API in its current form...

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

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

[Chris Pearce]

On Thursday, June 2, 2016 at 9:34:25 AM UTC+12, Jet Villegas wrote:
> On Thu, May 26, 2016 at 7:49 PM, Tzu-Hao Kuo  wrote:
> 
> 
> > *Link to standard*: No standard. This API was first discussed at Mozlando
> > and has been discussed online here(
> > https://github.com/w3c/mediacapture-worker/issues/33). The discussion has
> > been led to a stream-based design which will probably take a long time so
> > we would like to implement the proposed HTMLMediaElement::seekToNextFrame()
> > first for testing.
> >
> 
>  What's the plan for resolving Streams/MediaStream integration raised on
> the github issue? I read "probably take a long time" to mean we're working
> on it, but is that actually the case? This is a feature we definitely want
> interop on.
> 
> --Jet



The plan is to use feedback garnered from people experimenting with the 
experimental API in pre-release builds to help guide the design of the larger 
streams-based API.

We're not going to ship the API enabled in the current form in Release Firefox.

There are guys in Taipei interested in working on a streams-based API I 
believe. So they'll likely be leading the effort. We'll discuss this at 
Mozlondon.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

[Eric Shepherd]

Do: do you want this method documented or not? I presume not, since
exposure will be limited.


*From:* Chris Pearce
*Sent:* Thursday, Jun 2, 2016 4:40:59 PM EDT
*To:* dev-platform@lists.mozilla.org
*Subject:* Intent to implement: HTMLMediaElement::seekToNextFrame()

> We're not going to ship the API enabled in the current form in Release 
> Firefox.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network 
Blog: https://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Doodle: http://doodle.com/the.sheppy

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

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

[Chris Pearce]

On Friday, June 3, 2016 at 9:51:58 AM UTC+12, Eric Shepherd wrote:
> Do: do you want this method documented or not? I presume not, since
> exposure will be limited.
> 
> 
> *From:* Chris Pearce
> *Sent:* Thursday, Jun 2, 2016 4:40:59 PM EDT
> *To:* dev-platform@lists.mozilla.org
> *Subject:* Intent to implement: HTMLMediaElement::seekToNextFrame()
> 
> > We're not going to ship the API enabled in the current form in Release 
> > Firefox.
> 
> -- 
> 
> Eric Shepherd
> Senior Technical Writer
> Mozilla Developer Network 
> Blog: https://www.bitstampede.com/
> Twitter: http://twitter.com/sheppy
> Doodle: http://doodle.com/the.sheppy


I think minimal documentation, saying that this feature is experimental and 
that the user must enable the pref before it'll work is useful.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

IXL

[Nicholas Nethercote]

Hey baby,

Both kids are doing IXL right now! So I renamed Keira's account --
which Zack had been using -- as Zack, and then paid $29 to get an
extra account and added Keira.

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

Re: IXL

[nnethercote]

Please ignore this email, which I sent to this list by accident due to a Gmail 
address auto-completion mistake.

(I sent a "please ignore" reply an hour ago, but that doesn't seem to have gone 
through, so I'm trying again. Apologies if you see two such responses.)

If anyone has the power to remove this thread from the archives, please do so! 
Thank you.

Nick


On Friday, June 3, 2016 at 8:26:20 AM UTC+10, Nicholas Nethercote wrote:
> Hey baby,
> 
> Both kids are doing IXL right now! So I renamed Keira's account --
> which Zack had been using -- as Zack, and then paid $29 to get an
> extra account and added Keira.
> 
> N

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

Re: IXL

[Nicholas Nethercote]

Sorry, this email was not meant to go to this list. (Gmail changed the
auto-completion order I was accustomed to on the "address" field.)
Please ignore.

If anyone has the ability to remove this email from the list archives,
please do so!

Thanks.

Nick

On Fri, Jun 3, 2016 at 8:25 AM, Nicholas Nethercote
 wrote:
> Hey baby,
>
> Both kids are doing IXL right now! So I renamed Keira's account --
> which Zack had been using -- as Zack, and then paid $29 to get an
> extra account and added Keira.
>
> N
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Generating Visual Studio project files by default

[Jean-Yves Avenard]

On Wednesday, May 25, 2016 at 9:00:48 AM UTC+10, Gregory Szorc wrote:
> This change was tracked in bug 1275297. Bug 1275419 tracks a follow-up to
> allow disabling their generation.

so when is xcode support coming too ? :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

32-bit developer edition?

[Ben Kelly]

Hi all,

I noticed recently that all of the available download links for dev edition
point to the 32-bit installer.  Is there a reason for this?

Given we are talking about how to upgrade existing users to 64-bit it would
seem good to update the download links for new installs.

Thanks.

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

Re: 32-bit developer edition?

[Jet Villegas]

We should offer both.

--Jet

On Thursday, June 2, 2016, Ben Kelly  wrote:

> Hi all,
>
> I noticed recently that all of the available download links for dev edition
> point to the 32-bit installer.  Is there a reason for this?
>
> Given we are talking about how to upgrade existing users to 64-bit it would
> seem good to update the download links for new installs.
>
> Thanks.
>
> Ben
> ___
> 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