Community
Participate
Working Groups
Build Identifier: SWT 3.7M1 When embedding a Browser in an AWT application (but other controls may have the same issue), cursor behavior is messed up between AWT and SWT. Here are several things I noticed: 1. When an AWT control has the focus, the cursor does not change when hovering the SWT controls. 2. When a text field of a XULRunner browser is focused (caret), hovering an AWT component does not always change the cursor (generally the first time only). 3. When a text field of a Safari browser is focused (caret), hovering other DOM elements do not change the cursor, this until we hover an AWT component or click elsewhere. Reproducible: Always Steps to Reproduce: 1. Open an SWT_AWT application containing a browser and an AWT control with a defined cursor. 2. Give focus to the SWT control and see what happens when you hover the AWT component, and vice versa.
Created attachment 178094 [details] A simple SWT_AWT example to experiment the issue
Same thing for me with Mac OS X 10.6.4 - Java 1.6.0_20
(In reply to comment #0) > 2. When a text field of a XULRunner browser is focused (caret), hovering an AWT > component does not always change the cursor (generally the first time only). > 3. When a text field of a Safari browser is focused (caret), hovering other DOM > elements do not change the cursor, this until we hover an AWT component or > click elsewhere. Actually, for these two, I think the core problem is that mouse moves aren't being delivered to the browser. Run Snippet128, which creates a Browser control and some navigation buttons. Load iGoogle in this snippet and your example. In Snippet128 as you move over sections of the page the borders highlight. That doesn't happen in the SWT_AWT case. You can see it in the modified test case.
Created attachment 178456 [details] test case with event listeners Same as the first test but with additional mouse move listeners in AWT and SWT.
> Same as the first test but with additional mouse move listeners in AWT and SWT. I just tried it and indeed on Windows hovering the Browser generates SWT events and hovering Swing generates AWT events. On Mac, it always generates AWT events or SWT events depending on where you clicked and which control has the focus. Would it be a focus issue between the embedded Shell and the JFrame? In any case, feel free to rename the bug according to the identified cause ("mouse events are not delivered properly" or something).
(In reply to comment #5) > Would it be a focus issue between the embedded Shell and the JFrame? > In any case, feel free to rename the bug according to the identified cause > ("mouse events are not delivered properly" or something). That's my current thinking. Clicking on the embedded shell isn't moving the focus off the JButton. The WebKit browser implementation generates mouse events from the DOM events, and we aren't getting a native mouse-moved DOM event in this case.
(In reply to comment #6) > > That's my current thinking. Clicking on the embedded shell isn't moving the > focus off the JButton. The WebKit browser implementation generates mouse events > from the DOM events, and we aren't getting a native mouse-moved DOM event in > this case. Sadly, this is not the issue. Because we're hosted in an AWT window here, Shell's windowSendEvent override is never called to generate the mouse events, but I think I can fix that.
> but I think I can fix that. I keep my fingers crossed! :) By-the-way, do you know if there are other event types which could have similar issues when in AWT?
(In reply to comment #8) > By-the-way, do you know if there are other event types which could have similar > issues when in AWT? After some changes I haven't checked in yet, I verified that all events now get generated for embedded Shells in AWT. Unfortunately there's still some problem related to the cursor and mouse-move events not making it into the browser control. Something isn't quite right when the Shell doesn't have the window field set.
Thanks to the WebKit source I think I have an idea what's going on. WebHTMLViews rely on getting a private NSMouseMoved notification sent to them to generate the proper DOM events. I think something in the responder chain isn't doing the right thing and the notification doesn't fire. Unfortunately I'm now being blocked by 324329 with the latest pre-release of Java 6 on Snow Leopard, even at no magnification.
(In reply to comment #10) > Thanks to the WebKit source I think I have an idea what's going on. > WebHTMLViews rely on getting a private NSMouseMoved notification sent to them > to generate the proper DOM events. I think something in the responder chain > isn't doing the right thing and the notification doesn't fire. Right analysis, wrong reason. All WebHTMLViews register for mouse-moved events on the window, but the main WebHTMLView generates the DOM event. To get the event, mouseMoved: is sent to all of the NSResponders in the responder chain, and eventually the window receives the mouseMoved: message. But with the use of F-Script I found that in the AWT embedded case the AWT's subclass of NSWindow is not in the responder chain! So, the window never receives the mouseMoved: and the WKMouseMovedNotification doesn't fire. This explains why Snippet128 works because the SWT window doesn't do anything odd with the responder chain. This appears to be a bug on the AWT's part, but I've found a workaround. I just need to clean it up for 3.7M3.
Fixed > 20100917. Also fixes a general problem of Browsers getting two SWT.MouseMove events every time the mouse moved. Embedded shells will now receive activate and deactivate, move and resize events.
