Firefox 52 released
mozilla.org
mozilla.org
https://developers.google.com/web/updates/2017/01/css-grid is a simple introduction to it.
http://gridbyexample.com/ is probably the best reference site.
https://tympanus.net/codrops/css_reference/grid/ is another very nice single-page reference.
Some technical examples from Igalia, who have been implementing Grid in Blink and Webkit: http://igalia.github.io/css-grid-layout/
Some lovely creative examples from Mozilla's Jen Simmons:
Well done, new feature coming along with Devtools for it.
I recently had to deal with WebRTC on a headless machine and managed to hack up something with some Python scripting and GStreamer. I didn't know it was possible to run Firefox headlessly and now you got me wondering whether that would have been preferable to my stitched up solution.
Instead of having a real screen, Xvfb uses an in-memory framebuffer for screen output that you can screenshot etc if needed.
It's as easy as:
Xvfb :123 &
DISPLAY=:123 firefox
### firefox is now running and outputting
### to the framebuffer display on :123, and
### can be driven by WebDriver etc. xvfb-run --auto-servernum --server-args="-screen 0, 1024x868x24" firefoxXvfb looks to be pretty straightforward about what it does; now I just need to figure out how to control firefox after it was started.
1. It use javascript to script so writting sequential code wasn't possible so the code ended up using continuation passing style.
2. The very first example snippet on the front page don't work in the repl (https://github.com/ariya/phantomjs/issues/11180). So the repl is useless.
3. When an error occur in your script (not the one on the webpage) there is no message anywhere no matter what you do.
My mistake was to continue with phantomjs the hype around made me think others options would have been worst.
I have used selenium+firefox+php to do a quick test it was wayyyy better, just for n°1 using sequential php remove a lot headaches.
Near the top of a google search for 'phantomjs vs selenium', we have folks on HN complaining about phantomjs https://news.ycombinator.com/item?id=8418071
Using ghostery to block ads and tracking is shooting oneself and everybody else in the foot (feet?).
There are some addons which try to emulate text reflow on tap, but it's pain to use at best.
Reader mode is a workaround, text reflow is the solution. It a reason to use Opera on Android. I wonder if it's so hard to implement that nobody else coded it.
We can only blame Apple for that though, and not Mozilla for a lack of trying.
I was extremely surprised and disappointed (to say the least) when I moved to iOS and found this missing.
That's a bit harsh.
> It's a non-Firefox browser just set up to sync FF settings and bookmarks and kinda look like Firefox.
It's a WebView-wrapper like all other iOS "browsers" because that's everything Apple will allow. To be fair though, synced data, history, passwords and settings is probably one of the most important things for a mobile user, where entering things manually is a pain in the ass.
Basically NOT having this would risk losing users on the desktop (to something which does sync). And right now, Firefox can't afford to do that.
I've been watching this from the sidelines... what's the best way to dive into WebAssembly? Or is it just waiting for tooling to catchup to produce it for WebAssembly-enabled browsers to execute?
Lin Clark's Cartoon Intro to WebAssembly is also great: https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webasse...
Rasumus Andersson's WASM Intro dives deeper into the binary format and wasm semantics: https://rsms.me/wasm-intro
Lastly, the WASM Community Group's page at http://webassembly.org is quite good.
The tooling story is currently the same as it was for asm.js: Use the Emscripten fork of LLVM. Upstream support is being worked on in LLVM, and Rust has a cross-compiler in the works.
If you haven't used this, try it out, it's a fantastic feature. I use it all the time to send a page I'm reading on my phone to my laptop, and vice versa.
I seem to remember I used to be able to send an open tab on my Android phone to my desktop Firefox, but that option later disappeared with some update.
Edit: It sounds a lot like the "send to device" add-on mentioned in another comment. Was this bundled with Firefox for Android at some point?
EDIT asking because it's been this way for a long time, see https://wiki.mozilla.org/Services/PushTabToDevice#Desktop_Im... which says "Currently, push-tab-to-device on desktop must be used through an addon: [send-tab-to-device]"
Frankly it seems like the Firefox devs could just hand the Linux branch off to the Gnome devs at this point.
I'd guess that this would impact relatively few people if they're willing to require it.
I personally think it's a bad move to drop official support for ALSA. Not everyone can or wants to use PulseAudio, for various good and bad reasons. Supporting multiple backends also keeps you "honest," so to speak, preventing you from relying on certain behaviors or features that only some platforms support.
But, I can understand the practical arguments behind dropping support for ALSA. The ALSA API really sucks to work with. There's a fair number of bugs and device quirks and whatnot that you have to take care of as an application developer. Standardizing around PulseAudio means only PulseAudio has to care about those quirks, instead of every single application. In practice, the vast majority of users use PulseAudio; there's a small (but vocal) minority that don't.
So really there's no clear winner on whether to provide support for ALSA.
And of course, there's a large majority of users who couldn't care less, and who will just choose whatever their distribution installs (which is why I think the most Linux users not using PulseAudio are on those distros which don't install any sound stuff by default, e.g. Arch).
I didn't know pulseaudio was a Poettering product, but I know very well that pulseaudio has been a nightmare for me over the years on most setups with a variety of linux boxes and distros. And the fix when an audio problem arise is simply to uninstall pulseaudio and use alsa.
Now that I know pulseaudio is Poettering work, this makes a lot of sense.
Fortunately, OpenSuSE Leap appears to be a PulseAudio distribution.
I suppose mozilla does not care enough about losing these fringe users to actually do something about it.
https://www.browserling.com/firefox/52/news.ycombinator.com
If the demand is too high then you'll have to wait in a queue for a while to try it. I'm adding more servers right now to let more people try it without waiting.
Thanks for the hard work
Yeah sure, because we all know that deleting cookies makes you totally anonymous on the internet. /s
Good bye, you will be missed (not).
I'd like to say they won't be missed, but I've got a state Medicaid portal that uses some annoying Java applet to handle authentication I have no choice but to deal with (I've actually got a little flask web service that uses Selenium and Firefox in Xvfb just to log into the stupid thing and return the authentication cookies, since Chrome ditched NPAPI a while ago and IE isn't a sane option).
I won't be sad when applets finally go away, but that day is not today for me and it's going to really screw things up :/
Even today, Firefox decodes all video (even h264) on CPU.
Which causes, with 4K 60fps video, 50% CPU load on an entire core for me.
Is that a punch line? Because it sounds like one. What is that, like, 6.25% of your total CPU power?
I say this because many people have machines with CPUs that can't decode 4K 60fps video in realtime at all. So your stat sounds like a great deal to me.
Having said that, hardware video decoding is important for this very reason. It's a shame that the situation isn't better on Linux. It seems like, no matter what site or browser--Chrome or Firefox--VLC always plays the same video with far less CPU usage.
Which pushes you beyond what a single core is capable off.
The bugs on bugzilla are all marked "WONTFIX", and Linux seems to be an afterthought.
The mpv plugin worked as well for HTML5 video with hardware acceleration.
Now, well, not anymore.
Another internal tool to rewrite from scratch, yay.
> Acrobat and the like are no longer supported.
Is the build in PDF viewer still burning through battery power like the electric heater it turned my laptop into the last time I used it? Been some time so that would be interesting to know.
> Another internal tool to rewrite from scratch, yay.
If you care about security in the slightest, you should probably already have done that.
> > Acrobat and the like are no longer supported.
> Is the build in PDF viewer still burning through battery power like the electric heater it turned my laptop into the last time I used it? Been some time so that would be interesting to know.
You can still use an external reader of your choosing; for example I'm using the marvellous Okular. You just can't use an NPAPI-based PDF reader plugin.
These plugins have been click-to-play in the major browsers for a long, long time.
Obviously they still provide some attack surface, but the biggest threats today don't come from plugins, they come from the main browser functionality, thanks in no small part to all the things browsers now have to provide so we can still do useful things that we used to do with plugins.
Signed internal only use tool. Not running untrusted applets anywhere. Also no time to rewrite bug free working code.
> You can still use an external reader of your choosing;
So the answer is that it is still that bad? I guess I can just browse the web using wget and less if external tools are the next big thing. /s
> > Another internal tool to rewrite from scratch, yay.
> If you care about security in the slightest, you should probably already have done that.
What has one to do with the other
However, another difficulty with using browser file upload controls was that, for security reasons, programatically (JavaScript) putting a file to upload is forbidden (readonly form attribute) by the respective browser API spec, so in the end the GUI part had to be coded in the Java/applet, too, when the HTML GUI would have been preferable.
So my point is that Java applets in recent years weren't used for GUIs so much as they were used for piercing the browser sandbox, and I don't see a solution for this problem now that applets have gone.
Or, if the application is not strongly coupled to other server-side systems, make it standalone with a Swing, JavaFX or whatever front end.
Now I have to disable dns entries.
Yes, I'm slightly bitter. I'm starting to think the Suckless guys have the right idea...
I know, I know.
Still, it means I'll be missing that silverligh support.
Bradesco's fortunately works on any browser.
I doubt they will give up these "security" plugins, so the answer will most probably be an even more invasive system process. It seems that some banks are migrating to Warsaw, which is known for among other things causing problems with IPv6 (http://ipv6.br/post/bug-em-plugin-de-seguranca-de-bancos-blo...).
Many Chinese ecommerce and government sites require their own "security" NPAPI plugins. These don't work in Chrome, but the large majority of users in China run hybrid browsers that use both Blink and Trident (IE) engines so these sites that require NPAPI plugins can be seamlessly loaded in a Trident tab. The user doesn't know the difference.
Are Java applets and Silverlight apps demonstrably less secure than Flash?
Just as a naive metric, if you look at the CVE database, there have been a total of three CVEs for Silverlight last year; whereas for Flash... well, I stopped counting.
I don't know of any bank or government agency that uses Flash, but I certainly know that the Hong Kong government uses Java on some of its websites.
It feels like Mozilla is keeping Flash around just because it's more popular with browser gamers and video watchers. I don't think that's doing the right thing.
That's exactly right. The amount of Flash content dwarfs the amount of other plugin content.
Banning other NPAPI plugins doesn't avoid the Flash security problems but it does avoid the other security problems. It's a step forward, but it's not the final step.
Personally, I'm hoping we see a WebAssembly build of Flash eventually (once WA is featureful enough to support it), at which point the native plugin can die without breaking (as many) old sites.
drm something something...shall I remind spotify web player still uses flash.
Also Safari still doesn't support it...
Edit: switched "plugins" to "add-ons".
Its really "funny" how it seems i can get Qt5 to work on an "old" X11 install, but GTK3 balks at same.
If the FOSS world really wants a foot in the door on the desktop they really need to learn to properly do backwards compatibility. Yes, it is not a glorious job unlike working on the latest shiny framework or language. But it is what has kept the likes of Microsoft in the top spot all this time.
Frankly i fear that once Torvalds steps down as kernel boss, Linux as a whole will fragment into a million variants with diverging APIs.
Ended up finding that Firefox 52 is overly accepting in validation. Dead code is allowed to pop from an empty stack, whereas in Chrome that's not allowed (as per spec). It's fixed already in next versions of Fx
why??????????????
The more helpful answer, though, is: Because it's fun (at least to some people)!
https://bugzilla.mozilla.org/show_bug.cgi?id=594876
In the release notes for 52, it says hangouts is broken. I wonder if this means all of webrtc is broken or not.
Regressing "stable" features like these is creating serious problems for end users. I wish they'd focus on keeping the ship afloat instead of continuing to chase the new shiny. I really don't like relying on google (or any other ad/surveillance shop) for my web browser.
Hangouts is broken because Hangouts uses NPAPI, not WebRTC
Hangouts will be fixed whenever Google actually ships the WebRTC version of Hangouts
I am signed in and have synced recently.
The one I always used had a Firefox icon.
> Enhanced Sync to allow users to send and open tabs from one device to another.
Although, if you go back to the 51.0 release notes, it does say "Improved reliability of browser data sync".
https://www.mozilla.org/en-US/firefox/android/51.0/releaseno...
Because the share list is sorted alphabetically, a bunch of apps started doing "Add to..." rather than use their own names.
If View Source works properly, that'd be worth upgrading for immediately.
If you can reproduce this problem in a clean profile, please file a bug, cc "bzbarsky", and I'll take a look. Obviously, steps to reproduce would he helpful too.
If it doesn't happen in a clean profile, then we start looking into what's special about your existing profile.
I'm not sure what I've done to make it not work here, but this profile dates from a long time ago so maybe it's just cruft or an extension behaving oddly. I'll switch to using a clean profile. Sorry again and thanks for your attention.
Unless you were talking about some other kind of view source?
Then it only takes up space when someone needs it.
I will say that it would be nice if there was a way for them to recognize when the devtools are open and use that as a signal to keep around the source of the current page. But otherwise it would certainly cause significant memory bloat for each tab open.
It looks like the the original commenter is talking about was first reported 12 years ago[1], so I wouldn't count on it being resolved any time soon. It just doesn't seem to be something that many web browser users actually care about, so I don't blame the FF team for not assigning much priority to changing the current behavior, even though I'd also like View Source to work the way way Joeboy is asking for.
WASM reminds me of the NDK on Android. A way to write high performance GC-less code, but nobody started to use it for other things than high performance computations.
Will people really start to port runtime environments to WASM so they can run Ruby, Python and Java in browsers?
Or will this mainly be a place for C/C++, Rust and co to get some niche high end stuff running?
I also think there will be many web apps which are 50/50 JS/WebAssembly where WebAssembly is used for libraries that need to do fairly heavy computations, but can do that without having to call into browsers APIs too much (e.g. image processing, physics engines, AI, etc...).
Android NDK is heavily used for games, I wouldn't say that 'nobody started using it'.
I'm not seeing the appeal for running languages on top of WebAssembly that need a heavy runtime environment. The big downloads this requires will kill all the fun. Even C++ will create bloated WASM modules if one isn't careful. Using 'embedded style' programming practices really makes sense when trying to reduce module size for asm.js/WebAssembly.
Which is very much the only use case that Google's supports, and Android APIs that are exposed to it, for anything else welcome to JNI.
Utopia? Yeah. I know people will still choose their favorite languages for task x, y and z, but I can still dream.
Even for Android Things they gave up on their plan for C++ Frameworks on Brillo, and adopted the Android Frameworks instead, due to "We incorporated the feedback from Project Brillo to include familiar tools such as Android Studio, the Android Software Development Kit (SDK)".
So to come back to WASM, it depends on how willing the browser vendors are to push it, beyond the initial prototype.
But if you want, you can write libraries which will allow you to write Android Apps in C, C++, C#, Rust or Go (as people have already done, see Qt and Xamarin for example). The thing is that it's much easier to write a simple CRUD app in Java than in C++.
Using C++ on iOS or UWP isn't as painful experience as on Android.
It's likely we'll see other languages targeting WebAssembly in the next few years. I heard rumors Microsoft is working on something in that area. If I were to guess, I'd expect a TypeScript-to-WASM and C#-to-WASM to follow. Java, Rust, Go, and others will likely have something too.
Additionally, I expect to see some JS-heavy frameworks (React, Angular, etc.) write performance-critical sections with WASM, thus benefiting a great number of web apps.
Right now relying solely on WebAssembly where you can use JS is dead in the water (how many websites still keep up IE support).
The question will be in a few years (especially once WebAssembly DOM support comes in).
Even then, there's so much JS in the wild that only a depracative step (JS is no longer supported) will kill it.
It's like Clojure, Kotlin, Groovy and other JVM languages. Even if they are better by a long shot than Java, the legacy factor will keep JS (and Java) alive for a long time (and the fact that JS doesn't require a compiler or environmental).
Similar principles will surely apply. For WASM code to interact with DOM or external scripts / JS libs in any meaningful manner, the wasm generator will have to provide in any event additional JS code anyway.
I'll see about getting the release notes fixed to reflect that.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionet...
Does this mean that the library is being downloaded (and executed) using plain HTTP without any authentication? Sounds like a nice target for QUANTUM style MITM attacks.
Strange errors and broken functionality usually without any mention of my browser being the problem. That's sloppy development. A browser from 2014 isn't "Netscape 3".
Signed up to Google Firebase recently. Tried navigating to the console on my PC with Firefox 33, "there was an error completing your request". That's because I was using a browser from 2014. No mention of that in the error. At first I thought the service was down, then I tried a newer browser.
Backwards compatibility or at least graceful degradation and error handling is accessibility. Your site either has it or it doesn't.
This way users will have to upgrade, and the web can move forward.
One thing is to keep supporting something that costs hundreds of dollars (like an iPhone), but there is very little sense IMHO to spend a lot of effort and—potentially—make everyone's experience worse just because some users won't bother downloading a 50MB free update.
A lot of things happen in 3 years in this field!
Google was smart in making Chrome updates automatic. I doubt the average user cares the slightest anyway.
That is exactly the same justification for "deprecating" America's public transit infrastructure in the 1950s, and replacing it with highways. I don't consider a lot of updates to be upgrades.
And the cost associated with updates isn't 50Mb. The cost is losing essential features that I rely on.
So, you're saying that I should lose the ability to log into my router, all so you can use the latest template bullshit that will be abandoned in a year.
And it's not even that a major feature will be deprecated specifically, it's the threat and uncertainty that the constant update cycle creates.
I deeply miss the good old days, when I could trust that my computer would behave as I expected it to. The fact that things have become so damn unreliable is itself taking away from the UX, and more than offsets any improvements. Google has an awful UX, because of how unreliable it is.
All the financial websites that I use over the last two years have been ruined in the pursuit of UX. Information density has plummeted. I used to be able to copy and paste data on screen in a predictable manor. The browser responded instantly. Now, it's a messy, slow, and far less readable.
I'm thankful that I don't rely on accessible technology.
The direction the web has taken recently is horrible. And I'm convinced that this time will be looked back on with disgust.
I was a web designer from the late 90s to early 2000s. I vividly remember everyone saying how Flash needed to be pushed on users, and how HTML was obsolete. And that unskippable flash intro pages were cutting edge UX. And playing sounds in the background was a great idea. And that all users were 800x600 resolution.
The attitudes have not changed. I think they've actually gotten worse.
Sorry, I don't have time to go into the specifics of all the APIs that modern browsers have started supporting since 2014, but they're a lot.
> That is exactly the same justification for "deprecating" America's public transit infrastructure in the 1950s, and replacing it with highways. I don't consider a lot of updates to be upgrades.
Why are you comparing public transportation with web standards? Web standards evolve about 100 times faster than public transportation.
> So, you're saying that I should lose the ability to log into my router, all so you can use the latest template bullshit that will be abandoned in a year.
I don't see why you'd lose it. More modern browsers will still be able to interpret old code (http://info.cern.ch/)! The problem is the other way around: old browsers can't understand new code. Also, although I take it that you don't like updating your software, if something doesn't work if you updated your router firmware or software you might find out that it starts working again. You can also keep an older browser installed if you need to access some specific software, but I don't think it's a good idea to use an obsolete browser as your main browser, if anything for security concerns.
> he direction the web has taken recently is horrible. And I'm convinced that this time will be looked back on with disgust. I was a web designer from the late 90s to early 2000s. I vividly remember everyone saying how Flash needed to be pushed on users, and how HTML was obsolete. And that unskippable flash intro pages were cutting edge UX. And playing sounds in the background was a great idea. And that all users were 800x600 resolution.
Then, I find it hard to understand how you believe that things have gotten worse, since all browsers follow the standards now, most things are open source and build on open technologies.
> The attitudes have not changed. I think they've actually gotten worse.
Judging by your tone and attitude, I actually agree with you on this one.
So, you're saying that I should lose the ability to log into my router, all so you can use the latest template bullshit that will be abandoned in a year.
Non-broken HTML from the dawn of the web onward works fine in modern browsers. Had your router manufacturer done something sensible in the first place, we wouldn't be having this discussion.
And it's not even that a major feature will be deprecated specifically, it's the threat and uncertainty that the constant update cycle creates. [...] The direction the web has taken recently is horrible.
But, this is due to bad site design, not the fact that browsers are more capable now. You could argue that today's more-capable browsers enable and encourage this crap, which is kind of true. But in the old days site owners did the same horrible crap; they just used Flash and Java and ActiveX to do it.
And I'm convinced that this time will be looked back on with disgust.
I vividly remember everyone saying how Flash needed to be pushed on users, and how HTML was obsolete. And that unskippable flash intro pages were cutting edge UX. And playing sounds in the background was a great idea. And that all users were 800x600 resolution.
But, I don't see what harmful assumptions and proprietary closed technology have to do with one of the jewels of the open-source software world (Firefox) continuing to improve itself while remaining open.
Fear not, my friend. If we accept the premise that everyone should be forced to switch software every few weeks to retain access to useful content, even if doing so means losing access to other content in the process, then much of this time won't be looked back on at all.
So don't update your browser. Or at the very least, use an ESR.
> So, you're saying that I should lose the ability to log into my router
You're using the wrong tool to connect to your router. The web has always been in flux. If your router only supports web login and requires mildly fancy web code which might get deprecated, that's a problem with it, not the browser.
Similarly, it's not the browser's fault that google has bad UX, and you can make sparse-looking pages with ye olde html as well.
My browsing experience has been made significantly worse than it was 5 years ago by websites abusing new browser features. I have had to start running uMatrix to disable JavaScript except on whitelisted websites, and have had to start using youtube-dl to download videos instead of viewing them in the browser. Firefox Reader View is a must because of bad CSS everywhere. I use Firefox for most browsing but keep Chrome around just to view problem websites.
Most websites serve up text, the only reason they "need" new features is for serving intrusive ads. I also regularly use Lynx and think it continues to be a good browsing experience. Most websites can be (and historically are/have been) very usable and quick to navigate in text browsers. I continue to design personal webpages to work in text browsers.
The fact that web technologies have become powerful enough to make using complicated software a click away instead of forcing you to install a native app for every little thing..?
With as many ways as you can have your machine compromised by simply browsing to a website that had some malicious advertising code embedded, I can't imagine why anybody would use such an old browser if they weren't absolutely forced to.
I work with a visually impaired PhD student, and we had to turn off browser updates because of the hell it was causing him (eg why are my search results different all of a sudden? why are pdfs opening differently?).
This isn't limited to firefox, google voice recently got a UI update that lowered the information density. Where he used to be able to see who he was talking to now there is a big colored shape surrounded by whitespace, etc. If he didn't limit the updates, probably 25-50% of his time would be spent dealing with interface changes.
It's also more secure, because of my external sandboxing.
I also have my own container mechanism for Firefox that I have been using for years.
And this is what the web is all about. It used to be that the web was accessible to people in remote parts of the world, using old hardware, and anyone could write and add to it.
Now it's quickly becoming a black box that only wealthy people can access.
The performance gains that come with newer browsers (generally) should allow websites to run on older hardware. Not to mention support for new protocols and compression that lead to smaller assets being sent to all devices.
Oh right, Google and the cabal that runs the web decided so.
Just because something is "old" doesn't mean it is obsolete. This mentality is very wrong, and needs to be opposed. It isn't helping the users, it is helping the platforms.
Up until a few years ago, it was the responsibility of the developer to gracefully fall back and support as many users as possible. Now, instead, we design under the assumption that everyone has a computer made within the last 12-18 months, with the latest updates, on a high speed, low latency connection.
And that is awful, because it is cutting out users who aren't privileged enough to afford the web.
The new "improved" Google Voice is utter trash. It makes my 2011 Macbook grind to a halt. And for what? So that it cosmetically resembles their new phone app. And most tech reporting websites are gushing about how it looks.
And what is the justification for all of this garbage? Is the web faster? more reliable? More accessible to people with disabilities? NO.
And I don't particularly respect updates sold as "security" when they often move the furniture around, or remove features, or flog whatever new feature they think we want in our browsers.
Web browsers should be more stable, not frantically updating themselves every 5 minutes. Browsers are windows to online content - the online content is what changes and updates all the time. The browser, as viewer of those changing and varied websites, should be relatively static and stable.
Firefox 33 is a three year old point release intended for eight weeks of operation, so things being broken shouldn't be a surprise. So sites have the choice of feature-sniffing and keeping an updated list of all the rendering bugs in all browsers going back ... what, a decade?; or kicking out people using old non-ESR browsers. They could be more gentle about it, but the choice is fairly obvious.
If sites use bleeding edge features with no programmed fallback or error handling apart from "miserable failure", they have a responsibility to at least inform users of their limited browser support rather than pretending to be a website on the internet - which by its nature should be accessible to an official release browser from 2014 without failing miserably.
[0] https://addons.mozilla.org/en-US/firefox/addon/classicthemer...
Staring at a blank wall, for example.
That's really, really bad. At this point Firefox was the only browser which was supporting Java on Linux. I am forced to stick to the 51 version (52 64bit ESR does not support Java also).
You may ask, why on earth do you need Java inside your browser in 2017? My company, which does not support Linux, uses Java applet to create system-wide VPN connections to the client's networks and Firefox was the only choice.
This is what the realities of the situation are:
Touchscreen Windows users running 32-bit Firefox 52 should have multiprocess.
Touchscreen Windows users running 64-bit Firefox will not have multiprocess until version 54.
My main gripe is that it doesn't treat closing the window as "exit", which means you must go to menu and select Exit if you want to remove session cookies and similar.
Another one is that selecting text is clumsy because standard Android lens is not used.
But I still prefer FF to its "all-your-data-are-belong-to-us" competition.
EDIT: looks like it's available, installing... Thanks!
Not that I'm ungrateful; Firefox is my preferred browser.
I moved from chrome to firefox and so far this is my one complaint. This and I believe the CPU usage is higher for the same number of tabs open.
I've just skimmed through this guide: https://docs.services.mozilla.com/howtos/run-sync-1.5.html#h...
It doesn't look too difficult and it says that running your own account server is optional. Or does it mean that you can run your own sync server using a mozilla account? I'm not sure I understand how sync server and accounts server interact exactly...
What's the reason that they should accommodate you and write you a dockerfile?
Regardless, I'll likely be switching to FF 52 ESR so the point will be moot.
I do not see the release via the Play store app, but the web site shows it.
For a project that seems to bill itself as being for the people, they seems awful quick at dropping backwards compatibility.
I am for example quite reliant on .vimperatorrc for custom commands and set! about:config preferences.
On the other hand, some parts of VimFX's language are more logical, e.g. "yf" instead of ";y" to select a link into the clipboard.
https://gsuiteupdates.googleblog.com/2017/02/google-hangouts...
Ironically, Mozilla has stated that breaking all these user plugins is part of some strategy to regain market share and "influence web standards". Now that it's actually happening, I'm hoping more people will see how it's not going to work.
I never thought I would see a defense of NPAPI, of all things, on HN. NPAPI is a gaping security problem, and the only fix is to remove it entirely.
What is your proposal for making NPAPI secure?
https://plus.google.com/103171586947853434456/posts/39TCW3Pc...
(b) If the one of the largest software companies out there, which is apparently acting in good faith here (since they intend to release a new plugin), can't keep up, then in what universe do all the rest?
All that being said, who knows what it going on with the new Google Voice. While seemingly improving the UI, they made it very difficult to place outgoing calls to people one has not received calls from already. So maybe Google is getting ready to kill Voice off.
b. If they're acting in good faith why did they misrepresent when Mozilla announced they would be deprecating the NPAPI plugin API[1]? It seems more likely that they were simply lazy and instead of making the solution they used for Chrome (which already removed NPAPI support, mind you) work across the board, they waited until the last moment and realized Mozilla was actually going to go through with making the same changes they did.
[1] https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plu... which is a full year before Google mentioned Mozilla made the announcement ( https://www.fxsitecompat.com/en-CA/docs/2016/plug-in-support... )
https://plus.google.com/103171586947853434456/posts/39TCW3Pc...
All I can say is that while I didn't take a lot of time to parse this, most of the people impacted by this issue will take even less. They will just understand that Firefox worked with Google Voice and then stopped.
So it does seem to me like part of an overall theme. Firefox used to let users decide what was safe, now it's decided for us.