Closed Bug 267609 Opened 20 years ago Closed 15 years ago

Maximize window does not work properly when minimized in fullscreen mode.

Categories

(Core Graveyard :: Widget: OS/2, defect)

x86
OS/2
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: abhijeet.bhattacharya, Assigned: dragtext)

Details

(Keywords: fixed1.8)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6) Gecko/20040923
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6) Gecko/20040923

Open any web page press F11 to maximize the window. Now minimize the window it will
display an Icon on desktop. Try to restore it and see the behaviour. It will not
be restored.

Reproducible: Always
Steps to Reproduce:
1.Set Minimize window to desktop in properties option of icon of mozilla on desktop.
2.Open any web page press F11 to maximize the window. Now minimize the window it
will display an Icon on desktop.
3. Try to restore it and see the behaviour. 


Actual Results:  
1.It will not be restored.

Expected Results:  
1. Browser Window should be restored.
Are you still seeing this? I did as you say:
- F11
- Use the minimize icon at the top right
- Mozilla is minimized into "Minimized Windows Viewer"
- Restore it from there or using the Window List
- Window again displays, maximized, and with the same content as before
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a5) Gecko/20041106
I can still see the problem. One correction in recreation-
While restoring use Double click not Window List.
You reported this problem against Mozilla 1.7.

