Re: Announcing MozillaBuild 3.0 Release

[Nicholas Nethercote]

This thread is nominally about a new version of MozillaBuild 3.0, though it
has strayed significantly. I'm going to politely suggest that discussion of
other topics in this thread cease. If anybody wants to start other threads
on other topics, please do so.

But also be aware that this mailing list is read by a lot of people
(hundreds at least, I think) and it isn't really intended as a place for
new contributors to ask questions about anything and everything. In
contrast, the #introduction IRC channel is specifically designed for that.

Nick

On Tue, Jul 25, 2017 at 1:36 PM, Mike Hommey  wrote:

> On Tue, Jul 25, 2017 at 01:07:19AM +, Enrico Weigelt, metux IT consult
> wrote:
> > On 25.07.2017 00:34, Mike Hommey wrote:
> >
> > > Debian has 52esr.
> >
> > Maybe in experimental. But that doesn't help me much for jessie.
>
> No, it's in testing, and should reach stable at some point, and I guess
> the Debian LTS people will pull it for jessie, because it's already in
> wheezy.
>
> > > > And it still contains lots of dead weight, I'd like to get rid of.
> > >
> > > Which is out of scope for packaging something for Debian.
> >
> > Maybe for average Debian folks, who also have no problem w/ forcing
> > people into some special init system that wants to be an own OS.
>
> Oh, so you're also trolling, now.
>
> Mike
> ___
> 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: Announcing MozillaBuild 3.0 Release

[Mike Hommey]

On Tue, Jul 25, 2017 at 01:07:19AM +, Enrico Weigelt, metux IT consult 
wrote:
> On 25.07.2017 00:34, Mike Hommey wrote:
> 
> > Debian has 52esr.
> 
> Maybe in experimental. But that doesn't help me much for jessie.

No, it's in testing, and should reach stable at some point, and I guess
the Debian LTS people will pull it for jessie, because it's already in
wheezy.

> > > And it still contains lots of dead weight, I'd like to get rid of.
> > 
> > Which is out of scope for packaging something for Debian.
> 
> Maybe for average Debian folks, who also have no problem w/ forcing
> people into some special init system that wants to be an own OS.

Oh, so you're also trolling, now.

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

Re: OS/2 still supported ?

[Kris Maglione]

On Tue, Jul 25, 2017 at 01:13:42AM +, Enrico Weigelt, metux IT consult 
wrote:

On 25.07.2017 00:32, Mike Hoye wrote:

On 2017-07-24 8:27 PM, Enrico Weigelt, metux IT consult wrote:

Hi folks,


I see lots of #ifdef XP_OS2 ... is OS/2 still supported at all ?

Our list of supported platforms is here:

https://developer.mozilla.org/en/docs/Supported_build_configurations


I don't see OS2 here, nor win16. So, can we remove the related parts ?


The only remaining in-tree references to the XP_OS2 macros are 
in NSPR and NSS, which are technically separate projects, and 
have their own sets of supported platforms.

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

Re: OS/2 still supported ?

[Enrico Weigelt, metux IT consult]

On 25.07.2017 01:26, Gregory Szorc wrote:


Yes, please submit patches to remove dead code.


I've already kicked out a lot. Couldn't fully test yet, as still have to
cope w/ other breaks. But I'll move it to another branch, when I'm
trough.

BTW: BEOS could be next.

Shall I put that in one patch or separate smaller ones ?


If you want to go down a rabbit hole to help with that,
https://bugzilla.mozilla.org/show_bug.cgi?id=nukeb2g is full of open bugs.


Already have it in progress.


--mtx

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

Re: Intent to remove: sensor APIs

[Blair MacIntyre]

I’m not sure what you’re asking:  I’ve been using the deviceorientation API 
like this for many years, as have plenty of other people.It’s absolutely 
needed.
 
--
Blair MacIntyre
Principal Research Scientist
bmacint...@mozilla.com 




> On Jul 24, 2017, at 8:04 PM, Enrico Weigelt, metux IT consult 
> > wrote:
> 
> On 24.07.2017 20:46, Blair MacIntyre wrote:
> 
>> We are working on adding AR capabilities to the browser, and this will 
>> (similarly)
> > need to know device orientation.
> 
> Please make sure, we can easily compile completely w/o that.
> 
> 
> --mtx
> 

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

Re: Announcing MozillaBuild 3.0 Release

[Joshua Cranmer ]

On 7/24/2017 7:20 PM, Enrico Weigelt, metux IT consult wrote:

On 24.07.2017 23:04, Mike Hommey wrote:


It looks like you're doing a lot of work that is completely out of scope
for creating packages for Debian/Devuan,


Not quite. Of course, I don't wanna compile-in things that aren't
necessary here (eg. the media stuff). But that lead to lots of problems,
so I'm now getting my hands dirty and try to fix at the root.


Trying to build by disabling lots of flags in general leads to lots of 
frustration with broken builds. A decade of experience at Mozilla has 
shown that configurations not built on standard automation tend to be 
quickly broken. The onus of maintenance will be entirely on you, even if 
the changes are upstreamed--and they are unlikely to be accepted 
upstream without justification (which "I don't wanna have these" is not).


FWIW, building in odd configurations generally disqualifies you from 
being able to use Mozilla trademarks on the resulting product.





and that is work that sounds
like should be discussed with the thunderbird crowd.


Nope, they directed me to this list, as these things aren't in tbird's
own tree, but generic mozilla.


I directed you to this list because you were asking "how do I modify 
media/ to stop doing this stuff?", which is plainly out of scope for mdat.



When I'm done w/ that, I'll start w/ things I've been planning for
quite some time, eg. moving mailbox handling to external upas service,
all credential related stuff to factotum, move contact handling to
external programs, etc, etc.

But before I can start with that, I first need a clean working base.


If you believe that maintaining your own custom pared-down ersatz build 
is a necessary precondition for adding new functionality, you will have 
rather little time to implement other functionality.


As Mike Hommey says, you are looking to build a fork of Thunderbird at 
this point. It's not entirely clear what you're proposing, but the vague 
language suggests very heavily that you're intending to delete our 
present code for unknown external libraries, which is likely not in the 
vision of Thunderbird's future and therefore is unlikely to be accepted 
upstream.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: OS/2 still supported ?

[Gregory Szorc]

