Bug Hunting Session
Bug 99477 - EDITING: "View> Freeze Cells> Freeze First..." does not work if the sheet is already frozen
Summary: EDITING: "View> Freeze Cells> Freeze First..." does not work if the sheet is ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha1
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.0.0
Keywords: needsDevEval, topicUI
: 103338 (view as bug list)
Depends on:
Blocks: Split-Group-Buttons Cell-Freeze 91013
  Show dependency treegraph
 
Reported: 2016-04-24 12:17 UTC by pierre-yves samyn
Modified: 2019-03-09 03:42 UTC (History)
8 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 pierre-yves samyn 2016-04-24 12:17:10 UTC
Hi

Steps to reproduce:
1. File> New> Spreadsheet
2. Click anywhere in the sheet e.g. B3
3. View> Freeze Cells> Freeze First Column

Expected & Actual result: Col A frozen

4. View> Freeze Cells> Freeze First Row

Expected result: Col A unfrozen, Row 1 frozen
Actual result: Col A unfrozen

Of course same problem with Freeze First Row then Freeze First Column

Platform Windows 7/64 & Version: 5.2.0.0.alpha1 (x64)
Build ID: 902b28a39528b6c92602e9b521a1d0861be1caf9
CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; 
Locale: fr-FR (fr_FR)

Yousuf (Jay) Philips describes this in bug 91013, comment 16
I filled a new Issue because 91013 is about creating of the UNO commands

Regards
Pierre-Yves
Comment 1 Terrence Enger 2016-04-25 14:01:40 UTC
In daily Linux dbgutil bibisect version 2016-04-25, I see that View >
"Freeze Cells" offers three options ...
    ( ) Freeze Rows and Columns
    ( ) Freeze First Column
    ( ) Freeze First column
Each seems to work thusly:
  - If nothing is frozen, freeze as the option says.
  - Otherwise unfreeze.

It took me a minute to see what is happening, but the behaviour seems
somehwat logical.  And the bold "freeze lines" are visible in the
background around the menu and submenu, providing feedback about what
the program is doing.

But I am unusual in preferring to work with the keyboard.  The
spacebar invokes the highlighted submenu option and leaves the submenu
open, while clicking on the submenu option closes the view menu.  If
you are just clicking, it is a nuisance to go through the menus twice
to switch freezing from First Column to First Row.

On balance, I think it would be better to add a fourth submenu option,
"Unfreeze", so that each submenu option simply makes the state as the
words describe.  This makes all the functionality available with
fewer mouse clicks or with roughly the same number of keystrokes.
More importantly, the proposed behaviour is easier to describe.

How this would impact the toolbar button contemplated by bug 91013 I
do not know.  I am adding Yousuf (Jay) Phillips to cc.
Comment 2 Yousuf Philips (jay) (retired) 2016-04-25 16:03:46 UTC
I've mentioned this same issue in bug 91013 comment 16, but either Gulsah or Maxim replied to it.
Comment 3 Yousuf Philips (jay) (retired) 2016-10-19 21:04:10 UTC
*** Bug 103338 has been marked as a duplicate of this bug. ***
Comment 4 Eike Rathke 2017-06-30 08:32:41 UTC
I disagree about a part of the behaviour that change https://gerrit.libreoffice.org/39399 wants to introduce and the original poster claimed.

I do *not* expect to have a (first) frozen column unfrozen if I freeze the first row and vice versa. I expect the frozen column to stay and additionally freeze the first row.