Does it happen with Mozilla 1.7 or Mozilla 1.8?
Its happening in both 1.7 and 1.8 as well as in 1.8a2.
I minimize to the Minimized Window Viewer, rather than the desktop but I was
able to reproduce this once.  I followed the reproduce steps and at first it
fail.  I minimized and restored several times.  Then I saw something a bit odd
(really can't describe it) and then though the icon was there it wasn't.  That
is to say, right click was like rt clicking on the folder beneath it and double
clicking was like double clicking in the folder.  I restored fine with window
list and minimized and same thing.  I restored again, took it out of full
screen, minimized and the icon still didn't work.  I then closed the Minimized
Window Viewer and reopened it and it worked fine and I haven't been able to
reproduce.  I suspect this is some odd OS/2 quirk as opposed to something that
is wrong in Mozilla.
Andy
(In reply to comment #5)
> I suspect this is some odd OS/2 quirk as opposed to something that
> is wrong in Mozilla.

Hmm, then we should compare OS versions. I do not see it (tried the procedure
about 30 times or so) and am using eCS 1.1.
I am using eCS 1.2.  I just reproduced it again.  If I restore it with window
list and then take it out of maximize I can then minimize and restore fine. 
Then when I go to full screen and minimize it won't restore.  I did find that if
I do a select all in the minimized window viewer then hit enter it will restore
it along with everything else (I can also select all then deselect everything else).
The first time I did it I could only reproduce it the first time, I wasn't able
to do it again.  Now closing the minimized window viewer and reopening it isn't
clearing the problem as it did the first time (so now I am not sure if that
means it is more likely or less likely to be OS or Mozilla, as I thought that
the closing the minimized window viewer was fixing it meant there was a chance
it was OS).
Desktop enhancers -- styler2, xwp, wpswizard, lswitcher -- though I would
suspect the reporter did not have these so I doubt that is the issue.
I ended up restoring an older Mozilla after playing with gcc 3.3.5 as it didn't
have the screen repaint issues.  I Mozilla 1.8a5

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a5) Gecko/20041012
Will have to build a newer one and try it.  Also am needing to test a new
profile on something else so will see if there is something there causing it.
New profile did not help.
Product: Browser → Seamonkey
I am using  ACP/2 ver 4.5 and internal revision 14.089.
I tried to reproduce it again, and I could successfully recreate the problem(
Minimizing window viewer to an Icon on desktop then double clicking the Icon is
not restoring the window).But when I tried with window list I could not see the
problem( I could restore the window clicking the on minimized window list) . I
played around and found one peculiar behaviour that if you click once on
desktop before clicking on the minimized window Icon, restoring the main window
is possible everytime.
regards,
Abhijeet
Interesting... I don't minimize to the desktop at all, just to the window viewer.  
So far I have been unable to recreate at all on another stock eCS 1.2 system.  I
tried setting it to minimize to desktop but the icons don't show on the desktop
at all but the "minimized icon window" doesn't exhibit the behavior so far.
Just tested on the original machine and I don't get minimized icons on its
desktop either (tried turning of epager and same thing) must be something
specific that is in eCS 1.2.
The original machine that exhibits the behavior is using the amouse mouse
drivers and the one that doesn't exhibit the issue has the latest drivers from
IBM.  
Unless the OP has deskotp ehancers installed as my machine that exhibits the
behavior (also add dragtext to that list) then I don't think that is the issue
but don't know for sure.  
I am willing to test some things but I only posted here because as I was going
through the bugs I tried it and it did essentially the same.  I'll add myself to
CC in case there is something else to test.
Yeah this bug is ugly and I've known about it for a long time.

Has to do with our internal handling of WM_ACTIVATE.

Basically a minimized window to the desktop is the frame window, so any special
handling in the frame is done on that icon as well.

NEver been a high priority.
This change in nsWindow.cpp is fixing single click bringing up the broswer
problem, Which I have mensioned in Comment#9. 

 return NS_OK;
@@ -2512,6 +2514,8 @@
           break;
 
        case WM_ACTIVATE:
+          if (WinQueryWindowULong(mFrameWnd, QWL_STYLE) & WS_MINIMIZED)
+            break;
 #ifdef DEBUG_FOCUS
           printf("[%x] WM_ACTIVATE (%d)\n", this, mWindowIdentifier);
 #endif
This was confirmed by Andy.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I forgot about this and only discovered today the setting for the system wide
setting to minimize to desktop. Now I can reproduce as well: if I minimize after
F11 the menu of the minimized icon comes up on a single click but the Restore
item does nothing nor does a double click.

But Abhijeet's little patch has no effect on this behaviour with build 1.8a6
2004122713 that I am running currently. I noticed, however, that the minimized
icon does not have a title after using F11 while it does when minimizing without
F11. Perhaps OS/2 does not like those title-less icons?
"This one drives me crazy - single clicking on our minimized window 
displays us." - M. Kaply

Crazy no more: this patch fixes all(?) problems with minimized windows. It also
ensures sysmenus and minimized windows will always have an icon.

The primary problem was that giving a minimized window the focus generated an
NS_ACTIVATE event.  This produced a call to nsWindow::Show() which then restored
the window. The fix is somewhat of a kludge:  the activate event is now deferred
until nsWindow::SetSizeMode() is notified (after the fact) that the window has
been restored.

Minimized fullscreen/kiosk mode windows had additional problems involving their
frame controls which prevented them from being restored by their menu or a
dblclick. This has been fixed; plus, they now display a title.

Finally, every system menu & minimized window is now guaranteed to have an icon.
 If the window doesn't have a special icon, it will get the app's primary icon.
(I was surprised that no one mentioned that some windows, like Extension
Manager, display no icon at all when minimized - not pretty.)
Attached patch minimized window fix for OS/2 (obsolete) — Splinter Review
Very nice.

I just built and it seems to work OK.

I vaguely remember that last time I messed with this code I screwed up Java
focus, but I don't really think that matters anymore :)
My patch may also resolve Bug #280791 "System menu icon missing on OS/2"
Is there a reason you removed all my DEBUG_FOCUS stuff? It was very helpful when
I was trying to get focus working right :)
Attachment #181242 - Attachment is obsolete: true
(In reply to comment #19)
> Is there a reason you removed all my DEBUG_FOCUS stuff?

Aesthetics?  The revised patch restores the debugging stuff I removed but
replaces all of the #ifdef/printf()/#endif's with a macro:

  #ifdef DEBUG_FOCUS
    #define DEBUGFOCUS(what) \
            printf("[%x] "#what" (%d)\n", (int)this, mWindowIdentifier)
  #else
    #define DEBUGFOCUS(what)
  #endif

E.g. DEBUGFOCUS(NS_ACTIVATE);  [or]  DEBUGFOCUS(Create Frame Window);

I also extended your window numbering system to nsFrameWindow because frames
were being assigned large random numbers.

To me, the result is a lot cleaner & easier to read, but if you really want all
those messy #ifdef's back, I'll restore it to the way it was.
Your new way definitely sounds better than mine. I'll take it :)
Comment on attachment 181602 [details] [diff] [review]
min-win fix with focus debugging
[Checkin: Comment 25]

Mike,

You've already sorta-reviewed this - could you formalize it?  It would
certainly be nice to have one of your top 3 bugs fixed in Fx 1.1
Attachment #181602 - Flags: review?(mozilla)
Comment on attachment 181602 [details] [diff] [review]
min-win fix with focus debugging
[Checkin: Comment 25]

r/sr/a=mkaply
Attachment #181602 - Flags: superreview+
Attachment #181602 - Flags: review?(mozilla)
Attachment #181602 - Flags: review+
Attachment #181602 - Flags: approval1.8b3+
Fix checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
I am trying to find out why there is a focus problem (in forms and/or on https
pages) in the SeaMonkey 1.0a release. The only relevant change that I find since
2005-07-01 when the problem was not there was this checkin...

Was it intentional to basically remove the WM_ACTIVATE case from
widget\src\os2\nsFrameWindow.cpp completely? Before it effectively contained
these lines:

         if (SHORT1FROMMP(mp1)) {
            bDone = DispatchFocus(NS_GOTFOCUS, PR_TRUE);
         }
(In reply to comment #26)
> Was it intentional to basically remove the WM_ACTIVATE case from
> widget\src\os2\nsFrameWindow.cpp completely?

Yes, it was intentional, and yes, I've been concerned that these changes may
have caused the current problem which afflicts me every time I try to file a new
bug.

Still, I'm not sure that the removal of this particular code is the cause.  I do
know that its presence was a primary reason that minimized windows would be
restored by a single click.  I'm going to experiment with some alternate code
that might resolve the focus problem without regressing the minimized window issue.

Meanwhile, the workaround for this bug is to minimize then restore the affected
window.
(In reply to comment #26)
>          if (SHORT1FROMMP(mp1)) {
>             bDone = DispatchFocus(NS_GOTFOCUS, PR_TRUE);
>          }

Peter, try the following.  Reproducing the problem is pretty difficult, so I
don't know if I've fixed it or just been "lucky" and not triggered it:

      case WM_ACTIVATE:

        DEBUGFOCUS(frame WM_ACTIVATE);

        if (SHORT1FROMMP(mp1) &&

            !(WinQueryWindowULong(mFrameWnd, QWL_STYLE) & WS_MINIMIZED))

          bDone = DispatchFocus(NS_GOTFOCUS, PR_TRUE);

        break;

I tried that but it didn't help. I think the instances where this happens got a
bit fewer.
I may have made a mistake when I applied the fix from comment 28 two weeks ago.
I just added those lines again, and now it seems to work. To reproduce, I used
SeaMonkey with a fresh profile and started it to point to Web.de Freemail (a
secure page with login form):
   seamonkey.exe https://freemail.web.de
For reproducing the problem it seems to be important to not switch off the
warning dialog for visiting a secure page, the same test does not seem to work
with Firefox, though.

With the standard 1.8 branch code the login form does not get activated and the
cursor does not appear when clicking in the username field on the left. With the
fix from comment 28 the cursor already appears in the username field
automatically, and one can click and type there nicely without destroying the
iconify-to-desktop functionality.

It might be a good idea to try this fix on the trunk before checking into the
1.8 branch, though. In any case, if I don't find other problems myself I will
try to ship the next (SeaMonkey) release with this fix.
Again, for review, as a real patch attachment.
Attachment #200013 - Flags: review?(mozilla)
So this one fix seems to be enough?
Hmm, yesterday I extensively tested it--but only with a fresh profile. Today,
now that I have gone back to my normal working profile, I do see issues,
especially with the forms like
<https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox>. 

Perhaps I should really produce a few different wdgtos2.dll that work with
SeaMonkey 1.0a for wider testing by the people in the newsgroup. Won't happen
today though, I can barely keep my eyes open...
I built the patch into my nightly (even minimizing was not always making drop
downs clickable) and I have so far not had any problems with the url bar not
being able to get focus or problems clicking on the dropdowns.
Comment on attachment 200013 [details] [diff] [review]
focus fix from Rich Walsh
[2 Checkin: Comment 39]

OK, this and the reports in the newsgroup with the 1.8 branch DLL I made seem to indicate that this will indeed fix the problem, I guess this should get into the trunk ASAP and into the branch before Firefox 1.5 rc 1.
Comment on attachment 200013 [details] [diff] [review]
focus fix from Rich Walsh
[2 Checkin: Comment 39]

r=mkaply
Attachment #200013 - Flags: review?(mozilla) → review+
Comment on attachment 200013 [details] [diff] [review]
focus fix from Rich Walsh
[2 Checkin: Comment 39]

OS/2 only fix
Attachment #200013 - Flags: approval1.8rc2?
Comment on attachment 200013 [details] [diff] [review]
focus fix from Rich Walsh
[2 Checkin: Comment 39]

OS/2 Only - approved to land
Attachment #200013 - Flags: approval1.8rc2? → approval1.8rc2+
Last patch on trunk and branch.
Keywords: fixed1.8
There are now several reports which indicate that the patches here neither fixed the original bug that occurred with focus on restore nor have the reports about the focus bug in forms completely died down. They were with both trunk and 1.8(.0) branch.
I didn't have time to verify any of this yet but for now I reopen.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Here using Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20060228 Firefox/1.6a1 with a fresh profile pressing F11 to go to kiosk mode then minimizing the window to the minimized window viewer (just another folder where windows can be minimized to) then double clicking firefox in the minimized window  viewer to bring Firefox back to kiosk mode then pressing F11 leaves firefox in the foreground without focus. Clicking the window does not give Firefox focus. The mouse wheel works (I have it set for the window under the pointer). Selecting from the window list sometimes returns focus.
Usually I use Seamonkey and the sure way to give focus back is to select the current window from the Window menu. (menus still work using mouse even with the lack of focus). Right now can't test with Seamonkey as F11 is not working, possibly from new extensions. Will try a new profile later)
OK, I can reproduce that, sort of, with (OS/2; U; Warp 4.5; en-US; rv:1.8.0.1) Gecko/20060212 SeaMonkey/1.0 Mnenhy/0.7.3.0.

When pressing F11 after the restore it does have keyboard focus, though, just the titlebar isn't painted in foreground colors. I suspect it never gets focus that way after restoring, in fullscreen you just don't see the titlebar to check that. 

Let me see if one of these days I can make sense again of Rich's patch and if I can do something to improve this without making other things worse.
Attachment #200013 - Attachment description: focus fix from Rich Walsh → focus fix from Rich Walsh [2 Checkin: Comment 39]
Attachment #181602 - Attachment description: min-win fix with focus debugging → min-win fix with focus debugging [Checkin: Comment 25]
SeaMonkey v1.0.x is not supported anymore.
Can you reproduce with SeaMonkey v1.1.9 ?

Rich, Peter,
Are you still working on this ?
Hardware: Other → PC
Version: Trunk → SeaMonkey 1.0 Branch
I just tested with Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9pre) Gecko/2008053023 SeaMonkey/2.0a1pre and the behaviour seems close to correct. Problems  saw were,
When in kiosk mode (after pressing F11) and minimizing to desktop the icon appeared on top of other windows. Minimizing from a regular window works as expected, icon is behind everything else.
After playing around minimizing etc I minimized to the minimized window viewer and restored to normal mode and the title bar did not get painted as it does when it has focus. Keyboard etc works so Seamonkey does have focus.
Assignee: general → nobody
All known focus issues were resolved by the reworking of the mozilla focus system in v1.9.2 and by Bug 516274 which fixed OS/2-specific issues.  Problems with fullscreen mode are addressed by Bug 524258 (v1.9.1 & 1.9.2) and by Bug 522896 (v1.9.3).

Since all of the issues mentioned here have been resolved, I'm closing this bug as Resolved/Fixed.
Assignee: nobody → dragtext
Status: REOPENED → RESOLVED
Closed: 19 years ago15 years ago
Component: General → Widget: OS/2
Product: SeaMonkey → Core
QA Contact: general → os2
Resolution: --- → FIXED
Version: SeaMonkey 1.0 Branch → unspecified
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: