I also observe this behavior on Mac OSX 10.6.8

LibreOffice 3.5.4.2 
Build ID: 165a79a-7059095-e13bb37-fef39a4-9503d18

Created attachment 63084 [details]
Crash report when using slide panel to move a slide

I think this crash might also be related, I've been using this version of LibreOffice for two days, and have crashed in the same manner (when trying to move pages around) at least three times.

I do not reproduce exactly this bug on MacOS X 10.7.3 with LibO 3.6beta1.
But,
when i try to change a slide order by drag and drop, the behaviour isn't the expected one.

1. Create 4 slides presentation
2. Press left mouse button on the first slide in left panel "Slides"
3. Move mouse to the down between slides 3 and 4
4. Release mouse button

Current result : 
Nothing happen, the slide hasn't move.
Graphically the ghost slide and animation to demonstrate where the slide will ordered doesn't appear.

Expected result :
Slide moved between slides 3 and 4
Animation show the futur state.


I've made a screen cast to see the behaviour.

Created attachment 63176 [details]
Bug move slide in Slides panel

(In reply to comment #3)
> I do not reproduce exactly this bug on MacOS X 10.7.3 with LibO 3.6beta1.
> But,
> when i try to change a slide order by drag and drop, the behaviour isn't the
> expected one.
> 
> 1. Create 4 slides presentation
> 2. Press left mouse button on the first slide in left panel "Slides"
> 3. Move mouse to the down between slides 3 and 4
> 4. Release mouse button
> 
> Current result : 
> Nothing happen, the slide hasn't move.
> Graphically the ghost slide and animation to demonstrate where the slide will
> ordered doesn't appear.
> 
> Expected result :
> Slide moved between slides 3 and 4
> Animation show the futur state.
> 
> 
> I've made a screen cast to see the behaviour.

Fabien,
If understood that right, this is what is described at the beginning of this bug.
ANY slide moved to a different position ends up being the first slide. So if you move the first slide, it will end up being the first slide.
Please confirm, that this is also happening with other slides than the first one.

REPRODUCIBLE with
* LibreOffice 3.5.4.2 (Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18)
* LibreOffice/LOdev 3.6.0beta1 (Build ID: 1f1cdd8)
both with German langpack installed, both on MacOS X 10.6.8 German UI (Intel).

Taking the original description together with comment #3 and comment #5, I can confirm that if I create a simple presentation with 4 slides (I will attach my sample file), sorting slides via drag and drop both
-- in the left panel labelled "Slides"
   or
-- in the slide sorter
does not work correctly.

The circumstances are exactly the same in both cases:
-- if I try to move the *1st* slide to any other position,
   most times nothing happens;
-- if I try to move *any* *other* slide to another position,
   either nothing happens
   or the moved slide is inserted before all other slides
   (becomes slide #1), regardless where I have dragged the slide to.
I say "most times", because the behaviour seems not to be 100% deterministic (there must be some variable I don't understand).

And sometimes (cf. comment #2), if I try to drag around slides for a while,
-- LibreOffice crashes (I will attach the log file);
   this crash seems to happen a bit more often with beta 1 than with 3.5.4;
   but the crash log indicates always exactly the same type of crash:
   the 1st line of the trace for thread 0 is always
     0 libsdlo.dylib 0x4325a126
       sd::slidesorter::model::PageDescriptor::GetPage() const + 6

Created attachment 63289 [details]
Test file for bug 51023

Created attachment 63290 [details]
Log file for crash which occured after some slide drag and drop

Can someone please test if this bug is reproducible
-- on Windows
-- on some Linux variant? Thank you very much in advance!

A more complete review with LibreOffice 3.5.4.2.

Given four slides numbered 1, 2, 3, 4, what allows 4 x 3 = 12 primary drag actions, I get the following results when dragging slides in the "Slide Sorter" view and/or in the "Slides" section of the main window (the results are identical):

1a) Dragging the 1st slide between slide 2 and 3: nothing happens
    (still 1, 2, 3, 4)
1b) Dragging the 1st slide between slide 3 and 4: nothing happens
    (still 1, 2, 3, 4)
1d) Dragging the 1st slide after the last slide: works
    (result: 2, 3, 4, 1)
2a) Dragging the 2nd slide before the 1st slide: works
    (result 2, 1, 3, 4)
