Mozilla Nederland LogoDe Nederlandse

Mozilla Adds Device Management to Firefox Sync - Softpedia News (blog)

Nieuws verzameld via Google - ma, 10/10/2016 - 00:15

Softpedia News (blog)

Mozilla Adds Device Management to Firefox Sync
Softpedia News (blog)
Firefox accounts just received a well-deserved security boost with the addition of a Device Manager, a feature that allows users to remove devices they don't use anymore from their account. The feature is only visible to users that choose to sync data ...
Device Management Update rolls out for Firefox Account UsersTWCN Tech News (blog)

alle 2 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Nový softvér: Pomocníci pre Windows, vynovený Mozilla Thunderbird - Živé.sk

Nieuws verzameld via Google - zo, 09/10/2016 - 11:25


Nový softvér: Pomocníci pre Windows, vynovený Mozilla Thunderbird
Nový softvér: Pomocníci pre Windows, vynovený Mozilla Thunderbird. Do dnešného výberu softvéru sme zaradili napríklad balík nástrojov pre Windows, univerzálneho komunikačného klienta či nový Mozilla Thunderbird. dnes 13:00 2016-10-09 Autor: Martin ...

Google Nieuws
Categorieën: Mozilla-nl planet

Google Chrome & Mozilla Firefox Tags The Pirate Bay As Phishing Site; Kickass ... - Gamenguide

Nieuws verzameld via Google - zo, 09/10/2016 - 07:51


Google Chrome & Mozilla Firefox Tags The Pirate Bay As Phishing Site; Kickass ...
Now that Google Chrome and Mozilla Firefox has tagged The Pirate Bay as a phishing site, it seems that The Pirate Bay team is working double time to get the issue resolved. They claim that the phishing threats may be caused by third party advertisers.
Kickass Torrents shut down updates: Kickass Torrents, The Pirate Bay, and other ...ChristianToday

alle 9 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Cameron Kaiser: A Saturday mystery, or, locatedb considered harmful to old Macs

Mozilla planet - za, 08/10/2016 - 22:02
I've been waist-deep on AltiVec intrinsics for the last week converting some of those big inverse discrete cosine and Hadamard transforms for TenFourFox's vectorized PowerPC VP9 codec. The little ones cause a noticeable but minor improvement, but when I got the first large transform done there was a big jump in performance on this quad G5. Note that the G5, even though its vector unit is based on the 7400 and therefore weaker than the 7450's, likes long strings of sequential code it can reorder, which is essentially what that huge clot of vector intrinsics is, so I have not yet determined if I've just optimized it well for the G5 or it's generalizeable to the G4 too. My theory is that even though the improvement ratio is about the same (somewhere between 4:1 and 8:1 depending on how much data they swallow per cycle), these huge vectorized inverse transforms accelerate code that takes a lot of CPU time ordinarily, so it's a bigger absolute reduction. I'm going to work on a couple more this weekend and see if I can get even more money out of it. 720p playback is still out of the question even with the Quad at full tilt, but 360p windowed is pretty smooth and even 360p fullscreen (upscaled to 1080p) and 480p windowed can keep up, and it buffers a lot quicker.

The other thing I did was to eliminate some inefficiencies in the CoreGraphics glue we use for rendering pretty much everything (there is no Skia support on 10.4) except the residual Cairo backend that handles printing. In particular, I overhauled our blend and composite mode code so that it avoids a function call on every draw operation. This is a marginal speedup but it makes some types of complex animation much smoother.

Overall I'm pretty happy with this and no one has reported any issues with the little-endian typed array switchover, so I'll make a second beta release sometime next week hopefully. MSE will still be off by default in that build but unless I hear different or some critical showstopper crops up it will be switched on for the final public release.

