Closed Bug 81787 Opened 23 years ago Closed 23 years ago

Window coordinates are changed at the end of page load

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: simmo, Assigned: danm.moz)

References

Details

(Keywords: regression, smoketest, Whiteboard: 0.9.1) 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010518
All windows throughout mozilla will not stay maximized.
Windows will always somehow get restored.

Steps to repro:
1. Maximize Mozilla.
2. Click on any link.
3. When page finally finishes loading it will restore itself.

Expected:
- The windows stay maximized or at their previous state.
Confirming on win98 2001051822
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla0.9.1
keyword magic ...
Keywords: mozilla0.9.1, nsbeta1, nsCatFood, regression
Same bug as 81791 ?

Adding to CC
*** Bug 81791 has been marked as a duplicate of this bug. ***
The strange thing is the document title is also gone when this happens. I guess
that would make this a standards compliance issue, as well? :-)
Adding people whose checkins yesterday *might* have caused this. Sorry if you
have nothing to do with it.
*** Bug 81833 has been marked as a duplicate of this bug. ***
*** Bug 81831 has been marked as a duplicate of this bug. ***
After looking a bit more deeply into the bug the actual window maximised 
dimentions say 800x576 are changed down to 650x498 hence the window not being 
resizable after a page load and the restore button still telling the user that 
the window is still maximized.
Whiteboard: 0.9.1
*** Bug 81856 has been marked as a duplicate of this bug. ***
Blocks: 81856
OS: Windows 2000 → All
*** Bug 81887 has been marked as a duplicate of this bug. ***
*** Bug 81898 has been marked as a duplicate of this bug. ***
after conversation with Paul Chen on IRC -=> XP Toolkit/widget
Assignee: pchen → trudelle
Component: XP Apps → XP Toolkit/Widgets
*** Bug 81897 has been marked as a duplicate of this bug. ***
karnaze checked in something at 05/18/2001 19:45 that could affect window resizing:

"bug 64645 - process children of <object> during frame construction and reflow
child if alternate is needed. sr=attinasi, r=peterl"

Adding to CC.
changed summary to reflect what is actually happening
Summary: Mozilla windows will restore at end of page load → Window coordinates are changed at the end of page load
*** Bug 81922 has been marked as a duplicate of this bug. ***
dunno whether this helps any but I noticed that windows on win32 think 
they are in maximized (ie screen spanning ) state, even though they have 
been displaced and show the non-maximized window broder. Them 
being in maximized state is  evdidenced by the configuration of the resize 
buttons on the top left corner as well as the lack of resize handle cursors 
when mousing over the edge. When clicking the middle button it toggles 
them back to regular resizable state. Never seen this before...
dunno whether this helps any but I noticed that windows on win32 think 
they are in maximized (ie screen spanning ) state, even though they have 
been displaced and show the non-maximized window broder. Them 
being in maximized state is  evidenced by the configuration of the resize 
buttons on the top left corner as well as the lack of resize handle cursors 
when mousing over the edge. When clicking the middle button it toggles 
them back to regular resizable state. Never seen this before...
Clearing target for re-triage, and lowering severity since there is no apparent
development work blocked by this (despite bug 81856 being marked a dup/blockee).
 ->danm
Assignee: trudelle → danm
Severity: blocker → normal
Target Milestone: mozilla0.9.1 → ---
You have got to be kidding me.  Having the window bouncing around the screen 
has made Moz virtually unusable.  This should be a blocker.  On my machine it 
not only makes itself a PITA, but screen repaints where it used to be are all 
fouled up.  If it's not technically a blocker, it's at least critical.
Severity: normal → critical
ell,
Mozilla is not usable at the moment.

In that case, it is a blocker !!
I dont see any window jumping on linux. When i reported this bug (marked as dupe
of this one), was because any webpage that did popups, showed up the window and
it "looks" good, but if you move the window around you will see it's a full
sized window instead of a small one
QA Contact: sairuh → jrgm
*** Bug 81960 has been marked as a duplicate of this bug. ***
*** Bug 81962 has been marked as a duplicate of this bug. ***
From what  I can see on win32 it only occurs if the windows get in 
maximized state. I had a previous profile where windows where last 
opened as non-maximized, and there the bug did not occur until the 
window got maximized and a document (sidebar or content area) finished 
loading.
Shouldnt this be marked Blocker and or have smoketest keyword?
We have a winner...10 dupes, adding mostfreq keyword
Keywords: mostfreq
*** Bug 81971 has been marked as a duplicate of this bug. ***
I can reproduce this consistently with build 2001052104 on Win2k (SP2) with the 
following URL:  http://www.islandnet.com/~luree/contest.html

