Comment 1 Joseph Carroll 2012-08-31 09:00:13 EDT

Dani, would you feel that this is something that should be addressed with Bug 378815? Or do you think it is a separate issue?

JD

Comment 2 Dani Megert 2012-08-31 09:16:51 EDT

(In reply to comment #1)
> Dani, would you feel that this is something that should be addressed with
> Bug 378815? Or do you think it is a separate issue?
> 
> JD

This is a separate issue which was not broken in 4.2.

Comment 3 Dani Megert 2012-11-26 03:28:00 EST

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

Comment 4 Andreas Gronert 2012-11-26 14:08:06 EST

Hello,
there is another way to reproduce this problem. As this way is different from Danis, I'm adding this comment with the alternative way to reproduce the problem. The main difference between Danis and my way to reproduce the problem is, that Dani closes all perspectives and me not, but I have the same never ending exceptions. I think it may help to reproduce the problem in different ways when searching for the internal reason. Here are the details:

- creating a new plugin project with no template
- selecting the Extension tab from plugin.xml
- press ADD Button
- select the extension point org.eclipse.ui.perspectives
- add a new perspective (per context menu -> new -> perspectives)
- specify the id, name and class or leave the default
- click the class link, what will open the "New Class" wizard
- take all default values and click finish to generate the class
- save all
- run the plugin per "Launch an Eclipse application" link from plugin.xml
- this will open another workspace with the following result:
	(1) when running it the first time and open the new perspective in addition to the default "Plug-in Development Perspective" all works fine
	(2) when running it the second and all following times, the never ending exceptions will be shown at the console of the development workspace

Original I did discuss this problem in

"perspective with endless console error messages [message #987291]"

There you will find some more details.
Kind regards
Andreas Gronert

Comment 5 Michael Rennie 2013-01-10 17:08:31 EST

(In reply to comment #4)
> Hello,
> there is another way to reproduce this problem. As this way is different
> from Danis, I'm adding this comment with the alternative way to reproduce
> the problem. The main difference between Danis and my way to reproduce the
> problem is, that Dani closes all perspectives and me not, but I have the
> same never ending exceptions. I think it may help to reproduce the problem
> in different ways when searching for the internal reason. Here are the
> details:
> 

If you grab the example plugin from bug 386292 and do the following you can also reproduce the exceptions:

1. start target workspace (new or existing)
2. open the 'My Perspective' perspective
3. restart the target - leave 'My Perspective' open when you shut down the target workspace

Comment 6 Eric Moffatt 2013-01-16 14:36:24 EST

Dani, I'll get to this one soonest once 4.2.2 ships...

Comment 7 Paul Elder 2013-01-23 17:00:17 EST

Created attachment 226005 [details]
422 Patch

A surgical fix to find and remove orphaned items from the tool bar timer update list. In 4.3, we need to figure out how/why these items are getting orphaned.

Comment 8 Eric Moffatt 2013-01-23 21:38:13 EST

Paul, I took a quick look at the patch and it looks ok to me. I'll show you how to work the approval flags tomorrow...;-)

Comment 9 Paul Webster 2013-01-24 09:12:09 EST

Created attachment 226044 [details]
PaulE's updated patch

The patch looks good, with 2 minor modifications.  We don't recreate the bogus element list on every run, and check a shell to protect against an NPE.

Dani, I'd like to put this in 4.2.2.  What do you think?

PW

Comment 10 Paul Webster 2013-01-24 11:09:29 EST

The reason I added the check for shell==null. The SearchField.createWidget calls SearchField.restoreDialog after the listener is added but before the shell is created.  RestoreDialog is restoring commands and handlers, and one of them is causing the WorkbenchWindow to render the MenuBar and causing the resize event.

java.lang.NullPointerException
	at org.eclipse.ui.internal.quickaccess.SearchField$1.closeDropDown(SearchField.java:121)
	at org.eclipse.ui.internal.quickaccess.SearchField$1.controlResized(SearchField.java:113)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:235)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1276)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1300)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1281)
	at org.eclipse.swt.widgets.Shell.resizeBounds(Shell.java:1628)
	at org.eclipse.swt.widgets.Shell.setMenuBar(Shell.java:1864)
	at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRenderer.createWidget(MenuManagerRenderer.java:290)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:894)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:629)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$6.run(PartRenderingEngine.java:520)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:505)
	at org.eclipse.ui.internal.WorkbenchWindow.setup(WorkbenchWindow.java:570)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:613)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:861)
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:113)
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:83)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.inject(ContextInjectionFactory.java:72)
	at org.eclipse.ui.internal.Workbench.createWorkbenchWindow(Workbench.java:1253)
	at org.eclipse.ui.internal.Workbench.getActiveWorkbenchWindow(Workbench.java:1225)
	at org.eclipse.egit.ui.internal.history.command.AbstractHistoryCommandHandler.getPage(AbstractHistoryCommandHandler.java:140)
	at org.eclipse.egit.ui.internal.history.command.CheckoutCommitHandler.isEnabled(CheckoutCommitHandler.java:66)
	at org.eclipse.ui.internal.handlers.HandlerProxy.isEnabled(HandlerProxy.java:317)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.canExecute(E4HandlerProxy.java:59)
	at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:613)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:231)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:212)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.canExecute(HandlerServiceImpl.java:110)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.canExecute(HandlerServiceImpl.java:93)
	at org.eclipse.ui.internal.MakeHandlersGo.isEnabled(MakeHandlersGo.java:142)
	at org.eclipse.core.commands.Command.isEnabled(Command.java:862)
	at org.eclipse.ui.internal.quickaccess.CommandProvider.getElements(CommandProvider.java:68)
	at org.eclipse.ui.internal.quickaccess.CommandProvider.getElementForId(CommandProvider.java:52)
	at org.eclipse.ui.internal.quickaccess.SearchField.restoreDialog(SearchField.java:446)
	at org.eclipse.ui.internal.quickaccess.SearchField.createWidget(SearchField.java:140)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:613)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:861)
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:113)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:321)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:255)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:185)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:105)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:71)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:49)
	at org.eclipse.e4.ui.workbench.renderers.swt.ToolControlRenderer.createWidget(ToolControlRenderer.java:75)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:894)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:629)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:731)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:702)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:696)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:681)
	at org.eclipse.e4.ui.workbench.renderers.swt.SWTPartRenderer.processContents(SWTPartRenderer.java:59)
	at org.eclipse.e4.ui.workbench.renderers.swt.TrimBarRenderer.processContents(TrimBarRenderer.java:154)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:641)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$6.run(PartRenderingEngine.java:520)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:505)
	at org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer.processContents(WBWRenderer.java:665)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:641)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:731)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.access$2(PartRenderingEngine.java:702)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:696)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:681)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:987)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:942)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:613)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)

Comment 11 Dani Megert 2013-01-24 11:52:13 EST

(In reply to comment #10)

That NPE does not happen with the steps from comment 0 but when using an older workspace where the search field already has a (command) history.

The 'null' check is the safest to do for 4.2.2 but in 4.3 we should either move listener creation or the restore code after creating the shell. Also, the copyright date needs to be updated.

The other fix also looks good for 4.2.2 but I would
- not use "bogus" in the name
- use an ArrayList instead of a LinkedList, since there aren't that many 
  orphaned items

+1 for SR2 RC3.

Comment 12 Paul Webster 2013-01-24 12:02:19 EST

Released fix with minor mods as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=3b52355ebf44a9e1ba722681a3f1663c1d3a6249


Opened Bug 398990 to look at the SearchField instantiation ordering.

PW

Comment 13 Dani Megert 2013-01-25 05:14:22 EST

Verified in 4.2-M20130124-1700.

Fixed copyright with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=dd59f71d8db946b04892a0532a5e0468e86c922d

Fixed in 'master' with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3159984032ae4af0d8d6e76dbc01d0df21f41ef6

Comment 14 Paul Elder 2013-01-29 10:10:15 EST

Verified - 4.3-I20130128-2000

Comment 15 Bouchet Stéphane 2013-05-13 05:07:45 EDT

Hi,

is this bug fixed in 4.2.2 release ? 

i am getting this exact behavior ( endless exceptions ) with :

Version: 4.2.2
Build id: M20130204-1200

cheers,

Comment 16 Bouchet Stéphane 2013-05-13 05:08:29 EDT

complete stack :

eclipse.buildId=M20130204-1200
java.version=1.6.0_38
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=fr_FR
Command-line arguments:  -os win32 -ws win32 -arch x86_64

Error
Mon May 13 11:06:46 CEST 2013
Problems occurred when invoking code from plug-in: "org.eclipse.e4.ui.workbench.renderers.swt".

java.lang.NullPointerException
	at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.canExecuteItem(HandledContributionItem.java:840)
	at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$2(HandledContributionItem.java:834)
	at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$3.run(HandledContributionItem.java:227)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.updateItemEnablement(HandledContributionItem.java:257)
	at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$ToolItemUpdateTimer.run(HandledContributionItem.java:150)
	at org.eclipse.swt.widgets.Display.runTimer(Display.java:4270)
	at org.eclipse.swt.widgets.Display.messageProc(Display.java:3357)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2546)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1053)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:942)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	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:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)

Comment 17 Dani Megert 2013-05-13 08:38:00 EDT

