Subject: General Tech | October 29, 2011 - 05:56 AM | Tim Verry
Tagged: software, pdf, open source, mozilla, firefox, browser
One of the most useful features in Google’s Chrome web browser is the built in PDF reader. It is a feature that I use almost every day, and although I keep an install of Firefox’s Aurora browser as a backup I have yet to return to using Firefox as my main browser since first checking out Chrome.
For now though, the team has released PDF.js as a browser extension for the open source browser. In addition to the extension download, the source code is available on GitHub for anyone to view and edit.
PDF.js displaying a Dell service manual in PDF format.
As it is now, the PDF.js add-on rather basic, but is definitely off to a good start. You are able to navigate by sections or page thumbnails accessible by a mouse-over pop-up menu on the left of the window. Along the top are buttons for previous and next page, navigating to a specific page, zooming in and out, downloading, printing, and searching the PDF document.
During some informal testing using a 94 page Dell service manual in PDF form, scrolling was smooth enough until hitting a new page upon which there was a bit of lag. Navigating to specific pages was rather quick, however.
The PDF reader is off to a good start and I may have one more reason to switch back to Mozilla’s browser soon enough. What do you guys and gals think about built in PDF support, is it something you find useful during your daily browsing? If you're interested in checking it out for yourself, the extension is available for download here. Simply download this "pdf.js.xpi" file and install it (choose the Firefox or Aurora executable for installation if Windows does not assign the .xpi extension to Firefox automatically) using Firefox. Now navigate to a PDF file on any webpage to have it automatically open using PDF.js.
Subject: General Tech | September 8, 2011 - 09:05 PM | Tim Verry
Tagged: mozilla, do not track, adblock
Popular open source browser maker Mozilla recently released a field guide aimed at advertisers that outlines Do Not Track functionality. The guide is reported by Computer World as including tutorials, case studies, guidelines, and sample code to “inspire developers, publishers, and advertisers to adopt DNT.”
Mozilla's Firefox browser supports the popular Do Not Track add-on.
Mozilla indicated that approximately 22,500,000 users are currently employing the Do Not Track add-on. Further, there are currently more users who use Do Not Track than there are people using AdBlock Plus.
While the field guide is a good start, the real issue for consumers lies in whether or not advertisers will take notice and allow consumers to opt out of their tracking mechanisms. In the end, advertisers will need to implement some form of opt-out procedure (or better yet, an opt-in mechanism) lest they lose any revenue because users completely block out their advertisements. Currently; however, there is a cultural battle between advertisers and consumer privacy advocates, and it remains to be seen which will win out. Where do you stand on the issue; should advertisers be allowed to collect tracking data?
Subject: General Tech | August 26, 2011 - 01:33 PM | Tim Verry
Tagged: mozilla, browser, firefox
We reported earlier that Mozilla would be removing the version number from the About page due to a posting by Asa on the bugzilla page; however, designer Alex Faaborg has come forth to clear up the issue with the statement that “there are no plans to adjust the version number. It will remain in its current place in the about window, and we are going to continue with the current numbering scheme.”
That statement was in the mozilla.dev.usability group, which you can read here. Further in the thread, Alex notes that the confusion began from within the Mozilla UX design group, and Asa defended the design team with his posting on what he thought the final decision was. If the UX team had been playing a joke on Asa, it would have been perfectly executed, says Alex “that’s what I mean when I say significant confusion.”
With development that is done in public, some confusion is to be expected seems to be the sentiment of the thread. All said and done, are you happy to hear that the versioning will remain the same (as of now), or did you want to see them removed from the about screen?
Subject: General Tech | August 16, 2011 - 05:05 AM | Tim Verry
Tagged: software, mozilla, firefox, browser
A new bug report on Mozilla's Bugzilla website indicates that the versioning of the popular web browser will be hidden from the users in future builds. Specifically, bug 678775 was posted late last week by Asa Dotzler, and addresses the version number on Firefox's About page. The bug report recommends removing the specific version number in favor of a more general phrase such as "Firefox checked for updates 20 minutes ago, you are running the latest release," according to Asa. Firefox would then, ideally, check for an update whenever the About window was opened, to keep the update message current and the user running the latest build.
The current Firefox About page where version numbers are still listed.
While the specific version number will be removed from the About page, users would still be able to dig into the browser's less well known areas, such as the about:support configuration page, to see it.
On one hand, Firefox's new rapid-release schedule will make versioning a less efficient method of, well, versioning; however, the About page of an application has traditionally been the spot to find the version number, and removing the version number from what is essentially a version number information page seems counter productive. Firefox will likely be on version 7 before the end of the year, and considering version 5 was just released in June, the argument that version numbers are getting out of hand has some merit. With that said, a simplified message to users that they are, in fact, running the latest version is a good thing to implement, but does it necessitate no longer displaying the version number?
Personally, I enjoy knowing the specific version number of the applications I run, but I'm curious what you guys think; should the version number be buried?
Subject: Editorial, General Tech | July 19, 2011 - 11:59 PM | Scott Michaud
Tagged: mozilla, firefox
One side-effect of splitting a program up into multiple processes is that instructions do not inherently have a specific order. One of the most evident places for that to occur is during a videogame. I am sure most gamers have played a game where the controls just felt sluggish and muddy for some inexplicable reason. While there could be a few problems, one likely cause is that your input is not evaluated for a perceivably large amount of time. Chris Blizzard of Mozilla took on this and other issues with multithreaded applications and wrapped it around the concept of Firefox past, present, and future.
Firefox is getting Beta all the time.
One common misconception is that your input is recognized between each frame, which is untrue: many frames could go by before input affects the events on screen. John Carmack in a recent E3 interview discussed about iD measuring up to 100ms worth of frames occurring before a frame occurred which recognized the user’s command. This is often more permissible for games with slower-paced game design where agility is less relevant; if your character would lose to a Yak in a foot race, turns about as quick as one, and takes a hundred bullets to die: you will not notice that you started to dodge a few milliseconds earlier as you would expect to die in either case. In a web browser it is much less dramatic though the same principle is true: the browser is busy doing its many tasks and cannot waste too much time checking if the user has requested something yet. This aspect of performance, along with random hanging, is considered “responsiveness”. Mozilla targets 50 milliseconds (one-twentieth of a second) as the maximum time before Firefox rechecks its state for changes.
Chris Blizzard goes on to discuss how hardware is mostly advancing on the front of increases in parallelism rather than clock speed and other per-thread advancements. GPGPU was not a topic in the blog post leaving the question for the distant future centered on what a multithreaded DOM would look like – valuing the classical multicore over the still budding many-core architectures. Memory usage and crashing were also addressed though this likely was more to dispel the Firefox stereotype of being a memory hog starting later in the Firefox 2 era.
The GPGPU trail is not Mozilla's roadmap.
The last topic discussed was Sandboxing for security. One advantage of branching off your multiple threads into multiple discrete processes is that you could request that the operating system assign limited rights to individual processes. The concept of limited rights is to prevent one application from exploiting too much permissions for the purpose of forcing your computer to do something undesirable. If you are accepting external data, such as a random website on the internet, you need to make sure that if it can exploit vulnerability in your web browser that it gains as little permission as possible. While it is not a guarantee that external data will be executed with dangerous permission levels: the harder you can make it, the better.
What does our readers think? (Registration not required to comment.)
Subject: Editorial, General Tech | June 25, 2011 - 02:09 PM | Scott Michaud
Tagged: mozilla, enterprise
For enterprise users looking to introduce Firefox to their business: you may wish to reconsider. Businesses are notorious for being substantially behind in version numbers, occasionally (or a lot) trading even security for compatibility. Mozilla had a staggered release schedule: a minor version number was little more than a security update; a major version number was a fairly-large overhaul. Enterprise users were able to upgrade minor version numbers and be reasonably assured that compatibility would be maintained. There were no such assurances for a major version number, thus requiring rigorous testing before applying. Mozilla has ended their policy of supporting back versions with security updates and are also moving between full versions much more rapidly, causing dissension amongst enterprise users.
Moving the world forward, not backwards, and always twirling towards freedom.
Ed Bott took the opportunity to prod Mozilla during his Thursday evening column. He contends that shutting out enterprise will assist in the impending implosion of Firefox and allow Microsoft and Google to pick up the pieces. I seriously disagree with that statement and applaud Mozilla for staying focused on their goal. True, Mozilla will be vastly less attractive to the enterprise; however, if Microsoft did not have Windows and Office to push with Internet Explorer, would search ad revenue and donations cover the long-term development cost incurred supporting enterprise users? And really, I would have thought Ed Bott of all people (ok, except maybe Paul Thurrott) would respect a company that can make a decision like Mozilla just did and stick by it after covering Microsoft for so long.
Subject: General Tech | June 10, 2011 - 04:09 AM | Scott Michaud
Tagged: webian, mozilla, chromeless
Google Chromebooks have been talked about quite a bit lately particularly with the announcement of Samsung and Acer varieties nearing retail. You may believe that Google will be your only option as Microsoft and Apple are ignoring the stripped down OS market but you would be wrong. Webian OS has recently been released in preview form and combines Mozilla’s Chromeless project-based Webian Shell with openSUSE to make a self-contained OS similar to Google ChromeOS
Tired of what Simon says?
Webian Shell has a very minimalist interface with a tab-focused taskbar, the closest analog to application switching in a web-based operating system. Beyond the tab taskbar there is just a location bar which doubles as a progress bar; combined stop, go, and reload button; a clock; and the site itself. The project is not near completion yet as the developers anticipates to add home screen, widgets, onscreen keyboards, and other features as need arises. Have ideas or wish to contribute? Check out their website and GetSatisfaction.
Subject: General Tech | May 25, 2011 - 04:55 PM | Scott Michaud
Tagged: webp, mozilla, google
Google made news over the last year by butting heads with MPEG-LA with their royalty-free and open-sourced video codec: WebM. The hope was to provide an alternative to H.264 which was on a temporary royalty-free basis to end-users wishing to encode videos in the format (it has since been changed to a perpetual royalty-free license for end-users, 3 months after WebM’s release). WebM was mostly received with open arms from vendors, especially of free and open-sourced software such as Mozilla, and really shook up the industry. Google is now hoping to catch lightning twice by releasing a similar project for still images to replace the aging JPEG format. Mozilla’s response is suggesting that Google might just end up burnt by this experience.
WebP was requested to Mozilla Firefox’s bug tracker, Bugzilla, late last September as an enhancement request for Firefox. Since then, Mozilla closed the bug with a status of “RESOLVED WONTFIX” and a statement that they would not accept a patch for it but will re-evaluate their stance in the future if the format changes.
So for the near future it is looking like Jpeg, GIF, and PNG will reign Kings of the web. Mozilla’s Jeff Muizelaar goes into quite a bit of detail about their complaints with WebP in their personal blog. If you are a web developer you do not need to rush out and re-encode your images yet; however, you also do not have the option to if you still wish support the majority of web browsers. Typically that is a desire that web designers have.
Get notified when we go live!