Bug Hunting Session
Bug 33509 - Context menu in RTL spellcheck closes too early
Summary: Context menu in RTL spellcheck closes too early
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.0 RC4
Hardware: All All
: medium major
Assignee: Caolán McNamara
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-25 20:38 UTC by Fahad Al-Saidi
Modified: 2011-06-23 01:33 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
arabic spell-checking right click screenshot (15.56 KB, image/png)
2011-06-20 07:34 UTC, Caolán McNamara
Details
hebrew spell-checking right click screenshot (7.45 KB, image/png)
2011-06-20 07:35 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fahad Al-Saidi 2011-01-25 20:38:05 UTC
Hi all, 
This is an old and nasty bug for RTL langauge users [1]. I thought it will be better to report it here again in hope to be fixed faster than OpenOffice. 

Here is the description:
In RTL mode, when a user right-clicks on a misspelled Hebrew word in order to
see possible substitutions, the menu closes as soon as the user releases the
mouse button. Unless the user holds the mouse button down the entire time. he
does not have a chance to choose a substitution, because the menu has already
closed.

[1] http://qa.openoffice.org/issues/show_bug.cgi?id=62414
Comment 1 Noel Power 2011-01-27 08:02:02 UTC
it looks like something deep in vcl ( according to the associated iz bug http://qa.openoffice.org/issues/show_bug.cgi?id=55698 ) - trying Caolan
Comment 2 Caolán McNamara 2011-01-28 07:37:50 UTC
Well, I can reproduce it, and I can hack it fixed if needs be. Problem is really in writer.
Comment 3 Caolán McNamara 2011-01-28 13:22:15 UTC
ABCD
0123
    ^

Currently calls GetCharRect for position "0" and position "4". It should be
"3". We were placing the cursor *after* the final character. We really need to
place it *before* the final character and get the bounding box of the last char
to union it with the first char's bounding box. It works out ok for western
text, but you get a far different value for CTL text.
Comment 4 Caolán McNamara 2011-01-28 13:23:22 UTC
If the text is very short it might work seeing as the values are close enough, the longer the text is more likely it would popdown immediately
Comment 5 Caolán McNamara 2011-01-28 13:28:22 UTC
writer: f8118cf3888a2e95c35cc00705b458ada4ffe2d8
Comment 6 Fahad Al-Saidi 2011-01-28 20:11:06 UTC
@Caolán McNamara: Great. How can I test the patch without needing to compile libreOffice. Is there any nightly build?
Comment 7 Caolán McNamara 2011-01-29 04:54:31 UTC
Only way at the moment is to build it, hopefully soon we'll get nightly builds up and running
Comment 8 Fahad Al-Saidi 2011-06-17 04:23:07 UTC
Today I have some free time, so I tried LibreOffice 3.4. I can confirm that the bug still there and has not yet been fixed.
Comment 9 Caolán McNamara 2011-06-20 07:34:31 UTC
Created attachment 48192 [details]
arabic spell-checking right click screenshot
Comment 10 Caolán McNamara 2011-06-20 07:35:00 UTC
Created attachment 48193 [details]
hebrew spell-checking right click screenshot
Comment 11 Caolán McNamara 2011-06-20 07:36:48 UTC
Hmm, works for me. So...

a) what platform exactly is it failing on ?, and if it is Linux is it gtk or kde ?
b) can you attach a sample .odt here that has a misspelled work in it that reproduces it for you, in case my simple tests are missing something obvious.
Comment 12 Fahad Al-Saidi 2011-06-20 20:58:17 UTC
(In reply to comment #11)
> Hmm, works for me. So...
> 
> a) what platform exactly is it failing on ?, and if it is Linux is it gtk or
> kde ?
> b) can you attach a sample .odt here that has a misspelled work in it that
> reproduces it for you, in case my simple tests are missing something obvious.

You can produce the bug when you convert LibreOffice interface to Arabic from 
Tools > Options > Languages Settings > User interface

I use linux solely. I test the bug on KDE and GNOME desktops.
Comment 13 Caolán McNamara 2011-06-22 08:59:44 UTC
ah, two different bugs with the same effect.

bug 1) the first one to be fixed, by f8118cf3888a2e95c35cc00705b458ada4ffe2d8, is that any RTL word, regardless of the UI, would cause the popup dialog to immediately disappear

bug 2) the second one to be fixed, is that any word, whether a RTL word or a LTR word, in a RTL UI, would cause the popup dialog to immediately disappear
Comment 14 Caolán McNamara 2011-06-23 01:07:29 UTC
Bug two fixed with d72e9c179ced6e4fc7e01a297437c8c829890b00 in master, a different piece of logic was used for finding the place to put the menu in a rtl UI vs the logic used to find the place where the mouse pointer was, so it thought the menu wasn't getting placed under the mouse pointer.
Comment 15 Caolán McNamara 2011-06-23 01:33:33 UTC
cherry-picked to 3-4 for 3.4.2