Re: Alternative to Bonsai?

[Philip Chee]

On 15/09/2015 23:53, Boris Zbarsky wrote:
> On 9/15/15 11:11 AM, Ben Hearsum wrote:
>> I'm pretty sure https://github.com/mozilla/gecko-dev has full history.

Thanks to everyone for your suggestions.

> Though note that it doesn't have working blame for a lot of files in our 
> source tree (and especially the ones you'd _want_ to get blame for, in 
> my experience), so it's of pretty limited use if you're trying to do the 
> sorts of things you used to be able to do with bonsai.
> 
> I believe gps is working on standing up a web front end for the CVS repo 
> blame to replace bonsai...

But we don't have a working CVS repository any more right?

Phil (is confused)

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Default window size on a screen of 1920x1080 or 1280x1024?

[Axel Hecht]

Hi,

we're trying to find out what the default window size would be for 
people on screens of 1920x1080 or 1280x1024.


Sadly, I can't find the code that actually computes that for the heck of 
it, can anybody help?


Background: We want to ensure that the new about:privatebrowsing has the 
panels stacked side-by-side, but that depends on the window size. So 
we're trying to find out common window sizes for people. Some 
conversation in https://bugzilla.mozilla.org/show_bug.cgi?id=1198287


Thanks

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

Re: |hg bzexport| and Bugzilla two-factor authentication

[Gijs Kruitbosch]

On Windows I still get "No module named Cookie!" after using ./mach 
mercurial-setup to update vcs-tools.


~ Gijs

On 15/09/2015 22:52, Jeff Walden wrote:

The Mercurial extensions to interact with Bugzilla -- bzexport and the like -- 
have been updated to handle 2fa details.  No need to add API key support 
yourself, or use some sketchy dude's user-repo fix for the issue!  ;-)  (As at 
least three people have considered, two people have actually done, tho only one 
ended up landed upstream.)

Just run |./mach mercurial-setup| to pick up the new version with API key 
support.  Then add:

[bugzilla]
username = your-bugzilla-email-addr...@example.com
apikey = 0123456789ABCDEF0123456789ABCDEF01234567

to your ~/.hgrc, where the hex number is a Bugzilla API key generated on the 
relevant Bugzilla prefs page, and pushes should work again.

("Mercurial had it first...")

Jeff



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

Re: |hg bzexport| and Bugzilla two-factor authentication

[Gregory Szorc]

I am pretty sure this is due to running hg from a py2exe based Mercurial 
distribution on Windows. This is pretty much any hg on Windows that isn't 
MozillaBuild 2.0. This includes TortoiseHg.

Things have or will break unless running MozillaBuild 2.0.

Please file a Developer Services product bug with the command output with 
--traceback added to the args so we can track failing more gracefully.

> On Sep 16, 2015, at 05:02, Gijs Kruitbosch  wrote:
> 
> On Windows I still get "No module named Cookie!" after using ./mach 
> mercurial-setup to update vcs-tools.
> 
> ~ Gijs
> 
>> On 15/09/2015 22:52, Jeff Walden wrote:
>> The Mercurial extensions to interact with Bugzilla -- bzexport and the like 
>> -- have been updated to handle 2fa details.  No need to add API key support 
>> yourself, or use some sketchy dude's user-repo fix for the issue!  ;-)  (As 
>> at least three people have considered, two people have actually done, tho 
>> only one ended up landed upstream.)
>> 
>> Just run |./mach mercurial-setup| to pick up the new version with API key 
>> support.  Then add:
>> 
>> [bugzilla]
>> username = your-bugzilla-email-addr...@example.com
>> apikey = 0123456789ABCDEF0123456789ABCDEF01234567
>> 
>> to your ~/.hgrc, where the hex number is a Bugzilla API key generated on the 
>> relevant Bugzilla prefs page, and pushes should work again.
>> 
>> ("Mercurial had it first...")
>> 
>> Jeff
> 
> ___
> 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

Can not access window.navigator.mozApps in xulrunner 38.1 apps

[Yonggang Luo]

Does window.navigator.mozApps disabled for xulrunner or other reasons?

-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

service worker fetch interception riding to aurora 43

[Ben Kelly]

Hello all,

Currently service workers are enabled in 42 to support push notifications,
but network interception via the FetchEvent is disabled.  We've made a lot
of progress on the issues blocking this interception, however, and we feel
we are ready to move forward.

Therefore, we intend to let service worker fetch interception ride the
trains to aurora in 43 for desktop.  We think android could also ride the
trains, but need to verify how that team feels about it.  Service workers
will definitely not ship on b2g as there are a number of issues there
currently.

