Bug 75812 - [browser] Cursor over Safari Browser does not change
Summary: [browser] Cursor over Safari Browser does not change
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.0   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal with 6 votes (vote)
Target Milestone: 3.3 M4   Edit
Assignee: Grant Gayed CLA
QA Contact:
URL:
Whiteboard:
Keywords: usability
: 75928 103890 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-10-07 11:57 EDT by Benjamin Pasero CLA
Modified: 2006-12-01 14:42 EST (History)
7 users (show)

See Also:


Attachments
A simple double-clickable demonstration of this problem (Snippet128.java) (1.02 MB, application/zip)
2005-11-11 20:44 EST, Eric Seidel CLA
no flags Details
Workaround patch against current 3.3 (1.02 KB, patch)
2006-11-30 22:59 EST, Kelly Norton CLA
no flags Details | Diff
swt patch (1.17 KB, patch)
2006-12-01 13:24 EST, Grant Gayed CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Pasero CLA 2004-10-07 11:57:02 EDT
Hi,

using the browser snippet from the snippet section, hovering over a Link with
the mouse does not change the Cursor to the Hand Cursor. Running Safari
standalone however shows the hand cursor.

Ben
Comment 1 Benjamin Pasero CLA 2004-10-07 12:00:58 EDT
There might be a connection to Bug 75813:

[browser] StatusTextEvent not fired when hovering over Link
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75813
Comment 2 Christophe Cornu CLA 2004-11-05 12:41:37 EST
*** Bug 75928 has been marked as a duplicate of this bug. ***
Comment 3 Christophe Cornu CLA 2004-11-05 12:42:58 EST
Also from Bug 75928:

"using the browser snippet its not possible to select text of a webpage with 
the
mouse. The mouse cursor is not changing to a pipe, as it does in Safari when a
text selection is possible."


Comment 4 Christophe Cornu CLA 2004-11-05 12:45:31 EST
When focus is given, the cursor seems to take the right shape but appears to 
be forced back to the arrow cursor. Need to check if SWT gets in the way.
Comment 5 Christophe Cornu CLA 2005-04-08 10:33:38 EDT
Note to self.

Display.runEnterExit()
if (!cursorWasSet [0]) OS.SetThemeCursor ...
causes trouble in our case.

If we remove it when the control is the Browser, we have another problem: the 
mouse cursor moving over to another SWT widget and not reset to the default 
cursor e.g. hyperlink cursor (hand) over a Label widget.

Cocoa link to set cursors
http://developer.apple.com/documentation/Cocoa/Conceptual/CursorMgmt/Tasks/Chan
gingCursors.html
Comment 6 Todd Brackett CLA 2005-04-14 18:14:27 EDT
Would it be possible to get a clarification on the following statement:  "using the browser snippet from the 
snippet section"?  Perhaps a screenshot or set of steps that we can use to reproduce the problem?
Comment 7 Benjamin Pasero CLA 2005-04-14 18:29:56 EDT
I took this Browser Snippet:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet128.java?rev=HEAD&content-type=text/vnd.viewcvs-markup

Browsing any page running this Snippet on Mac does
1.) not show a Status message when hovering over Links
2.) not show the Hand cursor when hovering over Links
3.) not allow to select Text

This was some time ago, but I dont think one of these where fixed meanwhile.

Everything is working just fine outside SWT using Safari.
Ben
Comment 8 Grant Gayed CLA 2005-07-27 16:11:12 EDT
*** Bug 103890 has been marked as a duplicate of this bug. ***
Comment 9 Eric Seidel CLA 2005-11-11 20:43:02 EST
I've investigated this bug, and it does not seem to be a WebKit issue, but rather more likely to be an 
issue in how SWT is using WebKit.  I have a couple data points:

1.  This issue does not reproduce in the Developer Example: "SimpleCarbonWeb" which uses WebKit 
from a Carbon app.

2.  In GDB I've verified that WebKit is correctly calling into AppKit to set the correct cursor when the 
mouse rolls over a link.  However something is stopping this cursor from ever showing on the screen.  
No other calls are made through the Cocoa cursor management layer (NSCursor), it's possible that 
lower level components (such as Carbon or Java) aren't doing the right thing, however, it's most likely 
that SWT is making some incorrect Carbon cursor call overriding whatever cursor WebKit has set.

