[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

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

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

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

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

Re: Intent To Ship: backdrop-filter

[L. David Baron]

On Friday 2020-05-29 12:50 -0700, Erik Nordin wrote:
> Intent:
> 
> As of Nightly 79 (shipping in release 7/28) I intend to turn
> backdrop-filter on by default for all systems on which WebRender is enabled.
> 
> Here is a list of systems and their current status with regard to shipping
> WebRender:
> 
> https://wiki.mozilla.org/Platform/GFX/WebRender_Where
...
> More Information:
> 
> The backdrop-filter pref will be set to true on all systems, but
> backdrop-filter’s functionality will not be available unless WebRender is
> also enabled and available.
> 
> Developers can check for backdrop-filter’s availability via CSS.supports()
> or @supports. Developers can still explicitly turn off backdrop-filter by
> disabling its pref in about:config.
> 
> If WebRender were to crash and become unavailable, backdrop-filter will
> also become unavailable. Subsequent calls to CSS.supports() will reflect
> this change, as will subsequent parses of CSS StyleSheets that use @supports
> rules.
> 
> Note, however, that any backdrop-filter-related information that was
> collected prior to this event may now be incorrect until the page is
> refreshed.

It's worth calling out here that shipping platform features for only
some of our graphics backends is something new for us.  (It's
possible we've done it in the past, but I'm not aware of us doing it
*intentionally*.)

It's also something that I think we shouldn't be doing, at least not
without a clear and relatively short timeline for having the feature
available across all graphics backends (whether by implementing it
for more backends or by no longer shipping those backends).

I think it's bad for the following reasons:

  1. It makes the idea of targeting and testing on Firefox more
  complicated for Web developers.  We're at risk of being ignored by
  Web developers; being a more complicated and fragmented target
  increases that risk, especially for the smaller fragment(s), and
  also makes Web developers dislike us for creating more complexity
  for them.

  2. We risk creating Web compatibility problems for our own users.
  While shipping the feature to some of our users will probably
  reduce web compatibility problems for that subset of users, it
  will also probably *increase* Web compatibility problems for the
  remaining users, since many developers who *do* care about testing
  on Firefox may produce content that's broken for those users.

(I'd note that I've expressed this concern to Erik, Sean, and others
in the past, but also encouraged them to send this intent because I
think this should be a broader discussion.)

-David

-- 
턞   L. David Baronhttps://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)
___
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

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

Handing off W3C Advisory Committee duties

[L. David Baron]

For quite a while, I've been posting reviews of proposed W3C
charters and W3C Proposed Recommendations to this list, as part of
being Mozilla's representative to the W3C Advisory Committee, which
really means the person who expresses official Mozilla positions on
things to W3C, and designates Mozilla representatives to working
groups, who can then represent Mozilla in the discussions within
working groups.

I've just handed off the responsibility of being the Advisory
Committee Representative to Tantek Çelik, so in the future you
should expect to see those reviews coming from him rather than from
me.

(On a side note, it's also not clear to me that dev-platform is
really the best way to have those discussions today; it's possible
we should look for an alternative forum that lends itself a bit more
to discussion.)

-David

-- 
턞   L. David Baronhttps://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)
___
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-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

[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

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

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

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

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

Proposed W3C Charter: Immersive Web Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Immersive Web Working Group
  https://www.w3.org/2020/03/proposed-immersive-web-wg-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2020Mar/0005.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2018%2F09%2Fimmersive-web-wg-charter.html=https%3A%2F%2Fwww.w3.org%2F2020%2F03%2Fproposed-immersive-web-wg-charter.html

Mozilla has the opportunity to send comments or objections through
Monday, April 6.

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

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

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

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

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

Proposed W3C Charter: WebAssembly Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  WebAssembly Working Group
  https://www.w3.org/2020/01/wasm-wg-charter-2020-proposed.html
  https://lists.w3.org/Archives/Public/public-new-work/2020Jan/0003.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F08%2Fwasm-charter=https%3A%2F%2Fwww.w3.org%2F2020%2F01%2Fwasm-wg-charter-2020-proposed.html

Mozilla has the opportunity to send comments or objections through
Thursday, February 13.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.  (We should probably say something, even if
it's just support, given our involvement.)

-David

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

Proposed W3C Charter: Audio Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Audio Working Group
  https://www.w3.org/2011/audio/charter/audio-2019-ac.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Dec/0012.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2011%2Faudio%2Fcharter%2Faudio-2016.html=https%3A%2F%2Fwww.w3.org%2F2011%2Faudio%2Fcharter%2Faudio-2019-ac.html

The main difference appears to be the addition of the Audio Device
Client specification to the charter:
https://github.com/WebAudio/web-audio-cg/blob/master/audio-device-client/explainer.md

Mozilla has the opportunity to send comments or objections through
Monday, January 27 (but I would prefer to submit any comments this
week or next).

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.  (We should probably say something, even if
it's just support.)

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

Proposed W3C Charter: Web Payments Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web Payments Working Group
  https://www.w3.org/Payments/WG/charter-201910.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0003.html

The differences from the previous charter are:
  
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FPayments%2FWG%2Fcharter-201803.html=https%3A%2F%2Fwww.w3.org%2FPayments%2FWG%2Fcharter-201910.html

Mozilla has the opportunity to send comments or objections through
Friday, December 13.

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


(My one note so far is that the charter should link to the previous
charter; it currently only links to the charter before that.)

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

Proposed W3C Charter: Web of Things Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web of Things Working Group
  https://www.w3.org/2019/11/proposed-wot-wg-charter-2019.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0005.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F12%2Fwot-wg-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F11%2Fproposed-wot-wg-charter-2019.html

Mozilla has the opportunity to send comments or objections through
Tuesday, December 17.

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

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

Proposed W3C Charter: Second Screen Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Second Screen Working Group
  https://w3c.github.io/secondscreen-charter/
  https://lists.w3.org/Archives/Public/public-new-work/2019Nov/.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%2Fsecondscreen%2Fcharter-2018.html=https%3A%2F%2Fw3c.github.io%2Fsecondscreen-charter%2F

Mozilla has the opportunity to send comments or objections through
Friday, December 6.

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


I'm inclined to be supportive of this charter.  In the past we've
encouraged this group to have a standard protocol rather than
building an API that wraps proprietary APIs (such as Google Cast or
AirPlay); this charter appears to move significantly in that
direction relative to the previous charter.  That said, I don't
think anybody from Mozilla is currently participating in this work,
and I haven't looked into the current approach in much detail.

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

Proposed W3C Charter: Service Workers Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Service Workers Working Group
  https://www.w3.org/2019/11/proposed-sw-wg-charter-2019.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0004.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F08%2Fsw-charter=https%3A%2F%2Fwww.w3.org%2F2019%2F11%2Fproposed-sw-wg-charter-2019.html

Mozilla has the opportunity to send comments or objections through
Tuesday, December 17.

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


(I think we may want to comment on Background Synchronization (which
was also in the previous charter, but which we have concerns about
in [1] and [2]) and about Background Fetch (which is new to this
charter, and which I think we also have concerns about).)

-David

[1] https://github.com/mozilla/standards-positions/issues/173
[2] https://github.com/mozilla/standards-positions/issues/214

-- 
턞   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)
___
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

[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

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

Re: Intent to ship: CSS subgrid

[L. David Baron]

On Monday 2019-10-21 16:01 -0500, Mike Taylor wrote:
> Hi David,
> 
> On 10/21/19 7:22 AM, L. David Baron wrote:
> > (That we haven't applied the policy that much because we've granted
> > exceptions because other browsers have shipped the features reduces
> > the effectiveness of the policy and its ability to meet its goals.
> > This is the sort of policy that is most effective if it applies to
> > the largest number of thngs, both because it has larger effects and
> > because it sets much clearer expectations about what will be limited
> > to secure contexts.  I think it's worth considering reducing that
> > exception to the existence of actual web compat problems from the
> > secure contexts limitation.)
> 
> Can you unpack this a little here?
> 
> Are we saying we would ship features in non-secure contexts because sites
> theoretically rely on that behavior due to another browser shipping as
> non-secure before we did? (This sounds like the current rationale for
> exceptions, I think).
> 
> Or are we saying we would ship a feature by default as secure and be willing
> (compelled?) to move to non-secure if we discover sites rely on other
> significant market share browsers not requiring a secure context for said
> feature -- once our users reported the bugs (or we did some kind of analysis
> beforehand)?

I'm saying that we've been doing what you describe in the first
paragraph but maybe we need to shift to what you describe in the
second paragraph in order for the policy on secure contexts to be
effective.

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

Re: Intent to ship: CSS subgrid

[L. David Baron]

contexts,
  then it must be limited to secure contexts,
  even if the other factors above suggest it doesn't need to be.
  For example, a feature that communicates with USB devices
  if those devices have allowed
  Web content from the site's origin
  to communicate with those USB devices
  depends on the authentication of the origin
  and the integrity of the data
  sent to the USB device,
  since sending untrusted data to a USB device could damage that device
  or compromise computers that the device connects to.
  
  Specification authors can limit most features defined in
  https://heycam.github.io/webidl/;>WebIDL,
  to secure contexts
  by using the
  [https://w3c.github.io/webappsec-secure-contexts/#integration-idl;>SecureContext]
 extended attribute
  on interfaces, namespaces, or their members (such as methods and attributes).
  Similar ways of marking features as limited to secure contexts should be added
  to other major points where the Web platform is extended over time
  (for example, the definition of a new CSS property).
  However, for some types of extension points (e.g., dispatching an event),
  limitation to secure contexts should just
  be defined in normative prose in the specification.



Specifically on the question of subgrid, I think the strongest
reason *not* to limit subgrid to secure contexts is one that Sean
and Cameron already referred to -- that it is a feature designed to
mitigate a key problem with the grid feature that we and other
browsers have already shipped.  In particular, needing to support
grid implementations that do not support subgrid encourages
developers to remove elements from their markup in order to match
the grid model.  This can harm anything that depends on the
existence of those removed elements or that depends on the
availability of the semantics that would have been in those removed
elements, including accessibility and including interventions that
we make on behalf of the user (many of which depend on the identity
of objects in the DOM).  So limiting subgrid to secure contexts
while grid is available in insecure contexts would perpetuate these
problems.

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

W3C Proposed Recommendations: WebAssembly

[L. David Baron]

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

  WebAssembly Core Specification
  https://www.w3.org/TR/wasm-core-1/
  https://webassembly.github.io/spec/core/bikeshed/

  WebAssembly JavaScript Interface
  https://www.w3.org/TR/wasm-js-api-1/
  https://webassembly.github.io/spec/js-api/

  WebAssembly Web API
  https://www.w3.org/TR/wasm-web-api-1/
  https://webassembly.github.io/spec/web-api/

  Deadline for responses: Sunday, October 27, 2019

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

I think we should probably explicitly support these specifications
given our involvement.

-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)
___
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: What to do about scroll anchoring?

[L. David Baron]

On Sunday 2019-09-29 10:54 +1000, Cameron McCormack wrote:
> How useful is scroll anchoring outside of the two cases mentioned in 
> https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and 
> ad iframes being inserted?  Would it be feasible to make scroll anchoring a 
> much less general mechanism, and to scope it down to handling these specific 
> cases?

I think it's also quite useful for horizontal resizes of the browser
window (which can include device rotation on mobile, window
resizing/maximization on desktop, and also hiding/showing of browser
sidebar UI).

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

Re: What to do about scroll anchoring?

[L. David Baron]

On Friday 2019-09-27 14:23 +0200, Emilio Cobos Álvarez wrote:
> Does anyone have strong opinions against removing scroll anchoring from
> Gecko, based on the above?

It seems pretty sad, since I think it's a very useful feature for a
large class of pages -- particularly pages that are more "documents"
than "applications".

I wonder if it would be possible to disable the feature under
certain conditions, for example:
 * the page uses APIs that initiate scrolling from script, or
 * the page has handlers for scroll events, or
 * the page does both of the above
but leave the feature enabled for pages that don't do these things.

Based on what I've heard it seems like many of the cases where pages
are really broken involve some of those, although I haven't gone
through the bug lists.

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

Proposed W3C Charter: Web of Things Interest Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web of Things Interest Group
  https://www.w3.org/2019/07/wot-ig-2019.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Sep/0008.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F07%2Fwot-ig-charter.html=https%3A%2F%2Fwww.w3.org%2F2019%2F07%2Fwot-ig-2019.html

Mozilla has the opportunity to send comments or objections through
Friday, October 11.

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

-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)
___
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 revised charter for:

  Web Authentication Working Group
  https://www.w3.org/2019/08/webauthn-proposed-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Sep/0001.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F08%2Fweb-authentication-charter.html=https%3A%2F%2Fwww.w3.org%2F2019%2F08%2Fwebauthn-proposed-charter.html

Mozilla has the opportunity to send comments or objections through
Monday, September 30.

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

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

Proposed W3C Charter: CSS Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Cascading Style Sheets (CSS) Working Group
  https://www.w3.org/2019/08/proposed-css-2019.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Aug/0015.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FStyle%2F2016%2Fcss-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F08%2Fproposed-css-2019.html

Mozilla has the opportunity to send comments or objections through
Sunday, September 22.  (Sorry for delaying sending this for so
long!)

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

-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)
___
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: 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: 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: Proposed W3C Charter: Timed Text (TT) Working Group

[L. David Baron]

On Thursday 2019-08-29 13:23 -0500, Adam Roach wrote:
> Most of the deltas range from editorial to general good hygiene. The only
> changes of any real consequence that I see are:
> 
>  * Updating their previous work to new versions
>  * Charter item to work on a profile of TTML2 to support audio-only use
>cases
>  * Catch-all clause at the bottom of §2.1 that grants the WG carte
>blanche to work on any random thing they want
> 
> Having little background in this technology, I'm pretty ambivalent about the
> first two changes. I think we should object to the third change: charters
> serve both the guide work and limit scope, and this clause removes all scope
> limitations.

I would read that catch-all clause differently; I think it's
somewhat common in W3C charters, particularly for groups that have
existed for a while.  I don't think it allows the group to develop
specifications outside of their scope; it simply allows them to work
on deliverables *within their scope* that are other than the three
listed (for example, if they want to split a piece off of one of
them because they decide it belongs in a separate spec).

So I don't think it's grounds for an objection.

(I also think that if we haven't actually reviewed the charters from
a technical level of what we think should be happening, then it
might be better to *not* reply, to avoid suggesting that we have
done so.)

-David

> On 8/28/19 5:41 PM, L. David Baron wrote:
> > The W3C is proposing a revised charter for:
> > 
> >Timed Text (TT) Working Group
> >https://www.w3.org/2019/08/ttwg-proposed-charter.html
> >https://lists.w3.org/Archives/Public/public-new-work/2019Aug/0004.html
> > 
> > The comparison to the group's previous charter is:
> >
> > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2018%2F05%2Ftimed-text-charter.html=https%3A%2F%2Fwww.w3.org%2F2019%2F08%2Fttwg-proposed-charter.html
> > 
> > Mozilla has the opportunity to send comments or objections through
> > Tuesday, September 10.
> > 
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review, or if you think we should
> > support or oppose it.
> > 
> > -David
> > 
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: Proposed W3C Charter: Timed Text (TT) Working Group

[L. David Baron]

On Thursday 2019-08-29 13:44 +0300, Henri Sivonen wrote:
> On Thu, Aug 29, 2019 at 1:41 AM L. David Baron  wrote:
> >
> > The W3C is proposing a revised charter for:
> >
> >   Timed Text (TT) Working Group
> >   https://www.w3.org/2019/08/ttwg-proposed-charter.html
> >   https://lists.w3.org/Archives/Public/public-new-work/2019Aug/0004.html
> >
> > The comparison to the group's previous charter is:
> >   
> > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2018%2F05%2Ftimed-text-charter.html=https%3A%2F%2Fwww.w3.org%2F2019%2F08%2Fttwg-proposed-charter.html
> 
> What should one read to understand what perceived need there is for
> further development on TTML and WebVTT? (That is, what's currently
> missing such that these aren't considered "done"?)

I don't know if there's any document specifically covering this.  I
suspect it requires digging in to the group's mailing list at
https://lists.w3.org/Archives/Public/public-tt/ and their github
repositories listed at
https://www.w3.org/AudioVideo/TT/#recent-activity .

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

Re: Intent to ship: |clip-path: path()|

[L. David Baron]

On Saturday 2019-08-31 09:21 -0700, sime.vi...@gmail.com wrote:
> Is this a non-standard feature? I don’t see it in the spec: 
> https://drafts.fxtf.org/css-masking-1/#the-clip-path.

Some of the links for  don't seem to point to the best
targets, but it's defined in:

https://drafts.csswg.org/css-shapes-2/#supported-basic-shapes

which is currently a delta on top of:

https://drafts.csswg.org/css-shapes-1/#supported-basic-shapes

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

Re: Proposed W3C Charter: Decentralized Identifier (DID) Working Group

[L. David Baron]

I think the reason not to formally object is that it leads to
expenditure of both effort and political capital in a way that seems
unlikely to change the result.  It's an expenditure of effort
because the goal is that the AC operate by consensus, so the initial
result of formal objections is always discussions about what sort of
compromise would allow objectors to withdraw their objections.  And
given the number of current supporters of the work, I think any
director's decision that happens if there isn't consensus would
likely be in favor of chartering the work.

-David

On Thursday 2019-08-29 13:09 -0700, Eric Rescorla wrote:
> I tend to agree with you. Is there a reason not to formally object?
> 
> On Wed, Aug 28, 2019 at 3:30 PM L. David Baron  wrote:
> 
> > The W3C is proposing a new charter for:
> >
> >   Decentralized Identifier (DID) Working Group
> >   https://www.w3.org/2019/08/did-wg-charter.html
> >   https://lists.w3.org/Archives/Public/public-new-work/2019Aug/.html
> >
> > Mozilla has the opportunity to send comments or objections through
> > this Saturday, August 31.
> >
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review, or if you think we should
> > support or oppose it.
> >
> >
> > I'm pretty concerned that this group isn't a good use of W3C's
> > resources, and that the promoters of this work and related areas of
> > work have convinced various parties (e.g., government agencies like
> > [1]) that this work is valuable, partly through the use of the W3C's
> > reputation to promote this work.
> >
> > (I also feel like, while it's called decentralized, in practice it
> > seems to require more centralization than the Web, which allows
> > anyone to register a domain and then mint URLs.  I'm also skeptical
> > of the privacy claims made in the groups charter.)
> >
> > That said, I think it's probably going to happen anyway no matter
> > what we say, so I'm not sure what, if anything, to say in the
> > review.  I'd probably be inclined to explicitly abstain from the
> > review and add brief comments to that abstention.
> >
> > -David
> >
> > [1] https://lists.w3.org/Archives/Public/public-new-work/2019Aug/0013.html
> >
> > --
> > 턞   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)
> > ___
> > 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

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

Proposed W3C Charter: Cascading Style Sheets (CSS) Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Cascading Style Sheets (CSS) Working Group
  https://www.w3.org/2019/08/proposed-css-2019.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Aug/0015.html

The comparison to the group's previous charter is:
  
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FStyle%2F2016%2Fcss-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F08%2Fproposed-css-2019.html

Mozilla has the opportunity to send comments or objections through
Sunday, September 22.

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

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

Proposed W3C Charter: Timed Text (TT) Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Timed Text (TT) Working Group
  https://www.w3.org/2019/08/ttwg-proposed-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Aug/0004.html

The comparison to the group's previous charter is:
  
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2018%2F05%2Ftimed-text-charter.html=https%3A%2F%2Fwww.w3.org%2F2019%2F08%2Fttwg-proposed-charter.html

Mozilla has the opportunity to send comments or objections through
Tuesday, September 10.

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

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

Proposed W3C Charter: Decentralized Identifier (DID) Working Group

[L. David Baron]

The W3C is proposing a new charter for:

  Decentralized Identifier (DID) Working Group
  https://www.w3.org/2019/08/did-wg-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Aug/.html

Mozilla has the opportunity to send comments or objections through
this Saturday, August 31.

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


I'm pretty concerned that this group isn't a good use of W3C's
resources, and that the promoters of this work and related areas of
work have convinced various parties (e.g., government agencies like
[1]) that this work is valuable, partly through the use of the W3C's
reputation to promote this work.

(I also feel like, while it's called decentralized, in practice it
seems to require more centralization than the Web, which allows
anyone to register a domain and then mint URLs.  I'm also skeptical
of the privacy claims made in the groups charter.)

That said, I think it's probably going to happen anyway no matter
what we say, so I'm not sure what, if anything, to say in the
review.  I'd probably be inclined to explicitly abstain from the
review and add brief comments to that abstention.

-David

[1] https://lists.w3.org/Archives/Public/public-new-work/2019Aug/0013.html

-- 
턞   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)
___
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: 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

Proposed W3C Charter: Privacy Interest Group

[L. David Baron]

The W3C is proposing a new charter for:

  Privacy Interest Group (PING)
  https://w3cping.github.io/administrivia/charter-draft.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Jun/0009.html

Mozilla has the opportunity to send comments or objections through
Sunday, August 4.  (Sorry for delaying sending this for so long!)

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

-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)
___
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: 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 Implement: CSS backdrop-filter

