As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact bugzilla-admin@mozilla.org
Last Comment Bug 66834 - autocomplete/popup widgets should not block clicks outside of themselves
: autocomplete/popup widgets should not block clicks outside of themselves
Status: NEW
[adt3][Hixie-P0] fixed:os/2 ?:win32...
: access, helpwanted
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: P1 major with 15 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Neil Deakin
Mentors:
: 79303 82173 82494 82787 84388 87751 91901 94012 95237 103725 103815 105744 106799 109095 118731 130810 131135 135132 139960 147471 152660 156412 157336 157878 160518 176678 179652 227233 342628 (view as bug list)
Depends on:
Blocks: 55416 atfmeta 158464
  Show dependency treegraph
 
Reported: 2001-01-27 18:26 PST by Jesse Ruderman
Modified: 2012-08-21 23:46 PDT (History)
65 users (show)
asa: blocking1.8b2-
asa: blocking1.8b5-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
No brainer fix (749 bytes, patch)
2002-11-04 01:22 PST, Aaron Leventhal
no flags Details | Diff | Splinter Review
New better fix -- does correct thing for each widget on each platform (5.20 KB, patch)
2002-11-04 16:25 PST, Aaron Leventhal
mikepinkerton: review+
hyatt: superreview+
Details | Diff | Splinter Review
Have OS/2 follow Win32 (706 bytes, patch)
2002-11-06 13:13 PST, jhp (no longer active)
no flags Details | Diff | Splinter Review
proposal patch for gtk (1.72 KB, patch)
2002-12-05 19:19 PST, Robin Lu
no flags Details | Diff | Splinter Review

Description User image Jesse Ruderman 2001-01-27 18:26:41 PST
Steps to reproduce:
1. Open Mozilla.
2. Chop off the last part of the url you're at and wait a few seconds.
   (This should make the location bar drop-down appear.)
3. Click or start a drag in the content area or in the location bar.

Result: the drop-down goes away, but nothing else happens.  This is annoying 
when trying to focus the page for scrolling and when trying to move the 
insertion point within the location bar.

Expected result: my click (or start of drag) should succeed and the drop-down 
should go away.
Comment 1 User image Alec Flett 2001-01-29 11:13:14 PST
this is an xptoolkit bug, issues with popups
Comment 2 User image Mike Pinkerton (not reading bugmail) 2001-01-29 16:08:57 PST
hrm. right now, all popups/menus/tooltips eat the click by design. I guess we
need a mechanism to specify to the widget code not to eat the click. I notice
that gRollupListener implements nsIMenuRollup so perhaps we could stick
something on that.

cc'ing hyatt just for fun.
Comment 3 User image Alec Flett 2001-05-25 08:13:01 PDT
*** Bug 82494 has been marked as a duplicate of this bug. ***
Comment 4 User image Alec Flett 2001-05-25 08:15:02 PDT
also see bug 21390, marked INVALID
I like the idea of specific widgets indicating that they don't want to eat the
click.
Comment 5 User image Matthew Paul Thomas 2001-05-26 08:11:36 PDT
Yah, this is a duplicate of bug 21390, which I think really should be fixed. In 
that bug you can see Mac users wanting a click outside a popup just to cancel 
the popup, and Windows/Linux users wanting a click outside a popup to activate 
the item under the cursor. Why? Because that's how other apps on their 
respective OSes usually behave. The same applies to this particular popup -- I 
think allowing the behavior to be inconsistent between popups would be rather 
unfortunate.
Comment 6 User image Jesse Ruderman 2001-05-31 23:06:31 PDT
*** Bug 82173 has been marked as a duplicate of this bug. ***
Comment 7 User image Jesse Ruderman 2001-05-31 23:10:06 PDT
The location bar drop-down should not eat clicks outside of itself on any 
platform.  See bug 82494, takes two clicks to use the search button next to the 
location bar.

