A week ago I filed a bug report about Safari with Apple’s Feedback Assistant: (FB22057274) Pinned tabs: slow-loading target="_blank" links appear in the wrong tab. Apple has marked the “Resolution” of this bug report as “Investigation complete - Unable to diagnose with current information.” I was not notified by Apple that the investigation was complete, nor did Apple ask me for more information. Instead, Apple chose to toss my bug report into a virtual trash bin, or black hole.
It is rumored that the next major version of macOS will be a bug fix release, “another Snow Leopard.” Never mind that Snow Leopard was not actually a bug fix release. In any case, don’t believe the rumors. We’ve heard this kind of story before, and it amounted to nothing. By word and action—more accurately, inaction—Apple makes painfully clear its lack of commitment to software quality. If you’ve followed my blog, you may be aware that this is not the first time I’ve encountered “Investigation complete - Unable to diagnose with current information.” It appears to be standard practice. I have to assume that Apple engineers are incentivized by leadership to close bug reports, probably due to some perverse performance metric. If Apple is casually dismissing bug reports, what reason is there to believe that Apple is working on a major bug fix release? WWDC and presumably macOS 27 are coming in three months.
Back to my feedback, although I certainly don’t claim that the bug is the most important in the world, I do claim that the bug is 100% reproducible. I honestly don’t know what additional information Apple needs to diagnose it. I included not only steps to reproduce but also multiple screen recordings to illustrate. I have a suspicion that Apple did not even read my bug report, because I did not attach a sysdiagnose report. But a privacy-violating sysdiagnose would not be useful in this case! Anyway, here’s the description of the bug:
If you have a pinned tab with a web page with a target="_blank" link, and the link URL is slow to load, then the address bar shows the new URL loading in the pinned tab instead of a new tab.
This bug doesn't occur if you command-shift-click a link to open the link in a new tab in the foreground, of if the original tab is not pinned.
See the attached screen recordings. The "unpinned" video show the unpinned behavior, the "command-shift-click" video shows the behavior with a pinned tab and command-shift-click, and the "target-blank" video shows the behavior with a pinned tab and target="_blank"
The attached "index.html" file is the HTML source of the pinned tab in the videos.
I used Little Snitch with an "Ask" rule for example.org to simulate a slow-loading web page.
The "index.html" file included this simple code for two links:
<p><a href="https://example.org">command-shift-click to open in a new tab</a></p>
<p><a href="https://example.org" target="_blank">click to open in a new tab</a></p>
command-shift-click to open in a new tab
The "target-blank" video shows the bug. Notice that when example.org is loading, the pinned tab is still selected, but the address bar incorrectly shows example.org.
The "command-shift-click" video shows that the bug does not occur with command-shift-click, because that instantly creates and selects a new tab.
The "unpinned" video shows that the bug does not occur with an unpinned tab. Like with command-shift-click, but unlike with a pinned tab, clicking a target="_blank" link in an unpinned tab instantly creates and selects a new tab.
The only trick in my bug report is that I used Little Snitch to simulate a slow loading link. This was just the easiest way I could think of to reliably reproduce the bug. There are of course other ways to simulate a slow loading link; if Apple Safari engineers of all people somehow can’t figure that out, then they aren’t qualified for their jobs. Again, however, the more likely explanation is that my feedback was ignored because it did not include a pro forma sysdiagnose, but who knows, because Apple did not request more information of any kind from me.