Created attachment 72167 [details] bug presentation Problem description: 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. Current behavior: It copies/moves data from one column to another Expected behavior: data should not move from column to another column .. Operating System: Ubuntu Version: 4.1.0.0.alpha0+ Master
Thanks for reporting Can reproduce with LO 4.1.0.0.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: 4.0.0.0.beta2 (Bouw-id: 4104d660979c57e1160b5135634f732918460a0) TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0, Time: 2012-12-18_17:13:13 4.0.0.0.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 3.6.4.3 (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 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b WORKAROUND: first insert -> manual brake... -> column break
I can confirm this on 3.6.3.2 as well as on Version 4.1.0.0.alpha0+ (Build ID: 53a5bf7529255e59d63645ee6a453ed56df39a9). Marking as NEW and prioritizing: NEW (Confirmed) 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. Kind regards, Joren
my mistake: @reporter - I see you didn't prioritize it, Joren and I have discussed the bug and the rationale behind the prioritization :)
Reproducible with LO 4.3.2.2 (Win 8.1)
*** This bug has been marked as a duplicate of bug 54465 ***