Description: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU 7.6.2-3 Calc: threaded When you select part of a column with merged cells, all columns that are part of the merged cell are selected. Steps to Reproduce: 1.open spreadsheet 2.merge a4:c4 3.select a2:a5 Actual Results: selected a2:c5 Expected Results: selected a2:a5 Reproducible: Always User Profile Reset: Yes Additional Info: This is probably the result of fixing bug 155796 and bug 128678.
can confirm with: Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Flatpak Calc: threaded but NOT with: Version: 7.4.7.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Debian package version: 4:7.4.7-1 Calc: threaded
Based on comment 1.
I was able to replicate this bug in Linux using this repository: https://bibisect.libreoffice.org/linux-64-7.6 More information on the commit that caused this bug here: https://git.libreoffice.org/core/commit/39aa1f6424390821579bfb6b6ba14e9ce11040ce Adding CC: Jaume Pujantell Information about the first version that caused this bug: Version: 7.6.1.0.0+ (X86_64) / LibreOffice Community Build ID: 39aa1f6424390821579bfb6b6ba14e9ce11040ce CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to kdub from comment #3) > I was able to replicate this bug in Linux using this repository: > https://bibisect.libreoffice.org/linux-64-7.6 > > More information on the commit that caused this bug here: > https://git.libreoffice.org/core/commit/ > 39aa1f6424390821579bfb6b6ba14e9ce11040ce Let's the commit from the master branch (24.2) as well: https://cgit.freedesktop.org/libreoffice/core/commit/?id=341029de72cf957b7bc7775e51544070d4a49874
Thinking about this, I'm not sure this should be considered a bug. There's a merged cell in the range, which means your selection isn't strictly within column A, but spans to column C. Excel also behaves the same way. Let's ask the UX team, can you please share your thoughts?
LibreOffice behaves exactly like MS Excel, at least on macOS. However, I can follow the idea that selecting b1:b5 should not add a1 and c5 if a2:c4 is merged (as you get it via ctrl).
(In reply to Aron Budea from comment #5) This seems like a bug to me, because it denies us the expressive potential of the selection. We can choose to select a 3x5 region covering the merged cell; and we can (try to) select 1x5 region, in one of 3 ways (left, middle, right). Why should all four user behaviors result in the same thing, while almost no mouse-down selection behavior can produce a selection of a1,a2,a3,merged-a4-through-c4,a5 ? As for Excel compatibility... perhaps a toggle for our compatibility options in Tools > Options?
Let's see if my understanding if correct: - When you merge A4 to C4, there's no A4 cell anymore, only A4:C4 range, - A range is a rectangular area of cells, - When you select cells using Shift, or hold the left mouse button and drag, you select a range. This implies once the cells are merged in the example, there is no A2:A5 range anymore, and the smallest range including A2:A5 (and consequently A4:C4) is A2:C5. I'm not arguing there shouldn't be a way to select the least amount of cells+ranges that come with selection of cells, it just won't be a range anymore, and it should be a separate way apart from range selection. (In reply to Eyal Rozenberg from comment #7) > This seems like a bug to me, because it denies us the expressive potential > of the selection. We can choose to select a 3x5 region covering the merged > cell; and we can (try to) select 1x5 region, in one of 3 ways (left, middle, > right). Why should all four user behaviors result in the same thing, while > almost no mouse-down selection behavior can produce a selection of > a1,a2,a3,merged-a4-through-c4,a5 ? I see no argument in this comment why the selection you're looking for shouldn't be done in a different way, perhaps would be good to think about that first, instead of fragmenting the behavior by adding a compatibility flag.
(In reply to Bigor from comment #0) > Expected Results: > selected a2:a5 Just click on any cell (so there is no "selected range"), then click on the upper-left "Name Box" and type-in "a2:a5" (without quotation marks). I am not sure about the consequences of applying any action to that selected a2:a5 range, considering that cell a4 is no longer just a4 alone. Now, while the selection itself is possible as I just mentioned, I agree with Aron in comment 5. I am not sure this should be considered a bug. FWIW, Calc already has some possibilities (on the individual cells that conform the merged area, a4:c4 in the example) that are not available in Excel (IIRC, but I cannot check it myself ATM). If you still need to perform actions on individual cells, them maybe they should not be really merged at all and the user should consider some alternative layout. Moreover, there are situations in which the current behavior is desired. Having said that, maybe the OP could provide some practical use-case where the request is more meaningful.
(In reply to Aron Budea from comment #8) > Let's see if my understanding if correct: > - When you merge A4 to C4, there's no A4 cell anymore, only A4:C4 range, I'm not sure that's exactly correct, but let's assume that's the case. > - A range is a rectangular area of cells, > - When you select cells using Shift, or hold the left mouse button and drag, > you select a range. That's the buggy behavior. When I hold down shift and use the cursor keys, I expect the next cell down from the highlighted cell to be selected. I do not expect to select "the minimum rectangular range containing the existing selection plus the next cell" .
(In reply to Eyal Rozenberg from comment #10) > (In reply to Aron Budea from comment #8) > > - When you merge A4 to C4, there's no A4 cell anymore, only A4:C4 range, > > I'm not sure that's exactly correct, but let's assume that's the case. If you enter A4 in the cell selector in the formula bar, it turns into A4:C4. > That's the buggy behavior. When I hold down shift and use the cursor keys, I > expect the next cell down from the highlighted cell to be selected. I do not > expect to select "the minimum rectangular range containing the existing > selection plus the next cell" . If you press and hold Shift, and press down arrow and right arrow, do you expect cells to be selected in an L shape, or in a rectangle? I assume you would expect the rectangle to be selected.
Created attachment 194268 [details] How a shift+down selection should look like with multiple rows with merged cells (In reply to Aron Budea from comment #11) > If you press and hold Shift, and press down arrow and right arrow, do you > expect cells to be selected in an L shape But of course it's the L shape! If I didn't press right or left, I definitely don't want cells to the right and left of my selection, on previous lines, to get selected - I just want an extension by 1 down. And more generally, see this attachment for what I expect to get when I start from the top cell and go down, in the presence of all sorts of merges.
(In reply to Eyal Rozenberg from comment #12) > But of course it's the L shape! Calc is behaving the same as any other spreadsheet tool. If you don't want a rectangular selection, then use [CTRL] in order to add the ranges you want selected. I already mentioned a way to select the range A1:A5 without selecting other cells that would be also selected by doing it by dragging the mouse or by arrow keys. A merged range of cells is no longer just an independent group of cells. They are related, and behaving almost (and for the most part) as a unit (except for some extra advantages that Calc provides which are not available in some other spreadsheet tools). IMHO, the initial problem of selecting a specific range only (A1:A5) without having the merged cells being selected too, has a solution. For most situations, the current behavior is broadly used and acceptable. For less-frequent needs, there are alternatives (for either selecting cells or for implementing a different layout). I don't see a good-enough reason to change the default behavior (which users have been using for several decades on every spreadsheet tool).
(In reply to ady from comment #13) > Calc is behaving the same as any other spreadsheet tool. No, it doesn't. That is, not in principle. We consider what other spreadsheet apps do, and then decide whether to adopt such behavior or not. Very often, we adopt; but also often - we don't, or not quite. > If you don't want a > rectangular selection, then use [CTRL] in order to add the ranges you want > selected. No. Ctrl is for a disjoint selection. When you want to select a contiguous sequence of cells, you use the Shift key. > A merged range of cells is no longer just an independent group of cells. > They are related, and behaving almost (and for the most part) as a unit > (except for some extra advantages that Calc provides which are not available > in some other spreadsheet tools). Which is why the entire merged cells are, and should be, selected when the otherwise single-column selection is made using the Shift. But - cells which have _not_ been merged should be unaffected, w.r.t. selection, when other cells, in other rows, have been merged.
(In reply to Eyal Rozenberg from comment #12) > (In reply to Aron Budea from comment #11) > > If you press and hold Shift, and press down arrow and right arrow, do you > > expect cells to be selected in an L shape > > But of course it's the L shape! It's never worked like that. We shouldn't change how Shift + selection using mouse / arrow works on a whim. Again, I'm all for having a mode that behaves the way you would like, but please leave Shift + selection as it is.
(In reply to Aron Budea from comment #15) > It's never worked like that. It's always worked like that, except for the buggy behavior when it comes to merged cells. If the behavior had been _consistent_, then you could make the "this is how it's always worked argument" > We shouldn't change how Shift + selection using > mouse / arrow works on a whim. The rationale for the change has been explained in multiple comments. The arguments against seem to be: 1. Generally prefer no-change in behavior to change. 2. Microsoft Office has the same behavior is we do right now. These two arguments are not without merit, but they are meta-arguments rather than concrete ones. I find they are trumped by the arguments for the change. That being said - this is a candidate for another MS Office compatibility toggle.
(In reply to Eyal Rozenberg from comment #16) > It's always worked like that, except for the buggy behavior when it comes to > merged cells. If the behavior had been _consistent_, then you could make the > "this is how it's always worked argument" Let me repeat: > (In reply to Aron Budea from comment #11) > > If you press and hold Shift, and press down arrow and right arrow, do you > > expect cells to be selected in an L shape > > But of course it's the L shape! Please test in any version you'd like, no need for merged cells, just plain old Shift + arrow key behavior: hold Shift, down arrow, then right arrow. It was never an L shape.
(In reply to Eyal Rozenberg from comment #14) > (In reply to ady from comment #13) > No. Ctrl is for a disjoint selection. When you want to select a contiguous > sequence of cells, you use the Shift key. I didn't want to get into the detailed steps; I assumed the intention of my words would be understood. 1. Click on a cell and drag the mouse to select an area. 2. Release the mouse button. The area is selected. 3. Press the [CTRL] key and repeat the mouse operation on another range of cells; they can be adjacent to the previously-selected area or not. Without pressing the [CTRL] key, the prior area would no longer remain selected. Again, the specific original problem of selecting A1:A4 is _solved_ by means of the Name Box. As for the L shape, I don't recall ever working like that with the keyboard, nor with the mouse, on any spreadsheet tool. As for the behavior when there are (partial) merged cells, my experience has always been like it is ATM on every spreadsheet tool I have used; and I have taken advantage of this behavior too. But maybe I am getting too old to remember.
(In reply to Aron Budea from comment #17) > > But of course it's the L shape! > Please test in any version you'd like, no need for merged cells, just plain > old Shift + arrow key behavior: hold Shift, down arrow, then right arrow. It > was never an L shape. It's a straight column-segment. Which becomes an L-shape if one of the cells on those line is wider than the column.
(In reply to ady from comment #18) > 3. Press the [CTRL] key and repeat the mouse operation on another range of > cells; they can be adjacent to the previously-selected area or not. Without > pressing the [CTRL] key, the prior area would no longer remain selected. I know what using Ctrl means, but this is avbout the behavior of Shoft. > Again, the specific original problem of selecting A1:A4 is _solved_ by means > of the Name Box. It's not solved. The user does not want to, nor should they need to, click on anything. They just perform a vertical selection using Shift and the down key, and what they get is a wide rectangle, which is not the expressed intent.
IMHO... (In reply to Bigor from comment #0) > Expected Results: > selected a2:a5 An alternative method to achieve that is already available: Name Box. As for the default behavior in this matter, I do not agree that it should be modified. If at some point some advance compatibility option for a different behavior is added for this, it would not really be Excel-compatible but rather any-other-spreadsheet-compatible, and the current behavior should still be the default. I am not against having alternatives. Calc lacks lots of features that cannot be achieved at all, and requires a lot of very important improvements that are really limiting users (including myself).
(In reply to Eyal Rozenberg from comment #19) > It's a straight column-segment. Which becomes an L-shape if one of the cells > on those line is wider than the column. It seems we're still stuck at identifying what a range selection is. Selecting with shift creates a range selection, and range selection extends to the encompassing rectangle. It cannot be a straight column segment with horizontal extensions where there are merged cells.
We discussed the topic in the design meeting. On the one hand, one can argue that a selection starts on top-left and goes to bottom-right. In case of merged cells it just includes the full area. In this regard we are compatible with Excel - actually even better since extending the selection beyond the merged cell we keep the narrow range. Reason for this is that a merged cell is just "covering" what is below and values are kept (unlike in case of Excel). However, it might be also reasonable to depict the actual selection and to not extend. Both methods would have benefits. A major blocker is the fact that disjoint cells cannot be selected, only ranges. As long this isn't possible we must not change the current behavior. Totally unclear why this should be a regression.
Besides, Bigor has not outlined a use case. Why do you need to change a well-established pattern?
(In reply to Aron Budea from comment #22) > (In reply to Eyal Rozenberg from comment #19) > > It's a straight column-segment. Which becomes an L-shape if one of the cells > > on those line is wider than the column. > It seems we're still stuck at identifying what a range selection is. > > Selecting with shift creates a range selection, That's the bug. That is, without merged cells, that's what it should do, but with merged cells, it should be something else; > and range selection extends > to the encompassing rectangle. It cannot be a straight column segment with > horizontal extensions where there are merged cells. It can't be the 1 column x several rows, because of the merge. And that's why despite the indication of the range, the resulting selection must be (IMHO) the set of all cell _incident_ upon the indicated range. By the way - our current behavior is actually _not_ what you describe. Because if one Shifts-down beyond the merged cells, the selection contracts again to only one column wide, and actually skips the merged cells.
Created attachment 194315 [details] Example file I want to highlight the third column and copy the phone numbers
(In reply to Bigor from comment #26) > Created attachment 194315 [details] > Example file > > I want to highlight the third column and copy the phone numbers Method 1: Click on the Column-C header. Copy. Click on cell H1. Paste. Method 2: Click on cell C4. Click on the Name box. Type-in C4:C10 and press [ENTER]. [CTRL]+[C]. Click on cell E4. [CTRL]+[V]. Side note: Here we show one advantage of Calc over other spreadsheet tools, as the resulting paste includes the content of cell C7 despite being merged. In other spreadsheet tools, there is no such thing as cell C7, but rather the merged cells A7:C7 working as a whole unit. Anyway, goal achieved.
Hi, I had some more ideas related to this bug, and the related bugs. So as per my understanding, a merged cell is the top left cell of the merge range, just covering the other cells (hiding them). This means that the data for the covered cells (covered by the top left cell) is also being stored in the sheet. Also since the merge cell is different form other cells, as it's dimensions are different form other cells, it adds friction when selection interacts with the merge cell rectangle. Some of the things like "I want to select this or that" don't work smoothly out of the box. And this is the standard behaviour across all the spreadsheet software available. I propose we go out of the box. So when dragging and selecting, we should show all the hidden cells as shadows, so that the selection/dragging becomes more intuitive and once the select/drag is over, we can just hide the shadows of the hidden cells, letting the top left cell cover the whole merge area. This would eliminate a whole lot of merge x selection bugs + would be more user friendly.
Created attachment 194390 [details] Pictorial representation of "cell shadows" for merged cells
(In reply to Sahil Gautam from comment #28) > Hi, I had some more ideas related to this bug, and the related bugs. So as > per my understanding, a merged cell is the top left cell of the merge range, > just covering the other cells (hiding them). Sort of. It were "the top left cell", period, then it should not be selected when a selection only involves columns other than the left one. The ambiguity regarding what and where the merged cell is cannot be perfectly settled; we can only try to minimize inconsistency, confusing and frustrated expectations - but they will not reach zero. There will always trade-offs. Let's take your proposal: > when dragging and selecting, > we should show all the hidden cells > as shadows, so that the selection/dragging becomes more intuitive and once > the select/drag > is over, we can just hide the shadows of the hidden cells, letting the top > left cell cover the whole merge area. Other than the visualization aspect, you're suggesting a third kind of selection logic - neither what we have now nor the logic I've suggested. With your logic, if I've merged A4:C4 and shift-select B2:B5 - I will actually not get the merged cell selected. Is this what I wanted? Perhaps that's debatable. But what if I just select the merged cell - clicking on what used to be B4? Is the merged cell selected? That's inconsistent what your selection logic; or is the B4 "underneath" it get selected? That's definitely not what the use expects. So, I don't think the consistency/usability trade-off you suggest with your proposal is the right thing to do. (And if I've misinterpreted your suggestion, please correct me.)
> But what if I just select the merged cell - clicking on > what used to be B4? Is the merged cell selected? That's inconsistent what > your selection logic; or is the B4 "underneath" it get selected? That's > definitely not what the use expects. Yes, you have a point. Even if I say "B4 will be selected ..." then the user might want to select all the cells in the merge range, and saying "select the cells explicitly" might not be the best solution. I will think over it, if I can come up with some other ideas.