Also, I think an autocomplete drop-down is conceptually different from other 
drop-downs or menus, because the user explicitly activates the menus but not 
autocomplete drop-downs.  Let's keep this separate from bug 21390.
Comment 8 User image Claudius Gayle 2001-06-07 10:42:08 PDT
*** Bug 84388 has been marked as a duplicate of this bug. ***
Comment 9 User image Mike Pinkerton (not reading bugmail) 2001-06-11 12:26:16 PDT
*** Bug 84924 has been marked as a duplicate of this bug. ***
Comment 10 User image Jesse Ruderman 2001-06-20 17:31:45 PDT
*** Bug 79303 has been marked as a duplicate of this bug. ***
Comment 11 User image sairuh (rarely reading bugmail) 2001-06-20 17:38:19 PDT
thx to jesse for pointing this out to me. methinks i'm running into this all
platforms. here's my testcase --but let me know if anyone else thinks this is a
different bug [perhaps bug 82787?].

1. click in the URLbar.
2. if you hit pageDown, pageUp, or spacebar, this will trigger the URLbar
history droplist [expected].
3. click in the content area of browser window --the URLbar droplist goes away
as expected, but...
4. try to scroll in the browser window using the keyboard [pageDown, PageUp,
spacebar, arrow keys...].

result: unable to scroll. instead, the URLbar droplist drops down.

workaround: need to doubleclick or click twice in the content area to make
scrolling via keyboard work again. a singleclick doesn't seem to suffice.
Comment 12 User image gary_Cope 2001-06-25 22:44:55 PDT
*** Bug 87751 has been marked as a duplicate of this bug. ***
Comment 13 User image Jesse Ruderman 2001-06-26 13:53:23 PDT
See also bug 86643, Autocomplete dropdown is included in the tab order.
Comment 14 User image Jesse Ruderman 2001-07-26 00:49:44 PDT
*** Bug 91901 has been marked as a duplicate of this bug. ***
Comment 15 User image Akkana Peck 2001-08-06 10:59:54 PDT
This issue has been the main bug driving me to use browsers other than Mozilla
in the last few months.  It takes two clicks to transfer keyboard focus to other
apps, and sometimes I have to click three or four times in the mozilla content
area just to get focus out of the urlbar so that page up/down keys will work.
Comment 16 User image Mike Pinkerton (not reading bugmail) 2001-08-06 11:07:47 PDT
clicking to other apps shouldn't be affected by this bug (if we eat clicks to 
other apps, that's a different bug). also, if you have to click 3-4 times, that 
too is a different bug with key focus setting. i've never seen either of these 
problems.
Comment 17 User image Akkana Peck 2001-08-06 15:04:28 PDT
Clicking to other apps is affected because the dropdown is grabbing the mouse
focus, so the first click anywhere on the screen just dismisses the dropdown and
isn't passed through.  (You can tell because the cursor changes when the
dropdown is displayed, and doesn't change when you leave the mozilla window as
it should.) Presumably it does something different on Mac, but this is what it
does on Linux (both kde and gnome) with pointer focus.
Comment 18 User image Grey Hodge (jX) 2001-08-13 14:15:40 PDT
*** Bug 94012 has been marked as a duplicate of this bug. ***
Comment 19 User image Nathan 2001-08-13 15:22:42 PDT
The first click anywhere on the screen dismisses the dropdown and
*is* passed through for me on Win2k 20010806 and WinME 20010805.
Comment 20 User image Akkana Peck 2001-08-13 16:29:12 PDT
Definitely not passed through for me on Linux, using either kde or gnome/sawfish
and pointer focus.
Comment 21 User image Jesse Ruderman 2001-08-21 19:20:03 PDT
It's not passed through on WinNT 4 either.
Comment 22 User image Jesse Ruderman 2001-10-15 15:30:52 PDT
*** Bug 103725 has been marked as a duplicate of this bug. ***
Comment 23 User image Matthew Paul Thomas 2001-10-19 09:24:33 PDT
*** Bug 95237 has been marked as a duplicate of this bug. ***
Comment 24 User image sairuh (rarely reading bugmail) 2001-10-30 16:00:12 PST
*** Bug 103815 has been marked as a duplicate of this bug. ***
Comment 25 User image sairuh (rarely reading bugmail) 2001-11-01 19:39:02 PST
*** Bug 106799 has been marked as a duplicate of this bug. ***
Comment 26 User image R.K.Aa. 2001-11-08 12:01:13 PST
*** Bug 109095 has been marked as a duplicate of this bug. ***
Comment 27 User image Mike Pinkerton (not reading bugmail) 2001-11-28 13:55:23 PST
not going to get to it -> toolkit
Comment 28 User image Aaron Leventhal 2001-12-12 11:34:52 PST
*** Bug 105744 has been marked as a duplicate of this bug. ***
Comment 29 User image Jonas Jørgensen 2002-01-08 09:35:58 PST
*** Bug 118731 has been marked as a duplicate of this bug. ***
Comment 30 User image Peter Trudelle 2002-02-13 18:14:01 PST
nsbeta1+ per Nav triage team
Comment 31 User image Peter Trudelle 2002-02-21 11:59:39 PST
Mass move of nsbeta1+ bugs that didn't have a valid MachV milestone to mozilla1.0.
Comment 32 User image Tuukka Tolvanen (sp3000) 2002-04-03 07:48:36 PST
*** Bug 135132 has been marked as a duplicate of this bug. ***
Comment 33 User image Hogarth 2002-04-03 15:56:22 PST
A stroodle in your noodle: This issue affects focus on mouse and comment 16.
Basically I have my window manager set up so that if I move my mouse pointer
over a window, it activates it. Mozilla's autocomplete dropdown prevents this
from happening requiring that I actually click in the window in order to get focus.

This I find annoying. Mozilla should not be preventing my window manger from
doing it's job properly as per it's configuration. It seems the widget is eating
way to many events in a nasty way and as such is preventing Mozilla playing nice
with my window manager.

This may be Linux only but Windows has a similar feature with TweakUI I believe.
I just don't know if it affects things under Windows.
Comment 34 User image Dean Tessman 2002-04-03 16:35:47 PST
TweakUI's X-Mouse works properly for me in Win2K.
Comment 35 User image Chris Lyon 2002-04-09 19:15:38 PDT
*** Bug 131135 has been marked as a duplicate of this bug. ***
Comment 36 User image Vadim Berezniker 2002-04-09 19:24:48 PDT
This was a problem when the clear url button was introduced (not there anymore).
If you wanted to clear the URL with the drop-down open, you'd have to click
twice  on the X to clear it. Once to close the autocomplete widget and one to
actually clear the URL.
Comment 37 User image Peter Trudelle 2002-04-17 10:52:36 PDT
nsbeta1- per Nav triage team
Comment 38 User image Jerry Baker 2002-04-17 14:13:24 PDT
In response to Comment #19, the click is *not* passed through on Windows XP Pro 
either (Moz 0.9.9).
Comment 39 User image Jesse Ruderman 2002-04-25 14:36:33 PDT
*** Bug 139960 has been marked as a duplicate of this bug. ***
Comment 40 User image Jerry Baker 2002-05-27 14:35:45 PDT
Mass removing self from CC list.
Comment 41 User image Jerry Baker 2002-05-27 15:01:30 PDT
Now I feel sumb because I have to add back. Sorry for the spam.
Comment 42 User image Boris Zbarsky [:bz] (still a bit busy) 2002-05-28 04:59:00 PDT
*** Bug 147471 has been marked as a duplicate of this bug. ***
Comment 43 User image Olav Vitters 2002-07-09 01:21:40 PDT
*** Bug 156412 has been marked as a duplicate of this bug. ***
Comment 44 User image Olav Vitters 2002-07-09 01:21:47 PDT
*** Bug 130810 has been marked as a duplicate of this bug. ***
Comment 45 User image Olav Vitters 2002-07-09 01:24:19 PDT
*** Bug 152660 has been marked as a duplicate of this bug. ***
Comment 46 User image Aaron Leventhal 2002-10-07 15:32:28 PDT
This is a serious usability issue.