[L. David Baron]

On Thursday 2019-07-11 10:59 -0400, Jeff Muizelaar wrote:
> On Thu, Jul 11, 2019 at 10:46 AM Emilio Cobos Álvarez  
> wrote:
> > On 7/10/19 11:01 PM, Connor Brewster wrote:
> > > Hi David,
> > >
> > >> It's not clear to me what this option means in terms of what you're
> > >> proposing to implement and ship.  @supports is a feature that web
> > >> developers can use -- and it should clearly match whether the
> > >> feature is supported.  However, I think what you're suggesting here
> > >> is that you might ship the feature only when WebRender is enabled --
> > >> I think that's something that requires further discussion, given the
> > >> confusion it would cause in the web development world.  It also
> > >> seems (?) like you're suggesting something else about limiting which
> > >> filters are usable to only those that have a GPU implementation in
> > >> WebRender -- but it's not clear to me if that's for backdrop-filter
> > >> only, or also for the filter property -- when WebRender is enabled.
> > >
> > > The idea here is that @supports would reflect whether or not
> > > backdrop-filter and WebRender are enabled. This would allow web
> > > authors to add a fallback style if needed. I do agree that this would
> > > cause some confusion and needs more discussion.
> >
> > This seems pretty hard to do right / pretty awkward. @supports must
> > reflect whether the property parses. Not enabling the property if
> > webrender is not enabled seems hacky, but doable.
> >
> > But if you have WebRender enabled and your GPU process crashes, going
> > all the way back to the style system to invalidate everything doesn't
> > seem trivial / worth the effort. It seems pretty hard actually.
> 
> I feel like having the wrong results from @supports in this case is
> probably acceptable.
> I suspect background-filter is rarely used in ways that lying in
> @supports causes a website to become unusable.
> 
> I see disabling it in @supports as sort a best effort kind of thing as
> opposed to needing to be perfect.

