Bugzilla – Full Text Bug Listing
| Summary: | [Dialogs] double clicking on help button or disabled button may resize the dialog | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tom Hofmann <eclipse> | ||||||
| Component: | UI | Assignee: | Susan McCourt <susan> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | bradleyjames, c.hilmes, curtispd, daniel_megert, gheorghe, gunnar, icemank, immaneni, jcalder, jli1, Karice_McIntyre, Kevin_McGuire, konstantin, makandre, markus.kell.r, mihneag, Mike_Wilson, ns03ja, polifr, pombredanne, sayoub, snorthov, sridharkuna, susan, urs.frei | ||||||
| Version: | 3.2 | ||||||||
| Target Milestone: | 3.3 M6 | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Curtis, have you tried using the tray dialog on Linux-GTK? It seems to work fine on Windows. I did, but I did not test double clicking in particular. Karice, do you know why double clicking on the button bar resizes the dialog in the first place? I can replicate on Windows. I should mention that it appears to be the introduction of the help button toolbar that appears to be causing the problem. I didn't see anything obvious after taking a quick look at the code though. Yikes - the JFace dialog class has introduced (@since 3.2) a restore size mouse listener that restores the dialog to its computed size and this is called when the toolbar the help button sits on is double clicked. I think Susan knows more about this. It does not depend on the help button at all - double clicking anywhere on the button bar has the effect of resizing the dialog to its original size. This is ok (I believe this is a feature), but should only be activated for the button bar area, but not any controls on it. You can also double click on any disabled (Finish for example) button to have the same effect of resizing the dialog. It's only more 'interesting' with the help button because this also adds the help pane. For reference see bug 116906 and especially bug 137315. the intention is that clicking in the button bar (but not the buttons) resizes the dialog. The implementation hooks onto any composites, it must be that the help button is implemented with a composite. I'll look into this one. The issue here is that the help button is implemented as a toolbar with one item, not a button. Not sure why. The code that hooks the restore size listener hooks it on all composites, under the assumption that the double click will not be received if an atomic child is clicked. This is not true for tool bar items, since they are not full-fledged controls. Clicking in a tool bar item will trigger the event on the tool bar. Disabled buttons may also exhibit this behavior on some platforms. In all cases, note that the dialog will only resize to its original default size. If it has never been resized, you won't see a change. Instead of hooking the restore size listener on all composites, we could choose to ignore toolbars...(but then later when someone sticks a table tree in the button bar, do we ignore those? coolbars? spinners?) It's a brittle solution. We can't just hook it on the button bar composite (see bug #137315). We can't hit test the point after getting the event because we still won't detect tool items without a special case for tool bar composites. My preferred solution is that the help button be implemented with a button rather than a toolbar. I don't see solving this for 3.2/RC4. I don't believe this is a showstopper. However... ...one could argue that new users are most likely to need the help button, most likely to accidentally double-click it, and most likely to be confused if the whole dialog resizes. However if they haven't previously resized the dialog, everything will be fine. I also don't think this is a critical problem. McQ - thoughts? Agreed. Ok to defer. (In reply to comment #9) > Instead of hooking the restore size listener on all composites, we could > choose to ignore toolbars... [..] A solution to try could be this: add the mouse listener to all children of the button bar whose getClass() is Composite (but not to subclasses of Composite). *** Bug 142921 has been marked as a duplicate of this bug. *** *** Bug 140061 has been marked as a duplicate of this bug. *** I can take a look at this one post-3.2. I think Markus' suggestion in comment #12 would be the way to go unless you want to use a regular button instead of toolbar for the help button. *** Bug 143314 has been marked as a duplicate of this bug. *** *** Bug 147071 has been marked as a duplicate of this bug. *** note that we need a solution for the disabled button case in addition to the help button. Curtis, I can take this one back if you like, since it affects more than just the help button... Feel free to reassign (I can send you more of my bugs if you like :-)) FYI, I tried switching to a Button instead of a ToolBar with a single ToolItem, however the result was a bit ugly; I get a full button border on XP even if I use SWT.FLAT. I opened bug 147120 for this on SWT, but I suspect it's a platform limitation. I will admit that using a ToolBar here is not right though, since it's not a tool bar, it's just one button. I'll wait for the response to bug 147120, and if it's fixable we can switch, if it's a platform limitation I personally would rather live with using a ToolBar rather than having an ugly button on every dialog. Created attachment 44459 [details]
screenshot using Button
-1 for transforming the help toolbar button into a plain button, since this would prevent a fix for bug 127852. And as Susan said, we need a general solution, not only one for the help button (e.g. the one from comment 12). Thanks for checking it out, Curtis. I'll take this bug back and look for a more general solution that handles the disabled button case. I tried Markus' suggestion (check for getClass == Composite.class). It solves the "double click on help button" problem and would solve any other problems with dialog layouts that use composites such as toolbars, trees, etc. inside the button bar or as parents of the button bar. For this reason I think it's worth releasing the fix. However, it does not solve the disabled button problem on Windows (haven't checked others.) I tried adding a check for the cursor control at the time of the click (Display.getCursorControl()), but if a button is disabled, the parent composite will be reported as the cursor control. Not sure how to solve that one. cc'ing Steve for input. (Steve, I'll try to summarize the problem succinctly.) We want to hook listeners in dialogs such that double-clicking in the "blank space" will trigger our listener (which restores the size of the dialog.) The problem we have is detecting "blank space." If we hook the listener only on composites, (control.getClass() == Composite.class), it mostly works, except that we will also receive the listener when the user clicks on a disabled button. Can you suggest any way in SWT at that point to determine that the user actually clicked on a disabled button? Using Display.getCursorControl() doesn't work, it returns the composite as long as the button is disabled. (note: Steve is currently on vacation) In the meantime (awaiting Steve's comment), I've released the partial fix >20060711, which will fix the help button issue. Will consider a backport to 3.2.1. Leaving this open for now. If anyone has a strong opinion as to whether leaving this feature in is worth the problem with disabled buttons, please post here. I have a problem similar to this defect. I have a dialog that has a composite and this composite has a Tree control. When the user double clicks on any of the tree items, the dialog shrinks and the dialog become ugly. I知 suing Eclipse 3.2 on Win XP. Thanks Sameh Ayoub Advisory Software Developer. (613) 591-7041 Rational IBM Canada Sameh, can you try it on the next integration build of Eclipse (or a nightly build after 7/11/2006)? I have a partial fix released that in theory should fix your problem. The fact that you get this problem with a tree tells me that either your tree is a child of the button bar, or that it is a direct parent of the button bar. This is atypical. Could you verify that this is true for your dialog? Otherwise there may be another bug lurking. Since my dialog is a modeless, I don’t have a button bar. I used to override the method createDialogArea and createButtonBar (in this method I used to return the parent composite parameter and do nothing, because I don’t need to have ok and cancel buttons). After removing these two methods and override the createContents method. The problem doesn’t show up any more. Thanks for your help. This fixed my problem, but the original problem of miss-calculating the size of the dialog is not fixed yet. For me I don’t need this feature for now. Another way to avoid the hassle with inadvertent doubleclicks would be bug 116906 comment 6: remove the doubleclick listener and install a menu on getClass()==Composite.class children of the button bar (only for those which don't already have a menu). This would still allow the user to open the context menu on an empty button, but the menu item name would make clear what happens. When a control is disabled, mouse events go to the parent. This is standard SWT behavior and makes sense. If the events were to go to the control, then a disabled custom control would have to check if it was enabled before it performed and action. Display.getCursorControl() returns the control that is under the cursor that will get mouse events. It might be possible to add new API include disabled controls. Alternately, I can write a quick snippet that recurively descends down the widget tree and tests to see whether a point is included in the control. *** Bug 152783 has been marked as a duplicate of this bug. *** I just discovered that newly re-introduced "feature" when someone pointed me to it. I know that it is documented in the platform tips and tricks. However, this is the most surprising UI behavior I have seen... at first I really thought that this "shrinking the wizard on double click behavior" was a bug. Most of the times, wizards are too small as default, even for most platform provided wizards. Note that clicking on a disabled button in that area also triggers wizard's resizing. Could it be possible at the minimum that some of the newly introduced method could be overriden, or that this really weird resizing behavior can be prohibited in some way? Or just plain removed? I cannot understand the value of that resizing, which seems not working perfectly in all case, or looks really badly surprising in any case... It makes wizards plain weird, imho. Cordially Any update on a target date of when this problem might be fixed? and which version of Eclipse? -- Thanks in advance. This bug is currently assigned a 3.3 target milestone which means it is considered important to fix in 3.3, but has not yet been assigned a particular 3.3 "Mx" milestone.
This bug discusses the surprise of the resize when inadvertantly double clicking a disabled button, but there have been other bugs saying the whole feature is an unwelcome surprise.
I invite any of you watching this bug to comment on the discussed solutions. That is, do you find the current gesture useful enough to be fixed or should we be considering an alternative?
Options I see:
- keep the feature and add workaround code to prevent activation on disabled buttons, etc.
- make the feature a preference
- disable the feature and don't provide an alternative
- disable the feature and provide an alternative
- a "restore dialog to original size" menu option
- other ideas?
My current favorite is the menu.
*** Bug 162112 has been marked as a duplicate of this bug. *** *** Bug 170372 has been marked as a duplicate of this bug. *** (In reply to comment #38) > I invite any of you watching this bug to comment on the discussed solutions. > That is, do you find the current gesture useful enough to be fixed or should we > be considering an alternative? > > Options I see: > - keep the feature and add workaround code to prevent activation on disabled > buttons, etc. > - make the feature a preference > - disable the feature and don't provide an alternative > - disable the feature and provide an alternative > - a "restore dialog to original size" menu option > - other ideas? Where would the menu be? At the least I vote for removing it. Also if memory serves me right this isn't resizing to the original size but resizing to the preferred size. If I override Dialog.getInitialSize() this value isn't maintained when resizing via the double click listener. Is there any way to override Dialog to not to add the listener? I don't see any benefits of this feature. Instead it was reported as a bug by our QE team. I think you should get rid of the doubleclick listener and add a context menu instead. The doubleclick will continue to cause trouble, and a context menu would not hurt anybody (since it's only added to controls of type Composite, but not to subtypes). And it's at least as discoverable as the doubleclick. Get rid of it! I think the listener is clearly too unpopular for us to keep. I am generally not keenm on menus in dialogs as users don't expect to see them. Perhaps a drop down would be better than a popup. I'll be tracking this for the next while as Susan is currently on leave. Adding Kevin for a best practises perspective. Created attachment 58579 [details]
replace doubleclick by context menu
I find this behaviour mindboggling. AFAIK, double-click on the shell title bar is the only place resize would be expected. This is in keeping with the fact that the actual min/max controls are contained in the title bar (thus double-click behaviour related to them makes some sense). The same is not true for random space within a dialog. I agree with Tod that menus in wizards isn't expected. I just checked several windows apps (MS Word, iTunes, Thunderbird, Ableton Live, WinZip, Lotus Notes) and the only use of menu in dialogs is the "What's This?" menu item for controls/text in MS Word. Maybe I'm missing something, but seems we should just pull the behaviour. Its non standard and the current implementation makes unusable wizards with the Help tray open (some feature!). The double click behavior has caused enough trouble to warrant yanking it. I've reopened bug #116906. See that bug for the original rationale. Kevin McG - we still need some suggestions as to what we should be doing. Please read bug #116906 for the original feature request. I think it is reasonable that we restore the dialog to its preferred size using some gesture. (In reply to comment #47) Re "it's non standard": The difference is that Eclipse dialogs are generally resizable as soon as they contain content that can dynamically grow or shrink. Microsoft prefers to throw non-resizable dialogs at users, which is a royal pain in most places (have you ever tried to add something to the PATH variable?). => MS does not have this problem because they have a more severe GUI blooper (aka "The Keyhole Problem": http://www.aristeia.com/TKP/). I agree that the "right" solution would be another button in the dialog's titlebar, or an additional item in the titlebar's context menu. But I don't think that's feasible on all windowing systems. The best solution I could come up with was the context menu (comment 46), which is maybe also hard to discover, but at least does not interfere with other common gestures. Context menus are not very common but a pulldown might be a less unusual option. This functionality is useful so I would be reluctant to pull it but it is hard to make it clear what is going on. OK, I understand better now the problem we were trying to solve. This is a long thread so I will at least for my own sake try to recap: It seems we are all in agreement that the feature is useful/needed because our dialogs can be resized. It was recognized from the beginning that its not easily discoverable. As this is not a critical operation, perhaps that's not a huge problem. However, usually gestures have some other more immediate affordance to support them, like double click in title bar corresponds to the max/restore button, and its a bit of a problem that we don't have one here. I think we are all correctly hesitant to add a new control (either in the title bar which is likely impossible anyway, or elsewhere). We could add a menu, but that too is pretty non standard so people won't discover it easily, it would be the only menu item, and I don't want to encourage people to add more. The pulldown would have similar problem of only one item in it, and has the additional oddity that usually pulldowns in dialogs change the model state, while instead this one operates on the dialog itself. I have no clever ideas. Perhaps we need to separate this into three problems: 1) The feature isn't easily discovered and aught to have a primary affordance 2) The computation of what is "blank area" has problems with respect to disabled controls etc. 3) The current behaviour is buggy - when help tray is open, the recomputed size is wrong because it doesn't take the tray into account In combination, these issues have created much confusion. If we could fix (2) and (3) then I'd be ok with leaving the feature in, with a forward looking bug to decide on a better affordance for discovery (1). If we can't fix both (2) and (3) then we need to consider pulling the feature since it seems to be causing more harm than good in its present state. Susan, for (3) does this mean though that we'd need to revisit every dialog to correct its initial size computation to take into account the help tray? Issue #3 is covered in bug #162124, and there is a proposed patch there. It should not be difficult, and this bug should be fixed since the issue is unrelated to the particular gesture that invokes the feature. #2 occurs because the platform, and therefore SWT, propagate events to the parent when a control is disabled. But we can manually prevent this from occurring by doing our own hittesting (see comment #34). I will proceed on those. The objections to the feature in this bug do seemed tied in part to the bugginess. Please chime in if you feel the feature should be removed even if the bugs should be fixed. sorry, I meant... Please chime in if you feel the feature should be removed even if the bugs *are* fixed. (In reply to comment #53) > Please chime in if you feel the feature should > be removed even if the bugs *are* fixed. +1 to retain feature provided other bugs fixed. My guess is that if the other bugs had not been present, we'd have not seen this bug surface. Fixed in HEAD >20070215. The listener now ignores doubleclick if it detects a visible, disabled child is positioned under the click. Note that we DO respond to the double click if the disabled widget is invisible. Otherwise it would not be apparent why double click did not work. (For example, the Replace button is invisible/disabled in some pages of the search dialog). Anyone who still wants double-click feature to be yanked or replaced with a menu, please annotate bug #116906. I tested it and still think that we should get rid of this behavior: - it is not detectable - it is non-standard - it is not always available at the same position (depends on the layout) - it is very confusing for users that don't know about this "feature" and accidentally double-click in the hot-spot area. The amount of discussion and developer energy this has consumed is a good lesson on why consistency in the UI is important. For me to want us to leave this feature in, I would need to believe both that this function is important for the usability of the wizard framework, and that most users will understand the behavior and not be surprised by it. I tend to think we've proven neither of these, so I would agree with Dani. yet another bug report (#175545) on this. I'm yanking the double click at this point and leaving bug #116906 open (with no milestone) to track the original feature request. Bug #175545 will be the referenced bug report for yanking it. I'll move Markus' patch (context menu) to bug #116906 so it's not lost. verified I20070320-0010, WinXP. double click feature has been removed per bug #175545 *** Bug 188195 has been marked as a duplicate of this bug. *** *** Bug 204839 has been marked as a duplicate of this bug. *** |
3.2 RC2 - open a wizard (e.g File -> New...) - double click on the help button > help is shown and the entire dialog resized to its default size < expected: only double clicking on the tab bar proper resizes the dialog, but not double clicking a button On a side note, the resizing is really not helpful while help is being shown, as this makes the main dialog area extremely narrow.