2b) Dragging the 2nd slide between slide 3 and 4: 2 is inserted before 1
    (result 2, 1, 3, 4)
2c) Dragging the 2nd slide after the last slide: works
    (result 1, 3, 4, 2)
3a) Dragging the 3rd slide before the 1st slide: works
    (result 3, 1, 2, 4)
3b) Dragging the 3rd slide between slide 1 and 2: 3 is inserted before 1
    (result 3, 1, 2, 4)
3c) Dragging the 3rd slide after the last slide: works
    (result 1, 2, 4, 3)
4a) Dragging the last slide before the 1st one: works
    (result 4, 1, 2, 3)
4b) Dragging the last slide between slide 1 and 2: 4 is inserted before 1
    (result 4, 1, 2, 3)
4c) Dragging the last slide between slide 2 and 3: 4 is inserted before 1
    (result 4, 1, 2, 3)

Analysis:
A) moving a slide via drag and drop before the 1st slide or after the last slide works
B) moving a slide via drag and drop to any other position does NOT work, but inserts the moved slide before the 1st slide. In the special case when the moved slide is already the 1st slide itself, this means that nothing happens at all.

Created attachment 63300 [details]
Corrupted sample file, corrupted via a simple sequence of drag-and-drop actions

But the analysis given in my previous comment holds true only when I do single drag-and-drop actions, i.e. open my sample document (attachment 63289 [details]) before each step again and try only one step at once.

If I do several drag-and-drop actions one after another, I observe
a) crashes and 
b) data corruption.

I have not found yet a simple way to reproduce the crash with 100% reliability, but here is a simple sequence of drag-and-drop actions which leads to data corruption:
1) Open my sample file (attachment 63289 [details]) with LibreOffice 3.5.4.2 or 3.6beta 1
   and switch to the Slide Sorter.
   The order of the slides is first "1", "2", "3", "4".
2) Drag slide "2" after slide "3".
   The order of the slides is now   "2", "1", "3", "4" (wrong!).
3) Drag slide "1" (the 2nd one) after slide "3" (the third one).
   The order of the slides is again "1", "2", "3", "4" (wrong!)
4) Drag slide "2" after slide "3".
   The order of the slides is now   "2", "2", "3", "4": corruption!
Now we have two slides which look identical at the beginning of the slide show. The old slide "1" is gone.

And this is a serious and stable corruption, not only a drawing error: the double slide "2" is still present when I save, close and open the document again, and the old slide "1" is still missing.

Attached you find such a corrupted file which is the result of applying the given four steps to my sample file.

Some more hints and observations:

(a) There are some bug reports which could be related to this issue, especially for Linux, but I can't find any exact duplicates for now:
* bug 49543 just says that sorting slides via drag-and-drop does not work at all
* bug 46801 is the same (drag-and-drop does not work at all)
* bug 48101 speaks about "drag & drop of slides from another document"
* bug 42289 seems to speak about how many slides are visible in the slide sorter
  (if I understand it correctly).

(b) Updated summary according to previous comments.

(c) This bug is NOT REPRODUCIBLE with LibreOffice 3.4.6 (OOO340m1, Build:602), German langpack installed, on MacOS X 10.6.8 German (Intel).

-> The bug is new in 3.5.x, therefore added keyword "regression".

(d) This bug is NOT REPRODUCIBLE with LibreOffice 3.4.6, German langpack installed, on WinXP, therefore it seems to be a MacOS X only issue for now. (But someone else should still test Linux).

@Thorsten Behrens,
@Radek Doulik:

I insert your addresses into the CC list of this bug report because you are our Impress experts (and MacOS X expert, too, in the case of Thorsten). This bug seems to be limited to MacOS X for now, but it is nevertheless very important and urgent -- it makes sorting slides in Impress completely impossible, it leads to data corruption and even to crashes. Additionally, it is an regression introduced in LibreOffice 3.5.x.