I don't think having a CSS feature that stops working if the GPU
process crashes is acceptable.  It's not a coherent story to web
developers, and it means that once sites start relying on the
feature (which they'll think they can do because it looks like it
works), pages will be broken for some portion of our users.

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

Re: Intent to Implement: CSS backdrop-filter

[L. David Baron]

On Monday 2019-07-08 15:21 -0700, Connor Brewster wrote:
> Hi Ehsan,
> 
> Currently, the plan is to develop this feature behind a pref flag that will
> be off by default. We haven't decided the best way forward for enabling
> this feature by default yet. We have two possible options:
>  1. Add backdrop filter support to the other render backends.

This seems like a reasonable option.

>  2. Rely on an @supports media query to determine if backdrop-filter is
> supported (this would check for the backdrop-filter pref flag and check if
> WebRender is enabled). If we choose this route, we need to remove any
> dynamic fallbacks to the software renderer that may occur when using
> backdrop-filter. Currently WebRender does not support all SVG filters, so
> these would need to be fully implemented for this approach to work.

It's not clear to me what this option means in terms of what you're
proposing to implement and ship.  @supports is a feature that web
developers can use -- and it should clearly match whether the
feature is supported.  However, I think what you're suggesting here
is that you might ship the feature only when WebRender is enabled --
I think that's something that requires further discussion, given the
confusion it would cause in the web development world.  It also
seems (?) like you're suggesting something else about limiting which
filters are usable to only those that have a GPU implementation in
WebRender -- but it's not clear to me if that's for backdrop-filter
only, or also for the filter property -- when WebRender is enabled.

