Announcement

Collapse
No announcement yet.

Changes To Look Forward To With Firefox 52

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by debianxfce View Post
    Google Hangouts does not work.
    Regarding Hangouts, apparently Google is porting it to work with webRTC for calls. See the link below.

    Comment


    • #42
      I'm sincere Linux needs an its own browser based on Qtwebengine wayland Mesa completely able to take advantage of hardware acceleration. A PLETORA of distros and desktop environments vs 0 official linux browser is very ABSURD.
      Last edited by Azrael5; 03 February 2017, 03:20 PM.

      Comment


      • #43
        Originally posted by Azrael5 View Post
        I'm sincere Linux needs an its own browser based on Qtwebengine wayland Mesa completely able to take advantage of hardware acceleration. A PLETORA of distros and desktop environments vs 0 official linux browser is very ABSURD.
        Nowadays is completely unproductive, not helpful to have a browser tied to an unique OS, only walled gardens try to do this

        Comment


        • #44
          Some of the feature additions to Firefox 52 include the ability to send/open a tab from one device to another with Firefox Sync
          Hmmm, I only started using that feature recently, but with version 51 that is already possible.

          Comment


          • #45
            Originally posted by LinAGKar View Post

            That's not multi-threading, that's multi-process, where the content is run in a separate process from the chrome. It has nothing to do with multi-threaded JS.
            Originally posted by adler187 View Post

            Electrolysis is for multi-process support, not multi-threading. Firefox already make use of multiple threads:

            Code:
            $ grep Threads: /proc/$(pidof /usr/lib/firefox/firefox)/status
            Threads: 72
            (on Firefox 51)
            You're both right of course. I can't believe after all these years I still use those interchangeably. When I know too well they're not.
            To add insult to injury, I've actually checked htop before posting and it was clearly showing me both threads (many) and processes (a couple)

            Comment


            • #46
              Originally posted by Azrael5 View Post
              I'm sincere Linux needs an its own browser based on Qtwebengine wayland Mesa completely able to take advantage of hardware acceleration. A PLETORA of distros and desktop environments vs 0 official linux browser is very ABSURD.
              Quipzilla is QT browser i think , Epiphany is a GTK based Browser in linux . Wayland support in KDE is utter Crap atm, dunno what it'll be like in 5.9.0 . Firefox will never play nicely in a Wayland environment maybe untill it switches to Servo permanently

              Comment


              • #47
                Originally posted by uid313 View Post
                - No support for HTML5 input types datetime, datetime-local, date, time, month, week.
                You mention this EVERY. SINGLE. TIME. Do you think mentioning it here will result in the feature being implemented faster? Is it simply aggravation?
                It's really only a big deal if it's essential for your sites to have these pickers using native widgets (or js is disabled, or you don't want to include libraries), then no solution is particularly nice, but going with something like polymer is a completely legitimate alternative.
                ​​​​​​

                https://bugzilla.mozilla.org/show_bug.cgi?id=888320 metabug for input type https://bugzilla.mozilla.org/show_bug.cgi?id=1283381 metabug for ui

                Comment


                • #48
                  Originally posted by bug77 View Post



                  You're both right of course. I can't believe after all these years I still use those interchangeably. When I know too well they're not.
                  To add insult to injury, I've actually checked htop before posting and it was clearly showing me both threads (many) and processes (a couple)
                  Heh, yeah, i totally get this. The problem, imho, is that people say app_name_x, and the thought is, "oh, that's a cute little process". Obviously such thoughts are a massive simplification of reality, but i do think the cause is: 1) audience isn't versed in how software works and 2) app names tend to be in the singular, which suggests something monolithic.
                  FF, as you've noted, has been both threaded and multiprocess for years, but the language in this area is such that it assumes a decent amount of familiarity with, not only software, but the particulars of a browser.

                  Comment


                  • #49
                    Originally posted by gbcox View Post
                    CNET dedicated a whole article to the layoffs where they blared "Firefox Fail". If it were a fail, it's because they didn't do it sooner. It's the right move for them. They need to concentrate their limited resources on core technologies - making them best in class. They finally realized that. A strong/competitive Firefox is good for everyone. I just switched back to using FF from Chrome. It's going to be a bit bumpy while they get webextensions working - but I'm pleased with the overall experience. As far as the RAM, etc. there have been countless articles that all agree that FF uses less RAM - but for most people it doesn't really make that big of difference. All the major browsers these days are perfectly capable of providing a good user experience. What matters though is making sure there are choices and commitment to user privacy and security. Mozilla keeps those issue in the forefront.
                    Firefox os wasn't really a move away from their core, imho. If it did nothing else, it forced someone to look really hard at the idea of browser-as-a-platform and see what it was missing. Part of the issue was the lack of standard low level apis. That is continually being addressed. The other part is performance. With this you butt up against an intrinsic issue with the web (well, html/js) that has to be either worked around or fixed in order to get native-like responsiveness. Servo (the layout engine) will go some ways as a workaround, and had it been working, fxos would've been much nicer, and, imho, it will provide enough of a realisable performance difference that the responsiveness issue will be all but gone.
                    When that out of the way, i agree that having Mozilla focus on improving their product is a good thing (though, keep in mind that they still have an eye on IoT). Clearly ff hasn't been the best browser for a very long time.... almost a decade? Has it been 10 years since the iPhone, and eight since chrome? Ugh, well, regardless, Mozilla scraping some of the stuff that was diverting their engineers from making changes to the core product has already been advantageous for the desktop.
                    Lastly, we need to keep in mind were ff sure relative to their competitors. The web is no longer a place that make software companies can simply ignore. This means that the giants, like ms, apple and google can't afford to short their web offerings. All what being equal, that implies they can simply outspend Mozilla. Unfortunately, this is pretty much the current situation. Even with a stripped down Mozilla org, they don't have the resources to keep up, let alone pull ahead, with these other companies. So, with that in mind, you can see why they've made attempts to acquire alternate revenue streams, and with that failing, trying desperately to find a niche whereby Mozilla can become a sustainable endeavor.

                    Comment


                    • #50
                      Originally posted by gurqn View Post
                      crap!!, many corporate apps still require npapi java :/ I wonder how this will end up. Glad that I'm on MacOS with Safari and I'm safe at least until next version of OS
                      Corporate apps just have to deal with it, and invest the money to ditch that requirement. Because it's not just Firefox dropping plugin support - Chrome doesn't support Java, Edge doesn't support Java... Oracle is deprecating the plugin in Java 9, and presumably dropping it in 10.

                      Basically, anyone still using Java applets has until IE11 reaches end-of-life. That's going to be the last browser that still supports them, and it's already an obsolete platform that's being displaced by Edge.

                      Comment

                      Working...
                      X