Closed Bug 335608 Opened 19 years ago Closed 1 year ago

Window moves back to original location when moved

Categories

(Core Graveyard :: Widget: Mac, defect)

Product:
Core Graveyard
Component:
Widget: Mac
Version:
1.8 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: k.o_rohrer, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20060425 SeaMonkey/1.1a Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20060425 SeaMonkey/1.1a When I grab a window by the top and move it aside, it moves back to its original location. The faster the window is moved, the more likely the bug is to occur. Once the bug occurs, it is impossible to move the window at any speed. Reproducible: Always Steps to Reproduce: 1. Move a window quickly aside while clicking and holding the window at the top. 2. The window moves back to its original location. 3. Expected Results: Window should move and stay in its location
Version: unspecified → 1.8 Branch
Ken, how often can you reproduce this? Is there any chance to get a more detailed description on how to reproduce this? Does it happen with *all* windows that you move (browser window, MailNews, Help window, password manager window etc etc)?
I am able to reproduce the bug only in the browser and Composer windows. I am unable to test the Mail window because of a separate bug I've filed. To reproduce, create 2-3 new windows (I used Cmd-N). Move the last window quickly back and forth a few times and it will pop back to it's original location. Once it pops back, sometimes it is impossible for the window to move from its location. It took me a few tries of moving the window quickly to reproduce every time. Sometimes this occurs with only one new window, but doing the above should reproduce every time. By the way, I have OS version 10.4.6
Do you see this in Firefox as well (branch build from around same date)? The reason I ask is that it feels more like a core problem. The next thing is to find out when this started to occur - have you seen this for a long time? That said, I can't reproduce the problem with a branch build from 20060427 (Mac OS 10.3.9).
I just tried Firefox (Minefield 3.a1) build 20060429 and was unable to duplicate the problem. I tried the latest build for Seamonkey (#2006042817) and the problem still remains.
I forgot to answer your second question. I began seeing this with builds in late January.
I am still seeing this with the latest build. It is very frustrating. It may be unique to the Powerbooks. No other application has the windows move to different locations when you release your mouse button. Please fix this- I first filed this in April.
OS: Mac OS X 10.2 → Mac OS X 10.4
Hmm, the bad thing is that you seem to be the only one who sees this :-/ Karsten, can you reproduce this?
> Karsten, can you reproduce this? Unfortunately, yes: SM 1.1b nightly of 2006090720, on PowerBook G4/OSX 10.4.7. The steps given in comment #2 do reproduce here. :( I opened SM, opened three browser windows (which got displayed cascaded). When I move the last window very fast (via PowerBook touchpad button and touchpad) and release it, it (sometimes, not always) snaps back and takes the exact same position as the second window. I get no errors in the Error Console. I get no errors in Console.app (but it's a nightly, not a debug build). I failed *completely* to reproduce it with my current trunk debug build, though, and several trunk nightlies - the red dino must be really sick by now... ;-) Maybe one of the Mac wizards knows what's going on here... (Especially since it seems to be fixed on trunk?!)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks for mentioning that Karsten. I should have mentioned I am using the track pad. It wouldn't bother me so much but once it moves back, it's almost impossible to move it anywhere else. At first I thought I had a faulty track pad, but then I noticed that no other applications are affected by it. I'm glad I'm not alone with the bug...
This bug is still present in the 9/26/06 trunk. It seems to be worse with this one because it is doing almost every time I have two windows open at once. Once it begins snapping back to location, the only way I can move it is to put it near the bottom of my screen. If I toggle between both windows and move them in increments to the other side of the screen I can get them to move. Otherwise it appears that it bounces back to the location of the previous window. I assume this is only present in the Powerbooks. I have OS X.4.7. This bug is preventing me from using it for my online grading, so I am moving this bug up in severity as a major bug.
Severity: normal → major
It has been since April when this bug was filed. Will it ever be addressed?
Why hasn't this bug been fixed? It has been since April of 2006 when this bug was first reported. Anyone with an Apple laptop has difficulty with the windows. The only reason I still use it is because of the integration of mail, composer, and browser. I am quickly getting discouraged with Seamonkey and may have to abandon the program. Have you given up on it and are only working on Firefox now?
Can we reassign this to get resolution?
Sending this to Widget: Mac (not an app-specific issue).
Assignee: general → joshmoz
Component: General → Widget: Mac
Product: Mozilla Application Suite → Core
QA Contact: general → mac
I think I've isolated this bug as happening only when one of the browser windows has an embedded video object in it. You also perhaps need to be running flip4mac among several other factors. The speed at which you drag the windows, the length of time that Mozilla has been running, etc seem irrelevant, I think. See... https://bugzilla.mozilla.org/show_bug.cgi?id=393333#c1
(In reply to comment #16) > I think I've isolated this bug as happening only when one of the browser > windows has an embedded video object in it. You also perhaps need to be > running flip4mac among several other factors. The speed at which you drag the > windows, the length of time that Mozilla has been running, etc seem irrelevant, > I think. See... > > https://bugzilla.mozilla.org/show_bug.cgi?id=393333#c1 > Yeah, but comment #2 and comment #8 doesn't mention this.
It doesn't matter if there is an embedded video object on a page. The speed also is inconsequential. Once it decides to move back, it will do so whether you drag it in a minute or a second. However, I will say that the latest build seems to have improved upon it somewhat. There are fewer occurances of this happening now in the course of my work. ---------------------------------------------------------- (In reply to comment #17) > (In reply to comment #16) > > I think I've isolated this bug as happening only when one of the browser > > windows has an embedded video object in it. You also perhaps need to be > > running flip4mac among several other factors. The speed at which you drag the > > windows, the length of time that Mozilla has been running, etc seem irrelevant, > > I think. See... > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=393333#c1 > > > Yeah, but comment #2 and comment #8 doesn't mention this. >
I am seeing this too. I have a MacBook and I only notice this happening after I connect my MacBook up to my cinema display. So I suspect it has something to do with the screen being resized, or the monitor being dynamically added. Ken, I notice you are using a trackpad. Do you connect up to external monitors too?
I have had this issue for a long time and have encountered it on a G5 tower, an iMac, and a MacBook. So unfortunately it's not related to the additional/external monitor. Sure wish you were right though as this is so annoying to deal with. These days if I know I'm just browsing vs doing webdev work I turn to Safari. The Safari 3 beta in particular seems a lot faster than Firefox. Now if only Firebug were available to Safari...
No, I don't connect to external monitors. This bug seems to work independently of this. Curious that it hasn't been dealt with after so long.
Flags: blocking1.9?
It's not obvious to me that this happens on trunk (see for example comment #8). Note also that the bug is filed for the 1.8 branch so a blocking-1.9 request isn't correct here. Can anyone confirm that it happens with recent trunk builds? That is, builds downloaded from here: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ (SeaMonkey) http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (Firefox) (and please always mention what build you use when saying "I see this too")
Flags: blocking1.9?
Sorry about that, I'm using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7. I'll get a nightly and see if I can recreate it.
Just to clarify: Firefox 2.0.0.x/SeaMonkey 1.1.x are from the 1.8 branch. Nightly "trunk" builds are made from a snapshot of code under development (the 1.8 branch code doesn't really change that much, dot releases are mainly security fixes). The "trunk" is code that the forthcoming Firefox 3/SeaMonkey 2 releases will be built from.
I've seen this, too, in both Tiger and Leopard, and most recently with 2.0.0.11. I keep Activity Monitor running with the dock icon showing disk activity, and the problem seems much much likely when there is significant disk activity. If I see a disk activity spike after I mouse-down in the title bar, the problem will most likely happen, no matter how long I wait before mouse-up. I figure the spike comes from paging. The problem is also much more likely during a lengthy download of a large file. For me, the window doesn't jump back to it's original position. When I have multiple windows open, it jumps to the same position as another window (same one every time, once the problem starts going). If I have only one open, it jumps to screen top-left.
I'm no expert - just a user but I want to throw my support behind getting this finally addressed. I've been seeing this for a long time as well and sometimes it gets so bad I need to switch to safari. No other apps on my machine seem affected by this. It happens every single time I run firefox for more than a few minutes. If I quit firefox and relaunch, it sometimes goes away for awhile, but always comes back (and not always on the same page, btw). Also, though it doesn't seem to be dependent on embedded video, I have noticed that it's much more prevalent on pages with video or live chat type stuff (flash???). I'm on iMac 24" Core2Duo OSX 10.4.11.
I wonder if this is more prone to happen during complex Javascript or Flash exection execution.
Note: https://bugzilla.mozilla.org/show_bug.cgi?id=399789 appears to be a duplicate of this one. How do we flag it as such? I have this problem often. (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6) Mac OS 10.4.10 The position that the window "snaps-to" is always the origin of another Firefox window, either the download window or the window of an extension. (Today it is sticking to the "Down them all" download accelerator.) If I move this "other" window, the main FF window will snap to the updated location the next time the problem occurs. As I began writing this, the problem was 100% reproducible. (Every time I repositioned the window, it snapped to the other one.) Now I can't make it happen at all. How convenient!
So, have anyone seen this with any of the Firefox 3 beta versions? (see also comment #22)
Blocks: 398539
No longer blocks: 398539
In my experience, when a window jumps to a new location it almost always jumps to a location where 90% of the window is off the monitor. I have noticed that sometimes I can move the window a small amount and if it stays, then I can usually get it to move a longer distance and it will stay. Sometimes I have to move the window back using short moves until I get it back to the place I want it.
My partner has this. Often it moves it to a corner of the screen (80-90% of the time), but it also moves the window off the screen.
I've been using Firefox 3 beta for about 6 weeks now, currently on beta 5. The moving window happened to me a lot with Firefox 2, but has not happened at all -- not once! -- with Firefox 3.
The best description is from bug 3356023 comment 10: > I've found that when one window is loading, moving any other window causes it > to snap to the upper left corner of the loading one. That seems to be the most > reproducible case. When no window is loading, everything works fine. Same > situation for the Download Manager; when it's open and items are downloading, > other non-loading windows snap to it.
After I opened the help window, I dragged the help window to the side so that I could see the browser window and after I dragged the help window, the browser window jumped to the same location as the help window (browser under the help window). I'm not sure if this is part of this bug or this is should be under some other bug. I'm using a Mac OS X 10.4.11 and Firefox is: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
This bug has been totally fixed, as far as I can see, on Firefox 3. I've been using it since it's been released (actually I used the release candidate too), and have not experienced the jumping once under any circumstance.
(In reply to comment #40) It's still happening with SeaMonkey 1.1.9 on my fully upgraded Mac OSX 10.5.3
(In reply to comment #41) > (In reply to comment #40) > It's still happening with SeaMonkey 1.1.9 on my fully upgraded Mac OSX 10.5.3 Yes, the bug is filed against the 1.8 branch and is still open... (see the first part of comment #24).
Assignee: joshmoz → nobody
I have this problem too, with Seamonkey; it doesn't consistently jump to the UPPER left, but consistently to the left. I've had it thru' several Mac machines (iMac, Mac Mini, Laptop) and browser iterations. Currently SeaMonkey 1.1.16 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.21) Gecko/20090402 SeaMonkey/1.1.16 Mac OSX 4.11
This might be fixed in the upcoming seamonkey 2.0 release.
Product: Core → Core Graveyard
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.