Community
Participate
Working Groups
When using the SWT Browser widget the mouse events (mouseDown, mouseUp, mouseDoubleClick) do not fire after adding a mouselistener to the Browser widget (browser.addMouseListener). This can be recreated by creating a browser widget object with the mouse listener and then clicking inside of the browser window.
Not does the mouse listener not work on a browser, the global event filter doesn't work on it either. Might be related of course. This means the Browser class works totally different compared to all the other SWT widgets... ....getDisplay().addFilter(SWT.MouseDown, new Listener() { public void handleEvent(Event event) { // never called for mouse events inside the browser, but does // get called for all other mouse events. System.out.println(">> MouseDown " + event); } });
Note that this bug prevents an important application of the new mouse button support for buttons 4 and 5 (bug #7101). These buttons cannot be assigned to the usual "back" and "forward" actions in a browser.
On Windows platforms there is a similar problem with ActiveX components and key events (see bug #49699). Maybe these bugs are related.
I dont think the missing Events of the Browser widget (Mouse, Key, Focus) are caused by bugs, but simply because they are not yet implemented. I really hope they will become implemented in the 3.1 dev cycle. Ben
Yes. We are investigating support for these for 3.1.
Perhaps this project might help: http://justthe.net/jrex/ While I should probably make a feature request to get something like this fully supported, it might give some ideas about how to handle events when dealing with an embedded browser. BTW, the URL for the main project is jrex.mozdev.org. David
(In reply to comment #5) > Yes. We are investigating support for these for 3.1. Has anything become of this investigation? Are there plans or code already written to solve this issue? I also hope that the mouse events are cancellable to allow for removal of right context clicks before they reach the native browser object.
> I also hope that the mouse events are cancellable to allow for removal of right > context clicks before they reach the native browser object. That can be achieved by calling setMenu(new Menu()) on the Browser. Ben
I've taken an initial look at this and have partial solutions. Pages with frames are much more problematic than pages without. As a side note, this does work on Mac with the exception of MouseMove.
(In reply to comment #9) > I've taken an initial look at this and have partial solutions. Pages with > frames are much more problematic than pages without. > > As a side note, this does work on Mac with the exception of MouseMove. > Grant, Is there any chance that this critical Browser problem will be addressed any time soon? Thanks. ... Phil
There are currently other work items with higher priority. However since there are patches that capture a partial solution I should be able to at least revisit this during the 3.2 timeframe. The merits of having a partial solution (assuming that time constraints prevent further investigation) will be determined then.
This will likely not be in for 3.2; there are too many higher priority bugs in the browser and gtk 64-bit spaces for the time that remains according to the recently-posted endgame plan.
To update, the following mouse events are now fired on linux-gtk (both browser styles) and win32 (if Browser style is SWT.MOZILLA): down, up, doubleClick, enter, exit, move Also, all of these except for move are fired on OSX (both browser styles). So what's left, hopefully will be addressed for 3.3: - win32 (all of these for SWT.NONE browser style) - OSX (just move for both browser styles)
Hello Grant, It seems that on Windows we have to wait anyway because the Mozilla Browser style will be available in 3.3 release only. I'm especially interrested in the move event, including using addFilter. Moreover having these events on Window with SWT.NONE is critical because I think forcing the users to install Firefox and XULRunner on their system is not practical. Thank you, Francis
To update, this is now implemented on win32 for Browsers with style SWT.NONE. So this leaves MouseMove on OSX.
*** Bug 211224 has been marked as a duplicate of this bug. ***
Any plans we can get this for 3.4?
You mean just MouseMove on OSX, right? Grant, we sould close this bug (49696) as "fixed" with a note that the only remaining problem is addressed in bug 211224, and then reopen 211224. This bug is too 'global', and the title is too confusing now that the original bug is almost completely fixed.
>You mean just MouseMove on OSX, right? Yes.
(In reply to comment #18) > You mean just MouseMove on OSX, right? Safari (OS X 10.4.11) misses MouseMove, MouseUp, and DragDetect (on links). I really need the first two. I've opened bug 212416 for DragDetect (also missing on GTK/Mozilla).
re: comment 18 Yes this makes sense. I've reopened bug 211224 and am marking this report as fixed in 3.3.