-David

> 
> >  * Do we have other web-exposed features that are only supported when
> WebRender is enabled?
> 
> I don't believe we have any other web-exposed features only supported by
> WebRender at the moment.
> 
> > * How do we plan to communicate to web developers (who may not
> necessarily know/care what WebRender is) where this feature is usable?
> 
> This is a good thing to keep in mind when determining the right approach.
> If we decide to implement backdrop-filter on all backends, this won't be an
> issue; otherwise, if we go with approach 2, we would need to tell web
> developers to rely on the @supports media query.
> 
> > * What happens to the DevTools integration a) when WebRender is disabled
> on the target Firefox instance, and b) when WebRender is disabled on the
> target Firefox instance but enabled on the host instance (e.g. when
> debugging Fennec on Windows with the right NVIDIA GPU driver).
> 
> Currently, DevTools only checks if the backdrop-filter pref is enabled and
> doesn't check if WebRender is enabled. If we decide on approach 2, we would
> need to check for the cases that you mentioned.
> 
> Thanks,
> Connor
> 
> 
> On Fri, Jul 5, 2019 at 7:23 AM Ehsan Akhgari 
> wrote:
> 
> > On Mon, Jul 1, 2019 at 8:54 PM Connor Brewster 
> > wrote:
> >
> >> Platform coverage: All platforms using the Gecko rendering engine
> >> (WebRender enabled only)
> >>
> >> Target release: Firefox 71 (WebRender enabled only)
> >>
> >> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060
> >>
> >
> > Hi Connor,
> >
> > Since this feature is only enabled based on WebRender being enabled, I
> > have a few questions for you:
> >
> > * Do we have other web-exposed features that are only supported when
> > WebRender is enabled?
> >
> > * How do we plan to communicate to web developers (who may not necessarily
> > know/care what WebRender is) where this feature is usable?
> >
> > * What happens to the DevTools integration a) when WebRender is disabled
> > on the target Firefox instance, and b) when WebRender is disabled on the
> > target Firefox instance but enabled on the host instance (e.g. when
> > debugging Fennec on Windows with the right NVIDIA GPU driver).
> >
> > Thanks,
> > --
> > Ehsan
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

-- 
턞   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)
___
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=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: 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: 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: 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]

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

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: Remove browser and OS architecture from Firefox's User-Agent string?

[L. David Baron]

On Monday 2019-05-13 16:14 -0700, Chris Peterson wrote:
> On 5/11/2019 4:11 AM, j.j. wrote:
> > > < "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101
> > > Firefox/66.0"
> > >   > "Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0"
> > Note that  "navigator.oscpu"  returns  "Windows NT 6.1; Win64; x64"  or 
> > similar. This needs to change then.
> > 
> 
> Yes. navigator.oscpu and the UA string share some common code, so they would
> both be fixed to match 32-bit Windows.

I think it might be worth considering letting them diverge.

I'm skeptical of the idea that we can remove the ability to detect
things like 32-bit versus 64-bit from the overall fingerprinting
surface.  It seems like these should be detectable through things
like performance characteristics, if not through behavior
differences (like a Math one you mentioned earlier in the thread).
Likewise for some of the other differences here -- although I'd be
interested to see an argument that we actually can prevent them from
being detected.

However, there's another distinction worth considering, which is
passive fingerprinting versus active fingerprinting.  The UA string
allows passive fingerprinting -- fingerprinting that isn't possible
to detect by looking at the HTML, CSS, and JS that was sent over the
wire.  The attack surface for passive fingerprinting is small enough
that it seems like something that we can reasonably work to reduce.
Given the set of APIs already on the web, it's not clear whether we
can prevent users from being identified through active
fingerprinting without breaking significant web functionality.

So I think there's may be value in removing these distinctions from
the User-Agent header we send over HTTP even if they're still
accessible from Javascript (and useful there for sites offering
downloads).

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

Re: Intent to ship: Visual Viewport API on Android

[David Burns]

Not yet as we are stabilising tests for gecko view but hopefully soon!

David
On May 10, 2019, 7:22 PM +0100, Botond Ballo , wrote:
> On Thu, May 9, 2019 at 7:50 AM David Burns  wrote:
> > There are a number of wpt that fail only in firefox. Are we planning on 
> > fixing those tests with this work?
>
> We are, at least on Android. (On desktop, some of the tests need
> desktop zooming, which we do not yet have, to pass.) A number of fixes
> have landed [1] yesterday.
>
> Is there a way to get a dashboard view similar to [2] with Android results?
>
> Thanks,
> Botond
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1477610
> [2] 
> https://jgraham.github.io/wptdash/?bugComponent=core%3A%3Alayout=%2Fvisual-viewport=Interop+Comparison
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Visual Viewport API on Android

[David Burns]

There are a number of wpt that fail only in firefox[1]. Are we planning on
fixing those tests with this work?

David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1546387

On Thu, 9 May 2019 at 01:41, Botond Ballo  wrote:

