Given the recent debate around an accessibility browser, I decided to actually try fixing accessibility problems directly in WebKit.
The first bug that I will try fixing is the broken text announcement when navigating a text area by paragraph. I have already cloned the official repository, which is 12GB in size, and am now waiting for it to finish compiling for the first time, which is taking quite long. Unfortunately I don't have my Mac Studio with me at the moment so will have to make do with an M5 MacBook Air which is currently warm to the touch due to the compilation. The system is so loaded that I've even noticed stuttering on the music playback.
Once it builds I'll try running Safari with it, make some minor changes just to make sure that it's my build that's running, and if so, will begin browsing the huge codebase to learn the best strategy to fix the aforementioned bug. If I do manage to fix the bug and get my patch accepted, maybe I'll try fixing more, otherwise I'll just abandon this. I don't give up easily though. In fact I'm a lot more likely to give up on easy things that don't represent a challenge than on hard things that put up a good fight.
Comments
Good luck
If you can get some fixes in there, then you will be a hero round these parts.
12gb is some repository - wow.
Excellent
GOod on you. I was thinking of taking a look at this myself following that thread and may still do, though not the same bug of course. I hadn't checked out the repo yet, that is definitely not an insignificant codebase!
Finished compiling
I decided to take a nap waiting for it to compile and it finished shortly after I fell asleep in just over 2 hours of processing.
I browsed the WebProcess source code trying to find the relevant text area accessibility code but failed, so my next attempt is to write a debugger script that I can use to record all the functions called, run Safari with this development build of WebKit, and then enable the debugger script while editing text in a text area to see if I can find the source code responsible for that. Unfortunately almost half the codebase is in JavaScript and debugging like this requires native code in C++ or Objective-C++ to work, so I'm not sure if even this brute force attempt with the debugger will succeed. This is definitely not a trivial codebase.
I'll ask Gemini to write the debugger script since I'm not feeling like reading the lldb scripting API documentation. It should be a short script whose success should be easy to tell so the AI should not have a problem with it.
Deeper problem
This doesn't seem like an accessibility problem to me anymore. It's more like a deeper problem that manifests with accessibility.
The problem happens when a text area forces a long paragraph to wrap into multiple visible lines. Trying to read by paragraph after that always results in the whole text being read, or just the last line in the case of blank lines. However if instead of typing I just paste the text, browsing by paragraph resumes working normally, so now I'll have to figure out what is the fundamental difference between typing and pasting that's causing this behavior. It's likely that the line-wrapping is filling some accessibility buffer incorrectly.
I don't think that this will be an easy fix, which makes it fun. I'll go silent now and will only return if and when I find the offending source code.
Objective C
If I am remembering correctly, the original Apple OS, Matt, iPhone, etc., was all written under objective C. I understand that newer applications for Apple operating systems are written under swift, but if I remember correctly Swift was also compiled using objective C as its foundation.
Objective C is quite an old and outdated programming language, and I think by now most of us know that Apple is very good at piling code on top of code. If WebKit follows the standard, you may have to dig deep into the core of Web kids source code, in order to patch this.
I don't know if this will be useful information to you or not, but thought I would offer my two cents. 🙂
Postponing this
SO I hit a roadblock, which is that Safari sets a kernel flag to prevent it from getting debugged, working around this requires disabling System Integrity Protection because although I can make Safari run with my own build of WebKit, the main executable is still a system binary, I only do that inside virtual machines, and this MacBook Air simply doesn't have enough RAM to compile projects of this complexity on a virtual machine. Therefore I'll postpone this and wait to get my Mac Studio with its 128GB back to resume working on this.
Unfortunately I had a very sophisticated security breach back in March which I think was state sponsored to look for drone technology that I was considering developing, and as a result I filed a police report, handed over all the affected hardware for investigation, and bought new hardware that is nowhere as powerful as the hardware that I handed over. Also unfortunately the investigation is taking way too long, assuming it's already been started, so I may have to retract the report in order to get all my devices including my Mac Studio back.
As for Objective-C, I am very familiar with it, since I began developing on Apple platforms in 2011, 3 years before Swift came out. However WebKit is mostly written in JavaScript followed by C++ with some Objective-C++ sprinkles for Cocoa integration. WebKit is a cross-platform framework, and Objective-C is mostly only available on Apple systems, which is why it uses C++ for the lower level business logic.