Bug 162124 - [Dialogs] Double click to resize dialog should be tray-aware
Summary: [Dialogs] Double click to resize dialog should be tray-aware
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M6   Edit
Assignee: Susan McCourt CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2006-10-24 14:21 EDT by Curtis d'Entremont CLA
Modified: 2007-03-20 11:02 EDT (History)
3 users (show)

See Also:


Attachments
Makes double-clicking restore the _current_ preferred size (1.84 KB, patch)
2006-12-27 20:54 EST, Matt McCutchen CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Curtis d'Entremont CLA 2006-10-24 14:21:30 EDT
I20061024-0800

- Open a dialog with a help button, like preferences
- Click help button to open help tray
- Double click in toolbar to resize dialog

Problem: Dialog goes back to original size but still contains tray, so everything is out of whack and too small.

I think this resize feature must be tray-aware.
Comment 1 Susan McCourt CLA 2006-10-26 21:15:11 EDT
should look at this for 3.3 while revisiting the double-click approach in general
Comment 2 Matt McCutchen CLA 2006-12-27 20:54:29 EST
Created attachment 56215 [details]
Makes double-clicking restore the _current_ preferred size

Dialogs with "Details >>" expanders, such as some progress dialogs, seem to have the same problem.

Double-clicking currently sets a dialog to what its preferred size was when it was created, instead of its currently preferred size.  Is there a reason for this?  I changed my copy of Eclipse (patch attached) to use the current preferred size, and that fixed the problems with both help trays and "Details >>" expanders.
Comment 3 Susan McCourt CLA 2007-02-13 17:37:59 EST
we may end up punting the double-click behavior, but I will look this over so that any alternate gesture we might use would get the size right.
Comment 4 Susan McCourt CLA 2007-02-14 13:40:06 EST
The patch is simple and reasonable.  
Fixed in HEAD >20070214

>Double-clicking currently sets a dialog to what its preferred size 
>was when it was created, instead of its currently preferred size.  
>Is there a reason for this? 
Not a good one.  The original intent was to ensure the calculation occurred at the correct time in the creation sequence while reducing the number of times the calculation had to occur.  But of course it introduced this problem.

Side note:  Dialogs don't currently remember whether the help tray is open.  So when the bounds are recorded with the help tray open, the dialog will later open with these larger bounds and no help tray.  This has always been an issue independent of double-clicking, but now that double clicking is help tray aware, I foresee the feature request that dialogs also remember whether the help tray was open...
Comment 5 Paul Webster CLA 2007-02-14 15:10:03 EST
Could we back this patch out?  It was killing the save as dialog test and then all of the other tests in the UI Test Suite

PW
Comment 6 Paul Webster CLA 2007-02-14 15:13:36 EST
TESTROOT
org.eclipse.ui.tests.UiTestSuite
org.eclipse.ui.tests.dialogs.UIAutomatedSuite
org.eclipse.ui.tests.dialogs.UIDialogsAuto
testSaveAs(org.eclipse.ui.tests.dialogs.UIDialogsAuto)
org.eclipse.swt.SWTException: Graphic is disposed
	at org.eclipse.swt.SWT.error(SWT.java:3478)
	at org.eclipse.swt.SWT.error(SWT.java:3401)
	at org.eclipse.swt.SWT.error(SWT.java:3372)
	at org.eclipse.swt.graphics.Image.getBounds(Image.java:1131)
	at org.eclipse.swt.widgets.Label.computeSize(Label.java:128)
	at org.eclipse.swt.layout.FormData.computeSize(FormData.java:116)
	at org.eclipse.swt.layout.FormData.getWidth(FormData.java:145)
	at org.eclipse.swt.layout.FormData.getLeftAttachment(FormData.java:200)
	at org.eclipse.swt.layout.FormLayout.computeWidth(FormLayout.java:263)
	at org.eclipse.swt.layout.FormLayout.layout(FormLayout.java:330)
	at org.eclipse.swt.layout.FormLayout.computeSize(FormLayout.java:239)
	at org.eclipse.swt.widgets.Composite.computeSize(Composite.java:219)
	at org.eclipse.swt.layout.GridData.computeSize(GridData.java:478)
	at org.eclipse.swt.layout.GridLayout.layout(GridLayout.java:214)
	at org.eclipse.swt.layout.GridLayout.computeSize(GridLayout.java:159)
	at org.eclipse.swt.widgets.Composite.computeSize(Composite.java:219)
	at org.eclipse.jface.dialogs.Dialog.saveDialogBounds(Dialog.java:1195)
	at org.eclipse.jface.dialogs.Dialog.close(Dialog.java:986)
	at org.eclipse.jface.dialogs.TrayDialog.close(TrayDialog.java:143)
	at org.eclipse.ui.dialogs.SaveAsDialog.close(SaveAsDialog.java:120)
	at org.eclipse.ui.tests.harness.util.DialogCheck.assertDialogTexts(DialogCheck.java:85)
	at org.eclipse.ui.tests.dialogs.UIDialogsAuto.testSaveAs(UIDialogsAuto.java:135)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at junit.framework.TestCase.runTest(TestCase.java:164)
	at junit.framework.TestCase.runBare(TestCase.java:130)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:120)
	at junit.framework.TestSuite.runTest(TestSuite.java:230)
	at junit.framework.TestSuite.run(TestSuite.java:225)
	at junit.framework.TestSuite.runTest(TestSuite.java:230)
	at junit.framework.TestSuite.run(TestSuite.java:225)
	at junit.framework.TestSuite.runTest(TestSuite.java:230)
	at junit.framework.TestSuite.run(TestSuite.java:225)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:58)
	at org.eclipse.pde.internal.junit.runtime.UITestApplication$1.run(UITestApplication.java:122)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3467)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3107)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2264)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2228)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2103)
	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:457)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:452)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:101)
	at org.eclipse.pde.internal.junit.runtime.UITestApplication.start(UITestApplication.java:52)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:146)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:169)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:476)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1124)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1099)