I have done some extensive testing (see especially comment #10 and comment #11) to give you an exact description about when slide sorting works and when it doesn't, and what exactly happens when it doesn't work. I hope this helps a bit.

Now I ask you: please take a look at this issue. I know you have got much other things to do, but this is definitely a really critical bug, and should be placed high on your Impress priorities list.

Thank you very much in advance!

The real question is: when does the slide get corrupted; the trace is common as:

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0 sd::slidesorter::model::PageDescriptor::GetPage() const + 6
1 sd::slidesorter::controller::CurrentSlideManager::SetCurrentSlideAtXController(boost::shared_ptr<sd::slidesorter::model::PageDescriptor> const&) + 213
2 sd::slidesorter::controller::CurrentSlideManager::SwitchPageCallback(void*) + 63
3 Timer::Timeout() + 28
... from the mainloop ... 

I wonder if Linux versions have a similar trace. Most likely we need to run this under valgrind / drmemory to go back in time to when the corruption happened.

Also - a build with debugging symbols is always going to produce a better trace; I assume we have these for Mac, any chance you could try one if it's easy to reproduce ?

The comment in the relevant method doesn't fill one with confidence either:

IMPL_LINK_NOARG(CurrentSlideManager, SwitchPageCallback)
{
    if (mpCurrentSlide)
    {
        // Set current page.  At the moment we have to do this in two
        // different ways.  The UNO way is the preferable one but, alas,
        // it does not work always correctly (after some kinds of model
        // changes).  Therefore, we call DrawViewShell::SwitchPage(),
        // too.
        ViewShell* pViewShell = mrSlideSorter.GetViewShell();
        if (pViewShell==NULL || ! pViewShell->IsMainViewShell())
            SetCurrentSlideAtViewShellBase(mpCurrentSlide);
        SetCurrentSlideAtXController(mpCurrentSlide);
    }

    return 1;
}

(In reply to comment #14)
> Also - a build with debugging symbols is always going to produce a better
> trace; I assume we have these for Mac, any chance you could try one if it's
> easy to reproduce ?

I will be happy to do so -- but where can I get a Mac build with debugging symbols?

@Thorsten:
Can you explain me where to get a Mac build with debugging symbols?

*** Bug 51871 has been marked as a duplicate of this bug. ***

Created attachment 64604 [details]
Log fr crash after some slides drag’n’drop with Norbert's debug version of LibO 3.6.0.2+

(In reply to comment #14)
> Also - a build with debugging symbols is always going to produce a better
> trace; I assume we have these for Mac, any chance you could try one if it's
> easy to reproduce ?

@Michael Meeks
and other developers:
thanks to Norbert's debug version of LibO 3.6.0.2+, I have tested this again and hope that the attached log file for the crash helps to track down the issue. Again, the crash happened after I opened my simple sample file for this bug (attachment 63289 [details]) and dragged slides forth and back in the "Slides" panel (I did not use the "Slide sorter").


In addition, there are some very interesting messages in the _console_. After the first drag-and-drop action (slide 1 dragged after slide 4), the console printed 120 (!!!) times:

24.07.12 12:22:20	[0x0-0xa60a6].org.libreoffice.script[2081]	warn:legacy.osl:2081:1:/Volumes/Raid0/g_core/sd/source/ui/slidesorter/controller/SlsSelectionFunction.cxx:1848: OSL_ASSERT: mpDragAndDropContext

Every following drag action caused the same line to be printed again, each time, for about 100 times or so.

Finally, after the last drag-and-drop action, here are the last four lines which LibO printed to the console (the first one is the same as above, but the 2nd slightly differs, and the 3rd and the 4th one look very interesting):

24.07.12 12:25:52	[0x0-0xa60a6].org.libreoffice.script[2081]	warn:legacy.osl:2081:1:/Volumes/Raid0/g_core/sd/source/ui/slidesorter/controller/SlsSelectionFunction.cxx:1848: OSL_ASSERT: mpDragAndDropContext

24.07.12 12:25:53	[0x0-0xa60a6].org.libreoffice.script[2081]	warn:legacy.osl:2081:1:/Volumes/Raid0/g_core/sd/source/ui/slidesorter/controller/SlsCurrentSlideManager.cxx:247: OSL_ASSERT: rpDescriptor.get() != NULL

24.07.12 12:25:53	[0x0-0xa60a6].org.libreoffice.script[2081]	/Volumes/Raid0/g_core/solver/unxmacxi.pro/inc/boost/smart_ptr/shared_ptr.hpp:428: failed assertion `px != 0'

24.07.12 12:25:54	com.apple.launchd.peruser.501[98]	([0x0-0xa60a6].org.libreoffice.script[2081]) Job appears to have crashed: Abort trap
24.07.12 12:25:55	ReportCrash[2170]	Saved crash report for soffice[2081] version 3.6.0.2 (???) to /Users/eiselemalina/Library/Logs/DiagnosticReports/soffice_2012-07-24-122554_Kore.crash


Hope it helps to fix this issue!

Hi Roman - thanks so much for your work getting a trace with debugging symbols, however - I suspect you need to run soffice.bin under a debugger to get what we need out of those symbols. If they 'worked' I would expect to see detailed file + line-number information for each method in the call-trace; I suspect the generic crash app doesn't provide that.


Either way, this looks thankfully unrelated to the a11y problems though. Looks like a normal slideshow issue - where the cult of uncontrolled asynchronicity tends to lead to poorly lifecycle-managed callbacks - combined (ironically) with poor interactive performance ;-)

Thanks !

(In reply to comment #19)
> Hi Roman - thanks so much for your work getting a trace with debugging symbols,
> however - I suspect you need to run soffice.bin under a debugger to get what we
> need out of those symbols. If they 'worked' I would expect to see detailed file
> + line-number information for each method in the call-trace; I suspect the
> generic crash app doesn't provide that.

Good to know -- I would have expected much more detailed information myself, but thought that LibO just does not provide it. BTW: *Which* debugger would do the trick, and is there somewhere some kind of guidance *how* to run soffice.bin under that debugger (on MacOS X, of course)?

> Either way, this looks thankfully unrelated to the a11y problems though. Looks
> like a normal slideshow issue -

Good news! So I hope some developer, e.g. Thorsten, who is both a Impress and a MacOS X expert, will look into this issue soon?! ;-)

Issue still existent in 3.6 release.

- slide move animation doesn't show slide (frame), just a black sqare when moving a slide
- moved slide still always ends up being the first slide, 
exception:
 - when it is moved at the end of one row of slides and you move the cursor outside the slide sorter panel. Then the animation and placement works correkt for the last position in that row.

!!! 
- slide content of moved slide replaces the content of the slide where it is dropped.

Tested on openSUSE Linux (with openSUSE provided 3.6 packages): slide sorting is working as expected.

(In reply to comment #21)
> Issue still existent in 3.6 release.

Thank you very much for testing again! However, please do not "update" the Version field: the Version field should always contain the FIRST version which is known to contain the bug, and NOT the last one. Thank you ;-)

> Thank you very much for testing again! However, please do not "update"
> the Version field: the Version field should always contain the FIRST
> version which is known to contain the bug, and NOT the last one.

You know - I never understood how this policy works. How can you easily see a list of bugs that have been re-tested vs. a recent version to see if the issue is still there ? :-) but I guess I should ask on the mailing-list.

*** Bug 53628 has been marked as a duplicate of this bug. ***

This regression is nasty and a nogo for Impress. Working on presentations becomes impossible. Therefore I have increased the importance to highest.

The bug is still present in LO 3.6.1.2.

Mouse wheel scrolling is also not working - might be a related issue.

The latest version of OpenOffice.org (3.4.1) does not have this bug. Hence an ugly work-around is to open the presentation with OOo, rearrange the slides, and continue with LO. This is silly. 

Where is the download for LO 3.4??

The new bug report Bug 54580 – “Clicking Slide Thumbnail of Non-Focused Window Causes Rearrange/Crash” is nearly related to the present one (but NOT an exact duplicate, so please don’t mark bug 54580 as a duplicate for now, until we have more insight into the roots of both bugs!).

It contains of two parts:
1) “Clicking on a slide thumbnail in the left pane when LibreOffice does
   not have window focus causes the selected slide to shuffle to the top
   of the deck (become slide number one).”

IMHO this could be related to the broken drag-and-drop of slides in the present bug report; I mean, both issues could have the same underlying problem.

2) “Now that we have rearranged slides, we can click on the thumbnails for
   the two non-rearranged slides as many times as we want, but any attempts
   at clicking on the rearranged slide (slide 3 cum 1) will cause
   LibreOffice to crash.”

IMHO this is the same crash as the one reported in the present bug report, because the log files created for the crashes are all more or less identical.

So 1) seems nearly related to the present bug report, and 2) identical.

I would suggest to mark this bug as a blocker: Due to this bug, you cannot do a presentation in a productive environment  with Impress on a Mac as this time.

*** Bug 53249 has been marked as a duplicate of this bug. ***

(In reply to comment #29)
> *** Bug 53249 has been marked as a duplicate of this bug. ***

Note that 53249 has a test case attached which apparently also manifests on Linux.

(In reply to comment #30)
> Note that 53249 has a test case attached which apparently also manifests on
> Linux.

-> Therefore changed Platform to "All" (even if not reproducible on Windows, we need to use all, if reproducible both on Mac OS and Linux).

*** Bug 53621 has been marked as a duplicate of this bug. ***

Changed QA person just so that I can easily query. Hoping to get a fix committed soon. Thanks for the thorough bug report

*** Bug 53996 has been marked as a duplicate of this bug. ***

Added bibisectrequest, not sure whether that really will help, more for training of bibisecting staff ;-)

Please make 3.4.6 available again for download until this bug is resolved

(In reply to comment #36)
> Please make 3.4.6 available again for download until this bug is resolved

Please see
  http://downloadarchive.documentfoundation.org/libreoffice/old/
for *all* old LibreOffice versions, including 3.4.6.

Lifecycle 3.5 is terminated, so 3.5 MAB is no longer useful.
Comparing this one with other bugs this definitively is not a blocker.
This bug is rated as HardHack on <http://wiki.documentfoundation.org/HardHacks#Current_Hard_Hacks>, so let's hope the best

@Sergio Ballestrero:
<http://wiki.documentfoundation.org/BugReport#General_information> item 4
If yyou think <http://downloadarchive.documentfoundation.org/libreoffice/old/> should be mentioned more prominent in download hints please submit a separate WWW bug!

New research results:

This bug appears *first* in LibreOffice 3.5.4.1
(= RC1, build ID: 7306755-f4f605c-738527d-1cf4bc1-9930dc8).

It is *not* in LibreOffice 3.5.3.2
(Build ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80):
in all 3.5.x versions until and including 3.5.3.2, slide sorting still works (mostly ;-) correctly, both in the slide sorter and in the left panel, when I test with attachment 63289 [details].

So this bug was not (as I always wrongly assumed: sorry for not testing this earlier!) introduced somewhere in the 3.5 development process, but precisely between the branching of 3.5.3 and the first RC build of 3.5.4.1. This should it make much easier to find the root of this regression.


@ Thorsten Behrens, Rodo, Muthu Subramanian, and maybe others:

Could you please check the (not too lengthy) list of commits between the branching of 3.5.3 and the first RC of of 3.5.4.1? Somewhere there in the committs made to the 3.5/3.5.4 branch must be the root of this regression;
and if you can identify it there, it should be possible to fix it on the
3.6.x and Master branches.

Thank you very much!

Wow - Roman - that is some fantastic research ! thanks so much for narrowing it down so far :-) !

Created attachment 68794 [details]
git diff -u libreoffice-3.5.3.2..libreoffice-3.5.4.1 -- sd

The commit range indeed shows a change to the D&D code:

commit e4450c54aee85b295b933e91d207fd8220c01107
Author: Luboš Luňák <l.lunak@suse.cz>
Date:   Fri May 11 20:33:23 2012 +0200

    avoid recursion that can mess up DND setup (fdo#41996)
    
    The way too smart ctor for the DND handler started drag immediately,
    causing a race condition that could recurse to setting a handler
    again before the first one was actually set, thus immediately again
    causing the DND to be stopped, and then possibly later again started,
    depending on how the race condition turned out. Use delayed initialization
    to avoid this.

Lubos - rumour is that this hard-hack / MAB is nearby your fix for bug#41996.

Would a bibisect help?

> Would a bibisect help?

No - we already found the commit in question (assuming Roman's range is right - and it looks very plausible) - thanks ! now it's either fix that commit or revert it.

(In reply to comment #44)
> > Would a bibisect help?
> 
> No - we already found the commit in question (assuming Roman's range is
> right - and it looks very plausible) - thanks ! now it's either fix that
> commit or revert it.
Would a Valgrind trace help to understand why this commit gives this bug?
Perhaps the commit is ok in itself but triggers a buggy part of code.

(In reply to comment #44)
> No - we already found the commit in question (assuming Roman's range is
> right - and it looks very plausible)

I am quite sure about the range (and everybody can, at least on Mac OS X, check it himself/herself: just download 3.5.3.2 and 3.5.4.1 from
   http://downloadarchive.documentfoundation.org/libreoffice/old/
and test if you, like me, can reproduce the issue in 3.5.4.1, but not in 3.5.3.2).

The only little question which I, as a layman, see is if the problem was really caused (only) by commit e4450c54aee85b295b933e91d207fd8220c01107, or if another commit could be involved (too).

Of course, I don’t see any other commit in that range which could be involved (all other commits related to Impress look innocent, e.g. 009776a16410024a9437847af065d2160b434f30); but only a code expert can really judge this. So, if there are any doubts about the question if e4450c54aee85b295b933e91d207fd8220c01107 is really the (only) guilty one,
our Impress experts should check the list of all commits (ca.120?) in that range.

Has somebody actually built a version with the patch reverted to confirm it is really triggering the problem? The change should not have any other effects other than fixing the bug it fixed, so either it's not that, or something somewhere else is broken (race condition, whatever).

For what it's worth, I can't get any drag-and-drop to work, in Impress or Writer, in a master build on the Mac currently...

(In reply to comment #48)
> For what it's worth, I can't get any drag-and-drop to work, in Impress or
> Writer, in a master build on the Mac currently...

It works for me on Mac OS X 10.6.8 (Intel) with the master build
LOdev 3.7.0.0.alpha0+ (build ID: 370m0(Build:0); pull time: 2012-10-25 06:12:34)
from
   http://dev-builds.libreoffice.org/daily/MacOSX-Intel@27-OSX_10.7.0-gcc_4.2.1_llvm/master/

but only as well or as badly as reported here:
D&D of text snippets in Writer seems to work well;
D&D of slides in Impress works only partly (see commend #10),
and if I continue, the corruption happens (see comment #11).

Ha, I spoke too soon, it must have been some weird temporary glitch; simple d&d in Writer *does* work normally for me. And I indeed can reproduce the slide re-ordering problem. Will now try to see if reverting the patch helps.

Yes, after git revert e4450c54aee85b295b933e91d207fd8220c01107 drag-and-drop in the slide sorter seems to work fine... Over to Lubos;)

Looked into it with Lubos a bit and I now have a fair idea what to look for and where to debug... will do that in the coming days. (Lubos has no Mac.)

I debugged this during the flight home and found out the root cause to the problem (but not how to fix it): On the Mac, all the drag-and-drop action happens during the call to pSlideSorterViewShell->StartDrag() in the Initialize method. Thus no wonder that mpDragAndDropContext is null in the ProcessDragEvent() as it has not been initialized yet, and is in fact initialised only after the drag-and-drop already has finished.

I have a vague feeling that the same thing might happen on Windows, too, but will have to build me a fresh Windows build to verify. (I vaguely remember seeing something similar happening back in the days while working on the GTK port to Windows.)

(Nope, does not happen on Windows.)

New to LibreOffice (OpenOffice user for many years) I first posted this the other day in Ask LibreOffice.
"Using Version 3.6.2.2 (Build ID: da8c1e6) on a MacAir running Mac OS X Lion 10.7.5 I cannot re-organize Impress slides by any method described in Help: Slide Sorter, Slide pane in Outline, etc. Occasionally a slide will move but only to the front of the slide deck. Occasionally the moved slide will replace another one. Usually after enough attempts LibreOffice crashes."

I have now discovered the workaround posted: attempting to move a slide beyond the active window, then bringing it back into the window produces the thumbnail (which previously did not render). With the thumbnail visible I can drop the slide into position. This appears to work in Slide Sorter, or the Normal view also.

This is a copy of the Comment posted today for bug 41996 which seems to be superseded by this bug.

If you need more info I'm csettpiper@gmail.com

(In reply to comment #53)
> I debugged this during the flight home and found out the root cause to the
> problem (but not how to fix it): On the Mac, all the drag-and-drop action
> happens during the call to pSlideSorterViewShell->StartDrag() in the
> Initialize method. Thus no wonder that mpDragAndDropContext is null in the
> ProcessDragEvent() as it has not been initialized yet, and is in fact
> initialised only after the drag-and-drop already has finished.
> 
> I have a vague feeling that the same thing might happen on Windows, too, but
> will have to build me a fresh Windows build to verify. (I vaguely remember
> seeing something similar happening back in the days while working on the GTK
> port to Windows.)

(probably not the best way to report but that's the occasion:)
Now that this seems related to the drag and drop function on mac, there is another issue that has been annoying me on the mac version for quite a while (i.e. I think all 3.5 and 3.4 version are concerned):
one should wait a while (~1 second) when moving a border of any shape to have the proper behavior. Otherwise a click on the handle and move immediately, the complete object is moved.

Boudry: thanks for your input - but please -never- clutter a single focused bug with an unrelated issue - please file a new bug for your problem.

Tor - any cycles to debug this and/or get a stack trace from the constructor and Initialize methods on Mac so others can jump in ?

Thanks ! :-)

Michael: The core surprising point that Lubos's patch wasn't aware of was that all the drag-and-drop happens during the call to pSlideSorterViewShell->StartDrag(); that returns only after the whole drag-and-drop operation has finished.

For now, I fixed it in master by just reverting the patch for MacOSX only:

commit 192a0eb2beccee5349c3c7b60208aa95eb985f35
Author: Tor Lillqvist <tml@iki.fi>
Date:   Wed Nov 7 15:50:21 2012 +0200

    fdo51023: Revert e4450c54aee85b295b933e91d207fd8220c01107 for Mac OS X
    
    See bug for discussion. Basically, the root cause to the problem is
    that on the Mac, all the drag-and-drop action happens during the call
    to pSlideSorterViewShell->StartDrag() in the Initialize method. Thus
    no wonder that mpDragAndDropContext is null in the ProcessDragEvent()
    as it has not been initialized yet, and is in fact initialised
    pointlessly only after the drag-and-drop already has finished.
    
    Reverted just for Mac OS X and ifdefified in a straightforward even if
    ugly fashion.
    
    Change-Id: Icfb62fb24a5c72fda39c8bcea125267c99ecf624

 .../controller/SlsSelectionFunction.cxx            |   42 ++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)

Thanks Tor - should work for now - it'd be nice to cleanup the Mac abstraction in some deep future I imagine.

Pushed to -3-6...

VERIFIED as FIXED
with LOdev 4.0.0.0.alpha0+ (Build ID: 32315e; pull time: 2012-11-13 00:32:26)
on Mac OS X 10.6.8 (Intel):
sorting slides by drag and drop in the slide sorter and/or in the left panel labelled “Slides” now works again like in older LibreOffice versions; also the data corruption and crashes seem to be gone (at least I can no longer reproduce it by the simple steps listed in comment #11).

Thank you, Tor, Michael, et. all.!

*** Bug 57108 has been marked as a duplicate of this bug. ***

Some meta data cleanup:
tag “bibisectrequest” can be removed; added missing target:xxx tags; corrected Platform; assigned to Tor, who did the most important work for fixing this issue.

*** Bug 55624 has been marked as a duplicate of this bug. ***

*** Bug 56335 has been marked as a duplicate of this bug. ***

*** Bug 47465 has been marked as a duplicate of this bug. ***

target is 3.6.4, not 3.4.6 :-)