Pepper Flash with Firefox?

I don't know anything about this distro but the use of Pepper Flash with Firefox is interesting.
I'm wondering if the other "flavors" will do this.

Notable changes:

  • Nemo updated to 2.6.7
  • Running kernel 3.13.0-63
  • Firefox 40.0.3
  • Fixed Grub installing issues.
  • Fixed Docky & Network issues after waking from suspend.
  • Using Pepper Flash in Firefox instead of Adobe Flash.
  • Added the H.265/HEVC Codec for VLC.
Source: Pinguy OS
---> Pinguy OS 14.04.3 Mini Point Release

No Win64 Firefox Until Firefox 42?

The plans to 'officially' release a Win64 release of Firefox have now been pushed back to Firefox 42 (November 2015). As you may recall it was suppose to be Firefox 40 (August 2015) then was pushed to Firefox 41 (September 2015). The reason for the delay as described in Bug 1185532 has to do with the sandboxing feature for the 64-Bit Flash not working correctly.

Firefox 40.0.3 Released

Mozilla release an emergency update for the Firefox 40 branch on Thursday, August 27th with Firefox 40.0.3 release. This release addressed the following issues:
    • Disable the asynchronous plugin initialization (1198590)
    • Fix a segmentation fault in the GStreamer support (GNU/Linux) (1145230)
    • Fix a startup crash when using DisplayLink (Windows Only) (1195844)
    • Fix a regression with some Japanese fonts used in the <input> field (1194055)
    • On some sites, the selection in a select combox box using the mouse could be broken (1194733)
    • Some search partner codes were missing (1195683)
    • Various security fixes
  User should be prompted to update or can do so manually via Help > About Firefox or download and install the latest version via The next planned release is Firefox 41 on September 22nd.    

Mozilla Ruining Firefox?

I'm using Pale Moon but not because standard FF was crashing (I don't remember the last time it did), I just hated the new UI.

"A week ago, Mozilla shed some light on its future, laying out a plan on how the browser is going to dramatically change in the upcoming months. While most of us understood "Chrome extensions are coming to Firefox," it is not as simple as we all thought.
"... The Mozilla dev team has a pretty solid plan on how they can change the browser "always crashing" image, and even if we don't like it, this includes a severe and very profound change to Firefox's core code. ..."
---> Please God, Don't Let Mozilla Ruin Firefox - Softpedia

Experimental Private Browsing now in Firefox Beta

As mentioned in the Three Pillars of Firefox from July 2015. The Uniquely Firefox Pillar hinted towards an improved private browsing mode. In the past Private Browsing would not show up in your history, or keep cookies and temporary files. So, now Mozilla has expanded on what happens in a private browsing session and has rolled this out in the current Firefox 40 Beta.
Our hypothesis is that when you open a Private Browsing window in Firefox you’re sending a signal that you want more control over your privacy than current private browsing experiences actually provide. The experimental Private Browsing enhancements ready for testing today actively block website elements that could be used to record user behavior across sites. This includes elements like content, analytics, social and other services that might be collecting data without your knowledge.

Private Browsing Start Page

Once again, this leads into marketing about the Extension Signing how it is this great thing and is suppose to make users safer by not allowing unsigned extensions to be installed. After all Mozilla's philosophy is the user can't protect themselves and an unsigned extension is an unsafe extension. The reality is an unsigned extension is all likely a safe extension that developer can't get through or gave up on all the approval hoops. via Mozilla Future Releases

Mozilla to Depreciate add-ons using XUL, XPCOM, or XBL

