Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 552350

Summary: Eclipse starts with some ToolItems enabled when they shouldn't be
Product: [Eclipse Project] Platform Reporter: Eric Williams <ericwill>
Component: UIAssignee: Paul Pazderski <paul-eclipse>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: amj87.iitr, edeviser, manish.bansal, paul-eclipse, rishav.shandilya95, rodrigo.bento
Version: 4.11   
Target Milestone: 4.14 M3   
Hardware: All   
OS: All   
See Also: https://git.eclipse.org/r/151487
https://git.eclipse.org/r/151488
https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=38d12e3702baa5efc872a1c3c82c0126a8b1a858
https://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=d798f1df59f3682aa84ddc8ed6a18d013f7f6e7b
Whiteboard:
Attachments:
Description Flags
Start/stop buttons are enabled even when nothing is running none

Description Eric Williams CLA 2019-10-23 08:28:13 EDT
Created attachment 280384 [details]
Start/stop buttons are enabled even when nothing is running

I've been noticing for awhile now (at least two releases) that Eclipse starts with all ToolItems enabled in the workbench. For example, the launch buttons (Start/Stop/Suspend/etc.) are all enabled when first starting Eclipse, even though nothing is currently running. If I click on them, a dialog pops up and says "The chosen operation is not enabled".

If I start Eclipse and click some ToolItem, like the dropdown menu for the Run Configurations, then the ToolItems revert back to their correctly enabled/disabled state.
Comment 1 Paul Pazderski CLA 2019-10-23 08:50:53 EDT
I don't know if you already investigate this but the reason is simply that the toolbar buttons at first are only proxies which are always enabled by default and don't know there correct state until their providing plugin is loaded.

And this is at least since 4.11 where I first worked on a change which could improve the situation. (at least for the debug buttons which bothered me and you)
Comment 2 Eric Williams CLA 2019-10-23 09:01:14 EDT
(In reply to Paul Pazderski from comment #1)
> I don't know if you already investigate this but the reason is simply that
> the toolbar buttons at first are only proxies which are always enabled by
> default and don't know there correct state until their providing plugin is
> loaded.
> 
> And this is at least since 4.11 where I first worked on a change which could
> improve the situation. (at least for the debug buttons which bothered me and
> you)

I haven't looked into it yet, thanks for shedding some light on the issue. Is this an SWT bug or something in Platform UI?
Comment 3 Paul Pazderski CLA 2019-10-23 09:16:43 EDT
Platform UI or you could say Debug in this particular case. I'm not even sure I would call it a bug. As said by default the ToolItems are proxies and enabled until the plugin defining the action is loaded (in this case org.eclipse.debug.ui).

And I thinks this is usually not noticed because most toolbar buttons are enabled and the default is fitting for them and the launching buttons are only part of the debug perspective by default and activating debug perspective will load the debug plugin and set the buttons to there disabled state.
Comment 4 Eclipse Genie CLA 2019-10-23 09:35:45 EDT
New Gerrit change created: https://git.eclipse.org/r/151487
Comment 5 Eclipse Genie CLA 2019-10-23 09:35:51 EDT
New Gerrit change created: https://git.eclipse.org/r/151488
Comment 6 Paul Pazderski CLA 2019-10-23 09:37:34 EDT
My workaround for the debug buttons was to allow setting the initial state of the proxy button which isn't perfect but simple and preserves the lazy loading approach.
Comment 7 Eric Williams CLA 2019-10-23 09:50:52 EDT
(In reply to Paul Pazderski from comment #6)
> My workaround for the debug buttons was to allow setting the initial state
> of the proxy button which isn't perfect but simple and preserves the lazy
> loading approach.

I'm not an expert here, but sounds good. The save button on the toolbar is disabled from the start, is there some logic we could copy from it?
Comment 8 Paul Pazderski CLA 2019-10-23 09:55:01 EDT
(In reply to Eric Williams from comment #7)
> (In reply to Paul Pazderski from comment #6)
> > My workaround for the debug buttons was to allow setting the initial state
> > of the proxy button which isn't perfect but simple and preserves the lazy
> > loading approach.
> 
> I'm not an expert here, but sounds good. The save button on the toolbar is
> disabled from the start, is there some logic we could copy from it?

I will check but I'm quite sure the correct save button state come from the fact that the providing plugin is so fundamental that it is always loaded at start and providing the (correct) disabled state.
Comment 9 Eric Williams CLA 2019-10-23 10:02:17 EDT
(In reply to Paul Pazderski from comment #8)
> (In reply to Eric Williams from comment #7)
> > (In reply to Paul Pazderski from comment #6)
> > > My workaround for the debug buttons was to allow setting the initial state
> > > of the proxy button which isn't perfect but simple and preserves the lazy
> > > loading approach.
> > 
> > I'm not an expert here, but sounds good. The save button on the toolbar is
> > disabled from the start, is there some logic we could copy from it?
> 
> I will check but I'm quite sure the correct save button state come from the
> fact that the providing plugin is so fundamental that it is always loaded at
> start and providing the (correct) disabled state.

Makes sense.
Comment 12 Eric Williams CLA 2019-11-12 09:26:18 EST
Can we close this one now, Paul?
Comment 13 Paul Pazderski CLA 2019-11-12 09:27:57 EST
Yes. Should be better now. Thank you for the reminder.
Comment 14 Eric Williams CLA 2019-11-12 09:29:00 EST
(In reply to Paul Pazderski from comment #13)
> Yes. Should be better now. Thank you for the reminder.

Thank you for the fix! This issue has always bugged me for a long time.
Comment 15 Paul Pazderski CLA 2020-04-19 16:34:52 EDT
*** Bug 495569 has been marked as a duplicate of this bug. ***
Comment 16 Paul Pazderski CLA 2020-04-25 04:06:38 EDT
*** Bug 479324 has been marked as a duplicate of this bug. ***
Comment 17 Paul Pazderski CLA 2020-04-28 04:13:34 EDT
*** Bug 501878 has been marked as a duplicate of this bug. ***
Comment 18 Paul Pazderski CLA 2020-04-28 04:46:33 EDT
*** Bug 363436 has been marked as a duplicate of this bug. ***
Comment 19 Rishav Shandilya CLA 2020-08-09 07:11:02 EDT
(In reply to Paul Pazderski from comment #13)
> Yes. Should be better now. Thank you for the reminder.

Hi @Paul, @Eric,

I have been using 
Eclipse Java EE IDE for Web Developers
Version: 2018-09 (4.9.0)
Build id: 20180917-1800

And i can still see this issue whenever I start Eclipse IDE.
Comment 20 Rishav Shandilya CLA 2020-08-09 09:11:25 EDT
(In reply to Rishav Shandilya from comment #19)
> (In reply to Paul Pazderski from comment #13)
> > Yes. Should be better now. Thank you for the reminder.
> 
> Hi @Paul, @Eric,
> 
> I have been using 
> Eclipse Java EE IDE for Web Developers
> Version: 2018-09 (4.9.0)
> Build id: 20180917-1800
> 
> And i can still see this issue whenever I start Eclipse IDE.

I just updated to:-
Version: 2020-06 (4.16.0)
Build id: 20200615-1200

And i don't see this issue anymore in this version.