> Hi everyone!
>
> I would like to ship the Visual Viewport API [1] on Android. The
> initial implementation [2] was done in Firefox 63 behind the pref
> "dom.visualviewport.enabled" (see "Intent to Implement" thread [3]).
> It has since seen bug fixes, polish, and expanded test coverage.
>
> I intend to ship it on Android only for now. The API is primarily
> useful in scenarios involving pinch-zooming, and we don't currently
> support pinch-zooming on desktop. I intend to enable it on desktop
> concurrently with support for pinch-zooming at a later date.
>
> Target release: Firefox 68 or 69, depending on when the patches are
> ready. If it doesn't make 68, I would like to get it into Fennec
> 68.1esr, as it's an important web compat feature.
>
> Tracking bug for shipping:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1512813
>
> Status in other implementation:
>   Blink: Shipping since Chrome 61 [4]
>   Safari: Available in Preview version [5]
>
> Web platform tests: The feature has good WPT coverage, with a mix of
> automatic and manual tests. We are now [6] passing almost all tests on
> Android; of the two remaining failures, one is a test harness
> limitation [7], and the other is pending resolution of a spec issue
> [8]. There are also a couple of tests which are not applicable to
> Android because they involve reflowing zoom which Android does not
> support.
>
> Any thoughts / feedback is appreciated!
>
> Thanks,
> Botond
>
> [1] https://github.com/WICG/visual-viewport/
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1357785
> [3]
> https://groups.google.com/d/topic/mozilla.dev.platform/gchNtWfv_bk/discussion
> [4] https://www.chromestatus.com/feature/5737866978131968
> [5] https://webkit.org/status/#feature-visual-viewport-api
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1477610
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1547827
> [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1543485
> ___
> 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

Unplanned Phabricator Update - Thursday May 2nd 2019 between 14:00 and 15:00 UTC

[David Lawrence]

Due to issue discovered with the last update, we will be
deploying a Phabricator [1] update to fix the issue on Thursday
May 2nd 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

Proposed W3C Charter: HTML Working Group

[L. David Baron]

The W3C is proposing a new charter for:

  HTML Working Group
  https://www.w3.org/2018/12/html.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Apr/0004.html

Mozilla has the opportunity to send comments or objections through
this Friday, May 3.

There's a bit of background to this charter, related to the recent
history of HTML being developed at both the WHATWG and (based on
forks of the WHATWG spec) at the W3C.  This charter is a major piece
of the implementation of a draft Memorandum of Understanding (MoU):
  https://www.w3.org/2019/04/WHATWG-W3C-MOU.html
between the WHATWG and W3C that's designed to end this split.

The major points of this MoU are:

 * W3C will no longer publish specifications that are forks of
   WHATWG specifications.

 * For the HTML and DOM specifications specifically (not others),
   W3C will have a process that leads to WHATWG Review Drafts
   also becoming W3C Recommendations (by marking the W3C status in
   the document hosted on WHATWG servers).

 * The HTML working group (whose charter is being proposed here)
   will exist both to run this process (since W3C requires a Working
   Group to produce Recommendations) and to help contributors who
   have previously worked on the W3C side of this split contribute
   to the WHATWG specification.

 * There is a dispute resolution process if the W3C and WHATWG
   groups want different outcomes in the HTML and DOM specifications
   (i.e., if the W3C working group isn't happy to publish what the
   WHATWG has published).

This involves a bit of extra work, but the value is that we can
avoid the wasted effort, confusion, and fighting that resulted from
having two competing versions of the same specifications.


Please reply to this thread if you think there's something we should
say as part of this charter review.  Given my involvement in the
process that led to this charter being created, I strongly believe
we should support the charter, but it's entirely reasonable to give
specific feedback to improve the charter.

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

Unplanned Phabricator Update - April 30th 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 [1] update
to add new functionality tomorrow April 30th 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: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

[David Major]

On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley  wrote:
>
> Thanks Mike!
>
> So Fennec is the last remaining non-e10s configuration we ship to users.
> Given that Fennec test coverage is somewhat incomplete, we probably want to
> keep running desktop 1proc tests until Fennec EOL. We don't strictly need
> the browser-chrome tests, but we should probably avoid intentionally
> breaking non-e10s browser-chrome as long as engineers may still need to
> debug non-e10s test failures.
>
> After Fennec EOL, we basically have two options: a clean break where we rip
> out non-e10s support entirely, or a more muddled approach where we
> halfheartedly keep it working as a handy engineering hack as long as is
> practical. I think we should do the former.
>
> I don't want to downplay the handiness - being able to test and debug the
> browser in a single process can eliminate complexity and non-determinism,
> and save a lot of time. But at some point there's going to be a piece of
> core functionality that's too much work to keep supporting under non-e10s -
> and agonizing over that threshold on an ongoing basis is not a good use of
> anyone's time.

Why not have the conversation when such a piece of core functionality
arises? It's a much more convincing argument when you can say
"non-e10s needs to go away in order to support X".

In the meantime, single process debugging is a tremendous saver of
time and hassle, and we'd need a great reason to disable it. I'm not
convinced that one currently exists.

> Other opinions?
>
> On Tue, Apr 23, 2019 at 1:30 PM Mike Conley  wrote:
>
> > Hey folks,
> >
> > For Desktop, I don't believe there are any normal conditions under which
> > our users will have e10s disabled. [1] is where the decision gets made, and
> > it looks like these days, the only thing that will disable e10s is if the
> > user sets `browser.tabs.remote.autostart` to false themselves, or if a
> > MOZ_FORCE_DISABLE_E10S environment variable is set. I don't think either of
> > those are ever set by Mozilla these days.
> >
> > There was a case a few months back where e10s was disabled for users with
> > certain screen readers back for Firefox 60. Since that time, those screen
> > readers have updated to become more stable with e10s enabled.
> > Unfortunately, I don't have a reference to the bug(s) where that occurred,
> > but I spoke to yzen in #accessibility, and Firefox 60 ESR is the last
> > supported version where this e10s-disabling occurs on Desktop.
> >
> > So, to sum, I'm reasonably confident that, outside of Firefox 60 ESR,
> > e10s-disabled is not a mode that we ship to any of our users. We can
> > trigger it by pref flips or environment variables, but that's it.
> >
> > Mobile is another story - according to the fine folks in #mobile, Fennec
> > still runs Gecko in non-e10s mode.
> >
> > To circle back to Gijs's questions:
> >
> > 1. do we still consider running desktop Firefox with e10s disabled a
> >> supported configuration?
> >>
> >
> > Outside of Firefox 60 ESR, no, I don't believe so.
> >
> > 2. Will we need to turn it off on esr68 in the same circumstances where
> >> that happens on esr60?
> >>
> >
> > According to yzen from the Accessibility team, no, we won't.
> >
> > 3. If the answer to either of the previous 2 questions is 'yes', do we
> >> think it's acceptable not to run desktop tests on the configuration?
> >>
> >
> > Answers are no.
> >
> > 4. If the answer to both (1) and (2) is 'no', can we remove support for
> >> the pref and running desktop Firefox without e10s ? Some of the
> >> codepaths are not unified and so there is effectively dead code that
> >> we're lugging around for what would be no reason. (Note: a significant
> >> proportion isn't dead because even in e10s, we load some
> >> browser-provided content in parent process, ie a tab's browser is not
> >> always remote/non-same-process -- but even so, there's a bunch of stuff
> >> that keys off gMultiProcessBrowser that could be removed.)
> >>
> >
> > Yes, I believe that stuff is probably safe to remove at this point, as
> > long those changes don't assume e10s support on Fennec.
> >
> > -Mike
> >
> > [1]:
> > https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/toolkit/xre/nsAppRunner.cpp#4964-5002
> >
> > On Tue, 23 Apr 2019 at 13:35, Dave Townsend  wrote:
> >
> >> Is there still a configuration (ignoring hidden prefs) that can cause a
> >> user to end up using non-e10s? If so we should turn these tests back on.
> >>
> >> On Tue, Apr 23, 2019 at 8:25 AM Joel Maher  wrote:
> >>
> >> > Here is where we initially turned on non-e10s tests for win7:
> >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1391371
> >> >
> >> > and then moved to linux32:
> >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1433276
> >> >
> >> > Currently mochitest-chrome and mochitest-a11y run as 1proc in-tree-
> >> these
> >> > run this way as they do not work with e10s=true.  I suspect the
> >> > mochitest-chrome is by design and 

Re: Proposed W3C Charters: Internationalization (i18n) Working Group and Interest Group

[L. David Baron]

On Tuesday 2019-04-09 13:55 +0300, Henri Sivonen wrote:
> On Mon, Apr 8, 2019 at 11:32 PM L. David Baron  wrote:
> >
> > The W3C is proposing revised charters for:
> >
> >   Internationalization (i18n) Working Group
> >   https://www.w3.org/2019/04/proposed-i18n-wg-charter.html
> >   https://lists.w3.org/Archives/Public/public-new-work/2019Apr/0004.html
> >   diff from previous charter: 
> > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FInternational%2Fcore%2Fcharter-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F04%2Fproposed-i18n-wg-charter.html
> >
> >   Internationalization (i18n) Interest Group
> >   https://www.w3.org/2019/04/proposed-i18n-ig-charter.html
> >   https://lists.w3.org/Archives/Public/public-new-work/2019Apr/0004.html
> >   diff from previous charter: 
> > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FInternational%2Fig%2Fcharter-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F04%2Fproposed-i18n-ig-charter.html
> >
> > Mozilla has the opportunity to send comments or objections through
> > Friday, May 3.
> >
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review, or if you think we should
> > support or oppose it.  (Absent specific comments, I'd be inclined to
> > support the charters, because I think the i18n work at W3C has been
> > generally effective.)
> 
> Is the WG expected to continue to issue revisions to
> https://www.w3.org/TR/charmod-norm/ ? The document itself suggests
> sending comments via GitHub issues. I don't see a charter item that
> clearly covers the maintenance of this document. Should we ask for an
> item that ensures that the group is explicitly chartered to continue
> to maintain this document?

I expect the wording at the start of section 2.1 (Normative
Specifications) that says:

  The formal documents produced by the Working Group are guidelines,
  best practices, requirements, and the like. These are best
  published as Working Group Notes.

probably covers this.  Or does this document not fit within that
description?

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

Proposed W3C Charters: Internationalization (i18n) Working Group and Interest Group

[L. David Baron]

The W3C is proposing revised charters for:

  Internationalization (i18n) Working Group
  https://www.w3.org/2019/04/proposed-i18n-wg-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Apr/0004.html
  diff from previous charter: 
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FInternational%2Fcore%2Fcharter-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F04%2Fproposed-i18n-wg-charter.html

  Internationalization (i18n) Interest Group
  https://www.w3.org/2019/04/proposed-i18n-ig-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Apr/0004.html
  diff from previous charter: 
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FInternational%2Fig%2Fcharter-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F04%2Fproposed-i18n-ig-charter.html

Mozilla has the opportunity to send comments or objections through
Friday, May 3.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.  (Absent specific comments, I'd be inclined to
support the charters, because I think the i18n work at W3C has been
generally effective.)

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

Proposed W3C Charter: Media Working Group

[L. David Baron]

The W3C is proposing a new charter for:

  Media Working Group
  https://www.w3.org/2019/04/media-charter-draft.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Apr/0003.html

Mozilla has the opportunity to send comments or objections through
Friday, May 3.

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

Given that we implement a number of the specifications the group
will maintain, and are likely to implement others, we should almost
certainly express *some* opinion on this charter, even it is just
support.

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

Proposed W3C Charter: Web & Networks Interest Group

