GNOME Bugzilla – Bug 756397
Duplicate (and arguably too many) accessible object:text-changed:insert events with Gtk+ 3
Last modified: 2020-11-24 09:57:03 UTC
Created attachment 313069 [details] accessible-event listener Steps to reproduce: 1. Launch the accessible-event listener in a terminal 2. Open the attached test case in Gedit 3. Open the attached test case in Pluma (Gedit fork using Gtk+ 2) 4. Compare the resulting accessible object:text-changed:insert events Expected results: No duplicate events. And preferably far fewer events. Actual results Gedit (see below): 28 events (14 events, each duplicated) breaking the document text into 8192-character chunks. Actual results Pluma (see below): 1 event. Admittedly missing some of the initial text, but... Impact: Given a really large document, Orca is getting flooded with accessible events that are of no interest to Orca or its users (because the text insertion is the result of merely opening the document; not the result of user action and thus something Orca should present to the user). ===== Pluma ===== 82510 chars inserted by [application | pluma] into [text | ] (ine 1750 Line 1751 - Line 9999 Line 10000) ===== Gedit ===== 0 chars inserted by [application | gedit] into [text | ] (-) 0 chars inserted by [application | gedit] into [text | ] (-) 8192 chars inserted by [application | gedit] into [text | ] (Line 1 Line 2 - 921 Line 922 Li) 8192 chars inserted by [application | gedit] into [text | ] (Line 1 Line 2 - 921 Line 922 Li) 8192 chars inserted by [application | gedit] into [text | ] (ne 923 Line 924 - 1748 Line 1749 L) 8192 chars inserted by [application | gedit] into [text | ] (ne 923 Line 924 - 1748 Line 1749 L) 8192 chars inserted by [application | gedit] into [text | ] (ine 1750 Line 1751 - 2567 Line 2568 Lin) 8192 chars inserted by [application | gedit] into [text | ] (ine 1750 Line 1751 - 2567 Line 2568 Lin) 8192 chars inserted by [application | gedit] into [text | ] (e 2569 Line 2570 - 3386 Line 3387 Line) 8192 chars inserted by [application | gedit] into [text | ] (e 2569 Line 2570 - 3386 Line 3387 Line) 8192 chars inserted by [application | gedit] into [text | ] (3388 Line 3389 Line - Line 4206 Line 42) 8192 chars inserted by [application | gedit] into [text | ] (3388 Line 3389 Line - Line 4206 Line 42) 8192 chars inserted by [application | gedit] into [text | ] (07 Line 4208 Line - Line 5025 Line 5026) 8192 chars inserted by [application | gedit] into [text | ] (07 Line 4208 Line - Line 5025 Line 5026) 8192 chars inserted by [application | gedit] into [text | ] (Line 5027 Line 5028 - 5844 Line 5845 L) 8192 chars inserted by [application | gedit] into [text | ] (Line 5027 Line 5028 - 5844 Line 5845 L) 8192 chars inserted by [application | gedit] into [text | ] (ine 5846 Line 5847 - 6663 Line 6664 Lin) 8192 chars inserted by [application | gedit] into [text | ] (ine 5846 Line 5847 - 6663 Line 6664 Lin) 8192 chars inserted by [application | gedit] into [text | ] (e 6665 Line 6666 - 7482 Line 7483 Line) 8192 chars inserted by [application | gedit] into [text | ] (e 6665 Line 6666 - 7482 Line 7483 Line) 8192 chars inserted by [application | gedit] into [text | ] (7484 Line 7485 Line - Line 8302 Line 83) 8192 chars inserted by [application | gedit] into [text | ] (7484 Line 7485 Line - Line 8302 Line 83) 8192 chars inserted by [application | gedit] into [text | ] (03 Line 8304 Line - Line 9121 Line 9122) 8192 chars inserted by [application | gedit] into [text | ] (03 Line 8304 Line - Line 9121 Line 9122) 8192 chars inserted by [application | gedit] into [text | ] (Line 9123 Line 9124 - 9940 Line 9941 L) 8192 chars inserted by [application | gedit] into [text | ] (Line 9123 Line 9124 - 9940 Line 9941 L) 590 chars inserted by [application | gedit] into [text | ] (ine 9942 Line 9943 - Line 9999 Line 10000) 590 chars inserted by [application | gedit] into [text | ] (ine 9942 Line 9943 - Line 9999 Line 10000)
Created attachment 313070 [details] test case
It's most probably because GtkSourceView 3 loads files asynchronously, chunks by chunks, to not block the user interface.
If so, that would seem to rule out the "just one, please" request. Benjamin: What do you think about not emitting accessible text-inserted signals in this particular instance?
I don't think there's anything GTK can do about it. At least not easily. Because when the text changes GTK doesn't know why. It just know that the text changed.
Wait, are we emitting every event twice? Because *that* should indeed be fixable. But the coalescing of multiple events into one is way more difficult on the GTK level. Gedit could probably improve that if it didn't use 8kB buffers but larger ones (like 1MB maybe?). But I have no idea why 8kB was chosen...
A small chunk was probably chosen to implement easily a smooth progress bar. For the duplication, I don't know when the accessible object:text-changed:insert events are triggered, but one thing that has changed in GTK+ 3 is the emission of the notify signal for the GtkTextBuffer:text property (in addition to the ::insert-text signal).
It looks to me like testsuite/a11y/text.c verifies that we emit text_changed::insert and text_changed::delete in the expected way. If there is something amiss, I would appreciate a patch that adds a testcase here, showing the issue.
I don't see the duplicated events with GtkTextView examples in gtk+. Neither am I seeing it with polari. Just with gedit. Moving the back back to where it came from
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.