The Project Groups feature looks great.
There are some fixes to the URL Trigger feature. URL Trigger had some longstanding bugs: it wouldn’t always let you change from GET to POST, and even if your trigger was set to use POST it would still send the request via GET. This was problematic because the parameters would end up in your Web server log. And, even worse, if the parameters had too much data for the query string, the trigger would run into an error, and your server would never get the ping. Now, there should be no length limit because URL Trigger actually uses POST—although, confusingly, the way you tell it which parameters to send is by writing a query string. There is still a bug where every time you edit the URL trigger you have to click the “POST” checkbox again.
The new design is fine in most ways, but unfortunately the main body text color has changed from black to gray, which makes it lower contrast and harder to read. It is not so easy to see this in the example screenshots because the only body text is the two occurrences of “Hodor!”. However, in actual use, there are paragraphs of gray text occupying the bulk of the page.
There’s also a minor bug in that FogBugz’s sort indicator triangles are now upside down. That is, if your list is sorted A-Z the triangle will be shown with the point at the bottom.
There’s a new bug where resolving or closing a case will often bring up a modal alert that says:
Are you sure you want to leave this page?
Your case hasn’t been submitted yet, are you sure you want to leave?
It is not fun to see that many times throughout the day. Since this is hosted software, there’s no way to revert to an earlier version until the bug is fixed. The bug seems to only affect Safari, but I don’t like using other browsers. Turning off the Performance Upgrade also helps but has its own downsides.
Update (2015-07-05): The sort indicator arrows have been fixed.
Bug Bug Tracking Design FogBugz Safari Web
Benjamin Mayo:
discoveryd would cause random crashes, duplicate names on the network and many other WiFi-relate bugs. In the latest beta, Apple appears to have applied the same fix as the enthusiasts by axing discoveryd completely.
Looking at Activity Monitor on OS X 10.10.4 seed 4, discoveryd is no longer loaded by the system — instead relying on mDNSResponder. The ‘new’ process is really the one Apple used to use pre-Yosemite and did not have these problems.
John Gruber:
The saga of discoveryd is baffling to me. I would love to hear the backstory on how it shipped. And I still haven’t heard a plausible theory on what Apple was hoping to accomplish with it in the first place. What was the point of it?
Nick Heer:
There are two weeks until WWDC, where Apple will probably introduce OS X 10.11. While that won’t be released to the public until, most likely, autumn, 10.10.4 isn’t publicly available yet either. That means that developers, at least, have been using and complaining about discoveryd for about a year, and it’s still busted for consumers.
Furthermore, I haven’t heard a compelling reason for discoveryd’s existence. It must be “better”, in some way, because I can’t think of another reason why Apple would task their engineers with rewriting the networking stack. I always assumed it was to unify iOS and OS X and to enable Continuity features, but those seem to work just fine under mDNSresponder.
Lloyd Chambers:
I’ve had my own inexplicable and disturbing network failures which require disabling networking, then re-enabling it—even as the same local LAN has no issue at all on a 2nd machine. Maybe it’s discoveryd, maybe not but I’m hoping. And then there is the Pathological Network Performance in Apple OS X issue, but I don’t expect Apple to fix that one.
Hopefully, this will eventually fix the problem where I have to reboot my Apple TV before using it or it won’t have network access.
Previously: discoveryd Is Still Buggy, Why DNS in OS X 10.10 Is Broken.
Apple Software Quality Bug Domain Name System (DNS) Mac Mac OS X 10.10 Yosemite Networking Software Rewrite Wi-Fi