On Mon, Jul 24, 2017 at 6:13 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> On 25.07.2017 00:32, Mike Hoye wrote:
>
>> On 2017-07-24 8:27 PM, Enrico Weigelt, metux IT consult wrote:
>>
>>> Hi folks,
>>>
>>>
>>> I see lots of #ifdef XP_OS2 ... is OS/2 still supported at all ?
>>>
>> Our list of supported platforms is here:
>>
>> https://developer.mozilla.org/en/docs/Supported_build_configurations
>>
>
> I don't see OS2 here, nor win16. So, can we remove the related parts ?
>

Yes, please submit patches to remove dead code.

If you want to go down a rabbit hole to help with that,
https://bugzilla.mozilla.org/show_bug.cgi?id=nukeb2g is full of open bugs.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OS/2 still supported ?

[Enrico Weigelt, metux IT consult]

On 25.07.2017 00:32, Mike Hoye wrote:

On 2017-07-24 8:27 PM, Enrico Weigelt, metux IT consult wrote:

Hi folks,


I see lots of #ifdef XP_OS2 ... is OS/2 still supported at all ?

Our list of supported platforms is here:

https://developer.mozilla.org/en/docs/Supported_build_configurations


I don't see OS2 here, nor win16. So, can we remove the related parts ?


--mtx

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

Re: Announcing MozillaBuild 3.0 Release

[Enrico Weigelt, metux IT consult]

On 25.07.2017 00:34, Mike Hommey wrote:


Debian has 52esr.


Maybe in experimental. But that doesn't help me much for jessie.


And it still contains lots of dead weight, I'd like to get rid of.


Which is out of scope for packaging something for Debian.


Maybe for average Debian folks, who also have no problem w/ forcing
people into some special init system that wants to be an own OS.
But certainly not for me - I dont wanna have useless code on my
machines.


So, in fact, you want to fork thunderbird, you should just have said so
from the beginning.


Too early to tell whether it will end up in a fork or things can be
integrated into mainline. We'll see later.


--mtx

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

Re: Announcing MozillaBuild 3.0 Release

[Fabrice Desre]

On 07/24/2017 05:20 PM, Enrico Weigelt, metux IT consult wrote:



When I'm done w/ that, I'll start w/ things I've been planning for
quite some time, eg. moving mailbox handling to external upas service,
all credential related stuff to factotum, move contact handling to
external programs, etc, etc.

But before I can start with that, I first need a clean working base.


If you haven't done so yet, you should read the archives at 
https://mail.mozilla.org/pipermail/tb-planning/ where the future of 
Thunderbird is discussed. It looks quite different from trimming down 
gecko.


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

Re: Announcing MozillaBuild 3.0 Release

[Mike Hommey]

On Tue, Jul 25, 2017 at 12:20:48AM +, Enrico Weigelt, metux IT consult 
wrote:
> On 24.07.2017 23:04, Mike Hommey wrote:
> 
> > It looks like you're doing a lot of work that is completely out of scope
> > for creating packages for Debian/Devuan,
> 
> Not quite. Of course, I don't wanna compile-in things that aren't
> necessary here (eg. the media stuff). But that lead to lots of problems,
> so I'm now getting my hands dirty and try to fix at the root.
> 
> > and that is work that sounds
> > like should be discussed with the thunderbird crowd.
> 
> Nope, they directed me to this list, as these things aren't in tbird's
> own tree, but generic mozilla.
> 
> > (Also, there's already a thunderbird package in Debian)
> 
> An old one.

Debian has 52esr.

> And it still contains lots of dead weight, I'd like to get rid of.

Which is out of scope for packaging something for Debian.

> When I'm done w/ that, I'll start w/ things I've been planning for
> quite some time, eg. moving mailbox handling to external upas service,
> all credential related stuff to factotum, move contact handling to
> external programs, etc, etc.
> 
> But before I can start with that, I first need a clean working base.

So, in fact, you want to fork thunderbird, you should just have said so
from the beginning.

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

Photon Engineering Newsletter #9

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/07/24/photon-engineering-newsletter-9/)

Well, here we go again with a big update for Newsletter #9
! [Since the last update, I
took a vacation and ever since have been getting caught up. So this update
is terribly overdue. Sorry about that!]
Animations

Animations for toolbar icons are finally landing! Yay! :kermithands:
The stop/reload and pin-to-overflow animations are in Nightly, and the
Pocket, bookmarks, and downloads icons are next. I’d like to talk a little
about the way these animations are implemented. The effect is simple, but
there’s a lot of work behind the scenes.

As is often the case in engineering, we had a number of requirements that
needed to be satisfied. The most important was performance – we’re making
Firefox 57 blazing fast, and it wouldn’t do to have animations hurting that
work. We worked closely with our Graphics and Platform teams to develop a
technique (more on that in a second) that was efficient, and specifically
could run entirely within the compositor process
.
This helps ensure the animation can smoothly run at 60fps without impacting
(or being impacted by) all the other stuff running in the browser. The
other big requirement was around UX. We wanted to minimize the platform
technical constraints for our visual designers, so that their ideas were
not bound by platform limitations. [For example, we had an old patch
 to convert the
page-loading
throbber

from an APNG  to a static image
animated with a CSS transform (rotation). That’s nice, but then you’re
limited to effects possible in pure CSS.] We also needed to use SVG in the
animation, since the rest of Firefox’s icons are SVG now. This gives the
best result when scaling to different display DPI settings, and allows us
to dynamically adjust the icon colors based on system style.

The technique we’re using for Photon is based around an SVG “filmstrip” –
each frame is pre-drawn separately within an SVG image. We then use CSS to
crop it to a specific frame, and a CSS Animation to move the crop box for
each frame. Since it’s all declarative, Gecko and the compositor process
can handle the animation very efficiently.

[image: filmstrip]

A demo is worth 10,000 words, so check out Jared’s SVG Filmstrip Demo
 to see how this works in detail. (Since it’s all
based on web technologies, you can view-source and see the same technique
running in your browser that we use in chrome.)

Of course, nothing is ever simple! There’s a lot of work that goes into
getting these assets ready. First, our visual designers prototype an
animation in Adobe After Effects. It then goes through a process of design
iteration and user testing. (Is is distracting? Does it communicate what we
want? Too fast? Too slow?) The animation is then exported to an SVG file,
but the markup from Adobe is usually not very good. So we use SVGO
 to optimize it, often further hand-tune the
SVGO output, and finally tweak it to make use of the dynamic context-fill
 color specified from
the browser’s CSS.

Phew! But thankfully, as a user, you can just enjoy the finished result.
We’d like to refine the creation process, but overall it’s a pretty
powerful and flexible technique that we’ll be using more and more.
Recent Changes

Menus/structure:

   - Lots  of minor
    bugfixes
    to
    various
    aspects
    of the earlier
    changes
    we made
   . Thanks to
   contributors Jeongkyu Kim (bug 1376484) and Adolfo Jayme (bug 1376097) for
   their work!
   - Flexible spacers are now available in customize mode
   . This is the
   first step towards having the location field be centered in the navbar, as
   part of the Photon design.
   - Work on the Page Action panel is progressing
   . We gave a
   prototype sneak-peek at the All-Hands (see Photon Newsletter #8), but it’s
   not quite ready to land yet.
   - Made the Library button work correctly in the overflow panel
   

Re: OS/2 still supported ?

[Mike Hoye]

On 2017-07-24 8:27 PM, Enrico Weigelt, metux IT consult wrote:

Hi folks,


I see lots of #ifdef XP_OS2 ... is OS/2 still supported at all ? 

Our list of supported platforms is here:

https://developer.mozilla.org/en/docs/Supported_build_configurations

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

Re: Announcing MozillaBuild 3.0 Release

[Enrico Weigelt, metux IT consult]

On 24.07.2017 23:04, Mike Hommey wrote:


It looks like you're doing a lot of work that is completely out of scope
for creating packages for Debian/Devuan,


Not quite. Of course, I don't wanna compile-in things that aren't
necessary here (eg. the media stuff). But that lead to lots of problems,
so I'm now getting my hands dirty and try to fix at the root.


and that is work that sounds
like should be discussed with the thunderbird crowd.


Nope, they directed me to this list, as these things aren't in tbird's
own tree, but generic mozilla.


(Also, there's already a thunderbird package in Debian)


An old one. And it still contains lots of dead weight, I'd like to get
rid of.

When I'm done w/ that, I'll start w/ things I've been planning for
quite some time, eg. moving mailbox handling to external upas service,
all credential related stuff to factotum, move contact handling to
external programs, etc, etc.

But before I can start with that, I first need a clean working base.


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

Re: IDL vs ifdef

[Steve Fink]

On 07/24/2017 05:08 PM, Enrico Weigelt, metux IT consult wrote:

On 24.07.2017 21:03, Ralph Giles wrote:


I suspect this will be painful to maintain. We used to have a lot of
#ifdefs for media playback support but they weren't tested and were
usually broken, so we removed them.


Well, I'm just reintroducing them. 


You know all that excess complexity and cruft you're finding in the 
codebase and build system? This is how it gets there.


In order to get re-adding those #ifdefs to pass review, you'd need to 
(1) promise to maintain them, and (2) find a usage scenario that the 
mozilla project would find worth adding some technical debt to the 
entire project for.


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

Re: IDL vs ifdef

[Enrico Weigelt, metux IT consult]

On 24.07.2017 21:03, Ralph Giles wrote:


I suspect this will be painful to maintain. We used to have a lot of
#ifdefs for media playback support but they weren't tested and were
usually broken, so we removed them.


Well, I'm just reintroducing them.

My original intention was just to build w/o the codecs, but that
broke a lot in the media stuff, so I moved on to disable it completely.


If you're just concerned about codesize, you can get a significant
reduction by stubbing out the MediaDecoder class and then disabling all
the code it depends on.


I also don't want the dom-related part in tbird. I'm also going to make
sure that it even never executes any jscript stuff from mails.


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

Re: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 24.07.2017 20:46, Blair MacIntyre wrote:


We are working on adding AR capabilities to the browser, and this will 
(similarly)

> need to know device orientation.

Please make sure, we can easily compile completely w/o that.


--mtx

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

Re: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 24.07.2017 20:43, Kearwood  Kip  Gilbert wrote:

Please note that disabling the Device Orientation API will also
effectively disable the “WebVR Polyfill”.  The “WebVR Polyfill” is a
javascript library that allows browser that otherwise don’t support VR
(ie, Fennec) to use “Cardboard” VR holders to create simple VR
experiences.


Am I the only one here still remembering that web-browsers used
to be HTTP clients w/ hypertext display ?

The whole VR stuff might be nice for some niches (eg. CAD stuff, etc),
but I wonder what that got to do w/ hypertext ...


A non-VR use case that affects 90% of users is the “magic window”
effects.  These are most commonly used by sites such as Facebook to give
some degree of freedom in viewing a 360 panorama video or photo by
moving the phone around.


A website (especially FB) getting device positioning information
delivered by the browser - that is *really* scary!

The wireless tracking (even w/o gps) already is a massive problem,
we need to care about (not a browser topic), the situation is already
worse than in the previous socialist regimes. We shouldn't make that
even worse.


Combined with media capture API’s the orientation API is also essential
for implementing things like “Google Goggle” or Yelp’s Monocle on the
web platform.


Sorry, but these kind misfeatures are a total security nightmare,
way beyond the red line. Bad enought the people collaborate w/ mass
sourveillance by using games like pokemon go (which, IMHO should be
prohibited). But infecting browers with that is magnitudes worse.


--mtx

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

Re: Announcing MozillaBuild 3.0 Release

[Steve Fink]

On 07/24/2017 04:03 PM, Enrico Weigelt, metux IT consult wrote:

On 24.07.2017 21:29, Steve Fink wrote:


My guess is that the compilers/linkers don't really handle heavy C++
template usage very well, and end up generating and then eliminating
massive number of duplicate template instantiations. But that's idle
speculation.


I doubt there's much that compilers can do better here.

When compiling a C++ source, it needs to compile all that's needed
within that file (header-defined functions, constructors, template-
instantiations, etc). Later, at the linking phase, it can throw out
lots of duplicated code. For statically linked binaries, it's still
quite easy, but w/ shared libraries it gets pretty complex. 


Sure, I get that. But first, I'm a little skeptical that the slowdown is 
merely linear in the amount of duplication; it feels worse than that. 
And second, even if this is the exact problem at hand, it feels like 
C++'s reliance on independent compilation units is outdated. It's great 
for modularity and simplicity, but in fact C++ the language does not 
work that way, and stripping out redundancies during linking is the 
wrong algorithm. Not that I would assert that an alternative would be 
straightforward, especially with the preprocessor involved and differing 
scope lookup environments etc. But from an algorithmic standpoint, 
separate compilation is simply incorrect.


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

Re: Announcing MozillaBuild 3.0 Release

[Nathan Froyd]

On Mon, Jul 24, 2017 at 6:21 PM, Enrico Weigelt, metux IT consult
 wrote:
> On 24.07.2017 20:40, Nathan Froyd wrote:
>> Sure, it's daily business for us, too.  Mike cited examples in his
>> response (e.g. we cannot compile natively on 32-bit systems, Android
>> included, so Firefox for such platforms is cross compiled from a
>> 64-bit platform).
>
> OTOH, we should keep in mind that most distros dont do cross compiling.
> Some distros (eg. gentoo or lfs) are also building on the target.
>
> I don't like the idea of kicking away these platforms.

We do take into account the needs of Linux distributions when making
changes.  So far as I am aware, our compilation requirements for Linux
platforms have not caused huge amounts of headaches.

>>> Haven't tried on Windows yet. Can we crosscompile it from Linux ?
>>
>> No.  There are a few people interested, but there are lots of issues.
>
> I'd guess it could be helpful for developers not running Windows,
> at least for doing some build checks.

Developers not running Windows tend to use our try server for
compiling on Windows.  There are some good reasons for cross-compiling
to Windows, but none of them have become important enough to seriously
consider making the switch.

>>> This raises the question: why does it take up so much memory ?
>>
>> Because Firefox is a large program, and linking large programs takes
>> up a large amount of memory, more than is addressable on 32-bit
>> systems.
>
> Well, why is the main program so big that linking takes up so much
> memory ? Perhaps a lack of proper modularization ?

Well, libxul (the main shared library in Firefox) is rather large, but
we're not going to split it into smaller libraries.  We *did* have
multiple shared libraries in the past, and there was a significant
startup and performance hit for doing that.  So we have one large
shared library to link now.

> One thing we could do about that might be limitig the exported symbols
> of shared libraries (only export the really necessary ones).

We already do that.  Eyeballing the `readelf -sW` output from my
Firefox nightly on Linux, libxul exports ~1% of all the symbols it
defines.

Other people have mentioned options for pushing patches; my preferred
tool for doing this is git-bz-moz:
https://github.com/mozilla/git-bz-moz

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

Re: Announcing MozillaBuild 3.0 Release

[Mike Hommey]

On Mon, Jul 24, 2017 at 03:57:24PM -0700, Ralph Giles wrote:
> On Mon, Jul 24, 2017 at 3:51 PM, Botond Ballo  wrote:
> 
> 
> > With MozReview [1], you can submit patches from the command line via a
> > simple "hg push review".
> >
> 
> There's a `git mozreview push` command in the same repo but I believe it
> requires rebasing on top of a git-cinnabar clone of a mercurial repository.
> If you want to do this, install the extension and follow the setup
> instructons at
> https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.
> With that setup you can also use `./mach try` to submit test builds from
> the command line (once you have tier-1 commit access).

It's also possible to work from gecko-dev:
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial

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

Re: Announcing MozillaBuild 3.0 Release

[Ralph Giles]

On Mon, Jul 24, 2017 at 3:51 PM, Botond Ballo  wrote:


> With MozReview [1], you can submit patches from the command line via a
> simple "hg push review".
>

There's a `git mozreview push` command in the same repo but I believe it
requires rebasing on top of a git-cinnabar clone of a mercurial repository.
If you want to do this, install the extension and follow the setup
instructons at
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.
With that setup you can also use `./mach try` to submit test builds from
the command line (once you have tier-1 commit access).

There are also a few git extensions which can push and pull patches to
bugzilla, but this isn't the preferred method as it's harder to get test
feedback and loses the history.

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

Re: Announcing MozillaBuild 3.0 Release

[Enrico Weigelt, metux IT consult]

On 24.07.2017 21:13, Joshua Cranmer  wrote:


In that example, undoing that slows down your build. (Parsing C++ header
files take a lot of time in the aggregate, and you spend less time
linking when there's no duplicates of inlined methods).


That leads me to another question: do the headers need to so huge
at all ? Is there a lack of modularization ?

One problem I'm currently struggling with are the dependencies of
lots of places w/ specific network protocols. This IMHO deserves
a cleanup.


--mtx

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

Re: Announcing MozillaBuild 3.0 Release

[Botond Ballo]

On Mon, Jul 24, 2017 at 6:21 PM, Enrico Weigelt, metux IT consult
 wrote:
> Is there an automatic interface for patch submission (something
> similarily easy like git-send-mail) ? Having to click through websites
> manually is just very time consuming.

With MozReview [1], you can submit patches from the command line via a
simple "hg push review".

Cheers,
Botond

[1] 
https://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview-user.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing MozillaBuild 3.0 Release

[Enrico Weigelt, metux IT consult]

On 24.07.2017 20:40, Nathan Froyd wrote:


Sure, it's daily business for us, too.  Mike cited examples in his
response (e.g. we cannot compile natively on 32-bit systems, Android
included, so Firefox for such platforms is cross compiled from a
64-bit platform).


OTOH, we should keep in mind that most distros dont do cross compiling.
Some distros (eg. gentoo or lfs) are also building on the target.

I don't like the idea of kicking away these platforms.


Haven't tried on Windows yet. Can we crosscompile it from Linux ?


No.  There are a few people interested, but there are lots of issues.


I'd guess it could be helpful for developers not running Windows,
at least for doing some build checks.


This raises the question: why does it take up so much memory ?


Because Firefox is a large program, and linking large programs takes
up a large amount of memory, more than is addressable on 32-bit
systems.


Well, why is the main program so big that linking takes up so much
memory ? Perhaps a lack of proper modularization ?

One thing we could do about that might be limitig the exported symbols
of shared libraries (only export the really necessary ones).


There are probably many places the build can be optimized; if you have
a suggestion, please file a bug at
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Build%20Config


I'm currently working on fixing optional features, eg. protocols,
codecs, etc. Let's see whether I'll also find things to clean up
in the build system.

Is there an automatic interface for patch submission (something
similarily easy like git-send-mail) ? Having to click through websites
manually is just very time consuming.


You can request level 1 commit access to our try infrastructure:
https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/
 That will enable you to build Firefox with your patches on all the
major platforms we support.


Sounds interesting. Is there a way for pushing via git directly ?
I'm currently lacking the resources for coping w/ hg stuff.

A real cool feature would be the CI directly pulling from github,
that would make things a lot easier for people like me.


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

Re: Announcing MozillaBuild 3.0 Release

[Steve Fink]

On 07/24/2017 02:13 PM, Joshua Cranmer  wrote:

On 7/24/2017 3:25 PM, Enrico Weigelt, metux IT consult wrote:


Not sure, whether an 4core i7 w/ 8GB RAM already counts as "old", but
it's really slow on my box. I've got the impression there's stil a lot
of room for optimizations. For example, I wonder why lots of .cpp-files
are #include'd into one.
In that example, undoing that slows down your build. (Parsing C++ 
header files take a lot of time in the aggregate, and you spend less 
time linking when there's no duplicates of inlined methods).


Sorry, I know this is a tangent, but I'd like to underscore that final 
clause, since it's been so surprising to me.


Unified builds *massively* speed up the final link. I dropped the 
unified chunk size (number of .cpp files glued together at a time in 
unholy matrimony) for js/src because of a very common use case, which is 
to touch one file and rebuild. With the default of 16 source files glued 
together, that means recompiling a huge source file. Compiles are 
naturally much faster with the new value (6).


Surprisingly, though, the total time to touch a single source file and 
get out a working build was pretty much unchanged -- the time saved in 
the compilation was spent linking more object files instead.


Overall, it's still a good change, since when you're still working 
through compile errors on something, you aren't going to be linking 
anyway. It just surprised me that the link could get that much slower. 
More recently, I accidentally started using a nonunified build, and 
honestly thought the linker was hanging because it took so much longer 
than I'm used to (this was with n=1 instead of n=6 or n=16).


My guess is that the compilers/linkers don't really handle heavy C++ 
template usage very well, and end up generating and then eliminating 
massive number of duplicate template instantiations. But that's idle 
speculation.



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

Re: Keyboard APZ has landed on Inbound

[Ryan Hunt]

> We will not do keyboard APZ, even if the event listener is marked passive. 

I filed a bug 1383900 about this with a more in depth explanation and possible 
ways we can
get around this to use keyboard APZ more often. [1]

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

> Should that be APZ bug 1376525? Bug bug 1352654 looks like a WebRender
> bug for gradient display items.

Yes I copied the wrong bug. The correct tracking bug is bug 1376525.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing MozillaBuild 3.0 Release

[Joshua Cranmer ]

On 7/24/2017 3:25 PM, Enrico Weigelt, metux IT consult wrote:
That's been true for some time now; while we still support 32-bit 
systems,

> for example, you can't build Firefox on 32-bit systems at all due to
> memory constraints,

This raises the question: why does it take up so much memory ?


Release builds on Windows use LTO, which requires essentially keeping 
both the final object file and the entire internal IR in memory at the 
same time.

Not sure, whether an 4core i7 w/ 8GB RAM already counts as "old", but
it's really slow on my box. I've got the impression there's stil a lot
of room for optimizations. For example, I wonder why lots of .cpp-files
are #include'd into one.
In that example, undoing that slows down your build. (Parsing C++ header 
files take a lot of time in the aggregate, and you spend less time 
linking when there's no duplicates of inlined methods).


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: IDL vs ifdef

[Ralph Giles]

On Sat, Jul 22, 2017 at 12:11 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:


> I'm currently in process of making the media stuff optional.
> (dont need/want it within mail client).
>

I suspect this will be painful to maintain. We used to have a lot of
#ifdefs for media playback support but they weren't tested and were usually
broken, so we removed them.

If you're just concerned about codesize, you can get a significant
reduction by stubbing out the MediaDecoder class and then disabling all the
code it depends on. For recent versions you'll also need to stub out the
webrtc implementation. But in general, bottom-up will be easier than
top-down for the media stuff.

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

Re: Intent to remove: sensor APIs

[Blair MacIntyre]

On Jul 24, 2017, at 4:38 PM, Enrico Weigelt, metux IT consult 
 wrote:
> 
> On 24.07.2017 15:07, Mike Hoye wrote:
>> 
>> I have a sense that as AR gets richer and more nuanced that ambient
> 
> Are we still talking about browsers ?


Yes.  

There are plenty of websites that use deviceorientation, for example to let you 
pan around a panographic photo or a 3D “scene” using the orientation of your 
mobile device.  

Most websites that use WebVR prefer to use “real” WebVR APIs, but on most 
mobile browsers (which don’t support them) use deviceorientation to support a 
“3DOF” (just orientation) view in the world.

We are working on adding AR capabilities to the browser, and this will 
(similarly) need to know device orientation.


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

RE: Intent to remove: sensor APIs

[Kearwood Kip Gilbert]

Please note that disabling the Device Orientation API will also effectively 
disable the “WebVR Polyfill”.  The “WebVR Polyfill” is a javascript library 
that allows browser that otherwise don’t support VR (ie, Fennec) to use 
“Cardboard” VR holders to create simple VR experiences.  Usage of these VR 
holders with non-VR capable browsers is quite prolific, with these holders 
found in most department stores.

The WebVR API when implemented directly by the browser (ie. Firefox Desktop) 
negates the need of the Device Orientation API, as it exposes the tracking data 
from the VR positional sensors in a more direct fashion.

A non-VR use case that affects 90% of users is the “magic window” effects.  
These are most commonly used by sites such as Facebook to give some degree of 
freedom in viewing a 360 panorama video or photo by moving the phone around.

Combined with media capture API’s the orientation API is also essential for 
implementing things like “Google Goggle” or Yelp’s Monocle on the web platform.

Cheers,
- Kip


From: Enrico Weigelt, metux IT consult
Sent: July 24, 2017 1:35 PM
To: Ben Kelly; Anne van Kesteren
Cc: dev-platform
Subject: Re: Intent to remove: sensor APIs

On 24.07.2017 13:57, Ben Kelly wrote:
 > On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  
wrote:
 >
 >> * Device orientation
 >>
 >
 > Isn't this one required to build a decent web experience on mobile 
for some
 > sites?

Could you please define "decent web experience" ?

Maybe I'm just old, but I absolutely don't want an website know anything
about my local devices. Window size and resolution is fine, but ambient
conditions seriously crossed the red line of what I'd ever allow on my
machines.

I've already started patching out that stuff.

Same for things like USB devices, or all that "cloud" stuff.


--mtx

___
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: Announcing MozillaBuild 3.0 Release

[Nathan Froyd]

On Mon, Jul 24, 2017 at 4:25 PM, Enrico Weigelt, metux IT consult
 wrote:
> On 24.07.2017 16:00, Mike Hoye wrote:
>> Unfortunately we have to build _for_ a number of our supported operating
>> systems without being able to build _on_ those operating systems.
>
> Is that a big problem ?
>
> At least within Linux world, it's daily business for me (well, I'm
> doing a lot of embedded projects).

Sure, it's daily business for us, too.  Mike cited examples in his
response (e.g. we cannot compile natively on 32-bit systems, Android
included, so Firefox for such platforms is cross compiled from a
64-bit platform).

> Haven't tried on Windows yet. Can we crosscompile it from Linux ?

No.  There are a few people interested, but there are lots of issues.

>> That's been true for some time now; while we still support 32-bit systems,
>> for example, you can't build Firefox on 32-bit systems at all due to
>> memory constraints,
>
> This raises the question: why does it take up so much memory ?

Because Firefox is a large program, and linking large programs takes
up a large amount of memory, more than is addressable on 32-bit
systems.

>> This means some people on older hardware or OSes aren't able build
>> Firefox, that's true,
>
> Not sure, whether an 4core i7 w/ 8GB RAM already counts as "old", but
> it's really slow on my box. I've got the impression there's stil a lot
> of room for optimizations. For example, I wonder why lots of .cpp-files
> are #include'd into one.

Because doing this actually makes builds faster and the final binary
smaller.  See https://blog.mozilla.org/nfroyd/2013/10/05/faster-c-builds/
for details.

If you had more RAM, your builds would likely be much faster.  Four
C++ compiles could easily take 1-1.5GB of memory apiece, and you would
probably like to run other programs while you compile.

There are probably many places the build can be optimized; if you have
a suggestion, please file a bug at
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Build%20Config

>> but it doesn't mean they have no way to contribute to Firefox,
>
> A CI for contributors would be very nice here. For example, I don't
> have any Windows systems for decades.

You can request level 1 commit access to our try infrastructure:
https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/
 That will enable you to build Firefox with your patches on all the
major platforms we support.

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

Re: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 24.07.2017 15:07, Mike Hoye wrote:


I have a sense that as AR gets richer and more nuanced that ambient


Are we still talking about browsers ?


--mtx

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

Re: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 24.07.2017 13:57, Ben Kelly wrote:
> On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  
wrote:

>
>> * Device orientation
>>
>
> Isn't this one required to build a decent web experience on mobile 
for some

> sites?

Could you please define "decent web experience" ?

Maybe I'm just old, but I absolutely don't want an website know anything
about my local devices. Window size and resolution is fine, but ambient
conditions seriously crossed the red line of what I'd ever allow on my
machines.

I've already started patching out that stuff.

Same for things like USB devices, or all that "cloud" stuff.


--mtx

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

Re: platform specialities

[Ralph Giles]

On Sun, Jul 23, 2017 at 8:11 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:


> I'm seeing lots of things like #ifdef XP_WIN etc.
>
> Pretty often for simple things like directory delimiters,
> some missing standard types or functions, etc.
>
> Shouldn't things belong into NSPR ?
>

Or a Path.h class under mfbt. Sounds like an improvement.

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

Re: Announcing MozillaBuild 3.0 Release

[Enrico Weigelt, metux IT consult]

On 24.07.2017 16:00, Mike Hoye wrote:

Hi,


Unfortunately we have to build _for_ a number of our supported operating
systems without being able to build _on_ those operating systems.


Is that a big problem ?

At least within Linux world, it's daily business for me (well, I'm
doing a lot of embedded projects).

Haven't tried on Windows yet. Can we crosscompile it from Linux ?
(if so, is there an howto for that ?)


That's been true for some time now; while we still support 32-bit systems,

> for example, you can't build Firefox on 32-bit systems at all due to
> memory constraints,

This raises the question: why does it take up so much memory ?

> and the new MozillaBuild system is 64-bit only due to a

variety of dependencies.


Which constraints (beside memory) ? Also on Linux ?


This means some people on older hardware or OSes aren't able build
Firefox, that's true,


Not sure, whether an 4core i7 w/ 8GB RAM already counts as "old", but
it's really slow on my box. I've got the impression there's stil a lot
of room for optimizations. For example, I wonder why lots of .cpp-files
are #include'd into one.


but it doesn't mean they have no way to contribute to Firefox,


A CI for contributors would be very nice here. For example, I don't
have any Windows systems for decades.


It'd be nice in some abstract sense to be able to bootstrap a Firefox
executable on every system we support, but the tradeoffs we'd need to
accept to do that (support costs, development velocity, actual
as-delivered product quality and a lot more) are _so_ egregiously bad
for everyone involved that there's no reasonable, much less responsible,
way we can invest any time or effort making that happen.


I'm currently trying to package tbird (52esr) for Debian/Devuan.
When I'm done, I can provide scripts for that. (maybe put the whole
build stuff into an dedicated package).


--mtx

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

Re: Keyboard APZ has landed on Inbound

[Chris Peterson]

On 2017-07-21 11:05 PM, Ryan Hunt wrote:

The patch to enable async keyboard scrolling in nightly (for all platforms
except Android) has landed on inbound.

Once this is merged to central, key scrolling will be done by the compositor
instead of on the main thread in most cases. This should bring the
responsiveness of key scrolling in line with other input methods like mouse
wheel, scroll bar, and touch dragging which have already converted to APZ.


Awesome!


There may be issues with this enabled. Please test this out, and if you find
any regressions please file bugs blocking bug 1352654.


Should that be APZ bug 1376525? Bug bug 1352654 looks like a WebRender 
bug for gradient display items.

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

Re: Phabricator Update, July 2017

[Mark Côté]

On Wednesday, 19 July 2017 16:19:02 UTC-4, Randell Jesup  wrote:
> >On 2017-07-14 1:31 AM, Jim Blandy wrote:
> >> Many people seem to be asking, essentially: What will happen to old bugs?
> >> I'm trying to follow the discussion, and I'm not clear on this myself.
> >>
> >> For example, "Splinter will be turned off." For commenting and reviewing,
> >> okay, understood. What about viewing patches on old bugs?
> >
> >Migration-specific issues are still in flux, since we have still have
> >plenty of time to sort them out.  I'll be clarifying the migration plan as
> >we get closer to turning off old tools.  So far we've agreed that keeping
> >Splinter in read-only mode to view old patches is totally fine, and Dylan
> >(BMO lead) mentioned that there are even nicer diff viewers that we can
> >integrate with BMO, like  https://diff2html.xyz/, which is currently in use
> >by Red Hat's Bugzilla installation.
> 
> Good! your recent posting made me believe you'd gone back to "splinter
> must be totally turned off".  Thanks.  I still have significant
> questions about how security-bug access and review (and security of such
> items) will work; is there a design?  What has changed since our
> discussion in May, and have you met with the security engineers and
> major security reviewers/triagers?

Some platform-security people were presented with the integration plan, but 
there wasn't much commentary.  Most of the discussion has been around 
implementation details, some of which have been quite tricky.

Not much has changed from the original plan except that we are looking into 
mirroring the CC list over as well as the security groups.  Ideally we will 
have an exact match of the set of users who can view a bug and the set that can 
view associated revisions.

Some of this stuff has already landed on our development instance.  We'll have 
some docs and screencasts to show how it works.

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

Re: who uses idl stuff

[Bobby Holley]

I might suggest having a look at https://wiki.mozilla.org/Gecko:Overview
for your general architectural questions.

On Sun, Jul 23, 2017 at 12:00 AM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> Hi folks,
>
>
> could anyone please give me some insight, where the the IDLs
> (and the code generated from them) are actually used ?
>
> Javascript bindings ?
>
>
> --mtx
> ___
> 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: [RelEng] Switching to TaskCluster Windows builds on Wednesday July 26th

[Lawrence Mandel]

What Dustin said. Thrilled to see some big jobs moving to TC. Keep pushing!

Lawrence

On Fri, Jul 21, 2017 at 3:02 PM, Dustin Mitchell  wrote:

> Nice work -- what a milestone!
>
> Dustin
> ___
> release-engineering mailing list
> release-engineer...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/release-engineering
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: sensor APIs

[Anne van Kesteren]

Please consider the request to remove device orientation retracted for
now. We'll still need to figure out some kind of long term plan for
that API though. WebVR building on it through libraries that abstract
away the browser incompatibilities will just make it harder to fix the
underpinnings going forward. (And there's always the risk that folks
don't use libraries and code directly against what Chrome ships. Seems
likely even.)

On Mon, Jul 24, 2017 at 5:07 PM, Mike Hoye  wrote:
> I have a sense that as AR gets richer and more nuanced that ambient light
> and proximity sensing will become important as well, even if we're not there
> yet.

I'm not sure that's a good reason to keep the current APIs around
though. Ambient light in particular leaks cross-origin data. It's
rather surprising we haven't acted on that thus far. And none of what
we ship ended up being standardized as such. If we actually think we
need these APIs we should put in the effort to solve the security and
standardization issues.


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

Re: Announcing MozillaBuild 3.0 Release

[Mike Hoye]

On 2017-07-22 3:13 AM, Frank-Rainer Grahl wrote:
Personally I find this a bad idea. Windows 7 and 8.1 are still 
supported till 2020 and 2023. As long as the compilers are supported 
too on them these should also be fully supported as a build environment. 
Unfortunately we have to build _for_ a number of our supported operating 
systems without being able to build _on_ those operating systems. That's 
been true for some time now; while we still support 32-bit systems, for 
example, you can't build Firefox on 32-bit systems at all due to memory 
constraints, and the new MozillaBuild system is 64-bit only due to a 
variety of dependencies.


This means some people on older hardware or OSes aren't able build 
Firefox, that's true, but it doesn't mean they have no way to contribute 
to Firefox, and restricting ourselves to only shipping a product that we 
can build directly on those older systems means giving every single 
person who relies on those systems a crap experience and a substandard 
product.


It'd be nice in some abstract sense to be able to bootstrap a Firefox 
executable on every system we support, but the tradeoffs we'd need to 
accept to do that (support costs, development velocity, actual 
as-delivered product quality and a lot more) are _so_ egregiously bad 
for everyone involved that there's no reasonable, much less responsible, 
way we can invest any time or effort making that happen.




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

Re: Keyboard APZ has landed on Inbound

[Milan Sreckovic]

In this context, we don't have the numbers for keyboard APZ; we do know 
that 14% of the page loads (last time we did a telemetry measurement) 
had non-passive event listeners.



On 23-Jul-17 22:05, Ryan Hunt wrote:

We will not do keyboard APZ, even if the event listener is marked passive.

Passive only restricts the use of preventDefault, and we also care about whether
the event listener changes the focus or selection of a page.

An example where this matters would be a page with a key listener that sets the
focus of the page to a . If the user were to hit space twice, they 
would
expect the first space to scroll the page, and the second to be input into the
.

With keyboard APZ enabled we can't guarantee that to happen, as the focus
of the page can't be guaranteed to sync to APZ in time for us to know not to
scroll the root scroll frame again.

It's not clear whether this is behaviour that is widely relied on. We're 
attempting
to be conservative in the cases we allow this.

Let me know if the example is unclear.

Thanks,
Ryan


From: Ben Kelly 
Sent: Sunday, July 23, 2017 12:26 PM
To: Ryan Hunt
Cc: dev-platform@lists.mozilla.org
Subject: Re: Keyboard APZ has landed on Inbound

On Sat, Jul 22, 2017 at 2:05 AM, Ryan Hunt 
> wrote:
Keyboard APZ can't be used in every case. Currently it's disabled in the
presense of key event listeners, as they can preventDefault scrolling and that
is a non-negotiable part of the web.

Do we do keyboard APZ if the event listener is passive:true?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


--
- Milan (mi...@mozilla.com)

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

Re: Intent to remove: sensor APIs

[Blair MacIntyre]

True, true.  For example, if the ambient light sensing could deliver the kind 
of “estimation of ambient lighting” that Apple’s ARKit does, we could use that 
in rendering.

But, one question will be:  what of these capabilities should just be part of 
“WebAR”, and which can be used effectively independent of WebAR?  Especially 
when we think of issues discussed on this thread (e.g., threat models and 
security) having “things needed for AR” folded into WebAR, and accessible in 
the context of whatever permission model WebAR ends up using may be the way we 
want to go.

--
Blair MacIntyre
Principal Research Scientist
bmacint...@mozilla.com 




> On Jul 24, 2017, at 11:07 AM, Mike Hoye  > wrote:
> 
> 
> I have a sense that as AR gets richer and more nuanced that ambient light and 
> proximity sensing will become important as well, even if we're not there yet.
> 
> - mhoye
> 
> On 2017-07-24 10:39 AM, Blair MacIntyre wrote:
>> I was just about to say the same thing.  This API is essential for our AR 
>> work;  the fact that Firefox is different than other browsers is 
>> problematic, but there are javascript libraries that help with it.  Getting 
>> rid of it would be really bad.
>> 
>>> On Jul 24, 2017, at 9:57 AM, Ben Kelly >> > wrote:
>>> 
>>> On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren >> > wrote:
>>> 
 * Device orientation
 
>>> Isn't this one required to build a decent web experience on mobile for some
>>> sites?  It seems pretty common on mobile to adjust the UX based on whether
>>> the device is in portrait/landscape orientation.
>>> ___
>>> 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 remove: sensor APIs

[Mike Hoye]

I have a sense that as AR gets richer and more nuanced that ambient 
light and proximity sensing will become important as well, even if we're 
not there yet.


- mhoye

On 2017-07-24 10:39 AM, Blair MacIntyre wrote:

I was just about to say the same thing.  This API is essential for our AR work; 
 the fact that Firefox is different than other browsers is problematic, but 
there are javascript libraries that help with it.  Getting rid of it would be 
really bad.


On Jul 24, 2017, at 9:57 AM, Ben Kelly  wrote:

On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  wrote:


* Device orientation


Isn't this one required to build a decent web experience on mobile for some
sites?  It seems pretty common on mobile to adjust the UX based on whether
the device is in portrait/landscape orientation.
___
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 remove: sensor APIs

[Blair MacIntyre]

I was just about to say the same thing.  This API is essential for our AR work; 
 the fact that Firefox is different than other browsers is problematic, but 
there are javascript libraries that help with it.  Getting rid of it would be 
really bad.

> On Jul 24, 2017, at 9:57 AM, Ben Kelly  wrote:
> 
> On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  wrote:
> 
>> * Device orientation
>> 
> 
> Isn't this one required to build a decent web experience on mobile for some
> sites?  It seems pretty common on mobile to adjust the UX based on whether
> the device is in portrait/landscape orientation.
> ___
> 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 remove: sensor APIs

[Ben Kelly]

On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  wrote:

> * Device orientation
>

Isn't this one required to build a decent web experience on mobile for some
sites?  It seems pretty common on mobile to adjust the UX based on whether
the device is in portrait/landscape orientation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

IDL vs ifdef

[Enrico Weigelt, metux IT consult]

Hi folks,


I'm currently in process of making the media stuff optional.
(dont need/want it within mail client).

Unfortunately, it idl files are referenced by lot of others.
Just adding some #ifdef's around these places doesn't work.

Any idea to achieve this ?


--mtx


mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing MozillaBuild 3.0 Release

[Enrico Weigelt, metux IT consult]

On 21.07.2017 22:52, Gregory Szorc wrote:

Hi folks,


The plan from build system land is to attempt to go "all in" on Windows
Subsystem for Linux (WSL). That's the feature in Windows 10 (and even in
Server additions now) that implements Linux syscalls inside the Windows
kernel and allows you to run Linux binaries "natively" on Windows. The
performance is pretty good and it is a better Linux-on-Windows approach
than msys ever will be.



Does that mean, all the Windows specific stuff (at least except gui)
can now be dropped ?


--mtx

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

[Firefox Desktop] Issues found: July 17th to July 21st

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *July 17 - July 21* (week 29).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1383110 
Controllers are positioned inside the headset
CoreWebVR
NO  NOBODY
1383107 
[VR] Browser crash if the user opens a different page in a new tab
Core
WebVR
NO  NOBODY
1383106 
The device glitches on some demos
Core
WebVR   NO  NOBODY
1383105 
Game freezes in the VR device
CoreWebVR   NO  NOBODY
1383104 
	Refreshing the VR page causes the VR device to have jerky movements or 
crash

CoreWebVR   NO  NOBODY
1383099 
Closing the VR webpage causes the VR to remain frozen
CoreWebVR   NO  NOBODY
1383097 
Freeze in https://aframe.io/a-painter/
CoreWebVR   NO  NOBODY
1383095 
Misleading prompt   CoreWebVR   NO  NOBODY
1383094 
Unplugging your VR device displays no error prompt
CoreWebVR   NO  NOBODY
1381813 
Google Play can't be added in the Search bar as a new search engine
Tech Evangelism
Desktop
NO  NOBODY
1383032 
	Intermittent test_direct_update.py TestDirectUpdate.test_update | 
JavascriptException: ReferenceError: log is not defined

Testing
Firefox UI Tests
NO  NOBODY


*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1382660 
Active area for some checkboxes has changed since Preferences re-org
Firefox
Preferences
	YES 
 
	Evan Tseng 

1382247 
Crash in @0x7fffbd1729f7
Core
Widget: Cocoa
NO  NOBODY



*ESR CHANNEL*
none


Regards,
Cornel (:cornel_ionce)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: sensor APIs

[Anne van Kesteren]

As a follow-up to the Ambient Light Sensor API thread, which ended up
not really concluding, I hereby suggest we remove the various sensor
APIs from our code base. Flipping the preference first to make sure
there's no undue impact on web content and quick reversal is possible
and then removing the code in a later release.

This affects these APIs:

* Ambient light
* Proximity
* Device orientation

The rationale:

* These APIs have various privacy leaks, including violating the
same-origin policy, without the user being informed.
* These APIs do not match the current standards for sensor APIs and
some are incompatible with what is being shipped by Chrome (e.g.,
device orientation).
* There's no interest to address these shortcomings. (Mostly in the
sense of engineering resources and having other problems to tackle
first.)
* As these are event-driven APIs the compatibility impact should be
minimal to none. The events simply won't fire.

The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1359076


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

Re: git mirror

[Frederik Braun]

You could also look at git-cinnabar.
It's a git helper that allows you to talk to HG remotes developed by
Glandium, a Mozilla hacker.

See

for more

Hope this helps,
Freddy

P.S: If you only want to look at code and search for stuff, I can
recommend https://searchfox.org/


On 22.07.2017 21:42, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
> 
> 
> are there any official git mirrors (at least for the esr branches),
> that are regularily updated ?
> 
> The repos is *really* huge - import really takes a long time (started
> about 10hrs ago, still just not much over 10%). Github even gives up.
> Even hg clone runs for hours.
> 
> I'm looking for an git repo, where I can do a (shallow) clone from,
> that also receives updates from the hg master.
> 
> 
> thx
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform