Slashdot Mirror


Firefox 49 Postponed One Week Due To Unexpected Bugs (softpedia.com)

An anonymous Slashdot reader quotes Softpedia: Mozilla has announced this week that it is delaying the release of Firefox 49 for one week to address two unexpected bugs. Firefox 49, which was set for release on Tuesday, September 13, will now launch the following Tuesday, on September 20... Firefox 49 is an important release in Mozilla's grand scheme of things when it comes to Firefox. This is the version when Mozilla will finish multi-process support rollout (a.k.a. e10s, or Electrolysis), and the version when Firefox launches the new WebExtensions API that replaces the old Add-ons API, making Firefox compatible with Chromium extensions.
Firefox's release manager explained the delays as "two blocking issues and the need for a bit more time to evaluate the results of their fixes/backouts" -- one of which apparently involves opening Giphy GIFS on Twitter.

3 of 208 comments (clear)

  1. Re:Ah.. another week.... by jandersen · · Score: 4, Interesting

    Another week until I do not use this slow browser....

    Glad they keep going for diversity sake- but it's a sluggish pile of code. Beloved though it is.

    Browser speed has always struck me as slightly irrelevant, when in the majority of cases it is the fault of the websites, when things are slow. Although there is one case where it is definitely something about Firefox: Try to load http://www.dr.dk/nyheder/ (Denmark's Radio - "the Danish BBC" if you are kind) - it loads fast enough, but the whole browser freezes for ~10 sec when you scroll down; loading the same page in Konqueror (yes, there are some that use it) displays none of these problems. I have no idea why.

    But the real problems, for me at least, are: 1) The tendency in Firefox to switch to https when you activate Javascript, and then being unable to load the page, and 2) The increasing number of unwanted features, like embedded search engines that cannot be disabled and similar. I hate it when I mistype an address and get an idiotic search result from Google, Yahoo or whatever; all I want is an error message.

  2. Re:Ah.. another week.... by Anonymous Coward · · Score: 5, Interesting

    Depends on what you mean by browser speed. Firefox slows down massively when you use a ton of tabs. There must be some 2^N algorithms under the hood as that's the only conclusion I can come up with to explain the massive UI jitters. Closing many of those tabs does speed the browser up again, but it never releases a corresponding amount memory. If you're a heavy tab user and like to keep Firefox open, you eventually run out of memory or are forced to restart it due to the frustration of 15-25 second UI freezes when you open a page in a new tab. Oddly enough Firefox tends to crash a lot on closing when you're near max memory limits, so you can keep using a slow browser or close and crash. Then you reopen a profile with a thousand or more suspended tabs and it can take over 10 minutes until the UI responds to anything. Think about that. While very few people use that many tabs, there's no reason it should take 10 minutes. These are suspended tabs. Firefox is database focused, so all the browsers needs to do is load a 1000 list of tab ids, 1000 looks ups for the tab names, and 1000 look ups for tab icons yet it spends over 10 minutes doing that ( meaning 5 operations a second). Something is just not right with its performance, though I doubt the other browsers can handle that may tabs at all. Despite how advanced browsers are, they're also horribly designed pieces of software.

    Hopefully their multi-process support will help, but considering there's something fundamentally wrong with how they manage tabs I doubt they're going to handle this properly too.

  3. Re: a win for open source by blackest_k · · Score: 4, Interesting

    Ok I can only comment on systemd has caused problems for me. I have a nas running debian. Because a USB drive wasn't able to be mounted it stopped booting and dropped to an emergency shell. The device was able to be pinged but ssh wasn't running as this is headless with no access other than via ssh I was screwed, I was able to open the drive on another machine but there was no log information to say why it hadn't completed the boot.

    Obviously being an Arm build I couldn't boot the drive on an x86 system.

    The only thing that got me sorted was in a debian page about openssh in jessie, some kind soul had written that systemd now would drop to an emergency shell if it found something it couldn't mount in fstab.

    So I got lucky and was able to fix the problem but no thanks to systemd it was just a data drive not essential to the booting of the os.

    Lets say you have a server in a rack somewhere and a hdd dies in the raid rebooting that server remotely would end up in exactly the same situation. So systemd is a success but only when things don;t go wrong.

    So what are you supposed to do remove drives that are not essential for your server to start from fstab and manually mount them once the server has booted maybe not init any services that will be using those drives either....

    wouldn't it be better if systemd was able to init what it can and finish booting and issue a cry for help once the system was up and running?

    If you were running a windows server sure sometimes not all services get started, There is one domain controller which quite often fails to start the mail server. This results in no email for the domain and a remote login to restart the service. not a shutdown of the lan ...

    Systemd has potential but I'm not buying it as being ready for deployment when it can wreck your morning if not your entire day because of it;s behavior when there is a problem.

    .