We also intend to continue improving service workers on aurora 43 where we
can make targeted uplifts.  We expect these changes to be mostly
improvements to test coverage and isolated fixes uncovered by those tests.

Before 43 merges to beta we will re-evaluate where we stand and decide if
service worker fetch interception should ride the trains to release.  If we
decide to proceed, we will send an intent-to-ship at that time.

Of course, if we encounter any major new problems that cannot be fixed in
an uplift, then we will not ship to release in 43.  We may also disable
service workers on aurora depending on the nature of the issue.

Here are the list of bugs we consider blocking release of the feature:


https://bugzilla.mozilla.org/showdependencytree.cgi?id=1059784_resolved=1

Note that we expect to land many of these prior to the merge on Monday.

Please let us know if there are questions or concerns.

Thank you.

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

Re: mach mozregression command

[Benoit Girard]

This probably doesn't need to be mentioned but I'd like to discuss it
anyways:

We often ask bug reporters and various non developers to run bisection for
us. Maintaining mozregression to work well without a code checkout (i.e.
standalone) is important. I nearly feel that it should be so easy to run
standalone, since we require non developers to do it, that ideally there
should be little to no benefit to having a mach wrapper. However it's not a
pragmatic position and I can see the value of putting it in mach. I just
hope that we continue to maintain mozregression as a standalone tool and
that this wrapper doesn't cause us to miss regressions in it.

On Mon, Sep 14, 2015 at 12:43 PM, Julien Pagès  wrote:

> Hey everyone,
>
> I'm pleased to announce that we just added a "mach mozregression" command
> that allow to run mozregression (a regression range finder for Mozilla
> nightly
> and inbound builds) directly from your checkout of mozilla-central. To
> learn more about
> how to use it, just run:
>
> ./mach mozregression --help
>
> See http://mozilla.github.io/mozregression/ if you don't know about the
> tool.
>
> I hope you'll find this useful!
>
> Julien
> ___
> 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: Alternative to Bonsai?

[Ehsan Akhgari]

On 2015-09-15 11:53 AM, Boris Zbarsky wrote:

On 9/15/15 11:11 AM, Ben Hearsum wrote:

I'm pretty sure https://github.com/mozilla/gecko-dev has full history.


Though note that it doesn't have working blame for a lot of files in our
source tree (and especially the ones you'd _want_ to get blame for, in
my experience), so it's of pretty limited use if you're trying to do the
sorts of things you used to be able to do with bonsai.


Out of curiosity, which files are you mentioning here?

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

Re: |hg bzexport| and Bugzilla two-factor authentication

[Gijs Kruitbosch]

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

FWIW, part of the reason I've been using tortoisehg is that it used to 
make bzexport work, when it didn't work on Windows with the hg that 
shipped with mozillabuild. It's a little ironic that it's now 
(apparently!) the other way around, especially that we broke what used 
to work.


~ Gijs

On 16/09/2015 16:44, Gregory Szorc wrote:

I am pretty sure this is due to running hg from a py2exe based Mercurial 
distribution on Windows. This is pretty much any hg on Windows that isn't 
MozillaBuild 2.0. This includes TortoiseHg.

Things have or will break unless running MozillaBuild 2.0.

Please file a Developer Services product bug with the command output with 
--traceback added to the args so we can track failing more gracefully.


On Sep 16, 2015, at 05:02, Gijs Kruitbosch  wrote:

On Windows I still get "No module named Cookie!" after using ./mach 
mercurial-setup to update vcs-tools.

~ Gijs


On 15/09/2015 22:52, Jeff Walden wrote:
The Mercurial extensions to interact with Bugzilla -- bzexport and the like -- 
have been updated to handle 2fa details.  No need to add API key support 
yourself, or use some sketchy dude's user-repo fix for the issue!  ;-)  (As at 
least three people have considered, two people have actually done, tho only one 
ended up landed upstream.)

Just run |./mach mercurial-setup| to pick up the new version with API key 
support.  Then add:

[bugzilla]
username = your-bugzilla-email-addr...@example.com
apikey = 0123456789ABCDEF0123456789ABCDEF01234567

to your ~/.hgrc, where the hex number is a Bugzilla API key generated on the 
relevant Bugzilla prefs page, and pushes should work again.

("Mercurial had it first...")

Jeff


___
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: Alternative to Bonsai?

[Gregory Szorc]

On Wed, Sep 16, 2015 at 10:22 AM, Boris Zbarsky  wrote:

> On 9/16/15 2:38 AM, Philip Chee wrote:
>
>> But we don't have a working CVS repository any more right?
>>
>
> I could be confused, but I believe the CVS repo exists.  It can certainly
> be used in a read-only mode.  I don't know whether it allows commits.


