Created attachment 89116 [details]
Steps to reproduce:
1. Launch the attached accessible-event listener in a terminal.
2. Launch LibreOffice Writer and begin typing
Expected results: text-attributes-changed events would be seen if some action was taken which changed the text attributes (e.g. toggling bold, increasing the font size, hitting space after typing a misspelled word).
Actual results: text-attributes-changed events appear each time a new character is typed in the paragraph even though the attributes haven't changed.
Confirmed as descriped.
confirmed in Linux kernel 2.6.32-358.23.2.el6.x86_64 with Gnome v2. DE and LODev
Build ID: f99736820a23cb7e37139607713658dea1c69dd4
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2013-11-17_23:56:22
Already fixed in master (would be part of 4.3), due to this commit:
Shall we backport it?
(In reply to comment #3)
> Already fixed in master (would be part of 4.3), due to this commit:
> Shall we backport it?
Sorry, I typed in the wrong tab, this comment doesn't belong to this bug.
I've been checking the issue, and that's what I got:
The text-attributes-changed event is triggered by an actual attribute changed in the text object. That attribute is the RSID, which is used for document version comparison but it's not visible to the user.
In theory LibreOffice should detect the accessibility event caused by this particular attribute and drop it, but it's not doing it for some reason. That was in commit 8d08ccd5b84c121867d7b3102f9d10b26005c682.
(In reply to comment #5)
> I've been checking the issue, and that's what I got:
> In theory LibreOffice should detect the accessibility event caused by this
> particular attribute and drop it, but it's not doing it for some reason.
> That was in commit 8d08ccd5b84c121867d7b3102f9d10b26005c682.
The problem is that the code to drop the event in case it's caused by an RSID change never worked. The code is located at SwTxtFrm::Modify:
// send event
where isA11yRelevantAttribute looks like:
static bool isA11yRelevantAttribute(MSHORT nWhich)
return nWhich != RES_CHRATR_RSID;
The problem is nWhich value cannot be RES_CHRATR_RSID, it is always RES_UPDATE_ATTR in that point of the code. The method has received a SwUpdateAttr (parent class SfxPoolItem) which contains a description of an attribute modification and which nWhich value is RES_UPDATE_ATTR. That item tells us that the RES_TXTATR_AUTOFMT attribute was modified, but it doesn't tell us which of the specific text format attributes was changed.
I can access the contents of the text format attributes to check the presence of RSID attribute, but it is not enough because I only can check the present value and I don't know if it has changed. The SwUpdateAttr object doesn't contain enough information; the solution might be extending it so we can specify which sub-attributes are changing.
Jacobo Aragunde Perez committed a patch related to this issue.
It has been pushed to "master":
fdo#71556: Remove unwanted a11y event on text insertion
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
After the patch, most of the unwanted text-attributes-changed events are now gone. Still, the event shows up when you type the first letter of a new paragraph.
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
(In reply to Jacobo Aragunde Pérez from comment #8)
> After the patch, most of the unwanted text-attributes-changed events are now
> gone. Still, the event shows up when you type the first letter of a new
Build ID: 1:5.2.3~rc1-4~bpo8+1
Threads CPU : 4; Version de l'OS :Linux 3.16; UI Render : par défaut;
Locale : fr-FR (fr_FR.UTF-8); Calc: group
Thanks you very much for the work you have provided to reduce the impact of this issue.
On LibreOffice GTK2 the issue appears when you type the first letter of a paragraph or a word.
Do you think it could be possible with the new LibreOffice code to fix this issue completely ?
Alex suggested on IRC to close this, since the majority of this bug has been resolved. I opened bug 104351 for the remaining, minor issue. Please continue the discussion there.