Unplanned Phabricator Update - June 4th 2019 between 14:00 and 15:00 UTC

[David Lawrence]

Due to missing the normal update window normally on Mondays, we will be 
deploying a Phabricator  update
to add new functionality tomorrow June 4th between 14:00 and 15:00 UTC 
(10:00am ET).


Upgrades usually have no visible impact on the user; however, some 
updates may cause Phabricator to be partially unavailable

during this window.

If you have any questions about this, we’re available in #phabricator on 
slack for any questions and concerns.



Regards,


David Lawrence

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

Re: Running C++ early in shutdown without an observer

[David Teller]

Have you looked at nsIAsyncShutdown?

On 07/06/2019 08:18, Henri Sivonen wrote:
> For late shutdown cleanup, we have nsLayoutStatics::Shutdown(). Do we
> have a similar method for running things as soon as we've decided that
> the application is going to shut down?
> 
> (I know there are observer topics, but I'm trying to avoid having to
> create an observer object and to make sure that _it_ gets cleaned up
> properly.)
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Running C++ early in shutdown without an observer

[David Teller]

Even on Desktop, we needed to move some cleanup to startup, in case the
process was killed by the OS.

On 07/06/2019 20:40, Chris Peterson wrote:
> On 6/7/2019 9:36 AM, Kris Maglione wrote:
>> On Fri, Jun 07, 2019 at 09:18:38AM +0300, Henri Sivonen wrote:
>>> For late shutdown cleanup, we have nsLayoutStatics::Shutdown(). Do we
>>> have a similar method for running things as soon as we've decided that
>>> the application is going to shut down?
>>>
>>> (I know there are observer topics, but I'm trying to avoid having to
>>> create an observer object and to make sure that _it_ gets cleaned up
>>> properly.)
>>
>> Observers are automatically cleaned up at XPCOM shutdown, so you
>> generally don't need to worry too much about them. That said,
>> nsIAsyncShutdown is really the way to go when possible. But it
>> currently requires an unfortunate amount of boilerplate.
> 
> Note that on Android, you may never get an opportunity for a clean
> shutdown because the OS can kill your app at any time.
> 
> I don't know what is the recommendation for shutdown activities on
> Android. The GeckoView team has had some recent bugs caused by shutdown
> tasks not running (e.g. committing cached font files or deleting temp
> files). I think these tasks were moved to startup or scheduled to run
> periodically.
> ___
> 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: Running C++ early in shutdown without an observer

[David Teller]

On 10/06/2019 10:28, Henri Sivonen wrote:
>>> Observers are automatically cleaned up at XPCOM shutdown, so you
>>> generally don't need to worry too much about them. That said,
>>> nsIAsyncShutdown is really the way to go when possible. But it currently
>>> requires an unfortunate amount of boilerplate.
> 
> Thanks. (nsIAsyncShutdown indeed looks like it involves a lot of boilerplate.)