We no longer have a CVS server.

Snapshots of the repositories can be found at
https://ftp.mozilla.org/pub/mozilla.org/vcs-archive/. cvs-main contains
Firefox.

ViewVC works by reading from a CVS repository. But it doesn't run a CVS
server nor does it expose the raw CVS files to the internet.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Alternative to Bonsai?

[Boris Zbarsky]

On 9/16/15 2:01 PM, Ehsan Akhgari wrote:

Out of curiosity, which files are you mentioning here?


Here are some lovely links that all produce "This blame took too long to 
generate.  Sorry about that." for me:


https://github.com/mozilla/gecko-dev/blame/master/layout/base/nsCSSFrameConstructor.cpp

https://github.com/mozilla/gecko-dev/blame/master/dom/base/nsDocument.cpp

https://github.com/mozilla/gecko-dev/blame/master/dom/base/nsGlobalWindow.cpp

I have not done an exhaustive search for such files in our tree, but 
just those three represent a significant fraction of my blame lookups...


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

Re: Alternative to Bonsai?

[Jeff Muizelaar]

Blame does work on those files locally. FWIW, fugitive vim's Gblame
command has the ability to jump back to the blame of parent revision
of the current line which makes it much easier to navigate history
than any web based blame tool that I've seen. Even if you only use vim
for GBlame I'd say it's still worth using.

-Jeff

On Wed, Sep 16, 2015 at 2:13 PM, Boris Zbarsky  wrote:
> On 9/16/15 2:01 PM, Ehsan Akhgari wrote:
>>
>> Out of curiosity, which files are you mentioning here?
>
>
> Here are some lovely links that all produce "This blame took too long to
> generate.  Sorry about that." for me:
>
> https://github.com/mozilla/gecko-dev/blame/master/layout/base/nsCSSFrameConstructor.cpp
>
> https://github.com/mozilla/gecko-dev/blame/master/dom/base/nsDocument.cpp
>
> https://github.com/mozilla/gecko-dev/blame/master/dom/base/nsGlobalWindow.cpp
>
> I have not done an exhaustive search for such files in our tree, but just
> those three represent a significant fraction of my blame lookups...
>
>
> -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: Alternative to Bonsai?

[Boris Zbarsky]

On 9/16/15 3:02 PM, Jeff Muizelaar wrote:

Blame does work on those files locally.


Sure.  Locally everything is fine.

As soon as there is good integration between dxr/mxr and local stuff, 
and as soon as I can send someone a sane text representation of a local 
blame display, we can just drop web blame.  ;)


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

Re: |hg bzexport| and Bugzilla two-factor authentication

[Ryan VanderMeulen]

On 9/16/2015 2:32 PM, Gijs Kruitbosch wrote:

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

FWIW, part of the reason I've been using tortoisehg is that it used to
make bzexport work, when it didn't work on Windows with the hg that
shipped with mozillabuild. It's a little ironic that it's now
(apparently!) the other way around, especially that we broke what used
to work.

~ Gijs


Tortoisehg could always start shipping with the Cookie module if they 
felt so inclined. Which would work until the next feature we tried to 
add that depends on a previously-not-shipped python module. Things have 
worked in the past because they shipped with more python modules than 
the default mercurial distribution did, but ultimately they aren't 
shipping with the entirety of all available python modules.


We fixed that in Mozillabuild 2.0 by installing mercurial on top of the 
regular python install so *all* modules are available to it instead of 
depending on an upstream maintainer to bundle something we may want/need 
down the road.


So ultimately, what we're doing now is the most future-proof way to 
proceed. If python supports it, it'll be available to mercurial too :)


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

Web APIs documentation/evangelism/dev team meetup Thursday at 8 AM PDT

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://etherpad.mozilla.org/API-docs-meeting-2015-09-17.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mach mozregression command

[Julien Pagès]

This is great point. Mozgression will always be a standalone tool, easy to
use for non developers. We dropped the build bisection support out of
mozregression because it was broken, hard to maintain, and also because
where mozregression really shine is the easy to use bisection of pre-built
binaries. We are improving the tool to make it even easier, a good example
for that is the GUI that is currently developed. The mach interface is just
a nice to have (to me), and it was cheap to add it - so we did it. No
worries, the standalone mozregression will not be abandoned! And I'm glad
to hear that feedback Benoit. :)

Julien

2015-09-16 20:42 GMT+02:00 Benoit Girard :

