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

Bug 367016

Summary: Non-standard Windows Vista Tool Bar functionality
Product: [Eclipse Project] Platform Reporter: Ed Willink <ed>
Component: UIAssignee: Platform-UI-Inbox <Platform-UI-Inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: bsd, pwebster, remy.suen
Version: 4.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
Whiteboard: stalebug

Description Ed Willink CLA 2011-12-17 12:56:42 EST
e4 M4 does not offer the normal Windows menu on its ToolBar (Close, Minimize etc) and manages to corrupt the similar menus on non-e4 applications. Selecting the tool bar entry does not bring the relevant e4 app to the front.

The problem started when hitting a brekpoint in the debugger. Thereafter it proved very difficult to see the right windows; generally it was necessary to close any other firefoxes etc that were spuriously occluding the selecrted e4.
Comment 1 Ed Willink CLA 2011-12-17 13:06:27 EST
The Windows menu functionality returns to normal once the platform is running again (no longer stopped at the breakpoint in Bug 367015).
Comment 2 Brian de Alwis CLA 2011-12-19 08:35:44 EST
Ed, could you please provide more detail about what you were trying to do?

  * E4 is a platform — what application are you dealing with?  The IDE?
  * Close, Minimize are all elements in the window's system menu, and not the tool bar.
  * What corruption are you experiencing?  What were you expecting?

From what I can see of bug 367015 you hit a breakpoint in the SWT event thread.  In case you didn't know, in SWT applications all window updates and event handling is performed by the SWT thread.  Raising windows, redrawing widgets, etc. are all triggered by such events.  No events will be processed while that thread is suspended.  Once you resumed the thread, all pending events would have been processed and why everything would have appeared to work again.  This is standard behaviour to any SWT application, and is not new to E4.
Comment 3 Ed Willink CLA 2011-12-19 12:16:54 EST
I was just debugging as I have done on 3.x many times before.

I am well aware that the run-time Eclipse may freeze while the main Eclipse is at a breakpoint. However, I have never experienced a total failure outside of Eclipse whereby the Windows toolbar could not to-front by selecting. e.g. a Firefox window lost it's Windows menu and interaction.

On 3.x I have observed that sometimes the frozen Eclipse may need to be selected in order to allow the main Eclipse to successfully be selected and brought to front on top.

But this total inability to get the main Eclipse to-front is new to me. Only by closing all other intervening windows could the main Eclipse be made visible at the front.
Comment 4 Lars Vogel CLA 2019-11-27 07:40:46 EST
This bug hasn't had any activity in quite some time. Maybe the problem got
resolved, was a duplicate of something else, or became less pressing for some
reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it.
The information can be, for example, that the problem still occurs, that you
still want the feature, that more information is needed, or that the bug is
(for whatever reason) no longer relevant.

If the bug is still relevant, please remove the stalebug whiteboard tag.