Bug 71556 - Accessible text-attributes-changed signals should only be emitted when the text attributes have changed [a11y]
Summary: Accessible text-attributes-changed signals should only be emitted when the te...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.2.3 release
Hardware: Other Linux (All)
: medium normal
Assignee: Jacobo Aragunde Pérez
QA Contact:
URL:
Whiteboard: target:4.3.0
Keywords: accessibility
Depends on:
Blocks: a11y-Linux 104351
  Show dependency treegraph
 
Reported: 2013-11-13 04:19 UTC by Joanmarie Diggs
Modified: 2016-12-02 11:24 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
accessible-event listener (285 bytes, text/x-python)
2013-11-13 04:19 UTC, Joanmarie Diggs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2013-11-13 04:19:23 UTC
Created attachment 89116 [details]
accessible-event listener

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.
Comment 1 chrys87@web.de 2013-11-13 10:14:28 UTC
Confirmed as descriped.
Comment 2 V Stuart Foote 2013-11-22 00:24:45 UTC
confirmed in Linux kernel 2.6.32-358.23.2.el6.x86_64 with Gnome v2. DE and LODev

Version: 4.2.0.0.alpha1+
Build ID: f99736820a23cb7e37139607713658dea1c69dd4
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2013-11-17_23:56:22
Comment 3 Jacobo Aragunde Pérez 2014-04-25 09:30:41 UTC
Already fixed in master (would be part of 4.3), due to this commit:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e031c8ae1ac046fcf165213d80e83311d80a71f5

Shall we backport it?
Comment 4 Jacobo Aragunde Pérez 2014-04-25 09:32:21 UTC
(In reply to comment #3)
> Already fixed in master (would be part of 4.3), due to this commit:
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=e031c8ae1ac046fcf165213d80e83311d80a71f5
> 
> Shall we backport it?

Sorry, I typed in the wrong tab, this comment doesn't belong to this bug.
Comment 5 Jacobo Aragunde Pérez 2014-04-25 10:40:07 UTC
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.
Comment 6 Jacobo Aragunde Pérez 2014-04-25 18:15:56 UTC
(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:

    if (isA11yRelevantAttribute(nWhich))
        // 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.
Comment 7 Commit Notification 2014-04-30 14:47:46 UTC
Jacobo Aragunde Perez committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dddae1f0b950f1ce8ab4bcd24991f1917fa36aa6

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:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 8 Jacobo Aragunde Pérez 2014-04-30 14:57:09 UTC
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.
Comment 9 Xisco Faulí 2016-09-15 22:34:32 UTC
Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Comment 10 Alex ARNAUD 2016-12-02 11:11:57 UTC
(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
> paragraph.

Dear Jacobo,

Version: 5.2.3.1
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 ?

Best regards.
Comment 11 Aron Budea 2016-12-02 11:24:34 UTC
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.