Bug 212392 - [Browser] Browser widget does not send location changing event when losing focus in MouseUp
Summary: [Browser] Browser widget does not send location changing event when losing fo...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Grant Gayed CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-10 07:22 EST by Markus Keller CLA
Modified: 2019-09-06 16:10 EDT (History)
2 users (show)

See Also:


Attachments
SnippetHideShellInActivate2.java (3.00 KB, text/plain)
2007-12-10 07:22 EST, Markus Keller CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2007-12-10 07:22:26 EST
Created attachment 84855 [details]
SnippetHideShellInActivate2.java

N20071209-0010

For the enriched hovers in text editors, I need to replace a shell with tool trim by a shell with resize trims and scroll bars when the user clicks into the first shell.

I tried to replace the shells when the MouseUp event happens, but all my approaches failed because the browser widget does not send out location changing events after it lost focus or became invisible.

When you run the attached snippet, click the "Show" button and then click the link in the browser, no location changing event is triggered. Same problem when you toggle the comments for the following two lines:

                    shell.setFocus();
//                    shell2.setVisible(false);

Both variants work fine when you click the "Link Button" instead of the the link in the Browser widget.
Comment 1 Grant Gayed CLA 2008-01-17 14:27:11 EST
The problem is caused by IE notifying us of the MouseUp before it has processed it as a link click.  The processing of the link click fails in this case because the focus has been moved to another control.  So the only way to make this case work is for the focus to be moved a little later.

There are two ways to do this.  One would be for the Browser to post (defer)mouse events, which would require new api because the current api only allows controls like Browser to send (immediate) events.  The other way would be to change your MouseUp listener to use an asyncExec, which would look like:

public void handleEvent(Event e) {
    System.out.println("MouseUp: " + e.widget);
    display.removeFilter(SWT.MouseUp, this);
    //XXX: Browser widget does not send location changing event when
    // losing focus or becoming invisible in MouseUp:
    display.asyncExec(new Runnable() { // <---
        public void run() {
            if (shell.isDisposed()) return;
            shell.setFocus();
            //   shell2.setVisible(false);
        }
    });
}

One other possibility, if you only wanted to move the focus when a link was clicked, would be to do this in your LocationListener.changing(...) implementation instead.  I'm not sure if this applies to your case.

Are either of these changes doable at your level (using asyncExec or moving the focus change to LocationListener.changing(...))?
Comment 2 Markus Keller CLA 2008-01-17 19:16:24 EST
(In reply to comment #1)

I currently do this in an asyncExec, but the need to drive the event loop in between makes my code a little brittle. I haven't seen major problem so far, so I guess we can live with that (unless hell breaks loose in M5).

The LocationListener.changing(...) event is coming in even later, and the disadvantage of that approach is that I don't get any notification if the user didn't click a link (I already need to drive the event loop and work with timeouts to handle this correctly...).
Comment 3 Eclipse Webmaster CLA 2019-09-06 16:10:32 EDT
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.