Problem description: Steps to reproduce: 1. Hightlight a piece of text in a text box. 2. Right-click on it. 3. Sometimes a spellchecker menu appears and sometimes the normal context menu (with "cut", "copy", and "paste" at the bottom) appears. Current behavior: As above. Even within a single text box, the behavior of the right click depends on which piece of the text is selected, it seems to me. I haven't found out exactly what causes which menu to appear. Expected behavior: The spellchecker menu is inconvenient when you want to copy the text. Operating System: Mac OS X Version: 4.0.1.2 release
In my opinion this not a bug. Which kind of context menu appears depends on the word on which you double-click. If this word is correct, then the normal context menu appears. If this word has a typing error, then the spellchecker context menu appears. @Ryo: Could you please give a feedback if this resolves your issue, so that we can close this bug report.
Thank you for your input. > In my opinion this not a bug. > Which kind of context menu appears > depends on the word on which you double-click. > If this word is correct, then the normal context > menu appears. If this word has a typing error, > then the spellchecker context menu appears. First of all, let's NOT ask whether this is a bug or not. Let's ask whether this is a desirable behavior. I don't think it is. My argument is as follows. There are TONS of applications---browsers, text editors, drawing tools, presentation software, PDF viewers, etc.---on which you can select a portion of text, right-click on it, and copy it to the clipboard. Think about it. There are TONS of them. Users, including me, are used to the behavior. That's a very, very common behavior. You can say it's "the" standard behavior. As far as I know, LibreOffice Impress is the only application that sometimes fails to offer a "copy" option on a text selection. You can imagine how irritating that is. So, please include "copy" and "cut" (or "delete") in the context menu, even when spellchecker kicks in. Second, what you say is not entirely true. > If this word is correct, then the normal context > menu appears. If this word has a typing error, > then the spellchecker context menu appears. What I experience is different. Write a piece of text containing several misspelled words and correct ones. By mouse-dragging, choose a portion of the text and right-click on it. If the selection is a single misspelled word, the spellchecker menu always appears, as you describe. But, if the selection includes both correct and misspelled words, the spellchecker menu appears in some cases and the normal menu (including "copy") appears in other cases. Which menu appears seems to be random to me. (I don't understand the rules that determines it.) So, the current behavior is worse than you describe. We can call this part "a bug", I think. But, even if it's not a bug, the behavior needs fixing. Third, is it a good idea to have the spellchecker menu on right-click? I think it's too much intrusion. Think about a situation where there are foreign personal names the dictionary doesn't know and you want to copy a portion of text including those names. The intrusion of spellchecker is simply annoying.
@Ryo: Thank you very much for your fast reply. > behavior. As far as I know, LibreOffice Impress is the only application > that sometimes fails to offer a "copy" option on a text selection. You can > imagine how irritating that is. > > So, please include "copy" and "cut" (or "delete") in the context menu, even > when spellchecker kicks in. I would agree, this should be included. But not only these both options but all of the normal context menu. In the normal context menu we have a submenu SYNONYMS, maybe the spellchecker could also be integrated in this way. > What I experience is different. Write a piece of text containing several > misspelled words and correct ones. By mouse-dragging, choose a portion of > the text and right-click on it. If the selection is a single misspelled > word, the spellchecker menu always appears, as you describe. But, if the > selection includes both correct and misspelled words, the spellchecker menu > appears in some cases and the normal menu (including "copy") appears in > other cases. Which menu appears seems to be random to me. (I don't > understand the rules that determines it.) This I could unfortunately not reproduce with LO 4.0.1.2 (Win7 Home, 64bit). > Third, is it a good idea to have the spellchecker menu on right-click? I > think it's too much intrusion. Think about a situation where there are > foreign personal names the dictionary doesn't know and you want to copy a > portion of text including those names. The intrusion of spellchecker is > simply annoying. I think to have the spellchecker in the context menu is a nice feature. But I would agree, that sometimes context menus in LO are getting overloaded. Therefore, we need think how we can design the context menus more user-friendly and intuitive. We should for instance think whether the context menu items TEXT and BULLETS AND NUMBERING are really necessary in the context menu. The same would for me apply to EDIT STYLE, because this is a further menu for all the other options all together. Why can't I find it in the menu FORMAT at the top? In addition, the context menu item FONT is for me worthless, because I am faster choosing it from the menu at the top (scrolling down in the context menu takes much longer) and in addition there you have a preview of the font, which you don't have in the context menu. Furthermore, I can't even select all available fonts because it stops at the font JasmineUPC. @Thorsten: Could this issue maybe be something for you?
I agree that it'd be best to have at least the clipboard elements of the standard conext menu in the "spellcheck" context menu as well. I would also get rid of the font list in the standard context menu, as it's better to manage fonts using styles and as it lists only a subset of the system fonts anyway. Hopefully those two changes are no-brainers. As for personal suggestions on what else can be changed: * There is a "Default" item in the standard menu, but there's no clue as to what it does. (I myself have no idea what it does.) * "Change case" would be better handled by styles, but it seems that, for some reason, presentation styles don't support that feature yet. * "Size" might be better left up to styles as well. (If need be, it's in the toolbar.)
Hi, If this issue is about adding Copy/Cut/Paste to the context menu when spell checking is on: +1 When we start discussing other items in the context menu, pls not here.
*** Bug 64251 has been marked as a duplicate of this bug. ***
this is also relevant for WRITER, see e.g. also Bug 64251
Created attachment 108428 [details] simple test case to play with it
(In reply to Ryo Furue from comment #2) > ...Write a piece of text containing several > misspelled words and correct ones. By mouse-dragging, choose a portion of > the text and right-click on it. see attached test file > If the selection is a single misspelled > word, the spellchecker menu always appears, as you describe. confirmed in LibO 4.3.2.2 asalready discussed I agree it would be nice to have "Copy/Cut/Paste" items at the bottom to the spellcheck context menu > But, if the selection includes both correct and misspelled words, the spellchecker menu > appears in some cases and the normal menu (including "copy") appears in > other cases. Which menu appears seems to be random to me. (I don't > understand the rules that determines it.) I think it depends on the cursor position during right click over that selection. if it's over a correct word the standard context menu appears. if it's over the misspelled word the selection changes focus just on that single word and the spellcheck context menu kicks in.(In reply to Cor Nouws from comment #5) > Hi, > If this issue is about adding Copy/Cut/Paste to the context menu when spell > checking is on: +1 > > When we start discussing other items in the context menu, pls not here. I thinks we should change the summary notes accordingly and put an ux-advise tag in the fields. if the UX team decides it's something feasible it would be probably an easy hack. what do you think, Cor?
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
The same bug exists on the latest version: Version: 5.2.4.2 Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0 CPU Threads: 8; OS Version: Mac OS X 10.12.2; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group which I copied from "LibreOffice" > "About LibreOffice". When you right-click on a misspelt word, the right-click menu does not include "copy" or "cut".
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This problem seems to have been fixed. On the LibreOffice Writer, write a misspelt word. A red squiggly line appears below it. Select the word and right-click on it. You'll see the regular menu items Cut/Copy/Paste. Nice! I tested the above with Version: 5.4.4.2 Build ID: 2524958677847fb3bb44820e40380acbe820f960 CPU threads: 8; OS: Mac OS X 10.13.2; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
Thanks for testing and reporting, Ryo. I set as WorksForMe. Cor