[L. David Baron]

The W3C is proposing a new charter for:

  Web & Networks Interest Group
  https://www.w3.org/2019/03/web-networks-charter-draft.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Mar/0010.html

Mozilla has the opportunity to send comments or objections through
Friday, April 26.

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

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

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[L. David Baron]

On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote:
> FYI, the CSS Lists spec isn't very well maintained, sadly,
> so it's not up-to-date with recent resolutions.  So, some
> of the finer details in there might be wrong, but I think
> most of it regarding counters is correct.

If you've been implementing based off of resolutions that aren't in
the spec, it's probably worth submitting PRs to the spec so that
other future implementors are aware of those resolutions and you
don't have to later go and undo the effects of those resolutions for
compatibility.

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

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[L. David Baron]

On Tuesday 2019-03-26 14:25 -0700, Domenic Denicola wrote:
> It's great to hear that this isn't a regression in the way I expected. I 
> think I was thrown off by the phrasing of the OP, which implied to me a 
> switch from following the HTML spec to following the CSS lists spec. As I 
> noted, the CSS lists spec contradicts the HTML spec, e.g. disallowing 
> reversed="" from affecting the counter values. But it sounds like you're 
> ignoring that part of the CSS spec, and instead incrementing (setting?) the 
> list-item counter according to the HTML spec's rules.

I don't think there's an actual contradiction.  The spec describes
the default behavior of list items, but then specifies that other
things happen through the values of CSS properties that are in the
UA stylesheet.  This is the normal way that things evolve when CSS
adds a CSS explanation for an existing feature and part of that CSS
explanation lives in the UA stylesheet.

This has been under discussion in the CSS working group for... over
a decade now, so I wouldn't say that there hasn't been any
cross-browser discussion of it.

That said, the specs could certainly coordinate better.

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

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[L. David Baron]

On Sunday 2019-03-24 22:21 -0700, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser 
> mostly-interoperable behavior for list-item-like behaviors, in 
> https://github.com/whatwg/html/pull/2002 and linked threads. The result is 
> the spec at 
> https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and 
> the tests at 
> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element
>  .
> 
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems 
> to contradict that hard-fought consensus. It states simply that
> 
> > Additionally, list items automatically increment the special list-item 
> > counter. Unless the counter-increment property manually specifies a 
> > different increment for the list-item counter, it must be incremented by 1 
> > on every list item, at the same time that counters are normally incremented.
> 
> This omits all the details at 
> https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , 
> e.g. reversed="", the collection of owned list items, value="" attribute 
> parsing, etc.
> 
> It seems like a regression to implement list item numbering according to that 
> spec, instead of according to HTML.

I wouldn't expect any of these features or tests to regress as a
result of this.  (That said, I think it may be worth considering
behavior changes to edge cases, if such changes are needed,
particularly where browsers aren't currently interoperable, in order
to move towards the idea of list numbering being implemented with
CSS counters underneath.)

I'd note that the sample style sheet for HTML in CSS Lists does
attempt to describe what is needed for HTML:
https://drafts.csswg.org/css-lists/#ua-stylesheet
although it admits that the CSS counter model on its own can't
describe reversed.

The web-platform-test test expectation changes in
https://hg.mozilla.org/mozilla-central/rev/ae4e4daebdc4 are (except
for a single test) in the direction of improvement.

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

Proposed W3C Charter: Web Applications (WebApps) Working Group

[L. David Baron]

The W3C is proposing a charter for:

  Web Applications (WebApps) Working Group
  https://www.w3.org/2019/03/webapps-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Mar/.html

Mozilla has the opportunity to send comments or objections through
Friday, April 5.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.  Given our involvement, we should probably
have some comment, even if it's simply in support (which is what I
intend to do unless anything further comes up).

This charter replaces *most* of what was covered in the Web Platform
working group, whose current charter is at
https://www.w3.org/2017/08/webplatform-charter.html , but not the
parts that are related to forks/copies of WHATWG specifications.

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

W3C Proposed Recommendation: Pointer Events Level 2

[L. David Baron]

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

  Pointer Events Level 2
  https://www.w3.org/TR/pointerevents2/
  https://w3c.github.io/pointerevents/
  Deadline for responses: Thursday, March 21, 2019

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

(I'm not sure to what extent we implement the revisions that are in
level 2.  Knowing that would be helpful.  If it's something we
implement, then we should probably explicitly support it unless we
have a good reason to do otherwise.)

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

Re: Improving our usage of Bugzilla

[David Major]

Will setting the "regressed by" field send mail to the subscribers of
the earlier bug? This was a useful aspect of the blocks/depends field.

On Tue, Mar 12, 2019 at 1:59 PM Sylvestre Ledru  wrote:
>
> Le 12/03/2019 à 17:48, Andrew McCreight a écrit :
> > On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru 
> > wrote:
> >
> >> With this change, we are going to extend Bugzilla to add a new field with
> >> three new values:
> >>
> >> -
> >>
> >> Defect - an issue in one of our products
> >> -
> >>
> >> Enhancement - a new feature or an improvement
> >> -
> >>
> >> Task - a developer task. For example: refactor code foo.
> >>
> >>
> > Could please you explain more what these three values are supposed to
> > represent, possibly with some examples? It feels like there's a lot of
> > overlap between them. For instance, isn't any task I work on as a developer
> > a developer task? Isn't refactoring both a task and an improvement (and
> > thus also an enhancement)?
>
> * Defects are trivial. Examples:
> Crashes, intermittent, glitches, features not working as expecting, features 
> worked
> but no longer works, etc.
>
> This is mostly for users of our products (including ourself). Triaged by eng 
> triage owners.
>
> We decided NOT to call that bug as this word is super-overloaded at Mozilla.
>
> * Enhancement is a development of a new feature.  Examples:
> Add a new avatar for sync, implement feature foo in Javascript,
> add bar property in css 42, etc
>
> This is mostly coming from users and us. Should be triagged by product and 
> triage owners.
>
> * Task is mostly development work. Examples:
> Refactor function foo, remove function bar, improve function plop, etc.
>
> Almost of them should be coming from engineering.
>
> Now, we will have cases for which a ticket will be both a task and an 
> enhancement.
> Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1528330
> "Deliver acceptable GeckoView performance for Firefox Reality in H1"
> But I am sure you will agree that this new state will still be an improvement 
> over the current state.
>
>
> Now, a more concrete example, I have want to implement a new feature in 
> Firefox.
> I will create (or reuse) a bug with the "enhancement" value (probably as a 
> meta bug).
> Then, to develop the feature, I will create various "tasks" which will be 
> marking as
> blocking the meta bug.
>
> Because I am a bad developer, I will make mistakes and user will fill bugs 
> which
> will have the "defect" value (and I will use the regressed_by field).
>
>
> > Secondly, to bikeshed a little, could there be some name besides "task" for
> > that third category? Like I said above, everything we work as developers is
> > a developer task. "Refactor" seems like a clearer name, though maybe it is
> > a little limiting. "Side grade"? :)
>
> This is more than just refactoring. It is more "as an engineer, here is what 
> I have to do".
>
> About bikeshed, you can have a look here 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1522342
> Where we did that.
>
> > Thirdly, what category should "organizational" bugs like meta bugs be
> > assigned to? I guess if you have a meta bug for a bunch of enhancements, it
> > would be an enhancement?
>
> Yeah, "it depends" ;) Probably...
>
>
> >
> > 3) Adding a new field called “Regressed by”
> > This is great! The weird encoding of "regressed by" in the "depends on"
> > field is one of the more confusing aspects of Bugzilla, given how important
> > it is. I spend a ton of time setting regressions for bugs, and even still I
> > have to stop occasionally to make sure I'm doing it the right way.
>
> Same here ;)
>
>
> S
>
>
> ___
> 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: Min clang / libclang requirement was updated not long ago...

[David Major]

https://bugzil.la/bootstrap-toolchain-redownloads (it's even got a
name!) is a really annoying one that's been on file for 6+ months.

