Through focussed debugging, I have discerned that if a web page's "text" input element's name attribute contains a dash (and does not contain -#- (e.g. -0-)), Safari will: Display a contacts icon inside the field and Add a drop-down populated with phone numbers from the user's contact card (on top of any pre-existing datalist dropdown). Ignore the element's autocomplete="off" There is post after post and blog article after blog article on the web that propose endless solutions to similar Safari issues, each working in various different contexts. It's a mess really. I am currently trying to develop a django web form for scientific data using django's FormSet class. Specifically, I was using FormsSet.empty_form to create a javascript clone-able form that would propagate field values to added (numbered) forms. I implemented things incrementally. I started out with a regular form and encountered a behavior where an autofill dropdown would present me with previously submitted values, e.g.: Adding autocomplete="off" to the input element prevented this. I then implemented formsets, defaulting to 1 form (so that all input elements' names started with form-0-) and everything worked as expected. However, when I changed the strategy with default to 0 initial forms and presented FormSet.empty_form as a template that would be cloned anytime files were dropped/selected, I started getting phone number drop-downs in all of the test fields: I googled this quite a bit and tried many things, including a strategy I'd employed before, to no avail, so to make debugging this issue easier and try a bunch of things quickly, I saved the page source and put it in the static folder, then started tweaking things to figure out what was causing this to happen. It appears that anytime a text input element's name attribute contains a dash (and does not contain -#-), Safari assumes it's a phone number field, despite the fact that the name's text, placeholder's text, possibly the label's text, the fact that the element has a list attribute set to the ID of a datalist element, and the fact that autocomplete is explicitly set to off. I would say that the heuristic used to trigger phone number autofill needs some serious tweaking. Not only that, but web developers need more transparency on how it works, so that non-sensical autofill behavior like this can be avoided. Another aspect of this is that if you have lots of cloned forms that Safari tries to apply autofill to, it dramatically decreases the page's performance. Safari autofill behavior has been a constant bane of mine, because many of our users use macs. I have not yet tried CSS solutions I've seen hints of (mainly because all the articles/posts I've seen about them are quite dated). Any information anyone can provide to tame Safari autofill and prevent this errant behavior would be much appreciated.

I just updated to Sonoma on a Mac Mini that runs all my ad-hoc DIY home automations, and I have a bunch of custom self-made tools for triggering automations based in part on the state of reminders in the Reminders app. All of that stopped working immediately after the update. It took me a day to update my code for the new location of the sqlite reminders files and I made the changes to get my scripts working again, however one remaining problem is that I run an fswatch from node-red to monitor the database for changes to trigger my automations. Eventually, with help from stack and perlmonks, I found out that even though the permissions on the full path (via my home directory/Library) to the files is r*x to me and the node-red executable is running as me, I get an Operation not permitted error when I just try lsing the directories leading to the sqlite files. I read elsewhere that this sort of problem can be solved by granting full disk access to the executables(/processes) that are getting the Operation not permitted errors. However, I tried this, yet I still get the same error. Do I need to reboot? Is there some sort of documentation for casual users like myself that just code for themselves that can answer questions like this? The more aggressive Apple gets with security, the safer users are, but the more headaches and bewilderment it causes people like me.