When LO is open, with no document open, opening a document by double-clic on his icon may take time, between 2 seconds and 1 minute. More strange, if we make an other click, the document opens immediately. And even if we move the mouse, the opening is quite immediate too. Sometimes the problem doesn't appear, but in most cases, we notice it Tested with LO 4.2.3.3 on Mac OOSX 10.9.2 on different macs
is this issue still happening? did you try resetting the user profile? see here: https://wiki.documentfoundation.org/UserProfile
I can not reproduce this problem with 4.2.3.3 OS X 10.9.2. Putting to NEEDINFO until we know more how the reset of the user profile did go.
I started with a fresh profile (i delete the one existing). So here what's happening : 1° i open LO, close the window "Centre de démarrage", no document open : when i first double-clic on a LO document, it takes really a long time, more than 15 min to open. 2° double-clic on a second document makes it open in 1 between 20 seconds. 3° i quit LO, and start again in point 1° : same behavior, it takes really a long time to open the first document by double-clic on it 4° i quit LO, and start again in point 1°, but without closing the window "Centre de démarrage" --> no problem, double-clic on a document makes it open quite immediately. So, the problem appears when LO is open, but the window "Centre de démarrage" is closed : in this case, opening documents by double-clic takes time, especially for the first document. Hoping that my explanations could help to resolve this bug Christian
I can confirm this, but for a long time thought I was just being impatient, however it happens regularly enough for me to be irritated by it.
It is also noticeable if LO is running in taskbar with no open documents, and one double-clicks on a document in the Finder to open it, where the Finder window is on a different screen to the one that LO was first opened on.
*** Bug 94560 has been marked as a duplicate of this bug. ***
*** Bug 94729 has been marked as a duplicate of this bug. ***
*** Bug 95632 has been marked as a duplicate of this bug. ***
*** Bug 96110 has been marked as a duplicate of this bug. ***
For me things are much worse using LO 5.1b1. Files never open when opened from spotlight on 10.11.1. adding regression keyword and raising importance since if LO does not open files which are opened in a standard way, this is a very serious problem.
http://dev-builds.libreoffice.org/daily/libreoffice-5-1/MacOSX-x86_64@49-TDF/current/ from today opens files from spotlight as expected. setting to WORKSFORME please re-open if you still experience this issue with builds newer than todays 5.1 build.
My latest test results with yesterday's LO Dev, fresh user profile: If LibreOfficeDev is NOT running, an .ods file will NOT open by: Double-clicking, Cmd O, or Cmd [Down arrow] neither from: Finder, Spotlight, or Desktop alias. ... until I move the mouse cursor or press a key (even Shift key works). If I keep pressing the Cmd key when launching the file with Cmd O or Cmd Down, the file will not load until I release the Cmd key. If LibreOfficeDev IS running, the file will open instantaneously with all methods mentioned above. A few times I did get an .xls file to open normally from Finder, both by double-clicking and the mentioned keyboard shortcuts! After I succesfully launched an .xls file and quit LO Dev, the .ods file also launched normally with Cmd O and Cmd Down from Finder. But if I double-clicked the .ods file, it no longer launched, and we were back to square one. However, I can no longer get the .xls to open normally either. LibreOffice Dev -> About: Version: 5.1.0.1.0+ Build ID: 02c113a3ab57d7880bb1f794e192fb42aea078e1 CPU Threads: 4; OS Version: -; UI Render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:libreoffice-5-1, Time: 2015-12-28_15:20:39 Locale: en-US (en.UTF-8)
*** Bug 96898 has been marked as a duplicate of this bug. ***
Still current and reproducible in Version: 5.2.0.0.alpha0+ Build ID: d373cb7e15ceca249c33be39583a0515b413e417 CPU Threads: 2; OS Version: -; UI Render: default; Locale : fr-FR (fr.UTF-8)
*** Bug 98635 has been marked as a duplicate of this bug. ***
*** Bug 97403 has been marked as a duplicate of this bug. ***
*** Bug 98892 has been marked as a duplicate of this bug. ***
Still current and reproducible. Steps to reproduce: 1. LO not open 2. Double-click a Calc document, control-click Calc document and select Open with LibreOffice, or open a Calc document from Spotlight. Expected Behavior: LO launches and displays document in window Observed Behavior: LO launches, but document window is not displayed until there is mouse movement or a key pressed. If LO is already open, the expected behavior IS observed. This bug only appears when LO is not currently open. LO Version: 5.0.5.2 Build ID: 55b006a02d247b5f7215fc6ea0fde844b30035b3 Locale: en-US (en.UTF-8) Apple OS X System Version: OS X 10.11.4 (15E65) Kernel Version: Darwin 15.4.0
Still current. Happens just the same in stable 5.1.3.2, 5.1.4 and the latest daily snapshot from yesterday (5th Aug): LibreOffice_5.1.3.2_MacOS_x86-64.dmg LibreOffice_5.1.4_MacOS_x86-64.dmg master-2016-08-05_23.35.15_LibreOfficeDev_5.3.0.0.alpha0_MacOS_x86-64.dmg This bug report has been active for 2 years, 3 months and 2 weeks.
Still current and happening in LibreOffice 5.2.0.4.
*** Bug 103660 has been marked as a duplicate of this bug. ***
macOS 10.12.1 + LO Version: 5.3.0.0.alpha1+ Build ID: 3950166877bf1308f9e449992e20b558342af825 CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; Layout Engine: old; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-11-01_00:39:01 Locale: de-DE (de_DE.UTF-8); Calc: group still happening. LO closed, double click LO file currently: nothing (until mouse is moved) expected: file should open
forgot: tested w OpenDocument Text file
Tested with Master of today, problem exist for at least writer/calc/impress. It seems the document is actually loaded, but the main window never gets displayed, until a mouse event triggers a repaint (or at least so it seems, did not run it in the debugger).
A link to terminal output SAL_LOG+INFO+WARN with corresponding screen recording for this bug: https://drive.google.com/open?id=0B7DezVIXHrQOTzF3Y1J5MHVpc1E Created with LO Version: 5.3.0.0.alpha0+ Build ID: a9afa89e953f0f32acf26b143717e7d067cbc75a CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-10-13_05:13:57 Locale: en-US (en_NL.UTF-8); Calc: group It has something to do with a waitCondition: 34.720:info:sal.osl.condition:1667:6:sal/osl/unx/conditn.cxx:177: osl_waitCondition(0x7fd13ca974f0) 44.722:info:sal.osl.condition:1667:6:sal/osl/unx/conditn.cxx:177: osl_waitCondition(0x7fd13ca974f0) 71.620:info:sal.osl.condition:1667:1:sal/osl/unx/conditn.cxx:132: [On mouse movement]
*** Bug 107066 has been marked as a duplicate of this bug. ***
Probable cause and example of code which could be customized to fix copied here from duplicate bug 107066. This bug is likely due to the code not using a delegate to initiate the application. Example of a delegate: #import "AppDelegate.h" #import "yourapp.h" @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { // Insert code here to initialize your application [_window setAlphaValue:1.00]; //etc. as needed } - (void)applicationDidBecomeActive:(NSNotification *)aNotification { [_window setAlphaValue:1.00]; } - (void)applicationDidResignActive:(NSNotification *)aNotification { [_window setAlphaValue: _controller.alphaState]; } - (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender { return NSTerminateNow; //NSTerminateCancel } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)theApplication { return YES; } @end
Issue still reproducible on OS X. From the About dialog: Version: 5.3.4.1 Build ID: 1b1606c6e1203cdc3fd5ffbc16e74ecea300241a CPU Threads: 8; OS Version: Mac OS X 10.11.6; UI Render: GL; Layout Engine: new Disabling GL doesn't change anything.
*** Bug 111001 has been marked as a duplicate of this bug. ***
*** Bug 111693 has been marked as a duplicate of this bug. ***
The issue still present on macOS 10.12.6 for LO 5.4.1.2 with or without GL rendering.
Repro with: Version: 6.0.0.0.alpha0+ Build ID: f95e7ef38e0bf79fa9662bfd50de612d50ef71de CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-09-22_12:57:48 Locale: nl-NL (nl_NL.UTF-8); Calc: grou
Reproducible on: Version: 5.4.4.2 Build ID: 2524958677847fb3bb44820e40380acbe820f960 CPU threads: 8; OS: Mac OS X 10.12.6; UI render: GL Disabling GL doesn't change anything.
Created attachment 142227 [details] Log file excerpt with comments Can reproduce. I have LibreOffice running, no window open (not even Start Centre). In tan idle state, every ten seconds some timer fires in LO and it prints a handful of SAL_INFO lines (and some SAL_DEBUG ones I added). When I then double-click on a file associated to that LO installation (but don't do anything else, don't move the mouse (I actually a Trackpad, not a mouse), a few lines are printed right away, but nothing "interesting" happens until the ten-second timer fires again. Only then it starts opening the file etc.
Suggested fix at https://gerrit.libreoffice.org/#/c/54643/
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=059872b47ed957e847a3fe63bd35793ba93c4c32 tdf#77444: Call TriggerUserEventProcessing() in a few key places It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Edited title to match initial description (and the behaviour that was fixed).
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=158da8687f043dd5e38dce4e9c3a79c314d507e1 tdf#77444: Follow-up fix: Guard against GetSalData()->mpInstance being null It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=31c12e0b19edad32d1ae2aea4f8923056dff594e&h=libreoffice-6-1 tdf#77444: Follow-up fix: Guard against GetSalData()->mpInstance being null It will be available in 6.1.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.