Re: Rationalising Linux audio backend support

[Enrico Weigelt, metux IT consult]

On 29.09.2017 19:26, t...@tomsbox.co.uk wrote:

As someone who has had wonderful times with ALSA & headaches with PA it's time 
to say goodbye FireFox.


Maybe we should have a closer look at the PA library API, whether it
could be usable w/o the pa daemon. IOW: have libpulse implementations
that directly call the native APIs (eg. ALSA on Linux or directsound
on windows).

Another idea could be creating a *thin* (!) API layer, that bridges
to backends of the operator's choice. This, of course, should be 
independent of moz and in plain C, so it can be used by many other

projects having the same problem, instead of yet another private layer.


--mtx

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

Re: Device Memory header and JS API

[Enrico Weigelt, metux IT consult]

On 07.09.2017 23:30, Daniel Veditz wrote:

​Without some kind of signal everyone gets the least-common-denominator 
version of a site 


Exactly. That was the idea behind the web. Unfortunately, so many
things have been added in recent years that browsers became more
complex than operating systems and web coders take lots of dubious
assumptions (gladly, they meanwhile learned not to dictate screen
resolutions anymore :o), and the code of major sites becomes worse
day per day.

Just compare Facebook vs. VK: same functionality - FB is extremly
slow and fat, VK is very slim and fast. Ergo: folks like FB should
just do their homework (or become optimized-away someday).

(and even then older equipment or phones may result in 
a poor experience) or sites will try to guess based on user-agent.


Well, it's been a while since I was actively building web apps,
(when PCs were slower than today's cheap smartphones). I can't
recall any case where I had wished such an feature. My applications
also worked well even on the early smartphones (eg good old Nokia
communicator).

For images and things maybe CSS could specify some media queries that 
loads different resources based on local factors like amount of memory 
or network speed, but then that's leaking the same information just in a 
different way.


Not necessarily, and not in the same granularity. Of course it would be
better, if requests to css+co wouldn't send cookies.
(IMHO, cookies are a very bad invention to begin with)


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

Re: Firefox 55.* in Windows/Ubuntu - every day CPU 100%/Hangs Up. Please to do something!

[Enrico Weigelt, metux IT consult]

On 06.09.2017 09:45, Alexey Zvyagin wrote:


In both OSes i regulary and every day i see the situation when after few work time (may be even 
after 1-5 minutes) of Firefox i see the CPU 100% of Firefox and the Firefox hangs up after... Only 
one way i have for repairing of this: "killall -HUP firefox" command at Ubuntu and 
"End Task" in Windows.


No idea whether it's related - I'm regularily observing similar
problems in older version (eg. 49) - but in my case it comes back
again (sometimes takes several minutes). The problem increases with
the numeber of tabs and seems to happen especially while loading.
A hard case is ebay, maybe because it loads lots of extra urls.

Similar problems w/ TB - busy w/ 100% load for several minutes
and then comes back. (a long existing problem w/ TB). There's a theory
that this could be related to JS GC, but we don't have an good idea
for deeper analysis yet - maybe somebody here has a hint ?


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

Re: Device Memory header and JS API

[Enrico Weigelt, metux IT consult]

On 05.09.2017 19:13, Shubhie Panicker via dev-platform wrote:

Hi,

Boris expressed privacy concern with the API and suggested starting a > thread here to get some concrete feedback. We would love to get this> 
feedback and are open to updating the header and API as it would be 
great> to get FF behind this API.

I fully agree. There're already too many similar security problems.
(maybe it's different between countries/cultures, but over here in
Germany we *do* care about privacy.)

Optimally, the browser should tell nothing about the client - web
content should written in a way that it works independent from the
actual client. At least that's how the web originally was designed.

I'd also question the practical usecase. For example, video hosters
already have settings for video quality - which, btw has only small
relation to available memory (bottlenecks are bandwidth and cpu or
vpu power). Adding such an Header/API here just risks web coders
taking even more silly assumptions and adding even more bad code.

Also serving a "light version" of sites like Facebook or Google
Analytics (like mentioned in the google maillist) doesn't seem to be an
good use case to me, too:

#1: Facebook delivers really, really bad code. No idea how they do it,
but typing something sometimes takes several seconds per char. Scrolling
sometimes takes minutes, etc, etc (w/ multiple tabs that even goes up
exponentially) - in Chrome as well as FB. It's just beyond repair.

In contrast, VK just flashes. Quick and simple (like Google once was)
Ergo: when VK provides quite the same functionality w/o any performance
problems (and actually, that isn't such a big deal at all), then FB
is just doing it terribly wrong. I really wonder why such a big company
doesn't get their tech in order.

Well, if FB would honor such an header and serve a really light version
(I have my doubts), then I'd vote for hard-coding 128MB

#2: Google Analytics shouldn't be supported at all - they already far
too invasive (if it wouldn't open pandorra's box, I'd even vote for a
law for blocking them on ISP core routers) - I've blocked them on
my routers.

OTOH, I do see a valid case for *users* (not the computer on its own)
deciding on certain content preferences - on a per-site basis.

But that wouldn't be memory (*ideally*, normal user processes shouldn't
even care how much memory is in a box - let the kernel handle that),
instead things like max. video resolution, sound quality (I'm personally
fine w/ mono, as I only have one operating ear ;-)), etc. Such a setting
should be easily switchable any time (eg. I'm often listening to radio
shows @yt and switch to lowest resolution to save cpu cycles).

BTW: video playback can be much more efficient when using VPUs
(hw-codecs) - especially for embedded/mobile devices. But the 
hw-configuration, and therefore optimal pipeline is pretty device

specific, so it has to be configurable. The best option IMHO would
be using gst and let the user/operator specify the actual pipeline.


--mtx

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

Re: refcounting - which types to use ?

[Enrico Weigelt, metux IT consult]

On 17.08.2017 04:03, Shih-Chiang Chien wrote:
You should use |forget| to transfer the ownership of the nsIArray from 
list to _retval.


Ok, thanks. Already suspected that (found some similar things in the
code). Could we update the docs (maybe some set of examples) ?

IIRC, there're some places that do it like in my prev mail, which I took
as example (just forget where exactly that was) - should that be fixed ?

By the way: is there a difference between out parameters and rval ?
Or can I just assume, rval's are equivalent to an out parameter ?

