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)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: abhijeet.bhattacharya, Assigned: dragtext)
Details
(Keywords: fixed1.8)
Attachments
(2 files, 1 obsolete file)
15.46 KB,
patch
|
mkaply
:
review+
mkaply
:
superreview+
mkaply
:
approval1.8b3+
|
Details | Diff | Splinter Review |
876 bytes,
patch
|
mkaply
:
review+
mtschrep
:
approval1.8rc2+
|
Details | Diff | Splinter Review |
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.
Comment 1•20 years ago
|
||
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
Reporter | ||
Comment 2•20 years ago
|
||
I can still see the problem. One correction in recreation- While restoring use Double click not Window List.
Comment 3•20 years ago
|
||
You reported this problem against Mozilla 1.7. Does it happen with Mozilla 1.7 or Mozilla 1.8?
Reporter | ||
Comment 4•20 years ago
|
||
Its happening in both 1.7 and 1.8 as well as in 1.8a2.
Comment 5•20 years ago
|
||
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
Comment 6•20 years ago
|
||
(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.
Comment 7•20 years ago
|
||
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.
Comment 8•20 years ago
|
||
New profile did not help.
Updated•20 years ago
|
Product: Browser → Seamonkey
Reporter | ||
Comment 9•20 years ago
|
||
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
Comment 10•20 years ago
|
||
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.
Comment 11•20 years ago
|
||
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.
Reporter | ||
Comment 12•20 years ago
|
||
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
Comment 14•20 years ago
|
||
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?
Assignee | ||
Comment 15•19 years ago
|
||
"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.)
Assignee | ||
Comment 16•19 years ago
|
||
Comment 17•19 years ago
|
||
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 :)
Assignee | ||
Comment 18•19 years ago
|
||
My patch may also resolve Bug #280791 "System menu icon missing on OS/2"
Comment 19•19 years ago
|
||
Is there a reason you removed all my DEBUG_FOCUS stuff? It was very helpful when I was trying to get focus working right :)
Assignee | ||
Comment 20•19 years ago
|
||
Attachment #181242 -
Attachment is obsolete: true
Assignee | ||
Comment 21•19 years ago
|
||
(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.
Comment 22•19 years ago
|
||
Your new way definitely sounds better than mine. I'll take it :)
Assignee | ||
Comment 23•19 years ago
|
||
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 24•19 years ago
|
||
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+
Comment 25•19 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 26•19 years ago
|
||
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); }
Assignee | ||
Comment 27•19 years ago
|
||
(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.
Assignee | ||
Comment 28•19 years ago
|
||
(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;
Comment 29•19 years ago
|
||
I tried that but it didn't help. I think the instances where this happens got a bit fewer.
Comment 30•19 years ago
|
||
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.
Comment 31•19 years ago
|
||
Again, for review, as a real patch attachment.
Attachment #200013 -
Flags: review?(mozilla)
Comment 32•19 years ago
|
||
So this one fix seems to be enough?
Comment 33•19 years ago
|
||
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...
Comment 34•19 years ago
|
||
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 35•19 years ago
|
||
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 36•19 years ago
|
||
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 37•19 years ago
|
||
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 38•19 years ago
|
||
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+
Comment 40•18 years ago
|
||
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 → ---
Comment 41•18 years ago
|
||
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)
Comment 42•18 years ago
|
||
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.
Updated•16 years ago
|
Attachment #200013 -
Attachment description: focus fix from Rich Walsh → focus fix from Rich Walsh
[2 Checkin: Comment 39]
Updated•16 years ago
|
Attachment #181602 -
Attachment description: min-win fix with focus debugging → min-win fix with focus debugging
[Checkin: Comment 25]
Comment 43•16 years ago
|
||
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
Comment 44•16 years ago
|
||
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.
Updated•15 years ago
|
Assignee: general → nobody
Assignee | ||
Comment 45•15 years ago
|
||
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 ago → 15 years ago
Component: General → Widget: OS/2
Product: SeaMonkey → Core
QA Contact: general → os2
Resolution: --- → FIXED
Version: SeaMonkey 1.0 Branch → unspecified
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•