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
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Spreadsheet (show other bugs)
Version: 3.3.4 release
Hardware: All All
: low minor
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-31 08:50 UTC by sasha.libreoffice
Modified: 2014-06-27 10:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


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

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 3.6.1.2 (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 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
LibreOffice Version 3.6.3.1 (Build ID: f8fce0b)

Maybe a user profile reset can solve the issue.
http://wiki.documentfoundation.org/UserProfile
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. 

LibO 3.5.7.2 
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
LibO: 3.6.1.2

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 3.6.2.2 with Swedish language pack.

Also reproduced it on LibreOffice 3.5.6.2 (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
copied.


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

    --enable-symbols
    --enable-dbgutil
    --enable-crashdump
    --disable-build-mozilla
    --without-system-postgresql
    --enable-debug
    --enable-werror

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
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Terry.
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.