When I sat down at my G5 this warm Southern California Saturday morning, however, I noticed that MenuMeters (a great tool to have if you don't already) showed the Quad was already rather occupied. This wasn't a new thing; I'd seen what I assumed was a stuck cron job or something for the last several Saturday mornings and killed it in the Activity Monitor. But this was the sixth week in a row it had happened and it looked like it had been running for over three hours wasting CPU time, so enough was enough.

The offending process was something running /usr/bin/find to find, well, everything (that wasn't in /tmp or /usr/tmp), essentially iterating over the whole damn filesystem. A couple of ps -wwjp (What Would Jesus Post?) later showed it was being kicked off as part of the update system for an old Unix dragon of yore, locate.

There are no less than three possible ways to find files from the command line in OS X macOS. One is the venerable find command, which is the slowest of the lot (it uses no cache) and the predicates can be somewhat confusing to novices, but is guaranteed to be up-to-date because it doesn't rely on a pre-existing database and will find nearly anything. The second is of course Spotlight, which is accessible from the Terminal using the mdfind command. There are man pages for both.

The third way is locate, which is easier than find and faster because it uses a database for quick lookups, but less comprehensive than Spotlight/mdfind because it only looks for filenames instead of within file content as well, and the updater has to run periodically to stay current. (There's a man page for it too.) It would seem that Spotlight could completely supersede locate, and Apple thinks so too, because it was turned into a launchd .plist in 10.6 (look at /System/Library/LaunchDaemons/ and disabled by default. That's not the case for 10.5 and previous, however, and I have so many files on my G5 by now that the runtime to update the locate database is now close to five hours -- on an SSD! And that's why it was still running when I sat down to do work after breakfast.

I don't use locate because Spotlight is more convenient and updates practically on demand instead of weekly. If you don't either, then niced or not it's wasted effort and you should disable it from running within your Mac's periodic weekly maintenance tasks. (Note: on 10.3 and earlier, since you don't have Spotlight, you may not want to do this unless locate's update process is tying up your machine also.) Here's how:

  • On 10.5, the weekly periodic script can be told specifically not to run locate.updatedb. Edit /etc/defaults/periodic.conf as root (such as sudo vi /etc/defaults/periodic.conf -- you did fix the sudo bug, right?) and set weekly_locate_enable to "NO".

  • On 10.4 and before (I checked this on my 10.2.8 strawberry iMac G3 as well, so I'm sure 10.3 is the same), the weekly script doesn't offer this option. However, it does check to see if locate.updatedb is executable before it runs it, so simply make it non-executable: sudo chmod -x /usr/libexec/locate.updatedb

Now for some 8-Bit Weapon ambient (de)programming with a much more sedate G5 into the rest of the weekend.
Categorieën: Mozilla-nl planet

Firefox klaut von Chrome: Mozilla baut den Google-Klon - CHIP Online

Nieuws verzameld via Google - za, 08/10/2016 - 12:03

Firefox klaut von Chrome: Mozilla baut den Google-Klon
CHIP Online
Firefox ist im Umbruch, hat schon einige neue Features zu bieten und andere Neuheiten noch in der Pipeline. Das Problem, bei den meisten Neuheiten lässt sich Mozilla von Google Chrome inspirieren. So wird Firefox zum Chrome-Klon.
Firefox Account bekommt Geräteverwaltung für

alle 3 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Hub Figuière: Rust and Automake

Mozilla planet - za, 08/10/2016 - 04:01

But why automake? Cargo is nice.

Yes it is. But it is also limited to build the Rust crate. It does one thing, very well, and easily.

Although I'm writing a GNOME application and this needs more than building the code. So I decided I need to wrap the build process into automake.

Let's start with Autoconf for Rust Project. This post is a great introduction to solving the problem and give an actual example on doing it even though the author just uses autoconf. I need automake too, but this is a good start.

We'll basically write a and a in the top level Rust crate directory.

AC_INIT([gpsami], m4_esyscmd([grep ^version Cargo.toml | awk '{print $3}' | tr -d '"' | tr -d "\n"]), []) AM_INIT_AUTOMAKE([1.11 foreign no-dependencies no-dist-gzip dist-xz subdir-objects])

Let's init autoconf and automake. We use the options: foreign to not require all the GNU files, no-dependencies because we don't have dependency tracking done by make (cargo do that for us) and subdir-objects because we have one and don't want recursive mode.

The m4_esyscmd macro is a shell command to extract the version out of the Cargo.toml.

VERSION=$(grep ^version Cargo.toml | awk '{print $3}' | tr -d '"' | tr -d "\n")

This does the same as above, but put it into VERSION

This shell command was adapted from Autoconf for Rust Project but fixed as it was being greedy and also captured the "version" strings from the dependencies.

AC_CHECK_PROG(CARGO, [cargo], [yes], [no]) AS_IF(test x$CARGO = xno, AC_MSG_ERROR([cargo is required]) ) AC_CHECK_PROG(RUSTC, [rustc], [yes], [no]) AS_IF(test x$RUSTC = xno, AC_MSG_ERROR([rustc is required]) )

Check for cargo and rustc. I'm pretty sure without rustc you don't have cargo, but better be safe than sorry. Note that this is considered a fatal error at configure time.

dnl Release build we do. CARGO_TARGET_DIR=release AC_SUBST(CARGO_TARGET_DIR)

This is a trick: we need the cargo target directory. We hardcode to release as that's what we want to build.

The end is pretty much standard.

So far just a few tricks.

desktop_files = data/gpsami.desktop desktopdir = $(datadir)/applications desktop_DATA = $(desktop_files) ui_files = src/mgwindow.ui \ $(null)

Just some basic declarations in the The desktop file with installation target and the ui_files. Note that at the moment the ui files are not installed because we inline them in Rust.

EXTRA_DIST = Cargo.toml \ src/devices.json \ src/ \ src/ \ src/ \ src/ \ src/ \ src/ \ $(ui_files) \ $(desktop_in_files) \ $(null)

We want to distribute the source files and the desktop files. This will get more complex when the crate grows as we'll need to add more files to here.

all-local: cargo build --release clean-local: -cargo clean

Drive build and clean targets with cargo.

install-exec-local: $(MKDIR_P) $(DESTDIR)$(bindir) $(INSTALL) -c -m 755 target/@CARGO_TARGET_DIR@/gpsami $(DESTDIR)$(bindir)

We have to install the binary by hand. That's one of the drawback of cargo.

We this, we do

$ autoreconf -si $ ./configure $ make # make install

This build in release and install it in the prefix. You can even make dist, which is another of the reason why I wanted to do that.

Caveats: I know this will not work if we build in a different directory than the source directory. make distcheck fails for that reason.

I'm sure there are ways to improve this, and I will probably, but I wanted to give a recipe for something I wanted to do.

Categorieën: Mozilla-nl planet

Mozilla Partnered With Voter Registration Group Teaming With Democratic Data ... - Washington Free Beacon

Nieuws verzameld via Google - vr, 07/10/2016 - 18:35

Washington Free Beacon

Mozilla Partnered With Voter Registration Group Teaming With Democratic Data ...
Washington Free Beacon
The “nonpartisan” voter registration group that partnered with Mozilla Firefox to register new voters for the November elections is affiliated with a Democratic data firm., which describes itself as a “nonpartisan nonprofit digital voting ...

Categorieën: Mozilla-nl planet

Karl Dubost: [worklog] Edition 039. kill two images with one python

Mozilla planet - vr, 07/10/2016 - 16:55

Being born in France, lived/ing in Canada and Japan, The international news pages are usually my preferred source of information about the world. But when I read the non-comical farce and quite disheartening run for the USA presidential 2016, I'm dumbfounded. Quick, poetry and imagination! Tune of the week: Ol' Man River - William Warfield

Webcompat Life

Progress this week:

Today: 2016-10-11T07:15:20.170216 363 open issues ---------------------- needsinfo 19 needsdiagnosis 123 needscontact 12 contactready 20 sitewait 170 ----------------------

You are welcome to participate

I'll be speaking in Jakarta, Indonesia for Tech in Asia 2016 on November 16.

Preparing a brownbag for Taipei's office.

Webcompat issues

(a selection of some of the bugs worked on this week). development Reading List
  • will-change used too often. The thing I found interesting in this article is that it is written entirely from the prospective of Chrome without any tests in other browsers. This is one of the issues of the way some people think about the Web. Firefox is sending a warning in the console when people over-use will-change. fwiw the code provided in the article works very well in Firefox/Gecko and Safari/WebKit (testing in Edge would be cool too) and indeed shows bluriness in Blink (Opera and Chrome).

    The will-change spec doesn't really specify implementation details which means that Chrome's new behavior may be completely unique; Firefox might do something different, and then there's Edge, Safari, Opera, Android, etc. Perhaps Chrome requires that developers toggle back-and-forth to maintain clarity, but what if Firefox interprets that differently, or imposes a big performance penalty when doing the same thing? What if developers must resort to various [potentially conflicting] hacks for each browser, bloating their code and causing all sorts of headaches. We may have to resort to user agent sniffing again (did you just throw up a little in your mouth?). This will-change property that was intended to SOLVE problems for animators may end up doing the opposite.

Follow Your Nose TODO
  • Document how to write tests on using test fixtures.
  • ToWrite: Amazon prefetching resources with <object> for Firefox only.


Categorieën: Mozilla-nl planet

Gian-Carlo Pascutto: Firefox sandbox on Linux tightened

Mozilla planet - vr, 07/10/2016 - 16:43
As just announced on, we landed a set of changes in today's Nightly that tightens our sandboxing on Linux. The content process, which is the part of Firefox that renders webpages and executes any JavaScript on them, had been previously restricted in the amount of system calls that it could access. As of today, it no longer has write access to the filesystem, barring an exception for shared memory and /tmp. We plan to also remove the latter, eventually.

As promised, we're continuing to batten down the hatches gradually, making it harder for an attacker to successfully exploit Firefox. The changes that landed this night are an important step, but far from the end of the road, and we'll be continuing to put out iterative improvements.

Some of our next steps will be to address the interactions with the X11 windowing system, as well as implementing read restrictions.
Categorieën: Mozilla-nl planet

Myk Melez: SpiderNode In Positron

Mozilla planet - vr, 07/10/2016 - 08:35

Last Friday, Brendan Dahl landed SpiderNode integration into Positron. Now, when you run an Electron app in Positron, the app’s main script runs in a JavaScript context that includes the Node module loader and the core Node modules.

The hello-world-server test app demonstrates an Electron BrowserWindow connecting to a Node HTTP server started by the main script. It’s similar to the hello-world test app (a.k.a. the Electron Quick Start app), with this added code to create the HTTP server:

// Load the http module to create an HTTP server. var http = require('http'); // Configure our HTTP server to respond with Hello World to all requests. var server = http.createServer(function (request, response) { response.writeHead(200, {"Content-Type": "text/plain"}); response.end("Hello World from node " + process.versions.node + "\n"); });

The main script then loads a page from the server in an Electron BrowserWindow:

const electron = require('electron'); const app =; // Module to control application life. const BrowserWindow = electron.BrowserWindow; // Module to create native browser window. … var mainWindow = null; … // This method will be called when Electron has finished // initialization and is ready to create browser windows. app.on('ready', function() { // Create the browser window. mainWindow = new BrowserWindow({width: 800, height: 600}); // and load the index.html of the app. mainWindow.loadURL('http://localhost:8000'); … });

Which results in:

Hello World Server Demo

The simplicity of that screenshot belies the complexity of the implementation! It requires SpiderNode, which depends on SpiderShim (based on ChakraShim from node-chakracore). And it must expose Node APIs to the existing JavaScript context created by the Positron app runner while also synchronizing the SpiderMonkey and libuv event loops.

It’s also the first example of using SpiderNode in a real-world (albeit experimental) project, which is an achievement for that effort and a credit to its principal contributors, especially Ehsan Akhgari, Trevor Saunders, and Brendan himself.

Try it out for yourself:

git clone cd positron git submodule update --init MOZCONFIG=positron/config/mozconfig ./mach build ./mach run positron/test/hello-world-server/

Or, for a more interesting example, run the basic browser app:

git clone ./mach run electron-sample-apps/webview/browser/

(Note: Positron now works on Mac and Linux but not Windows, as SpiderNode doesn’t yet build there.)

Categorieën: Mozilla-nl planet