Bug 133144 - ui: editing: sort: <data - sort - options - left to right (sort columns)> proposes wrong row as sort criteria
Summary: ui: editing: sort: <data - sort - options - left to right (sort columns)> pro...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.8.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Sorting
  Show dependency treegraph
 
Reported: 2020-05-18 10:05 UTC by b.
Modified: 2023-02-18 03:24 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description b. 2020-05-18 10:05:09 UTC
Description:
very small oddity, stumbled upon it while investigating car filter(*1) curiosities ... 
(*1) - sorry, deepl, should read 'autofilter', left it in to spread some smile

<menu - data - sort> normally proposes the actual column as sort criteria and has 'top to bottom (sort rows)' selected in the options tab, 

when you change this to 'left to right (sort columns)' - don't hit enter! - and switch back to the 'sort criteria' tab, one would expect the row of the actual - focus - cell as row-proposal, 

if the focus is not on a diagonal top-left - down-right line of cells through the selected range you get something else, imho 'mirrored' at that diagonal line, 

might be that in this stage something is messed between 'ByRow' and 'ByColumn' interpretation as suspected in #132488

Steps to Reproduce:
1. fill A1:C3 with any data, 
2. click A3, 
3. <menu - data - sort> 
4. see 'column A' proposed as sort criteria, 
5. click tab 'options', 
6. select 'left to right (sort columns)', don't hit enter or click ok, 
7. click tab 'sort criteria', 
8. see 'row 1' proposed as sort criteria, 

Actual Results:
proposed a row different from that of the cell in focus, 

Expected Results:
propose row 3 as the row of the focus cell, 


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.0.0.0.alpha1 (x64)
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI: en-US
Calc: threaded

most likely the bug is older, I have not tested it yet
Comment 1 Ming Hua 2020-05-18 13:02:42 UTC
Reproduced in 6.2.8:
Version: 6.2.8.2 (x64)
Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee
CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: zh-CN (zh_CN); UI-Language: en-US
Calc: threaded

Indeed it seems to just blindly remember the column index and use it for the rows when sorting direction is switched.  If one uses A1:D4 range which is asymmetric, and starts with D1 cell selected instead of A3, the "sort criteria" tab will just have a blank "sort key 1", presumably becaused it wants to use "row 4" but can't.
Comment 2 Andreas Heinisch 2021-02-17 17:55:12 UTC
I tested the behaviour and I think this is just soley a bug.

First of all, LO proposes a column and saves your decision. Then, if you change the tab and select 'left to right (sort columns)', how could LO react?

I see here two options: either reset the entire sort dialog (so the row of the focus will be correctly set) or change just the labels of the sort options, because maybe you have already updated some of them.

In the first approach, you maybe lose your sort options, but it is consistent. In the second approach, if you already made some updates, you keep your sorting options, but have the above behaviour.

Maybe the QA could make some comments on this.
Comment 3 QA Administrators 2023-02-18 03:24:13 UTC
Dear b.,

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