which seems to leave the save as dialog up and kills many more tests:
org.eclipse.ui.tests.api.ApiTestSuite


testOpenWorkbenchWindow(org.eclipse.ui.tests.api.IWorkbenchTest)
org.eclipse.swt.SWTException: Graphic is disposed
	at org.eclipse.swt.SWT.error(SWT.java:3478)
	at org.eclipse.swt.SWT.error(SWT.java:3401)
	at org.eclipse.swt.SWT.error(SWT.java:3372)
	at org.eclipse.swt.graphics.Image.getBounds(Image.java:1131)
	at org.eclipse.swt.widgets.Label.wmDrawChild(Label.java:621)
	at org.eclipse.swt.widgets.Control.WM_DRAWITEM(Control.java:3639)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:3488)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4159)
	at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method)
	at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2114)
	at org.eclipse.swt.widgets.Label.callWindowProc(Label.java:96)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:3562)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:4172)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2200)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3102)
	at org.eclipse.ui.tests.harness.util.UITestCase.processEvents(UITestCase.java:222)
	at org.eclipse.ui.tests.harness.util.UITestCase.doTearDown(UITestCase.java:214)
	at org.eclipse.ui.tests.harness.util.UITestCase.tearDown(UITestCase.java:203)
	at junit.framework.TestCase.runBare(TestCase.java:131)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:120)
	at junit.framework.TestSuite.runTest(TestSuite.java:230)
	at junit.framework.TestSuite.run(TestSuite.java:225)
	at junit.framework.TestSuite.runTest(TestSuite.java:230)
	at junit.framework.TestSuite.run(TestSuite.java:225)
	at junit.framework.TestSuite.runTest(TestSuite.java:230)
	at junit.framework.TestSuite.run(TestSuite.java:225)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:58)
	at org.eclipse.pde.internal.junit.runtime.UITestApplication$1.run(UITestApplication.java:122)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3467)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3107)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2264)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2228)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2103)
	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:457)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:452)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:101)
	at org.eclipse.pde.internal.junit.runtime.UITestApplication.start(UITestApplication.java:52)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:146)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:169)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:476)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1124)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1099)

PW
Comment 7 Susan McCourt CLA 2007-02-14 15:15:36 EST
sorry for not rerunning all the tests.  I'll back it out and try again.
Comment 8 Matt McCutchen CLA 2007-02-14 15:25:26 EST
(In reply to comment #4)
> Side note:  Dialogs don't currently remember whether the help tray is open.  So
> when the bounds are recorded with the help tray open, the dialog will later
> open with these larger bounds and no help tray.  This has always been an issue
> independent of double-clicking, but now that double clicking is help tray
> aware, I foresee the feature request that dialogs also remember whether the
> help tray was open...

It looks to me that when one double-clicks, the dialog does not save its current preferred size; it saves a special value DIALOG_DEFAULT_BOUNDS that tells it to open next time at its preferred size *then*.  Thus, the right thing happens whether or not the help tray is in the same state when the dialog next opens as when the user double-clicks.

IMHO, DIALOG_DEFAULT_BOUNDS should be stored on closing if the user has never resized the dialog since opening or the last double-click, not if the current size happens to equal the preferred size.  This would require an extra variable to remember whether the user has resized the dialog, but it would eliminate the crashing Paul is getting.
Comment 9 Susan McCourt CLA 2007-02-14 15:51:15 EST
Fixed (again) >20070214.

First of all, I want to say that the crash was due to some "freebie" behavior I added on top of Matt's patch.  His patch was simple and reasonable.

While thinking about the issue of resize due to dynamic content, I added some code on dialog close to check against preferred size.  I should have opened a separate bug for that anyway, now I have.  See bug #174225. 

Third of all, Matt's last suggestion (comment #8) is a good one and will be taken up in 174225.
Comment 10 Susan McCourt CLA 2007-03-20 11:02:39 EDT
verified I20070320-0010, WinXP.
double click feature has been removed per bug #175545