Bug 54308 - Calc EDITING: drag&fill not working when select some cell and hold Ctrl
Summary: Calc EDITING: drag&fill not working when select some cell and hold Ctrl
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.3.4 release
Hardware: All All
: low minor
Assignee: Not Assigned
Depends on:
Blocks: AutoFill
  Show dependency treegraph
Reported: 2012-08-31 08:50 UTC by sasha.libreoffice
Modified: 2022-02-11 05:46 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

B1 selected first, Ctrl pressed before click (46.61 KB, image/jpeg)
2014-06-27 09:48 UTC, kloud

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2012-08-31 08:50:45 UTC
My goal this time was to fill several columns in Calc with the same values using drag and fill. For example column A with ones and column B with twos. But it not working as expected.

Steps to reproduce:
0. Start LO Calc
1. Enter 1 and 2 to A1 and B1
2. Select both A1 and B1
3. Press and hold Ctrl, drag by right hand bottom corner of cell B1
Expected: cells in column A filled by 1 and in B by 2
Actually: nothing happens

Workaround: repeat step 3 second time

Reproduced in 3.3.4, 3.6.1 on Fedora 64 bit
and in 3.5.0 on Windows XP 32 bit
Comment 1 Joel Madero 2012-10-14 21:57:29 UTC
Can't reproduce, marking as WORKSFORME. 

Version (Build ID: e29a214)

@Sasha - not sure why you're seeing this as I'm on the same version. What OS?
Comment 2 sasha.libreoffice 2012-10-15 05:55:36 UTC
today reproduced in 3.6.2 on Windows XP 32 bit
Comment 3 Joel Madero 2012-10-15 15:14:05 UTC
I'll try to find a second opinion on this one as I am completely unable to reproduce
Comment 4 m.a.riosv 2012-10-15 15:36:03 UTC
I can not reproduce.

Win7x64 Ultimate.

LibreOffice Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
LibreOffice Version (Build ID: f8fce0b)

Maybe a user profile reset can solve the issue.
Comment 5 Joel Madero 2012-10-15 15:39:30 UTC
Sasha - maybe localization problem? What locale are you using? I'll try to reproduce with same localization. Seems really strange that this would be a localization problem though
Comment 6 Niklas Johansson 2012-10-15 15:48:09 UTC
Interesting I can reproduce on Windows 7 64-bit (Swedish). But ONLY if i press down the Ctrl key before pressing down mouse button and start dragging. 

And as the reporter says it works the second time.

If I on the other hand start by pressing down the mouse button then Ctrl and start dragging it always seems to work for me.
Comment 7 Patrick Oltmann 2012-10-15 15:53:16 UTC
I can reproduce it and also observe the behavior reported by Niklas: When I first click (and hold) the right bottom corner, then press (and hold) CTRL and then drag, everything works as expected. On the other hand, when I first press and hold CTRL and then click and drag the right bottom corner I also observe this bug. 

Fedora 17 64 bit 
Locale: en-US
Comment 8 Joel Madero 2012-10-15 15:55:48 UTC
This is becoming more complicated than it looked at first :) I can't reproduce either by holding mouse button first or by using ctrl button first. 

Distro: Bodhi Linux

Thanks for marking as NEW, definitely confirmed at this point.
Comment 9 Niklas Johansson 2012-10-15 15:57:25 UTC
Forgot to mention that I reproduced it on LibreOffice with Swedish language pack.

Also reproduced it on LibreOffice (no language pack active) on Mac OS X 10.7.5.

And finally on LibreOffice 3.4.6 on a Windows XP machine.

And still the crucial thing is to press Ctrl (cmd on mac) before you press the mouse button.
Comment 10 Terrence Enger 2012-10-15 15:58:46 UTC
This is my first time using this feature, so take this comment for
what it is worth.

I observe that behaviour is different depending on whether the mouse
cursor is over the bottom right corner of B1 when you press <ctrl>.
With the cursor somewhere else, the program works as sasha expects.
With the cursor already in position, dragging the mouse cursof selects
either cells of column A only or cells of row 1 only, and nothing is

My LO is master commit id f1b6058, fetched 2012-10-13, configured ...


built and running on ubuntu-natty (11.04) ...

    $ uname -a
    Linux cougar-natty 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 18:00:43 UTC 2012 i686 athlon i386 GNU/Linux
    $ gcc --version
    gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
    Copyright (C) 2010 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO

Comment 11 Joel Madero 2012-10-15 16:02:07 UTC
That's the trick! I always had the cursor on the bottom right (seemed intuitive I guess to me ;) ). None the less, probably qualifies as a minor bug as it's not consistent behavior, also as a few other people were able to reproduce it so easily, it meant they were not assuming to go to bottom right corner first.

Thanks for the pointer Terrence, I can now confirm this is an issue
Comment 12 kloud 2014-06-27 09:48:42 UTC
Created attachment 101854 [details]
B1 selected first, Ctrl pressed before click
Comment 13 kloud 2014-06-27 10:10:09 UTC
This one is still present in 4.3 RC1 on XP and it can be distracting.

(In reply to comment #10)

With the cursor somewhere else, I still experience this issue. But I've learned, that if I select B1 before A1 it always works as it should, except the graphical border will only expand in the B-column.
Comment 14 QA Administrators 2015-07-18 17:43:09 UTC Comment hidden (obsolete)
Comment 15 Buovjaga 2015-10-17 13:24:08 UTC
Works for me in any way imaginable.


Win 7 Pro 64-bit Version:
Build ID: 186f32f63434e16ff5776251657f902d5808ed3d
TinderBox: Win-x86@39, Branch:master, Time: 2015-10-16_09:42:47
Locale: en-US (fi_FI)
Comment 16 QA Administrators 2016-11-08 11:23:31 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2020-09-28 03:55:51 UTC Comment hidden (obsolete, spam)
Comment 18 BogdanB 2021-07-31 08:31:34 UTC
Please retest in the newest versions.

Working well in
Version: / LibreOffice Community
Build ID: 5aa74aa1e6fac571f99146ebcb6adc9feb1459ad
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-28_19:35:14
Calc: threaded
Comment 19 QA Administrators 2022-01-28 03:58:35 UTC Comment hidden (obsolete, spam)
Comment 20 Justin L 2022-02-11 05:46:06 UTC
Two WORKSFORME and no opposing claims / response to NEEDINFO in 6 years. Closing.