OTOH, is there a way to create versions that really return it as rval,
so I conveniently could just call like that ?

   nsCOMPtr list = addrbook->FindRecipients(addr);


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

Re: Intent to ship version 4 of the Safe Browsing protocol

[Enrico Weigelt, metux IT consult]

On 16.08.2017 12:40, Gijs Kruitbosch wrote:


This and other queries like it are best asked and answered on  > 
https://support.mozilla.org/ .


Unfortunately, it only tells how to switch some things off, but
not to remove it entirely. Neither does it tell anything about the
security implications of sending meta data to dubious corporations.

Furthermore, just like with your  > next-most-recent posts (about nsString and printf, and about CIDs), 

the > answer is already documented and easily found using a web search:
If the docs wouldn't answer all my questions, I wouldn't have asked in
the first place. I'd volunteer to update the docs, but obviously I need
the proper information for that first.

https://developer.mozilla.org/en-US/search?q=printf

--> nothing about using printf() here :(

Regarding CID vs CONTRACTID - still haven't understood why CIDs are
random numbers, instead of human-readable names (similar to hierarchical
class names, eg. "org.mozilla.collections.array) ?

And still I find the naming "CID" (class-ID ?) vs "CONTRACTID" quite
confusing. Why not something like "INTERFACEID" or "PROTOCOLID" vs.
"SERVICEID" ?

The term "contract" isn't entirely obvious (to non-moz folks), it's
often used for interface (the way I can talk to something), instead
of a collection of interfaces / a service that might have multiple
interface.

I also believe your reflexive responses along the line of "how can I get  > a version of Firefox that doesn't have X" for every X (you don't 

like) > that happens to come up in this group are unproductive.

This "reflex" comes from the tendency that more and more things are
added - even things that contradict the whole spirit of free software,
like despotic restriction management (even downloads the malware on
its own) - and then we downstreams (packagers, integrators, operators)
have the huge burden of getting these things under control.

Please also consider, that there's more than average John Doe user,
and there're lots of reasons for disabling things (not even compile
them in the first place). Limited resources may be one of them.
Security concerns, managebility, etc, may be others. One's killer
feature can be another one's misfeature. Therefore it's important
that things can be turned off / removed easily (the optimum would
be external components that can be deployed separately).

A bunch of configure options are currently broken, some can't be
easily repaired (w/o touching xpidlgen to add preprocessor).

The answer to that last question is almost invariably "no". There are  > usually prefs while features are being developed, but those will > 
frequently get removed when features are mature enough that we don't > 
think turning them off is web-compatible.


How exactly is "web-compatible" specified here ?
Does it include $megacorp's servers or automatically download
and execute arbitrary binaries or allow tracking users ?

Firefox and Gecko are  > explicitly *not* aiming to have 42,000 build-time defines to remove > 

every conceivable feature that someone might not want.

Doesn't need to be that much. Less than hundred should be sufficient,
and most of them should be orthogonal to the rest.


--mtx

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

refcounting - which types to use ?

[Enrico Weigelt, metux IT consult]

Hi folks,


I'm still a bit confused on which types (nsCOMPtr, ...) to use when
exactly, in combination w/ IDLs.

Let's consider a case where an nsArray is created and returned
(as rval, not out-parameter):

IDL:

[scriptable, uuid(ea0d8b3d-a549-4666-82d8-3a82cee2a3f1)]
interface nsIAddrBookService : nsISupports
{
nsIArray FindRecipients(in AString name);
...
}

C++:

/* nsIArray FindRecipients (in AString name); */
NS_IMETHODIMP nsAddrBookService::FindRecipients(const nsAString & addr, 
nsIArray * *_retval)

{
nsresult rv = NS_OK;
nsCOMPtr list =
do_CreateInstance(NS_ARRAY_CONTRACTID, );
NS_ENSURE_SUCCESS(rv, rv);
*_retval = list;
return FillRecipients(addr, list);
}

I'd assume that do_CreateInstance() returns the object w/ refcnt=1.
The assignment to nsCOMPtr should increase refcount. Correct ?
When the function is left, the nsCOMPtr is destroyed, and refcnt
goes back to 1 (we now have a reference left in the caller's pointer
field).

Now the caller side: (inspired by various examples ...)

nsCOMPtr list;
rv = addrBookService->FindRecipients(
splittedRecipients[j].mEmail,
getter_AddRefs(list));

I'd guess getter_AddRefs() causes refcnt to be increased again, so
we're back at 2. That could lead to a leak, when that function returns
(and doesn't pass the ref anywhere else).

So, should I use dont_AddRef() here ?

Is the situation different when using out parameter instead of rval ?


BTW: what happens when passing nsCOMPtr as a reference (w/o IDL) ?

Assume the following code:

void caller() {
nsCOMPtr ref;

callee(ref);
ref->Something();
}

void callee(nsCOMPtr & outref) {
nsCOMPtr myref = do_CreateInstance(...);
...
outref = myref;
}

I'd assume that the last line will fill the caller's ref field w/ the
pointer and increase the object's refcnt (so it's 2 now), then when
callee is left, its myref is destroyed and refcnt is back to 1.

Is that correct ?


--mtx

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

Re: Intent to ship version 4 of the Safe Browsing protocol

[Enrico Weigelt, metux IT consult]

On 16.08.2017 01:46, Francois Marier wrote:

After a year's worth of development, bug fixes, and integration testing,
we are now ready to enable the latest version [1] of the Safe Browsing
API in Firefox 56, two releases ahead of schedule and only a few weeks
behind Chrome.


How can I get rid of that ?
I don't want my browser to call google servers, nor do I want allow
google to decide what's malware and what's not.

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

ns*String vs. printf()

[Enrico Weigelt, metux IT consult]

Hi folks,

what's the best way to print out ns*String classes via printf ?
Using ToNewUTF8String or converting to nsCString to use it's get(),
doesn't feel like the best approach ...


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

what are CIDs for ?

[Enrico Weigelt, metux IT consult]

Hi folks,


I wonder what exactly the CID's (*_CID defines) are for. IIRC, the
classes are looked up via their contract-IDs (*_CONTRACTID defines),
but I haven't seen anything that actually uses the CIDs.


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

Re: webidl: partial interfaces and build-time configuration

[Enrico Weigelt, metux IT consult]

On 07.08.2017 17:17, Boris Zbarsky wrote:


Can I move that stuff to a separate webidl file, which is only
added in dom/webidl/moz.build when wakelocks enabled ?
(so no #ifdef's in Navigator.webidl needed)


If you try to do this, you will get a message from binding codegen that 
explicitly says this is not supported:


   TypeError: The binding build system doesn't really support partial
   interfaces which don't appear in the file in which the interface they
   are extending is defined.  Don't do this.

Of course using partial interfaces can make the #ifdef bits simpler in 
some cases.


hmm, then what are the partial interfaces actually for ?

I had the impression that distributing (potentially optional) parts of
the interface over several files was exactly the usecase behind.

--mtx
--
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: Restricting the Notifications API to secure contexts

[Enrico Weigelt, metux IT consult]

On 07.08.2017 15:45, Anne van Kesteren wrote:

Chrome wants to restrict the Notifications API
https://notifications.spec.whatwg.org/ to secure contexts:


wait a second ... it was wide open all the time ?


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

Re: webidl: partial interfaces and build-time configuration

[Enrico Weigelt, metux IT consult]

On 07.08.2017 10:31, Gabriele Svelto wrote:

On 06/08/2017 21:56, Enrico Weigelt, metux IT consult wrote:

For example, I'm currently working on making the whole wakelock
stuff optional (eg. only built on android). Navigator.webidl
references MozWakeLock, which wouldn't exist w/o wakelocks.


Do you mean navigator.requestWakeLock()? That's deprecated and should be
removed altogether.


Okay, added it to my pipeline.
Are there more wakelock-related things to be removed ?

Anyway, my question is more genric: can we get rid of #ifdef's in
*.webidl files by partial interfaces in separate file ?
(also affects other things, eg. gamepad)


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

webidl: partial interfaces and build-time configuration

[Enrico Weigelt, metux IT consult]

Hi folks,

is there a way to use the partial interfaces for build-time
configurable features ?

For example, I'm currently working on making the whole wakelock
stuff optional (eg. only built on android). Navigator.webidl
references MozWakeLock, which wouldn't exist w/o wakelocks.

Can I move that stuff to a separate webidl file, which is only
added in dom/webidl/moz.build when wakelocks enabled ?
(so no #ifdef's in Navigator.webidl needed)

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

Re: Rationalising Linux audio backend support

[Enrico Weigelt, metux IT consult]

On 05.08.2017 07:27, kichu...@gmail.com wrote:

Hi folks,


You're right. I have a sound card that supports mixing and all other necessary 
stuff in hardware, why shoud I waste my CPU for doing that with pulseaudio?
Long time ago I switched from Opera to Firefox... maybe it's time to switch 
back.


haven't followed the whole thread, but let me add a few thoughts:

Few month ago I had a discussion w/ PA folks about non-Linux platforms.
It seems that it works well on win32, mac, bsd, etc (not tested
myself).

So, why not just using libpulse directly (w/o any extra layers) ?
Folks who don't wanna have the PA daemon in between could patch up
libpulse to talk to the actual device directly.

That way, we'd have moved out all the platform specific logic to an
already widely adopted subsystem and therefore less own code to
maintain.


--mtx

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

Re: Intent to remove: EME support on insecure contexts

[Enrico Weigelt, metux IT consult]

On 04.08.2017 04:04, Chris Pearce wrote:

Summary:
Encrypted Media Extensions on insecure contexts (i.e. web sites served over 
non-HTTPS) is deprecated and will soon stop working in Firefox.

Sites wanting to use EME should switch to HTTPS if they have not already.


Let me add another request here: allow builds completely w/o EME.

While trying to build moz/tbird w/o the codecs, I've observed that
some EME stuff (depending eg. on FMP4) does get build, even w/
--disable-eme.

I've got a patch for fixing the codec build problem here. Couldn't
submit yet - still having problems w/ git+hg ...

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

Re: security problems [WAS: Intent to remove: sensor APIs]

[Enrico Weigelt, metux IT consult]

On 02.08.2017 15:53, Blair MacIntyre wrote:


FWIW, I wouldn’t mind being involved in a discussion about this,

> if people want to seriously consider putting it behind a
> "user-permission prompt"  (similar to geolocation) or

"user-action requirement”


I'd even go further and move it to an extra package, that may not even
be deployed in the first place.

One major reason is that browsers are often used on system where we
can't always trust the user to always take the right decisions.
Scenarios could be my 90rs old grandpa (who's already annoyed by all
that web-2.0 stuff) or business machines where companies wanna protect
themselves from espionage etc (similar to banning smartphones w/
cameras from their facilities, etc.

The more of those things are added to the browser, the harder it gets
to manage this. Sooner or later we'll get to a point where FF is just
banned (or forked). I doubt that this is your intention.


There has been discussion of this issue in the WebVR community, for

> example, noting that in WebVR, you don’t get any device reports
> without a user action requesting the “VR”.

By device reports you mean calling home ?


On top of that, there is very likely a need to not just “ask once at

> the start” but toggle access to sensitive info on/off as the user uses
> a web app

And there should be a manual control (eg. via keys or mouse gestures),
w/o the web app noticing that it's manual.

There's even more: the user also needs control over where the data
is actually coming from (eg. which device exactly). Otherwise that
fancy feature will only be usable in some specific usecases.


I think as we move toward exposing AR technology (like Tango, ARKit,

> Windows Holographic) in web user-agents, we may need to rethink how
> we obtain and manage the data user’s give to pages.

Yes, that's a very vital issue. And I'd also suggest which parts of that
are implemented *inside* the browser at all (vs external applications)

> I believe that respecting user privacy and supporting their ability
> to control information flow may actually be the thing that makes the

web a preferred platform for AR/VR,


Perhaps we should also rethink what "the web" *actually* means here.
Does everything that the web might offer need to run inside the
browser ? Does that mean the browser has to become an kind of own
operating system ?


since the various platforms are giving all data to apps automatically,

> which create a “take it or leave it” attitude regarding privacy and
> sensor information.

An important point here is that it's easy to leave it. If you don't want
to run any proprietary code, just don't do it. Period. And it doesn't
seem to be easy making great number of people dependent on it.

OTOH, if these things are already integrated in the browser, it isn't
so easy anymore. It quickly becomes an all or nothing decision.


Anyway, if folks want to discuss this, let me know.  We should probably move 
off this thread?


Agreed, for the WebVR stuff (maybe should be even discussed on a
separate list). In general, I'd just like to highlight that
security is a vital aspect.


--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 02.08.2017 14:39, Blair MacIntyre wrote:


It’s used for panoramic image viewing (orient the pano with the camera
movement), and google street view uses it for similar motion control.


Okay, why not adding a generic interface for controlling the virtual
view direction ? So, the user/operator could decide how to control it
(keys, mouse gestures, external 3d positioning devices, etc).

Anyways, I wonder how the current approach would work at all with
non-portable devices. And the idea of having to physically turn around
just to see different perspectives seems really weird to me.


Regarding security:  perhaps it is, I have seen discussions of this
sort.


Allowing webites to track individual movements, IMHO qualifies more
than just an "perhaps". Do you feel well with the idea of being tracked
with every single footstep ?

> But, it would seem that ship sailed when the W3C approved it, and

now it’s common and assumed and relied upon. Removing it in Firefox
would render Firefox incompatible with a growing use of the web,


Okay, we now know that was a wrong assumption - but even it was
really was approved: does that mean we have to support anything that
some beaurocrats find a good idea ?

In the past, there have been lots of standards that peopel stopped
supporting / complying to, because they turned out to be a bad idea.
I still remember when leaded fuel was standard - meanwhile it's even
prohibited (except for a few old timers). I also remember when IPX
or DecNet have been de-facto standards. Flash has been a de-facto
standard, it was a security nightmare, and it took a long time to get
rid of it.

What would you do if W3C decided that web applications shall be allowed
to execute arbitrary binaries with user's full privileges ?
(actually, I wouldn't be surprised if Goverments making such laws ...)


especially mobile (including Windows tablets).


What would be the actual impact ? A few websites that rely on that
won't work completely anymore. Actually, haven't seen single one yet.

Is it okay, to sacrify the security of all users just for the joy of
that small minority ?


This might be a discussion the security team wants to have, I guess:

> is the Firefox team worried enough about the threats opened by this
> API to justify breaking a large class of applications, and making

Firefoxunusable for AR/VR moving forward.


Suggestive question. And implies that this "large class of applications"
actually exists already.

I'd prefer asking: is it okay to sacrifice security for some niche
features ?

OTOH, I'd also question whether that AR/VR really belongs into a
browser, and what's the costs and risks of that. (some countries
already started legislation against AR, most notably Pokemon Go, for
good reasons ...).

Certainly, AR/VR has it's use in some industrial applications or
entertainment machines, but I doubt Browsers and HTML are particular
well suited for those jobs.



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

security problems [WAS: Intent to remove: sensor APIs]

[Enrico Weigelt, metux IT consult]

On 02.08.2017 14:29, Michael Hoye wrote:


You need to dial this rhetoric back about 100%. It is not acceptable to
bring even an implied accusation like that to a technical discussion, or
indeed any conversation at all, at Mozilla.


Who did I accuse of what exactly ?

All I'd like to say here is that those features add yet another tool
for mass sourveillance.

I've grown up in the GDR regime - I've learned what it means when your
privacy is invaded or you get punished because somebody in your family
or a neighbor said a wrong word.

And we're strongly marching towards the same again, but now with the
oppressors having much better technology, in our bedrooms. It's not
fiction, it's fact - it's already there. Spying phone apps everywhere,
even spying TV sets, remote controllable cards, etc, etc.

Quite recently, the German parliament voted yet another enabling act
for mass sourveillance (eg. wiretapping people just because some
neighbour or colleque *might* possibly have done a tax fraud, etc).
And they did what w/ only a small minority of the representatives
even present (reminds me to 1933).

So, the problem is very immanent. We need to be very careful here,
which information to send out (or even aquire in the first place).
Various fingerprinting techniques already impose a big problem
(IMHO, generic cookies should never have been introduced in the
first place).


We're always happy to listen to honest criticism and walk back our
mistakes, but we are going have those discussions without demeaning the
work or comparing the people doing that work to volkscryptopolitzei
collaborators.


Please. I didn't imply anybody here collaborating with dark forces.
I'm just warning about the danger of these features.

At least these things should be purely optional and providing an
*easy* way to filter that data. (same for the geolocation stuff).


--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 02.08.2017 13:01, Salvador de la Puente wrote:

I strongly encourage you to take a look at the telemetry stats regarding
the usage of deviceorientation API and other. I don't know the penetration
of proximity and ambient light APIs but deviceorientation is definitively
used.


Just curious: for what exactly is it used ?

For rendering / GUI, I'd assume that the job of the windowing system /
compositor - the application would just see a window geometry change.

Making that information visible to websites (even worse: movement
tracking via g-sensor, etc), definitively looks like security nightmare
which even the Stasi never dared dreaming of.

--mtx

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

Re: nodejs for extensions ?

[Enrico Weigelt, metux IT consult]

On 31.07.2017 20:30, David Teller wrote:

Node dependency trees tend to be pretty large, so I'm a little concerned
here. Has the memory footprint be measured?


That would also concern me (OTOH, moz's footprint already is as large as
a small skyscraper anyways ;-)).

We also have similar problems jscript-intensive websites.
Maybe there could be a way of sharing node modules between extensions ?

In the optional case, I'd like to have an extension actually being a
node modules, managed via npm or distro's package manager.

But I've got the feeling, that would require a fresh start w/ moving
that completely out to separate server processes: gecko exports some
IPC interface which extensions can call into, eg. request becoming a
filter for url pattern, retrieve and change a DOM subtree, trigger
certan actions, etc. When we even add docking windows to a dom element,
we'd also have the most vital parts for generic plugins.
This approach isn't even bound to javascript or nodejs - these
extensions could be written in any language.


--mtx

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

refcounting [WAS: More Rust code]

[Enrico Weigelt, metux IT consult]

On 31.07.2017 13:53, smaug wrote:




Reference counting is needed always if both JS and C++ can have a
pointer to the object.


By the way - just curious:

Anybody already thought about garbage collection ?

That wouldn't have the problem w/ circular graphs, and should make the
whole code smaller and faster.


--mtx

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

Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Enrico Weigelt, metux IT consult]

On 31.07.2017 09:23, Cameron McCormack wrote:

Hi Enrico,

Firefox patches should be submitted via Bugzilla, rather than by email
to dev-platform.  Please see:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_-_Get_your_code_reviewed


Is there a way to submit via mail ? Or some git-send-email counterpart ?

Always going through the web frontend manually would be pretty time
consuming ...


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

[PATCH] gfx: 2d: DrawTargetCairo: drop unused surface types

[Enrico Weigelt, metux IT consult]

Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weig...@gr13.net>
---
 gfx/2d/DrawTargetCairo.cpp | 10 --
 1 file changed, 10 deletions(-)

diff --git a/gfx/2d/DrawTargetCairo.cpp b/gfx/2d/DrawTargetCairo.cpp
index c0e4f0af2..66e3f8854 100644
--- a/gfx/2d/DrawTargetCairo.cpp
+++ b/gfx/2d/DrawTargetCairo.cpp
@@ -642,31 +642,21 @@ DrawTargetCairo::GetType() const
 case CAIRO_SURFACE_TYPE_PS:
 case CAIRO_SURFACE_TYPE_SVG:
 case CAIRO_SURFACE_TYPE_WIN32_PRINTING:
-case CAIRO_SURFACE_TYPE_XML:
   return DrawTargetType::VECTOR;
 
-case CAIRO_SURFACE_TYPE_VG:
-case CAIRO_SURFACE_TYPE_GL:
-case CAIRO_SURFACE_TYPE_GLITZ:
 case CAIRO_SURFACE_TYPE_QUARTZ:
-case CAIRO_SURFACE_TYPE_DIRECTFB:
   return DrawTargetType::HARDWARE_RASTER;
 
-case CAIRO_SURFACE_TYPE_SKIA:
 case CAIRO_SURFACE_TYPE_QT:
   MOZ_FALLTHROUGH_ASSERT("Can't determine actual DrawTargetType for 
DrawTargetCairo - assuming SOFTWARE_RASTER");
 case CAIRO_SURFACE_TYPE_IMAGE:
 case CAIRO_SURFACE_TYPE_XLIB:
 case CAIRO_SURFACE_TYPE_XCB:
 case CAIRO_SURFACE_TYPE_WIN32:
-case CAIRO_SURFACE_TYPE_BEOS:
-case CAIRO_SURFACE_TYPE_OS2:
 case CAIRO_SURFACE_TYPE_QUARTZ_IMAGE:
-case CAIRO_SURFACE_TYPE_SCRIPT:
 case CAIRO_SURFACE_TYPE_RECORDING:
 case CAIRO_SURFACE_TYPE_DRM:
 case CAIRO_SURFACE_TYPE_SUBSURFACE:
-case CAIRO_SURFACE_TYPE_TEE: // included to silence warning about 
unhandled enum value
   return DrawTargetType::SOFTWARE_RASTER;
 default:
   MOZ_CRASH("GFX: Unsupported cairo surface type");
-- 
2.11.0.rc0.7.gbe5a750

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

[PATCH] mfbt: Poison: drop obsolete OS2 support

[Enrico Weigelt, metux IT consult]

Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weig...@gr13.net>
---
 mfbt/Poison.cpp | 34 +-
 1 file changed, 1 insertion(+), 33 deletions(-)

diff --git a/mfbt/Poison.cpp b/mfbt/Poison.cpp
index b2767011d..e9981764f 100644
--- a/mfbt/Poison.cpp
+++ b/mfbt/Poison.cpp
@@ -14,7 +14,7 @@
 #include "mozilla/Assertions.h"
 #ifdef _WIN32
 # include 
-#elif !defined(__OS2__)
+#else
 # include 
 # include 
 # ifndef MAP_ANON
@@ -76,38 +76,6 @@ GetDesiredRegionSize()
 
 #define RESERVE_FAILED 0
 
-#elif defined(__OS2__)
-static void*
-ReserveRegion(uintptr_t aRegion, uintptr_t aSize)
-{
-  // OS/2 doesn't support allocation at an arbitrary address,
-  // so return an address that is known to be invalid.
-  return (void*)0xFFFD;
-}
-
-static void
-ReleaseRegion(void* aRegion, uintptr_t aSize)
-{
-  return;
-}
-
-static bool
-ProbeRegion(uintptr_t aRegion, uintptr_t aSize)
-{
-  // There's no reliable way to probe an address in the system
-  // arena other than by touching it and seeing if a trap occurs.
-  return false;
-}
-
-static uintptr_t
-GetDesiredRegionSize()
-{
-  // Page size is fixed at 4k.
-  return 0x1000;
-}
-
-#define RESERVE_FAILED 0
-
 #else // Unix
 
 #include "mozilla/TaggedAnonymousMemory.h"
-- 
2.11.0.rc0.7.gbe5a750

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

[PATCH] old-configure: startupcache: check for zipwriter

[Enrico Weigelt, metux IT consult]

startupcache depends on zipwriter.
when enabled, check that zipwriter is also enabled.

Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weig...@gr13.net>
---
 old-configure.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/old-configure.in b/old-configure.in
index daa593bfa..d76ebd547 100644
--- a/old-configure.in
+++ b/old-configure.in
@@ -4662,6 +4662,10 @@ if test -n "$MOZ_B2G"; then
 fi
 if test -n "$MOZ_DISABLE_STARTUPCACHE"; then
   AC_DEFINE(MOZ_DISABLE_STARTUPCACHE)
+else
+  if test -z "$MOZ_ZIPWRITER" ; then
+AC_ERROR([startup cache depends on --enable-zipwriter])
+  fi
 fi
 AC_SUBST(MOZ_DISABLE_STARTUPCACHE)
 
-- 
2.11.0.rc0.7.gbe5a750

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

[PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Enrico Weigelt, metux IT consult]

For now, our GfxSurfaceType enum (and things depending on it) is tightly
coupled to cairo_surface_type_t, which is bad for encapsulation. And we're
also tightly coupled to the current, meanwhile pretty old and customized
in-tree version of cairo.

To reduce maintenance burden and as a first step towards using future
use of external cairo, decouple these types. The overhead is minimal:
gfxASurface::GetType() now uses a small switch statement (compilers have
many ways for good optimizations), and the function doesn't seem to
be a hot path.

Note that this patch also drops values that aren't used by mozilla.
Also fix the value for invalid surface type: some sites used -1, while
others used Max.

Alternative options could be:

* directly alias it to cairo_surface_t (and also for similar enums)
  pro: less code
  con: more coupled to cairo api
  * only makes sense of we do it for other enums, too
  * consequently, we could also think about the gfx layer completely
(except some small cairo surface reference type - autoptr derivative
which calls cairo's ref/unref functions) and just add some helpers
that operate on cairo API directly - reduce even more own code
* store the gfxSurfaceType value in the gfxASurface instances (so the
  value mapping only has to be done once, on init)
* make GfxSurfaceType a class, that holds the cairo_surface_type_t along
  w/ other information (eg. like SurfaceMemoryReporterAttrs, ...) and use
  references instead of enum values.
---
 dom/plugins/ipc/PluginInstanceChild.cpp |  4 +--
 gfx/ipc/GfxMessageUtils.h   |  2 +-
 gfx/thebes/gfxASurface.cpp  | 57 +
 gfx/thebes/gfxTypes.h   | 18 +++
 4 files changed, 36 insertions(+), 45 deletions(-)

diff --git a/dom/plugins/ipc/PluginInstanceChild.cpp 
b/dom/plugins/ipc/PluginInstanceChild.cpp
index af9db9103..940687bcc 100644
--- a/dom/plugins/ipc/PluginInstanceChild.cpp
+++ b/dom/plugins/ipc/PluginInstanceChild.cpp
@@ -183,7 +183,7 @@ PluginInstanceChild::PluginInstanceChild(const 
NPPluginFuncs* aPluginIface,
 #endif
 , mAccumulatedInvalidRect(0,0,0,0)
 , mIsTransparent(false)
-, mSurfaceType(gfxSurfaceType::Max)
+, mSurfaceType(gfxSurfaceType::Invalid)
 , mPendingPluginCall(false)
 , mDoAlphaExtraction(false)
 , mHasPainted(false)
@@ -3395,7 +3395,7 @@ PluginInstanceChild::DoAsyncSetWindow(const 
gfxSurfaceType& aSurfaceType,
 bool
 PluginInstanceChild::CreateOptSurface(void)
 {
-MOZ_ASSERT(mSurfaceType != gfxSurfaceType::Max,
+MOZ_ASSERT(mSurfaceType != gfxSurfaceType::Invalid,
"Need a valid surface type here");
 NS_ASSERTION(!mCurrentSurface, "mCurrentSurfaceActor can get out of 
sync.");
 
diff --git a/gfx/ipc/GfxMessageUtils.h b/gfx/ipc/GfxMessageUtils.h
index e45aa7040..3268b36d8 100644
--- a/gfx/ipc/GfxMessageUtils.h
+++ b/gfx/ipc/GfxMessageUtils.h
@@ -202,7 +202,7 @@ template <>
 struct ParamTraits
   : public ContiguousEnumSerializer<
  gfxSurfaceType,
- gfxSurfaceType::Image,
+ gfxSurfaceType::First,
  gfxSurfaceType::Max>
 {};
 
diff --git a/gfx/thebes/gfxASurface.cpp b/gfx/thebes/gfxASurface.cpp
index 31f185596..5020d1596 100644
--- a/gfx/thebes/gfxASurface.cpp
+++ b/gfx/thebes/gfxASurface.cpp
@@ -207,9 +207,24 @@ gfxSurfaceType
 gfxASurface::GetType() const
 {
 if (!mSurfaceValid)
-return (gfxSurfaceType)-1;
+return gfxSurfaceType::Invalid;
+
+switch (cairo_surface_get_type(mSurface)) {
+case CAIRO_SURFACE_TYPE_IMAGE:  return gfxSurfaceType::Image;
+case CAIRO_SURFACE_TYPE_PDF:return gfxSurfaceType::PDF;
+case CAIRO_SURFACE_TYPE_PS: return gfxSurfaceType::PS;
+case CAIRO_SURFACE_TYPE_XLIB:   return gfxSurfaceType::Xlib;
+case CAIRO_SURFACE_TYPE_XCB:return gfxSurfaceType::Xcb;
+case CAIRO_SURFACE_TYPE_QUARTZ: return gfxSurfaceType::Quartz;
+case CAIRO_SURFACE_TYPE_WIN32:  return gfxSurfaceType::Win32;
+case CAIRO_SURFACE_TYPE_SVG:return gfxSurfaceType::SVG;
+case CAIRO_SURFACE_TYPE_WIN32_PRINTING: return 
gfxSurfaceType::Win32Printing;
+case CAIRO_SURFACE_TYPE_QT: return 
gfxSurfaceType::QPainter;
+case CAIRO_SURFACE_TYPE_RECORDING:  return 
gfxSurfaceType::Recording;
+case CAIRO_SURFACE_TYPE_SUBSURFACE: return 
gfxSurfaceType::Subsurface;
+}
 
-return (gfxSurfaceType)cairo_surface_get_type(mSurface);
+return gfxSurfaceType::Invalid;
 }
 
 gfxContentType
@@ -427,40 +442,26 @@ struct SurfaceMemoryReporterAttrs {
 };
 
 static const SurfaceMemoryReporterAttrs sSurfaceMemoryReporterAttrs[] = {
-{"gfx-surface-image", nullptr},
-{"gfx-surface-pdf", nullptr},
-{"gfx-surface-ps", nullptr},
-{"gfx-surface-xlib",
+[gfxSurfaceType::Image] = { "gfx-surface-image" },
+

nodejs for extensions ?

[Enrico Weigelt, metux IT consult]

Hi folks,


just curious: did anyone already try nodejs modules
for (javascript-only) extensions ?


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

Re: Extensions and Gecko specific APIs

[Enrico Weigelt, metux IT consult]

On 26.07.2017 23:27, Steve Fink wrote:


Doing this at a time of weak market share is... courageous[2].


Remember when the whole FOSS movement started - the market share
was about zero.


In short: better to have fewer users now with a high quality product


ACK. Leave the toys to others.


But to make the sacrifice worthwhile, that means we have to *be* a high
quality product.


ACK. And to achieve that, there's a lot to clean up.


That's my argument for why the default answer here should be "Heck yeah!
If we can provide something that other browsers don't, DO IT!" I could


For example small footprint and easily managable code.

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

Re: Extensions and Gecko specific APIs

[Enrico Weigelt, metux IT consult]

On 26.07.2017 22:23, Karl Dubost wrote:


As soon as some people are willing to adopt one of the browser

> "lab-style-features" in the open, because well it solves their
> issues and plays well with the ecosystem market shares, the

the vendor prefix strategy is falling apart for everyone else.

> It makes even things worse on a long term.

Maybe it's less painful when these things have to be explicitly
enabled by the user. So, arbitrary web coders (hopefully) don't
get the idea of relying on them. And they should have a limited
lifetime.


--mtx

___
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 14:28, Jeff Muizelaar wrote:


The cairo stuff is from an upstream project and not worth removing.


The bundled cairo pieces are quite far away from upstream
and ancient.

Perhaps we should kick out the bundled stuff and use the original
package (from distro) instead.


--mtx

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

Re: Correct format specifier for size_t

[Enrico Weigelt, metux IT consult]

On 25.07.2017 21:34, Mike Hommey wrote:



Why not just adding GNU-style printf()+friends to nspr
(perhaps even w/ printk() extensions) and use that everywhere,
instead of having special cases or complex for fmt string
construction everywhere ?


--mtx

___
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 02:04, Kris Maglione wrote:


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.


In esr52 there's a bit more:

gfx/2d/DrawTargetCairo.cpp
gfx/cairo/cairo/src/cairo-features.h.in
gfx/cairo/cairo/src/cairo-mutex-impl-private.h
gfx/cairo/cairo/src/cairo-os2-private.h
gfx/cairo/cairo/src/cairo-os2-surface.c
gfx/cairo/cairo/src/cairo-os2.h
gfx/cairo/cairo/src/cairo.h
js/src/ctypes/CTypes.cpp
js/src/ctypes/libffi/src/closures.c
js/src/ctypes/libffi/src/dlmalloc.c
js/src/ctypes/libffi/src/x86/win32.S
media/libvpx/vp8/common/threading.h
mfbt/Poison.cpp


--mtx

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

[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

[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

[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

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

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

platform specialities

[Enrico Weigelt, metux IT consult]

Hi folks,


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 ?


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

Re: who uses idl stuff

[Enrico Weigelt, metux IT consult]

On 24.07.2017 02:18, Boris Zbarsky wrote:

Hi,


Brief summary.  IDL:

1)  Generates xptcall information for xpconnect to allow calling from JS
and into JS (via synthetic vtables).
2)  Generates headers that declare pure virtuals.
3)  Is used for defining XPCOM interfaces.

(you can do just #2 without #1 if the interface is not scriptable).


I see *a lot* idl stuff here. Is that all scriptable ?
And does it really need to be ?


WebIDL:

1)  Generates C++ glue code to allow calling from JS (or into JS in the
case of callbacks or callback interfaces).
2)  Is used for defining things that are part of the web platform.  Is
standardized at https://heycam.github.io/webidl/


What exactly is the diffence of the web platform and xpcom ?
Why are both used ?


I've noticed that webidl's seem to support preprocessor directives
(eg. #ifdef), while the others dont.


That is one of the many differences, yes.  They also have different use
cases, different syntax, different output.


How can I add preprocessor to the XPCOM IDLs ?

Problem is: there are lots of references to things I'd like to disable
in here. For now, I'll have to directly patch it out.


--mtx

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

Re: who uses idl stuff

[Enrico Weigelt, metux IT consult]

On 24.07.2017 00:11, Enrico Weigelt, metux IT consult wrote:



what's the difference between idl and webidl ?

I've noticed that webidl's seem to support preprocessor directives
(eg. #ifdef), while the others dont.

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

Re: who uses idl stuff

[Enrico Weigelt, metux IT consult]

On 23.07.2017 18:15, Botond Ballo wrote:

could anyone please give me some insight, where the the IDLs
(and the code generated from them) are actually used ?

Javascript bindings ?


They are typically used as an interface between C++ and JS code.


Ah, what I've already suspected.

While trying to disable media stuff (in 45.8 - the version in jessie),
I had already removed that stuff from the IDLs, but still after
regeneration these functions appeared again (but couldn't find them
anywhere else), leading to breaking build (pure virtuals that hadn't
been overwritten.

After doing a complete clean, the error didn't appear again.
Are there some cache files (binary/compressed or outside the src tree) ?

Now it breaks w/ LDAP stuff:
Executing: c++ -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare 
-Wwrite-strings -Wno-invalid-offsetof -Wcast-align -g -O2 
-fno-delete-null-pointer-checks -fno-schedule-insns2 -fno-exceptions 
-fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections 
-fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG 
-DTRIMMED -g -freorder-blocks -Os -fomit-frame-pointer -fPIC -shared 
-Wl,-z,defs -Wl,--gc-sections -Wl,-h,libprldap60.so -o libprldap60.so 
/home/nekrad/src/thunderbird/icedove-45.8.0/obj-thunderbird/ldap/c-sdk/libraries/libprldap/tmpvhq1t4.list 
-lpthread -Wl,--no-keep-memory -Wl,--reduce-memory-overheads -Wl,--stats 
-Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id 
-Wl,-rpath-link,/home/nekrad/src/thunderbird/icedove-45.8.0/obj-thunderbird/dist/bin 
-Wl,-rpath-link,/usr/lib ../libldap/libldap60.so 
../../../../nsprpub/lib/ds/libplds4.so 
../../../../nsprpub/lib/libc/src/libplc4.so 
../../../../nsprpub/pr/src/libnspr4.so -ldl

/home/nekrad/src/thunderbird/icedove-45.8.0/obj-thunderbird/ldap/c-sdk/libraries/libprldap/tmpvhq1t4.list:
INPUT("ldappr-dns.o")
INPUT("ldappr-error.o")
INPUT("ldappr-io.o")
INPUT("ldappr-public.o")
INPUT("ldappr-threads.o")

/usr/lib/i386-linux-gnu/libc_nonshared.a(stack_chk_fail_local.oS): In 
function `__stack_chk_fail_local':

(.text+0x10): undefined reference to `__stack_chk_fail'
collect2: error: ld returned 1 exit status


Meanwhile I'm trying a fresh start on 52esr branch.

Again trouble w/ IDLs: for example it couldn't find PFTPChannel.ipdl,
PTransportProvider.ipdl, etc.


--mtx

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

how exactly are the P*.h files generated ?

[Enrico Weigelt, metux IT consult]

Hi folks,

I've got some trouble w/ regenarating
./obj-thunderbird/ipc/ipdl/_ipdlheaders/mozilla/dom/PContentParent.h


I had to change ./mozilla/dom/ipc/ContentParent.h to ifdef-out some
methods (trying to build tbird w/o media stuff), but PContentParent.h
still contains these functions (and no #ifdef around them).

What's going wrong here ?


--mtx

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

who uses idl stuff

[Enrico Weigelt, metux IT consult]

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

Re: build complexity vs kbuild

[Enrico Weigelt, metux IT consult]

On 23.07.2017 01:19, Gregory Szorc wrote:


Yes, the build system is complex. It has evolved organically for over 20
years, accumulating tons of cruft and complexity along the way. Much of
the existing complexity can be simplified.


Yeah, I'm already trying some experiments here. IMHO, the underlying
problem is the lack of an strict moduarity (lots of interdependencies
between different areas - media stuff is one example).


Kbuild is not a viable long-term solution because it is tied to Make,


Sorry, I was a bit imprecise. I'm thinking of Kconfig. And this is
quite independent of the actual build system.

OTOH, even for large project I'm usually fine w/ plain (g)make.
But my projects tend to be strictly modularized, and I take care that
they don't grow so huge in the first place.

I believe, we could reduce the (actually used) mozilla source size
radically and make things much easier. There's a also lot that wouldn't
like to have in the browser itself, but entirely separate programs.
Well, that's another story ...

By the way: I've read some rumors that the whole b2g stuff is going
to be dropped - is that correct ?


Bazel is one such modern tool.


hmm, according to the intro, looks pretty much like something I did
over 15 years ago (it was called "treebuild", as it modeled the whole
project in a tree structure) ... suggested it to several large projects
like moz, ooffice, etc - the reaction were, hmm, not entirely friendly.


By the way: xorg/xf86 used to have similar problems (anyone still
remembers xmkmf ? *b*), but due to modularization, things became
quite simple today (okay, Xserver itself is still ugly, but's a whole
story of its own :o).

That's the way I would like to go.


--mtx

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

build complexity vs kbuild

[Enrico Weigelt, metux IT consult]

Hi folks,


the whole build seems to be very complex.

Not just the huge configure.in, but also the complexity in moz.build
files, many ifdef's, etc, etc. Many orthogonal things are twisted
together (eg. widget toolkits influence lots of other things)

I'm thinking of having a deeper look at Kbuild. It's really nice to
handle complex dependencies. In the kernel we also use that for
automatically switch hidden settings by higher level ones
(eg. combination of a and b can activate c, certain things automatically
happen based on platform/cpu type, etc, etc.

Could it be an option for moz ?


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

Re: git mirror

[Enrico Weigelt, metux IT consult]

On 22.07.2017 19:49, Jörg Knobloch wrote:

On 22/07/2017 21:42, Enrico Weigelt, metux IT consult wrote:

Even hg clone runs for hours.


Best to use a bundle:

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial/Bundles


according to hg output, it already uses them.

(devuan)nekrad@orion:~/src/thunderbird/hg$ hg clone 
https://hg.mozilla.org/releases/mozilla-esr52/

destination directory: mozilla-esr52
applying clone bundle from 
https://hg.cdn.mozilla.net/releases/mozilla-esr52/5dd82ab194b9f8c82b94cbf20e2dc5f1975b2788.gzip-v2.hg

adding changesets
adding manifests 

adding file changes 

files 
[> 
  ] 200892/269670 14m50s


Same for git side. But the bottleneck seems to be importing the bundle
into local repo (git import is magnitudes slower, probably because it
has to process rev by rev).

--mtx

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

make media stuff optional

[Enrico Weigelt, metux IT consult]

Hi folks,


I'm trying to build tbird with minimal dependencies, and therefore
switched off various codecs. Unfortunately it causes the whole
media stuff to break.

As I don't need that at all in the mail client, I've added ifdefs
to disable it (introducing a new MOZ_MEDIA flag). Unfortunately
idl compiler doesnt seem to support ifdef's, but several idl's
directly reference media stuff.


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

git mirror

[Enrico Weigelt, metux IT consult]

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

--

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

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: More Rust code

[Enrico Weigelt, metux IT consult]

On 10.07.2017 12:29, Nicholas Nethercote wrote:

Hi folks,

Firefox now has multiple Rust components, and it's on track to get a 
bunch more. See https://wiki.mozilla.org/Oxidation for details.


I wonder which of the pressing problems (eg. massing resource wasting,
bad performance, horribly complicated build systems, hard to maintain
source tree, too much in one application, etc), are actually improved
by yet another language. No idea, which fancy features of rust you're
so keen on, but most of what I've seen so far, has already been done
in ADA (hmm, does rust have domain types and compile-time constraints?)

By the way, just in case nobody noticed: recent Debian stable doesn't
have rustc (for good reasons, as it's still unstable), so pretty much
no chance of recent moz in Debian world (I'd guess the same w/ other
stable distros) - limited to bleeding-edge distros for the next years.
Rustc is so alpha, that it doesn't even compile (eg. wrong guesses
on the target architecture, neeed bleeding-edge cmake, ...)

I'd rather concentrate on consequent cleanups, starting with dropping
bundled 3rdparty libraries, dropping various misfeatures, esoteric
build systems, move audio/video stuff to separate tools that are
really made for that (eg. ffmpeg or gst - yes, that gives you hw
acceleration for free), move out mail protocol handling to separate
service (mailfs is your friend) - same for address books, dictionaries,
bookmarks finally an lightweight interface
to run extensions as separate programs.

When I look back the past decade, I don't recall any major improvement
(okay, don't remember whether session management did exist back then),
but it just got slower and slower, even w/ magnitudes faster machines
since back then.

Will moving to rust improve anything of these areas ?

- Lack of Rust expertise for both writing and reviewing code. We have 
some pockets of expertise, but these need to be expanded greatly.


Wouldn't that be a yet another big argument for keeping rust stuff
optional, until that problem is settled (and rust is matured enough
so become an option for production systems ?)

- ARM/Android is not yet a Tier-1 platform for Rust. See 
https://forge.rust-lang.org/platform-support.html and 
https://internals.rust-lang.org/t/arm-android-to-tier-1/5227 for some 
details.


So, is android also dropped out of the list of supported platforms,
just like all recent stable gnu/linux distros already are ?


- Compile times are high, especially for optimized builds.


Compile times for C++ are already very high (c++ in general is very
expensive to compile, and also very complicated to write good code).
How much worse is that for rust ?


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