72488 - [beos] Closing Window with open menu crashes Mozilla [@nsMenuPopupFrame::GetWidget]

Status: RESOLVED DUPLICATE of bug 175285

(Core :: XUL, defect)

Description

[Gregor Rosenauer]

On BeOS, build 2001021912, open a(nother) navigator-window. Open any menu, then
close the window (by clicking on the close-button or via shortcut, not via
menu,-). Mozilla crashes (everytime):

segment violation occurred
4081e028 read_fault
mozilla-bin:sc
   frame         retaddr
fd001738   ed102066  nsMenuPopupFrame::GetWidget(nsIWidget **) + 0000002e
fd001754   ed10affc 
nsMenuDismissalListener::GetSubmenuWidgetChain(nsISupportsArray **) + 0000008c
fd0017c8   eca2ad66  nsWindow::DealWithPopups(unsigned long, nsPoint) + 0000011e
fd00182c   eca2c31c  nsWindow::CallMethod(MethodInfo *) + 00000234
fd001868   eca1e766  nsAppShell::Run(void) + 000000b2
fd001898   ec9838a8  nsAppShellService::Run(void) + 00000024
fd0018a8   8000968b  main1(int, char **, nsISupports *) + 00000943
fd0019f8   80009c9b  main + 0000011b
fd001a24   80006a05  _start + 00000061

mozilla-bin:regs
 eax 4081e028   ebp fd001738   cs 001b
 edx 82afc4cf   esi 82af9874   ss 0023
 ecx 00000000   edi fd001750   ds 0023
 ebx ed330338   esp fd001718   es 0023
                               fs 1723
 eflags 00010286  eip 4081e028
 trap_no 0000000e  error_code 00000004

mozilla-bin:ps
 PID  DEBUG NAME                              STATUS
 2d5  curr  mozilla-bin                       semaphore
 2d8        BApplication                      semaphore
 2dd        moz-thread                        semaphore
 2e1        timer roster                      semaphore
 301        w>Prompt                          semaphore
 30c        w>Alert                           semaphore
 3cf        w>Compose: Get The Bunny          semaphore
 3f4        w>Downloading                     semaphore
 403        w>Saving File                     semaphore
 46a        w>Secundum Artem - pixel32.box.   semaphore
 47c        w>Alert                           semaphore
 4af        w>Downloading                     semaphore
 4c3        w>Saving File                     semaphore
 4cd        w>                                semaphore
 4cf        w>Add Bookmark                    semaphore
 4d1        w>                                semaphore
 4d3        w>                                semaphore
 4d6        w>                                semaphore
 4ee        w>Alert                           semaphore
 4f1        w>Alert                           semaphore
 548        w>::: V3X - 3D ENGINE - Realtec   semaphore
 55f        w>BeNews - The place with more    semaphore
 582        w>                                semaphore
 588        w>                                semaphore
 589        w>                                semaphore
 58b        w>                                semaphore
 58d        w>                                semaphore
 5b7        w>Downloading                     semaphore
 5b8        moz-thread                        semaphore
 5c8        w>Saving File                     semaphore
 5d1        team 132 debugtask                semaphore
mozilla-bin:

Comment 1

[Mike Pinkerton (not reading bugmail)]

is this beos only? i'm tempted to say so since this works on win32.

Comment 2

[:deanis74]

I would think so, and probably somewhere within the nsWindow functions that are 
getting called.

Comment 3

[Oliver Klee]

Adding crash keyword.

Comment 4

[Marko Macek]

linux had a similiar bug when you had a context menu open. I am not sure
if it was fixed... searching...

Comment 5

[Jeroen Oortwijn]

Confirmed on BeOS build 2001021912.
But mozilla doesn't crash immediately when you closed the second window.
You have to click in the first window after closing the second and then mozilla
crashes.
When you have only 1 mozillawindow open and you close that window (when it has
an menu open) mozilla quits nicely.

Comment 6

[John Morrison]

Although you can get this crash if you use the steps on bug 64022 _and_
you set '-moz-user-focus: ignore' for the element menulist.

Comment 7

[Michal 'hramrach' Suchanek]

The Linux one is 86750

Comment 8

[Michal 'hramrach' Suchanek]

Sorry, bug 86750

Comment 9

[Yannick Koehler]

No more working on Bezilla

Comment 10