I also expect that if one row or column is already frozen and "Freeze Rows and Columns" has a check mark then selecting that menu option unfreezes the row or column instead of changing the freeze to the current cursor position.
Comment 5 Gabor Kelemen 2017-06-30 12:17:46 UTC
(In reply to Eike Rathke from comment #4)
> I do *not* expect to have a (first) frozen column unfrozen if I freeze the
> first row and vice versa. I expect the frozen column to stay and
> additionally freeze the first row.
> 

Of course this can be debated. As there was no debate yet, I supposed just going ahead is fine.

Another angle to this discussion: Do we care what Excel does? Do we want to copy it 1:1 or do we want to figure out something better?

For comparison, my workplace Excel 2013 has the same three options as we do, they work like:

- Freeze Panes: freezes at an arbitrary position. The button changes into "Unfreeze Panes" and removes all freezes when clicked.
Selecting "Freeze Top Row" or "Freeze First Column" changes the arbitrarily placed freeze into a top row / first column freeze.

- Freeze Top Row: Freezes the first row. Selecting it again does nothing. 
The Freeze Panes button becomes "Unfreeze Panes" and removes all freezes when clicked. 
Selecting "Freeze First Column" switches to first column freeze.
- Freeze First Column: Freezes the first column. Selecting it again does nothing. 
The Freeze Panes button becomes "Unfreeze Panes" and removes all freezes when clicked. 
Selecting "Freeze Top Row" switches to first row freeze.
Comment 6 Yousuf Philips (jay) (retired) 2017-06-30 15:31:24 UTC
(In reply to Eike Rathke from comment #4)
> I do *not* expect to have a (first) frozen column unfrozen if I freeze the
> first row and vice versa. I expect the frozen column to stay and
> additionally freeze the first row.

The UNO commands were intended to be created in this fashion, without a checkbox/toggle type behaviour. If they did have a checkbox/toggle behaviour, then your expectation would make sense.

> I also expect that if one row or column is already frozen and "Freeze Rows
> and Columns" has a check mark then selecting that menu option unfreezes the
> row or column instead of changing the freeze to the current cursor position.

That is how it functions now and should be how it functions, or was someone trying to change it from this?
Comment 7 Gabor Kelemen 2017-07-01 12:03:15 UTC
(In reply to Yousuf Philips (jay) from comment #6)
> > I also expect that if one row or column is already frozen and "Freeze Rows
> > and Columns" has a check mark then selecting that menu option unfreezes the
> > row or column instead of changing the freeze to the current cursor position.
> 
> That is how it functions now and should be how it functions, or was someone
> trying to change it from this?

Yes, me here: 
https://gerrit.libreoffice.org/#/c/39399/

Maybe not the perfect solution for this bug. Opinions are welcome :).
Comment 8 Eike Rathke 2017-09-04 14:40:52 UTC
(In reply to Yousuf Philips (jay) from comment #6)
> (In reply to Eike Rathke from comment #4)
> > I do *not* expect to have a (first) frozen column unfrozen if I freeze the
> > first row and vice versa. I expect the frozen column to stay and
> > additionally freeze the first row.
> 
> The UNO commands were intended to be created in this fashion, without a
> checkbox/toggle type behaviour. If they did have a checkbox/toggle
> behaviour, then your expectation would make sense.
Enabling "Freeze First Column" or "Freeze First Row" they *do* check the "Freeze Rows and Columns" box, and giving the wording "Freeze ..." without any checkbox that's one more reason to expect that when selecting the other one the first one is not removed.

One can always remove any freeze with choosing the checked "Freeze Rows and Columns".
Comment 9 Eike Rathke 2017-09-04 17:22:47 UTC
This is my stab at it: https://gerrit.libreoffice.org/41908
Comment 10 Eike Rathke 2017-09-05 09:24:57 UTC
It's easy to remove an already existing column freeze if Freeze First Row is selected and vice versa if that is really wanted. It's odd for me, but.. if people want to mimic Excel.. I thought keeping the other freeze was easier for the inexperienced user. Just let's come to a conclusion.
Comment 11 Eike Rathke 2017-09-11 11:48:17 UTC
So, any comments on this? Any real case except "Excel does it this way" for removing an existing freeze when selecting Freeze First, instead of preserving the other axis? If not, I'll just push the change.
Comment 12 Yousuf Philips (jay) (retired) 2017-09-11 12:28:45 UTC
(In reply to Eike Rathke from comment #10)
> It's easy to remove an already existing column freeze if Freeze First Row is
> selected and vice versa if that is really wanted. It's odd for me, but.. if
> people want to mimic Excel.. I thought keeping the other freeze was easier
> for the inexperienced user. Just let's come to a conclusion.

Yes this is the wanted behaviour.

This is the logic it should have and i think your gerrit patch summary says the same thing.

if [.uno:FreezePanesFirstColumn] then
   Disable existing freeze if any
   Enable freeze of first column

else if [.uno:FreezePanesFirstRow] then
   Disable existing freeze if any
   Enable freeze of first row

else if [.uno:FreezePanes] then
   if [any cells are frozen] then
      Disable existing freeze
   else
      Enable freeze based on cursor
   end if
end if
Comment 13 Eike Rathke 2017-09-11 13:25:12 UTC
(In reply to Yousuf Philips (jay) from comment #12)
> This is the logic it should have and i think your gerrit patch summary says
> the same thing.
No, the current gerrit patch keeps an existing column freeze if Freeze First Row is chosen, and keeps an existing row freeze if Freeze First Column is chosen. Your flow removes any existing other freeze in these cases.
Comment 14 pierre-yves samyn 2017-09-11 14:56:11 UTC
Hi

(In reply to Eike Rathke from comment #11)
> So, any comments on this? 

My comment is... I fully share your comments.

The menu command announces that it will freeze the first row (column). There is no indication that it will unfreeze a line/col that may be frozen. The result is totally unexpected.

Best regards
Pierre-Yves
Comment 15 Yousuf Philips (jay) (retired) 2017-09-11 16:03:55 UTC
(In reply to Eike Rathke from comment #13)
> No, the current gerrit patch keeps an existing column freeze if Freeze First
> Row is chosen, and keeps an existing row freeze if Freeze First Column is
> chosen. Your flow removes any existing other freeze in these cases.

Well my flow is the behaviour in Excel and makes it easy for beginners who dont easily get how .uno:FreezePanes works (this has happened to me many times) to easily get what they wanted.

http://www.online-tech-tips.com/wp-content/uploads/2010/06/ExcelFreezePanesButton_thumb.png
Comment 16 Eike Rathke 2017-09-20 14:58:36 UTC
I'll push the mentioned commit that keeps an existing freeze on the other axis, maybe people can play with it in a daily build. As is, we seem to have two contradicting expectations how this feature should behave. As said it is easy to modify things to remove an existing freeze if that's really what we want.
Comment 17 Commit Notification 2017-09-20 14:59:28 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea572a4fc616721b2d77baf6242c48a371fdc489

Resolves: tdf#99477 freeze first col/row always set a freeze

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Xisco Faulí 2017-10-21 16:40:07 UTC
A polite ping to Eike Rathke: is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Thanks
Comment 19 bureautiquelibre 2017-10-26 14:10:24 UTC
Each of the command should set a freeze.

Personnaly I don't care if behavior is same as in Excel.

If it is, fine.

IMHO a Checkmark in the menu to reflect current state of freeze/unfreeze of 1st line and 1st column would be welcome.

Regards,
Eric
Comment 20 Heiko Tietze 2017-10-26 15:10:03 UTC
I would expect a toggle function, which also improves the menu. Like this

[x] First row
[ ] First col
-
[ ] From here (or another caption, but the terminology should make clear that "First row/col" are different)

If "[x] From here is checked", the other two will be unchecked and disabled. Clicking this item again, the selection unfreezes. 

"[ ] First row/col" toggles the first row/col independently (both can be on or off at the same time and do not depend on the other state).
Comment 21 Eike Rathke 2017-12-06 18:31:33 UTC
(In reply to Heiko Tietze from comment #20)
> If "[x] From here is checked", the other two will be unchecked and disabled.
Doesn't make sense to me. Why should the user be forced to first unfreeze the current state before being able to freeze a first row or column?

As is, selecting Freeze First Row now automatically unfreezes a different row freeze if any.

> "[ ] First row/col" toggles the first row/col independently (both can be on
> or off at the same time and do not depend on the other state).

That we almost have, just that unfreezing independently is not possible now, unfreeze works only on the checked "Freeze Rows and Columns" entry. The behaviour actually matches the current presence of toggle boxes.
Comment 22 Heiko Tietze 2017-12-07 16:09:55 UTC
(In reply to Eike Rathke from comment #21)
> (In reply to Heiko Tietze from comment #20)
> > If "[x] From here is checked", the other two will be unchecked and disabled.
> Doesn't make sense to me. Why should the user be forced to first unfreeze
> the current state before being able to freeze a first row or column?

Freezing "From here" don't work together with a frozen first row/col and therefore these two are unchecked _automatically_. 

> As is, selecting Freeze First Row now automatically unfreezes a different
> row freeze if any.

The only difference, so far, is the proper feedback via unsetting the checkbox.
Comment 23 Xisco Faulí 2018-03-08 11:39:13 UTC
Dear Eike Rathke,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 24 QA Administrators 2019-03-09 03:42:02 UTC
** 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