319881 - [BeOS] Implementing floating and modal windows

Status: RESOLVED FIXED

(Core Graveyard :: Widget: BeOS, defect)

Description

[Sergei Dolgov]

Due some troubles
https://bugzilla.mozilla.org/show_bug.cgi?id=66809
all native windows in BeZilla have B_NORMAL_WINDOW_FEEL at the moment.

It brings to some very irritating issues, like "non-working" pages, in case when modal dialog/popup widget was created and occasionally main window was brought to front.
Like those windows to fill password and other data at pages.

Also, having floating behaviour for dialogs with parent (like "Find") adds a lot of usability.

Comment 1

[Sergei Dolgov]

Attachment: patch

implements Floating and Modal window support

Comment 2

[Sergei Dolgov]

Attachment: patch

review request

Comment 3

[tqh]

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

r=[e-mail]

Comment 4

[Sergei Dolgov]

landed in trunk
Checking in mozilla/widget/src/beos/nsWindow.cpp;
/cvsroot/mozilla/widget/src/beos/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.115; previous revision: 1.114
done
Checking in mozilla/widget/src/beos/nsWindow.h;
/cvsroot/mozilla/widget/src/beos/nsWindow.h,v  <--  nsWindow.h
new revision: 1.49; previous revision: 1.48
done 

closing bug

Comment 5

[Sergei Dolgov]

Patch is unsufficient due to flacky BeOS abilities to handle windows Z-order and hierarchy. Good indication of that is buggy Customize window in Firefox.
With current patch it floats over main window, as expected, but:
1)You cannot open drop-down window to switch between "icons with text", "icons without text" etc
2)When Customize window is closed, main windows is "blocked" - as it did't get proper sequence of deactivate/activate messages.

So new patch will follow to work those issues around.

Comment 6

[Sergei Dolgov]

Attachment: patch

Sets Customize dialog to work as expected.
1)Adds B_FLOATING_ALL_WINDOW_FEEL for popups when parent is FLOATING_SUBSET (and only then).
2)Manually sends activate/deactivate messages for parents of floating windows.

I know that tqh will dislike code in StandardWindowCreate due nested ifs, but i couldn't get fully reliable code when placing all things into single long if's statements. Order dependency in logical expressions is suspicious for me, especially if it includes risk to access some methods via null-pointers.
I think that nicer code may be achieved if part of it will be moved above, before we create nsWindowBeOS, but at least it works for me.

Comment 7

[tqh]

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

r=[e-mail]

Seems ok to me.

Comment 8

[Sergei Dolgov]

landed in trunk.
Checking in mozilla/widget/src/beos/nsWindow.cpp;
/cvsroot/mozilla/widget/src/beos/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.116; previous revision: 1.115
done
Checking in mozilla/widget/src/beos/nsWindow.h;
/cvsroot/mozilla/widget/src/beos/nsWindow.h,v  <--  nsWindow.h
new revision: 1.50; previous revision: 1.49
done 

Comment 9

[Doug Shelton]

sergei, do we need to land this in the branch also?  it appears to have been created shortly after the branch occurred.

Comment 10

[Sergei Dolgov]

(In reply to comment #9)
> sergei, do we need to land this in the branch also?  it appears to have been
> created shortly after the branch occurred.
> 
It needs some investigation. I have feeling that modal and floating windows are OK in branch. So will look at that this weekend