-> Trudelle, for retriage.
Comment 47 User image Aaron Leventhal 2002-10-07 19:09:57 PDT
This appears to be a general problem with any popup menu. Once one is open, any
click outside of it is swallowed, and will only cancel the current menu.
Comment 48 User image Peter Trudelle 2002-10-07 22:07:55 PDT
->varga, helpwanted in case navtriage minuses it again.
Comment 49 User image Samir Gehani 2002-10-24 14:23:26 PDT
Nav triage team: nsbeta1+/adt3
Comment 50 User image Kenneth Herron 2002-10-25 11:00:56 PDT
*** Bug 176678 has been marked as a duplicate of this bug. ***
Comment 51 User image Kenneth Herron 2002-10-25 11:03:49 PDT
*** Bug 157878 has been marked as a duplicate of this bug. ***
Comment 52 User image Michael Lefevre 2002-11-01 13:11:01 PST
*** Bug 160518 has been marked as a duplicate of this bug. ***
Comment 53 User image Andrew Hagen 2002-11-01 14:09:12 PST
*** Bug 157336 has been marked as a duplicate of this bug. ***
Comment 54 User image Aaron Leventhal 2002-11-04 01:15:40 PST
I have a fix for this.
Comment 55 User image Aaron Leventhal 2002-11-04 01:22:04 PST
Created attachment 105063 [details] [diff] [review]
No brainer fix

This has been like this for a long time. Apparently popups eat any mouse events
that are outside of them. When certain events happen, the popup gets rolled up,
but the event gets eaten.

Blake came along while back and fixed it so that right clicks outside the popup
could make it through. Now with this patch left clicks and middle clicks
outside the popup don't get eaten.

I'm not sure which of these events really need to get eaten by popups, if any -
should we be letting more of these through? (WM_ACTIVATE, WM_NCLBUTTONDOWN,
WM_LBUTTONDOWN, WM_RBUTTONDOWN, WM_MBUTTONDOWN, WM_NCMBUTTONDOWN,
WM_NCRBUTTONDOWN, WM_MOUSEACTIVATE, WM_MOUSEWHEEL, uMSH_MOUSEWHEEL,
WM_ACTIVATEAPP, WM_MENUSELECT, WM_MOVING, WM_SIZING, WM_GETMINMAXINFO).

Seeking r=
Comment 56 User image Aaron Leventhal 2002-11-04 01:30:10 PST
*** Bug 82787 has been marked as a duplicate of this bug. ***
Comment 57 User image Mike Pinkerton (not reading bugmail) 2002-11-04 08:16:00 PST
Comment on attachment 105063 [details] [diff] [review]
No brainer fix

this will break menus. you do not want the click processed when you click
outside a menu.
Comment 58 User image Aaron Leventhal 2002-11-04 09:59:17 PST
Pinkerton, can you be more specific?

I open IE, pull down the file menu and click on a link and it works there.

What exactly about processing the click outside the menus will break menus?
Comment 59 User image David Hyatt 2002-11-04 15:12:48 PST
Looks like Win32 eats clicks for menulists/selects, but doesn't eat clicks for 
menus (context/menu bar/etc.).

Mac eats clicks for all of these.

