Bug 89673 - EDITING - can't use the regular context menu on misspelled words
Summary: EDITING - can't use the regular context menu on misspelled words
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: high major
Assignee: Not Assigned
Depends on:
Blocks: Context-Menu
  Show dependency treegraph
Reported: 2015-02-26 05:06 UTC by Octavio Alvarez
Modified: 2022-11-24 03:42 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Octavio Alvarez 2015-02-26 05:06:18 UTC
1. Open Calc.

2. Type 'screenshot' or some other word that gets recognized as mispelled. Make sure spelling detected 'screenshot' as a mispelled word by showing a red underline. (Language may be needed to be changed to English).

3. Double click on the column header boundary to set it to optimal width. To make it more annoying, further reduce the column width to make the word barely fit.

4. The user wants to format the cell using the context menu. Right click on the cell (not on a blank part, but on the word because it is part of the cell).

Expected behavior: The regular context menu appears. I should click 'Format cells' after the menu shows up.

What happens: The spell-fix context menu appears. No 'Format cells' option. Functionality is lost.

Recommendation: Both menus should be merged in this case. Spelling-fix menu entries should be appended to the regular context-menu, possibly under a 'Spelling >' submenu or possibly just after the regular context menu, but the point is that regular context menu entries should not be put away.

The same happens if the user hits F2, then highlights the word and right clicks on it to copy it: no copy option in the menu. This particular case gets more frequent for users that write proper foreign names in the worksheet, like teachers and employers.

Comment 1 raal 2015-02-26 06:04:57 UTC
I can confirm with Version:
Build ID: a2fa9e2468aa5c4fd4b610c5d0ebc8959e87a072
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-02-23_02:34:05

Looks like fixed in bug 74087 and appear again. Setting the same priority as in bug 74087
Comment 2 Robinson Tryon (qubit) 2015-03-05 16:42:19 UTC
Whiteboard -> bibisectRequest
Comment 3 Matthew Francis 2015-03-28 13:58:24 UTC
From the description I'm pretty sure the present behaviour is the intended result after the fix to bug 74087. That is to say, the point of bug 74087 was that the spelling entries should be shown only when the cursor is over a mis-spelled word, and not over a blank portion or other text of the cell.

However, this doesn't account for the case where there isn't any convenient blank part or other text in the cell, and the report in this bug (reasonably, I think) asks for there to be a way to use the regular menu options even in the case that this is so.

This specific problem as stated has existed since before LO, so I think this is properly not a regression
Comment 4 Katarina Behrens (Inactive) 2015-11-03 13:26:06 UTC
Not limited to Calc, Impress/Draw behaves the same -- as soon as there's a misspelled word, there's no way to access formatting entries from context menu. 

There must be some secret plan behind all this, to force users to spell words properly (and I wasn't even able to find this bugreport, because the word 'mispelled' is misspelled in its summary :P :D)
Comment 5 QA Administrators 2017-12-27 03:24:57 UTC Comment hidden (obsolete)
Comment 6 Octavio Alvarez 2017-12-28 18:04:36 UTC
The problem still exists under:

Build ID: 1:5.4.3-4
CPU threads: 4; OS: Linux 4.2; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.utf8); Calc: group
Comment 7 QA Administrators 2019-11-29 03:44:40 UTC Comment hidden (obsolete)
Comment 8 Roman Kuznetsov 2020-11-23 20:07:43 UTC
still repro in

Version: (x64)
Build ID: ccd0e5f445d4a7d0e7aca6c23c02c61bf14510b2
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL
Comment 9 QA Administrators 2022-11-24 03:42:11 UTC
Dear Octavio Alvarez,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team