Community
Participate
Working Groups
Build Identifier: I20120608-1400 Under certain circumstances (see steps to reproduce) I noticed really strange behavior of SWT controls under Mac OS X. Some background: When working with GEF/GMF based diagram editors, the property view always displays properties of the currently selected element. If the property view contains multiple SWT controls (like Text controls) and the user clicks in any of these controls except the first, the value of the _first_ SWT control is copied into the newly selected control. I chose "Major" as severity but maybe this is a critical bug since if you simply click around in the property views text fields, the user doesn't expect the diagram/model to get changed. Therefore it might be possible to lose data without noticing it. Note: Although the described setup requires the installation of the Ecore Tools SDK, I suppose the problem is somewhere in the Juno SWT implementation for Mac OS X because I also was able to reproduce the problem in my special GEF based editor which also uses a property view with multiple SWT textfields. Reproducible: Always Steps to Reproduce: Setup: 1. Install Ecore Tools SDK from the eclipse update site to get the GMF based ecore diagram editor 2. Import the attached project "MyProject.zip" 3. Open the included diagram "myModel.ecorediag" 4. Ensure the property view is open and visible Steps to reproduce 1. Click somewhere into the diagram. Note the property view is displaying the values for "Name", "NS Prefix" and "NS URI". 2. Click in the textfield of property "NS Prefix" Result: The value "somePrefix" changes to "NoName" and the editor gets dirty. Expected: The value "somePrefix" stays the same.
Created attachment 217996 [details] The example project Project containing the example diagram
I debugged this and it doesn't look like a bug in SWT. Text.setText() for the 'NS Prefix' textbox is explicitly called with the new text string. May be its a bug/feature in EMF. Moving bug to EMF for further comments/investigation.
It doesn't happen on windows.
Cedric, do you know anyone with a mac to try this out. If's more likely a problem in GMF than Ecore Tools specific...
Lakshmi, if I see this right, Text.setText() is explicitly called because ecore tools has a listener which reacts on text changes on text fields. Here is the trace: Daemon Thread [Thread-1] (Suspended (breakpoint at line 2069 in Text)) Text.setText(String) line: 2069 NsPrefixPropertySection(AbstractTextPropertySection).refresh() line: 138 NsPrefixPropertySection(AbstractTabbedPropertySection).handleModelChanged(Notification) line: 490 AbstractTabbedPropertySection$1.safeNotifyChanged(Notification) line: 107 AbstractTabbedPropertySection$1(PropertiesAdapterImpl).notifyChanged(Notification) line: 39 EPackageImpl(BasicNotifierImpl).eNotify(Notification) line: 374 EPackageImpl.setNsPrefix(String) line: 351 EPackageImpl.eSet(int, Object) line: 609 EPackageImpl(BasicEObjectImpl).eSet(EStructuralFeature, Object) line: 1071 SetCommand.doExecute() line: 722 SetCommand(AbstractOverrideableCommand).execute() line: 125 EMFCommandOperation.doExecute(IProgressMonitor, IAdaptable) line: 119 EMFCommandOperation(AbstractEMFOperation).execute(IProgressMonitor, IAdaptable) line: 150 DefaultOperationHistory.execute(IUndoableOperation, IProgressMonitor, IAdaptable) line: 513 WorkspaceCommandStackImpl.doExecute(Command, Map<?,?>) line: 208 WorkspaceCommandStackImpl(AbstractTransactionalCommandStack).execute(Command, Map<?,?>) line: 165 WorkspaceCommandStackImpl(AbstractTransactionalCommandStack).execute(Command) line: 219 NsPrefixPropertySection(AbstractTabbedPropertySection).createCommand(Object, Object) line: 370 NsPrefixPropertySection(AbstractTextPropertySection).handleTextModified() line: 147 AbstractTextPropertySection$1.textChanged(Control) line: 107 AbstractTextPropertySection$1(TextChangeListener).handleEvent(Event) line: 87 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4134 Text(Widget).sendEvent(Event) line: 1458 Text(Widget).sendEvent(int, Event, boolean) line: 1481 Text(Widget).sendEvent(int) line: 1462 Text(Control).sendFocusEvent(int) line: 3295 Display.checkFocus() line: 645 Shell.makeFirstResponder(long, long, long) line: 1249 Display.windowProc(long, long, long) line: 5603 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Text(Widget).callSuper(long, long, long) line: 221 Text(Widget).textDidEndEditing(long, long, long) line: 1955 Display.windowProc(long, long, long) line: 5571 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Shell(Widget).callSuperBoolean(long, long, long) line: 288 Shell(Widget).makeFirstResponder(long, long, long) line: 1166 Shell.makeFirstResponder(long, long, long) line: 1248 Display.windowProc(long, long, long) line: 5603 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Text(Widget).callSuper(long, long, long) line: 221 Text(Widget).mouseDownSuper(long, long, long) line: 1093 Text(Widget).mouseDown(long, long, long) line: 1085 Text(Control).mouseDown(long, long, long) line: 2538 Display.windowProc(long, long, long) line: 5493 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Shell(Widget).callSuper(long, long, long) line: 221 Shell(Widget).windowSendEvent(long, long, long) line: 2102 Shell.windowSendEvent(long, long, long) line: 2284 Display.windowProc(long, long, long) line: 5557 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Display.applicationSendEvent(long, long, long) line: 5002 Display.applicationProc(long, long, long) line: 5151 OS.objc_msgSend(long, long, long) line: not available [native method] NSApplication.sendEvent(NSEvent) line: 128 Display.readAndDispatch() line: 3616 PartRenderingEngine$9.run() line: 1022 Realm.runWithDefault(Realm, Runnable) line: 332 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 916 E4Workbench.createAndRunUI(MApplicationElement) line: 86 Workbench$5.run() line: 585 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 540 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 124 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 353 EclipseStarter.run(String[], Runnable) line: 180 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 Main.invokeFramework(String[], URL[]) line: 629 Main.basicRun(String[]) line: 584 Main.run(String[]) line: 1438 Main.main(String[]) line: 1414 In my opinion, NsPrefixPropertySection(AbstractTextPropertySection).handleTextModified() line: 147 is the interesting line. At the point in time where this code reached, NO Text.setText has been called with the new value but evaluating getText().getText() in this line magically yields the value. Besides this, the bug also occurs in our product where we neither use ecore tools nor GMF. Best regards, Andreas
What normally causes the setText event to be called for the first time? Could you set a breakpoint to see how the wrong value ends up being the value that's returned?
Ed, the trace for normal 'focus out' edit operations looks as follows: Daemon Thread [Thread-1] (Suspended (breakpoint at line 2069 in Text)) Text.setText(String) line: 2069 NsPrefixPropertySection(AbstractTextPropertySection).refresh() line: 138 NsPrefixPropertySection(AbstractTabbedPropertySection).handleModelChanged(Notification) line: 490 AbstractTabbedPropertySection$1.safeNotifyChanged(Notification) line: 107 AbstractTabbedPropertySection$1(PropertiesAdapterImpl).notifyChanged(Notification) line: 39 EPackageImpl(BasicNotifierImpl).eNotify(Notification) line: 374 EPackageImpl.setNsPrefix(String) line: 351 EPackageImpl.eSet(int, Object) line: 609 EPackageImpl(BasicEObjectImpl).eSet(EStructuralFeature, Object) line: 1071 SetCommand.doExecute() line: 722 SetCommand(AbstractOverrideableCommand).execute() line: 125 EMFCommandOperation.doExecute(IProgressMonitor, IAdaptable) line: 119 EMFCommandOperation(AbstractEMFOperation).execute(IProgressMonitor, IAdaptable) line: 150 DefaultOperationHistory.execute(IUndoableOperation, IProgressMonitor, IAdaptable) line: 513 WorkspaceCommandStackImpl.doExecute(Command, Map<?,?>) line: 208 WorkspaceCommandStackImpl(AbstractTransactionalCommandStack).execute(Command, Map<?,?>) line: 165 WorkspaceCommandStackImpl(AbstractTransactionalCommandStack).execute(Command) line: 219 NsPrefixPropertySection(AbstractTabbedPropertySection).createCommand(Object, Object) line: 370 NsPrefixPropertySection(AbstractTextPropertySection).handleTextModified() line: 147 AbstractTextPropertySection$1.textChanged(Control) line: 107 AbstractTextPropertySection$1(TextChangeListener).handleEvent(Event) line: 87 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4134 Text(Widget).sendEvent(Event) line: 1458 Text(Widget).sendEvent(int, Event, boolean) line: 1481 Text(Widget).sendEvent(int) line: 1462 Text(Control).sendFocusEvent(int) line: 3295 Display.checkFocus() line: 645 Shell.makeFirstResponder(long, long, long) line: 1249 Display.windowProc(long, long, long) line: 5603 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Text(Widget).callSuper(long, long, long) line: 221 Text(Widget).textDidEndEditing(long, long, long) line: 1955 Display.windowProc(long, long, long) line: 5571 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Shell(Widget).callSuperBoolean(long, long, long) line: 288 Shell(Widget).makeFirstResponder(long, long, long) line: 1166 Shell.makeFirstResponder(long, long, long) line: 1248 Display.windowProc(long, long, long) line: 5603 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Shell(Widget).callSuper(long, long, long) line: 221 Shell(Widget).windowSendEvent(long, long, long) line: 2102 Shell.windowSendEvent(long, long, long) line: 2284 Display.windowProc(long, long, long) line: 5557 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Display.applicationSendEvent(long, long, long) line: 5002 Display.applicationProc(long, long, long) line: 5151 OS.objc_msgSend(long, long, long) line: not available [native method] NSApplication.sendEvent(NSEvent) line: 128 Display.readAndDispatch() line: 3616 PartRenderingEngine$9.run() line: 1022 Realm.runWithDefault(Realm, Runnable) line: 332 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 916 E4Workbench.createAndRunUI(MApplicationElement) line: 86 Workbench$5.run() line: 585 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 540 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 124 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 353 EclipseStarter.run(String[], Runnable) line: 180 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 Main.invokeFramework(String[], URL[]) line: 629 Main.basicRun(String[]) line: 584 Main.run(String[]) line: 1438 Main.main(String[]) line: 1414 If I press the enter key, the trace looks like this: Daemon Thread [Thread-1] (Suspended (breakpoint at line 2069 in Text)) Text.setText(String) line: 2069 NsPrefixPropertySection(AbstractTextPropertySection).refresh() line: 138 NsPrefixPropertySection(AbstractTabbedPropertySection).handleModelChanged(Notification) line: 490 AbstractTabbedPropertySection$1.safeNotifyChanged(Notification) line: 107 AbstractTabbedPropertySection$1(PropertiesAdapterImpl).notifyChanged(Notification) line: 39 EPackageImpl(BasicNotifierImpl).eNotify(Notification) line: 374 EPackageImpl.setNsPrefix(String) line: 351 EPackageImpl.eSet(int, Object) line: 609 EPackageImpl(BasicEObjectImpl).eSet(EStructuralFeature, Object) line: 1071 SetCommand.doExecute() line: 722 SetCommand(AbstractOverrideableCommand).execute() line: 125 EMFCommandOperation.doExecute(IProgressMonitor, IAdaptable) line: 119 EMFCommandOperation(AbstractEMFOperation).execute(IProgressMonitor, IAdaptable) line: 150 DefaultOperationHistory.execute(IUndoableOperation, IProgressMonitor, IAdaptable) line: 513 WorkspaceCommandStackImpl.doExecute(Command, Map<?,?>) line: 208 WorkspaceCommandStackImpl(AbstractTransactionalCommandStack).execute(Command, Map<?,?>) line: 165 WorkspaceCommandStackImpl(AbstractTransactionalCommandStack).execute(Command) line: 219 NsPrefixPropertySection(AbstractTabbedPropertySection).createCommand(Object, Object) line: 370 NsPrefixPropertySection(AbstractTextPropertySection).handleTextModified() line: 147 AbstractTextPropertySection$1.textChanged(Control) line: 107 AbstractTextPropertySection$1(TextChangeListener).handleEvent(Event) line: 81 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4134 Text(Widget).sendEvent(Event) line: 1458 Text(Widget).sendEvent(int, Event, boolean) line: 1481 Text(Widget).sendEvent(int, Event) line: 1466 Text(Widget).sendKeyEvent(int, Event) line: 1495 Text(Widget).sendKeyEvent(NSEvent, int) line: 1491 Text.sendKeyEvent(NSEvent, int) line: 1595 Text(Control).doCommandBySelector(long, long, long) line: 1060 Display.windowProc(long, long, long) line: 5585 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Text(Widget).callSuper(long, long, long) line: 221 Text(Widget).superKeyDown(long, long, long) line: 1899 Text(Widget).keyDown(long, long, long) line: 1077 Text(Control).keyDown(long, long, long) line: 2375 Display.windowProc(long, long, long) line: 5495 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Shell(Widget).callSuper(long, long, long) line: 221 Shell(Widget).windowSendEvent(long, long, long) line: 2102 Shell.windowSendEvent(long, long, long) line: 2284 Display.windowProc(long, long, long) line: 5557 OS.objc_msgSendSuper(objc_super, long, long) line: not available [native method] Display.applicationSendEvent(long, long, long) line: 5002 Display.applicationProc(long, long, long) line: 5151 OS.objc_msgSend(long, long, long) line: not available [native method] NSApplication.sendEvent(NSEvent) line: 128 Display.readAndDispatch() line: 3616 PartRenderingEngine$9.run() line: 1022 Realm.runWithDefault(Realm, Runnable) line: 332 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 916 E4Workbench.createAndRunUI(MApplicationElement) line: 86 Workbench$5.run() line: 585 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 540 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 124 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 353 EclipseStarter.run(String[], Runnable) line: 180 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 Main.invokeFramework(String[], URL[]) line: 629 Main.basicRun(String[]) line: 584 Main.run(String[]) line: 1438 Main.main(String[]) line: 1414 As far as I can see it's the same trace as above. One additional information: If you disable the listener which is responsible for creating and executing the command (which can be done by comment out line 107 in AbstractTabbedPropertySection, the value in the field is changed but Text.setText() is NOT called.
Hi, I just want to know if I can provide any more details to get this bug fixed. Or is somebody already fixing it? Best regards, Andreas
Any news on this? This pretty much makes our Juno-based RCP unusable on MacOS, so we have to advise our Mac users to stay with 3.x. I'd offer help, but as far as we could see, this seems to be either in the native code or buried very deep in platform-specific SWT code, neither of which I can make heads or tails of. (In reply to comment #2) As Andreas explained in comment #5 this doesn't seem to be the case. When you debug into the setText(), you'll see that at this point the text field's value already has "magically" changed to the offending value beforehand. This really doesn't appear to be caused by anything on the EMF side. So I'd suggest moving it back to SWT.
It seems to me that while the problem looks to be OS-specific, tracking when setText is called on the control and understanding why it's being called, ought to help track this problem down. I don't think SWT fundamentally copies values between controls, so it must be some misbehavior in GMF, potentially caused by some bogus control event, differences in event data, or even different ordering across platform. Perhaps the listener is has some state and rather associating the event with the control the event says it comes from associates with the "current control". Given you can reproduce the problem you're really in the best position to determine why setText is being called on the wrong control. As I said, I'd love to help you and fix this, but I can't. :-(
I had time to have another look at this problem. I tried to prove that this is not an EMF related problem by putting some debug out into org.eclipse.swt.widgets.Text and org.eclipse.swt.widgets.Widget. I'm using the macosx version 3.100.1.v4236b of SWT and attached a patch which can be applied to the two corresponding files which enables the mentioned debug output. What the debug output is doing: - Everytime Widget::checkWidget() is called, the stacktrace is printed to the console if it's interesting (to not get an overwhelming amount of output on each single event). - Everytime Text::setText() or Text::setTextChars() is called, a simple debug out is printed to the console. All output is marked with timestamps. I also attached a recorded debug session in EclipseBug#383750_Mac_Trace.txt which shows how the NsPrefix textfield magically changes it's value: - Line 6845 shows the correct value 'somePrefix' for the NsPrefix Textfield - Line 7046 then magically yields the new value 'NoName'. --> Between that lines, neither Text::setText() nor Text::setTextChars() has been called. The stacktrace output at this time also contains no single line which is related to EMF. I hope this helps to track this bug down. Best regards, Andreas
Created attachment 228840 [details] Patch for debug out (SWT macosx, v4236b)
Created attachment 228841 [details] Dump of recorded debug seesion
Additional information on how to reproduce the attached debug session: 1. Setup as described in my first post 2. Clear your console log in your development eclipse 3. Hover over the NsPrefix TextField and wait some seconds until the debug out stops. 4. Click into the NsPrefix TextField and again wait some seconds until the debug out stops. If necessary I can see if we can setup a remotely accessible account on our mac if that would help.
(In reply to comment #11) > The stacktrace output at this time also contains no single line which is > related to EMF. I think at this point it's a pretty safe bet that the cause is not EMF-related. So it would make sense to move this bug back to SWT. Any objections, Ed?
I have no objections but I understand that folks working on a framework typically want/expect a "self contained" test case that demonstrates a problem with the framework itself, so asking them to install Ecore Tools could be quite annoying.
Moving back to SWT. Since the Text value "magically" changes without any call to setText() or setTextChars(), this seems to be caused by some (native?) SWT internals. I am sorry that we didn't manage to isolate the problem to reproduce it without the Ecore Tools. I can see that this is annoying, but I hope it's workable.
I've been pulling my hair our on this issue and it makes the tabbed property sections with multiple text controls on OSX completely unusable. Is there any movement on this?
Created attachment 238375 [details] Sample project to demo the bug The zip contains a mini project which demos the bug with just 20 lines of the code.
To repeat the bug with the sample project: 1. extract the bugdemo.zip and import it into eclipse. 3. right click on the bugdemo project and Run As Eclipse Application 4. open the sample view and property view in the launched Eclipse App (Window->Show View->Other->Sample View & Window->Show View->Properties) 5. place the sample view and property view beside each other (IMPORTANT), and click an item in the sample view, the property view shall show bugdemo tab. 6. click the lang text box 2, the content will immediately be changed to text 1. This sample project just based on eclipse ui and tabbed properties without EMF or 3. party dependencies.
I found that, if the first control in the properties view is a list, the bug will not be triggered anymore! So a workaround is to create a mini list in the first section.
Someone in SWT should really respond on this issue. We are doing everything possible to help narrow it down but it will need the deep SWT knowledge of a OSX dev to likely ultimately solve it.
We are also suffering from this bug at camunda. It basically means that we can only ship our eclipse bpmn modeler for indigo eclipse and not for kepler (for MAC). It is a very annoying bug. We are also happy to provide input/help on this. We are no SWT experts though. How is this going to proceed? Cheers Robert
We also have this bug in our project (Orcc: https://github.com/orcc/orcc). This is new since we just have added a Graphiti SDK based graph editor. I confirm that this bug appears only on Mac OS (10.9 on our test machines) with default Apple JVM (1.6). This definitely seems to not being related to EMF. I can always reproduce the issue with Dongyue Mou attachement. I also confirm that Text.setText() and Text.setTextChars() is never called between initialization of faulting text field and its 'magical' value update. I put some breakpoints to confirm that. I still search for a workaround on that, since this bug is very very annoying for our users. I tried to manually set focus on the first field at refresh, but this causes the field to be selected. The other workaround (creating a mini list as first widget) does not please me, but I have to fix this issue for our Mac users. I will maybe use that as last resort. I also am ready to provide aditional information/help if someone with better experience on SWT needs it. Regards
This is also an issue for our project at Oracle. When can we expect a response from SWT?
(In reply to Dongyue Mou from comment #20) > To repeat the bug with the sample project: > 1. extract the bugdemo.zip and import it into eclipse. > 3. right click on the bugdemo project and Run As Eclipse Application > 4. open the sample view and property view in the launched Eclipse App > (Window->Show View->Other->Sample View & Window->Show View->Properties) > 5. place the sample view and property view beside each other (IMPORTANT), > and click an item in the sample view, the property view shall show bugdemo > tab. > 6. click the lang text box 2, the content will immediately be changed to > text 1. > > This sample project just based on eclipse ui and tabbed properties without > EMF or 3. party dependencies. Thanks for the sample code. Cocoa uses a single text editor which is shared by all text fields in a window. After clicking on text box 2(step 6), focus moves to text2, then to text1, and finally, back to text2. The shared editor is unable to keep up, because of the quick focus changes. Essentially, it looks like a Cocoa issue. We're looking for a work-around in SWT.
Any news on that? The problem still persists under Yosemite public beta (I use their latest build, thus I think the problem will still exist in the final version). Thank you.
This issue also happens in WireframeSketcher and can be easily reproduced. Create a new screen, add a widget and then put it in a group using Ctrl+G. The Properties for the group contain a Name text field and then 4 fields for coordinates. Change the name to some text and then try to click on the group in screen editor and then on any of those fields. The text from the Name field is copied there. Debugging this issue showed that setText is never called. There is also another behavior that I've observed and that is not found on other platforms. When clicking on a field in Properties View it will first focus the field, then activation sequence is performed on the view part which forces another focus change. This focuses the first field in the view and the clicked field loses it's focus. So I think that this rapid sequence of focus changes might be related to this issue.
Created attachment 249170 [details] Focus lost issue stack trace I've attached a stack trace for the focus lost issue I've described above. You can see in the sequence that a the click on a text field in a deactivated view triggers some activation sequence which results in the focus lost because it focuses the first text field (not the one clicked).
I can reproduce this behavior too, and it affects two applications we develop. Any news from the SWT team?
Any news on this? It would really be great to get this fixed for Mars, so we can support newer Eclipse versions for Mac again (we're currently stuck with 3.8).
I'm verifying the same bad behavior in our product. I experienced it while trying to move our RCP app to Eclipse 4. Any news on the topic? Any valuable workarounds? Thanks. Massimo.
We have this affecting our product right now, even in Mars, OSX 10.10.4, 10.11 making no difference. It causes values to just pop into text fields, completely upsetting our users.
Hi, I just wanted to notify that also the text alignment seems to be involved: for example if the widgets have different style-bits specified on creation (i.e SWT.RIGHT). In our product we were able somehow (with dirty tricks) to handle this bad text behavior, but we recently noted the issue related to text alignment. You can simply verify it modifying the PropertySection class in the "Sample project to demo the bug" attachment. > text1 = getWidgetFactory().createText(parent, ""); > text1.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, false)); > text2 = getWidgetFactory().createText(parent, "", SWT.RIGHT); > text2.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, false)); Just give a quick look to the following screencast: http://screencast.com/t/yFyfOEVpXq The SWT.READ_ONLY style bit seems not to be affected. Not sure if there are others that might be influenced by this bug. Regards, Massimo. P.S: do you know if there is a way to workaround this? i.e forcing the orientation after creation?!
(In reply to comment #36) > In our product we were able somehow (with dirty tricks) to handle this bad text > behavior Massimo, would you be able to share your "dirty tricks" to work around the issue with the text value?
(In reply to Carsten Reckord from comment #37) > (In reply to comment #36) > > In our product we were able somehow (with dirty tricks) to handle this bad text > > behavior > > Massimo, would you be able to share your "dirty tricks" to work around the > issue with the text value? In the past, I wrote a workaround for the bug which worked pretty well. You can find it here: https://github.com/orcc/orcc/blob/d35b17a674c7ec090223f4735bd1206219665e4a/eclipse/plugins/net.sf.orcc.xdf.ui/src/net/sf/orcc/xdf/ui/properties/AbstractGridBasedSection.java#L175 Basically, the trick is to create a fake Text object, hidden from the current view, and give it the focus on refresh action (https://github.com/orcc/orcc/blob/d35b17a674c7ec090223f4735bd1206219665e4a/eclipse/plugins/net.sf.orcc.xdf.ui/src/net/sf/orcc/xdf/ui/properties/AbstractGridBasedSection.java#L93). Hope that will help
Created attachment 265798 [details] Sample RCP Workbench App I was able to narrow it down even further to an issue with view activation and setting the focus. This sample RCP app works just like the previous sample project with the same results. If you comment out the "parent.setFocus()" call at line 47 in SampleChildView, then it will not replace the text. I verified that it is a bug in SWT with a standalone snippet. It uses only SWT to simulate what is happening in the workbench. The listener for the "Activate" event on the parent shell is called when you click on 'text2'. This calls setFocus() on the parent just like the workbench would for the ViewPart. Since text1 is the first child of the parent composite, it takes the focus and corrupts the text. That's as far as I have tracked it, but it makes sense why the suggested workarounds of putting another control before the first Text widget work. As long as they take focus, the shared text editor used by SWT/Cocoa is not affected. This does have a side effect of preventing the Text widget from getting focus like it should though. I think this points to a larger issue within SWT/Cocoa.
Created attachment 265799 [details] SWT-only Snippet to reproduce the issue
New Gerrit change created: https://git.eclipse.org/r/93053
I uploaded a fix to Gerrit. There is a bigger underlying problem with the disconnection between SWT's Focus/Activate events and Cocoa's FirstResponder, but this solution fixes the immediate problem and reduces many of the extra events that are sent. There are still more events sent than on the other SWT platforms, but this removes all of the problematic ones. The biggest change is moving the setActiveControl calls from Control.sendFocusEvent() to Display.checkFocus(). The reason for this is to fix the order of the Activate calls to match SWT behavior on Windows and Linux.
Thanks for investigating & providing the patch! I'll review it for 4.7.
(In reply to Cole Markham from comment #42) > I uploaded a fix to Gerrit. There is a bigger underlying problem with the > disconnection between SWT's Focus/Activate events and Cocoa's > FirstResponder, but this solution fixes the immediate problem and reduces > many of the extra events that are sent. There are still more events sent > than on the other SWT platforms, but this removes all of the problematic > ones. > > The biggest change is moving the setActiveControl calls from > Control.sendFocusEvent() to Display.checkFocus(). The reason for this is to > fix the order of the Activate calls to match SWT behavior on Windows and > Linux. I tested the patch using the snippet in comment#40. I see that there are no focus events sent for the Text boxes. Also, I'm unable to traverse through the widgets using TAB.
(In reply to Lakshmi Shanmugam from comment #44) > (In reply to Cole Markham from comment #42) > > I uploaded a fix to Gerrit. There is a bigger underlying problem with the > > disconnection between SWT's Focus/Activate events and Cocoa's > > FirstResponder, but this solution fixes the immediate problem and reduces > > many of the extra events that are sent. There are still more events sent > > than on the other SWT platforms, but this removes all of the problematic > > ones. > > > > The biggest change is moving the setActiveControl calls from > > Control.sendFocusEvent() to Display.checkFocus(). The reason for this is to > > fix the order of the Activate calls to match SWT behavior on Windows and > > Linux. > > I tested the patch using the snippet in comment#40. I see that there are no > focus events sent for the Text boxes. Also, I'm unable to traverse through > the widgets using TAB. The patch seems to fix the problem but causes other issues as mentioned above. Moving to 4.8
I've been bitten by this buf on Mac. Ouch! Is there a workaround?
(In reply to Lakshmi Shanmugam from comment #44) > (In reply to Cole Markham from comment #42) > > I uploaded a fix to Gerrit. There is a bigger underlying problem with the > > disconnection between SWT's Focus/Activate events and Cocoa's > > FirstResponder, but this solution fixes the immediate problem and reduces > > many of the extra events that are sent. There are still more events sent > > than on the other SWT platforms, but this removes all of the problematic > > ones. > > > > The biggest change is moving the setActiveControl calls from > > Control.sendFocusEvent() to Display.checkFocus(). The reason for this is to > > fix the order of the Activate calls to match SWT behavior on Windows and > > Linux. > > I tested the patch using the snippet in comment#40. I see that there are no > focus events sent for the Text boxes. Also, I'm unable to traverse through > the widgets using TAB. I've updated the gerrit patch to fix the above problems. I'll push it to master after some more testing.
Will this make it into M2?
(In reply to Lakshmi Shanmugam from comment #47) > > I've updated the gerrit patch to fix the above problems. > I'll push it to master after some more testing. I did some more testing with the patch and also compared the results with Windows & Linux. With the latest patch the issue is fixed, but it prevents some focus events from being sent. This prevents the text value from being copied but leads to missing focus events. For example, with the patch, when clicking on Textbox 3 in the SampleApp, the following events are sent: <focus-out List {}> <focus-in text3> <activate Text {}> <activate Composite {}> <activate Composite {}> But, the expected events are below: <focus-out List {}> <focus-in text3 {}> <activate text3 {}> <activate Composite {}> <activate Composite {}> <focus-out text3 {}> <focus-in text 1> <activate Text {}> <activate text3 {}> <focus-out text 1> <focus-in text3 {}> Note that the additional focus events after <activate Composite {}> are caused by the parent.setFocus() in the Activate listener of the Composite. The fix completely blocks those focus events. Running the SampleApp on Windows & Linux, gives us the expected event output. I don't think we should go with the patch as it doesn't fix the root cause and results in missing focus events, which could lead to other problems.
(In reply to Eric Williams from comment #48) > Will this make it into M2? Patch is not good to go. Needs more investigation, moving to M3.
*** Bug 423887 has been marked as a duplicate of this bug. ***
Needs more investigation, moving to M4.
Please set a new target milestone when you plan to work on this.
Moving to 4.12 for investigation.
I devised a new workaround for this bug. Add a FocusListener to the Text control. When focusGained(Event) is called, call setText(String) on the Text control with the correct string value. This assumes that you have stored the value somewhere or are getting it from somewhere.
Moving to 4.13.
*** Bug 405784 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/148512
I've verified the fix with snippet and sample rcp app attached to the bug. Can someone please test the gerrit patch and verify it works in their application? @Sravan, can you please review for RC1?
(In reply to Lakshmi Shanmugam from comment #59) > I've verified the fix with snippet and sample rcp app attached to the bug. > Can someone please test the gerrit patch and verify it works in their > application? > I would like to test it with our RCP application, Archi. However we use a target file that includes a few other dependencies. How do I change the target to include the patched SWT file?
(In reply to Phil Beauvoir from comment #60) > (In reply to Lakshmi Shanmugam from comment #59) > > I've verified the fix with snippet and sample rcp app attached to the bug. > > Can someone please test the gerrit patch and verify it works in their > > application? > > > > I would like to test it with our RCP application, Archi. However we use a > target file that includes a few other dependencies. How do I change the > target to include the patched SWT file? You need to apply the gerrit patch on the SWT source code.
> You need to apply the gerrit patch on the SWT source code. I don't know how to do that. Is this something easily done?
(In reply to Eclipse Genie from comment #58) > New Gerrit change created: https://git.eclipse.org/r/148512 I stepped thru NSTextView.becomeFirstResponder using lldb and I noticed it calls acceptFirstResponder, which is overridden for bug 267138, but not called by the new code. To keep the same behaviour, maybe SWT.READ_ONLY should to be checked before the disabled check, but maybe this combination is not relevant anyway (I haven't tried)? As background for how the bug appears: NSTextView.becomeFirstResponder calls selectText, which indirectly causes the invocation of becomeFirstResponder of other widgets (this selectText is not needed for SWT): * frame #0: 0x00007fff40f230c0 AppKit`-[NSTextView(NSSharing) becomeFirstResponder] + 229 frame #1: 0x00007fff40e86978 AppKit`-[NSWindow _realMakeFirstResponder:] + 493 frame #2: 0x000000011058e6bc libswt-pi-cocoa-4928r15.jnilib`Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSendSuper__Lorg_eclipse_swt_internal_cocoa_objc_1super_2JJ + 140 frame #3: 0x0000000110a46a0b frame #4: 0x0000000110730e70 frame #5: 0x0000000110730b30 frame #6: 0x0000000110730b30 frame #7: 0x0000000110a4ee1c frame #8: 0x000000010ceef6ce libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 frame #9: 0x000000010cf26565 libjvm.dylib`jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 447 frame #10: 0x000000010cf1e769 libjvm.dylib`jni_CallStaticLongMethodV + 268 frame #11: 0x0000000110537826 libswt-cocoa-4928r15.jnilib`callback + 1334 frame #12: 0x000000011053bb0e libswt-cocoa-4928r15.jnilib`fn7_3 + 46 frame #13: 0x00007fff41012171 AppKit`_NSEditTextCellWithOptions + 2280 frame #14: 0x00007fff4101179f AppKit`-[NSTextFieldCell _selectOrEdit:inView:target:editor:event:start:end:] + 357 frame #15: 0x00007fff41011634 AppKit`-[NSCell selectWithFrame:inView:editor:delegate:start:length:] + 46 frame #16: 0x00007fff410115fe AppKit`__26-[NSTextField selectText:]_block_invoke + 94 frame #17: 0x00007fff40d67869 AppKit`+[NSAppearance _performWithCurrentAppearance:usingBlock:] + 84 frame #18: 0x00007fff4101129a AppKit`-[NSTextField selectText:] + 231 frame #19: 0x00007fff410111a5 AppKit`-[NSTextField becomeFirstResponder] + 246
(In reply to Till Brychcy from comment #63) > I stepped thru NSTextView.becomeFirstResponder using lldb and I noticed it I meant NSTextField.becomeFirstResponder
(In reply to Till Brychcy from comment #63) > (In reply to Eclipse Genie from comment #58) > > New Gerrit change created: https://git.eclipse.org/r/148512 > > I stepped thru NSTextView.becomeFirstResponder using lldb and I noticed it > calls acceptFirstResponder, which is overridden for bug 267138, but not > called by the new code. To keep the same behaviour, maybe SWT.READ_ONLY > should to be checked before the disabled check, but maybe this combination > is not relevant anyway (I haven't tried)? > Thanks Till for investigating. In the SampleApp snippet, parent.setFocus() is called in Activate listener. This causes a chain of acceptsFirstResponder and becomeFirstResponder calls. I can see that the last acceptsFirstResponder call is missing. But, didn't see any problem due to that in CCombo. In general, the acceptFirstResponder call is not missing. I also tried overriding NSTextField.selectText() instead of forceFocus(), it fixes the problem but the selection is not preserved. What do you suggest?
(In reply to Lakshmi Shanmugam from comment #65) > What do you suggest? I think your patch is good. The only change is that before this patch, acceptFirstResponder (and then becomeFirstResponder) returned true when SWT.READ_ONLY is set even for disabled widgets, now it returns false. I guess this shouldn't be a problem (I don't think bug 267138 is relevant for disabled widgets).
(In reply to Till Brychcy from comment #66) > (In reply to Lakshmi Shanmugam from comment #65) > > What do you suggest? > > I think your patch is good. > > The only change is that before this patch, acceptFirstResponder (and then > becomeFirstResponder) returned true when SWT.READ_ONLY is set even for > disabled widgets, now it returns false. I guess this shouldn't be a problem > (I don't think bug 267138 is relevant for disabled widgets). Thanks Till. I think returning false is ok since disabled widgets can't become first responder or take focus. Widget.becomeFirstResponder() also returns false for disabled widgets.
Gerrit change https://git.eclipse.org/r/148512 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=80726824d6f7fd5c82a1507c410b3b2fe0820e86
(In reply to Lakshmi Shanmugam from comment #67) > I think returning false is ok since disabled widgets can't become first > responder or take focus. Widget.becomeFirstResponder() also returns false > for disabled widgets. You are right, I didn't consider the check in Widget.becomeFirstResponder(). +1 for the patch without further changes.
Thanks Sravan and Till for reviews!
Verified with build I20190904-2200. https://download.eclipse.org/eclipse/downloads/drops4/I20190904-2200/
