Yes, you’re right, I did neglect to actually put a specific search term that was doing this for me. That was almost a year ago so I can’t completely remember why I didn’t, but I think it had to do with it being history-specific so I didn’t really think it would be all that helpful for reproducing the issue. Still, my mistake, and if it helps I think that I took that sysdiagnose right after reproducing that issue. As for the other bug: according to my history I first hit that on the 16th on my iPad. I didn’t file it at that point because 1. we don’t have tap-to-Radar so I’m a bit lazier about filing bugs when I’m not at my computer and 2. submitting bugs for something you saw once the week before WWDC is a surefire way to get it ignored.
Speaking of that, I’d just like to say one more thing on this topic while I still have your attention here. While the things I mentioned here could have been filed a bit better, aside from that I really do try my best to report things I find, often in great detail and depth that I specifically take time out of my day for. I run Safari Technology Preview ten hours a day, every day, on whatever the latest developer beta is. (Yes, I’m running Big Sur and using yesterday’s build.) I think Safari is a great browser; I know everyone on the team is passionate and cares about making it better, and I’m sure they’d be disappointed to hear that I’m going around calling some part of it “totally broken” on a reasonably sized social website and that my experience is clearly shared by many of the people here.
But the usual Apple complaint still applies here: they need to be more responsive to reports, and yes they need to actually fix their stuff. I know this is not your team, and that you probably don’t have much control over this, but you’re surely in contact with them often and I’d appreciate it if you could remind them. I have filed literally dozens of Safari bugs in the last few years. It’s probably the component I file bugs against the most because I use it so much and because I care very much that it works right. But it’s disheartening to see maybe half of them getting any response at all, and of those just a couple with actual responses that are not just “please attach a sysdiagnose” or “this bug has been marked as a duplicate”. It’s disheartening to find bugs in Safari Technology Preview running on a developer seed and have them be ignored as they slowly make their way into public beta Safari and then into an official release where other people run into it. It’s disheartening when I can go a month without being able to launch Safari Technology Preview with it crashing immediately until I literally take a binary diff of Safari.framework, disassemble it, and find the exact change made and the circumstances that made it crash, and highlight it in a red circle along with a suggested patch to get it fixed correctly (Safari Technology Preview releases 37 and 38, rdar://problem/33815640, rdar://problem/34167199). More recently I was having crashes every two hours-or under load, even more frequently-because of something which I will bet you $10 is a data race in Safari’s Remote Web Inspector Lockdown code (this has stopped crashing but now causes an infinite loop, and I’ve become accustomed to attaching a debugger to Safari, breaking in the offending code, and suspending the lockdown queue from there; FB7660529). When you put out these prerelease builds and I take the time and effort to use them and file issues about them, I think the least I can expect is the bugs actually being fixed or barring even that just some acknowledgement of the issue. Thanks.
Thanks for the feedback. I agree that communication about bugs could be better. Still would appreciate an FB# for any weird autocompletes you experience.
I’ll make sure to file a feedback if I run into it again, and if you’d like I’d be more than happy to email the number to you as well if you’d like to CC yourself on it or push it to the right people. Thanks for your help!
Speaking of that, I’d just like to say one more thing on this topic while I still have your attention here. While the things I mentioned here could have been filed a bit better, aside from that I really do try my best to report things I find, often in great detail and depth that I specifically take time out of my day for. I run Safari Technology Preview ten hours a day, every day, on whatever the latest developer beta is. (Yes, I’m running Big Sur and using yesterday’s build.) I think Safari is a great browser; I know everyone on the team is passionate and cares about making it better, and I’m sure they’d be disappointed to hear that I’m going around calling some part of it “totally broken” on a reasonably sized social website and that my experience is clearly shared by many of the people here.
But the usual Apple complaint still applies here: they need to be more responsive to reports, and yes they need to actually fix their stuff. I know this is not your team, and that you probably don’t have much control over this, but you’re surely in contact with them often and I’d appreciate it if you could remind them. I have filed literally dozens of Safari bugs in the last few years. It’s probably the component I file bugs against the most because I use it so much and because I care very much that it works right. But it’s disheartening to see maybe half of them getting any response at all, and of those just a couple with actual responses that are not just “please attach a sysdiagnose” or “this bug has been marked as a duplicate”. It’s disheartening to find bugs in Safari Technology Preview running on a developer seed and have them be ignored as they slowly make their way into public beta Safari and then into an official release where other people run into it. It’s disheartening when I can go a month without being able to launch Safari Technology Preview with it crashing immediately until I literally take a binary diff of Safari.framework, disassemble it, and find the exact change made and the circumstances that made it crash, and highlight it in a red circle along with a suggested patch to get it fixed correctly (Safari Technology Preview releases 37 and 38, rdar://problem/33815640, rdar://problem/34167199). More recently I was having crashes every two hours-or under load, even more frequently-because of something which I will bet you $10 is a data race in Safari’s Remote Web Inspector Lockdown code (this has stopped crashing but now causes an infinite loop, and I’ve become accustomed to attaching a debugger to Safari, breaking in the offending code, and suspending the lockdown queue from there; FB7660529). When you put out these prerelease builds and I take the time and effort to use them and file issues about them, I think the least I can expect is the bugs actually being fixed or barring even that just some acknowledgement of the issue. Thanks.