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

Bug 458516

Summary:	Display.getBounds not reliable in new Chrome tab
Product:	[RT] RAP	Reporter:	John Gymer <jgymer>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	2.3
Target Milestone:	3.0 M6
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description John Gymer

2015-01-27 08:00:16 EST

Display.getBounds() will sometimes (1 out of 10 tries maybe) return a 0x0 display size.
This only happens in Chrome (on Windows).  I'm using Chrome 40.0, and only when entering a RAP application via an HTML link that open the app in a new Chrome browser tab (open in new Chrome window is OK).

For example... my HTML page simply has:

<html>
<head>
</head>

<body>
	<p>
		<a href="http://127.0.0.1:9090/test" target="new">Test</a>
	</p>
</body>

</html>

My RAP application simply says:

/* DEMONSTRATES Display.getBounds issue in Chrome tabs */
package bug.snippet;

import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.FormAttachment;
import org.eclipse.swt.layout.FormData;
import org.eclipse.swt.layout.FormLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Shell;

public class Bugsy {
	Display display;
	Shell shell;
	Label lab;
	public void begin() {
		display = new Display();
		System.out.println("display size: " + display.getBounds().width + " x " + display.getBounds().height);
		shell = new Shell(display, SWT.APPLICATION_MODAL|SWT.CLOSE);
		shell.setFullScreen(true);
		shell.setText("My Shell");
		FormLayout layout = new FormLayout();
		shell.setLayout(layout);
		
		lab = new Label(shell, SWT.BORDER);
		lab.setText("my label");
		FormData fd = new FormData();
		fd.left = new FormAttachment(0, 10);
		fd.top = new FormAttachment(0, 10);
		fd.right = new FormAttachment(100,-10);
		fd.bottom = new FormAttachment(100,-10);
		lab.setLayoutData(fd);

		shell.open();
	}
}

To reproduce the error, simply launch Chrome at the HTML page, then click the link.  Then close the RAP application that just opened in the new browser tab.  Then click the link again, and close the new tab.  Repeat this process a few times... it averages around 10 attempts before the Display.getBounds() returns 0,0.

I tried inserting a delay after discovering getBounds() gave 0,0... but this did not help... once it decides that the display is 0,0 size, it doesn't matter how long I wait, it will always return it as 0,0 for that session.

Am using RAP 2.3 (cannot go to 3.0 yet, as this has to run with Tabris too).
Also tested with IE and Firefox, both of which are OK.

Thanks, John

Comment 1 Ivan Furnadjiev

2015-01-30 05:28:27 EST

I've tried to reproduce it today without success on both RAP 2.3.1 and 3.0M4. Maybe a timing issue.

Comment 2 John Gymer

2015-01-30 05:55:35 EST

Hi Ivan,
Thanks for trying it out... seems a bit strange though as it is relatively easy to reproduce here. We've tried on 2 different laptops, both with Win7Pro 64-bit (if that makes any difference).
As I said, it happens on average 10% of the time, which obviously would make the application 'feel' unreliable, even though once you're into it, it is good.
The use-case here is that a customer has their own existing application (different technology) that they want to link into the RAP app via a hyperlink, which launches in another browser tab, so it is quite a reasonable requirement.
Is there anything else we can provide that would help you reproduce it?
Thanks, John

Comment 3 Ivan Furnadjiev

2015-01-30 06:13:54 EST

Is this a problem with Chrome 40 only? Did you try any previous Chrome version - 39 for example... or Safari on Mac? The related code is in rwt.html.Window.js#getInnerWidth/Height. By looking into the code it's possible to return 0 in some cases (document.documentElement.(clientWidth) is missing). Maybe this "webkit" switch there is not needed anymore. innerWidth/Height is working for me with Chrome 40. But we have to check with Safari as well. We have an idea to not detect Chrome as "webkit" anymore, but "blink" - see bug 441564.

Comment 4 Ivan Furnadjiev

2015-02-02 06:02:13 EST

John, could you try to apply the change https://git.eclipse.org/r/#/c/40877/ in RAP 2.3? Does it fix your problem?

Comment 5 John Gymer

2015-02-02 07:32:39 EST

I'm not building RAP locally from source, so isn't easy for me to apply. The RAP 2.3.1 that I'm using is the one that comes from the Tabris 1.4 nightly.
Is there some (simple) way to apply the changes to that?

Comment 6 Ivan Furnadjiev

2015-02-12 06:33:58 EST

John, change https://git.eclipse.org/r/#/c/40877/ has been merged to master. The easiest way to test it is to get the RWT bundle from git, apply the patch and run your application in development mode by selecting the RAP RWT bundle from your workspace (instead of target).

Comment 7 Ivan Furnadjiev

2015-03-11 09:49:42 EDT

John, I'll mark this bug as fixed. Please reopen if the issue persists with RAP 3.0 M6+.