Wait about 5 - 10 seconds and a new smaller window will be popped up...once it 
gets done loading, it resizes itself to the size of the window that opened it 
up.  Many times, the window minimize, maximize, and close widgets that are 
supposed to be at the far right of the window end up being in the place they 
would be had the window stayed the size it was meant to.  However, they are non-
functional.  The rest of the top part of the window to the right is a bit 
messed up and you have to sort of guess at where the window close widget is.  
Those widgets do exist and if you guess the right spot, you are able to 
activate any of those widgets.

Hope that helps

jake


Not holding the tree for this is just silly.  The fact we use workarounds and
technicalities to get around fixing bugs is why the product is in the state it's
in today.  This needs to be fixed before people start piling on other
regressions on top of it.  Remarking blocker and adding smoketest keyword.
Severity: critical → blocker
Keywords: nsdogfood, smoketest
May I ask a really dumb question ?

Why do we have code in mozilla that changes size or z-order of windows ?

I have seen some related bugs ( bug 72651, bug 47988, bug 28467, bug 33117, bug 
30400, bug 47032, and many more ), but I still don't realize why we need to 
have code in mozilla that modify window placement.

Sorry for the spam ...
*** Bug 81856 has been marked as a duplicate of this bug. ***
you just asked. and no this isn't the right bug, but i can't think of a better 
bug and it's probably worth answering.
(a) alert dialogs need to be able to come to the front
(b) we need to be able to place said dialogs
(c) someone years ago decided it would be neat for javascript in web pages to 
be able to create windows at arbitrary coordinates
there are probably a bunch of other reasons.

however, none of them justify the behavior experienced here.
any ideas how long before we have a fix ?
not a tree stopping issue. just size the window large and don't maximize to 
workaround.
Severity: blocker → critical
Daniel, take a look at the behavior I described.  It does not involve 
maximizing a window.  It simply involved a popup window that is set to open at 
some specified size (in this case smaller than your average window) which, upon 
load, re-sized itself to the size of the window that opened it.

You can't avoid the bug on the page that I referenced.

And when that window resizes itself, the painting of the top window bar is all 
messed up so that it is difficult to see where to close the window.

Again, there is no workaround for the case that I mentioned above.  As such, 
this should be a "tree stopping issue" based on the conditions you implied.

jake
Mozilla creates popup windows with full screen size, and only shows the correct
size of them unless you move them. There is NO workaround for this, and this
should be fixed.

Top bugs to check for 0.9.1:
-This one
-Mail downloading issue and hangs
-Talkback not working in linux

IMHO ...
Please stop fiddling with this bug, it is only making extra spam, and the 
assignee does not like spam.  There is no crash, data loss, severe leak or major 
loss of function, so this is normal severity, and no number of keywords is going 
to get it fixed any faster.  Also, please take off-topic conversations to the 
appropriate newsgroup, and flames >>dev/null
Severity: critical → normal
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Well, that clears it then. I guess IE is going to win...
I have suggested that bug 20847 be reopened until this is fixed. In a sense, we 
have returned to the state where Mozilla cannot be maximized - only now it's 
ten times more painful. What astonishes me is that not even the Netscape techs 
can agree on a solution for this. I cannot stress enough that this take 
priority over other bugfixes before this problem gets harder to fix. Maybe my 
IE remark was a little too vague, but this isn't: Problems like this really 
need to be fixed before little rendering bugs. I personally can't and won't 
test any daily build containing this bug, not because it is physically 
impossible, but because the builds are awkward and uncomfortable to use. I'm 
sure there are other testers who feel the same way. Also, as Kersey said, 
letting this bug remain in the code will make removing it later on that much 
more difficult. Don't underestimate the importance of fixing this bug.
this happens for me, on mac, with every single page i load and every window i 
open (2 or 3 times when you launch mail). no popups necessary. every webpage does 
it.
Hardware: PC → All
Thanks, Skewer! Your continued pleas, though they do take up a lot of space, were 
worth it because they really galvanized me to get up and fix this bug. But you're 
right; it would be most helpful if we increased the problem's visibility by 
opening up a few other old related bugs as well.