> This probably doesn't need to be mentioned but I'd like to discuss it
> anyways:
>
> We often ask bug reporters and various non developers to run bisection for
> us. Maintaining mozregression to work well without a code checkout (i.e.
> standalone) is important. I nearly feel that it should be so easy to run
> standalone, since we require non developers to do it, that ideally there
> should be little to no benefit to having a mach wrapper. However it's not a
> pragmatic position and I can see the value of putting it in mach. I just
> hope that we continue to maintain mozregression as a standalone tool and
> that this wrapper doesn't cause us to miss regressions in it.
>
> On Mon, Sep 14, 2015 at 12:43 PM, Julien Pagès 
> wrote:
>
>> Hey everyone,
>>
>> I'm pleased to announce that we just added a "mach mozregression" command
>> that allow to run mozregression (a regression range finder for Mozilla
>> nightly
>> and inbound builds) directly from your checkout of mozilla-central. To
>> learn more about
>> how to use it, just run:
>>
>> ./mach mozregression --help
>>
>> See http://mozilla.github.io/mozregression/ if you don't know about the
>> tool.
>>
>> I hope you'll find this useful!
>>
>> Julien
>> ___
>> 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: mach mozregression command

[J. Ryan Stinnett]

On Wed, Sep 16, 2015 at 1:42 PM, Benoit Girard  wrote:
> I just
> hope that we continue to maintain mozregression as a standalone tool and
> that this wrapper doesn't cause us to miss regressions in it.

The mach wrapper essentially just calls "pip install mozregression"[1]
and passes args along, so the standalone tool should be safe.

[1]: 
https://dxr.mozilla.org/mozilla-central/rev/9ed17db42e3e46f1c712e4dffd62d54e915e0fac/tools/mach_commands.py#398

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

Re: Default window size on a screen of 1920x1080 or 1280x1024?

[Axel Hecht]

Thanks, exactly what I was looking for.

Axel

On 9/16/15 7:13 PM, Gavin Sharp wrote:

See 
https://hg.mozilla.org/mozilla-central/annotate/3e8dde8f8c17/browser/base/content/browser.js#l1017
if you're wondering about Firefox specifically.

Gavin

On Wed, Sep 16, 2015 at 7:26 AM, Axel Hecht  wrote:

Hi,

we're trying to find out what the default window size would be for people on
screens of 1920x1080 or 1280x1024.

Sadly, I can't find the code that actually computes that for the heck of it,
can anybody help?

Background: We want to ensure that the new about:privatebrowsing has the
panels stacked side-by-side, but that depends on the window size. So we're
trying to find out common window sizes for people. Some conversation in
https://bugzilla.mozilla.org/show_bug.cgi?id=1198287

Thanks

Axel
___
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: Default window size on a screen of 1920x1080 or 1280x1024?

[Gavin Sharp]

See 
https://hg.mozilla.org/mozilla-central/annotate/3e8dde8f8c17/browser/base/content/browser.js#l1017
if you're wondering about Firefox specifically.

Gavin

On Wed, Sep 16, 2015 at 7:26 AM, Axel Hecht  wrote:
> Hi,
>
> we're trying to find out what the default window size would be for people on
> screens of 1920x1080 or 1280x1024.
>
> Sadly, I can't find the code that actually computes that for the heck of it,
> can anybody help?
>
> Background: We want to ensure that the new about:privatebrowsing has the
> panels stacked side-by-side, but that depends on the window size. So we're
> trying to find out common window sizes for people. Some conversation in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1198287
>
> Thanks
>
> Axel
> ___
> 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: easily getting allocation stacks for leaking objects

[David Rajchenbach-Teller]

That sounds great!

Thanks a lot,
 David

On 15/09/15 22:32, Nathan Froyd wrote:
> Hi all,
> 
> For some intermittent leaks, it's not at all clear where the leaked objects
> are coming from, especially for objects that are widely used across the
> codebase.  Bug 1196430 added the ability for our leak checking mechanism to
> track allocation stacks of objects and to print said stacks for leaked
> objects at the end of a test run.
> 
> The wiki page for BloatView has been updated with a description of how to
> use this capability:
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/BloatView#Bloat_Statistics_on_Tinderbox
> 
> If you are facing a particular pernicious intermittent leak, please
> consider doing some try runs with --setenv=XPCOM_MEM_LOG_CLASSES=FOO added
> to aid in understanding where the leak starts.  Also, please feel free to
> file bugs on how leak checking could be improved to provide more
> information for investigating these kind of bugs.
> 
> Thanks,
> -Nathan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Alternative to Bonsai?

[Boris Zbarsky]

On 9/16/15 2:38 AM, Philip Chee wrote:

But we don't have a working CVS repository any more right?


I could be confused, but I believe the CVS repo exists.  It can 
certainly be used in a read-only mode.  I don't know whether it allows 
commits.


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