Community
Participate
Working Groups
The relevant part of the stack trace is: at org.eclipse.xtext.ui.guice.AbstractGuiceAwareExecutableExtensionFactory.create(AbstractGuiceAwareExecutableExtensionFactory.java:51) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:262) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55) at org.eclipse.ui.internal.handlers.HandlerProxy.loadHandler(HandlerProxy.java:350) at org.eclipse.ui.internal.handlers.HandlerProxy.setEnabled(HandlerProxy.java:231) at org.eclipse.ui.internal.handlers.E4HandlerProxy.setEnabled(E4HandlerProxy.java:127) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:305) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:239) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132) at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.setEnabled(HandlerServiceHandler.java:80) at org.eclipse.core.commands.Command.setEnabled(Command.java:862) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.canExecute(HandlerServiceImpl.java:179) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.canExecute(HandlerServiceImpl.java:165) at org.eclipse.ui.internal.quickaccess.CommandProvider.getElements(CommandProvider.java:80) at org.eclipse.ui.internal.quickaccess.CommandProvider.getElementForId(CommandProvider.java:63) at org.eclipse.ui.internal.quickaccess.SearchField.restoreDialog(SearchField.java:612) at org.eclipse.ui.internal.quickaccess.SearchField.createControls(SearchField.java:170) This usually takes half a second in our product, so its not so dramatic. On one particular occurrence though, this took a minute due to xtext bundle loading (org.eclipse.xtext.ui.guice.AbstractGuiceAwareExecutableExtensionFactory contacts plug-in activators). It would be great if the above is done *only* for previous choices of the user, and not for *all* commands in the product. Seen with e.g.: Eclipse SDK Version: Photon (4.8) Build id: I20180531-0700
This isn't minor, because loading *not used* command handlers should be avoided especially *if they plugins aren't loaded yet* => not only this slows down the startup of bigger installations, this can trigger blocking operations *directly on UI thread*, leading to timeouts on startup and to deadlock in worst case. Note, that the original stack contained this error, where the result was that org.eclipse.xtext.ui.shared.SharedStateModule was not properly initialized. Same (or worse) can happen with any other bundle, and the result for the user can be horrible! Additionally this is adding an extra big pile of random startup failures we might see without any idea how to reproduce, just because we don't know what user did *in the previous* session with the CTRL+3 dialog. !ENTRY org.eclipse.osgi 2 0 2018-01-05 16:08:07.980 !MESSAGE While loading class "org.eclipse.xtext.ui.shared.SharedStateModule", thread "Thread[main,6,main]" timed out waiting (5000ms) for thread "Thread[Worker-4,5,main]" to finish starting bundle "org.eclipse.xtext.ui.shared_2.10.0.v201605250459 [516]". To avoid deadlock, thread "Thread[main,6,main]" is proceeding but "org.eclipse.xtext.ui.shared.SharedStateModule" may not be fully initialized. !STACK 0 org.osgi.framework.BundleException: Unable to acquire the state change lock for the module: osgi.identity; osgi.identity="org.eclipse.xtext.ui.shared"; type="osgi.bundle"; version:Version="2.10.0.v201605250459"; singleton:="true" [id=516] STARTED [STARTED] at org.eclipse.osgi.container.Module.lockStateChange(Module.java:337) at org.eclipse.osgi.container.Module.start(Module.java:401) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468) at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:103) at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:529) at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:368) at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:442) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at com.advantest.itee.tpl.ui.internal.TplActivator.getSharedStateModule(TplActivator.java:92) at com.advantest.itee.tpl.ui.internal.TplActivator.createInjector(TplActivator.java:64) at com.advantest.itee.tpl.ui.internal.TplActivator.getInjector(TplActivator.java:55) at com.advantest.itee.tpl.ui.TplExecutableExtensionFactory.getInjector(TplExecutableExtensionFactory.java:26) at org.eclipse.xtext.ui.guice.AbstractGuiceAwareExecutableExtensionFactory.create(AbstractGuiceAwareExecutableExtensionFactory.java:51) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:262) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55) at org.eclipse.ui.internal.handlers.HandlerProxy.loadHandler(HandlerProxy.java:350) at org.eclipse.ui.internal.handlers.HandlerProxy.setEnabled(HandlerProxy.java:231) at org.eclipse.ui.internal.handlers.E4HandlerProxy.setEnabled(E4HandlerProxy.java:127) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:305) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:239) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132) at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.setEnabled(HandlerServiceHandler.java:80) at org.eclipse.core.commands.Command.setEnabled(Command.java:862) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.canExecute(HandlerServiceImpl.java:179) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.canExecute(HandlerServiceImpl.java:165) at org.eclipse.ui.internal.quickaccess.CommandProvider.getElements(CommandProvider.java:80) at org.eclipse.ui.internal.quickaccess.CommandProvider.getElementForId(CommandProvider.java:63) at org.eclipse.ui.internal.quickaccess.SearchField.restoreDialog(SearchField.java:612) at org.eclipse.ui.internal.quickaccess.SearchField.createControls(SearchField.java:170) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:990) at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:124) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:399) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:332) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:186) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:108) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:74) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:51) at org.eclipse.e4.ui.workbench.renderers.swt.ToolControlRenderer.createWidget(ToolControlRenderer.java:126) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:992) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:661) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:767) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:738) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:732) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:716) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.subscribeChildrenHandler(PartRenderingEngine.java:305) at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.di.internal.extensions.EventObjectSupplier$DIEventHandler.handleEvent(EventObjectSupplier.java:88) at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:201) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135) at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78) at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39) at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:52) at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:60) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374) at org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(EcoreEList.java:249) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:356) at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:343) at org.eclipse.e4.ui.internal.workbench.ContributionsAnalyzer.processAddition(ContributionsAnalyzer.java:435) at org.eclipse.e4.ui.workbench.renderers.swt.TrimBarRenderer.addTrimContributions(TrimBarRenderer.java:164) at org.eclipse.e4.ui.workbench.renderers.swt.TrimBarRenderer.processContents(TrimBarRenderer.java:136) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:675) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:767) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$0(PartRenderingEngine.java:738) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:732) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:716) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.subscribeTopicToBeRendered(PartRenderingEngine.java:154) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.di.internal.extensions.EventObjectSupplier$DIEventHandler.handleEvent(EventObjectSupplier.java:88) at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:201) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135) at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78) at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39) at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:52) at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:60) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374) at org.eclipse.e4.ui.model.application.ui.impl.UIElementImpl.setToBeRendered(UIElementImpl.java:303) at org.eclipse.ui.internal.CoolBarToTrimManager.update(CoolBarToTrimManager.java:571) at org.eclipse.ui.internal.WorkbenchWindow.updateActionBars(WorkbenchWindow.java:2362) at org.eclipse.ui.internal.WorkbenchWindow.largeUpdateEnd(WorkbenchWindow.java:2415) at org.eclipse.ui.internal.Workbench.largeUpdateEnd(Workbench.java:3380) at org.eclipse.ui.internal.WorkbenchWindow.fillActionBars(WorkbenchWindow.java:2612) at org.eclipse.ui.internal.WorkbenchWindow.setup(WorkbenchWindow.java:674)
Quickly looking on the SearchField code, org.eclipse.ui.internal.quickaccess.SearchField.restoreDialog() could run *after* UI startup, in a job (unfortunately many QuickAccessProvider providers need UI), but the CommandProvider and PreferenceProvider definitely not. And I would either add some simpler "static" check for command which does not load handlers (not sure if there is something, I think at lest about handler/command bundle activation check via BundleUtility.isActive(bundleId)) or just skip this check in QuickAccessProvider and check directly before execution in CommandElement. So point 1) should be immediately doable and allow faster startup anyway, point 2) requires some more thinking but will fix the root cause problem for possible deadlocks / timeouts on startup.
I think we could move the SearchField.restoreDialog() call to the first time the search field gets focus.
(In reply to Lars Vogel from comment #3) > I think we could move the SearchField.restoreDialog() call to the first time > the search field gets focus. Why? It will then (again, in worst case) freeze UI. The data collection (this is what restoreDialog() does) should run in background.
(In reply to Andrey Loskutov from comment #4) > (In reply to Lars Vogel from comment #3) > > I think we could move the SearchField.restoreDialog() call to the first time > > the search field gets focus. > > Why? It will then (again, in worst case) freeze UI. The data collection > (this is what restoreDialog() does) should run in background. At least startup will be not blocked, so this would be a quick gain for users which are not using the search box. Also, I assume lots of plug-ins will be loaded during the restore of the perspectives, so this should run faster if the user uses the first time the search box. So this might be "quick gain". But running the operation in the background is the better solution.
(In reply to Andrey Loskutov from comment #4) > (In reply to Lars Vogel from comment #3) > > I think we could move the SearchField.restoreDialog() call to the first time > > the search field gets focus. > > Why? It will then (again, in worst case) freeze UI. The data collection > (this is what restoreDialog() does) should run in background. +1.
New Gerrit change created: https://git.eclipse.org/r/124399
Hi Simeon, Please, consider the that the quick access shown in the toolbar is implemented through SearchField, while when the toolbar is not visible, it is implemented via the QuickAccessDialog. - QuickAccessDialog is the standalone dialog (legacy implementation) - SearchField is the new search dialog. Its context is created only when the search field is visible on the toolbar (there is a focus listener) Also, note there is a bug about the issue that the legacy search dialog has a previous pick list disjoint w.r.t the new "E4" search dialog. This is bug 495065. It has a gerrit review pending since a long time. If you deal with quick access commands, it is worth the time to take a look at this change.
Gerrit change https://git.eclipse.org/r/124399 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3b6d8f2f7a8ecede0baea8e2e1e1223772107bb3
New Gerrit change created: https://git.eclipse.org/r/124788
Gerrit change https://git.eclipse.org/r/124788 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5c3e14fa38a4fd7603568e267c39dcd3a4608151
Simeon, can you try if workbench starts faster for you with Eclipse SDK? Version: 4.9 Build id: I20180621-2000 OS: Linux, v.4.15.0-22-generic, x86_64 / gtk 3.22.30 Java version: 1.8.0_161 Starts for me now in 9489 ms which is a bit slower but could be "while noise". I used the following .options file and started Eclipse with -debug # turn on debugging for the org.eclipse.core plugin. org.eclipse.osgi/debug=true # turn on loading time for the plug-ins org.eclipse.osgi/debug/bundleTime=true Simeon, could you post your before and after numbers? Build can be found here: http://download.eclipse.org/eclipse/downloads/drops4/I20180621-2000/
(In reply to Lars Vogel from comment #12) > Simeon, can you try if workbench starts faster for you with Eclipse SDK? > Version: 4.9 > Build id: I20180621-2000 > OS: Linux, v.4.15.0-22-generic, x86_64 / gtk 3.22.30 > Java version: 1.8.0_161 > > Starts for me now in 9489 ms which is a bit slower but could be "while > noise". > > I used the following .options file and started Eclipse with -debug > > # turn on debugging for the org.eclipse.core plugin. > org.eclipse.osgi/debug=true > # turn on loading time for the plug-ins > org.eclipse.osgi/debug/bundleTime=true > > Simeon, could you post your before and after numbers? Build can be found > here: http://download.eclipse.org/eclipse/downloads/drops4/I20180621-2000/ Interesting to see this with the Eclipse installation containing XText, because XText init is heavy weight (at least in our environment).
(In reply to Andrey Loskutov from comment #13) > Interesting to see this with the Eclipse installation containing XText, > because XText init is heavy weight (at least in our environment). Both are interesting, SDK startup time (best case) and startup time with XText (worsed case (?)).
Simeon, could you please provide the startup numbers?
Sure, I'll try to do so within this week.
Sorry, I've not been able to get to this yet. I'll post measurements when I have some.
Bug is fixed.
When I open a new window and close it, I see: org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4595) at org.eclipse.swt.SWT.error(SWT.java:4510) at org.eclipse.swt.SWT.error(SWT.java:4481) at org.eclipse.swt.widgets.Widget.error(Widget.java:451) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:350) at org.eclipse.swt.widgets.Text.getText(Text.java:1319) at org.eclipse.ui.internal.quickaccess.SearchField$13.runInUIThread(SearchField.java:627) at org.eclipse.ui.progress.UIJob.lambda$0(UIJob.java:95) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3933) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3564) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1170) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1059) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:625) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:560) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:656) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:592) at org.eclipse.equinox.launcher.Main.run(Main.java:1498) at org.eclipse.equinox.launcher.Main.main(Main.java:1471) I see this after using the reproduction steps from bug 535462, I'm not sure if its just always visible. But my guess is yes.
This bug has introduced a regression when dealing with multiple monitors (bug 539510).
I'm also surprised that we don't see more exceptions from this backgrounded job as many handlers in my experience assume that they are only triggered on the UI thread.
Will take a look, likely next week.(In reply to Brian de Alwis from comment #21) > I'm also surprised that we don't see more exceptions from this backgrounded > job as many handlers in my experience assume that they are only triggered on > the UI thread. Will take a look next week. The entries are loaded with 2 jobs, see QuickAccessProvider.requiresUiAccess(): 1. Providers which require UI access. Entries are loaded with a UI job. 2. Providers which don't require UI access. Entries are loaded with a normal job. Overall the goal was to avoid loading a lot of plug-ins at start up, and avoid loading in UI thread as much as possible.
This may have caused a regression, please see Bug 539510
(In reply to Lars Vogel from comment #23) > This may have caused a regression, please see Bug 539510 Sorry, wrong clipboard content. This may have caused a regression, please see Bug 546217
(In reply to Lars Vogel from comment #24) > (In reply to Lars Vogel from comment #23) > > This may have caused a regression, please see Bug 539510 > > Sorry, wrong clipboard content. > > This may have caused a regression, please see Bug 546217 No, bug 546217 is caused by patch in bug 546187.
