140867 - [gtk2] Mail/News window shutdown when click "File" twice.

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Jessie Li]

This is a gtk2 related bug.

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020425
BuildID:    



Reproducible: Always
Steps to Reproduce:
1.Open Mail/News window.
2.Hightlight one message.
3.Click "File" on file menu,then the selected message is opened in a new message
window.
4.Close the message window.
5.Click "File" the second time.

Actual Results:  The Mail/News window disappears suddenly.
If you don't highlight one message at beginning,the mail window shutdown after
you click "File" several times.

Expected Results:  After the "File" menu displays, everything is Ok.

Comment 1

[Boris 'pi' Piwinger]

*** Bug 140868 has been marked as a duplicate of this bug. ***

Comment 2

[John Morrison]

Can we find a different owner for these gtk2 bugs (and perhaps a different QA 
since I don't really have time to do this). And can we label the gtk2 bugs with 
[gtk2].

Comment 3

[Christopher Blizzard (:blizzard)]

->[e-mail]

Comment 4

[Louie Zhao]

When we click the 1-level menu(such as "File", "Edit"...), mozilla focus to the
second 2-level menu(such as "Open Web Location..." in "File") automatically and
execute the command of that menu. 

This can explain why the selected message is opened in a new message window when
click the "File" menu in Mail/News window. This can also generate other bugs.
For example, when click "File", "Open Web Location" display and when click
"Edit", "Redo" is executed if available.

Sometimes, if the sccond 2-level menu is not available, the third 2-level menu
is executed. That's why "If you don't highlight one message at beginning,the
mail window shutdown after you click "File" several times." In my testing, if
you don't move the mouse when clicking 1-level menu, the third 3-level menu
never be executed. So I think it's due to the operation of the user(such as
moving the mouse).

Not all the 1-level menu has the problem, Below is my testing result(menu with
"*" has the problem):
-------------------------------------------------------------------------
version:Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020527
OS:Linux 7.2 + GTK2

Navigator Window
*File *Edit *View *Go Bookmarks Tools *Window Help Debug QA

Mail&Newsgroup Window
*File *Edit *View Message       Tools *Window Help

Manage BookMarks Window
*File *Edit *View               Tools *Window Help
----------------------------------------------------------------------------

Comment 5

[Jeff Qiu]

*** Bug 140903 has been marked as a duplicate of this bug. ***

Comment 6

[Jeff Qiu]

*** Bug 140878 has been marked as a duplicate of this bug. ***

Comment 7

[Robin Lu]

Attachment: patch, not the best

per my investigation, following bug may be caused by the same problem:
140867,140897,140896,140903
The problem seems like we get something wrong when we do gdk_pointer_grab
in CaptureRollupEvents calling GrabPointer. 

I created a patch which grabs a window very similar with the inner_window.
The only difference is that the new grab_window is created without set the
user data to the widget as inner_window.

This patch fixed all the problem described in these four bug reports. But it
brings a new bug. When the menu rolls up, we can not response to any mouse
event out of the browser window. 

Since I have little knowledge about GTK, it may be all that I can do for this
bug. I just use this patch to point out the problem. I hope someone can have a
look at it and provide a better one.

Comment 8

[Jeff Qiu]

*** Bug 140897 has been marked as a duplicate of this bug. ***

Comment 9

[Jeff Qiu]

*** Bug 140896 has been marked as a duplicate of this bug. ***

Comment 10

[Robin Lu]

Attachment: patch, a better one

Actually, the former patch is not very good one. It only force the pointer
grabs to no widget. Now I think I found the root cause after aother week of
study. 

The root cause is that: when gtkmain dispatches the event, it checks the grab
status. If we have a pointer grab and the window of the event is not in the
same group as the grab window, gtk will rewrite the event, modify the
event->window,x and y then dispatch it. In fact, I think gtk does some work
already done by X11 on this situation(a bug of gtk2???). So, the event with
wrong x,y and window is dispatched finally. Unfortunately, nsWindow create
every popup window without adding it to any group, while the other type of
window does add. Then we got all these bugs here.

This patch just adds any popup window to the toplevelParent's group and it
works.

Comment 11

[Robin Lu]

Attachment: patch, a better one

Actually, the former patch is not very good one. It only force the pointer
grabs to no widget. Now I think I found the root cause after aother week of
study. 

The root cause is that: when gtkmain dispatches the event, it checks the grab
status. If we have a pointer grab and the window of the event is not in the
same group as the grab window, gtk will rewrite the event, modify the
event->window,x and y then dispatch it. In fact, I think gtk does some work
already done by X11 on this situation(a bug of gtk2???). So, the event with
wrong x,y and window is dispatched finally. Unfortunately, nsWindow create
every popup window without adding it to any group, while the other type of
window does add. Then we got all these bugs here.

This patch just adds any popup window to the toplevelParent's group and it
works.

Comment 12

[Robin Lu]

sorry, I mistakenly put two patches due to the crash of bugzilla. They are the same.

Comment 13

[Robin Lu]

Ok, Blizzard, you may have your own mind on the group issue. Then this bug turns
out to be a bug of gtk. This is the wrong function at gtkmain.c. You will find
this func gives you a wrong caculation of x and y.
static void
rewrite_events_translate (GdkWindow *old_window,
			  GdkWindow *new_window,
			  gdouble   *x,
			  gdouble   *y)
{
  gint old_origin_x, old_origin_y;
  gint new_origin_x, new_origin_y;

  gdk_window_get_origin	(old_window, &old_origin_x, &old_origin_y);
  gdk_window_get_origin	(new_window, &new_origin_x, &new_origin_y);

-  *x += new_origin_x - old_origin_x;   
-  *y += new_origin_y - old_origin_y;
+  *x -= new_origin_x - old_origin_x;
+  *y -= new_origin_y - old_origin_y;

}
After this translation, widget may consider the pointer is in-widget while
actually it is out-of-widget in some situation.

And, you will also find following lines in function rewrite_event_for_grabs(...)
in gtkmain.c will ignore your event mask and re-dispatch the event while the
event window and grab window are in the same application but not the same
gtk-window-group, because event mask is only used by X11 but not GTK.
  if (grab_widget &&
      gtk_main_get_window_group (grab_widget) != gtk_main_get_window_group
(event_widget))
    return rewrite_event_for_window (event, grab_window);

Comment 14

[Robin Lu]

or more precisely, gtk-window-group grabs event without checking event mask.

Comment 15

[Jay Yan]

add Erwann to the cc list, perhaps Erwann can help on gtk2 issues.

Comment 16

[Jay Yan]

and add a link of gtk2 bug here: http://bugzilla.gnome.org/show_bug.cgi?id=85229

Comment 17

[Jay Yan]

FYI
For comment #13, robin's patch is right, and it has been checked into gtk2.
please see http://bugzilla.gnome.org/show_bug.cgi?id=85229

Comment 18

[Jay Yan]

Robin:
I am trying to add this patch in my workspace and have a try. I found that

+                gtk_window_set_transient_for(GTK_WINDOW(mShell), topLevelParent);

This line is more than 80 column. shoule be splited into 2 lines to make it shorter.

Comment 19

[Robin Lu]

Attachment: patch after Jay's comment

The patch after Jay's comment

Comment 20

[Christopher Blizzard (:blizzard)]

I have filed bug 160621 to remind one of us to use the correct setup for window
modality.

For now, this patch is fine.  Go ahead and check it in.

Comment 21

[Christopher Blizzard (:blizzard)]

Comment on attachment 89017 [details] [diff] [review]
patch after Jay's comment

r=blizzard

Comment 22

[Bolian Yin]

checked in!