Can anyone say what GTK does?  We're going to need some #ifdefs in the menu 
dismissal listener code to get this right I think.
Comment 60 User image David Hyatt 2002-11-04 15:16:06 PST
Another idea (to avoid #ifdefs) would be to make the boolean parameter 
represent a widget type instead of a consume flag.  Then the various widget 
implementations could say e.g., "Oh, it's a menulist, I can decide what I 
should do with that."
Comment 61 User image Aaron Leventhal 2002-11-04 15:34:20 PST
Here's the chart that I intend to follow:

Eat clicks that occur outside of menu (rollup popup only)?

       Menus     Autocomplete     Comboboxes
Mac     Eat           No              Eat
Win     No            No              Eat     
Unix    Eat           No              Eat
Comment 62 User image Aaron Leventhal 2002-11-04 16:25:49 PST
Created attachment 105135 [details] [diff] [review]
New better fix -- does correct thing for each widget on each platform

Seeking r=/sr=
Comment 63 User image David Hyatt 2002-11-04 16:56:46 PST
Comment on attachment 105135 [details] [diff] [review]
New better fix -- does correct thing for each widget on each platform

Aren't there two places in the menu dismissal listener file that call
CaptureRollupEvents? Do you want to patch both?  

sr=hyatt
Comment 64 User image David Hyatt 2002-11-04 16:57:21 PST
Comment on attachment 105135 [details] [diff] [review]
New better fix -- does correct thing for each widget on each platform

sr=hyatt
Comment 65 User image Aaron Leventhal 2002-11-04 17:08:08 PST
Sigh, this patch doesn't help with gtk -- we might need to file a separate bug
for that. In widget/src/gtk/nsWindow.cpp, it doesn't look like we do anything with
the aConsumeRollupEvent parameter in CaptureRollupEvents().

Are the events getting swallowed by  
nsWindow::OnButtonPressSignal(GdkEventButton *aGdkButtonEvent)
?

Perhaps that method needs to pay attention to a member variable set by the
aConsumeRollupEvent parameter in CaptureRollupEvents()?
Comment 66 User image Mike Pinkerton (not reading bugmail) 2002-11-05 07:24:46 PST
in IE on win2k, clicking outside a menu eats the click. this is different from
what your patch does.
Comment 67 User image Aaron Leventhal 2002-11-05 08:03:56 PST
Pinkerton, Hyatt and I both got the same results.

Pull down the file menu in IE, and then try clicking a link or in the URL bar.
Or, open notepad, pull down the file menu and click in the text.
Comment 68 User image Mike Pinkerton (not reading bugmail) 2002-11-05 08:10:35 PST
i was on crack. ignore me.
Comment 69 User image Mike Pinkerton (not reading bugmail) 2002-11-05 08:39:10 PST
Comment on attachment 105135 [details] [diff] [review]
New better fix -- does correct thing for each widget on each platform

r=pink

i really don't care for the name (GetConsumeOutsideClicks). There's no setter,
and other routines in the api that are PRBool "getters" don't have this naming
semantic (IsMenuBar() is an example). How about just "ConsumeOutsideClicks"?
Comment 70 User image Aaron Leventhal 2002-11-05 08:40:58 PST
Okay done.
Comment 71 User image Jerry Baker 2002-11-05 11:10:10 PST
Clicks outside of menus are not eaten on WinXP. I tried in both IE and Notepad.
Comment 72 User image Akkana Peck 2002-11-05 14:23:45 PST
Mentioned in several of the bugs duped to this one, but not here: a big part of
the problem at least on unix, which the patch doesn't fix, is that the grab is
systemwide: you can't click in any other app either as long as the mozilla app
has a menu up.
Comment 73 User image Aaron Leventhal 2002-11-05 19:17:51 PST
Windows fix checked in, leaving open for other platforms.
Comment 74 User image Aaron Leventhal 2002-11-05 19:20:40 PST
->Akkana, for widget/src/gtk fixes

widget/src/gtk/OnButtonPressSignal should not always return early if
gRollupWidget is true. 

We need to remove the extra return statement and let it fall through to the last
statement, if a variable like gCaptureClicksOutsidePopup is set. We need to
invent that variable and set it from the nsWindow::CaptureRollupEvents()
method's last parameter. Then we can avoid the early return here if that's false.

Comment 75 User image jhp (no longer active) 2002-11-06 13:13:48 PST
Created attachment 105368 [details] [diff] [review]
Have OS/2 follow Win32

Patch to make OS/2 follow the windows route.
Comment 76 User image jhp (no longer active) 2002-11-06 13:22:55 PST
I am a little confused.  The patch here seems to disable consuming clicks for
menus, but doesn't seem to address the autocomplete issue.  Has it been decided
to keep the current behaviour for the autocomplete menu?
Comment 77 User image Aaron Leventhal 2002-11-06 13:41:35 PST
Eat clicks that occur outside of menu (rollup popup only)?

       Menus     Autocomplete     Comboboxes
Mac     Eat           No              Eat
Win     No            No              Eat     
Unix    Eat           No              Eat


The Windows specific behavior was for menus only.

For autocomplete, the patch makes us call nsIWidget::CaptureRollupEvents(blah,
blah, PR_FALSE) on all platforms. However, we still need platform specific
patches to make sure we use the last parameter in CaptureRollupEvents(), for
determining whether to eat clicks or not.

Believe it or not, clicks in the Mozilla window are always supposed to be eaten
when a combobox is pulled down (they just roll the combobox up).

However, there's yet another problem in gtk where clicks outside the Mozilla
window are even getting eaten, when a combobox is pulled down.
Comment 78 User image Aaron Leventhal 2002-11-08 11:15:30 PST
Is there anyone from the Sun team who can take this bug from Akkana? The
explanations I give at the end should give you a head start.
Comment 79 User image Akkana Peck 2002-11-08 11:56:32 PST
Blizzard, does gtk2 do this right?  Who owns menus in the gtk/gtk2 widget
library, or has some familiarity with the menu code?
Comment 80 User image Christopher Blizzard (:blizzard) 2002-11-08 13:38:37 PST
This is easy to fix.  Don't make the autocomplete widget grab the pointer or the
keyboard.  Make it pop down on a focus out event.
Comment 81 User image djk 2002-11-12 12:11:41 PST
I see a problem with the w32 solution that was checked in:
I can't dismiss a menu by clicking on the menu item once the menu has dropped down.

1. Single click on the Edit menuitem.
2. Wait a short amount of time (1s or so? It's hard to tell).
3. Single click on the Edit menuitem.

Actual Results:
Menu does not roll up; it stays visible and usable.

Expected Results:
Menu rolls up.

Workaround:
If you do not wait long between clicks, the menu dismisses ->  double clicking
the menu item effectively rolls the menu back up.
Comment 82 User image NorthMan 2002-11-12 12:50:28 PST
I can duplicate the behavior in comment 81 on win32 Windows Millenium build
2002110808
Comment 83 User image Aaron Leventhal 2002-11-12 14:56:36 PST
Yes, how annoying -- please file a spinnoff bug for that specific issue.
Comment 84 User image djk 2002-11-13 06:11:26 PST
Ah, I see someone already filed it as bug 179567.
Comment 85 User image Jan Varga [:janv] 2002-11-13 12:35:27 PST
*** Bug 179652 has been marked as a duplicate of this bug. ***
Comment 86 User image Akkana Peck 2002-12-02 17:20:01 PST
Sending this back to widgets where it belongs.  If someone wants to tell me what
widget implements this and does the grab, I'll be happy to code up a patch
making it not do that, but it really ought to be done by someone familiar with
the code and why we're doing it the current way.
Comment 87 User image Christopher Blizzard (:blizzard) 2002-12-02 21:55:37 PST
I, for one, would love to see autocomplete not grab at all.  This is something
that has been asked for by lots of people that I talk to.  I don't really like
it either.

That being said, we need to emulate platform behaviour as closely as possible. 
With gtk/gtk2 popups and dropdowns always eat the mouse event and are popped
down.  As near as I can tell we're pretty close to platform behaviour, at least
with that particular platform.
Comment 88 User image Robin Lu 2002-12-05 19:19:04 PST
Created attachment 108440 [details] [diff] [review]
proposal patch for gtk

This patch will enable gtk aware the aConsumeEvent. I did not touch the grab
code because I think it's more like just because the check_roll_up eats the
event. 

However, only with this patch the problem could not be sovled, at least in my
gtk mozilla, because the aConsumeEvent being sent to me is always TRUE. I found
the parentTag of the autocomplete in my mozilla is 'popupset' instead of
'textbox'. Could anyone explain it to me?

Blizzard, I don't mean to break the platform routing. I just provide a choice
here. :)
Comment 89 User image Dean Tessman 2003-01-02 16:50:02 PST
Is it just me or do context menus on Windows still eat clicks?
Comment 90 User image John Morrison 2003-01-02 17:07:34 PST
(What I see on win2k). Context menus eat clicks in mozilla/xul. However, 
context menus do not eat clicks in File Explorer, Nav4.x and IE6.
Comment 91 User image Dean Tessman 2003-01-02 17:33:11 PST
Aaron, did this patch not also address context menus?
Comment 92 User image Aaron Leventhal 2003-01-02 17:35:09 PST
I forgot to test context menus, but we should open a separate bug on them.
Comment 93 User image Dean Tessman 2003-01-03 08:34:49 PST
Filed bug 187575 for context menus.

(Re: comment 66, you may have been looking at the Favorites menu in IE6.  That
menu blocks clicks but no other menu does.)
Comment 94 User image Jesse Ruderman 2003-01-03 16:21:38 PST
This is also a problem for autocomplete in the content area in Phoenix.  For
example, if I type something into the search box at http://www.alltheweb.com/,
clicking on the Search button makes the autocomplete dropdown go away but
doesn't submit the search.
Comment 95 User image Jesse Ruderman 2003-01-05 02:24:14 PST
Comment 73 says this is fixed on Windows, but jesus_X and I still see this bug
on Windows XP.  That might be related to why a regression from this patch (bug
187631, "Menus not clearing when cursor is off menu focus") happens on XP but
not other versions of Windows...
Comment 96 User image Dean Tessman 2003-01-05 12:30:24 PST
Jesse: Bug 187631 does happen for me on Win2K.  See bug 179567 comment 26.
Comment 97 User image Aaron Leventhal 2003-01-06 12:39:44 PST
Jesse, how do I test forms autocomplete in Mozilla? I need to know what the XUL
looks like for the autocomplete popup.
Comment 98 User image Jesse Ruderman 2003-01-06 19:47:58 PST
To test form autocomplete, I guess you would build Phoenix.
Comment 99 User image Jesse Ruderman 2003-01-07 17:12:19 PST
Now this WFM on Windows XP (with Mozilla url bar autocomplete).  Maybe the fix
for bug 187575 fixed this on XP, or fixed a regression on all Windows platforms.
 Either way, it works now :)
Comment 100 User image Jesse Ruderman 2003-01-07 17:41:29 PST
Marking this bug as fixed.  I moved the gtk patch to bug 188126.  Was the OS/2
patch checked in, or does that also need its own bug?
Comment 101 User image Akkana Peck 2003-01-07 18:32:40 PST
Reopening: this bug is platform ALL, and being suddenly wfm on win xp isn't
enough to mark it fixed on all platforms.
Comment 102 User image NorthMan 2003-01-07 18:38:08 PST
Suddenly works for me on 2003010708 Win32 Millenium.
Comment 103 User image Mike Kaply [:mkaply] 2003-01-08 10:24:02 PST
Nope, noone checked in the OS/2 piece. I'll do it when the tree opens.
Comment 104 User image Grey Hodge (jX) 2003-01-08 14:05:24 PST
Yeah, not believing till I see, this is now ok on Win32. Interesting...
Comment 105 User image Ian Nartowicz 2003-01-18 13:16:37 PST
Current behaviour on win98 latest nightly:

file menus no longer eat clicks
right-click menus no longer eat clicks
URL bar dropdown no longer eats clicks
personal toolbar folders (eg. bookmark menu) still eat clicks
toolbar dropdowns (eg. back/forward history) still eat clicks (see bug 65279)

Comment 106 User image Ian Nartowicz 2003-01-24 06:57:44 PST
Context menus in MailNews still eat clicks.
Comment 107 User image R.K.Aa. 2003-02-03 13:10:19 PST
Mentioned in several of the duplicates: You still have to click the "Go" button
twice after writing an URL.
Comment 108 User image Samir Gehani 2003-02-17 10:12:25 PST
-> Jag
Comment 109 User image jag (Peter Annema) 2003-03-21 04:08:04 PST
R.K.Aa: on what platform are you seeing this? I'm guessing Mac or Linux.
Comment 110 User image Grey Hodge (jX) 2003-03-21 14:14:03 PST
Rkaa is a Linux user.
Comment 111 User image Jesse Ruderman 2004-01-09 23:21:32 PST
Now fixed for OS/2 (mkaply's checkin earlier today).
Comment 112 User image R.K.Aa. 2004-03-21 07:50:53 PST
*** Bug 227233 has been marked as a duplicate of this bug. ***
Comment 113 User image Wayne Mery (:wsmwk, NI for questions) 2005-10-05 05:01:33 PDT
is whiteboard accurate status of the platforms? 
Comment 114 User image Mats Palmgren (:mats) 2006-06-24 19:38:40 PDT
*** Bug 342628 has been marked as a duplicate of this bug. ***
Comment 115 User image James B. Higgs 2006-06-25 17:06:14 PDT
Here's another example, originally filed as Bug #342628:

Consider the following situation:

My Personal Toolbar is a collection of Folders, not individual Links. So, when
I click on one, I get a drop-down menu. At that point, if I click on *any*
other control (even the "X" control in the upper right corner that should close
the window, or another Personal Toolbar Folder) it simply negates the drop-down
list instead of acting on the other control.

Jim H. (aka CuriousJ)
Comment 116 User image James B. Higgs 2006-06-25 17:14:52 PDT
(In reply to comment #57)
> (From update of attachment 105063 [details] [diff] [review] [edit])
> this will break menus. you do not want the click processed when you click
> outside a menu.
> 

Why not? Dammit, when I click *anywhere* whether it's on a control or not, I
want that click to *do* *what* *I* *intended* *it* *to* *do*! Either I clicked
on a control, which means I wanted to activate that control, or I just clicked
at a random spot on the screen - which, if I were in a menu, means I wanted
*out* of that menu.

Jim H. (aka CuriousJ)
Comment 117 User image Matthew Paul Thomas 2006-06-30 23:41:03 PDT
"But when we looked at people actually trying to use the product, they didn't 'aim' their 'dismiss the menu' click at all.  They weren't actually trying to both make the gallery go away and also perform some action with a single click.  Clicking away from the gallery was just an efficient and discoverable way of making it disappear..." -- A Microsoft Office PM on how they went to great lengths to make clicking outside a menu do nothing except close the menu. http://blogs.msdn.com/jensenh/archive/2006/01/26/517851.aspx
Comment 118 User image Ben Ruppel 2006-07-01 14:32:30 PDT
I don't think this is a straightforward issue by any means.  I would like to point out that web pages, for the most part, have tons of blank space (that is, space where clicking doesn't do anything).  Compare this to office, where clicking most anywhere on the document would change your caret position or selected cell if the click were not consumed in dismissing the menu.  

I believe that if this bug were "fixed" clicking on blank space would still be a mostly viable means of dismissing the menu.  Furthermore, the user can be sure that their click will be in "dead space" via the feedback mechanism of the mouse cursor appearance.  Whether this is good enough, I can't say.

Note You need to log in before you can comment on or make changes to this bug.