[REVIEW] fdo#43989 first launch terminates after splash

[Stephan Bergmann]

On 06/11/2012 05:47 PM, Korrawit Pruegsanusak wrote:
> I'd like to propose Stephan's patch into stable branch:
>
> * http://cgit.freedesktop.org/libreoffice/core/commit/?id=55836370ffb70a34b888f81cdacdfede8fee29cf
> This fixed fdo#43989, which is 3.5 MAB, but we already have Andras'
> 8783ead70cc2bc2a83bf473b0dfb51f3ee10b6da backported, so I'm not sure
> whether we should have Stephan's patch backported too.
>
> Also, from the commit message, Stephan committed new fix for
> bnc#524250 at b5ad981518f4407243f89507b2561dd0b1ef28ee. Should this
> patch backported as well?

 From #libreoffice-dev backlogs:

> Jun 07 11:22:35 <sberg>	timar, tml_, I'm unsure whether we want 55836370ffb70a34b888f81cdacdfede8fee29cf (and maybe b5ad981518f4407243f89507b2561dd0b1ef28ee, too) in -3-6 or even -3-5; without them, we'll keep the behavior on Windows that there is no automatic restart (is this by now considered a feature, or rather a bug?) but also that LO only starts upon second attempt "sporadically" (i.e., when syncing with bundled/shared extensions needs to be done, after
> Jun 07 11:22:35 <sberg>	those have changed in some way)
> Jun 07 11:22:37 <IZBot>	no match found - might try http://cgit.freedesktop.org/libreoffice/core/commit/?id=55836370ffb70a34b888f81cdacdfede8fee29cf in a couple of minutes
> Jun 07 11:23:03 <sberg>	s/no automatic restart/no automatic restart *after crash*/
> Jun 07 11:42:46 <timar>	sberg: and what about, if we restarted only after E_NORMAL_RESTART, and not after crash?
> Jun 07 11:49:06 <sberg>	timar, one could fiddle something like that into -3-6 etc., sure; but I would keep it simple -- either backport wholesale, or live with the current situation on -3-6 etc., which should be ~ok after your fix for fdo#43989
> Jun 07 11:49:10 <IZBot>	LibreOffice-UI normal/medium RESOLVED FIXED After installation first launch terminates after splash screen https://bugs.freedesktop.org/show_bug.cgi?id=43989

My take is that b5ad981518f4407243f89507b2561dd0b1ef28ee isn't entirely 
trivial (there is that curious distinction between bExistsRecoveryData 
and bExistsSessionData in that code...), but backporting 
55836370ffb70a34b888f81cdacdfede8fee29cf without 
b5ad981518f4407243f89507b2561dd0b1ef28ee wouldn't be ideal, either.

Stephan