(In reply to comment #15)
> Hi,
> 
> is this bug fixed in 4.2.2 release ? 

Yes, this bug (see comment 0), is fixed. Just verified it again. If you can reproduce the exceptions with different steps using http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M7-201305020800/ then please file a new bug report with those steps.

Comment 18 Bouchet Stéphane 2013-05-14 06:20:31 EDT

Hi,

i cannot reproduce with a fresh install. I suspect then one of my installed plugins is causing this.

i'll investigate.

Thanks

Comment 19 Elena Laskavaia 2013-05-31 13:35:55 EDT

This is not actually fixed. I think we found a real problem, I will add comments
to Bug 404312

Comment 20 Marc Gobeil 2013-05-31 14:07:35 EDT

Why did the ToolItemUpdateTimer class even exist before the hack solution to this problem was introduced into it?  Its only job appears to be running the windowRunnables registered to it through addWindowRunnable(), but a search for calls to that method turn up no results.

If that isn't stripped out as part of this fix, we should open another bug to strip it out, as per comment on HandledContributionItem:173

// HACK!! local 'static' timerExec...should move out of this class post 4.1
public static ToolItemUpdateTimer toolItemUpdater = new ToolItemUpdateTimer();

Comment 21 Marc Gobeil 2013-05-31 14:16:09 EDT

ah, it already has caused a performance issue:
Bug 385394 - Performance issue regarding enabled state handling for menuContributions containing command (ToolItemUpdateTimer puts constant load on CPU)

Comment 22 Paul Webster 2013-05-31 14:36:35 EDT

(In reply to comment #21)
> ah, it already has caused a performance issue:
> Bug 385394 - Performance issue regarding enabled state handling for
> menuContributions containing command (ToolItemUpdateTimer puts constant load
> on CPU)

Yes, but it's behaviourly necessary until we come up with a solution ... the one we had hoped to use in 4.3 didn't work.

PW

Comment 23 Marc Gobeil 2013-05-31 14:40:43 EDT

We believe Elena's found the root problem (Comment 19), and attached a patch for it to Bug 404312

Comment 24 Marc Gobeil 2013-05-31 14:43:37 EDT

Sorry, I realize you might have been talking about the ToolItemUpdateTimer before the patch on this bug was applied, but in that case, how is it used if addWindowRunnable() is never called.  Am I missing a reference to it?

Comment 25 Johannes Michler 2013-08-21 13:08:09 EDT

Well I'm not sure if this is really fixed, even with Elena's root-problem-fix. I have this problem with an RCP-Application "upgraded" from 3.8, but only when running an exported version of the application. When running the RCP-App from within eclipse during development that error never occurs.

I'm on 4.3 and I tried to import org.eclipse.ui.workbench and changed CoolBarTrimManager according to https://git.eclipse.org/r/15090. After exporting my project again I still get thousands of those NPEs :-(

Any further ideas? What could be the difference between running from within eclipse and running my exported rcp-app?


Regards,
Johannes Michler

Comment 26 Paul Webster 2013-08-21 13:25:44 EDT

(In reply to comment #25)
> 
> Any further ideas? What could be the difference between running from within
> eclipse and running my exported rcp-app?

Try exporting your RCP from one of the Maintenance builds that includes the fix, http://download.eclipse.org/eclipse/downloads/

PW

Comment 27 Johannes Michler 2013-08-21 15:38:16 EDT

(In reply to comment #26)
> (In reply to comment #25)
> > 
> > Any further ideas? What could be the difference between running from within
> > eclipse and running my exported rcp-app?
> 
> Try exporting your RCP from one of the Maintenance builds that includes the
> fix, http://download.eclipse.org/eclipse/downloads/
> 
> PW

Well this would require me alot of work: I've installed numerous plugins and it would need half a day to re-install them all on the Integration oder M1-Build. Or is there an easy way to upgrade my 4.3.0 to this release without re-installing?

Comment 28 Paul Webster 2013-08-21 15:56:02 EDT

(In reply to comment #27)
> 
> Well this would require me alot of work: I've installed numerous plugins and
> it would need half a day to re-install them all on the Integration oder
> M1-Build. Or is there an easy way to upgrade my 4.3.0 to this release
> without re-installing?

That really depends on how your 4.3.0 is configured.  One thing you can try is deliberately installing the maintenance RCP feature into 4.3.0 to pick up this fix.  http://download.eclipse.org/eclipse/updates/4.3-M-builds

When you made your change and re-exported your product, did it put the correct versions of the fixed ui.workbench in there?

PW

Comment 29 Johannes Michler 2013-08-21 16:04:17 EDT

(In reply to comment #28)
> (In reply to comment #27)
> > 
> > Well this would require me alot of work: I've installed numerous plugins and
> > it would need half a day to re-install them all on the Integration oder
> > M1-Build. Or is there an easy way to upgrade my 4.3.0 to this release
> > without re-installing?
> 
> That really depends on how your 4.3.0 is configured.  One thing you can try
> is deliberately installing the maintenance RCP feature into 4.3.0 to pick up
> this fix.  http://download.eclipse.org/eclipse/updates/4.3-M-builds
> 
> When you made your change and re-exported your product, did it put the
> correct versions of the fixed ui.workbench in there?
> 
> PW

yes it did. Verified this by changing the manifest.mf-version in a custom way. So I'm quite sure I really got the fixed version. But if you're sure this must be fixed I'll start over again that part tomorrow, maybe I've missed something. But anyway: Shouldn't the ugly hack/workaroun here (that is in 4.3) avoid the problem with or without the CoolBarTrimManager fix?

Maybe this problem is related due to my manual removal of the quick-search-bar as described in 362420? But then why is it working from within eclipse?

JM

Comment 30 Johannes Michler 2013-08-22 09:23:13 EDT

Well I did some more checks. Obviously I did something wrong while trying to hide the quick-search. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=362420 and my latest comment there for all details ....

JM