I'll be happy to review patches that scrap the boilerplate :)

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

Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`

[David Teller]

The Google style sounds pretty good to me.

On 04/07/2019 07:11, Gerald Squelart wrote:
> Recently I coded something with a not-very-important slow-changing 
> rarely-used positive number: `unsigned mGeneration;`
> My reviewer commented: "Please use a type with an explicit size, such as 
> uint32_t. (General mozilla style; you don't see a bare "unsigned" around 
> much)"
> 
> I had never heard of this (in 4+ years), so I did a bit of research:
> 
> - I found plenty of `unsigned`s around, more than `uint32_t`s.
> 
> - I can't see anything about that in our coding style guides [1, 2].
> 
> - Our latest coding style [1] points at Google's, which has a section about 
> Integer Types [3], and the basic gist is: Use plain `int` for "not-too-big" 
> numbers, int64_t for "big" numbers, intXX_t if you need a precise size; never 
> use any unsigned type unless you work with bitfields or need 2^N overflow (in 
> particular, don't use unsigned for always-positive numbers, use signed and 
> assertions instead).
> 
> So, questions:
> 1. Do we have a written style I missed somewhere?
> 2. Do we have an unwritten style? (In which case I think we should write it 
> down.)
> 3. What do we think of the Google style, especially the aversion to unsigned?
> 
> Cheers,
> Gerald
> 
> 
> [1] 
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
> [2] https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code
> [3] https://google.github.io/styleguide/cppguide.html#Integer_Types
> ___
> 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: [ann] Slides from Mozilla Android Bootcamp presentation

[David Bolter]

Thank you Nick! This is going to be an enduring resource!
D

On Sat, Jul 6, 2019 at 5:34 PM Nicholas Alexander 
wrote:

> On Wed, Jun 26, 2019 at 10:08 AM Nicholas Alexander <
> nalexan...@mozilla.com>
> wrote:
>
> > Hello all,
> >
> > On Wed, Jun 19, 2019 at 10:19 AM Nicholas Alexander <
> > nalexan...@mozilla.com> wrote:
> >
> >> Hello folks,
> >>
> >> As part of the June 2019 Whistler All Hands
> >> , I delivered a
> >> presentation titled "Android Bootcamp" for Gecko/platform engineers
> working
> >> on Android.  It's a 10,000 foot view of Mozilla's Android ecosystem and
> how
> >> to get started building and running Gecko and GeckoView on Android.
> >>
> >> Here are the publicly available slides
> >> <
> https://docs.google.com/presentation/d/1MzU9q2wCwojC0kb1eVfma8hrQ-KayCRFFd_mV5Gx1F4/edit#slide=id.g37695b23f5_0_10
> >
> >> .
> >>
> >
> > Many people reached out to inform me that the slide footer said "Mozilla
> > Confidential".  Nothing here is confidential and I have removed the
> > footer.  Sorry for the confusion, and many thanks to the folks who
> informed
> > me of the footer.
> >
> >
> >> The session was videotaped and I am told it will be available on
> >> air.mozilla.org but I don't know when it will be posted.
> >>
> >
> > It is available on air.mozilla.org now:
> >
> https://onlinexperiences.com/Launch/Event.htm?ShowKey=44908&DisplayItem=E333861
> ,
> > but I think that the recording is private to Mozilla.  The quality of the
> > recording is not great -- somebody kept walking in front of the projector
> > -- so I intend to record a webinar version.  More if and when I get to
> it!
> >
>
> I did get to recording a webinar version
> .  It
> can be viewed from Google Drive directly or downloaded (roughly 2Gb at a
> high quality).  This webinar version should be viewable by anybody with the
> link.
>
> I recorded in a sound booth at the Vancouver Public Library so the audio
> track is great but the video background is not great.  There were some good
> questions raised at the end of the Whistler session but I ran out of time
> when recording so they're not included in the webinar version.
>
> Best,
> 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: non-const reference parameters in new and older code

[David Teller]

I believe in least surprise for the caller of an API. This seems to
match with the Google style, as you describe it: any parameter which may
be mutated in any manner should be passed as pointer, rather than reference.

Cheers,
 David

On 22/07/2019 08:43, Karl Tomlinson wrote:
> https://google.github.io/styleguide/cppguide.html#Reference_Arguments
> has a simple rule to determine when reference parameters are
> permitted:
> "Within function parameter lists all references must be const."
> This is consistent with Mozilla's previous coding style:
> "Use pointers, instead of references for function out parameters,
> even for primitive types." [1]
> However, across Gecko there are different interpretations of what
> "out" parameter means.
> 
> The Google style considers a parameter to be an out parameter if
> any of its state may be mutated by the callee.
> In some parts of Gecko, a parameter is considered an out parameter
> only if the callee might make wholesale changes to the state of
> parameter.  Well before the announcement to switch to Google style,
> this interpretation was discussed in 2017 [2], with subsequent
> discussion around which types were suitable as non-const reference
> parameters.
> 
> I'm asking how should existing surrounding code with some
> different conventions affect when is it acceptable to follow
> Google style for reference or pointer parameters?
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

[David Burns]

On Jul 25, 2019, 12:23 PM +0200, Tom Schuster , wrote:
> On Wed, Jul 24, 2019 at 3:21 AM Boris Zbarsky  wrote:>
> > On 7/22/19 6:22 AM, Tom Schuster wrote:
> > > This was also discussed at https://github.com/whatwg/html/issues/3255.
> > > It seems like Chrome does NOT plan on shipping this at the moment.
> >
> > Does "at the moment" mean they are open to shipping it in the future if
> > we ship it and don't run into web compat issues, or that they are not
> > planning to ship at all? What are Safari's plans here? What is the
> > proposed path to interop?
> >
>
> After asking the Chrome team for clarification
> (https://github.com/whatwg/html/issues/3255), they are interested in
> shipping this, but need more time and information.
> So I propose restricting this change to Beta/Nightly and to wait for
> them or until we see too much fallout.

Are there wpt that we can write to make sure We eventually do have the interop 
we want here?

David

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

Re: Intent to ship: CSS 'display:block ruby'

[David Burns]

Are there any web platform tests for this or will they be added as part of
this work?

David

On Wed, 14 Aug 2019 at 17:38, Mats Palmgren  wrote:

> Summary:
> Add support for 'display:block ruby' which creates a block box
> with a ruby box inside it.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1557825
>
> Standard: https://drafts.csswg.org/css-display/#the-display-properties
>
> Platform coverage: All
>
> Estimated or target release: v70
>
> Preference: None
>
> DevTools: The new value has been added to the auto-completion menu
> for the 'display' property
>
> Other browsers: Other UAs don't support this yet, AFAIK.
>
>
> /Mats
> ___
> 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: PSA: Improvements to infrastructure underpinning `firefox-source-docs`

[David Teller]

That sounds useful :)

Do we have any documentation on how to add documentation?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Naming parameters in lambda expressions

[David Teller]

For what it's worth, I recently spent half a day attempting to solve a
bug which would have been trivial if `a` and `m` prefixes had been
present in that part of the code.

While I find these notations ugly, they're also useful.

Cheers,
 David

On 06/09/2019 12:57, Honza Bambas wrote:
> On 2019-09-05 23:14, Emilio Cobos Álvarez wrote:
>> Yeah, let's not add a new prefix please.
>>
>> I don't like aFoo either, though it's everywhere so consistency is
>> better than nothing :/.
>>
>> That being said, it shouldn't be hard to write some clang plugin or
>> such that automatically renames function arguments to stop using aFoo,
>> should we want to do that... Just throwing it in the air, and
>> volunteering if we agreed to do that ;)
> 
> I personally find it useful (the 'a' prefix) same as the 'm' prefix. 
> When I trace back where from an argument is coming, when it bubbles down
> few functions, it's good to see when it changes from 'aArg' to 'arg' ->
> ah, here we set the value!
> 
> -hb-
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Naming parameters in lambda expressions

[David Teller]

I'm sure that Searchfox could have useful highlights.

However, as you guessed, this was something that happened within an
editor + debugger, so there's only so much we can do in this direction.

Cheers,
 David

On 06/09/2019 15:40, Andrew Sutherland wrote:
> On 9/6/19 7:31 AM, David Teller wrote:
>> For what it's worth, I recently spent half a day attempting to solve a
>> bug which would have been trivial if `a` and `m` prefixes had been
>> present in that part of the code.
>>
>> While I find these notations ugly, they're also useful.
> 
> 
> Is this something searchfox could have helped with by annotating the
> symbol names via background-color, iconic badge, or other means?  Simon
> and I have been discussing an optional emacs glasses-mode style of
> operation which so far would allow for:
> 
> - expansion of "auto" to the actual underlying inferred type. "auto"
> would still be shown, and the expanded type would be shown in a way that
> indicates it's synthetic like being placed in parentheses and rendered
> in italics.
> 
> - inlining of constants.
> 
> 
> Searchfox does already highlight all instance of a symbol when it's
> hovered over, or optionally made sticky from the menu (thanks, :kats!),
> but more could certainly be done here.  The question is frequently how
> to provide the extra information without making the interface too busy.
> 
> But of course, if this was all being done from inside an editor or a
> debugger, no matter what tricks searchfox can do, they can't help you
> elsewhere.
> 
> 
> 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: Intent to Prototype: Have window.outerHeight/outerWidth lie and report the innerHeight/innerWidth

[David Teller]

Have you checked that we don't use it internally in Firefox to e.g.
position tooltip menus? If so, we may need workarounds for the UI and
possibly WebExtensions.

Cheers,
 David

On 08/09/2019 06:57, Tom Ritter wrote:
> Summary:
> window.outerHeight/outerWidth are legacy properties that report the
> size of the outer window of the browser. By subtracting against
> innerHeight/innerWidth it exposes the size of the user's browser
> chrome which can be unique depending on customization, but at the
> least reveals non-standardized information that can be used for
> fingerprinting purposes.
> 
> I have a hard time figuring out how a website would use it for
> (legitimate|reasonable) rendering purposes. I discussed it with Anne
> and we'd like to neuter it and see if we can remove this
> fingerprintable information if possible.
> 
> Tor Browser (and RFP mode) has reported the values of
> innerHeight/innerWidth for outerHeight/outerWidth for a long time and
> I haven't seen or heard of any breakage caused as a result of that.
> 
> (We'll also need to spoof window.screenX and window.screenY as
> window.mozInnerScreenX and window.mozInnerScreenY respectively.)
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1579584
> Standard: https://www.w3.org/TR/cssom-view-1/#dom-window-outerwidth
> Platform coverage: All, although TBH I don't know how this behaves on 
> Android...
> 
> Preference: Yes, this will be controlled by a preference that I'll
> flip for Nightly for now and watch for reports of breakage.
> 
> DevTools bug: n/a
> Other browsers: I haven't proposed this to any other browsers.
> web-platform-tests: I don't believe any WPT actually test for the
> correct value here.
> Secure contexts: This will be applicable everywhere
> 
> I considered adding telemetry for the properties; but reading them
> doesn't imply websites are relying on them for anything.
> 
> -tom
> ___
> 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 aim to add informative messages to your exceptions

[David Teller]

Very good news!

Does this have any impact on SpiderMonkey error handling?

Cheers,
 David

On 14/09/2019 06:47, Boris Zbarsky wrote:
> Hello,
> 
> ErrorResult has two kinds of exception-throwing APIs on it: the older
> ones that don't allow specifying a custom message string, and newer ones
> that do.  People should use the newer ones where possible.
> 
> That means not using the following when throwing nsresults/DOMExceptions:
> 
>   ErrorResult::Throw(nsresult)
>   ErrorResult::operator=(nsresult)
> 
> and instead using:
> 
>   ErrorResult::ThrowDOMException(nsresult, const nsACString&)
> 
> which allows passing a message string that explains why the exception is
> being thrown.  Web developers will thank you and not post tweets like
> https://twitter.com/sebmck/status/1155709250225573889
> 
> When throwing TypeError or RangeError, ThrowTypeError/ThrowRangeError
> already require a message string, though I am making some changes in
> https://phabricator.services.mozilla.com/D45932 to make it a bit simpler
> to pass in custom message strings there.
> 
> Thank you all for making web developers' lives better,
> Boris
> 
> P.S. We currently have a _lot_ of uses of the
> no-informative-error-message APIs.  Some of these might be things we
> don't really expect web pages to hit (e.g. exceptions when in the wrong
> type of global).  But generally speaking all ~560 uses of
> operator=(nsresult) are code smells, as are the ~1000 uses of
> Throw(NS_ERROR_DOM_*).
> ___
> 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 prototype: Web Share Target

[David Burns]

On Fri, 4 Oct 2019 at 03:30,  wrote:

>
>
> Web-platform-tests: requires manual tests.
>

Is this something that we could be tested with testdriver.js inside wpt?

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

Re: Upcoming changes to hg.mozilla.org access

[David Teller]

For what it's worth, when I last tried, I couldn't even `moz-phab
submit` a self-reviewed patch. I had to arbitrarily pick another
reviewer for a patch that was not meant for landing (it was a
demonstration of a reproducible bug in phabricator, but that's another
story).

Cheers,
 Yoric

On 03/11/2019 11:14, Emilio Cobos Álvarez wrote:
> On 11/2/19 12:53 PM, Andreas Tolfsen wrote:
>> Documentation changes have historically been well served by a “wiki
>> editing”/micro adjustments approach.  I wonder if there is anything
>> we can do with Phabricator to ease review requirements for documentation
>> changes from peers?
> 
> I think you can land patches without review even with Lando. I
> personally think that's acceptable for typo fixes / documentation
> updates / etc.
> 
> It's certainly a few more clicks than `git push` / `hg push` though.
> 
>  -- Emilio
> 
> 
>> ___
>> 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

[ANNOUNCEMENT] bugzilla.mozilla.org outage: November 9th, 11:00 AM EST (16:00 UTC)

[David Lawrence]

Bugzilla.mozilla.org will be down for maintenance work on Saturday, 
November 9th, from 11:00 AM EST (16:00 UTC) for approximately four hours.



Various maintenance tasks will be performed during that time period such 
as upgrading of the database to a newer version of MySQL on RDS.



If any issues occur requiring a longer outage, notifications will be 
sent to the appropriate lists and Slack channels. Slack channel #bmo can 
also be used for any concerns or questions.



Thanks

BMO Team

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

Phabricator Update Moved to Tuesday 10:00 AM EST

[David Lawrence]

Normally we do Phabricator release updates for 
phabricator.services.mozilla.com on Mondays at 10:00 AM EST. This coming

weeks update will occur Tuesday at the same time instead.

Thanks
dkl

--
David Lawrence
d...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visibility of disabled tests

[David Burns]

I think a lot of the problem is not necessarily a technical issue, meaning
I am not sure that tooling will solve the problem, but it is more of a
social problem.

I think the problem is making sure that items are triaged and placed into
peoples workflow sooner would solve this problem but I also appreciate the
difficulty when there are competing priorities within teams.

This was a problem I started working on last quarter, mostly for web
platform tests, and would like to continue it this quarter. I am going to
be reaching out to more people over the quarter to see if we can solve
this. If you would like to be part of the process please let me know and I
will schedule an interview with you.

David

On Thu, 9 Jan 2020 at 00:28, Andrew Sutherland 
wrote:

> On 1/8/20 12:50 PM, Geoffrey Brown wrote:
> > Instead of changing the reviewers, how about:
> >  - we remind the sheriffs to needinfo
> >  - #intermittent-reviewers check that needinfo is in place when
> > reviewing disabling patches.
>
> To try and help address the visibility issue, we could also make
> searchfox consume the test-info-disabled-by-os taskcluster task[1] and:
>
> - put banners at the top of test files that say "Hey!  This is
> (sometimes) disabled on [android/linux/mac/windows]"
>
> - put collapsible sections at the top of the directory listings that
> explicitly call out the disabled tests in that directory. The idea would
> be to avoid people needing to scroll through the potentially long list
> of files to know which are disabled and provide some ambient awareness
> of disabled tests.
>
> If there's a way to get a similarly pre-built[2] mapping that would
> provide information about the orange factor of tests[3] or that it's
> been marked as needswork, that could also potentially be surfaced.
>
> Andrew
>
> 1:
>
> https://searchfox.org/mozilla-central/rev/be7d1f2d52dd9474ca2df145190a817614c924e4/taskcluster/ci/source-test/file-metadata.yml#62
>
> 2: Emphasis on pre-built in the sense that searchfox's processing
> pipeline really doesn't want to be issuing a bunch of dynamic REST
> queries that would add to its processing latency.  It would want a
> taskcluster job that runs as part of the nightly build process so it can
> fetch a JSON blob at full network speed.
>
> 3: I guess test-info-all at
>
> https://searchfox.org/mozilla-central/rev/be7d1f2d52dd9474ca2df145190a817614c924e4/taskcluster/ci/source-test/file-metadata.yml#91
> does provide the "failed runs" count and "total runs" which could
> provide the orange factor?  The "total run time, seconds" scaled by the
> "total runs" would definitely be interesting to surface in searchfox.
>
> ___
> 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

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200211.1)

https://bugzil.la/1613686 : Improper encoding of content-type, 
content-transfer-encoding for security reports causes content to not be 
displayed properly
https://bugzil.la/1556727 : Replace “Email sent to” message with a toast 
notification
https://bugzil.la/1611281 : Double-escaping of '<' in code areas
https://bugzil.la/1611494 : Bugzilla custom email headers are getting mashed 
together
https://bugzil.la/1612287 : Issue with negation operator in query search

-- 
David Lawrence
d...@mozilla.com

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

happy bmo push day!

[David Lawrence]

happy bmo push day!

https://bugzil.la/1612290 : Provide self-service UI for users to
reactivate their account after being disabled due to bouncing

One notable change that was pushed live to production today was the
ability to self-service your own account if you get blocked due to email
bouncing issues. Now if your email bounces, instead of not being able to
login completely, your email notifications will be temporarily disabled
but you will still be able to login. You will see a banner message
stating that your email has been disabled with a link to a page where
you can turn it back on.

The linked page will display the error messages returned from the
upstream mail relay and display a form to turn on your email. Please do
not enable email if you are not sure the bouncing issue has been resolved.

A internal counter will allow you to reactivate your email notifications
up to five times in a thirty day period. On the fifth time, your account
will be disabled for login and you will need an admin to reactivate the
account similar to the process before.

This new feature should hopefully help BMO admins to not have to deal
with the majority of intermittent email bounce issues and instead allow
the user to admin their own account when they happen.

The following other changes have been pushed to bugzilla.mozilla.org
<http://bugzilla.mozilla.org>:

https://bugzil.la/1617358 : Extra slash in the "phabricator review
requests" link's url on the BMO dashboard
https://bugzil.la/1591549 : Hide bugs in dependencies and regression
fields from users without access
https://bugzil.la/1237874 : File size unit always plural: "1 bytes"
https://bugzil.la/1599865 : Bug description is erased during page load,
leading to dataloss during Firefox session restore
https://bugzil.la/1472757 : Comment field empty after clicking "go back
page"
https://bugzil.la/1614634 : 13 hours ago wasn't "1 day ago"

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200226.1
<https://github.com/mozilla-bteam/bmo/tree/release-20200226.1>)

-- 
David Lawrence
d...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecation of NS_NewNamedThread

[David Teller]

That's cool!

I wonder if there is (or will be) a way to somehow preserve the naming
part of NS_NewNamedThread, which is sometimes precious for debugging,
i.e. somehow attach to the background thread a debugging information in
addition to the stack that would let us analyze what the thread was
attempting to do in case of crash.

Is anything like this planned?

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

Re: Intent to unship: FTP protocol implementation

[David Teller]

Out of curiosity, what external application? OS-specific?

On 19/03/2020 01:24, Michal Novotny wrote:
> We plan to remove FTP protocol implementation from our code. This work
> is tracked in bug 1574475 [1]. The plan is to
> 
> - place FTP behind a pref and turn it off by default on 77 [2]
> - keep FTP enabled by default on 78 ESR [3]
> - remove the code completely at the beginning of 2021
> 
> We're doing this for security reasons. FTP is an insecure protocol and
> there are no reasons to prefer it over HTTPS for downloading resources.
> Also, a part of the FTP code is very old, unsafe and hard to maintain
> and we found a lot of security bugs in it in the past. After disabling
> FTP in our code, the protocol will be handled by external application,
> so people can still use it to download resources if they really want to.
> However, it won't be possible to view and browse directory listings.
> 
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1574475
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1622409
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1622410
> ___
> 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

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200401.1)

https://bugzil.la/1621662 : Remove option for using Vagrant for BMO development 
and support Docker as primary method
https://bugzil.la/1621160 : First row of stagger column headers will be hidden 
when table header becomes sticky
https://bugzil.la/1621278 : Make bug IDs on search results proper bug links
https://bugzil.la/1622956 : Update contact emails and URLs
https://bugzil.la/1344094 : Add a link to a wiki.mozilla.org page describing 
how to request a keyword
https://bugzil.la/1623727 : Graphviz needs to be installed in bmo-slim base 
container to allow showdependencygraph.cgi to work properly
https://bugzil.la/849902 : my dashboard should be able to refresh on its own
https://bugzil.la/1370492 : "Assigned to you" in My dashboard should show bugs 
priority
https://bugzil.la/1183759 : keyword suggestions should not show keywords which 
have been already selected
https://bugzil.la/1410994 : Add utility for mass-disabling stale accounts


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

Faster compilers available in bootstrap

[David Major]

As of bug 1326486, our clang toolchains for Linux and Windows are built
with PGO. (Apologies to Mac users: that toolchain is cross-compiled.)

Under optimal conditions (Spidermonkey build, touch mfbt) I've seen 10-15%
compile time improvements locally, but in more common scenarios the gains
will be diluted by other parts of the system. Perfherder measured 5-9%
improvements in CI.

To pick up a new compiler: after the next time you update your tree, run
`./mach bootstrap` or `cd ~/.mozbuild && /path/to/mach artifact toolchain
--from-build linux64-clang`, or on Windows replace the last part with
`win64-clang-cl`.

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

Re: Faster compilers available in bootstrap

[David Major]

Yes, I believe so.

On Thu, Apr 9, 2020 at 1:09 PM Botond Ballo  wrote:

> Thanks, compile time improvements are always good news!
>
> Out of curiosity, does this impact builds targeting Android on Linux or
> Windows?
>
> Thanks,
> Botond
>
> On Thu, Apr 9, 2020 at 12:52 PM David Major  wrote:
> >
> > As of bug 1326486, our clang toolchains for Linux and Windows are built
> > with PGO. (Apologies to Mac users: that toolchain is cross-compiled.)
> >
> > Under optimal conditions (Spidermonkey build, touch mfbt) I've seen
> 10-15%
> > compile time improvements locally, but in more common scenarios the gains
> > will be diluted by other parts of the system. Perfherder measured 5-9%
> > improvements in CI.
> >
> > To pick up a new compiler: after the next time you update your tree, run
> > `./mach bootstrap` or `cd ~/.mozbuild && /path/to/mach artifact toolchain
> > --from-build linux64-clang`, or on Windows replace the last part with
> > `win64-clang-cl`.
> >
> > Happy compiling!
> > ___
> > 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

BMO Down for Maintenance Saturday April 18th starting at 9:00 AM EDT (1:00 PM UTC)

[David Lawrence]

  BMO (bugzilla.mozilla.org) will be down for database maintenance this 
Saturday, April 18th. The maintenance will
start around 9:00 AM EDT (1:00 PM UTC). We do not expect it go longer 
than 4 hours but will keep everyone posted if it

ends up taking longer.

  This outage will of course affect other systems that rely on BMO such 
as Phabricator and Lando. So you may see

some issues with those systems as well.

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

[ANNOUNCEMENT] BMO development instance bugzilla-dev.allizom.org will have its data refreshed on Friday May 8th

[David Lawrence]

The database for bugzilla-dev.allizom.org, which is our testing instance 
of BMO, has data that was last synchronized from

production on July, 2017.

On Friday, May 8th, we will be switching over to a newer import of test 
data that is more in sync with data from production.
The data is of course sanitized and all private information has been 
removed. This also includes passwords which means you
will need to do a password reset for your account if you want to access 
bugzilla-dev.allizom.org for testing. To make things
more complicated, all email is normally disabled for the system so a BMO 
administrator will need to reset the password for you.


To access your account on bugzilla-dev.allizom.org after May 8th, 
contact a BMO administrator either in #bmo on Slack, or
#bugzilla.mozilla.org on Matrix. You can also email 
bmo-m...@mozilla.com.  We will be happy to help.


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

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200429.1)

https://bugzil.la/1631051 : The current setting of the auto-refresh button in 
My dashboard should be stored
https://bugzil.la/1631971 : Create link to Matrix support channel for each 
product
https://bugzil.la/1632038 : Remove number of people from bug update toast 
notification
https://bugzil.la/1632624 : When adding vars to the fields data that is logged 
to stack driver, convert to a JSON string
https://bugzil.la/1632994 : [Bugzilla.App] Can't use an undefined value as a 
subroutine reference at /app/Bugzilla/Error.pm line 94.
https://bugzil.la/1633848 : Fix possible areas where memory leak can occur in 
the PhabBugz daemon code
https://bugzil.la/1623009 : Long password denial of service in 
bugzilla.mozilla.org

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

Tree Closure Stats - June 2014

[David Burns]

Hi Everyone, (cross posted to dev-platform)

Below is the stats for Tree Closures for the main trees that the 
sheriffs manage. Please feel free to let me know if you have any questions._


_A lot of the backlog numbers were down to there being AWS machines not 
picking up jobs fast enough. RelEng have been working on this_.


Mozilla Inbound_

2014-06
 backlog: 9:46:52
 checkin-compilation: 1 day, 2:47:16
 checkin-test: 2 days, 23:38:59
 infra: 16:57:27
 no reason: 0:00:33
 other: 1:41:36
 total: 5 days, 6:52:43

_Mozilla-Central_

2014-06
 backlog: 4:55:13
 checkin-compilation: 3:40:03
 checkin-test: 6:24:24
 infra: 9:37:15
 no reason: 0:00:54
 other: 1:42:27
 total: 1 day, 2:20:16

_Fx-Team_

2014-06
 backlog: 9:30:43
 checkin-compilation: 0:12:54
 checkin-test: 9:52:53
 infra: 12:14:43
 no reason: 0:00:22
 other: 1:41:36
 total: 1 day, 9:33:11

_B2G-Inbound_

2014-06
 backlog: 5:06:17
 checkin-compilation: 4:37:29
 checkin-test: 6:54:03
 infra: 8:43:13
 no reason: 3:19:53
 other: 1:01:39
 total: 1 day, 5:42:34

If you would like to see how this compares to previous months please see 
http://futurama.theautomatedtester.co.uk/


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

Tree Closure Stats - July 2014

[David Burns]

Hi Everyone, (cross posted to dev-platform)

Below is the stats for Tree Closures for the main trees that the 
sheriffs manage. Please feel free to let me know if you have any questions._


Mozilla-Inbound
_
2014-07
 checkin-compilation: 1 day, 1:19:41
 checkin-test: 1 day, 2:44:14
 infra: 1 day, 12:59:37
 no reason: 0:00:10
 total: 3 days, 17:03:42_

__Mozilla-Central_

2014-07
 checkin-test: 2:26:46
 infra: 1 day, 10:34:31
 no reason: 0:14:02
 total: 1 day, 13:15:19

_Fx-Team

_2014-07
 checkin-compilation: 1:06:28
 checkin-test: 13:45:54
 infra: 1 day, 14:58:00
 other: 0:46:07
 total: 2 days, 6:36:29_
_
_B2G-Inbound_

2014-07
 checkin-compilation: 1:14:08
 checkin-test: 2:54:52
 infra: 1 day, 5:29:23
 no reason: 0:15:34
 total: 1 day, 9:53:57

If you would like to see how this compares to previous months please see 
http://futurama.theautomatedtester.co.uk/


David

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

Re: Tree Closure Stats - July 2014

[David Burns]

One of the items that has limited the closures is the new requirement 
from Sheriffs that if there is a checkin-needed that there is a try push 
for that patch. There has also been changes from Releng about being able 
to run arbitary jobs against a build which wasnt there before which has 
helped narrow down issues that need backing out.


The sheriffs have, as always, been trying to limit the closures where 
they can which has also had an affect.


David

On 06/08/2014 07:03, Ehsan Akhgari wrote:
Hmm thanks David, this is interesting data!  Looking at the chart, the 
amount of tree closure in the recent past seemed to have peaked in 
April and have been declining since.  Do you have any idea what we've 
been doing right?  I am always uncomfortable with good results that I 
don't understand!


Thanks a lot for sending these out!

On 2014-08-04, 5:42 PM, David Burns wrote:

Hi Everyone, (cross posted to dev-platform)

Below is the stats for Tree Closures for the main trees that the
sheriffs manage. Please feel free to let me know if you have any
questions._

Mozilla-Inbound
_
2014-07
  checkin-compilation: 1 day, 1:19:41
  checkin-test: 1 day, 2:44:14
  infra: 1 day, 12:59:37
  no reason: 0:00:10
  total: 3 days, 17:03:42_

__Mozilla-Central_

2014-07
  checkin-test: 2:26:46
  infra: 1 day, 10:34:31
  no reason: 0:14:02
  total: 1 day, 13:15:19

_Fx-Team

_2014-07
  checkin-compilation: 1:06:28
  checkin-test: 13:45:54
  infra: 1 day, 14:58:00
  other: 0:46:07
  total: 2 days, 6:36:29_
_
_B2G-Inbound_

2014-07
  checkin-compilation: 1:14:08
  checkin-test: 2:54:52
  infra: 1 day, 5:29:23
  no reason: 0:15:34
  total: 1 day, 9:53:57

If you would like to see how this compares to previous months please see
http://futurama.theautomatedtester.co.uk/

David

___
dev-tree-management mailing list
dev-tree-managem...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tree-management




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

Re: We should drop MathML

[storey . david]

On Sunday, May 5, 2013 10:27:41 PM UTC-7, p.kraut...@gmail.com wrote:
> 2.1 you claim MathML never saw traction outside of Firefox. I tried to point 
> out that MathML has huge traction in publishing and the educational sector, 
> even if it wasn't visible on the web until MathJax came along. Google wants 
> MathML support (they just don't trust the current code) while Apple has 
> happily advertised with the MathML they got for free. Microsoft indeed 
> remains a mystery.

Actually, MS is very clear on their position on MathML in Internet Explorer: 
http://status.modern.ie/mathml?term=mathML
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

[David Burns]

I know this is tangential but the small changes are the least tested 
changes in my experience. The try push requirement for checkin-needed 
has had a wonderful impact on the amount of times the tree is closed[1]. 
The tree is less likely to be closed these days.


David

[1] http://futurama.theautomatedtester.co.uk/

On 19/08/2014 22:04, Ralph Giles wrote:

On 2014-08-19 1:55 PM, Benoit Girard wrote:

Perhaps we should instead promote checkin-needed (or a similar simple)
to coalesce simple changes together.

I would prefer to use 'checkin-needed' for more things, but am blocked
by the try-needed requirement. We need some way to bless small changes
for inbound without a try push. Look up the author's commit access maybe?

  -r
___
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

Switching to Visual Studio 2013

[David Major]

We plan to switch the Windows build machines to Visual Studio 2013 on the 
Firefox 35 train.

Some benefits from this change:
* No more linker OOM crashes. VS2013 includes a 64-bit toolchain for 32-bit 
builds, so the linker will no longer be limited to 4GB address space.
* The linker capacity opens the door for merging our binaries into libxul (like 
we do on the other platforms)
* More than 2x improvement in PGO build times
* Better language support

The tracking bug is 914596. The remaining blockers are here: 
https://bugzilla.mozilla.org/showdependencytree.cgi?id=914596&hide_resolved=1

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

Re: Switching to Visual Studio 2013

[David Major]

Please open bugs for this kind of thing. I filed 1061339 for you.

- Original Message -
> From: "xunxun" 
> To: "David Major" 
> Cc: dev-platform@lists.mozilla.org, firefox-...@mozilla.org
> Sent: Monday, September 1, 2014 9:01:19 PM
> Subject: Re: Switching to Visual Studio 2013
> 
> And after switching to VS2013, we should enable AVX2 on libvpx then,
> because libvpx has some AVX2 optimization code.
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Marionette Mailing List

[David Burns]

Hi Everyone!

Marionette now has it's own mailing list[1] that allows us to be able to 
send a message to one place that is open for anyone to send to.


We can use it to discuss changes that are happening in the WebDriver 
spec, breaking changes we want to do and for releases. Please join the 
list and feel free to pass this email on to anyone else that might be 
interested in joining the list.


David


[1] https://lists.mozilla.org/listinfo/tools-marionette
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to Visual Studio 2013

[David Major]

Update: the switch will happen early in version 36.

The build machines needed a reinstall of VS2013 due to a deployment issue. As 
merge day is coming up, it's not a good time for major changes. We'll wait for 
36 to have more bake time. 

On the plus side, we picked up Update 3 in the process.

David

- Original Message -
> From: "David Major" 
> To: dev-platform@lists.mozilla.org, firefox-...@mozilla.org
> Sent: Friday, August 22, 2014 6:27:58 PM
> Subject: Switching to Visual Studio 2013
> 
> We plan to switch the Windows build machines to Visual Studio 2013 on the
> Firefox 35 train.
> 
> Some benefits from this change:
> * No more linker OOM crashes. VS2013 includes a 64-bit toolchain for 32-bit
> builds, so the linker will no longer be limited to 4GB address space.
> * The linker capacity opens the door for merging our binaries into libxul
> (like we do on the other platforms)
> * More than 2x improvement in PGO build times
> * Better language support
> 
> The tracking bug is 914596. The remaining blockers are here:
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=914596&hide_resolved=1
> 
> David
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to Visual Studio 2013

[David Major]

VS2013 is now on inbound and all Windows builds are green.

(Win64 builds were actually switched late last week, as they are
unaffected by trains.)

Please file bugs blocking 914596 if you encounter any VS2013-specific
issues.

If you're not sure what version you're running, you can:
* Check the package:
  VS2013 builds contain msvcr120.dll and msvcp120.dll.
  VS2010 builds contain msvcr100.dll and msvcp100.dll.
* Check the build log:
  VS2013 logs contain the string 'Compiler Version 18.00'.
  VS2010 logs contain the string 'Compiler Version 16.00'.

David


- Original Message -
> From: "David Major" 
> To: dev-platform@lists.mozilla.org, firefox-...@mozilla.org
> Sent: Wednesday, October 8, 2014 7:21:07 PM
> Subject: Re: Switching to Visual Studio 2013
> 
> Update: the switch will happen early in version 36.
> 
> The build machines needed a reinstall of VS2013 due to a deployment issue. As
> merge day is coming up, it's not a good time for major changes. We'll wait
> for 36 to have more bake time.
> 
> On the plus side, we picked up Update 3 in the process.
> 
> David
> 
> - Original Message -
> > From: "David Major" 
> > To: dev-platform@lists.mozilla.org, firefox-...@mozilla.org
> > Sent: Friday, August 22, 2014 6:27:58 PM
> > Subject: Switching to Visual Studio 2013
> > 
> > We plan to switch the Windows build machines to Visual Studio 2013 on the
> > Firefox 35 train.
> > 
> > Some benefits from this change:
> > * No more linker OOM crashes. VS2013 includes a 64-bit toolchain for 32-bit
> > builds, so the linker will no longer be limited to 4GB address space.
> > * The linker capacity opens the door for merging our binaries into libxul
> > (like we do on the other platforms)
> > * More than 2x improvement in PGO build times
> > * Better language support
> > 
> > The tracking bug is 914596. The remaining blockers are here:
> > https://bugzilla.mozilla.org/showdependencytree.cgi?id=914596&hide_resolved=1
> > 
> > David
> > 
> ___
> 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: Compiler version expectations

[David Major]

I was thinking it would be nice to support VS2010 as long as any of our main 
channels use it -- meaning we could drop it on the first day of 39. But I have 
no practical justification for that. If it causes a burden on Skia work then it 
might be reasonable to switch sooner.

> This set: http://chromium-cpp.appspot.com/
What MS compiler does that list require? There's a number of people building 
with VS2012, would that still be supported?

David

- Original Message -
> From: "Jeff Muizelaar" 
> To: "Ehsan Akhgari" 
> Cc: "dev-platform@lists.mozilla.org list" 
> Sent: Friday, October 17, 2014 9:14:19 AM
> Subject: Re: Compiler version expectations
> 
> 
> On Oct 16, 2014, at 3:57 PM, Ehsan Akhgari  wrote:
> 
> > On 2014-10-16, 3:49 PM, Jeff Muizelaar wrote:
> >> After some discussion some IRC it was clear that our compiler deprecation
> >> schedule is not very clear.
> >> 
> >> Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4
> >> for B2G, I expect we’ll be dropping support for building with VS2010 and
> >> GCC 4.4  in the near term.
> > 
> > GCC is https://bugzilla.mozilla.org/show_bug.cgi?id=1077549.  No specific
> > bug or plans for MSVC2010, but I'd be open to killing support for it on
> > the next release train.
> > 
> >> This is important to us because Skia is planing on using more C++11
> >> features in the near term and we’d like to continue updating from
> >> upstream. Are there reasons we can’t drop support for these compilers in
> >> the 37-38 time frame?
> > 
> > What C++11 features specifically?
> 
> This set: http://chromium-cpp.appspot.com/
> 
> -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: Using __declspec(thread) on Windows

[David Major]

> in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in
> our shipped Windows builds mozglue.dll is statically linked to firefox.exe
> so we could put __declspec(thread) variables there.

What does 'statically linked' mean in this context? Mozglue.dll is still a DLL, 
but yes it's a load-time link in version 33. Starting in version 34 it's a 
delay-load due to some WinXP sorcery.

- Original Message -
> From: "Robert O'Callahan" 
> To: dev-platform@lists.mozilla.org
> Sent: Friday, October 17, 2014 10:10:57 AM
> Subject: Using __declspec(thread) on Windows
> 
> It would be cool to use fast TLS via __declspec(thread) on Windows (and
> __thread on gcc/clang). Due to WinXP bustage that only works for variables
> in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in
> our shipped Windows builds mozglue.dll is statically linked to firefox.exe
> so we could put __declspec(thread) variables there.
> 
> However, that would break if someone tried to dynamically load libxul on
> WinXP in the context of a .EXE which did not statically link mozglue.dll.
> Does anyone know if that's a problem? I assume no-one's finding the Firefox
> libxul.dll and loading it from their own .EXE, but maybe they're building
> their own? Do we care?
> 
> Rob
> --
> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
> owohooo
> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
> oioso
> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
> owohooo
> osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
> ooofo
> otohoeo ofoioroeo ooofo ohoeololo.
> ___
> 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: About the bitfield requirement for portibility

[David Major]

Mixing types will likely produce unexpected and/or wasteful results. Examples 
at 
http://randomascii.wordpress.com/2010/06/06/bit-field-packing-with-visual-c/. I 
believe that is still true in VS2013.

David

- Original Message -
> From: "Xidorn Quan" 
> To: dev-platform@lists.mozilla.org
> Cc: "David Baron" , s...@mozilla.org, blizz...@mozilla.org
> Sent: Tuesday, October 21, 2014 4:21:21 PM
> Subject: About the bitfield requirement for portibility
> 
> Hi,
> 
> I read the C++ portibility guide [1], in which it is said that all
> bitfields should have the same type, or some compiler may mishandle the
> code. Is that still true for the compiler set we currently use? The
> compiler the doc mentioned is MSVC++8 which I believe we have dropped. Can
> we use different type for bitfields in a class in our new code?
> 
> I found the document is quiet old. It doesn't seem to be maintained
> anymore. The last update was in 7 years ago, and there are many rules have
> been broken in our current code. At least many bitfield-related rules.
> Should we follow the guide there? Or do we have another document for this
> purpose?
> 
> [1]: https://developer.mozilla.org/en-US/docs/Mozilla/Cpp_portability_guide
> 
> Regards,
> Xidorn
> ___
> 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: Screen Capture

[David Burns]

On 23/10/2014 22:10, Jet Villegas wrote:

Roc wrote up a proposal last year for a web-facing screen capture API:
https://wiki.mozilla.org/User:Roc/ScreenCaptureAPI

Even if not web-facing, we could use the implementation code to cover chrome 
use cases like this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=933389

At a recent GFx/Layout work week, we discussed using the Compositor to extract 
the screen-grab in an efficient, cross-platform manner. It seems we've got 
enough infrastructure in place to implement this quickly.

I'd like options on the API to allow for obscuring text layers so that we could 
use the images for UI tiles, and other privacy-sensitive use cases.

Kicking off this thread to get a discussion on:

1. Web-facing or not?


Not. Feels like there would be a lot of security issues


2. Security/Privacy concerns


Addon's would need to be flagged for using this API. E.g. what if it did 
screenshots when visiting your bank?



3. Implementation concerns


Just for clarification, this would only return the viewport? If so, 
would full document (at the time call so we don't have to scroll and get 
into a parallax painful world) be doable?



4. Feature requests (eg. blurred or lorem-ipsum text)




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

Re: Removing unused Perl scripts from the tree

[David Keeler]

Thanks for doing this!

On 10/27/2014 03:18 PM, Nicholas Nethercote wrote:

> ./security/manager/ssl/tests/unit/test_certificate_usages/generate.pl
> - mentioned in comments in
> security/manager/ssl/tests/unit/test_certificate_usages.js

We probably still need this until bug 969985[0] is fixed (in which we
want to convert it to a python script).

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

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[David Illsley]

On Fri, Jan 16, 2015, at 08:58 AM, Anne van Kesteren wrote:
> On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron 
> wrote:
> > Please reply to this thread if you think there's something else we
> > should say, or if you think we should support the charter.
> 
> I think in general it's fine, but there's a couple things:
> 
> * "Confinement with Origin Web Labels" the description does not make
> it clear what this actually is.
> 
> * "Entry Point Regulation for Web Applications" in a way this is nice
> for defense-in-depth, but also seems to allow a site to completely
> isolate itself from the rest of the web.

Indeed. It reads to me to allow sites to trivially get a browser to
prevent deep linking, which doesn't seem desirable.

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

Re: Capturing additional metadata in moz.build files

[David Burns]

The last bullet for me is the killer feature. I recently hit an issue where
I made some fairly big change to an API and updated all the consumers that
I was aware and even ran a try push for the "happy" set. Unfortunately this
burnt the tree.

I see this situation as a bigger waste of resources (sheriffs time,
infrastructure time) than people not compiling their code and pushing to a
tree.

Obviously there is an issue that annotating the tree will only give you the
"happy" set but that is much better than what we have now and would
hopefully remove the need for people to workout what they need as try
syntax, it would be done for them.

David

On 9 December 2014 at 18:46, Gregory Szorc  wrote:

> In Portland, there were a number of discussions around ideas and features
> that could be easier implemented if only we had better metadata and
> annotations for source files. For example:
>
> * Suggested reviewers for a patch
> * Determine the Bugzilla component for a failing test
> * Determine the Bugzilla component for a changed file so a bug can be
> filed automatically
> * Building a subscription service for watching code and reviews
> * Defining what static analysis should run on a given source file
> * Mapping changed files to impacted automation jobs (useful for minimizing
> automation that runs)
>
> There is pretty much universal consensus that as much metadata as possible
> should live in the tree, next to the things being annotated. This is in
> contrast to how current systems like Bugzilla's suggested reviewers feature
> operate, which is to establish a separate service/data store, essentially
> fragmenting the source of truth and introducing one-off change processes.
>
> I discussed options with Mike Hommey and we believe that moz.build files
> are the appropriate default location for this metadata. We considered
> alternatives such as moz.build-like Python sandboxes under a different
> filename and standalone JSON or YAML files. We like moz.build because it is
> a fully customizable Python environment that already exists and therefore
> doesn't require much effort to stand up and doesn't fragment source of
> truth.
>
> This should not be a surprise: capturing non-build metadata in moz.build
> files was always an eventual goal. There is already precedence for this in
> defining the Sphinx documentation [1]. We just haven't had a good reason or
> time to add more things. Until now.
>
> In the weeks and months ahead, expect to start seeing work to integrate
> extra metadata into moz.build files. This may require refactoring some
> moz.build files. We'll need to support a world where moz.build files can be
> evaluated before configure is executed (so any tool with a copy of the
> source and the Python package for reading moz.build files can extract
> metadata in milliseconds).
>
> This work should enable all kinds of awesome tooling and developer
> productivity wins.
>
> If anyone has any other crazy ideas for what metadata to capture in
> moz.build files to help improve processes, I'm definitely interested in
> hearing them!
>
> [1] https://ci.mozilla.org/job/mozilla-central-docs/Tree_
> Documentation/index.html#adding-documentation
> ___
> 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 un-ship: nsISSLErrorListener

[David Keeler]

As part of the Great PSM Modernization, the nsISSLErrorListener
interface will be removed in bug 844351 [0]. All implementations in
comm-central and chatzilla have already been removed [1][2] (they were
functionally no-ops anyway). All implementations in the addons indexed
by mxr are either incompatible with current versions of gecko, don't do
anything anyway, or both.

Any addons affected by this change can simply remove any references to
nsISSLErrorListener and any implementations of the interface (i.e.
notifySSLError).

Cheers,
David

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=844351
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1143105
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1143110
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

nsINSSCertCache has been removed; use nsIX509CertDB.getCerts()

[David Keeler]

The functionality provided by nsINSSCertCache has been redundant for a
while now. To prevent potential confusion, it has been removed[0][1]. If
you ever needed to do something like this (to get a list of all known
certificates, for example) :

let certcache = Cc["@mozilla.org/security/nsscertcache;1"]
  .createInstance(Ci.nsINSSCertCache);
certcache.cacheAllCerts();
let certlist = certcache.getX509CachedCerts();

The canonical way is now this:

let certdb = Cc["@mozilla.org/security/x509certdb;1"]
   .getService(Ci.nsIX509CertDB);
let certlist = certdb.getCerts();

If you ever needed to do something like this:

let certcache = Cc["@mozilla.org/security/nsscertcache;1"]
  .createInstance(Ci.nsINSSCertCache);
certcache.cacheCertList(someX509CertList);
...
let certlist = certcache.getX509CachedCerts();

The original nsIX509CertList ("someX509CertList" in this example) should
be used directly.

Cheers,
David

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1147085
[1] https://hg.mozilla.org/mozilla-central/rev/1dfe22ca4abe
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

AsyncPanZoom enabled for one Nightly - 4/22/2015 - Windows E10S only

[David Anderson]

To get some feedback on AsyncPanZoom we are enabling it on tonight's nightly, 
for Windows only. It will be re-disabled in the next nightly.

For those unfamiliar, APZ makes scrolling responsive by pre-rendering more 
content than what is visible in the viewport [1]. This lets us present it 
asynchronously without blocking on the content thread.

To use APZ you just need E10S, and to scroll with a mouse wheel or a 
trackpad/touchpad. (Arrow or page dn/up keys do not trigger APZ.)

We're interested in any significant behavior changes with APZ, and especially 
any situations in which we can't pre-render content fast enough. In this case 
you might see blank white areas of the screen while scrolling (aka 
"checkerboarding"). Please file any sites you find this way against the 
"paint-fast" bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1154825

If needed you can flip the APZ pref manually with 
layers.async-pan-zoom.enabled. It requires a browser restart.

If you want to test whether you have APZ working, I've made a test site that 
will jank normal Firefox pretty badly [2]. With APZ+E10S, it should scroll fine.

[1] https://wiki.mozilla.org/Platform/GFX/APZ
[2] http://users.alliedmods.net/~dvander/apzc.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: AsyncPanZoom enabled for one Nightly - 4/22/2015 - Windows E10S only

[David Anderson]

On Wednesday, April 22, 2015 at 3:58:17 AM UTC-4, James May wrote:
> On 22 April 2015 at 12:51, David Anderson <@gmail.com> wrote:
> 
> > To get some feedback on AsyncPanZoom we are enabling it on tonight's
> > nightly, for Windows only. It will be re-disabled in the next nightly.
> >
> > For those unfamiliar, APZ makes scrolling responsive by pre-rendering more
> > content than what is visible in the viewport [1]. This lets us present it
> > asynchronously without blocking on the content thread.
> >
> > To use APZ you just need E10S, and to scroll with a mouse wheel or a
> > trackpad/touchpad. (Arrow or page dn/up keys do not trigger APZ.)
> >
> 
> What about using the scroll bar? Is there somewhere I can see if it's
> enabled/I've got the correct nightly?
> 
> 
> >
> > We're interested in any significant behavior changes with APZ, and
> > especially any situations in which we can't pre-render content fast enough.
> > In this case you might see blank white areas of the screen while scrolling
> > (aka "checkerboarding"). Please file any sites you find this way against
> > the "paint-fast" bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1154825
> >
> > If needed you can flip the APZ pref manually with
> > layers.async-pan-zoom.enabled. It requires a browser restart.
> >
> > If you want to test whether you have APZ working, I've made a test site
> > that will jank normal Firefox pretty badly [2]. With APZ+E10S, it should
> > scroll fine.
> >
> > [1] https://wiki.mozilla.org/Platform/GFX/APZ
> > [2] http://users.alliedmods.net/~dvander/apzc.html
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> 
> -- James

about:support should show you under the "Graphics" section. Clicking the 
scrollbar or dragging the thumb won't route through APZ.

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

Re: Largest chunks of code that are likely to be removable?

[David Zbarsky]

On Tuesday, June 30, 2015 at 9:01:45 AM UTC-4, kgu...@mozilla.com wrote:
> On Tuesday, June 30, 2015 at 3:41:43 AM UTC-4, Kearwood "Kip" Gilbert wrote:
> > Would anyone be opposed to combining the Matrix4x4 class and gfx3DMatrix?  
> > Rather than adding support for transforms and projections that involve 
> > vertices behind the w=0 plane to gfx3DMatrix, it may be cleaner to refactor 
> > affected call-sites to use Matrix4x4 instead.  The remaining references to 
> > gfx3DMatrix would be very few and easily replaced as well.
> > 
> 
> I think dzbarsky was in the process of converting gfx3DMatrix use to 
> Matrix4x4, I'm not sure what happened or if he's still working on it. I think 
> people would be quite happy if you finished it off. CC'ing dzbarsky to see if 
> he has any updates.
> 
> kats

I ran out of time to finish this up and I'm not sure when I'll be able to get 
back to it.  Anyone who wants to should feel free to take over.

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

Re: Shutdown hangs are very common

[David Major]

> Should fixing shutdown hangs be higher priority?
> And if so, should we allow features with shutdown hangs to be released?

I admit to skimming over shutdown-hang signatures when looking at
topcrash lists. In my experience they're often longstanding issues that
are difficult to diagnose and rarely end in a successful fix. Given
infinite resources, we should absolutely work on these hangs. In
practice though, we always have more bugs than time, so I tend to focus
my efforts on other topcrashes that we have a better chance of fixing.

A possible exception is for new, never-before-seen shutdown hangs. Those
are likely to be more actionable since we often have a clear regression
range. I think it would be fair to consider those a blocker for the
associated feature.

___
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++

[David Anderson]

+1 for removing this. Gecko's use is inconsistent, and outside of Gecko code 
that does use it, I've never seen it used in any other codebase. I've never 
gone to another project and thought, "I miss decorating everything in a way 
that changes capitalization and impairs canonical naming".

Reasons for using it in the first place are suspect. None of them seem to 
justify the extra developer overhead or the odd variable names that result. I 
can't imagine we've solved some massive readability problem unique to Gecko or 
unsolved by other projects, or that we're catching important problems that 
static analysis can't find.
___
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++

[David Anderson]

+1 for removing this. Gecko's use is inconsistent, and outside of Gecko code 
that does use it, I've never seen it used in any other codebase. I've never 
gone to another project and thought, "I miss decorating everything in a way 
that changes capitalization and impairs canonical naming".

Reasons for using it in the first place are suspect. None of them seem to 
justify the extra developer overhead or the odd variable names that result. I 
can't imagine we've solved some massive readability problem unique to Gecko or 
unsolved by other projects, or that we're catching important problems that 
static analysis can't find.
___
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++)

[David Major]

May I request that the major parts of this not happen until we have a
blame that can "see through" such changes.

Last I checked, gps had some ideas in that space but lacked time to
implement.

On Wed, Jul 15, 2015, at 03:23 AM, Benjamin Smedberg 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Help with removing __iterator__ from JS

[David Bruant]

Hi Paolo,

The ES6 iterator protocol is what you're looking for. See:
* 
https://hacks.mozilla.org/2015/04/es6-in-depth-iterators-and-the-for-of-loop/
* 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator


Alongside with the computed property syntax, you should be able to 
achieve what you want. Something along the lines of:


function makeIterableEventList(el){
el[Symbol.iterator] = function(){ /* define iterator here*/ }
return el;
}

  events: {
[Symbol.iterator]: function(){ /* define iterator here*/ }
mainview: makeIterableEventList({
  focus(event) {},
}),
filter: makeIterableEventList({
  input(event) {},
}),
  },

  this.boundEventHandlers = [
for ([elementName, events] of this.events)
for ([eventName, handler] of events)
[elementName, eventName, handler.bind(this)]
  ];
---

It should work in Firefox today (at least the Symbol.iterator and 
computed object prop parts. Not 100% sure about the array comprehension 
as I haven't tested)


David

Le 22/07/2015 14:42, Paolo Amadini a écrit :

On 7/21/2015 12:07 PM, Tom Schuster wrote:

Aside: Please also try avoid using Iterator().


What would be the alternative to Iterator() when I need to iterate and
easily assign both keys and values of an object to local variables?

See for example <https://bugzilla.mozilla.org/show_bug.cgi?id=980828>:

  this.boundEventHandlers = [
for ([elementName, events] of Iterator(this.events))
for ([eventName, handler] of Iterator(events))
[elementName, eventName, handler.bind(this)]
  ];

There's more context on the bug for the specific example (the bug is
about supporting destructuring in comprehensions in the first place)
but my concern in general is that I've failed to find an alternative
to Iterator() that is as expressive.

Cheers,
Paolo
___
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

On the future of and application/x-x509-*-cert MIME handling

[David Keeler]

[cc'd to dev-security for visibility. This discussion is intended to
happen on dev-platform; please reply to that list.]

Ryan Sleevi recently announced the pre-intention to deprecate and
eventually remove support for the  element and special-case
handling of the application/x-x509-*-cert MIME types from the blink
platform (i.e. Chrome).

Rather than reiterate his detailed analysis, I'll refer to the post here:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ

Much, if not all, of that reasoning applies to gecko as well.
Furthermore, it would be a considerable architectural improvement if
gecko were to remove these features (particularly with respect to e10s).
Additionally, if they were removed from blink, the compatibility impact
of removing them from gecko would be lessened.

I therefore propose we follow suit and begin the process of deprecating
and removing these features. The intention of this post is to begin a
discussion to determine the feasibility of doing so.

Cheers,
David



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

Re: Intent to Ship: Updated third-party iframe storage behavior

[David Illsley]

Is this pref something that's exposed to users, or is it only
about:config (I can't seem to find any UI for it)?

If so, this seems like a step away from being able to ever expose it as
more apps will be built assuming IndexedDB will be unconditionally
available in 3rd party iframes. This change would make the 'it breaks
the web argument' against exposing it stringer. From my perspective,
this would be undesirable.

On Tue, Aug 18, 2015, at 04:20 PM, Michael Layzell wrote:
> Summary: Currently, there are inconsistent rules about the availability 
> of persistent storage in third-party iframes across different types of 
> storage (such as caches, IndexedDB, localstorage, sessionstorage, and 
> cookies). We are looking to unify these behaviors into a consistent set 
> of rules for when persistent storage should be available. We have 
> modeled this after our cookie rules, and now use the cookie behavior 
> preference to control third party access to these forms of persistent 
> storage. This means that IndexedDB (which was previously unconditionally 
> disabled in 3rd-party iframes) is now available in 3rd party iframes 
> when the accept third-party cookies preference is set to "Always". As 
> our current definition of accepting third-party cookies from "Only 
> Visited" makes no sense for non-cookie storage, we currently treat this 
> preference for these forms of storage as though the preference was
> "Never".
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1184973
> 
> Link to standard: N/A.
> 
> Platform coverage: All platforms.
> 
> Target release: Firefox 43.
> 
> Preference behind which this will be implemented: None, although the 
> preference
> "network.cookie.cookieBehavior" will be used to guide the behavior of 
> storage in third-party iFrames.
> 
> DevTools bug: N/A.
> 
> Do other browser engines implement this: Based on my quick testing: 
> Chrome uses it's third party preference to control access to 
> localStorage and sessionStorage, but not IndexedDB or caches. Safari 
> appears to use it's preference to control IndexedDB, but not 
> sessionStorage or localStorage. IE appears to only use its 3rd party 
> preference for cookies. All other browsers allow IndexedDB in 3rd party 
> iframes with default settings.
> 
> Security & Privacy Concerns: This changes how websites can store data on 
> the user's machine.
> 
> Web designer / developer use-cases: Previously, we had made IndexedDB 
> unavailable in 3rd-party iframes. Web developers will now be able to use 
> IndexedDB in 3rd party iframes when the user has the accept cookies 
> preference set to always.
> 
> Michael
> ___
> 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: Dan Stillman's concerns about Extension Signing

[David Burns]

Another data point that we seem to have overlooked is that users want to be
able to side load their extensions for many different reasons. We see this
with apps on phones and with extensions currently. I appreciate that users
have grown to be warning blind but, as others have pointed out, this feels
like a sure way to have users move from us to Chrome if there extension
lives there too. Once they are lost it will be non-trivial to get them back.

My main gripe is that we will be breaking tools like WebDriver[1] (better
known as Selenium) and not once have we approached that community. Luckily
we have Marionette being developed as a replacement for them, and was being
developed before we started the addon signing. When mentioned I was told
that since it instruments the browser it can never get signed and we need
to get a move on or get everyone to change to the "whitelabel" version to
use WebDriver. Having spoke to peers at other large tech companies they
said no, they will remain on older versions and if it breaks then stop
support for it until they have a like for like replacement. They will stop
caring about WebCompat until they have a like for like replacement. We will
drive away other users because Firefox does work as well on their favourite
website.

There are also companies that have developed internal tools in addons that
they don't want in AMO. We are essentially telling them that we don't care
about how much effort they have put in or how "sooper sekrit" their addon
is. It's in AMO or else...

I honestly thought we would do the "signing keys to developers" approach
and revoke when they are being naughty.

David

[1] http://github.com/seleniumhq/selenium

On 26 November 2015 at 13:50, Thomas Zimmermann 
wrote:

> Hi
>
> Am 26.11.2015 um 13:56 schrieb Till Schneidereit:
>
> > I read the blog post, too, and if that were the final, uncontested word
> on
> > the matter, I think I would agree. As it is, this assessment strikes me
> as
> > awfully harsh: many people have put a lot of thought and effort into
> this,
> > so calling for it to simply be canned should require a substantial amount
> > of background knowledge.
>
> Ok, I take back the 'complete nonsense' part. There can be ways of
> improving security that involve signing, but the proposed one isn't. I
> think the blog post makes this obvious.
>
>
> >
> > I should also give a bit more information about the feedback I received:
> in
> > both cases, versions of the extensions exist for at least Chrome and
> > Safari. In at least one case, the extension uses a large framework that
> > needs to be reviewed in full for the extension to be approved. Apparently
> > this'd only need to happen once per framework, but it hasn't, yet. That
> > means that the review is bound to take much longer than if just the
> > extension's code was affected. While I think this makes sense, two things
> > strike me as very likely that make it a substantial problem: many authors
> > of extensions affected in similar ways will come out of the woodwork very
> > shortly before 43 is released or even after that, in reaction to users'
> > complaints. And many of these extensions will use large frameworks not
> > encountered before, or simply be too complex to review within a day or
> two.
>
> Thanks for this perspective. He didn't seem to use any frameworks, but
> the review process failed for an apparently trivial case. Regarding
> frameworks in general: there are many and there are usually different
> versions in use. Sometimes people make additional modifications. So this
> helps only partially.
>
> And of course reviews are not a panacea at all. Our own Bugzilla is
> proof of that. ;) Pretending that a reviewed extension (or any other
> piece of code) is more trust-worthy is not credible IMHO. Code becomes
> trust-worthy by working successfully in "the real world."
>
> >
> > I *do* think that we shouldn't ship enforced signing without having a
> solid
> > way of dealing with this problem. Or without having deliberately decided
> > that we're willing to live with these extensions' authors recommending
> (or
> > forcing, as the case may be) their users to switch browsers.
>
> I think, a good approach would be to hand-out signing keys to extension
> developers and require them to sign anything they upload to AMO. That
> would establish a trusted path from developers to users; so users would
> know they downloaded the official release of an extension. A malicious
> extensions can then be disabled/blacklisted by simply revoking the keys
> and affected users would notice. For anything non-AMO, the user is on
> their own

Re: ESLint is now available in the entire tree

[David Bruant]

Hi,

Just a drive-by comment to inform folks that there is an effort to 
transition Mozilla JavaScript codebase to standard JavaScript.

Main bugs is: https://bugzilla.mozilla.org/show_bug.cgi?id=867617

And https://bugzilla.mozilla.org/show_bug.cgi?id=1103158 is about 
removing non-standard features from SpiderMonkey.
Of course this can rarely be done right away and most often requires 
dependent bugs to move code to standard ECMAScript (with a period with 
warnings about the usage of the non-standard feature).


Le 27/11/2015 23:53, Dave Townsend a écrit :

We also know that some of our JS syntax isn't supported by ESLint. Array
generators look like they might not be standardized anyway so please
switch them to Array.map.
If anyone notices such cases and don't necessarily have the time to fix 
them right away, please make a bug that blocks

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

...and of course, you meant Array.prototype.map given Array.map is 
non-standard and meant to disappear ;-)

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


For conditional catch expressions we may
want to add support to eslint somehow but for now any of those cases
will just have to be ignored.
I created https://bugzilla.mozilla.org/show_bug.cgi?id=1228841 for 
eventual removal of this non-standard feature.

Adding support to ESLint might be a sensible choice in the meantime indeed.

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

Re: Thanks for all the great teamwork with the Sheriffs in 2015!

[David Burns]

Well done Sheriffs! Really proud of all the work you did this year!

David

On 30 December 2015 at 14:19, Carsten Book  wrote:

> Hi,
>
> Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
> lot of teamwork with different Groups and our Community like Developers, IT
> Teams and Release Engineering and a lot more to keep the trees up and
> running. And without this great teamwork our job would be nearly impossible!
>
> So far in 2015 we had around:
>
> 56471 changesets with 336218 changes to 70807 files in mozilla-central
> and 4391 Bugs filed for intermittent failures (and a lot of them fixed).
>
> So thanks a lot for the great teamwork with YOU in 2015 - especially also
> a great thanks to our Community Sheriffs like philor, nigelb and Aryx who
> done great work!
>
> I hope we can continue this great teamwork in 2016 and also the monthly
> sheriff report with interesting news from the sheriffs and how you can
> contribute will continue then :)
>
> Have a great start into 2016!
>
> Tomcat
> on behalf of the Sheriffs-Team
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200511.1)

https://bugzil.la/1633846 : Enable retries for uploading attachments to S3 when 
an error occurs
https://bugzil.la/1636549 : Guided Bug Helper extension filing bugs with 
'normal' instead of '--' severity.
https://bugzil.la/1634342 : change links for security approval documents to 
source docs
https://bugzil.la/1594066 : reproducible "Can't use ARRAY(0x17340610) as a field 
name." when Custom Search used
https://bugzil.la/1635332 : [SECURITY] Upgrade Mojolicous to 8.42
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200526.1)

https://bugzil.la/1638022 : Phabbugz should not try to set needs-review when 
the revision is closed or abandoned
https://bugzil.la/1639311 : Attaching a file with emojis breaks them
https://bugzil.la/1639903 : Fix `Use of uninitialized value in pattern match 
(m//) at /app/Bugzilla/App.pm line 71`
https://bugzil.la/1639902 : Fix `Use of uninitialized value in string eq at 
/app/Bugzilla/Bug.pm line 4674`

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

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200603.1)

https://bugzil.la/1641249 : Enable the crash signature field for the Focus and 
Fenix Stability components
https://bugzil.la/1641897 : Cleanup old severity values in custom forms and 
other places
https://bugzil.la/1641117 : Add Sentry to the list of See Also URLs.
https://bugzil.la/1642654 : Add ability for users to reactivate their own 
account when disabled from inactivity


David Lawrence
d...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

[David Major]

I agree that it's a bad idea for users to be running permanently with this
setting on their daily driver browsers.

But the environment variable has been a huge productivity enhancer to
reduce my mental load when setting up an extra-hairy debug session or
taking system traces.

I wish we could have a way to allow this for one-off cases but not
long-term usage. Unfortunately I can't settle for a proposal like "allow it
only in debug or only in nightlies" because I often need to debug actual
user-facing builds. Is there any way we could build some auto-expiration
into this setting, like maybe you'd have to set the env var equal to the
build ID or today's date?



On Wed, Jun 10, 2020 at 2:44 PM Dave Townsend  wrote:

> Non-e10s is such a different environment that I don't think we have any
> hope of keeping it working without running the full test suite in that mode
> and I don't think anyone wants to do that. Now that this has started
> breaking I think it is actively harmful to our users for us to allow them
> to disable e10s.
>
> On Wed, Jun 10, 2020 at 11:30 AM Gijs Kruitbosch  >
> wrote:
>
> > (Copied to fx-dev; Replies to dev-platform please.)
> >
> > Hello,
> >
> > Just over a year ago, I started a discussion[0] about our support for
> > disabling e10s. The outcome of that was that we removed support for
> > disabling e10s with a pref on Desktop Firefox with version 68, except
> > for use from automation. We kept support for using the environment
> > variable. [1]
> >
> > Last week, we released Firefox 77, which turned out to break all
> > webpages sent using compression (like gzip) if you had disabled e10s
> > using this environment variable. [2]
> >
> > So here we are again. I'd like to propose we also stop honouring the
> > environment variable unless we're running tests in automation. We
> > clearly do not have sufficient test coverage to guarantee basic things
> > like "the browser works", it lacks security sandboxing, and a number of
> > other projects require it (fission, gpu process, socket process, ...),
> > so I think it's time to stop supporting this configuration at all.
> >
> > I hope to make this change for the 79 cycle. I'm open to arguments
> > either way about what to do for 78 esr (assuming the patch for 79 turns
> > out to be simple; the work to remove the pref had a number of annoying
> > corner-cases at the time).
> >
> > Please speak up if you think that this plan needs adjusting.
> >
> > ~ Gijs
> >
> >
> > [0]
> >
> >
> https://groups.google.com/d/msg/mozilla.dev.platform/cJMzxi7_PmI/Pi1IOg_wCQAJ
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548941
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1638652
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200624.1)

https://bugzil.la/1643821 : Add code to generate_conduit_data.pl to create an 
oauth2 client for Phabricator when used for development
https://bugzil.la/1645455 : Can't attach some text, 500 internal server error
https://bugzil.la/1646559 : Phabricator to BMO OAuth2 authentication fails to 
work properly due to CSP protections

David Lawrence
d...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200722.1)

https://bugzil.la/1645768 : Please add 'See Also' support for GitLab
https://bugzil.la/1651591 : BMO attempts to preload FiraSans, which was 
replaced with FiraGO in May 2019
https://bugzil.la/1652863 : setting the needinfo flag when filing a new bug in 
Core or Toolkit does not cause the textbox for user information to pop up


dkl

David Lawrence
dklaw...@gmail.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200805.1)

https://bugzil.la/1643526 : Attachment comments don't render markdown,
but their preview does
https://bugzil.la/1654456 : [needinfo] Provide instructions and
guidance when needinfo is requested of the bug's reporter
https://bugzil.la/1654370 : Remove remaining code that references
Firefox OS from BMO code base
https://bugzil.la/1655808 : Send guided bug flow users to GitHub for
Fenix issues

-- 
David Lawrence 
Mozilla, Inc.

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

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200908.1)

https://bugzil.la/1657542 : During recent bmo deployment, emails were delivered 
to a file instead of SES which caused interruption of email service
https://bugzil.la/1658622 : "product responsibilities" on editusers should 
include Triage Owner
https://bugzil.la/1588661 : Design for WebHooks
https://bugzil.la/1659177 : Replace mozillians.org with people.mozilla.org in 
Reps Mentorship From
https://bugzil.la/1649841 : Include data-review? requests in notification count
https://bugzil.la/1658317 : Make scopes more descriptive and user friendly when 
authenticating to BMO using OAuth2
https://bugzil.la/1657778 : Offer link to Bugzilla for filing security issues 
in Fenix and iOS
https://bugzil.la/1658846 : Allow users to enable and disable their webhooks
https://bugzil.la/1658845 : Allow users to see their own queue for their 
webhooks
https://bugzil.la/1662747 : Version number not visible in bug query results 
because of Long version numbers
(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200910.1)

https://bugzil.la/1658841 : Webhooks should include comments added to a bug
https://bugzil.la/1661042 : Add a new table profile_iam to contain mappings 
between BMO accounts and LDAP accounts

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

Re: Dogfooding Warp

[David Teller]

That's an impressive speedup!

Congrats on enabling this, everyone.

On 24/09/2020 14:56, Jan de Mooij wrote:

Warp is now enabled by default on Nightly, after positive feedback
from users dogfooding it [0,1].

Here are just a few of the Talos/Raptor graphs showing improvements
when Warp landed:

- 20% on Win64 GDocs loadtime: https://mzl.la/3cp6dAs
- 13% on Android Reddit SpeedIndex: https://mzl.la/2RUWdp8
- 18% on pdfpaint: https://mzl.la/2HtXb9W
- 8% on tp6 JS memory: https://mzl.la/3j2VwGb
- 8% on damp (devtools perf): https://mzl.la/3kLbhSM

Please let us know if you notice any improvements or regressions.

Thanks,
The Warp team

[0] 
https://www.reddit.com/r/firefox/comments/itib6s/dogfooding_warp_on_nightly_new_js_jit_engine/
[1] 
https://www.reddit.com/r/firefox/comments/iy2036/nightly_is_finally_feeling_as_fast_as_chromium/

On Tue, Sep 15, 2020 at 2:57 PM Jan de Mooij  wrote:

Hi all,

The SpiderMonkey (JS) team has been working on a significant update to
our JITs called WarpBuilder (or just Warp) [0,1]. Before we enable
Warp by default in Nightly (hopefully next cycle in 83) we need your
help dogfooding it.

Warp improves performance by reducing the amount of internal type
information that is tracked, optimizing for a broader spectrum of
cases, and by leveraging the same CacheIR optimizations used by last
year’s BaselineInterpreter work [2]. As a result, Warp has a much
simpler design and improves responsiveness and page load performance
significantly (we're seeing 5-15% improvements on many visual metrics
tests). Speedometer is about 10% faster with Warp. The JS engine also
uses less memory when Warp is enabled.

To enable Warp in Nightly:

1. Update to a recent Nightly
2. Go to about:config and set the "javascript.options.warp" pref to true
3. Restart the browser

We're especially interested in stability issues and real-world
performance problems. Warp is currently slower on various synthetic JS
benchmarks such as Octane (which we will continue investigating in the
coming months) but should perform well on web content.

If you find any issues, please file bugs blocking:

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

If you notice any improvements, we'd love to hear about those too.

Finally, we want to thank our amazing contributors André Bargull and
Tom Schuster for their help implementing and porting many
optimizations.

Turning Warp on is only our first step, and we expect to see a lot of
new optimization work over the next year as we build on this. We are
excited for what the future holds here.

Thanks!
The Warp team

[0] WarpBuilder still utilizes the backend of IonMonkey so we don't
feel it has earned the WarpMonkey name just yet.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1613592
[2] 
https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a-faster-js-interpreter-in-firefox-70/

___
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

happy bmo push day!

[David Lawrence]

the following changes have been pushed to bugzilla.mozilla.org:

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200928.1)

https://bugzil.la/1665916 : Remove block severity from blocklist bug creation 
template
https://bugzil.la/1665891 : Overlaid image viewer is not full in height
https://bugzil.la/1666292 : Blue "New comments" popup not clickable
https://bugzil.la/1666917 : Remove code from PhabBugz extension dealing with 
auth delegation since it is no longer used
https://bugzil.la/1667201 : Replace Reps profile with Community Portal profile 
in Reps Budget and Swag forms
https://bugzil.la/1667321 : release tracking report hardcodes old date ranges

dkl

David Lawrence
Bugzilla Senior Software Engineer
d...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[OUTAGE] Phabricator (phabricator.services.mozilla.com) to be down for maintenance on Sat Mar 13th at 12:00 PM EST (17:00 UTC)

[David Lawrence]

On Saturday, March 13th, at 12:00PM EST (17:00 UTC), Phabricator will be 
taken down for a period

of two hours for database maintenance.

A recent upstream migration requires a change to one of the larger 
tables that could cause Phabricator
to be unresponsive. So we decided best to do the changes during off 
hours. Also, taking the system
down will allow us to roll back to a database backup if  any issues 
occur.


Systems affected:
* https://phabricator.services.mozilla.com - Phabricator will be 
unavailable during the database upgrade.
* https://lando.services.mozilla.com - Lando requires access to 
Phabricator for various tasks so it

  should not be used during the outage.
* https://bugzilla.mozilla.org - Bugzilla displays current revision data 
in some bug reports so that

  functionality could be affected.

For any comments or questions, you can find us in #phabricator on Slack.

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

Re: Git mirror of mozilla-central down

[David Humphrey]

Thanks for your work, Ehsan, it's really appreciated.

Can we file a bug on this and not have it be something literally off the 
side of your desk?  Too many of us depend on it now to not see this 
through, and if you can't get it, we need to find another solution soon.


Dave

On 12-09-13 6:24 PM, Ehsan Akhgari wrote:

On 12-09-13 6:18 PM, Ralph Giles wrote:
* This repo is created by RelEng by a direct conversion of the 
mercurial
repository to git, which means that there is no CVS history for you 
to use.


You you understand why this repo doesn't have the same problem with the
ionmonkey merge?


I'm reasonably certain that I hit a bug in hg-git.  I've tried their 
tip version but that still doesn't fix it.  I don't know the details 
of the bug unfortunately (which prevents me from fixing it!), but I 
have no reason to believe that it has anything to do with my setup, so 
I'm pretty sure that the other repo will hit the same problem sooner 
or later.  Which means that it's really a good idea for the 
maintainers of that repo to try to figure out what happened with my 
mirror before this bug breaks their setup.  :-)


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: Git mirror of mozilla-central down

[David Humphrey]

On 12-09-13 6:40 PM, Ehsan Akhgari wrote:

On 12-09-13 6:30 PM, David Humphrey wrote:

Thanks for your work, Ehsan, it's really appreciated.

Can we file a bug on this and not have it be something literally off the
side of your desk?  Too many of us depend on it now to not see this
through, and if you can't get it, we need to find another solution soon.


Not sure what kind of bug are you asking for.  I filed bug 790710 to 
ask for help from IT but that got wontfixed because they did not 
believe that they should spend time on this given that RelEng is in 
the process of duplicating my setup.  Or are you asking for a 
different bug?


Ehsan

Your original email included no bug, so I was asking for *any* bug to 
get filed vs. this getting lost in a mailing list post.


I want to see this not die with your efforts, basically.

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

Proposal: Remove Linux PGO Testing

[David Anderson]

Hi,

After being faced with the prospect of debugging Yet Another PGO-only Bug, I 
propose that we stop testing Linux PGO builds. One of these bugs is causing 
perma-red on Aurora (bug 799295). The developer cost of figuring out how to 
reproduce, debug, and fix these problems is quite high, and even higher where a 
specific distro and compiler version might be in play. The cost is not worth 
the benefit of testing this configuration.

All evidence at Mozilla suggests that PGO is endlessly buggy, and I've heard 
this has been true historically in compilers. PGO deeply and zealously modifies 
calling conventions, function bodies, and large callgraphs, causing subtle 
problems, often topcrashes, that are difficult to reproduce and nearly 
impossible to debug. The result is that we litter the codebase with untestable 
deoptimization hints that may or may not randomly become obsolete.

This is depressing on any platform, but at least on Windows, we have a single 
compiler version to worry about (and, notably, a compiler that has PGO bugs 
even with a huge amount of resources behind its development). It is possible 
that PGO could expose real bugs. If so, we'll see the bug one way or another, 
likely in a context that is more easily reproducible and easier to debug.

So, let's turn off Linux PGO testing, free up releng resources, and save 
ourselves the inevitable pain and suffering.

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

Re: Proposal: Remove Linux PGO Testing

[David Anderson]

Yeah, if we're not testing them I guess we don't have to make or distribute 
them at all.

-David

On Wednesday, October 10, 2012 2:58:18 PM UTC-7, Justin Lebar wrote:
> By "turning off Linux PGO testing", you really mean "stop making and
> 
> distributing Linux PGO builds," right?
> 
> 
> 
> The main reason I'd want Linux PGO is for mobile.  On desktop Linux,
> 
> most users (I expect) don't run our builds, so it's not a big deal if
> 
> they're some percent slower.  (Unless distros commonly do PGO builds
> 
> of Firefox?)  But we're not doing mobile Linux PGO builds (that I know
> 
> of), and I don't expect success with desktop PGO is much related to
> 
> success with mobile PGO.
> 
> 
> 
> -Justin
> 
> 
> 
> On Wed, Oct 10, 2012 at 5:14 PM, David Anderson wrote:
> 
> > Hi,
> 
> >
> 
> > After being faced with the prospect of debugging Yet Another PGO-only Bug, 
> > I propose that we stop testing Linux PGO builds. One of these bugs is 
> > causing perma-red on Aurora (bug 799295). The developer cost of figuring 
> > out how to reproduce, debug, and fix these problems is quite high, and even 
> > higher where a specific distro and compiler version might be in play. The 
> > cost is not worth the benefit of testing this configuration.
> 
> >
> 
> > All evidence at Mozilla suggests that PGO is endlessly buggy, and I've 
> > heard this has been true historically in compilers. PGO deeply and 
> > zealously modifies calling conventions, function bodies, and large 
> > callgraphs, causing subtle problems, often topcrashes, that are difficult 
> > to reproduce and nearly impossible to debug. The result is that we litter 
> > the codebase with untestable deoptimization hints that may or may not 
> > randomly become obsolete.
> 
> >
> 
> > This is depressing on any platform, but at least on Windows, we have a 
> > single compiler version to worry about (and, notably, a compiler that has 
> > PGO bugs even with a huge amount of resources behind its development). It 
> > is possible that PGO could expose real bugs. If so, we'll see the bug one 
> > way or another, likely in a context that is more easily reproducible and 
> > easier to debug.
> 
> >
> 
> > So, let's turn off Linux PGO testing, free up releng resources, and save 
> > ourselves the inevitable pain and suffering.
> 
> >
> 
> > -David
> 
> > ___
> 
> > 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: Proposal: Remove Linux PGO Testing

[David Anderson]

Right, exactly. I am arguing that testing PGO, which is a buggy optimization 
pass, incurs too much developer cost to justify a "5-20%" talos improvement on 
select benchmarks. On Linux, which is a very small percentage of our market 
share, and where distributions make their own builds anyway.

Whether we'd tell distributions that PGO was unsupported: it actually seems 
difficult to say that it *is* supported, even now. PGO bugs will likely be 
highly dependent on the environment and compiler version, which are won't be 
exactly the same anywhere as they are on Windows.

-David

On Thursday, October 11, 2012 12:32:10 AM UTC-7, Boris Zbarsky wrote:
> On 10/11/12 3:05 AM, Tim Taubert wrote:
> 
> > Also, I'm not sure how this affects Telemetry results. In terms of perf
> 
> > measurements we'd probably need to completely ignore everything from
> 
> > non-release builds as the results might differ heavily for some use
> 
> > cases.
> 
> 
> 
> I'm not following.
> 
> 
> 
> The suggestion, as far as I can tell, is to drop Linux PGO completely. 
> 
> We woudln't have it in nightly, Aurora, Beta, or releases.  Compiling 
> 
> with PGO on Linux would be an unsupported configuration that we'd 
> 
> probably advise distros against, because it wouldn't be particularly 
> 
> well-tested.
> 
> 
> 
> So the real question is whether PGO on Linux is worth it in general to 
> 
> us, again as far as I can tell.
> 
> 
> 
> -Boris

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

Re: Proposal: Remove Linux PGO Testing

[David Anderson]

Keep in mind that debug builds are probably at least an order of magnitude 
slower (or a large factor), whereas PGO is a very small factor. (After all, we 
do not PGO on Mac and it doesn't seem to be a problem.)

-David

On Thursday, October 11, 2012 12:05:35 AM UTC-7, Tim Taubert wrote:
> On 10/10/2012 11:57 PM, Justin Lebar wrote:
> 
> > The main reason I'd want Linux PGO is for mobile.  On desktop Linux,
> 
> > most users (I expect) don't run our builds, so it's not a big deal if
> 
> > they're some percent slower.  (Unless distros commonly do PGO builds
> 
> > of Firefox?)  But we're not doing mobile Linux PGO builds (that I know
> 
> > of), and I don't expect success with desktop PGO is much related to
> 
> > success with mobile PGO.
> 
> 
> 
> You may be right for release builds but that doesn't hold true for
> 
> Nightly/Aurora/Beta users. I don't think it's a good idea to make those
> 
> builds ~20% slower when of course we want and need more testers. Don't
> 
> forget that testers on Linux do not only test Linux-only features but
> 
> also features we have on every platform.
> 
> 
> 
> Nobody likes running debug builds because they're slower so why would
> 
> that be different for non-PGO builds?
> 
> 
> 
> Also, I'm not sure how this affects Telemetry results. In terms of perf
> 
> measurements we'd probably need to completely ignore everything from
> 
> non-release builds as the results might differ heavily for some use
> 
> cases.
> 
> 
> 
> - Tim

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

Re: Proposal: Remove Linux PGO Testing

[David Anderson]

> 5-20%, if it were a general slowdown, is _huge_. We have people who work 
> 
> for months to get speedups of 1 or 2%.

Yes, I know, that is pretty much all I do at Mozilla ;) I don't think scattered 
Talos wins of 5-20% are so valuable and important that we should keep 
sacrificing developer time to debug problems from having the buggy optimization 
pass.

> We should find out whether the Linux distros are using PGO. If they are, 
> 
> it would be unwise for us to stop supporting their release 

As I said, unless they're using the exact same compiler version and 
environment, we're already not supporting their configuration. C++ compilers 
are twitchy - much more so with PGO.

-David

On Thursday, October 11, 2012 7:46:00 AM UTC-7, Gervase Markham wrote:
> On 11/10/12 08:54, David Anderson wrote:
> 
> > Keep in mind that debug builds are probably at least an order of
> 
> > magnitude slower (or a large factor), whereas PGO is a very small
> 
> > factor. (After all, we do not PGO on Mac and it doesn't seem to be a
> 
> > problem.)
> 
> 
> 
> 5-20%, if it were a general slowdown, is _huge_. We have people who work 
> 
> for months to get speedups of 1 or 2%.
> 
> 
> 
> We should find out whether the Linux distros are using PGO. If they are, 
> 
> it would be unwise for us to stop supporting their release 
> 
> configuration, and tell them that the new supported configuration is a 
> 
> lot slower...
> 
> 
> 
> Gerv

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

Re: Proposal: Remove Linux PGO Testing

[David Anderson]

These Dromaeo improvements will in part be because IonMonkey is not fully 
JIT'ing these paths yet (a regression we're tracking from Firefox 17).

-David

On Thursday, October 11, 2012 11:26:49 AM UTC-7, Rafael Ávila de Espíndola 
wrote:
> On 10/11/2012 02:33 AM, Mike Hommey wrote:
> 
> > On Wed, Oct 10, 2012 at 05:57:53PM -0400, Justin Lebar wrote:
> 
> >> By "turning off Linux PGO testing", you really mean "stop making and
> 
> >> distributing Linux PGO builds," right?
> 
> >>
> 
> >> The main reason I'd want Linux PGO is for mobile.  On desktop Linux,
> 
> >> most users (I expect) don't run our builds, so it's not a big deal if
> 
> >> they're some percent slower.
> 
> >
> 
> > Many people have made claims about that at several different occasions.
> 
> > Can we once and for all come up with actual data on that?
> 
> >
> 
> > That being said, PGO on Linux is between 5 and 20% improvement on our
> 
> > various talos tests. That's with the version of gcc we currently use,
> 
> > which is 4.5. I'd expect 4.7 to do a better job even, especially if we
> 
> > added lto to the equation (and since we are now building on x86-64
> 
> > machines, we wouldn't have to worry about memory usage ; link time could
> 
> > be a problem, though).
> 
> >
> 
> > Also note that disabling PGO currently also means disabling the
> 
> > optimizations we do on omni.ja (central directory optimizations and
> 
> > reordering). This is somehow covered by bug 773171.
> 
> 
> 
> I wouldn't be surprised if most of the pgo benefit is because of bad 
> 
> inline decisions by gcc. If we can narrow the gap by adding 
> 
> MOZ_ALWAYS_INLINE, then maybe we can drop pgo.
> 
> 
> 
> I did a talos run during the last clang update to compare it with the 
> 
> previous version on OS X, but I now added linux runs to compare gcc 4.5 
> 
> and clang on linux. The results are interesting (see attached file). 
> 
> dromaeo_dom shows a 31% improvement on 64 bits for example.
> 
> 
> 
> This also suggests another option: using clang on linux too. This would 
> 
> have the added benefit of using the same compiler for OS X and Linux, 
> 
> which would remove most of the argument of developers spending time on 
> 
> linux only issues. I can do a comparison of gcc+pgo and clang if others 
> 
> are interested.
> 
> 
> 
> > Mike
> 
> 
> 
> Cheers,
> 
> Rafael
> 
> 
> 
> 
> 
> a11yr_paint
> 
> Fedora 12 - Constantine   | (527.681818182, 2.59651983057) -> 
> (413.15,   1.41403960494)  1.2772x better
> 
> Fedora 12 x64 - Constantine   | (451.454545455, 1.24422992408) -> 
> (349.45,   0.819984718342) 1.2919x better
> 
> 
> 
> dromaeo_css
> 
> Fedora 12 - Constantine   | (2152.09181818, 12.0144869607) -> 
> (2639.839, 8.95312637755)  1.2266x better
> 
> Fedora 12 x64 - Constantine   | (2485.29272727, 13.7659449067) -> 
> (2921.445, 17.8096790459)  1.1755x better
> 
> 
> 
> dromaeo_dom
> 
> Fedora 12 - Constantine   | (142.806181818, 0.744898237637) -> 
> (187.9765, 0.650195498534) 1.3163x better
> 
> Fedora 12 x64 - Constantine   | (181.576818182, 0.806482009967) -> 
> (232.0514, 1.34925457235)  1.2780x better
> 
> 
> 
> kraken
> 
> Fedora 12 - Constantine   | (3939.40909091, 71.9270328223) -> 
> (3767.41,  71.3917310166)  1.0457x better
> 
> Fedora 12 x64 - Constantine   | (3579.29090909, 15.596652341)  -> 
> (3446.56,  9.33275577468)  1.0385x better
> 
> 
> 
> num_ctors
> 
> CentOS (x86_64) release 5 (Final) | (232.0,None)   -> (174.0, 
>None)   1.x better
> 
> CentOS release 5 (Final)  | (232.0,None)   -> (174.0, 
>None)   1.x better
> 
> 
> 
> sunspider
> 
> Fedora 12 - Constantine   | (364.172727273, 1.5583412188)  -> 
> (345.08,   1.26271089553)  1.0553x better
> 
> Fedora 12 x64 - Constantine   | (334.363636364, 2.07058055282) -> 
> (321.97,   2.64172734312)  1.0385x better
> 
> 
> 
> tdhtmlr_nochrome_paint
> 
> Fedora 12 - Constantine   | (417.558727273, 0.728348424302) -> 
> (392.9735, 0.424360042529) 1.0626x better
> 
> Fedora 12 x64 - Constantine   | (390.3705, 0.633414181048) -> 
> (359.1264, 6.1131889195)   1.0870x better
> 
> 
> 
> tdhtmlr_paint
> 
> Fedora 12 - Constant

Re: Proposal: Remove Linux PGO Testing

[David Anderson]

On Thursday, October 11, 2012 5:49:07 PM UTC-7, Brian Smith wrote:
> I think it is important to give Linux users the fastest browser we can give 
> them, because:

It's still unclear to me what our Linux PGO builds mean. Do distributions use 
them? If not, are they using the exact same compiler version and PGO 
environment data? If not, then they have a different configuration that we 
haven't tested.

If distributions are using these builds, or these builds are favored by users 
over distribution builds, then we'll have to answer Dave and Bill's points re: 
cost-benefit analysis.

-David

> Zack Weinberg wrote:
> 
> > Link-time optimization is described as an experimental new feature in
> 
> > the GCC 4.5.0 release notes[1].  The 4.6.0 release notes[2] say that
> 
> > it has now "stabilized to the point of being usable", and the 4.7.0
> 
> > release notes[3] describe it as still further improved both in
> 
> > reliability and code quality.  If we're trying to use the 4.5 LTO,
> 
> > I'm not at all surprised to hear it's causing more trouble than it's
> 
> > worth.
> 
> > 
> 
> > PGO is not the same thing as LTO, of course, but GCC's PGO was kind
> 
> > of an unloved stepchild until they got serious about LTO, so that,
> 
> > too, is likely to be much improved in 4.7.
> 
> 
> 
> I think it is important to give Linux users the fastest browser we can give 
> them, because:
> 
> 
> 
> 1. Linux users tend to be disproportionately influential in the markets we 
> care the most about (web developers, techies)
> 
> 2. Linux is the foundation of B2G and Firefox for Android, where we 
> *definitely* must deliver the fastest product we can
> 
> 
> 
> Now, if it were up to me, I'd try to reproduce this on a build built with the 
> latest stable GCC or latest stable clang, and if that fixes the issue, I'd 
> consider this a big motivation for upgrading to GCC 4.5 to a better compiler, 
> which we need to do anyway for language feature support. Definitely, I don't 
> think we should be adding hacks to our code to work around GCC problems that 
> are already fixed in later releases of GCC. It's better to just make the 
> build fail when the user attempts to use one of those older GCC releases.
> 
> 
> 
> Now, if PGO doesn't result in the fastest browser, then of course we should 
> disable PGO.
> 
> 
> 
> Or, if there is no better compiler possible, then yes, I think it makes sense 
> to disable PGO temporarily until there is a better compiler available. 
> (And/or, help fix the compiler, either by contributing a patch, or by 
> commissioning somebody else to contribute a patch.)
> 
> 
> 
> Cheers,
> 
> Brian

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

Re: Firefox debug build and https: sec_error_bad_signature

[David Dahl]

I have also experienced the same problem on ubuntu/clang - probably the same as 
yours. I downloaded a debug build from ftp.mozilla.org in order to test this 
with our "official debug builds", which are built with gcc:

Build platform
target
x86_64-unknown-linux-gnu
Build tools
CompilerVersion Compiler flags
/usr/bin/ccache /tools/gcc-4.5-0moz3/bin/gccgcc version 4.5.2 (GCC) 
-pedantic -Wall -Wpointer-arith -Wdeclaration-after-statement 
-Werror=return-type -Wtype-limits -Wempty-body -Wno-unused 
-Wno-overlength-strings -Wcast-align -Wno-long-long -fno-strict-aliasing 
-ffunction-sections -fdata-sections -pthread -pipe -DDEBUG -D_DEBUG -DTRACING 
-g -Os -freorder-blocks -finline-limit=50 -fno-omit-frame-pointer
/usr/bin/ccache /tools/gcc-4.5-0moz3/bin/g++gcc version 4.5.2 (GCC) 
-pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type 
-Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings 
-Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -Wno-long-long 
-fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections 
-fdata-sections -fno-exceptions -std=gnu++0x -pthread -pipe -DDEBUG -D_DEBUG 
-DTRACING -g -Os -freorder-blocks -finline-limit=50 -fno-omit-frame-pointer
Configure arguments

--enable-debug --enable-trace-malloc --enable-signmar --enable-stdcxx-compat 
--with-ccache=/usr/bin/ccache --enable-warnings-as-errors 


Naturally, these work fine. I wish I knew what was the problem here too.

Cheers,

David

- Original Message -
From: "Mihai Sucan" 
To: "Brian Smith" 
Cc: "mozilla-dev-platform" 
Sent: Wednesday, November 21, 2012 5:54:13 AM
Subject: Re: Firefox debug build and https: sec_error_bad_signature

Thank you for your reply.

On Wed, 21 Nov 2012 00:20:37 +0200, Brian Smith  wrote:

> Mihai Sucan wrote:
>> Any https page I try to load shows:
>>
>>Peer's certificate has an invalid signature.
>>Error code: sec_error_bad_signature
>>
>> I can't even run mochitests that load https pages.
>
> 1. Are you using --use-system-nss and/or --use-system-nspr?

This is my mozconfig for dbg builds:
https://github.com/mihaisucan/mozilla-work/blob/master/mozconfig/dbg

I don't know what ./configure does. How can I check?


> 1.1: Are you trying to build 64-bit Firefox? I remember that 64-bit NSS  
> doesn't always work.

I'm on Ubuntu amd64. about:buildconfig:

about:buildconfig

Target: x86_64-unknown-linux-gnu

Compiler:

/usr/bin/ccache clang -Qunused-arguments -fcolor-diagnostics -w

Flags:

-Qunused-arguments -pedantic -Qunused-arguments -Wall -Wpointer-arith  
-Wdeclaration-after-statement -Werror=return-type -Wtype-limits  
-Wempty-body -Wno-unused -Wno-overlength-strings -Wno-long-long  
-fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -pipe  
-DDEBUG -D_DEBUG -DTRACING -g -fno-omit-frame-pointer


Compiler:

/usr/bin/ccache clang++ -Qunused-arguments -fcolor-diagnostics -w

Flags:

-Qunused-arguments -pedantic -Qunused-arguments -Wall -Wpointer-arith  
-Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body  
-Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof  
-Wno-variadic-macros -Wno-c++0x-extensions -Wno-extended-offsetof  
-Wno-unknown-warning-option -Wno-return-type-c-linkage  
-Wno-mismatched-tags -Wno-long-long -fno-exceptions -fno-strict-aliasing  
-fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x  
-pthread -pipe -DDEBUG -D_DEBUG -DTRACING -g -fno-omit-frame-pointer  
-Qunused-arguments

Configure arguments:

--enable-application=browser --disable-optimize --enable-debug  
--enable-tests --enable-chrome-format=symlink --with-ccache


$ cclang -v

Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM  
3.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

$ file dist/bin/firefox-bin

dist/bin/firefox-bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),  
dynamically linked (uses shared libs), for GNU/Linux 2.6.24

$ ccache -V
ccache version 3.1.6


> 2. What compiler are you building with?

See above.


> 3. Do things work with a new profile?

Afaik, running mochitests always creates a new temporary profile and I  
have problems running them. I just tried with a new profile on my own (as  
a user): same problem.

Here's what I get when I load google.com (something I haven't seen before):

   A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem  
has occurred with the token or slot.
   Error code: sec_error_pkcs11_device_error.


> 4. Do thinks work in safe mode and/or with all addons disabled?

No addons installed - new profile. Tried -safe-mode as well, no luck.


> 5. File a bug, CC bsm...@mozilla.com, and attach one of the certificates  
> to the bug.

Which certificate should I attach? I have this problem

Re: Firefox Social API

[David Dahl]

Adam:

Disclaimer: I only speak for myself, not Mozilla, I do not have a Facebook 
account (and have no plans to create one even to test this Firefox feature)

The Social API was built to be quite generic in nature. I assume it is pretty 
easily-integrated with any site that desires to do so. I imagine integrating 
with Facebook was a strategic move to get many users using this feature to 
quickly weed out bugs. 

I fully agree with you, Tim Berners-Lee and others who think that 'walled 
gardens' are bad for the web. Making chat and other social features more 
integrated with the browser will hopefully move the 'needle of control' back 
toward users who own their social graph and chat data.

As far as P2P features in browsers, perhaps the time has come, however, with 
WebRTC I understand a 3rd party server is stilled required to set up the NAT 
traversal.

Cheers,

David

- Original Message -
From: "Adam Sobieski" 
To: dev-platform@lists.mozilla.org
Sent: Thursday, November 22, 2012 5:29:16 PM
Subject: Firefox Social API

Mozilla Firefox Team and Community,
 
Greetings.  I would like to comment on the new Firefox Social API 
(http://blog.mozilla.org/blog/2012/11/20/firefox-introduces-new-social-api-and-previews-integration-with-facebook/).
 
I would like to list a few events that might indicate some concerns that a 
number of scientists and technologists might have about centralized 
socialization, or a socialization industry.

November 2, 2010. The 2010 United States Elections.

November 22, 2010. Tim Berners-Lee in Scientific American indicates that some 
large networking sites are not congruent with the principles of the Web. 
http://www.scientificamerican.com/article.cfm?id=long-live-the-web .

June 14, 2011. Iceland makes use of Facebook for e-democracy. 
http://www.zdnet.com/blog/facebook/iceland-taps-facebook-to-rewrite-its-constitution/1600
 .
 
January 12, 2012. Facebook gives Politico, and possibly others, deep access to 
users' political sentiments. http://mashable.com/2012/01/12/politico-facebook/ 
, 
http://allthingsd.com/20120112/facebook-gives-politico-deep-access-to-users-political-sentiments/
 .
 
November 6, 2012. The 2012 United States Elections.
 
November 22, 2012. Facebook proposes to end voting on privacy issues. 
http://abcnews.go.com/Technology/wireStory/facebook-proposes-end-voting-privacy-issues-17787954
 .

November 22, 2012. Nordic countries express frustration with Facebook. 
"Facebook should stop unsolicited advertising to users in Nordic countries or 
face legal action, the Norwegian consumer agency said on Thursday." 
http://phys.org/news/2012-11-nordic-countries-facebook-ads.html .
 
Those events indicate some of the concerns that a number of scientists and 
technologists might have about large social networking websites, centralized 
socialization, or a socialization industry.

Onto technical topics, the Firefox Social API could be scalable for modular 
components, scalable for P2P solutions.  WebRTC is a contemporary technology 
and pertains to video calls, conferences, and potentially videos forums.  
WebRTC does include P2P technologies.  I would like to describe a scenario with 
P2P distributed storage for hypertext, audio and video calls, some new 
features, towards some P2P social networking technology topics.

Scenario: Person A calls Person B; Person A might know whether Person B is 
online or offline before they commence a communication activity. If Person B is 
online, the data motion is simplified. If Person B is offline, they could have 
an answering machine multimedia clip available on a group of nodes which they 
have designated, e.g. per social network graphs. Person A can watch Person B's 
streaming answering machine clip or skip to leaving a message. If Person A 
leaves a message, that streaming video message is stored on a group of nodes, 
possibly the union of the two groups of nodes designated by both Person A and 
Person B. When Person B comes online, within a system-specific duration of 
time, e.g. 90 days or 1 year, the portions of data are downloaded by them, 
segmented downloading, and possibly with something like a BITS 4.0+ technology. 
If Person B chooses to view any of the streamable media during that initial 
phase, which might not be uncommon, a log on and check message
 s pattern, the segmented downloading can toggle to a streaming variety of 
download, including variable bitrate streaming. Even after Person B might watch 
real-time segmented downloads of variable-bitrate streaming multimedia, the 
entirety of their high-bitrate messages could be downloaded and stored by 
Person B unless or until Person B indicated otherwise.

We can envision and develop features for P2P video communication systems, P2P 
hypertext, audio and video systems, multimedia systems, including those 
described.  Video calls and Video conferencing have been illustrated with 
WebRTC; video forums may be rea

Re: Firefox Social API

[David Dahl]

It seems this bug tracks the work for integration with any chat provider/site: 
https://bugzilla.mozilla.org/show_bug.cgi?id=809694

Cheers,

David

- Original Message -
From: "David Dahl" 
To: "Adam Sobieski" 
Cc: dev-platform@lists.mozilla.org
Sent: Thursday, November 22, 2012 11:35:07 PM
Subject: Re: Firefox Social API

Adam:

Disclaimer: I only speak for myself, not Mozilla, I do not have a Facebook 
account (and have no plans to create one even to test this Firefox feature)

The Social API was built to be quite generic in nature. I assume it is pretty 
easily-integrated with any site that desires to do so. I imagine integrating 
with Facebook was a strategic move to get many users using this feature to 
quickly weed out bugs. 

I fully agree with you, Tim Berners-Lee and others who think that 'walled 
gardens' are bad for the web. Making chat and other social features more 
integrated with the browser will hopefully move the 'needle of control' back 
toward users who own their social graph and chat data.

As far as P2P features in browsers, perhaps the time has come, however, with 
WebRTC I understand a 3rd party server is stilled required to set up the NAT 
traversal.

Cheers,

David

- Original Message -
From: "Adam Sobieski" 
To: dev-platform@lists.mozilla.org
Sent: Thursday, November 22, 2012 5:29:16 PM
Subject: Firefox Social API

Mozilla Firefox Team and Community,
 
Greetings.  I would like to comment on the new Firefox Social API 
(http://blog.mozilla.org/blog/2012/11/20/firefox-introduces-new-social-api-and-previews-integration-with-facebook/).
 
I would like to list a few events that might indicate some concerns that a 
number of scientists and technologists might have about centralized 
socialization, or a socialization industry.

November 2, 2010. The 2010 United States Elections.

November 22, 2010. Tim Berners-Lee in Scientific American indicates that some 
large networking sites are not congruent with the principles of the Web. 
http://www.scientificamerican.com/article.cfm?id=long-live-the-web .

June 14, 2011. Iceland makes use of Facebook for e-democracy. 
http://www.zdnet.com/blog/facebook/iceland-taps-facebook-to-rewrite-its-constitution/1600
 .
 
January 12, 2012. Facebook gives Politico, and possibly others, deep access to 
users' political sentiments. http://mashable.com/2012/01/12/politico-facebook/ 
, 
http://allthingsd.com/20120112/facebook-gives-politico-deep-access-to-users-political-sentiments/
 .
 
November 6, 2012. The 2012 United States Elections.
 
November 22, 2012. Facebook proposes to end voting on privacy issues. 
http://abcnews.go.com/Technology/wireStory/facebook-proposes-end-voting-privacy-issues-17787954
 .

November 22, 2012. Nordic countries express frustration with Facebook. 
"Facebook should stop unsolicited advertising to users in Nordic countries or 
face legal action, the Norwegian consumer agency said on Thursday." 
http://phys.org/news/2012-11-nordic-countries-facebook-ads.html .
 
Those events indicate some of the concerns that a number of scientists and 
technologists might have about large social networking websites, centralized 
socialization, or a socialization industry.

Onto technical topics, the Firefox Social API could be scalable for modular 
components, scalable for P2P solutions.  WebRTC is a contemporary technology 
and pertains to video calls, conferences, and potentially videos forums.  
WebRTC does include P2P technologies.  I would like to describe a scenario with 
P2P distributed storage for hypertext, audio and video calls, some new 
features, towards some P2P social networking technology topics.

Scenario: Person A calls Person B; Person A might know whether Person B is 
online or offline before they commence a communication activity. If Person B is 
online, the data motion is simplified. If Person B is offline, they could have 
an answering machine multimedia clip available on a group of nodes which they 
have designated, e.g. per social network graphs. Person A can watch Person B's 
streaming answering machine clip or skip to leaving a message. If Person A 
leaves a message, that streaming video message is stored on a group of nodes, 
possibly the union of the two groups of nodes designated by both Person A and 
Person B. When Person B comes online, within a system-specific duration of 
time, e.g. 90 days or 1 year, the portions of data are downloaded by them, 
segmented downloading, and possibly with something like a BITS 4.0+ technology. 
If Person B chooses to view any of the streamable media during that initial 
phase, which might not be uncommon, a log on and check message
 s pattern, the segmented downloading can toggle to a streaming variety of 
download, including variable bitrate streaming. Even after Person B might watch 
real-time segmented downloads of variable-bitrate streaming multimedia, the 
entirety of their high-bitrate message

Re: automating gecko in-rprocess xpcom

[David Burns]

Peter,

The FirefoxDriver drive does, as Clint points out, speak via XPCOM to 
the browser to get access. Granted there is a lot of JavaScript that 
needs to be executed for calls. We are doing rewriting it to put it into 
Gecko[1] because it allows us to implement the Browser Automation W3C 
Spec[2]. This still an out-of-process, from a client/server perspective, 
way to drive the browser, like WebDriver, but it means that we can 
automate things like Fennec and B2G just by sending data to the browser.


Let me know if you have any further questions and if you have any 
suggestions please let us know!


David

[1] https://developer.mozilla.org/en-US/docs/Marionette
[2] http://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html

On 03/12/2012 16:22, Clint Talbert wrote:
I'm not sure what you mean because as best I understand it, the 
Selenium Firefox driver is an extension and thus runs in the same 
process space as Firefox itself.  If you're looking for a closer 
binding between your automation code and Firefox, you can take a look 
at our new automation mechanism called Marionette that uses the 
WebDriver protocol to drive Firefox. (Marionette is wired inside Gecko 
in order to make this kind of automation easier).


https://developer.mozilla.org/en-US/docs/Marionette

Hope that helps,

Clint

On 11/30/2012 10:04 PM, mozz wrote:
i've been using selenium firefox driver to automate firefox and it's 
too slow as communications between firefox and driver happens 
out-of-process.


possible to embed gecko in a process and drive it/interact with its 
DOM directly via xpcom?


thanks.





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

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

[David Rajchenbach-Teller]

Yes, I mostly meant XPConnect.

On 04/01/16 14:36, smaug wrote:
> On 01/03/2016 06:35 PM, David Rajchenbach-Teller wrote:
>> Accessing XPCOM in a worker will most likely break the garbage-collector
>> in novel and interesting ways,
> 
> Why would it? Our workers are full of xpcom stuff.
> One needs to be careful what to touch sure, and deal with CC and GC
> handling like in the main thread.
> 
> But perhaps you meant xpconnect, not xpcom.

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

W3C Proposed Recommendation: Web Storage (Second Edition)

[L. David Baron]

A W3C Proposed Recommendation is available for the membership of W3C
(including Mozilla) to vote on, before they proceed to the final
stage of being W3C Recomendation:

  Web Storage (Second Edition)
  http://www.w3.org/TR/webstorage/
  deadline: January 8, 2016 (Friday!)

This specification is derived from an upstream WHATWG specification.

If there are comments you think Mozilla should send as part of the
review, or if you think Mozilla should voice support or opposition
to the specification, please say so in this thread.  (I'd note,
however, that there have been many previous opportunities to make
comments, so it's somewhat bad form to bring up fundamental issues
for the first time at this stage.)

(Sorry, should have sent these out a bit sooner.)

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Proposed W3C Charter: Web Authentication Working Group

[L. David Baron]

The W3C is proposing a charter for:

  Web Authentication Working Group
  http://www.w3.org/2015/12/web-authentication-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2015Dec/0010.html

Mozilla has the opportunity to send comments or objections through
January 25.

Please reply to this thread if you think there's something we should
say as part of this charter review.

(It seems likely that we want to support it given that Richard is
involved, and one of the proposed co-chairs.)

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: W3C Proposed Recommendation: Web Storage (Second Edition)

[L. David Baron]

On Thursday 2016-01-07 08:52 +0100, Anne van Kesteren wrote:
> On Thu, Jan 7, 2016 at 6:05 AM, L. David Baron  wrote:
> > This specification is derived from an upstream WHATWG specification.
> 
> And therefore hasn't removed the storage mutex concept it seems. Not
> sure if that's careworthy since we don't implement from TR/ anyway,
> but I thought I'd mention it.

Could you give a brief explanation of what the storage mutex is, and
why it was/should be removed?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: Proposed W3C Charter: Web Authentication Working Group

[L. David Baron]

On Thursday 2016-01-07 10:14 -0800, Richard Barnes wrote:
> Obviously, given the earlier FIDO thread here, I think this is good work to
> support.
> 
> I think the charter is in pretty good shape.  The only comment I have is
> that it talks about "attestations" without defining what is being attested.
> This could be addressed with the following change:
> 
> OLD:  "Attestation and signature formats defined for interoperability."
> NEW: "Formats for signed data and verifiable attestations of a signer's
> properties."

OK, I'll plan to submit a vote in support, with the above comment as
a suggested (but not formal objection) change.

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: Proposed W3C Charter: Web Authentication Working Group

[L. David Baron]

On Saturday 2016-01-09 07:22 +1100, L. David Baron wrote:
> On Thursday 2016-01-07 10:14 -0800, Richard Barnes wrote:
> > Obviously, given the earlier FIDO thread here, I think this is good work to
> > support.
> > 
> > I think the charter is in pretty good shape.  The only comment I have is
> > that it talks about "attestations" without defining what is being attested.
> > This could be addressed with the following change:
> > 
> > OLD:  "Attestation and signature formats defined for interoperability."
> > NEW: "Formats for signed data and verifiable attestations of a signer's
> > properties."
> 
> OK, I'll plan to submit a vote in support, with the above comment as
> a suggested (but not formal objection) change.

(And this response is modifiable until the deadline for comments.)

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
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

[David Rajchenbach-Teller]

I also think that this makes sense. Can we already start thinking about
countermeasures, though?

It looks to me that catching a long-running/infinite microtask loop is
much easier to detect and interrupt than a long-running sequential loop.
However, if we wish to pause a page with such a microtask loop to
display some UX, trigger a breakpoint or even to leave some CPU to other
pages in the same process, is there anything specific we need to do to
guarantee that no network/user input/layout/apz... can be processed
during the interrupt?

Cheers,
 David

On 14/01/16 00:35, Ehsan Akhgari wrote:
> I think this makes sense.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebKitCSSMatrix

[L. David Baron]

On Thursday 2016-01-14 14:06 -0800, William Chen wrote:
> *Summary*: WebKitCSSMatrix has been available for years in WebKit based
> browsers and has seen widespread usage on the web. This feature is
> currently available in Chrome, Safari and Edge. Mike Taylor has been
> working on standardizing the feature and it is being implemented in Gecko
> to improve web compatibility.
> 
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=717722
> 
> *Link to standard*:
> https://compat.spec.whatwg.org/#webkitcssmatrix-interface
> <https://compat.spec.whatwg.org/#dom-window-orientation>
> 
> *Platform coverage*: All platforms.
> 
> *Estimated or target release*: Firefox 46

It seems to me this is important to have behind a preference that is
specific to new webkit-prefixed features, given the compatibility
risks of shipping support for some but not all webkit-prefixed
features.

(It's possible it could be the same preference as other new
webkit-prefixed CSS features.)

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: You can now run specific tasks in an xpcshell test using add_task.only / add_test.only

[David Rajchenbach-Teller]

Fwiw, I used to perform a search-replace `add_task` => `/*add_task*/` to
deactivate everything, then uncomment individual tasks.

Of course, your solution looks cleaner, especially if it can be made to
work via mach.

Cheers,
 David

On 19/01/16 13:39, Philipp Kewisch wrote:
> Hi Folks,
> 
> I have just recently pushed bug 1192533, which will allow more fine
> grained debugging in xpcshell tests. I often had the problem that only a
> single task within a test was failing. Running the test over and over
> again took longer because all the other tasks had to run. I wished we
> could use .only() and .skip() as you may know from mocha tests.
> 
> Well, now you can! It currently requires editing the file instead of
> running via a mach parameter, but since you are fixing an issue you'll
> be editing the file anyway.
> 
> Before:
> 
> add_task(function* my_test() {
> // the failing task.
> // ...
> });
> 
> add_test(function my_async_test() {
> // a working test.
> // ...
> run_next_test();
> });
> 
> After:
> 
> add_task.only(function* my_test() {
>// the failing task, ready to debug
> });
> 
> add_test.skip(function my_async_test() {
> // a working test.
> // ...
> run_next_test();
> });
> 
> Then run the test as usual, no extra parameters.
> 
> Don't forget to remove the .only/.skip when you are done. With a little
> extra effort this could be changed to pass the task name via mach, I've
> made a suggestion how to do this in the bug comment 3.
> 
> Philipp
> ___
> 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: Just Autoland It

[David Rajchenbach-Teller]

That sounds like it's going to break stuff.

Reviewers frequently ask me to change stuff during reviews. I don't
re-run all the tests on all the platforms after every single round of
review. Once in a while, the changes end up breaking stuff which I need
to fix – generally trivial stuff that I can fix without requesting an
additional review.

Also, I frequently ask for review without having run all the tests on
all the platforms. Every so often, I get r+ and only then realize that
it doesn't build under Windows, or it breaks an entirely unrelated test.

In either case, if the reviewer takes the habit to land my patches
without asking me,  we'll end up with much more breakage.

Cheers,
 David

On 22/01/16 03:35, Gregory Szorc wrote:
> If you have level 3 source code access (can push to central, inbound,
> fx-team) and have pushed to MozReview via SSH, as of a few weeks ago you
> can now land commits from the "Automation" drop down menu on MozReview.
> (Before only the review request author could trigger autoland.)
> 
> This means that anyone [with permissions] can land commits with a few
> mouse clicks! It will even rewrite commit messages with "r=" annotations
> with the review state in MozReview. So if someone does a drive-by
> review, you don't have to update the commit message to reflect that
> reviewer. Neato!
> 
> I've gotten into the habit of just landing things if I r+ them and I
> think they are ready to land. This has startled a few people because it
> is a major role reversal of how we've done things for years. (Typically
> we require the patch submitter to do the landing.) But I think
> reviewer-initiated landing is a better approach: code review is a gate
> keeping function so code reviewers should control what goes through the
> gate (as opposed to patch authors [with push access] letting themselves
> through or sheriffs providing a support role for people without push
> access). If nothing else, having the reviewer land things saves time:
> the ready-to-land commit isn't exposed to bit rot and automation results
> are available sooner.
> 
> One downside to autoland is that the rebase will happen remotely and
> your local commits may linger forever. But both Mercurial and Git are
> smart enough to delete the commits when they turn into no-ops on rebase.
> We also have bug 1237778 open for autoland to produce obsolscence
> markers so Mercurial will hide the original changesets when you pull
> down the rebased versions. There is also potential for some Mercurial or
> Git command magic to reconcile the state of MozReview with your local
> repo and delete local commits that have been landed. This is a bit
> annoying. But after having it happen to me a few times, I think this is
> a minor annoyance compared to the overhead of pulling, rebasing,
> rewriting commit messages, and pushing locally, possibly hours or days
> after review was granted.
> 
> I encourage my fellow reviewers to join me and "just autoland it" when
> granting review on MozReview.
> 
> gps
> 
> 
> ___
> 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: Just Autoland It

[L. David Baron]

On Monday 2016-01-25 11:35 -0500, Mike Conley wrote:
> Just be sure to file them. Having talked to the MozReview team about these
> types of bugs, I do know that trust-worthiness of diffs and interdiffs is
> very much a thing that we should be able to take for granted. Any bugs in
> diff and interdiff trust-worthiness are high-priority to fix.

It's not clear to me that making trustworthy interdiffs across
rebases is a thing that can be done given the current UI for showing
diffs, since it's not clear to me that it shows enough information.

I regularly do diffs of diffs (producing double-diffs that have two
columns of +/-/ before the code rather than one), and I've
gotten used to reading them.  It's not clear to me how to explain
interdiffs in a reliable and trustworthy way without that much
metadata about the changes.

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Making it easier to file performance bugs?

[David Rajchenbach-Teller]

So, complaints about the performance of Firefox are a pretty common
topic. Performance bugs, on the other hand, are quite rare and/or lost
in noise, even when they are submitted by advanced users. While
Telemetry gives us have hard numbers on performance, intuition suggests
that we are lacking data on the operations and websites that *feel* slow.

I believe that one of the problems is that, to file a performance bug,
users need to attach it to a precise component, which results in people
giving up and/or attaching it randomly.

One possible solution would be to:
- add a component Firefox > Performance (and also Thunderbird >
Performance, etc.) to Bugzilla, which would cover all untriaged
performance issues (including web content, ux, e10s, ...);
- have people triaging these issues to likely features involved.

What do you think?

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

Re: Making it easier to file performance bugs?

[David Rajchenbach-Teller]

Well, before you can file a perf-keyword bug, you still need to
1/ find a product/component in which to file it (which is the original
issue);
2/ know that keywords in general exist, and this keyword in particular;
3/ (I believe) have editbugs rights.

That's a pretty big list.

Cheers,
 David

On 13/02/16 21:13, Matthew N. wrote:
> Note that we already have the "perf" keyword that can be filtered on
> and  https://bugzilla.mozilla.org/show_bug.cgi?id=1050252 was filed to
> add a checkbox to the guided bug form to easily add this keyword to
> new bugs. I see that keyword still used regularly by regular
> contributors.
> 
> Have you considered using bugzilla whine emails to receive a list of
> all new bugs with that keyword. You could narrow it down to the
> "Untriaged" component(s) if you wish.
> 
> Cheers,
> Matthew N. (:MattN)
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Making it easier to file performance bugs?

[David Rajchenbach-Teller]

My bad, I misread bug 1050252.

You are right, that is basically a different implementation of the same
general idea.

Thanks for the pointer,
 David


On 13/02/16 21:39, Matthew N. wrote:
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[L. David Baron]

On Sunday 2016-02-14 21:26 -0800, Kyle Huey wrote:
> 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.

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?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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