It was stated that Apple is including the fix with the next update of Sierra, which is currently in testing.
So, "soon". Meanwhile, don't turn off Safari's cache.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Consumer Reports Retesting MacBook Pro Battery Life After Apple Says Safari Bug to Blame
- Thread starter MacRumors
- Start date
- Sort by reaction score
So, "soon". Meanwhile, don't turn off Safari's cache.
The drama... USBc is a standard, not proprietary, thus...
http://www.computerworld.com/articl...dapter-for-new-macbook-and-other-devices.html
As much as I'd like to "blame" CR, it comes down to practicality.
They "visit" a fixed-set of five webpages that they host "locally", on a closed-network, from their own test server. They do this specifically to factor-out stuff like competing network traffic and WiFi traffic affecting the test. So far, so good.
But the results would be overly-optimistic with the browser-cache enabled, as far as battery life is concerned; because the pages would simply be re-rendered pretty much completely from cache. That is NOT "real-world", unless you too only ever visit 5 web pages.
So, they turn OFF the browser cache, forcing a "reload" of the Pages each and every time. This is more like browsing to DIFFERENT websites, which is not only more "real-world"; but also a more consistent and rigorous test.
UNfortunately, when they did this with Safari, it uncovered an unknown and intermittent bug in Safari that caused the CONTINUOUS reloading of certain assets from the Page, instead of simply loading the page and then rendering. And THAT is what drained the battery so quickly.
[doublepost=1484167467][/doublepost]
There is a BIG difference between an application that uses a fair amount of CPU, and one where a runaway process CONTINUOUSLY uses 100% (or nearly so) of the CPU.
How about the bug that even if you disable siri on the mac the process keeps running and you can't kill it or disable it.
https://macperformanceguide.com/blog/2017/20170108_1908-required-apps.html
Perhaps that is also draining battery power?
https://macperformanceguide.com/blog/2017/20170108_1908-required-apps.html
Perhaps that is also draining battery power?
My 13" and 15" 2016's are both humming along nicely with fine battery life, while everyone one here is crying that the Apple world is coming to an end...
They are amazing machines and I've owned a PB 2004, 1st gen MBP 2006, MBP 2009, MBA 2011, MBA 2012, MBPr 2015, and 2016 models along with various PC's I've built myself...
Okay, back to the complaining, belly aching, and general whining everyone... /sigh
xoxo
They are amazing machines and I've owned a PB 2004, 1st gen MBP 2006, MBP 2009, MBA 2011, MBA 2012, MBPr 2015, and 2016 models along with various PC's I've built myself...
Okay, back to the complaining, belly aching, and general whining everyone... /sigh
xoxo
I know because if reports are correct the battery fix affects safari use only.
Music pro applications equal Logic Pro. Cubase pro 9 and Pro tools. I have tested standardised projects across both computers. With no other applications running - I think you may have me confused with a 10 year old child.
Ps your plethora of caps for emphasis is adorable.
THIS!!!! It's amazing how many folks missed this simple truth.
Get off your high-horse!
Apple never said that you shouldn't use Developer mode in Safari. They said a typical user wouldn't generally turn off browser caching, and thus wouldn't have tripped-over this bug.
Consumer Reports in NO WAY "easily found a bug"; if so, they certainly didn't state that they DID. They insinuated that MAYBE there was a bug in Safari, since they got consistently GOOD results from Chrome. I'm sure that helped Apple zero-in on the Safari bug; but there is a BIG difference between saying "Hmm, I've noticed that...", and "We have isolated the problem to..."
Hmmm. Okay, so even though Apple itself uses the same basic method of a few canned web pages to do their official battery life tests...
... the complaint here from many people is that such a test does "not reflect real life".
The problem is, of course, that such tests have to take a middle ground, and have to be repeatable.
So think about it, folks. First, whose habits would you really test? Someone like my wife who barely surfs? Or someone like me who does intensive surfing at times? And how many hours a day do you run the test?
More importantly, some people here claimed that tests should go out to the real internet. Which then instantly makes the tests unrepeatable and quite likely unfair to other devices being tested on different days.
Perhaps playback of a video is the better metric, although I bet choice of video can make a difference there as well.
--
So the upshot is, there is no such thing as a perfect test. You just have to be aware that when Apple says "x hours of web surfing time", they actually mean fetching a page from a local server every three minutes, until the battery dies.
... the complaint here from many people is that such a test does "not reflect real life".
The problem is, of course, that such tests have to take a middle ground, and have to be repeatable.
So think about it, folks. First, whose habits would you really test? Someone like my wife who barely surfs? Or someone like me who does intensive surfing at times? And how many hours a day do you run the test?
More importantly, some people here claimed that tests should go out to the real internet. Which then instantly makes the tests unrepeatable and quite likely unfair to other devices being tested on different days.
Perhaps playback of a video is the better metric, although I bet choice of video can make a difference there as well.
--
So the upshot is, there is no such thing as a perfect test. You just have to be aware that when Apple says "x hours of web surfing time", they actually mean fetching a page from a local server every three minutes, until the battery dies.
Fine.
However, assuming that you mean that you are actually using Photoshop or Lightroom in the field, or FPX or After Effects if you are shooting video, what laptop do you think WOULD give you "all day" battery-life running THOSE applications?
I'm not being snarky; I am honestly baffled. You might get one hour difference with another laptop; but I really doubt that you could CONSISTENTLY achieve that.
Personally, I'd look into either an external auxiliary power-source, or a change in workflow; so you aren't having to run high-demand software while running on batteries for long periods in the field. That doesn't mean the new MBP isn't "Pro"; it just means you have an EXTREME corner-case, usage-wise, and must be considering the difference between 4 hours and 4.5 hours to be ALL the difference; because that's about what we're talking about, if you're being honest with yourself.
[doublepost=1484171984][/doublepost]
Um, maybe because the bug in Safari is a new, or very recent, one?
[doublepost=1484172353][/doublepost]
Nice try.
You said "Apple says it isn't a setting used by most users."
Then you magically turned the "most" into "none" with your statement: "So no web developers ever use Macbook Pro computers?"
I would say that, by and large, most users of any computer are not web developers. But some (which is related to "most", but not related to "none") is the key difference between what you are attempting to conflate and the true meaning of Apple's statement.
Publish your results and methods.
[doublepost=1484172893][/doublepost]
Then use the "Empty Cache" (or another Browser) until the next Sierra update, which has the bugfix.
You're mistaken. The cache bypass setting *triggered* the bug in question.
Disabling caching in a browser doesn't "simulate real world usage of a web browser". Unless of course, you think that "real world usage of a web browser" involves repeatedly reloading the same small set of pages of the local hard drive with caching disabled. That doesn't sound anything like "real world usage of a web browser" to me.
Every web browser in existence caches files *by default*. The fact that they have to change a default setting across the board in the name of making it 'consistent' doesn't pass the sniff test. Especially since they claim they want the results to reflect normal usage.
I get that they want to take network speeds out of the equation. That makes sense, since it's a variable that can't be adequately controlled. If you want to mimic hitting a wide variety of web pages without network timing inconsistency interfering with your measurements, put a wide variety of web pages on the local drive, don't hit the same small set of pages repeatedly.
And when you claim to be doing scientific testing (even low-grade scientific, like CR does), and you get widely variable results where you expect consistency, you don't just go ahead and say, "well, that doesn't make any sense at all, better publish." That's even *more* true when you flip one variable, and the results are suddenly consistent *and* within the expected range. That tells you that something was wrong with your first test, or that you've got a completely uncontrolled variable that you haven't accounted for, which makes the *entire* set of test results invalid. (Not just the wonky ones.)
[doublepost=1484173307][/doublepost]
Fascinating how you conflate "isn't a setting used by most users" with "no web developers ever use MacBook Pro computers. Are you claiming that most users are web developers? Or do you just enjoy posting non sequiturs?
I didn't say I liked the fact that it's not user repairable. I wish it was.
The truth is - I'm not expecting the SSD to fail - and if it does? Well, I pay Apple an expensive amount to repair it out of warranty and restore my backup or I buy a new computer and restore my backup. This is what happens. Do I like it? No. But I use my laptop for work, in these 4 years it will pay itself off several times, even if it explodes after that - I still got my money's worth. And, of course, my data is always backed up.
This is a trend. I can either just go with it - understand the downsides, or I can get some product I don't like using.
[doublepost=1484173578][/doublepost]
~10% after an hour of surfing here. So, no real issues. There could be numerous reasons why yours dropped 20% - but it doesn't mean Apple is hiding something. Perhaps something activated your dGPU and it stayed on. That thing cuts battery life in half
That's the plan, and that's what I'd do if I hit the battery issue. My post wasn't to complain about the existing bug, but rather explain to the previous poster that the "Disable Caches" feature definitely has a use case. Since he seemed to claim that I was simply trolling when asking about the potential bug fix release since I would have no use for it (which the article has now been edited to include the release date of).
Side-note: I haven't seen the battery drain reported by CR. All I did was ask when the fix will make its way to owners, and explain the use of the feature for those that demonized me for asking the question. I never complained.
Probably not.
According to people who were downloading the Beta builds of Sierra, they were, by turns, taking out and then putting-back the Time Remaining indicator in those Builds. And of course, that was LONG before the whole kerfluffle about battery life started with the new MBPs. Because it really doesn't work very well unless you sit there doing the same thing, hour after hour.
Obviously, you can still see an ESTIMATED Time-Remaining in Activity Monitor, plus I am pretty sure that the FREE "Coconut Battery" shows that, and much more. Here's a screenshot of the Coconut Battery Menubar info, and drop-down:
And here's the Coconut Battery URL:
http://www.coconut-flavour.com/coconutbattery/
[doublepost=1484174045][/doublepost]
Thanks for the update and clarification!
No, Chrome works fine, as does Firefox. the problem is only with Safari. and the Safari fix is already out.
You simply need to learn to read
Believe it or not, Apple's little footnote on the MacBook Pro Product-Page is damn-near a WHITEPAPER in terms of depth-of-explanation of testing-methodology compared with EVERY other Laptop manufacturer. Just poke around on the Dell, Lenovo and HP sites like I have, and you'll see.
[doublepost=1484175027][/doublepost]
And therein EXACTLY lies the rub.
If you don't know much about a product you TRUST CR.
Yet, if you DO know about a product, you tend to DISREGARD CR.
So, if it is true that MOST people don't really know much about batteries in computers, and/or computers in general, what do you think they think when CR says "Boy, these battery numbers are wacky! DO NOT BUY!"?
Personally, I think that CR should have contacted Apple before publishing their clearly anomalous results; but since they did not, I believe Apple has a legitimate cause-of-action against them.
[doublepost=1484175395][/doublepost]
Because Clicks lead to Subscriptions. And Subscriptions make the CR world-go-round.
[doublepost=1484175687][/doublepost]
My feeling is that they screwed up those tests and forgot to Disable Browser Cache, and thus got an unrealistically HIGH battery-life number, because virtually EVERYTHING was coming locally from SSD, which takes pretty much no power.
Next question?
There's no correlation between a negative Apple story and driving clicks for subscriptions. If there were, wouldn't CR consistently rate Apple products negatively? The opposite is true, especially regarding macbooks.
To be fair, approaching Apple first would have likely looked even worse in the press. Can you even imagine the following scenario?
Consumer reports goes to Apple with a lousy grade in hand. Some secretive discussion goes on behind closed doors. Consumer reports amends its grade a few days later and issues some mumbo jumbo about a safari bug which has now been solved.
The cynic would conclude that some sort of bribery had gone on behind the scenes and that CR's palm was being greased. This would have affected their credibility and their future profitability.
The battery is obviously an issue, cannot even handle 32 gb of ram under normal use. Weak design that only with ideal conditions will fully support Professional applications and users was my point.
Last edited: