Linux test shell: get rid of popups when they "lose focus".

Linux test shell: get rid of popups when they "lose focus".


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=7483

[Evan Stade, 2008-12-20 00:00:30]

I put "lose focus" in quotations because the popup window, annoyingly, never
actually gets gtk focus (at least it never gets any such event). The popup and
its drawing area get no notification when the user clicks away from the popup or
away from the program, which is why we need to use this multi-pronged approach
to closing the popup. This relies on the fact that PopupMenuChromium.cpp checks
whether clicks are within the popup's bounds, which, prior to this date, had
questionable utility, since the popup menu wouldn't get a mouse click event that
wasn't already inside its bounds.

Another question arises: what do want to do with clicks that are outside the
bounds of the popup, while the popup is open? (i.e. do we pass them through or
not, like if you you click on a button while the popup is open, does the button
get pressed as well as closing the popup)

a little data I've collected on clicks outside the popup window:

browser | OS   | click within browser window | click outside browser window
firefox3| linux| don't pass through          | don't pass through
firefox3| win  | don't pass through          | pass through
chrome  | win  | pass through                | pass through

on windows, passing through seems to be the behavior for most programs (browsers
and non), whereas on linux (GDE), default behavior seems to be to not pass
through. Which is good, because that's what this patch does.

http://codereview.chromium.org/14912/diff/1/2
File webkit/tools/test_shell/test_shell_gtk.cc (right):

http://codereview.chromium.org/14912/diff/1/2#newcode340
Line 340: if (!m_popupHost)
note that this check is not a hack to avoid the below-mentioned recursion, there
are legitimate cases where you would call ClosePopup when no popup exists
(mainly when the main window loses focus without a popup)

[Evan Stade, 2008-12-20 00:14:13]

let me amend my last statement: this patch matches the firefox3 on windows
behavior from the table.

The reason that the GDE default is never passing through clicks is because thats
what gtkmenu.c does. It accomplishes this by capturing all clicks that X passes
to GTK, a behavior which I was able to copy but I don't think is very safe. If
you crash while you are capturing all X mouseclick events (not just those clicks
that land on your browser window), and your program freezes, then you lose all
mouse input (this happened to me during testing). Gtk probably works around this
somehow but I've no guess as to how.

My personal opinion is that firefox3 on windows has the best behavior.

[Evan Stade, 2008-12-29 18:19:55]

ping

[agl, 2008-12-29 18:48:28]

LGTM