Sigh. Smiley? Maybe. Perhaps it's not obvious. Perhaps I should point out that 
comment repetition in bug reports is one of the reasons most of us regularly lose 
control of our bugzilla mail folders; a problem often fixed with select all / 
delete. There now. Look what you made me do to this otherwise perfectly good bug 
report.

And Thanks, MIKE! You too, damnit. Gor. Here comes my third attempt to commit the 
comment saying that I fixed this bug. (*#(*&#$&#*. I wonder if I'll collide with 
someone saying they've noticed it's been fixed, now?
---
Where was I? Apparently someone has introduced a new onload event from some DOM 
Window that must not have been firing them last week. This new one got past a 
faulty check which was intended to abort handling of the onload event for frames, 
but didn't take sandboxing into account. Or something like that. Anyway, an 
unexpected onload was causing the window's size and position to be refetched from 
persistent storage, and fixing the check makes the problem go away.

Index: nsWebShellWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,v
retrieving revision 1.342
diff -u -r1.342 nsWebShellWindow.cpp
--- nsWebShellWindow.cpp	2001/05/10 23:13:27	1.342
+++ nsWebShellWindow.cpp	2001/05/22 02:02:08	1.343
@@ -1224,18 +1224,16 @@
   if (mChromeLoaded)
     return NS_OK;
 
-  //
   // If this document notification is for a frame then ignore it...
-  //
-  nsCOMPtr<nsIDOMWindow> domWindow, topDOMWindow;
-
-  (void) aProgress->GetDOMWindow(getter_AddRefs(domWindow));
-  if (domWindow) {
-    domWindow->GetTop(getter_AddRefs(topDOMWindow));
-
-    if (domWindow != topDOMWindow) {
+  nsCOMPtr<nsIDOMWindow> eventWin;
+  aProgress->GetDOMWindow(getter_AddRefs(eventWin));
+  nsCOMPtr<nsPIDOMWindow> eventPWin(do_QueryInterface(eventWin));
+  if (eventPWin) {
+    nsCOMPtr<nsIDOMWindowInternal> rootiwin;
+    eventPWin->GetPrivateRoot(getter_AddRefs(rootiwin));
+    nsCOMPtr<nsPIDOMWindow> rootPWin(do_QueryInterface(rootiwin));
+    if (eventPWin != rootPWin)
       return NS_OK;
-    }
   }
 
   mChromeLoaded = PR_TRUE;
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 82066 has been marked as a duplicate of this bug. ***
*** Bug 82080 has been marked as a duplicate of this bug. ***
*** Bug 82086 has been marked as a duplicate of this bug. ***
*** Bug 82085 has been marked as a duplicate of this bug. ***
no longer seeing this problem on Win32 2001052204
*** Bug 82140 has been marked as a duplicate of this bug. ***
*** Bug 82053 has been marked as a duplicate of this bug. ***
*** Bug 81967 has been marked as a duplicate of this bug. ***
WFM 2001052204 Win98. Nice work.
verify fixed,
good work
Status: RESOLVED → VERIFIED
I've just seen it again on 2001052204. Not as general as before but still
possible to reproduce. I hit it when I change newsgroups (meaning klick on
another newsgroup name on the left pane) in the full screen, alternative 3-pane
Mail window. The behavior is as described before: false widgets visible off the
window, real one invisible, the window not full screen but it does not know it... 

One more common trait (not reported before): on a two graphic cards, two
monitors system if you try pull the corrupted window to the other monitor, it is
invisible. All other windows (except the full screen ones) can be moved between
the screens.

If it happens again with the morning build (20010523), I'll reopen the bug or
open a new one (to let it slip the mozilla0.9.1 target). Help with deciding
which would be better is welcome - preferably by e-mail to avoid spamming.
The problem I see was filed as a new bug 82368
I don't know if this will help with this problem but it seems to have worked
it's way back into my older build that I'm still using 2001032319.
I suspect that this problem may have something to do with the chrome being
loaded from later builds of Mozilla.  I'm no 100% on this but otherwise I can't
think of any other way my older build might have inherited this bug.
You need to log in before you can comment on or make changes to this bug.