Window coordinates are changed at the end of page load

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
XUL
VERIFIED FIXED
17 years ago
7 years ago

People

(Reporter: Andrew Simmonds, Assigned: Dan M)

Tracking

({regression, smoketest})

Trunk
mozilla0.9.1
regression, smoketest
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: 0.9.1)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
Confirming on win98 2001051822
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Updated

17 years ago
Target Milestone: --- → mozilla0.9.1
keyword magic ...
Keywords: mozilla0.9.1, nsbeta1, nsCatFood, regression

Comment 3

17 years ago
Same bug as 81791 ?

Adding to CC

Comment 4

17 years ago
*** Bug 81791 has been marked as a duplicate of this bug. ***

Comment 5

17 years ago
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? :-)

Comment 6

17 years ago
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. ***

Comment 8

17 years ago
*** Bug 81831 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 9

17 years ago
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.

Updated

17 years ago
Whiteboard: 0.9.1
*** Bug 81856 has been marked as a duplicate of this bug. ***
Blocks: 81856

Updated

17 years ago
OS: Windows 2000 → All

Comment 11

17 years ago
*** 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

Comment 14

17 years ago
*** Bug 81897 has been marked as a duplicate of this bug. ***

Comment 15

17 years ago
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.
(Reporter)

Comment 16

17 years ago
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

Comment 17

17 years ago
*** Bug 81922 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
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...

Comment 19

17 years ago
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...

Comment 20

17 years ago
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 → ---

Comment 21

17 years ago
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

Comment 22

17 years ago
ell,
Mozilla is not usable at the moment.

In that case, it is a blocker !!

Comment 23

17 years ago
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

Comment 24

17 years ago
*** Bug 81960 has been marked as a duplicate of this bug. ***

Comment 25

17 years ago
*** Bug 81962 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
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.

Comment 27

17 years ago
Shouldnt this be marked Blocker and or have smoketest keyword?
We have a winner...10 dupes, adding mostfreq keyword
Keywords: mostfreq

Comment 29

17 years ago
*** Bug 81971 has been marked as a duplicate of this bug. ***

Comment 30

17 years ago
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

Comment 31

17 years ago
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 ...

Comment 33

17 years ago
*** Bug 81856 has been marked as a duplicate of this bug. ***

Comment 34

17 years ago
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.

Comment 35

17 years ago
any ideas how long before we have a fix ?

Comment 36

17 years ago
not a tree stopping issue. just size the window large and don't maximize to 
workaround.
Severity: blocker → critical

Comment 37

17 years ago
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

Comment 38

17 years ago
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 ...

Comment 39

17 years ago
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
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1

Comment 40

17 years ago
Well, that clears it then. I guess IE is going to win...

Comment 41

17 years ago
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
(Assignee)

Comment 43

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 44

17 years ago
*** Bug 82066 has been marked as a duplicate of this bug. ***

Comment 45

17 years ago
*** Bug 82080 has been marked as a duplicate of this bug. ***

Comment 46

17 years ago
*** Bug 82086 has been marked as a duplicate of this bug. ***

Comment 47

17 years ago
*** Bug 82085 has been marked as a duplicate of this bug. ***

Comment 48

17 years ago
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. ***

Comment 51

17 years ago
*** Bug 81967 has been marked as a duplicate of this bug. ***

Comment 52

17 years ago
WFM 2001052204 Win98. Nice work.
(Reporter)

Comment 53

17 years ago
verify fixed,
good work
Status: RESOLVED → VERIFIED

Comment 54

17 years ago
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.

Comment 55

17 years ago
The problem I see was filed as a new bug 82368

Comment 56

17 years ago
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.