On Wed, Feb 27, 2019 at 8:39 AM Nathan Froyd  wrote:
>
> On Wed, Feb 27, 2019 at 6:22 AM Kartikaya Gupta  wrote:
> > On Wed, Feb 27, 2019 at 3:40 AM Axel Hecht  wrote:
> > >
> > > Can we please not force bootstrap?
> >
> > +1. In general bootstrap isn't "rock solid" enough to force people
> > into running it.
>
> If people have problems with bootstrap (it doesn't do enough, it
> assumes too much about your system, etc. etc.), please file bugs on
> what's wrong.  We need to start depending more on bootstrap for
> everything, to the point of "you can't depend on X unless it gets
> installed via bootstrap", and we can't get to that world if we don't
> know what rough edges people find in bootstrap.
>
> Thanks,
> -Nathan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Min clang / libclang requirement was updated not long ago...

[David Major]

Does configure warn about this?

The link between this error and needing to bootstrap is not super
clear (and a surprising number of people don't read dev-platform) so
I'm not looking forward to answering the same question in #build for
the rest of the week. :)

On Tue, Feb 26, 2019 at 12:23 PM Emilio Cobos Álvarez  wrote:
>
> ... so if you don't use the mozilla-provided libclang (or are using a
> very old one), and you see an error like:
>
> > error[E0277]: the trait bound
> `values::generics::rect::Rect f32>>:
> std::convert::From,
>
> Please re-run mach bootstrap, or update your libclang.
>
> Thanks!
>
>  -- 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

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

[L. David Baron]

The W3C is proposing a revised charter for:

  Web Application Security (WebAppSec) Working Group
  https://www.w3.org/2019/02/webappsec-2019-proposed-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2019Feb/0010.html

Mozilla has the opportunity to send comments or objections through
Friday, March 15.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.  Given our involvement, we should probably
have some comment, even if it's simply in support.

A comparison with the current charter is:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2011%2Fwebappsec%2Fcharter-2017.html=https%3A%2F%2Fwww.w3.org%2F2019%2F02%2Fwebappsec-2019-proposed-charter.html
and the document's own summary of the changes is:

  Added Feature Policy

  Dropped User Interface Security and the Visibility API,
  Confinement with Origin Web Labels

  Origin-Wide Policy becomes Site-Wide Policy

(I'm happy about the addition of Feature Policy, since I think it's
important for, among other things, improvements to permission
prompts triggered from iframes.)

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

Re: Intent to ship: BigInt

[L. David Baron]

On Thursday 2019-02-21 15:44 +0100, Andy Wingo wrote:
> ## Support in other browser / JS engines
> 
> Chrome / V8 implements the draft spec.
> 
> Safari / JavaScriptCore has a partial implementation that is being
> completed on an ongoing basis by Caio Lima.

Have either of them announced plans to ship (or actually shipped)
this feature?

(What's the opinion of TC39 on shipping features that are at stage
3?  That doesn't seem obvious from
https://tc39.github.io/process-document/ .)

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

Re: Type-based alias analysis and Gecko C++

[David Major]

I don't think anyone wants to allow aliasing merely for its own sake.
A lot of these flags were added just to keep builds working in the
face of noisy compilers a long time ago. It would be good to retest
with our current codebase and current compilers and see where we
stand. If we can easily remove (or reduce) uses of this flag, I think
that would be pretty uncontroversial. But if it turns out to be a huge
amount of work, then as nice as it would be to do the cleanup, it
might not be a justifiable use of time and opportunity cost.


On Fri, Feb 15, 2019 at 3:59 AM Henri Sivonen  wrote:
>
> I happened to have a reason to run our build system under strace, and
> I noticed that we pass -fno-strict-aliasing to clang.
>
> How committed are we to -fno-strict-aliasing?
>
> If we have no intention of getting rid of -fno-strict-aliasing, it
> would make sense to document this at
> https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code
> and make it explicitly OK for Gecko developers not to worry about
> type-based alias analysis UB--just like we don't worry about writing
> exception-safe code.
>
> Debating in design/review or making an effort to avoid type-based
> alias analysis UB is not a good use of time if we're committed to not
> having type-based alias analysis.
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
> ___
> 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

WIP new W3C Charter: Media Working Group

[L. David Baron]

The W3C has announced work in progress (WIP) on the development of a
new working group charter:

  Media Working Group
  https://lists.w3.org/Archives/Public/public-new-work/2019Feb/0009.html

The description of the working group is:

  The Media Working Group would develop and improve client-side
  media processing and playback features on the Web by standardizing
  media related specifications and features that have matured in the
  Web Platform Incubator Community Group [0]. The group would also
  maintain and further develop the existing Media Source Extensions
  (MSE) Recommendation [1].

and there's also discussion as to whether or not to include
maintenance of EME as well (see link above).

This is prior to the formal review, and it's useful (and probably
easier) to get feedback in at this early stage.  Depending on the
feedback, it may make sense to discuss it here or to file issues
directly, whichever seems appropriate.  (Feel free to contact me
directly if you're not sure.)

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

Re: Moving reviews to Phabricator

[David Major]

For what it's worth, arcanist works fine for me in WSL, with a
considerably less-horrifying installation process than on real
Windows.

With an alias you can call it from MozillaBuild as if it were native:
alias arc="cmd //c ubuntu1804 run arc"


On Wed, Feb 6, 2019 at 3:49 PM Jörg Knobloch  wrote:
>
> On 06/02/2019 21:42, Kim Moir wrote:
> > On February 28 Bugzilla review flags will be disabled for Firefox and other
> > mozilla-central products and components. From this point forward, all
> > reviews of code changes to mozilla-central should be conducted in
> > Phabricator. Tasks that have been identified as crucial to this transition
> > have been set as blocker bugs tohttps://bugzil.la/1514775.
>
> Any simplification in sight to get this set up more easily for Windows
> users?
>
> Last I looked you needed 12 steps to get there:
> https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html
>
> I have three Windows development machines to set up :-(
>
> Jörg.
>
>
> ___
> 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

W3C Proposed Recommendation: Web Authentication

[L. David Baron]

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

  Web Authentication
  https://www.w3.org/TR/webauthn/
  Deadline for responses: Thursday, February 14, 2019

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

Given that we implement this specification, one of the editors works
for us, and have been supporting this work for a while, I'm assuming
we should support this advancement as well...

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

W3C Proposed Recommendation: User Timing Level 2

[L. David Baron]

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

  User Timing Level 2
  https://www.w3.org/TR/user-timing-2/
  Deadline for responses: Thursday, February 7, 2019

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

(I'm not sure to what extent we implement this specification.
Knowing that would be helpful.  If it's something we implement, then
we should probably explicitly support it unless we have a good
reason to do otherwise.)

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

Proposed W3C Charter: Secure Web Payments Interest Group

[L. David Baron]

The W3C is proposing a new charter for:

  Secure Web Payments Interest Group
  https://www.w3.org/securepay/charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2018Dec/0008.html

Mozilla has the opportunity to send comments or objections through
Wednesday, February 6.

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

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

PSA: Inadvertently exporting third-party symbols

[David Major]

Hi,

As importing third-party code into libxul seems to be pretty popular,
I wanted to point out something that's easy to overlook.

Libraries usually have code that goes like:

#ifdef _WIN32
#define MYLIB_EXPORT __declspec(dllexport)
#else
#define MYLIB_EXPORT __attribute__((visibility("default")))
#endif

MYLIB_EXPORT int MyLibrary_DoTheThing() { return 42; }

This makes perfect sense when upstream builds their product as
MyLibrary.dll, as those APIs need to be callable from the outside
world. But when we paste the code into libxul, and its callers are
also in libxul, there is no need to cross a library boundary.

Exporting those symbols when not needed is harmful for several reasons:

* It prevents optimization and/or increases code size. The compiler
has to choose between keeping a single copy of the function with the
shape demanded by the ABI, which inhibits interprocedural
optimizations; or creating optimized/inlined copies but keeping the
original just in case the outside world ever calls it.

* It attracts wrongful blame in crash stacks. In cases where a
debugger doesn't have access to symbols, it will guess an
instruction's function based on the nearest exported symbol. This
often makes it look like function_that_landed_last_week+0x12345 caused
a crash, which wastes time with a wild goose chase.

* Exported symbols invite function hooks from questionable software.

I've filed bug 1523352 to see if we can keep track of export table
size in Perfherder similar to the existing section size metrics.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ method definition comments

[David Teller]

I find them extremely useful, too (as in "removing them would make my
life miserable in quite a few bugs"). I have no problem with putting
them on a separate line.

Cheers,
 David

On 26/01/2019 15:19, Jonathan Watt wrote:
> Personally I find them useful. Putting them on a separate line seems 
> reasonable
> to me.
> 
> Jonathan
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: SVG Working Group

[L. David Baron]

Thanks.  Revised comments submitted at:
https://lists.w3.org/Archives/Public/public-new-work/2019Jan/0010.html

-David

On Thursday 2019-01-24 23:32 -0800, Tantek Çelik wrote:
> Comments inline.
> 
> On Thu, Jan 24, 2019 at 5:54 PM L. David Baron  wrote:
> >
> > On Sunday 2018-12-23 09:59 -0800, L. David Baron wrote:
> > > The W3C is proposing a revised charter for:
> > >
> > >   Scalable Vector Graphics (SVG) Working Group
> > >   https://www.w3.org/Graphics/SVG/svg-2019-ac.html
> > >   https://lists.w3.org/Archives/Public/public-new-work/2018Dec/0006.html
> > >
> > > Mozilla has the opportunity to send comments or objections through
> > > Friday, January 25.
> > >
> > > Please reply to this thread if you think there's something we should
> > > say as part of this charter review, or if you think we should
> > > support or oppose it.  Given our past involvement, we should
> > > probably have some comment, even if it's simply in support.
> > >
> > > A comparison with the current charter is:
> > > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F04%2Fsvg-2017.html=https%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG%2Fsvg-2019-ac.html
> >
> > Based on the comments from Henri and Cameron, I propose to submit
> > the following comments.  Please let me know in the next 24 hours if
> > there's anything wrong with them.
> 
> In general this is very good.
> 
> 
> > -David
> >
> > We generally support this charter and its focus on stabilization and 
> > testing, although we're not sure we'll be able to put significant effort 
> > into supporting the group's work.
> 
> Add: ... especially any new features.
> 
> Based on just the past two years of new feature implementation (CSS
> etc.), It's quite likely that we wouldn't be able to prioritize
> allocating time to debating/discussing details of new SVG features
> (much less implementing them), before the end of this charter period.
> 
> > There are two particular concerns we have with the charter.
> >
> > The first is with the sentence "As a secondary focus, the group may address 
> > modules for new graphical features for SVG, once there is broad consensus 
> > on adding each such feature to the Web Platform."  We'd like this sentence 
> > to be clearer that "broad consensus" needs to include consensus of 
> > implementors; it shouldn't be sufficient if there are a significant number 
> > of users interested in a feature but only a single implementor.
> 
> Two things:
> 
> 1. This charter sentence concerns me a lot. It feels too open ended
> and underspecified as to what new graphical features. I'd prefer that
> this sentence be rewritten for new feature incubation / development to
> happen across the SVG CG / SVG WG similar to new feature incubation /
> development happens in WICG and graduates to WPWG (Soon to be
> WebAppsWG).
> 
> 2. This (even the just the existing concerns noted above) is worth a
> FO.  I would reword the double-negative ("shouldn't be sufficient ...
> but only") for clarity, e.g.:
> "We'd like this sentence to be clearer that "broad consensus" needs to
> include consensus of implementors; a single implementor is
> insufficient; broad consensus must be include explicit interest from
> at least two implementors in addition to users interested in a
> feature."
> 
> 
> > The second is with the statement that SVG 2 updates SVG 1.1 to include 
> > HTML5-compatible parsing.  While that's probably fine, we'd like it to be 
> > clear that changes to the HTML parsing algorithm are out of scope; the HTML 
> > parsing algorithm should be maintained in the HTML specification, and 
> > should be changed very rarely due to the high costs of updating both 
> > client-side and server-side software and the costs of those pieces of 
> > software being out-of-sync.
> >
> >
> > We also have a few other smaller comments:
> >
> > - The proposed "Core SVG" specification seems in some ways to duplicate or 
> > replace the work in https://www.w3.org/TR/svg-integration/ .  It would be 
> > useful to clarify the relationship.
> >
> > - The statement in the Scope section that "The SVG WG develops a single 
> > deliverable" seems to conflict with the deliverables section.
> 
> These are good. Also perhaps drop this from 3.1 W3C Groups:
> "
> Web Platform Working Group
> Coordinate on integration of SVG and HTML, and on compatibility with
> the Canvas API specifications.
> "
> As that WG will n

Re: Proposed W3C Charter: SVG Working Group

[L. David Baron]

On Sunday 2018-12-23 09:59 -0800, L. David Baron wrote:
> The W3C is proposing a revised charter for:
> 
>   Scalable Vector Graphics (SVG) Working Group
>   https://www.w3.org/Graphics/SVG/svg-2019-ac.html
>   https://lists.w3.org/Archives/Public/public-new-work/2018Dec/0006.html
> 
> Mozilla has the opportunity to send comments or objections through
> Friday, January 25.
> 
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.  Given our past involvement, we should
> probably have some comment, even if it's simply in support.
> 
> A comparison with the current charter is:
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F04%2Fsvg-2017.html=https%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG%2Fsvg-2019-ac.html

Based on the comments from Henri and Cameron, I propose to submit
the following comments.  Please let me know in the next 24 hours if
there's anything wrong with them.

-David

We generally support this charter and its focus on stabilization and testing, 
although we're not sure we'll be able to put significant effort into supporting 
the group's work.

There are two particular concerns we have with the charter.

The first is with the sentence "As a secondary focus, the group may address 
modules for new graphical features for SVG, once there is broad consensus on 
adding each such feature to the Web Platform."  We'd like this sentence to be 
clearer that "broad consensus" needs to include consensus of implementors; it 
shouldn't be sufficient if there are a significant number of users interested 
in a feature but only a single implementor.

The second is with the statement that SVG 2 updates SVG 1.1 to include 
HTML5-compatible parsing.  While that's probably fine, we'd like it to be clear 
that changes to the HTML parsing algorithm are out of scope; the HTML parsing 
algorithm should be maintained in the HTML specification, and should be changed 
very rarely due to the high costs of updating both client-side and server-side 
software and the costs of those pieces of software being out-of-sync.


We also have a few other smaller comments:

- The proposed "Core SVG" specification seems in some ways to duplicate or 
replace the work in https://www.w3.org/TR/svg-integration/ .  It would be 
useful to clarify the relationship.

- The statement in the Scope section that "The SVG WG develops a single 
deliverable" seems to conflict with the deliverables section.

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

Closure of #ateam irc channel

[David Burns]

For the last 2 years the Automation and Tools team (#ateam) has not existed
as a single function as parts of the team were split up between Firefox
Engineer Operations and Product Integrity.

As traffic in #ateam has dropped it is time to close this irc channel and
request people go to more specific channels to get the help that you need.


   -

   #build - Build team: Compilation of Firefox
   -

   #vcs - hg.mozilla.org
   -

   #engworkflow - Engineering Work flow: Tooling for engineers phabricator,
   lando.
   -

   #bmo - bugzilla.mozilla.org
   -

   #Sheriffs - Sheriffing team: Sheriffing of trees
   -

   #cia - CI and Automation team: Test harnesses and CI scheduling
   -

   #treeherder - Treeherder team: Treeherder specific problems or queries
   -

   #perftest - Performance Testing: Performance test harnesses and their
   tests
   -

   #interop - Web Predictability and Interop: Marionette, Webdriver and Web
   Platform Tests


If you are unsure of where your question may fall feel free to try any of
the channels listed and you will be directed to the best team to help.


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

How do we land `./mach vendor rust` patches, these days?

[David Teller]

Hi everybody,

 My last two attempts to update our crates with `./mach vendor rust`
failed, not during vendoring, but when I attempted to upload the patch.
Both times, moz-phab/arcanist or phabricator simply choked during the
call and I gave up after waiting 24h for the patch to be uploaded.

Do we have a better way to do this? Or should I use splinter for such
patches?

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

Re: Intent to implement: report-to header as part of Reporting API

[David Burns]

On Thu, 10 Jan 2019 at 12:27, Andrea Marchesini 
wrote:

> web-platform-tests: just a little support. I wrote several mochitests which
> can be converted to WPTs with a bit of effort.
>

There don't appear to be any WPT if I am looking in the right place[1].
Since Google are experimenting it feels like we have some WPT from the
start, even if its a pure conversion of the mochitest, it would help make
sure we interoperable with them.

[1]
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/reporting/

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