Back in July Mozilla's Dave Camp had talked about in his email how to get Firefox away from being dependent on XBL and XUL. At that time, many on mozillaZine were concerned that this could have dire consequences on the future of Firefox as trying to move away from a development system that has been used for the past decade would not be easy. If anything, it would require a complete rewrite/redesign of the desktop version of Firefox. Many had hoped this would be like a campaign promise and people would forget about it. Unfortunately, Mozilla has lived up their promise on this. Mozilla announced on Friday in the Mozilla Add-ons Blog they would deprecate support for add-ons using XUL, XPCOM, or XBL (which is what most add-ons are built with now).
Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now. We are announcing the change now so that developers can prepare and offer feedback.
Mozilla is trying to move add-on developers over to the newer WebExtensions API which is used by Chrome and Opera. This announcement has not gone over well some add-on developers including Christopher Finke who announced on his blog he discontinuing further development of his add-ons as a result of Mozilla's announcement.  Meanwhile Bill McCloskey offers some insights on how add-on developers could make this transition and the possible short comings of Mozilla's plans. Another reason Mozilla is pushing towards WebExtensions as they are fully compatible with Electrolysis aka E10s (multi-process). While add-ons which haven't been upgrade to work with Electrolysis will still run, they are going to be forced to run in the current single process environment which will be slower. Mozilla still hasn't even determine when Electrolysis would be officially rolled out. The current target is with the Firefox 43 release in mid December 2015. Whatever the release date happens to be, Mozilla plans on killing support for add-ons using XUL, XPCOM, or XBL within 6-months. Finally, everyone's favorite add-on topic, Extension Signing was also marketed discussed in this blog post. Mozilla is trying to force tell developers to move towards using WebExtensions as this will make the review process for extension signing simper and quicker:
Starting in Firefox 42, add-on developers will be required to submit extensions for review and signing by Mozilla prior to deployment, and unsigned add-ons cannot be installed or used with Firefox. We realize that the add-on review process can sometimes be inconvenient for developers. Reviewing is a mostly manual, human process today, and moving an extension from the initial submission to passing a full review that meets our guidelines can be a time-consuming process that can take weeks or months. A major advantage of WebExtensions is that they can be reviewed more quickly. In general, it’s easier to develop a correct WebExtension, and the permissions system makes it easier to recognize malicious add-ons.
I understand that the current XUL, XPCOM, or XBL architecture is over a decade old and their is new and better ways of doing things now. However, the timing of this (along with E10s and extension signing) is horrible. Add-on developers are already unhappy with having to jump through hoops to get their add-ons signed, but are now being told they need to re-write them as well to use WebExtensions to better take advantage of E10s (which has been in the works since around 2009 and Mozilla still doesn't have a firm date when it will be active) which will make the signing process easier. Part of the issue is Mozilla has put E10s on hold to allocate resources to other short term projects. E10s should have been fully developed and implemented by now so add-on developers would be able to see the advantage of using WebExtensions. What I can see is happening is add-on developers are going to simply abandon Firefox as Mozilla is becoming increasingly too difficult to work with. Since add-ons are the biggest part of Firefox this could mean the start of the death of the (desktop) Firefox browser. Of course, extension signing will already start the clock ticking next month with Firefox 40 (even though user can still over-ride the forced signing check).

Coming This Weekend…

Been busy adapting to a new work schedule (and soon will be adding school into the mix), so posting is somewhat limited to the weekends. There are some Firefox related news items that have come out during the week which I will be posting over the weekend. Some of these have to do with the 'announcements' that were made this past summer during Mozilla's annual retreat in Whistler, BC. Including New Experimental Private Browsing and depreciation of XBL/XUL/XPCOM based addons. The latter could have a huge negative impact on the desktop based Firefox browser and also seems to support Mozilla's (unofficial) plan to make Firefox like Chrome.

Enable 1080p YouTube Support in Firefox 40 for Linux

"You can check if your browser supports all the codecs for YouTube by checking the YouTube HTML5 Video Player website, which list everything supported on your PC. If you have a Linux systems and Firefox 40, it's likely that some of those codecs will have a red sign, meaning that they are not enabled. All you have to do is open about:config and make the following changes. Please make sure that you don't change anything else. ..."
Source: Softpedia
---> How to Enable 1080p YouTube Support in Firefox 40 for Linux

Block Firefox from connecting to sites when you hover over links

I thought I had these all off but I missed one.
" Find out how to prevent the Firefox web browser from connecting to sites when you hover over links in the browser. "

@ Firefox from connecting to sites when you hover over links - gHacks Tech News

Firefox 41 (and Headaches) Coming September 22nd

Mozilla is moving right along with getting Firefox 41 ready to ship for the September 22nd release. Having had a chance to play with the current Beta version of Firefox 41, here are THREE major changes users should be aware of to avoid headaches upon updating/downloading:
  1. New 'New Tab' behavior. Gone are the days users could set their preference as to what comes up when they open a new tab via the browser.newtab.url preference in about:config. Nope, that was being 'exploited' so Mozilla removed this functionality that has been in Firefox since Firefox 13 (June 2012). There is a simple solution, Custom New Tab add-on. Simple, but... Why should users have to add an add-on to restore (what now has become) core functionality to Firefox and at the same time why can't users add an add-on to add features that shouldn't be in the core functionality such as Hello, Pocket, etc.? This add-on does not require a restart. Once installed go into the add-ons manager click Custom New Tab and then Options.custom-new-tab-optionsSimply place the address of the site you want to open (or leave blank for a blank tab) when you open a new tab. Place focus in URL bar - when you open a new tab, the specified page opens and your cursor is placed in the URL bar (after the page is fully loaded) so you type the address of where you want to go next without having to click in the URL bar. Make URL bar emptywhen you open a new tab, the specified page opens and the URL bar is blank (warning: the URL bar is cleared when the page finishes loading and if you start typing in the URL bar before the page is done loading your text will be removed).
  2. Extension Signing/Verification. Been talking about this for a while now. You may have seen the warnings in your add-on manager with Firefox 40 if you have unsigned or unverified extensions. In Firefox 41, unsigned extensions will be disabled when you update and also won't be installable. However, in Firefox 41 you still turn off this annoying feature via about:config and set xpinstall.signatures.required to FALSE. Warning: in Firefox 42 xpinstall.signatures.required preference will be ignored and unsigned add-ons will not be permitted.Mozilla can still 'make this right' by keeping the xpinstall.signatures.required preference active so that users who know what they are doing can continue to use unsigned add-ons. Just because an add-on is unsigned does not mean it is not safe. There are many developers who don't want to host their add-ons on AMO and don't want to jump through the multiple hoops with Mozilla to get their add-ons signed. This is especially true for corporations which may have proprietary add-ons, though they should be using the ESR version of Firefox which currently does not enforce extension signing.
  3. 64-Bit Windows Firefox. The plan is for Mozilla to release the first official public version of 64-Bit Firefox for Windows with Firefox 41. Mozilla's objectives on this is to make it more stable, efficient and safer compared to the 32-bit version. To do this, they have made a critical change in the Windows 64-bit (no changes with the OS X and Linux) version that removes support for most NPAPI plugins such as Silverlight and Java. This appears to be an industry trend as Microsoft Edge (Windows 10) browser has no plugin support (other than Flash) and Google Chrome is removing support for NPAPI plugins (except Flash) by the end of the year.With that said though, Mozilla needs to carefully consider how they 'disclose' this fact and market the Win64 version of Firefox. By disclose I don't mean bury it in the release notes which is likely what they are going to do. What I fear is Mozilla is going to make a big deal out the 64-Bit support and mention in very small print somewhere deep on the page: Netflix, Amazon Instant Video, Magine TV, Maxdome and an unknown number of other streaming and VOD sites worldwide will not work this version. Instead they need to tell users if you want to use Silverlight, JAVA or any other plugin technology this version is not for you, use the 32-bit Firefox version.
So there you have it, three things to be aware of with the upcoming Firefox 41.