Created attachment 172351 [details] Proof of bug When selecting a space, the word and character count says "198 words, 1 character" instead of "0 words, 1 character". The 198 is the word count of the whole document. To reproduce: 1. Open any LO document 2. Select a space in the document 3. Look at the word and character count on the bar Attached is a picture of this bug in action.
I reproduced it in the following environment. I didn't know if this was a bug or intentionally. Version: 7.1.3.2 / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
I'm not sure why this would matter at all. What problem does this cause in the real world?
Code pointer: https://opengrok.libreoffice.org/xref/core/sw/source/uibase/uiview/view2.cxx?r=95c003d7#1575
Dear Jamie Douglass, 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 MassPing-UntouchedBug
I can confirm that this bug is still present in version 7.5.5.2 (x86_64), which is the latest version I can get through my package manager. I agree that this bug is not a huge issue, but it would be nice to have it fixed. From a quick looks, it seems like replacing these two lines: sal_uLong nWord = selectionStats.nWord ? selectionStats.nWord : documentStats.nWord; sal_uLong nChar = selectionStats.nChar ? selectionStats.nChar : documentStats.nChar; with the following two lines: sal_uLong nChar = selectionStats.nChar ? selectionStats.nChar : documentStats.nChar; sal_uLong nWord = (selectionStats.nWord + selectionStats.nChar) ? selectionStats.nWord : documentStats.nWord; would solve the issue. My question is: Is it worth investigating this issue, or just considering the information shown as a feature rather than a bug? Despite its inaccuracy, maybe it's more useful?
(In reply to Jamie Douglass from comment #5) > with the following two lines: > sal_uLong nChar = selectionStats.nChar ? selectionStats.nChar : > documentStats.nChar; > sal_uLong nWord = (selectionStats.nWord + selectionStats.nChar) ? > selectionStats.nWord : documentStats.nWord; > > would solve the issue. Indeed; and even simpler: the word count condition should only consider selected chars, not words, so the second line's condition should be the same as the first one's. Please don't hesitate to provide a fixing commit - we welcome contributions, and users who are interested that something is fixed do great things by actually fixing even small bugs. Please see https://www.libreoffice.org/community/developers/
(In reply to Mike Kaganski from comment #6) > (In reply to Jamie Douglass from comment #5) > > with the following two lines: > > sal_uLong nChar = selectionStats.nChar ? selectionStats.nChar : > > documentStats.nChar; > > sal_uLong nWord = (selectionStats.nWord + selectionStats.nChar) ? > > selectionStats.nWord : documentStats.nWord; > > > > would solve the issue. > > Indeed; and even simpler: the word count condition should only consider > selected chars, not words, so the second line's condition should be the same > as the first one's. > > Please don't hesitate to provide a fixing commit - we welcome contributions, > and users who are interested that something is fixed do great things by > actually fixing even small bugs. Please see > > https://www.libreoffice.org/community/developers/ Sadly, making this modification did not resolve this issue. I attempted making several modifications to that function, there was no change in the word count (or even the character count when I attempted to make them static numbers). I'm going to try passing my own SwDocStat object into the pWrdCnt object to see if that does anything, but other than that it appears that no changes to this function result in any change in the compiled writer application. Maybe I am doing something wrong? Maybe the function I am editing is the wrong function to be editing? I would be glad for any assistance
Make sure you work with FN_STAT_WORDCOUNT case in SwView::StateStatusLine (sw/source/uibase/uiview/view2.cxx).
(In reply to Mike Kaganski from comment #8) > Make sure you work with FN_STAT_WORDCOUNT case in SwView::StateStatusLine > (sw/source/uibase/uiview/view2.cxx). I have tested multiple changes to that file, some of them just to see if there even are any changes, and I have detected no changes in any of the work. Maybe it is my development environment, but it seems like that part of the code is just not used. The commented code is the code I have added for testing purposes: case FN_STAT_WORDCOUNT: { //SAL_DEBUG("Getting wordcount!"); SwDocStat selectionStats; SwDocStat documentStats; rShell.CountWords(selectionStats); documentStats = rShell.GetDoc()->getIDocumentStatistics().GetUpdatedDocStat( true /* complete-async */, false /* don't update fields */ ); sal_uLong nWord = selectionStats.nWord ? selectionStats.nWord : documentStats.nWord; //sal_uLong nWord = selectionStats.nChar ? selectionStats.nWord : documentStats.nWord; sal_uLong nChar = selectionStats.nChar ? selectionStats.nChar : documentStats.nChar; //TranslateId pResId = selectionStats.nChar ? STR_WORDCOUNT : STR_WORDCOUNT_NO_SELECTION; TranslateId pResId = selectionStats.nWord ? STR_WORDCOUNT : STR_WORDCOUNT_NO_SELECTION; TranslateNId pWordResId = selectionStats.nWord ? STR_WORDCOUNT_WORDARG : STR_WORDCOUNT_WORDARG_NO_SELECTION; //TranslateNId pWordResId = selectionStats.nChar ? STR_WORDCOUNT_WORDARG : STR_WORDCOUNT_WORDARG_NO_SELECTION; TranslateNId pCharResId = selectionStats.nChar ? STR_WORDCOUNT_CHARARG : STR_WORDCOUNT_CHARARG_NO_SELECTION; const LocaleDataWrapper& rLocaleData = Application::GetSettings().GetUILocaleDataWrapper(); //OUString aWordArg = SwResId(pWordResId, nWord).replaceAll("$1", rLocaleData.getNum(nWord, 0)); OUString aWordArg = SwResId(pWordResId, nWord).replaceAll("$1", rLocaleData.getNum(6, 0)); //OUString aCharArg = SwResId(pCharResId, nChar).replaceAll("$1", rLocaleData.getNum(nChar, 0)); OUString aCharArg = SwResId(pCharResId, nChar).replaceAll("$1", rLocaleData.getNum(6, 0)); OUString aWordCount(SwResId(pResId)); aWordCount = aWordCount.replaceAll("$1", aWordArg); aWordCount = aWordCount.replaceAll("$2", aCharArg); rSet.Put( SfxStringItem( FN_STAT_WORDCOUNT, aWordCount ) ); //rSet.Put( SfxStringItem( FN_STAT_WORDCOUNT, "Selection occurring!" ) ); SwPostItMgr* pPostItMgr = rShell.GetPostItMgr(); if (pPostItMgr) selectionStats.nComments = pPostItMgr->end() - pPostItMgr->begin(); SwWordCountWrapper *pWrdCnt = static_cast<SwWordCountWrapper*>(GetViewFrame().GetChildWindow(SwWordCountWrapper::GetChildWindowId())); //Debug SwDocStat SwDocStat debugStats = SwDocStat(); debugStats.nWord = 6; debugStats.nChar = 20; debugStats.nCharExcludingSpaces = 15; if (pWrdCnt){ pWrdCnt->SetCounts(selectionStats, documentStats); //pWrdCnt->SetCounts(selectionStats, debugStats); } } break;
(In reply to Jamie Douglass from comment #9) Which IDE / debugger do you use? Try putting the breakpoint to the code, and see if it gets called. I certainly did, before writing comment 8.
It's my bad. I realised that running "soffice --writer" in the build directory was running the version installed on my computer, not the development build. I can now see that all of my changes are having an impact. Please forgive me for this mistake, I am testing the original changes now
Jamie Douglass committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ef5aadffaefe47870f1e9472d7cdb8d37526c104 tdf#142494 Word count set to 0 when no words are selected. It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bug was fixed in a patch that was submitted on the 1st of January. Now marking as fixed. See https://gerrit.libreoffice.org/c/core/+/161509 for more information.