| 02:30 | <Domenic> | Quick question regarding whatwg participant data, I originally signed up as an indivual but am now part of the Igalia organisation. Do I need to remove myself from https://github.com/whatwg/participant-data/blob/main/individuals.json or will the system handle it? |
| 11:55 | <zcorpan> | sideshowbarker: thanks for https://github.com/WebKit/WebKit/pull/24735 ! I haven't checked the patch closely, but note that for drag and drop the textInput event is fired first in both Chromium and WebKit today, and there's no spec yet for textInput for drag and drop. (There's also no spec for beforeinput/input for drag and drop.) |
| 12:08 | <zcorpan> | sideshowbarker: I think it would make sense to change the event order for drag and drop so that it's consistent with other editing operations, but I have no data if it's web compatible. |
| 12:12 | <sideshowbarker> | Thanks — as far as that WebKit textInput patch goes, I haven’t looked at the drag-and-drop test cases for that, but I guess my patch as currently written is changing the order for drag-and-drop too (that is, so beforeinput would now be fired first there too). |
| 12:14 | <sideshowbarker> | I think it’d likely take some significant more work to special-case the change such that for drag-and-drop it goes back to (stays at) the textInput-first state. |
| 12:17 | <sideshowbarker> | When I started on that patch at the beginning of the week, I had naïvely imagined that just changing the order of the events would be a pretty simple thing to implement. But… it’s not been. I don’t know about the code for those events in other engines, but in WebKit the way it happens — the way it’s coded — doesn’t at all easily facilitate flipping the order. |
| 12:19 | <sideshowbarker> | But that said, until this patch, I had never actually looked at the input-events code — the editing code — in WebKit. So it’s kind of a case where probably 80% of my effort has effectively been around getting familiar with that code and what it’s doing, and where. |
| 12:21 | <sideshowbarker> | For the code owners or somebody else already somewhat familiar with that code, it’d be much easier. |
| 12:26 | <sideshowbarker> | Among other things, handling the requirement to not fire textInput for Enter keypresses in input elements turned out to be one thing that didn’t work (regressed) after I first implemented the patch — and it wasn’t clear to me why it wasn’t working any longer, and how/where in the code I needed to fix it. But it basically amounted to re-implementing the check in a completely separate part of the code from where (in the HTMLInputElement code itself) the existing check is. |
| 12:29 | <sideshowbarker> | And all that said, I’m just assuming (hoping) the way I went about implementing it is actually the right/acceptable way to do it. But… it hasn’t actually been reviewed at all yet. So who knows, I may end up getting told by reviewers that the way I approached it is not the right way to go about it at all. |
| 12:34 | <sideshowbarker> | zcorpan: Anyway, I’d be happy if/when you have a few minutes, you might take a look at the 4 tests in the Tests that failed text/pixel/audio diff list at the top of https://ews-build.s3-us-west-2.amazonaws.com/macOS-Monterey-Release-WK2-Tests-EWS/89ef9249-36849/results.html. Those are tests that my patch regressed. I haven’t looked at them much yet to figure out what I need to do for them (if anything — since for any given test, it’s possible it could turn out that the test is deficient and I need to update/fix the test/results, rather than the code in my patch) |
| 12:36 | <sideshowbarker> | And if you look at https://github.com/WebKit/WebKit/pull/24735#issuecomment-1960782141 there are some other tests that regressed on other ports/platforms that I still need to look at too. (And this is all after having fixed earlier regressions in previous iterations of the patch) |
| 12:41 | <sideshowbarker> | And it sure would be nicer if could be working from the WPT tests at https://github.com/web-platform-tests/wpt/pull/44472 — but as I noted in https://bugs.webkit.org/show_bug.cgi?id=268988#c3, those tests can’t be run as expected in the normal WebKit test environment, due to its testdriver not yet implementing whatever those WPT test are relying on to automate the key sending and form-control filling. |
| 13:32 | <zcorpan> | sideshowbarker: https://ews-build.s3-us-west-2.amazonaws.com/macOS-Monterey-Release-WK2-Tests-EWS/89ef9249-36849/editing/pasteboard/paste-text-events-diff.txt "textInputCount should be 6. Was 12." seems like a real regression |
| 13:32 | <sideshowbarker> | yeah |
| 13:33 | <sideshowbarker> | working on the other ones now; adding an (additional) if (inputType == "insertText"_s || inputType == "insertParagraph"_s || inputType == "insertLineBreak"_s) check… |
| 13:47 | <zcorpan> | The flashbacks with these tests http://wpt.live/html/editing/dnd/selection/ |
| 13:48 | <sideshowbarker> | Flashbacks? |
| 13:49 | <zcorpan> | from Opera times |
| 14:53 | <Sam Sneddon [:gsnedders]> | nice, useful naming strategy in those tests |