Re: Rationalising Linux audio backend support
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
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!
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
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 ?
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
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 ?
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, &rv); 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
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()
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 ?
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
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
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
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
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
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
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]
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
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]
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
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 ?
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]
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
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
Signed-off-by: Enrico Weigelt, metux IT consult --- 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
Signed-off-by: Enrico Weigelt, metux IT consult --- 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
startupcache depends on zipwriter. when enabled, check that zipwriter is also enabled. Signed-off-by: Enrico Weigelt, metux IT consult --- 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
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" }, +[gfxSurfaceType::PDF
nodejs for extensions ?
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
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
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 ?
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
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 ?
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 ?
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 ?
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
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
OS/2 still supported ?
Hi folks, I see lots of #ifdef XP_OS2 ... is OS/2 still supported at all ? --mtx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing MozillaBuild 3.0 Release
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
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
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
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
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. --mtx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing MozillaBuild 3.0 Release
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
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&component=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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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
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
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
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
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
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