[Kenneth Herron]

Attachment: window.close() on a five-second delay

Comment 11

[Kenneth Herron]

Oops, that last attachment was intended for bug 86750. It's a valid testcase for
this bug report, FWIW.

Comment 12

[Dennis Jakobsen]

NOT an issue any more..  tested on 0.9.8 and 0.9.8+ built this morning. Marking FIXED.

Comment 13

[Greg]

This bug is still occurring in RC1 build number 2002042715 for Beos.

Comment 14

[Greg]

I should have said in my previous comment that the steps neccessary to produce
this bug are the same as the comment made by Jeroen Oortwijn ie; "But mozilla
doesn't crash immediately when you closed the second window.
You have to click in the first window after closing the second and then mozilla
crashes.
When you have only 1 mozillawindow open and you close that window (when it has
an menu open) mozilla quits nicely." 
This is occurring in RC1 for Beos, build number: 2002042715.
I am using Beos 5.03 personal edition on its own partition and a PC platform.  

Comment 15

[timeless]

i hit this today with a nightly build from this week.
[after getting libnet.so from someone]

Comment 16

[Sergei Dolgov]

Attachment: calls DealWithPopups in Destroy()

closes popups on window destroy

Comment 17

[Sergei Dolgov]

previous isn't universal approach.
Problem is that mouse event scope for PopUp/Menu is too restricted now.
SetEventMask() for mView in eWindowType_popup must be applied.
Though. additional rework of ONMOUSE: event processing in nsWindow.cpp is needed.
This scope enlargement should fix also other issues with PopUp-s 

Comment 18

[Sergei Dolgov]

have solution, but it partially depends on bug 126843. So waitin' until 126843
check-in.

Comment 19

[Sergei Dolgov]

know how

Comment 20

[Paul]

Sergei, what is the status of this?  The patch you created seems to work, but
you mentioned there may be other changes required.  Do you still think this way?

Comment 21

[Sergei Dolgov]

Yeah. I'm waiting checkins for bugs 71343 and 66809. Maybe some other, don't
recall. Idea is simple - i set/unset in nsWindow:Show() for popups mouse event
mask: B_POINTER_EVENTS. It automatically brings proper behaviour for all cases
related to popups - like in BeOS BMenu class - but needs additional filtering in
some places. Though, for safety i still call DealWithPopups in Destroy() and
CallMethod() ONACTIVATE:. Again, Win32 and MacOS code IIRC deals directly with
rollup listeners in such cases (Activation and destroy) - maybe you will look
there if it is better than calling DealWith ?

Comment 22

[Sergei Dolgov]

i think it is worth r= and checkin, because it will stay in further code. And
now it adds stability

Comment 23

[Sergei Dolgov]

Attachment: Patch. More care about PopUps

Now also closes popups on window deactivation, move, resize, workspace change.

Comment 24

[Sergei Dolgov]

Attachment: Style patch

Now it follows overall file style - search it for "if(w && (t =
w->GetToolkit()) != 0)"

Comment 25

[timeless]

Comment on attachment 95870 [details] [diff] [review]
Style patch

r=timeless
sr=blizzard (ports)

Comment 26

[Sergei Dolgov]

Comment on attachment 95870 [details] [diff] [review]
Style patch

Noticed little issue.
Not so serious, but patch needs update.
Namelly - in chats.
If someone is slow-hand person and opens some menu for a while, when being in
chat, auto-refresh of chat window closes menu.
So patch needs adding mWindowType != eWindowType_child condition.

Comment 27

[Sergei Dolgov]

Attachment: patch

Same as previous, but triggers DealWithPopups() only for top-windows

Comment 28

[timeless]

Comment on attachment 96250 [details] [diff] [review]
patch

+			if(eWindowType_popup != mWindowType  &&
eWindowType_child != mWindowType)

"  &&" => " &&",
r=timeless
sr=blizzard (ports)

Comment 29

[Sergei Dolgov]

it ssems that better place for DeakWithPopups call is not Destroy() Method but
case ONCLOSE: in CallMethod. Though, further testing is planned

Comment 30

[Sergei Dolgov]

changing severity.
Needs polishing, but no such crashes more.

Comment 31

[Olivier Cahagne]

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

Comment 32

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 33

[Sergei Dolgov]

*** This bug has been marked as a duplicate of 175285 ***