I've attached a simple double-clickable App demonstrating this problem to make it easier for future 
investigators to do further debugging.
Comment 10 Eric Seidel CLA 2005-11-11 20:44:34 EST
Created attachment 29815 [details]
A simple double-clickable demonstration of this problem (Snippet128.java)
Comment 11 Billy Biggs CLA 2005-11-24 20:19:24 EST
Adding SSQ who probably has some thoughts on this.
Comment 12 Benjamin Pasero CLA 2006-03-24 02:22:37 EST
is this on the plan for m6 or 3.2?

Ben
Comment 13 Grant Gayed CLA 2006-03-24 08:12:32 EST
Not for M6.  Hopefully this can be investigated for 3.2, but it has lower priority than (for instance) crashes.
Comment 14 thomas comiotto CLA 2006-03-28 17:29:30 EST
Re priorisation: please be aware that this issue renders the browser component useless for apps using safari/mozilla/ie's design mode (wysiwyg editing apps) in terms of preventing the user from selecting, copying, pasting text.

bests
tom
Comment 15 Benjamin Pasero CLA 2006-06-17 06:39:56 EDT
Would be cool to have this issue fixed for 3.3.

Ben
Comment 16 Scott Kovatch CLA 2006-09-21 11:35:30 EDT
I think the complete fix for bug 133597 would fix this as well. If I apply the patch we put in that bug, I can get a hand cursor to briefly appear, but the cursor switches back to an arrow when moving over a link. Steve mentioned that there were one or two other spots that needed a similar change -- I 'd be interested in seeing what happens here with those additional changes.
Comment 17 Scott Blum CLA 2006-10-16 19:24:47 EDT
There is a related problem with is in fact a deal killer for GWT running MacOSX hosted mode.  The manifestation is that JavaScript code executing into the Browser cannot grab mouse capture.  To reproduce, simply open http://maps.google.com in Eclipse's internal browser and try to drag the map.  You can't.  This works just fine in Safari.  Unfortunately, this is now holding up our next product release.  Are there any workarounds?
Comment 18 Steve Northover CLA 2006-10-17 11:02:54 EDT
The GWT grab seems line another issue.  As Scott Kovatch said, we have the code that fixes the cursor but haven't yet applied the patch.  When we do, the cursor should change, but the grab problem won't be fixed.

Scott Blum, can you please enter another bug report for the grab issue (with the steps) and CC me and Grant on it?  Thanks.
Comment 19 Scott Kovatch CLA 2006-10-17 11:25:13 EDT
Steve is right -- the mouse drag problem is one I had to fix when I implemented AWT-in-SWT embedding. HIWebView is responding to kHICommandClick instead of kHICommandMouseDown, so when you click and drag all of the mouse-drag and mouse-up events get swallowed up by the standard click handler. They never make it to the underlying Cocoa WebView, so no live dragging happens. I'll add additional comments to the new bug.
Comment 20 Steve Northover CLA 2006-11-28 20:37:25 EST
Grant, any idea on this?  Both RSS Owl and Azureus want this fixed.
Comment 21 Kelly Norton CLA 2006-11-30 22:59:16 EST
Created attachment 54861 [details]
Workaround patch against current 3.3

I'm attaching a workaround patch that has worked for us in Google Web Toolkit. It is the fix suggested in Christophe Cornu's earlier comment #5 and may suffer the side effects he described. However, we haven't actually observed the cursor not changing on other SWT widgets. Additionally, I tried the patch in RSSOwl and didn't see those side effects there either.

This also works for us in both 3225 and 3318. The patch I've attached is for the current 3.3. It is meant as a workaround; it is in no way a general solution.
Comment 22 Grant Gayed CLA 2006-12-01 13:24:01 EST
Created attachment 54910 [details]
swt patch

Here's the patch that is being applied to swt, thanks to Silenio for the suggestion.
Comment 23 Grant Gayed CLA 2006-12-01 13:25:32 EST
fixed > 1201
Comment 24 Benjamin Pasero CLA 2006-12-01 14:42:54 EST
Here goes one of my oldest bugs. Thx :)!