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
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
Well, I can reproduce it, and I can hack it fixed if needs be. Problem is really in writer.
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.
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
writer: f8118cf3888a2e95c35cc00705b458ada4ffe2d8
@Caolán McNamara: Great. How can I test the patch without needing to compile libreOffice. Is there any nightly build?
Only way at the moment is to build it, hopefully soon we'll get nightly builds up and running
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.
Created attachment 48192 [details] arabic spell-checking right click screenshot
Created attachment 48193 [details] hebrew spell-checking right click screenshot
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.
(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.
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
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.
cherry-picked to 3-4 for 3.4.2