Created attachment 72167 [details]
when we create text document with section having two columns and both columns are filled with data.. so when we insert the footnote/Endnote it copies data from one column to another one.
Steps to reproduce:
1. Open new Writer-Document
2. Click on Insert > Section > Columns. Select 2 Columns.
3. insert text into both columns.Click on Insert.
3. Put the cursor into the created section. Click on Insert > Footnote/Endnote. Click OK.
It copies/moves data from one column to another
data should not move from column to another column ..
Operating System: Ubuntu
Version: 220.127.116.11.alpha0+ Master
Thanks for reporting
Can reproduce with LO 18.104.22.168.alpha0+ (Build ID: 699132c269a6c6d9e815fc582e2e6a106e46923)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-27_01:05:51
With Mac OS X -> not linux only -> platforms 'all'
Also REPRODUCIBLE with:
22.214.171.124.beta2 (Bouw-id: 4104d660979c57e1160b5135634f732918460a0)
TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0, Time: 2012-12-18_17:13:13
126.96.36.199.beta1+ (Build ID: f4a1520c58f8bbbaf5027222c071374afb55961)
TinderBox: MacOSX-Intel@27-OSX_10.7.0-gcc_4.2.1_llvm, Branch:libreoffice-4-0, Time: 2012-12-16_21:58:26
Version 188.8.131.52 (Build ID: 2ef5aff) -> set Libreoffice bug version to this version.
Following the 'Prioritizing bugs flowchart (https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg)' I set importance to HIGHEST and BLOCKER.
Can't find any duplicate/relevant bugs so far.
Also reproducable using LibreOffice 184.108.40.206
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
WORKAROUND: first insert -> manual brake... -> column break
I can confirm this on 220.127.116.11 as well as on Version 18.104.22.168.alpha0+ (Build ID: 53a5bf7529255e59d63645ee6a453ed56df39a9).
Marking as NEW and prioritizing:
Normal (can prevent high quality work for some users)
Low (only happens if using columns in a specific way -- sections -- as well as using footnotes, both are not common for the largest percentage of our users)
Joren - thanks for the workaround, this makes it even more obvious that it is low priority since there is a workaround
@reporter - please be careful about over prioritizing your bugs, a blocker implies a major bug which results in data loss, crashes, memory loss, etc...that affects a substantial percentage of our users. Over prioritizing can delay the speed at which your bug is handled.
(In reply to comment #3)
> @reporter - please be careful about over prioritizing your bugs, a blocker
> implies a major bug which results in data loss, crashes, memory loss,
> etc...that affects a substantial percentage of our users. Over prioritizing
> can delay the speed at which your bug is handled.
I did that :-), not the reporter. That's why I forwarded this bug to check if I made the correct decision. But afterwards it wasn't ;-). I'll keep that in mind.
@reporter - I see you didn't prioritize it, Joren and I have discussed the bug and the rationale behind the prioritization :)
Reproducible with LO 22.214.171.124 (Win 8.1)
*** This bug has been marked as a duplicate of bug 54465 ***