This sounds very strange to me.
Many people are pretty excited that Mozilla is doing this Rust thing and trying to move the rendering engine to a safer language.
And now they start a project that:
a) wants to keep flash alive longer.
b) wants to replace their javascript (aka already memsafe) PDF renderer with a C++ one.
I mean I get that pdf.js is not perfect. It had some bad security vulns in the past. But pdfium also has a pretty bad wrap when it comes to vulns (I got plenty of bounties for it myself). But more than that: It's moving from a memsafe language back to C++. That doesn't seem to make any sense at all. If anything they should move their PDF renderer to Rust.
And Flash... please just let it die in peace and don't put any more effort into supporting it.
There is a ton of existing valuable, fun, educational, historical, etc Flash content on the web. There's no reason to cut off access to it if it can be handled more securely and more cheaply, which is what this project is intending to do. If they convert to this new system, they can retire a chunk of the older plugin framework which will soon only allow Flash anyway.
This is what Shumway was supposed to be for. Creating a Flash runtime in javascript/html5 which would allow all that "existing valuable fun, educational, historical etc Flash content" to live on, without making it attractive to continue creating Flash content. Allowing all that content to be archived for the future.
Unfortunately, according to that same thread, Shumway's been killed off. Without shumway, we're now losing a huge chunk of the web's early history and the first years of online video games, gaming on the web, etc.
I wish I understood what Firefox's mission is anymore, or what their goals were... they seem to just be randomly wandering around from vision to vision without really ever completing anything, which is not only extremely depressing but also extremely annoying, as I really really want to feel like there is an "upstream" I trust for "the web" :/.
From what I've read, the leadership of Mozilla has been taken over by money-minded suits rather than those who understand the mission of Mozilla, and there's a rift between the engineering team and this leadership. Of course I'm sure the reality is more nuanced than that, and I'm sure there are principled leaders that still remain at Mozilla, but that's the general impression I get. It's not unusual either, for non-profits to become more corporate over time, sadly it's a reflection on what can happen when the financial base of an organisation relies on making money.
You can't reduce a collection of the priorities of individuals down to a single one. Mozilla doesn't have a single direction in the same way Apple or Google don't have a single direction. You can look at the general goal of pushing the web forward if you want, but that idea has many forms of expression.
The real problem doesn't come from being confused about what Mozilla 'stands for', it's comes from short term thinking by their leadership. Their products are being undermined by a leadership that doesn't understand their potential worth (both in terms of their importance to the web, and financially to Mozilla). Without leadership that looks long term at what benefits the web and has a vision of how to get there, that leadership will mostly be a hindrance. Thankfully the engineering teams seemed to have struck gold with Rust/Servo (and in ASM.JS's influence on WebAssembly), which should serve Mozilla well as the technical basis for future development.
That is so irrelevant I'm having a hard time understanding why you're even bringing it up:
1. The flash plugin is honestly a piece of crap. Has always been. If running "a flash interpreter in javascript" is bad on your hardware, the plugin will be just as bad.
2. Nobody cares about performance on low hardware in the context of a project that is meant to move you off Flash and into more standard/open technologies.
3. We're talking about archival here. Performance isn't a concern today, and it definitely won't be in 70 years.
1: No, it is faster. 2: Don't make up facts. Also, if the pdf renderer will be faster and less memory intensive this will be a win for who can't afford new hardware. 3: Performance is a concern today and it definitely will be in 70 or more years. Remember, pdf part has nothing to do with archival.
You're bending facts and using rhetoric to make a false argument that implementing browser parts in C++ is somehow bad for web. These are the internal implementations of the given features and the more efficient the better.
You have got to be kidding me. You're seriously arguing that a closed flash plugin is better for archival than an open-tech-based solution because of performance?
When one requires a specific browser, with specific APIs whereas the other is a generic open source runtime?
This is a strawman, as it has nothing to do with the performance issues I brought up against your words. Though I admit I didn't know if pepper stuff was closed-source, my intuition was that it were open source if not why Mozilla would consider using it, but I was apparently wrong on that.
Still, though, that does not mean a JS pdf reader and more importantly a JS flash player are the way to go. That if you don't want to cater only to those who can afford high-end devices, which Mozilla seemingly is not doing, seen with the target market of Firefox OS and with their motto:
> Hi. We’re Mozilla, the proudly non-profit champions of the Internet, helping to keep it healthy, open and accessible to all. [https://www.mozilla.org/en-US]
After the initial exuberance when it seemed that OSs could be implemented in Javascript the harsh reality sets in that the language is not even adequate for implementing a pdf renderer, nevermind a Flash VM.
Any sensible person could have figured this out, but Javascript developers are arrogant enough to think that they should use JS for everything and succeed.
Maybe it's worth someone else keeping access to the existing content alive, but that doesn't mean it has to live inside Firefox and use up time and money that could be better invested in forward looking tech.
Separate projects/apps should instead be maintained by whomever thinks it's worth the investment.
If no one else steps up to maintain such a niche Flash project, then we know maybe the content wasn't worth saving.
Personally I'd like to see money and/or talent tossed at The Internet Archive for things like this.
Flash support runs contrary to maintaining a modern browser, while it's entirely aligned with the mission to preserve parts of the internet as reference material.
PDF.js doesn't support PDF forms, while PDFium does. Like Shumway and Flash, the long-tail of PDF compatibility is a lot of work spent on something that is not part of the Web.
Of course. It's part of the PDF standard and PDF government forms and similar that you just fill out and print are very common.
So switching to Pdfium means added user friendliness and convenience for users and significantly higher performance (when we last evaluated PDF.js, it was far from fast).
It is if your browser's default behaviour is to use the built in renderer. I've been confused in the past that a PDF was "broken", when in practice it was Firefox.
And yet, shipping something that works and is performant while at the same time reducing development effort is apparently more important for Mozilla than using Rust or Javascript.
In other words: market realities are more important than philosophical arguments about programming languages.
They took the right decision IMO, they can't afford working on irrelevant side-projects when they're losing the browser war.
I'm pretty sure they're still on path to deprecate flash regardless of which plugin api it's using.
That said it doesn't look like they are on path to integrate pepper-flash in any reasonable timeline. It's not even listed in the goals/milestones. It may be too complicated as I've heard the sentiment that pepper-flash uses 150% of PPAPI.
I for one find it funny that they claim they wish to reduce the time spent on "a complete web browsing experience, but
are not a core piece of the Web platform" reduce complexity and maintenance cost etc, and start with... maintaining their useless PDF viewer. Take it off your code base. Is it a browser or a PDF viewer? I guess expecting sanity from Mozilla really is insane.
I don't get this whole trend of trying to cram everything into browsers. People have been working on PDF viewers, media players, document editors and a whole bunch of applications for decades. Some are more lightweight, some are more feature rich, others are prettier, easier to use or more reliable. Yet there's this weird trend to throw all that away and reimplement everything as part of this huge beast. Why?
Part of the appeal may simply be an UX thing. For instance, I don't think a PDF reader should be a part of the browser codebase, but when I'm reading papers I found on HN, I like it that the PDF opens as another browser tab, not a separate application window.
I think browsers shouldn't really have tabs in the first place. That's the job of a window manager. And then you can decide which one to use. Do you want tiling or floating windows? Do you want workspaces? Stacked, tabbed, side-by-side layouts? Hotkeys or UI for navigation? Performance or features? And so on.
I agree, but browser developers have to work with the reality that most users use Windows, and windows has no reasonable solution to handle tab equivalents, or even large amounts of windows. And windows doesn't have a good way to extend or replace the window manager to fix that.
So instead we are stuck with each program implementing their own tabs.
Mozilla wants to remove the whole plugin API that these tools were depending. And some of the reasons are "Plugins are a source of performance problems, crashes, and security incidents for Web users."[1]
_Browsers_ are a source of performance problems, crashes, and security incidents for Web users.
I've had browsers crash, become unresponsive, use unreasonable amounts of memory or cpu. I've had youtube throw errors, load forever or pause videos and refuse to continue playing them. I've had js pdf readers produce unreadable garbage.
On the other hand, I've never had any problems with my choice of media player or pdf viewer, even though they offer far more features related to their specific job than any in-browser solution i've seen.
And browsers just keep adding more features - more resource hogs, more opportunities to crash and bigger attack surfaces.
Nope, that's not happening. Instead, it seems Mozilla is investing more of their relatively smaller resources on the most important two things that actually matter: a) Browser engine and b) JavaScript.
This is exactly what they should do. Produce the fastest, leanest, safest browser core. After playing with Servo, I feel it will be as big a release as the original Firefox was in the early 2000s.
With regards to Opera: they were pulling in record profits, quarter after quarter, while falling further and further behind Google and Mozilla. There was money to be spent on the browser if management wanted to.
I might underestimate the complexity of modern browser development, but they had income of >$300.000.000 in 2014, naively one would assume it could be possible to build a browser with that money.
> Well, Google, Microsoft and Apple pull in several billion per year...
Yes, but Mozilla doesn't also maintain the world's largest search engine, sell an operating system and office suite and gaming systems, or make computers, laptops, tablets, phones, and develop chips to run them on.
All Mozilla does is make software. And they only have one primary product. If x hundred million dollars per year is not enough for them to do that, I don't think the problem is that they don't have enough money.
Sadly that report doesn't tell us where the 212 million went into, I would suspect not mainly in Firefox.
Also it would be interesting what the 212 million of sofware development include from a payroll perspective, e.g. is it mostly developers, how much they are paid etc.
The Pepper API is supposed to be super easily sandboxable, though, right? It would be extremely strange if they decided to run PDFium and Pepper Flash unsandboxed, since I expect that the upstream projects treat them in the security model where Chrome sandboxes them. But if they are sandboxing it (and hopefully writing the sandbox in a memory-safe language), does it matter much?
Firefox sandboxes plugins like Flash and DRM plugins [1].
They weren't sandboxing web content previously (which I assume means PDF.js wasn't sandboxed?). But they announced this year [2] that they will be copying Chrome's security model and again supporting per-tab sandboxing. Instead of running all web content in one big process. Not sure if this was rolled out yet.
I really hope their security people push back on this (assuming they haven't already trumped security people who had a say in these high level decisions).
Although I didn't read the flash thing as finding a reason to keep it longer?
Edit: removed comment about Chromium, I forgot PDF.js was manually installed :p
Right, PDFium is the default. I've been using the PDF.js plugin for a while now and disabled the default via chrome://plugins.
Fortunately Chrome stopped supporting Foxit and Adobe PDF plugins with version 45 (released a year ago) when they depreciated NPAPI.
> As of Chrome 45, support for old, insecure NPAPI plugins is permanently removed. I believe Adobe Reader and Foxit Reader both integrate with web browsers through NPAPI plugins. If so, the old NPAPI-based Adobe Reader and Foxit Reader no longer works in Chrome, regardless of whichever version you have installed. http://www.chromium.org/developers/npapi-deprecation
I think this is bad news. I really like that pdf's in firefox is just another webpage. This means that all my plugins and other HTML-shenanigans can be used on pdf's.
This also appears to be a step away from Mozillas strategy of web-technologies everywhere.
Oh jesus christ. The entire ML thread is bad news.
Why on earth would they move away from PDF.js (which is a fantastic project) and then use that move to justify Mortar?
Also, I just learned this from the thread: Why the fuck would they kill Shumway? I'm all for killing Flash, but Shumway is an important tool not just for migration, it's also really important for archival.
God damn it Mozilla. I've talked about this before, too: Hearing Mozilla executives, each Mozfest, talk about commitment to the free web. Commitment to open technologies. What commitment, exactly?
In a handful of years, Mozilla has managed to severely damage its poster child web browser's reputation by including then subsequently dropping drm, by including then subsequently dropping Hello (a good initiative with a horrible user experience), by completely screwing up the launch of Pocket (which they could only have done by massively misunderstanding their userbase).
In that same handful of years, Mozilla took some good initiatives, such as Persona and Firefox OS, completely botched marketing and experience on both, severely underestimated the required efforts on the latter, then dropped both projects.
In that same handful of years, Mozilla dropped support for its second poster child, Thunderbird, arguably the last decent FOSS email client.
It all screams mismanagement and I haven't even talked about half of the problems. I've been upset about all this for some time but now writing it all out I'm starting to wonder of Mozilla isn't just in a free fall.
PS: I 100% understand the concerns and difficulties of allocating development time but this is a pattern I keep seeing with Mozilla: Spin up a project, get it to 80%, give up. You could build a castle with the amount of efforts wasted on projects either doomed from the beginning (FxOs), or dropped near the finish line. This is all absurd.
Anecdotally, PDF.js is slow compared to native viewers and often renders documents incorrectly. And the project is five years old now. It's not bad as a fallback, but considering how important PDF files are, looking for a better solution makes sense.
Agreed. As an OS X user, I hate it any time a browser or website uses something like PDF.js instead of the native PDF support. The native PDF support in OS X is fast and excellent.
PDF.js sole purpose is to be non native. I don't want to rely on native existence of a safe enough, fast enough PDF renderer. PDF.js provides just that.
Then they should make PDF.js faster! The way it uses a canvas could be significantly improved. I guess the point is that they don't want to invest the engineering resources to do that, which is a shame but I understand the reasoning.
I got tired of constantly updating due to vulnerabilities. I haven't had a PDF viewer installed for years, I have PDFs open in Firefox.
I got tired of having Adobe Updater constantly running in the background (why not a scheduled task run periodically like Google Updater?!) and the need to update/reboot my PC regularly when a new version of Acrobat came out.
I switched PDF viewers briefly but ended in the same update cycles I was in with Adobe.
PDF.js isn't perfect but I've yet to come across a PDF that it couldn't open for me. I use it mainly to view things like insurance bills or other random documents where pixel perfect rendering is irrelevant.
Agreed. I use Firefox on OS X and I love pdf.js. I found it a huge hassle to get native PDF working on Firefox in the past, and with pdf.js I just don't have to worry about security. I've also not had much/any compatibility issues with pdfs. Bills, concert tickets, and specs all render acceptably. I will be very sad to see it go.
As a scientist, pdf.js is simply not capable enough for any serious work with pdf.
I would love to do as you say, and read pdfs in the browser only. From what I have learned in the context of this discussion, switching away from pdf.js will contribute to enabling that.
> As a scientist, pdf.js is simply not capable enough for any serious work with pdf.
As a counterpoint, I regularly read (CS) research papers in pdf.js and have never had any trouble. One of the reasons I stuck with Firefox is the superior Zotero integration.
Nonsense. On windows I have used foxit for a long time and I never had all that shit that you are talking about.
On Mac if anyone told me that they used happily a JavaScript PDF viewer instead of the built in viewer I would seriously worry for their mental health.
The only time I ever start a native PDF viewer is when I need to actually print it. Apart from those rare cases, to me a PDF is a web page, just worse, and I want it to live where all the web pages live on my computer, in a browser tab, with all the facilities the browser provides (history, tree style tabs, frictionless access to Google, etc etc).
I'm sure ymmv depending on what kind of PDFs you use and how often; I'm on the lower end.
I might be in the minority, but I really dislike reading PDFs on OS X's Preview while using the touchpad because of accidental horizontal scrolling. I do not understand why Apple decided to make the "rubberband" effect when clearly there's nothing to scroll on the left and right sides of the PDF. If anyone has a solution to prevent horizontal scrolling on OS X applications (Safari, Preview etc), please do share.
Have to admit I find it pretty damn useful myself, even though I believe PDFs to be completely out of scope of a web browser.
I really wish the format would disappear. Everybody says it's useful at being a "perfect digital representation of what things look like on paper", which is certainly super useful for printing. But I cannot understand how so much information that should simply be distributed in either HTML (forms), epub (ebooks) or jpg/png (scans and digital images) is distributed over PDF, a pain-in-the-arse, overengineered format whose readers are always extremely slow and riddled with security issues and from which it's extremely hard to extract source data.
There are a number of places where PDF has advantages that HTML, etc can't match. For forms, the PDF spec has electronic signatures, which means that you can sign legal documents without having to find a fax machine, or mail things back and forth. For print documents, it can do things like multiple column text in a sensible manner, across page breaks. As a general document format, it allows you to actually describe paper sizes, etc, so you can email someone a document that looks like it will when it's finalized. For archival, it means you can, without a bunch of hacks, create searchable documents of old, scanned in content. So things like electronics datasheets are searchable, and still retain the formatting of the originals. PDF continues to exist because there are so very many places that the alternatives are an even bigger pain in the ass, fix those, and then you can start to get rid of pdf.
Shipping Shumway has some problems due to patent claims by Adobe, as I understand. It was thought that things could be worked out, but apparently that fell through.
So the options are to either keep developing Shumway but not ship it, or stop developing it and not ship it. The latter is a bit more attractive if resources are limited.
I have previously installed shumway but it never seemed to work on the websites I wanted to load. :( So perhaps the remaining effort to get it working was too much.
Thunderbird is still my email client and it's still getting updates. Not sure where it will be in a couple of years, but for now it's still very much decent. And I liked the idea behind PDF.js very much, have been a big fan, but it's still rendering documents incorrectly and doesn't do forms.
Mozilla is an organization that needs to be careful about allocating their resources. These projects are open-source and with enough interest they can continue. If Mozilla's Persona died, that's because it never had a future in the first place and killing it was the right call ;-)
And on Hello and Pocket, I really don't understand the drama. I think the Internet is making some of us way too pissy.
They're not killing PDF.js, just taking a step in a direction that might eventually lead to it dying. This is explicitly mentioned in the ML thread.
Shumway hasn't been worked on in a while. No idea why, but I would guess that it has something to do with how large the Flash feature set is. Long tail and all that.
The reasoning here is probably like so (speculating here):
- We want to deprecate most plugin APIs
- We still want to support flash
- Shumway isn't there yet, let's use pepper flash
- Flash and PDF probably need very similar feature sets as far as the API is concerned
- Supporting the subset of PPAPI needed for Flash is probably going to let us include PDFium too, which is already supported by Google. As long as we're going down this path, let's try to include PDFium too.
- In case PDFium turns out to work, we can decide if pdf.js needs to be replaced
I personally hope that pdf.js isn't replaced; since a JS thingy is far better than a vulnerability-ridden C program. At the same time, this depends on how much the demand for a full pdf feature set is.
> this probably means more work gets done on Gecko, Servo, the Monkeys, and Rust
Well, does it? Are they moving devs from PDF.js to the Rust ecosystem? It seems more likely to me that they would either lay them off, or move them to the PDFium stuff. Same applies to Shumway.
What a backwards step either way. As for Servo, how's it doing these days? Is it anywhere near done? What terrifies me is Mozilla would drop Servo when it's 80% done, just like it did with all its other projects, because "well, we already have Gecko, and it works, and it's too much work to finish Servo".
Aside from Rust and some Firefox tech, I haven't seen anything concrete come out of Mozilla in a long, long time. Rust, FWIU, has its own organization and is no longer handled by Mozilla alone (thank god); everything else gets killed off like a westerosi wedding.
As I mentioned elsewhere, there haven't been any full time mozilla devs on PDF.js for quite awhile. I'm not sure I actually see the whole maintenance cost savings argument since PDF.js has practically cost Mozllia nothing the last few years. A lot of bug fixes have come from unpaid contributors in that time.
Initially, PDFium was pitched as a freebie if we added support for chromium's flash and then we'd also get improved PDF printing and form support. However, the amount of effort that has gone into supporting PDFium is already far beyond what it would have taken to improve PDF.js form support and help improve Firefox's printing (which would have benefited the web in general). Though, this is my very biased opinion as I was tech lead of PDF.js.
Good god. So the project was already unmaintained, and now they're dropping it in favour of a maintenance burden, all the while regressing from a JS solution to a plugin-based native one?
I was wrong, Mozilla isn't in a free-fall. They hit the ground and are now digging the grave to bury themselves in.
Thanks! Good to see a blog. I'm very excited about Servo; like I was saying, I just really hope it won't get killed off before it reaches the finish line and replaces Gecko.
I don't think they'll kill Servo. They need to modernize Gecko, and there's so much potential in Servo to do so that it would be a waste throw the code out.
scrollaway is not behaving like a troll. Mozilla have engaged in some very bizarre moves in recent years. Whilst I don't think Servo is in trouble, it's fairly clear the leadership of Mozilla has become erratic. Thankfully the development of Servo goes beyond just one company.
Not necessarily moving devs; people have different competencies. But keep in mind that—despite being a nonprofit— Mozilla does pay its developers, and most of the work is done by those paid developers. Layoffs of non-core-project devs free up budget to hire more core-project devs.
While I also appreciate Mozilla's browser renderer, PDFs really aren't web technology. If it's a question of constrained resources, I'd prefer Mozilla focus their energy on improving HTML-shenanigans overall, not maintaining a PDF rendering application.
I fail to see how they are so constrained. They have more money than ever, and have just dropped Firefox OS, which - all things equal - should free up a lot of developers.
Care to hazard a guess at the number of people at Google working on Chrome or at Microsoft working on Edge?
Last I checked both were bigger than the number Mozilla has working on Firefox.
And yes, the people who were working on Firefox OS are now working on other things, and we _still_ don't have enough people to cover all the things that need doing...
For how long? Sure they have a deal with Yahoo (Verizon?) that could fund them for some time. When that deal runs its course what do they have to bargain with?
Their market share is currently in the single digits on the desktop and they have virtually no market share on mobile which increasingly is more relevant than the desktop in terms of usage.
It's smart for them to decrease costs and maintenance burden right now while they still have the resources.
Desktop usage is still around 15% according to statcounter. They are ~7% across devices.
Firefox for Android has become really good, and I prefer it to Chrome, but my impression is that mobile users are very unlikely to stray from their default browser, even if it is just the blue globe "internet"
I'd like to use them on mobile, mainly because ads are so absolutely obnoxious on there, but their user interface isn't that great and seems to be the one place they haven't copied Chrome.
other things they have put thunderbird and parts of the addon system in maintenance mode. Various other less frequently used browser features have been discontinued too. So there has been some fat-cutting going on for a while now.
They've also put a lot of effort into looking and acting more like Chrome. I killed auto update on Firefox when they added search suggestions more like chrome because it broke my workflow. People had complained about the ui being made more like chrome, features being dropped to be more like chrome, etc., for a while. Then you have the deprecation of the Firefox extension model in favor of, essentially, chrome's.
It is harder and harder to see how Firefox stands out on its own as opposed to being a chrome imitator. This is just the latest example. If they think they can sell Firefox based on a free and open web instead of based on power user features, a great extension ecosystem, or whatever, I can only say...good luck. I don't know many projects that have succeeded outside a small core of users based on ideology.
Servo may be the distant future of Firefox. But I am becoming increasingly pessimistic that Firefox will even make it to that future, which I feel awful about. I don't understand what mozillas leadership is doing.
> Then you have the deprecation of the Firefox extension model in favor of, essentially, chrome's.
This comes up every time as an example of Firefox copying Chrome. It's not.
Firefox's extension model wasn't a model, it was a wide open API hole which you could reach into and tweak whatever internals you want with. That's not great -- each update is bound to break things, and architectural changes like electrolysis are even harder to make.
This needs to go. What can it be replaced with? A web standard! Web extensions are this web standard. Now is an ideal time to do this replacement because electrolysis already broke a large part of the addons ecosystem, so you can piggyback on this breaking change.
Chrome and Opera both use the same API. It makes sense to use this as a base for a standard. The old XUL API in Firefox can't really be used as a base since there was no API boundary.
However, Firefox plans to implement a more powerful version, such that most extensions that worked with the old API will continue to work after upgrading. So while code will break, the new API will still expose the same functionality. Well, it can't expose all of the same functionality since we're back to square one in that case, but it can expose enough to make most extensions still work. As an end user, I suspect you will just have to upgrade your addons and otherwise not feel a thing.
I don't know of any other features being dropped to be more in line with Chrome. The UI is at most superficially similar to chrome wrt the tabs (and you can go back to square tabs if you like with a setting, one which is enabled by default in dev edition). The rest of the UI changes (e.g. the customizeable UI) that landed then are nothing like Chrome.
People always being that up like it is a good thing... I like Firefox the way it is, I do not like electrolysis or the way chrome does it processes
>>Firefox's extension model wasn't a model, it was a wide open API hole which you could reach into and tweak whatever internals you want with. That's not great
Actually it was/is Awesome, It is what made Firefox great.
> Firefox's extension model wasn't a model, it was a wide open API hole which you could reach into and tweak whatever internals you want with. That's not great
It was great for the extension ecosystem, which, of course, could literally do anything.
Did it have drawbacks? Of course it did. Nothing in life is free. The fact that extensions could do anything was one of the key features that made Firefox stand out, almost since the beginning. Now, aren't able to, because Mozilla wants to make the same trade-off Chrome made. In fact, they want to make almost the exact same trade-off. They are attempting to ameliorate the issue, by, essentially, adding to the API to grandfather in many popular Firefox extensions.
The fact you mention Opera has another adopter of this 'standard' pretty much only helps emphasize the point. Opera dropped everything that made Opera Opera and turned into, essentially, a reskinned Chrome. That's why you don't see the very vocal Opera fans posting anymore - they abandoned Opera (or the later versions of Opera) because they didn't want a reskinned Chrome.
> I don't know of any other features being dropped to be more in line with Chrome. The UI is at most superficially similar to chrome wrt the tabs (and you can go back to square tabs if you like with a setting, one which is enabled by default in dev edition). The rest of the UI changes (e.g. the customizeable UI) that landed then are nothing like Chrome.
It's been going for on for years, and sometimes Mozilla developers literally cite Chrome as the reason they're doing it.
My friend's big complaint is that Panorama was dropped, which had been around since Firefox 4, if I recall correctly. Panorama, and many other features, have been dropped because, supposedly, not enough people used it. But that's exactly what you expect from power user features: 80% of the people use 20% of the features, but they all use different sets of features.
What killed Firefox for me was "unifiedcomplete." This feature is a move towards having a unified search bar and address bar. While at the time I last used it there still were separate UI elements for the address bar and the search bar, the first result in the address bar was always "Search $SEARCH_ENGINE for X", which meant that every single time I used the address bar, I had to hit tab at least one extra time. Additionally, it crippled the Awesomebar - my address bar results no longer bore much resemblance to what they had been, so I had to do a lot more typing or tabbing to get where I wanted to go.
But there are plenty of examples going back years. It's rare, now, that a release doesn't drop something or change functionality to be more like Chrome. That was just the last straw for me. There was a very vocal group of users that hated Australis for being too Chrome like (was that when we got the hamburger menu? and when the status bar went away? I don't remember). Another example is the six-week release cycle, or multi-process browsing. Though these are sold as uniformly good, they come with tradeoffs, and Mozilla is choosing to make the same tradeoffs as Chrome.
Not all of it has been explicit Chromification - some of it has been the attitude, apparently prevalent, that as much configurability as possible should be removed lest it confuse someone. For example, the removal of the "disable Javascript" checkbox.
> Well, it can't expose all of the same functionality since we're back to square one in that case, but it can expose enough to make most extensions still work. As an end user, I suspect you will just have to upgrade your addons and otherwise not feel a thing.
As a user, I disabled Firefox updates many versions ago to retain a working Firefox, so no, I won't. In the long term, I will have to switch to something else, because I'm not getting security updates, and I know NoScript doesn't give me 100% coverage. Which is really incredible - I spent years contributing to Mozilla and evangelizing Firefox, because I believed it was the best browser. Now, I don't recommend it (or anything in particular) because...why? I don't know what I can tell people that would justify me recommending it. "Free and open web" is not a reason I can use with the average user. I can't really see any real differences between Chrome and Firefox anymore, from a user functionality standpoint. More websites ask that you use Chrome or IE for compatibility. Chrome is generally ahead on "standards", if only because Google invents new ones that it then uses on its web properties.
> It was great for the extension ecosystem, which, of course, could literally do anything.
Right, and that helped keep the rest of the browser stuck and slow. I think electrolysis really drove this realization home.
> While at the time I last used it there still were separate UI elements for the address bar and the search bar
As far as the "hitting tab one extra time" is concerned, yeah, that should be customizeable. You can get rid of the search bar (which I do), but in case you have both visible you really don't need the awesomebar to do searches.
I wonder if I can add customization easily. In my personal workflow half of the time I need search but I get that that's not for everyone.
> Though these are sold as uniformly good, they come with tradeoffs, and Mozilla is choosing to make the same tradeoffs as Chrome
Fair. However, they both seem to address the needs of the majority of the user base (fast browser that works with modern websites and modern browser usage, not something that can be easily done with single process or a slow release cycle). This does mean that some users lose out.
Totally agree with the power users point. I was annoyed with the removal of Panorama as well. I now use Vertical Tabs (and may switch to Tree Style) and it is good enough, but if my tab usage was even higher it wouldn't be.
> In the long term, I will have to switch to something else
Sorry to hear that. I personally used to use Chrome (since around 2010) even when I started contributing to Firefox (I contributed to Firefox because it was easier; Chromium didn't have a great build/contribution process). I later stopped contributing to Firefox because I didn't have time, but I switched over to it around last year because it got much better. I'm surprised that folks find that it got worse in that time period, but I suspect it's just that the changes I liked were disliked by others.
If it helps, when the feature was first introduced (43, I believe), the pref to control it was browser.urlbar.unifiedcomplete. It was later removed.
In addition to the search with, I believe it also changed up how the awesomebar search itself worked, weighting url contents, for example, much higher than page titles, and (I want to say just based on end user experience) throwing away page visit frequency information. Strangely, it would also recommend pages I had never visited, if that page was top level and something I had visited was further down.
Trying, yes. But the method they have chosen is to abandon what made Firefox popular in the first place and imitate Chrome. So why not just use Chrome?
IOW, they're killing the goose that laid the golden egg by trying to transform it into a duck. But if I wanted a duck, I'd already have a duck.
I guess they're blaming Chrome for their lost market share rather than blaming themselves for mismanaging their product. So instead of fixing their mismanagement, they're just trying to copy Chrome.
They used to be leaders (without Mozilla, Chrome probably wouldn't exist as it does today), but now the leader has become the follower. And who needs another follower?
Another perspective is that the Web has "grown up" since 1998. Back then the percentage of Web users who were "power users" (remember, empowering users was the mission back then; "Take back the web!") was much higher--but the raw number was still enough to be fruitful. Since then, half the planet is on the Internet, and the percentage of them that are power users is much lower. The raw number is surely much higher still, but that's not enough for Mozilla--they've got to appeal to the masses to get the percentages. All the loyal users who've been with Mozilla for nearly two decades? They can switch to...uh...Pale Moon, I guess. Mozilla just wants the noobs, because that supposedly brings in the most money.
I hate to say it, but Mozilla needs to die so it can be reborn--again. Every so often, the tree of browser needs to be cleansed with the blood of layoffs--something like that. Then their successors can focus on making a good browser instead of chasing more millions.
> "I hate to say it, but Mozilla needs to die so it can be reborn--again. Every so often, the tree of browser needs to be cleansed with the blood of layoffs--something like that. Then their successors can focus on making a good browser instead of chasing more millions."
And you're thinking that because in all of human history, a success story happened exactly once.
Not much of a sample dude and if I were to bet, I'd say that if Mozilla dies, then Firefox will be completely dead as well, because the market dynamics have completely changed since 1998. The elephant in the room being that developing a browser takes a lot of resources and can no longer be done by a bunch of students on their free time.
> "Mozilla just wants the noobs, because that supposedly brings in the most money."
That's a really condescending and damaging attitude. Most of us are in this industry to serve the needs of the "noobs", in order for them to be better at their own jobs. It's how society works you know.
> Not much of a sample dude and if I were to bet, I'd say that if Mozilla dies, then Firefox will be completely dead as well, because the market dynamics have completely changed since 1998. The elephant in the room being that developing a browser takes a lot of resources and can no longer be done by a bunch of students on their free time.
You're likely right, of course. I should have clarified that I don't think that Firefox necessarily will be reborn if Mozilla fails, only that I hope it would be. But I'm afraid that we will find out before long...
> by a bunch of students on their free time.
I'm not an expert on the history of Mozilla, but my understanding is that it was never developed that way. It started with the Navigator code drop from Netscape, and the Mozilla organization was quickly formed around it with existing developers. It took a few years before they had "Firefox" out the door, but I don't think they did that for free in their spare time. Please correct me if I'm wrong. :)
But you're right that developing a browser that can compete with existing ones (in security, at least) is probably impractical without a decent number of full-time staff.
And that brings to mind an idea: a community-funded security team paid to keep up with security fixes, while the rest of the browser is maintained by community volunteers. Sure, it wouldn't get developed as quickly--but I, for one, would be happy to have less UI churn...
> That's a really condescending and damaging attitude. Most of us are in this industry to serve the needs of the "noobs", in order for them to be better at their own jobs. It's how society works you know.
I understand how you could interpret that as condescending, but that's not how I intended it. From my perspective, it's the "non-noobs" that are being condescended to by Mozilla as they continually shoo them away, effectively telling them, "This browser you've been using for 18 years--it is not the browser you're looking for..."
Witness the bug report in question here, in which a Mozilla developer says that Linux users can be expected to build Firefox themselves--he assumes that all Linux users are "Linux developers." What does he care if thousands of people suddenly have their browser fail to function? Mozilla can't be bothered to maintain the existing ALSA backend code.
Is that not their job, to maintain the codebase? What are they getting paid for? Why are they being paid to remove features? Why are they being paid to do things that their users don't want? Please don't lecture me about "maintainability" and human resources--I understand the burdens of legacy code, spaghetti code, etc. The answer is not to toss it into the bitbucket, pulling the rug out from under users. The answer is to refactor the code to improve maintainability, and replace the old code when the new code reaches parity. This is like, they've hit the CADT-panic button, and anytime they see old code, they go, "Eww, gross! Deprecated!"
It's like the ship is sinking, so they're starting to toss things overboard--including pieces of the hull. That will make the ship lighter, while at the same time letting more water in. Eventually it ceases to be a useful or salvageable as a ship, and the passengers jump ship, and then the crew has no passengers or ship. It's like the ship of Theseus: an interesting thought experiment, but it turns out that replacing the hull during a voyage causes ship loss. If they want to build S.S. Mozillium, they should park the S.S. Firefox in drydock first. At least that way the passengers wouldn't have to swim.
Firefox started from a Navigator code dump, but KDevelop was developed in the open by volunteers, along with KHTML, which is how WebKit was then born. Back then it was completely possible to compete with IExplorer as an open-source project, because the expectations weren't that high.
I don't know what the situation for Linux is, even though I'm a Linux (Ubuntu) user at home. But traditionally Linux distributions have been building their own packages. I can understand such concerns though, I care very much about Linux.
That's a good point about KHTML. A long time ago, Konqueror was actually usable as a web browser on most sites. And of course, WebKit has diverged so far...
Maybe what we need is to split up the browser: develop the rendering engine, JS engine, UI, etc, separately, with well-defined APIs. Then the things that require dedicated expertise could be developed by full-time employees, and the results of their work could be integrated into different end-user products, different browsers with different target audiences, developed by different groups, with much less effort and expertise required.
Of course, this is what Gecko and XULRunner used to be. Now Mozilla's direction is just demonstrating how badly needed their former course of action still is.
libgecko, anyone? (or even libservo--but will they handle it the same way they've handled Gecko, and make it practically Firefox-only?)
> Desperately trying to get back to two-digit marketshare?
> Trying to compete, as the last major open browser, against all the corporate browsers?
Firefox was successful because it was a great browser that power users picked up and evangelized to their friends.
Chrome became successful because it was a great browser that Google has pushed hard to users on all their properties, which serve billions of people a day.
Internet Explorer is successful because it's a reasonably good browser that is installed by default on millions upon millions of computers, and because it supports all kind of enterprisey things that enterprises care about.
Safari is successful because it is a reasonably good browser that is installed by default on a platform used by millions of people, and is the only browser actually available on a platform used by millions and millions of people.
Nobody as big as Google or Microsoft is going to push Firefox. Nobody. And if they did, we'd probably consider it a corporate browser anyway. So what is Firefox's strategy to get ahead? To all appearances, cut out the features that made it popular among its core users and strong advocates, and imitate Chrome, because Chrome is popular. But Chrome is not popular because of its features or UI, it is popular because it's a Google product.
I cannot see how Mozilla's strategy is going to succeed, and I've only seen it drive people away - and that includes me, because eventually I will have to move off an outdated version of Firefox. Maybe they have some kind of master marketing plan when they get the product where they want it. I don't know. I don't see how even Servo is going to bring users back. Supporting a free and open web is great, and a goal I support 100%, but at the end of the day I need a web browser that works for me. You can't retain anything more than a very small user base by selling yourself on ideology if that's the only thing that differentiates you.
They're deprecating XUL and the NPAPI plugin architecture so that they can move to servo relatively legacy free.
Importing Chrome's SWF and PDF is a way to stress test their new plugin implementation.
Not maintaining pdf.js seems a budgeting decision but Flash is restoring functionality to Linux via a cross-browser plugin, which Adobe had abandoned for Chrome only.
OTOH, this means more focus on things like Rust, Servo, Gecko improvements, and JS engine optimizations (to say nothing of implementing ES6 and beyond).
Any more components that are coming directly from Chromium?
This is an interesting move if it allows Mozilla to focus on Servo and the new Rust components. At least I hope that's what they are doing, after the recent Firefox OS news.
As an outside observer and Firefox user, this seems ridiculous and I don't understand the thought process at all. PDF.js works as far as I've seen, and my understanding was it was pure web technologies. How does Flash fit into this? Why is dropping PDF.js suddenly a priority?
PDF.js worked in my experience too, but it's the usual problem with a massively complex format like PDFs - getting 80% or 90% is feasible, and PDF.js does that great, but getting to 100% - things like forms, etc. - is very, very hard.
It's easier to just use an existing PDF renderer like PDFium that already has the 100%.
The Flash thing is separate. Flash is sadly still necessary on the web - most people won't use a browser without Flash, except on mobile. And the pepper version of Flash is more stable than the other.
Where the two connect is that if you support enough pepper for pepper-Flash, then you also have the option to use that pepper support to run PDFium.
Why not just drop Flash and PDF support? Flash is dead and PDFs never needed to be rendered in browsers in the first place, they can already be opened through free, cross-platform, open source programs with all the features on the goal list.
As a counterpoint I love pdf support in the browser. People post pdf versions of most documents, papers, and presentations and viewing them in the browser makes the overall experience so much better! I actually have chrome as my default pdf viewer because it starts up faster than most other pdf viewers and I'm more used to it.
I've never understood why you even needed a browser plugin to do this. Why can't the browser just spawn a PDF viewer-app's COM server or equivalent, and then hand it a rendering context and send UI events back and forth—all without even knowing what exactly the filetype it's embedding is?
Flash is not entirely dead yet, so support can't be completely dropped. However, both Chrome [1] and Firefox [2] have announced long-term schedules for removing support for Flash, bit by bit.
As for PDF, the PDF viewers shipped in browsers seem to be much more hardened against attack than the stand alone ones people use, so as a practical matter, including a PDF viewer helps keep users safe.
In Windows 10, Reader was officially merged into Edge. The app that remains in the Windows Store will gently encourage you to use Edge instead. This seems part of the direction shift from simple task-focused apps (back) towards branded monolithic apps as Microsoft tries to find a healthy middle ground between good for mobile and convenient for old desktop users. (It's been a bigger deal of public concern with the Messaging/Phone/Skype apps back and forth shifts, but that hasn't been the only place this has been happening, as seen here with Reader, Reading List, and Edge.)
I remember that one. Before 8.1, it could not print PDFs. I have been struggling ever since to come up with an appropriate metaphor for how idiotic a PDF viewer without printing is.
Windows 8 tried to move all of printing into the Charms bar, which was a great idea in that something so common (so many apps need to print) would have one big place to nearly always find it, but of course was also a bad idea because learning the Charms required unlearning the idea that every app has its own Print button scattered somewhere possibly randomly in the app itself and learning the Charms instead.
So you could definitely print PDFs in Windows 8 from the Devices Charm. You'd just need to know that was what the Devices Charm was for.
(I thought the Charms were a good idea that Microsoft didn't quite know how to execute.)
OTOH, pdf.js is the first thing I disable in Firefox, since SumatraPDF and Atril render things much more quickly and lightly! :)
I can understand customer demand but I'd prefer if it was optional - e.g. the first time a user visits a PDF they're prompted to install a viewer if they so wish.
True, but since Windows (up until 7, and then on 10 as well) doesn't come with a PDF viewer by default, the only popular platform that guarantees a PDF viewer is OS X, which only makes up a small portion of Firefox users (7 percent as of 2009 [1], can't find newer statistics though), especially since Firefox is quite popular for GNU/Linux users.
And anyways, it all comes down to convenience. I know of many people who would much prefer viewing a PDF in their browser than having to switch between applications even though they're "techy enough" to install one. If people are happy with the PDF.js or some other in-browser PDF viewer, why make them switch?
I can assure you that Arch Linux and Manjaro do not come with a PDF viewer. Considering openSUSE is distribute with other desktop environments than those you listed, it doesn't seem to come with a PDF viewer by default (although it's possible that I missed some package that adds it anyways). Please don't spread misinformation without first researching the topic.
Of course you might get openSUSE in a flavor without a PDF viewer, but you could say the same thing about Ubuntu: Just get the Server edition. So when we're talking about "by default" I also consider the "default" flavor of those distributions.
OK, our experiences differ it seems. Maybe your docs are bigger or harder to render or something.
I mostly open < 50page docs, typically api specs etc. I guess they are converted from Word although hard to say.
Computers specs are 1 y.o. laptop, ssd, dual core intel with 16 GB memory and ssd.
I have expeeienced broken docs once or twice but nothing that really bothered me.
For me the convenience of normal Firefox search etc working is worth firing up an external pdf reader for once or twice a year.
I wonder if I haven't seens ome kind of web form or something where you could submit hard-to-render docs but this of course doesn't help if the docs are NDAed or something.
CBS.com requires flash and has lots of great content such as "The Late Show with Stephen Colbert". Also one of my banks requires Flash for online check deposit. If Firefox dropped flash, I'd drop Firefox.
When NSAPI plugins were around, I could use kpartsplugin to make PDFs render with KDE's PDF reader in the browser window. This was the perfect solution, and I'm still more than a little bit pissed that it's no longer available.
The reason Flash is still around is because of ads. Most (video) ads are served through Flash still and publishers still don't know how to switch, or don't want to.
Agreed. Advertisers are stupid these days. They don't realise that when they crap in their own backyard, nobody goes near them. If they want to misuse Flash (which they do, all the time) then we all stop using Flash. Most of us install ad blockers.
Folks might want to downvote me, but Flash ads are a big reason why people install adblockers. It's now shifting to JavaScript injections from ad networks, so it's only a matter of time before adblockers start analysing JavaScript to prevent them from misusing this mechanism also.
How many people are working on PDF.js that are paid by Mozilla? https://github.com/mozilla/pdf.js/graphs/contributors looks like there are only 2 main contributors (i.e. maintainers, in the sense of continuously and ongoing committing for longer time)
Yury and I are the only paid staff that work very occasionally on PDF.js. We both have not been full time on the project for quite awhile. We do have a pretty active community and quite a few outside companies using PDF.js though.
Thanks. Your answer and your work even more so are very much appreciated! I hope you can keep it up. Maybe some of the other companies could also jump in with as financier (though I do not have too high hopes for this as taking is more common than giving...)
Seems like the Internet Archive would be the most likely org to care: a Javascript renderer for PDFs lines up with their "preservation and easy display through in-browser emulation" philosophy.
1. pdf.js has only seriously attempted to implement forms over just the last few weeks, and has made significant progress[1] not to mention someone did quite a bit of it on their own 4 years ago and no-one seemed interested in working with him. [2]
2. Mozilla has a strong interest in furthering web technologies, and pdf.js could be used in just about every enterprise LOB and government form based workflow (as they slowly move to web technologies), if it matured a bit more. Has Mozilla thought of how their unique position as a non-profit could enable them to partner in ways a corporation could not? The insurance industry on its own produces 10s if not 100s of millions of pages of PDFs every day...has anyone from Mozilla ever talked to ACORD (or even knows who they are?)
Interesting. I didn't know that someone had started working on form support (in 2016 or 2012). PDF.js started in Mozilla Research as a demonstration, and benchmark, for JS and Canvas capabilities. I don't know how much work adding full form support would be. PDF is a complicated format and I imagine there are a lot of corner cases.
(I work for Mozilla but am not involved with PDF.js or PDFium.)
Acroform support (so not the proprietary Adobe Livecycle XFA stuff) is relatively straightforward once you understand the underlying PDF specs. It's been around since PDF 1.2 (1996!!)
At the rate I see development moving, pdf.js should be able to handle, say, every IRS form well before the end of the year, perhaps much sooner.
If I had the skills or resources to help now, I would.
I still don't understand why Mozilla has apparently not reached out to the larger business/governmental universe to see if they could partner in moving pdf.js forward. A single large insurance company might spend millions each year on licensing and implementing pdf "solutions". I can only imagine what the US government uses (or could use.)
Has anyone from Mozilla spoken to 18F?
Perhaps even a open (and not proprietary) JSON (instead of XML) based form standard for "next-generation" forms could be implemented, with PDF.js at its core. (see https://github.com/modesty/pdf2json I linked to before for an element of that...the author is an employee of Intuit...perhaps it's already being used by them for their online tax software?).
When I click a non HTML link, FF asks me what to do, I select open and it opens the PDF with mupdf. I get that on windows you don’t want require people to download Acrobat reader, but why not just bundle FF with a good PDF reader on Windows? There must be open source projects doing PDF on Windows?
The last ESR of Firefox was reasonably fast, since I updated to 45 everything is sluggish. The upside is that some HTML5 audio features work better now, the downside is that the Youtube video player is so inefficient I needed to install a plugin that disables it (the fan is roaring).
Many years ago I installed a native Mplayer plugin for Firefox, and I could watch videos on the web. It was a 800Mhz CPU, and a 32MB Radeon graphics card? I could play videos without touching the CPU?
Right now I am typing a HN comment and FF sits at 100% for whatever reason...
My point is, everything implemented in a browser that is not a HTML/CSS renderer or JS JIT compiler, seems to suck to the point of being useless.
As much as I would like to get rid of the Flashplayer plugin, its the most reasonable way to play video in FF. Less of a CPU hog, less crashes. How did we get into this mess?
Same argument why Opera chose to base their browser on Blink. PDFium is 100% dependent on Google. I do not think it's a clever move to go down into this dependency.
Sure web > pdf > flash in terms of mozilla's focus, but I fear pdf will be part of the web for a long time to come.
If Mozilla wants to lower their engineering costs, wouldn't it make sense to start cutting back on projects like Rust?
Don't get me wrong, Rust is an amazing project and I am happy it exists and grateful for their work on it, but if I had to choose between Rust and Firefox, for the shake of internet and freedom I would choose Firefox.
I guess a PDF viewer or just another implementation of Flash is not sexy, interesting work, but IMHO is more aligned with the mission of Mozilla.
Part of the motivation of Rust and Servo is that Firefox in the long run is unmaintainable. It's many millions of lines of C++ code, any of which could corrupt memory or create a security vulnerability, and it's a very old codebase that has to deal with architectural decisions made decades ago when the web was very different. (Firefox was first released in 2002 as a fork of Mozilla, Mozilla was first released in 1998 as an open-source fork of Netscape Navigator/Communicator, and Netscape Navigator was released in 1994.)
Mozilla had the option of either remaining in long-term software maintenance mode and falling behind or doing something to move forward the state of the art in browser design and security. Sometimes the seemingly-risky choice is actually the safer option; I hope it works out.
Investing in Rust is the best Mozilla can do for the long-term prospects of Firefox. The safety and speed of a modern language like Rust could be a real game changer when it comes to the competition with Chrome.
It was already shut down. Years after they should have – actually it should never have been started in the first place –, but they finally did pull the plug.
OK. That was the point that I was trying, and miserably failing, to make. That they should cut resources from all the other, non-core projects, before cutting from Firefox.
> If Mozilla wants to lower their engineering costs, wouldn't it make sense to start cutting back on projects like Rust?
Do you really think that the people working on Rust would just drop it and work on something else instead? More like leave Mozilla and work on what they like while getting paid by someone else. Not all people are easily allocable resources that you can move from project to project based on corporate political goals. Some things take combination of deep technical insight and passion, none of the two optional.
Better for them to keep a few of these high value people on pay so at least they can try and nudge them in directions that help Mozilla more.
I wonder how many "second-systems" in the history of SW development were devised to "reduce engineering costs in the long-term", and then went on to sink hundreds of SWE-years, including new programming languages and tools.
I routinely have to open large spec sheets for work. Have you ever tried to open any large documents with PDF.js? Chrome's pdf plugin can handle 100+ page documents with ease, while Firefox's PDF.js can make the entire browser unresponsive. Hopefully e10s will finally fix this.
Agreed. PDF.js and multi-process both have room for improvement, but the security benefit is huge.
Ideally, NPAPI and Pepper should both die, but I don't necessarily mind them killing NPAPI and adding this minimal set of Pepper support for Flash. Pepper crashes the browser less (though most of the fault lies with Flash).
But even if this enables PDFium, it should not be adopted, and the talk of adopting it makes me want to oppose the whole idea of "project mortar."
I managed to get this working as a WebExtension in Firefox (mostly just hacking around a few APIs that aren't ready in Firefox yet). Could be a path forward for folks that want to keep using pdf.js perhaps.
Google Groups is such a lousy product these days. It uses stupid shebang-URLs, it requires you to sign in to view anything... but in signing in it forgets which URL you were trying to visit and dumps you back on the homepage.
It's a pretty good case study in why rebuilding your product entirely in JavaScript isn't necessarily a good idea.
Erk. In my experience, even ignoring issues of JavaScript vs unsafe languages, PDF.js provides a much better experience. I'd like to see Google switch to PDF.js, not vice versa.
Which would be a very good thing, for we might witness the raise of a fresh new Mozilla and a new Firefox kicking ass, instead of watching year after year the decay of the current ones.
You give the world too much credit. If firefox jumped to blink, we'd just shrug our shoulders. A few of the hardcore would move to IceWeasel or PaleMoon, but the majority of people, even developers, might shake their heads a bit, but wouldn't really care all that much.
There was an alpha product based on Servo in June this year. Servo is nowhere near being done enough to be an actual product (the alpha was a tech demo).
Some Servo components are close enough to being "done" that we're considering sharing them with gecko.
Given Mozilla's recent banging on about "core products" and "cost cutting", I'm a bit amazed that a PDF renderer isn't considered out of scope. It seems like another tacked-on feature (with necessarily inclusive bugs, security holes, etc) to the browser that is better handled by external applications that everyone already has.
That's a good question; I'm in the 'external' camp. But other browsers such as Edge and Chrome have built-in support, so there's a percentage of Mozilla management and user base that would regard a browser as feature incomplete if it didn't have it.
At least, once the scaffolding is done, they can hand off development to the Chrome team and thence focus on the core browser issues of implementing HTML 5.x
I wish more of the world considered PDF and Flash to be obsolete/deprecated technologies. The amount of energy wasted on these rotten old techs is such a shame.
That said, if someone has to do it, I felt better about PDF.js than I feel about the Chrome implementation, for a few reasons. Higher level language means less surface area for vulnerabilities (though I guess it's never been perfect, either). Being a huge and complex project in JavaScript means it works the JS engine and renderer in the browser pretty hard and can provide a great test suite for the browser itself. Being JavaScript also means improvements in the VM (whether performance or security) automatically improve the PDF renderer (though I guess PDFium is quite a bit faster already, so that's less of a benefit on the PDF.js side).
Honestly, though, these are dead technologies, to me. I use them only when absolutely necessary. I don't have Flash installed on any of my machines and have no intention to do so. I do have to look at PDFs now and then, but I don't like it. I'm tired of people slapping the paper skeuomorph onto web pages. Web pages are better than paper, in every dimension, so stop imitating paper! Having to load up a buggy, quirky, weird-looking, plugin to view the damned thing is just adding insult to injury.
So...let'em die. But, I guess if Mozilla feels like they need to keep providing it for now, I'm fine with them doing whatever they have to do to make it cost as little as possible. Mozilla has wasted enough money over the years on weird projects; I guess supporting Flash and PDF count as another one. (Even though I like PDF.js a lot, for making PDF less of an asshole.)
Honest question, if PDF is obsolete, what technology/format was it made obsolete by that is not dependent on the cloud like Google Docs? What lightweight format is there that I can export my .doc's to that I can send to my clients?
We're speaking completely different languages here, I'm afraid. I don't "send .docs to my clients". I haven't opened Word in a decade or more. I occasionally share a Google Doc with people I'm working with, but only for the collaboration features, not because I want them to see what a nice font I selected for the headers.
I recently removed PDF export of invoices from my company shopping cart, and converted it to use an HTML document instead; I spent a couple of days of my labor removing PDF functionality. Same style sheet, looks the same when printed, provides the same information, but no external tools needed. PDF is an anti-pattern, and if I'm working with someone and they send me a PDF I instantly like them less (except in the very rare circumstance that it's necessary to print the thing, like signing documents, though even that can be mostly automated away with tech).
So, I'll answer your question with my own: What are you sending your clients in PDF? Why? Why isn't it online yet? Why are you manually creating these docs, whatever they are, and emailing them to someone? I switched payment providers because my last one mailed me a PDF form, and asked me to sign and send it back. I said "no thanks", and signed up with someone who lives in this century.
There's very little that people do with PDF that can't be done better some other way.
> What are you sending your clients in PDF? Why? Why isn't it online yet?
What do you mean by "online"? Obviously PDFs can be online. Are you implying some clunky proprietary webapp that must allow me to share something?
Let's say some project is going to post a schematic and I'd like to read it. I'd much rather grab that in a PDF than the native format of whatever CAD program they used to capture it (although obviously the latter is necessary for editing). You're either saying that CAD programs should print-to-file as vector-perfect HTML (why?), or that local programs should be deprecated?
To me, PDF is just a nicer page-precise layout compared to PS. And for many locally-saved documents, I'd rather not even involve my web browser - just a simple evince <file>.
Is the PDF support on nonfree platforms really that bad that it's created such hate for the whole format? It sounds like that failing is better attributed to the operating system itself.
"Obviously PDFs can be online. Are you implying some clunky proprietary webapp that must allow me to share something?"
No, I'm suggesting that the web is an open standard, available to more people than any computing platform in history, that can do everything PDF can do, and incomparably more. If there are workflows that rely on PDF, the workflow is probably wrong, and could be improved by a web standards based implementation.
Passing around files is the least common denominator, the stop-gap solution until something good comes along, it's not the optimal solution where we decide, "OK, that's perfect! Let's keep doing it this way for 20 years."
"You're either saying that CAD programs should print-to-file as vector-perfect HTML (why?), or that local programs should be deprecated?"
I'm saying neither. That's why we have SVG. All browsers render it. It is a powerful and pretty well-designed and well-defined vector-based image format that has universal availability across nearly any device. PDF may be powerful but it is not particularly well-designed or particularly well-defined (as evidenced by the lack of good non-Adobe implementations, and as evidenced by how many elements of the PDF format have had to be riddled out by experimentation, rather than merely following a spec).
"Is the PDF support on nonfree platforms really that bad that it's created such hate for the whole format? It sounds like that failing is better attributed to the operating system itself."
I don't know what you're asking here. I primarily use Linux and have for 20+ years. PDF support on free platforms is historically worse than on Mac or Windows, though it's kinda clunky on every OS.
PDF served its purpose, and was good for its time and place (I recall with great excitement when OpenOffice first got PDF export that worked, and it was the feature that convinced a number of people I knew at the time to switch from MS Office, which didn't yet have PDF export without additional software). It's just done, now, and it's a good time to move on.
Your comments look a lot more like someone on a personal vendetta against PDF, for whatever reason, than an argument grounded in reality. There are people whose usecases are entirely different from yours, who do not want PDF to die because it is immensely useful.
I work in printing and graphic design, and PDF is irreplacable. It's literally the only dependable vector graphics interchange format that exists. Would you have us going back to passing around zip files of PageMaker documents?
SVG is a laughable train wreck for any use where it's imperative that files look the same across devices, media and apps. I've yet to encounter a non-trivial SVG file that renders exactly the same across, say, Chrome/FF/IE or Illustrator/CorelDRAW/Inkscape. I don't know whether the format is trash or all implementations are, but the end user experience is awful either way.
Now, none of this means it's a good idea to throw random PDF files at the web when HTML would have worked as well or better. If your argument would have stopped at that I would have agreed with you.
That's all fine. I don't care about that environment or use case; it's not harming anyone. I'm talking about PDF being considered an important part of web browsers. That's what I think should end.
I was unaware of the issues you bring up about SVG; it's not a problem I've seen in a while (though I remember it being an issue many years ago going back and forth between Inkscape and Illustrator, and of course browsers had awful SVG support for a long while). But, professionals in specialist industries can use whatever tools they like, without making the rest of the world carry around that baggage. So, carry on using PDF for this purpose, just don't ask every browser to support it. It shouldn't be a part of the web anymore, even if PDF still has a place in pre-press, or something.
I too had plenty of problems using Free PDF viewers a decade ago. But these days, I can't recall the last time I saw something that rendered wrong.
To me, on Debian, it's a format that "just works". Even nicer than HTML which either wants to commandeer an already-running heavyweight browser and possibly load arbitrary unknown baggage from the Internet, or be half-viewed with lynx.
You seem to be primary arguing for replacing it with SVG, which probably has merit. But honestly I'm just not invested enough in choosing the "perfect" format to weigh one versus the other. You're effectively saying the two have similar functionality but for a lack of a format PDF spec, but as PDF currently functions that argument is quite abstract.
Furthermore, why doesn't Firefox's "Print to file" have SVG as an output option? It's kind of hard to adopt a different format when software that's supposedly directly geared for it doesn't have the option to use it.
> Passing around files is the least common denominator, the stop-gap solution until something good comes along
Erm sure. But that "something good" certainly isn't centralized web silos and nouveau proprietary software marketed as "open web". So we'll continue with files until some feasible user-centric replacement technology is on the horizon.
If somebody sends a pdf invoice then i can save the invoice. An html invoice on the web needs to be printed to paper or pdf in order to be part of a financial administration.
If it stays on a webserver, the document likely dissappears.
My ebook reader (a Kindle) uses an HTML-based format. No ebook reader I know of uses PDF.
My favorite websites to read are not PDF. "Fidelity" is not important to me...being easy to read on the device I'm reading it on is what is important to me. In fact, I find it painful to read a PDF on my computer, whereas I read tons of documentation on web pages without trouble.
Finally, a web page today can look like pretty much anything, including a "book" layout. PDF isn't necessary or useful. Fonts can be embedded, styling can be done down to the pixel level, scalable illustrations can be embedded in SVG, etc. The only reason people don't lay out stuff on the web like a PDF is because it's not as functional as treating it like a web page.
I have genuinely never experienced this, even on a Kindle. The books I read have pleasant layouts, which I feel is only because the designer works on a fixed page.
That said, I have been reading material from http://www.accountingcoach.com and the author has got good design on pretty much all browsers I've used, including my iPhone so I suppose it can be done.
PDF is the preferred format for reading textbooks and journal articles on e-readers. With a large-size e-reader it works well. The only real competitor to PDF is DjVu.
It is not the default format, and if you'd ever tried to read a PDF formatted for big screens on a Kindle, you'd know that it's a horrible experience. The default format for Kindle is mobi, and many others used epub. My point was that though I read books exclusively in digital form, I never read them in PDF format. I don't miss the "fidelity" of PDF; I want the book to be comfortably readable on the device I'm reading it on, and PDF is never the best choice for that.
The Kindle does have PDF support and has for many years. However, people rarely use PDF support on small-screen devices, and nearly all Kindles are small-screen.
a) wants to keep flash alive longer.
b) wants to replace their javascript (aka already memsafe) PDF renderer with a C++ one.
I mean I get that pdf.js is not perfect. It had some bad security vulns in the past. But pdfium also has a pretty bad wrap when it comes to vulns (I got plenty of bounties for it myself). But more than that: It's moving from a memsafe language back to C++. That doesn't seem to make any sense at all. If anything they should move their PDF renderer to Rust.
And Flash... please just let it die in peace and don't put any more effort into supporting it.