Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 332096

Summary:

Browser.print() steals focus

Product:

[Eclipse Project] Platform

Reporter:

e fergus <efergus>

Component:

SWT

Assignee:

Felipe Heidrich <eclipse.felipe>

Status:

RESOLVED FIXED

QA Contact:

Severity:

major

Priority:

CC:

eclipse.felipe, Silenio_Quarti

Version:

3.6

Target Milestone:

3.7 M5

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
patch	none

Description e fergus

2010-12-07 18:37:36 EST

I have two browsers, one which acts as a rich text editor, and the other which shows the result within a canvas widget.  The result on canvas is actually an image of the browser, so as the user types into the editor, the browser which is not visible is printed and that image is drawn on the canvas widget.  When the second browser is printed, it steals focus from the editor browser, which interrupts user input.

I believe that a call to print() should not affect the current focus, as was the behaviour in SWT for platform 3.5.

I do not see this behaviour in XP.

Comment 1 e fergus

2010-12-07 19:12:39 EST

I have traced the issue down to Control.printWidget().  One of the two following sections is causing the focus change:

if (!OS.IsWinCE && OS.WIN32_VERSION >= OS.VERSION (6, 0)) {
   OS.SetWindowLong (hwnd, OS.GWL_STYLE, (bits1 & ~OS.WS_CHILD) | OS.WS_POPUP);
   OS.SetWindowLong (hwnd, OS.GWL_EXSTYLE, bits2 | OS.WS_EX_TOOLWINDOW);
}

OR

if (!OS.IsWinCE && OS.WIN32_VERSION >= OS.VERSION (6, 0)) {
   OS.SetWindowLong (hwnd, OS.GWL_STYLE, bits1);
   OS.SetWindowLong (hwnd, OS.GWL_EXSTYLE, bits2);
}

Comment 2 Felipe Heidrich

2010-12-08 10:17:30 EST

does the problem happen only to Browser ?
does the problem happen only to Windows 7 ?

Comment 3 e fergus

2010-12-08 13:32:41 EST

(In reply to comment #2)
> does the problem happen only to Browser ?
> does the problem happen only to Windows 7 ?

Sorry but I only have Windows XP & Windows 7 available so I cannot test on other platforms.  Out of those two, I was only able to produce this issue on Windows 7.

I can confirm that this is an issue for more than just the browser widget.  I replaced the browser with a button and that same call to print() did steal the focus from my editor.

Comment 4 Felipe Heidrich

2010-12-08 13:53:28 EST

(In reply to comment #3)
> I can confirm that this is an issue for more than just the browser widget.  I
> replaced the browser with a button and that same call to print() did steal the
> focus from my editor.
thank you

Comment 5 Felipe Heidrich

2010-12-13 11:54:17 EST

Works for me with this code:
public static void main(String[] args) {
	Display display = new Display();
	final Shell shell = new Shell(display);
	shell.setLayout(new GridLayout());
	Text text = new Text(shell, SWT.SINGLE);
	text.setText("text.");
	final Button button = new Button(shell, SWT.PUSH);
	button.setText("button.");
	display.addFilter(SWT.KeyDown, new Listener() {
		public void handleEvent(Event e) {
			if (e.keyCode == SWT.F1) {
				Image image = new Image(e.display, 200, 200);
				GC gc = new GC(image);
				boolean result = button.print(gc);
				gc.dispose();
				image.dispose();
				System.out.println("Button printed okay ? " + result);
			}
		}
	});
	shell.pack();
	shell.open();
	while (!shell.isDisposed()) {
		if (!display.readAndDispatch())
			display.sleep();
	}
	display.dispose();
}


Run the test and give the focus to text control, hit F1, note focus stayed in the text control (and the console shows that the button has printed okay).

Comment 6 e fergus

2010-12-13 15:15:58 EST

(In reply to comment #5)
> Works for me with this code:
> ...
> Run the test and give the focus to text control, hit F1, note focus stayed in
> the text control (and the console shows that the button has printed okay).

You're correct.. the code you give does not produce the issue. Here is some code that will (which I couldn't reproduce using a button either.. but hopefully it's enough for you to pinpoint the issue):

public static void main(String[] args) {
	final Display display = new Display();
	final Shell shell = new Shell(display);
	shell.setLayout(new GridLayout());
	final Browser browser = new Browser(shell, SWT.NONE);
	browser.setText("<html><body contentEditable=true><p>&nbsp;</p></body></html>");
	final Browser browser2 = new Browser(shell, SWT.NONE);
	browser2.setVisible(false);
	display.addFilter(SWT.KeyDown, new Listener() {
		public void handleEvent(Event e) {
			if (e.keyCode == SWT.F1) {
				browser2.setText(browser.getText());
			}
		}
	});
	browser2.addProgressListener(new ProgressAdapter() {
		public void completed(ProgressEvent event) {
			Image image = new Image(display, 200, 200);
			GC gc = new GC(image);
			boolean result = browser2.print(gc);
			gc.dispose();
			image.dispose();
			System.out.println("Browser printed okay ? " + result);
		}
	});
	shell.pack();
	shell.open();
	while (!shell.isDisposed()) {
		if (!display.readAndDispatch())
			display.sleep();
	}
	display.dispose();
}

Comment 7 e fergus

2011-01-17 18:30:50 EST

any idea if there are plans to fix this issue?

Comment 8 Felipe Heidrich

2011-01-19 11:04:12 EST

This was caused by the fix for bug 299714, I'm looking into it.

Comment 9 Felipe Heidrich

2011-01-20 16:11:21 EST

Created attachment 187242 [details]
patch

The problem is that we are reparenting the browser to the desktop and then reparenting back. This reparenting is just to work around and should not change the state of the shell, but focus events are being fired and the state of the shell is changing. The patch puts back the savedFocus control to the right control so the focus goes to the right place when all the reparenting dance is over.

Please try the patch or the next nigthly build and let me know if the case is fixed.

Comment 10 Felipe Heidrich

2011-01-20 16:12:28 EST

Fixed in HEAD