Closed Bug 306276 Opened 19 years ago Closed 17 years ago

User control of the window movement is restricted

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: e_mayilme, Unassigned)

References

Details

Attachments

(4 files)

Screen movie of window snapback bug
280.30 KB, video/quicktime
Details
Couple of HTML files that consistently reproduce the bug.
2.47 KB, application/zip
Details
Couple more HTML files that consistently reproduce the bug (this time using http-equiv="refresh")
19.85 KB, application/zip
Details
Section of the screen showing the inaccessible grab bar
48.49 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

When the user wishes to drag a window to a new location on the screen, most of
the time the window immediately returns to its original position.

This bug is very difficult to diagnose. It cannot be reproduced reliably. There
seems to be some automatic detection mechanism that tries to keep people from
"accidentally" moving their windows around.

Some people hate to move any windows, anyway. I move my windows all the time.

When there are two or three windows open on my screen, it is absolutely
essential for my efficient use of the computer that I can move them instantly
anywhere, without an automatic response mechanism that restores them to their
original location.

I tried to find out if this is a feature which exists in the preferences, but I
found nothing mentioned. It may be an anomaly the cause of which does not exist
in the Firefox/Mozilla source code.

But it is very real, and it is happening to me all of the time.

As I write, I tried to reproduce it again by dragging this window itself. The
problem now does not manifest itself in this window only. This is one of the
most infuriating things.

Any user action which the user believes will have occurred may result in the
next moment an action being taken which depends on the result of the previous
action. If the user's software denies the user from obtaining the first result,
the second step may result in the user's click on their Desktop closing and
deleting the text of a one-page email which they just wrote, because the window
really didn't move, and their next click was directly on the close box.

Therefore, any bug is extremely severe which results in throwing away user input.

Comments: This bug is one of the most irritating bugs to someone who is affected
by it. I feel like saying something really horrible.


Reproducible: Sometimes

Steps to Reproduce:
WFM:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050827
Firefox/1.0+

I've never seen this bug, and I doubt if Firefox is controlling the movement of
its windows - I'm pretty sure the OS is responsible for this.

Reporter:
- Are you seeing this problem only with Firefox, or with other apps as well?
- Does this happen with Firefox 1.0.x?
- Does this happen with a recent build (which you can download from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/firefox-1.0+.en-US.mac.dmg
)?

My Firefox-Build: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

My System: Mac OS X 10.4.4, running on Mac Mini 1,25 GHz

Since updating from Firefox 1.5 to 1.5.0.1, I am having almost exactly this Bug as well. 

In addition to the firefox-windows returning to their original position when moved, I am experiencing windows jumping up und left exactly on top of ones created earlier in the window-cascade. Often windows jump around even without moving them, just by clicking onto their top bar.

I too cannot reproduce the effect at will, but I have been running through all the suggested diagnostics (running Firefox without data from earlier versions, in safe-mode, etc.) - without being able to get rid of this annoying bug.
*** Bug 327360 has been marked as a duplicate of this bug. ***
I believe we are talking of the same bug, so I just marked it as a duplicate, but want to further note that the window "jumps" and it may go to any location on the screen even off-screen, though it does tend to revert to back to its original location.

Since this bug affects multiple Macs running different versions of OS X, and since it seems to have started with last release of Firefox, it is hard to see how it is  not a Firefox bug.
(Just added my eMail to the CC list)
Looks like it is real. OS 10.3.9, Firefox 1.6a1.

It doesn't move randomly, it moves to the (0,0) of the main window. A good example is the "About Deer Park..." window. Move that window around, and then let go. As you should see, it usually happens on mouse up, not when you are moving the window. If you drag it extra-super-fast across the screen, it doesn't happen as much. I got a screen video of it.

http://bigpixel.macintoshdevelopers.net/DeerPark.mov
At least in Firefox 1.5.0.1, it appears to be random. Sometimes, it moves the way it shows in the movie above, but at other times, it moves to crazy places, including off the edge of the screen. So it's not clear where it's getting the target coordinates to go to.
Yes, it just happened to me a few more times, this time, half way off the screen. A temporary fix for it would be to go to Window>Zoom
I get this bug all the time, and I have found that it works for smaller windows, such as the mlb.com gameday windows for viewing baseball games. The snapping occurs, for me, whenever another page is loading. As long as another window is loading a webpage, the smaller window will snap to the top, left corner of the larger, loading window. Highly frustrating! I am using Mac OS 10.4.7 with Firefox 1.5.0.7.
I can confirm that this happens in 2.0RC1, but I have only ever had it happen when one window has multiple tabs open with 1 tab being loaded. Any other window that I move around jumps so that the upper left corner of the moved window and the loading window match.  Bug #342602 has a very good description about this exact issue.
*** Bug 342602 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can confirm that this has happened at least since 1.0 on Mac OS X. Without exaggeration, it is near constant for me. I have not had the time to try to write out a reproduction script, and will make that a priority. So far, however, I have noticed one thing. If I am surprised that it isn't happening (leading me to think that I may have new diagnostic information), opening the Downloads window renews the unwanted behavior. I have had to split my time between Safari and Firefox 80/20 because of this.

One comment said the window jumps to (0,0) of the main window, however my behavior is the same as comment #2. Wndows jump to the exact location of other open windows. In my attempts to move one or more windows, it will sometimes jump to several different other open window locations in the cascade.

I would wager some serious coin that this is a Firefox bug, or at least directly related to Firefox or an extension etc., and not restricted to the OS. It ONLY happens in Firefox for me, and nearly always happens for me.

I can't change any OS, Version, or Keywords, so I'll say this affects at least Mac OS 10.2.8 through 10.4.7, at least Firefox 1.0 through 1.5.0.7 (2.x noted in comments below, but I haven't tried it yet), and I'd classify this as keywords: pp and conversion
It's clearly a firefox bug. How do we get someone to work on it?

I don't believe it's always to the 0,0 position of a window, but a random relative location. It's just whereever Firefox is getting the value to jump to happens to be 0 more often than other numbers, so it often jumps to the 0,0 position, but I've had it jump a number of times such that the upper portion of the window is off the top of the screen.
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
> rv:1.8b3) Gecko/20050712 Firefox/1.0+
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
> rv:1.8b3) Gecko/20050712 Firefox/1.0+
> 
> When the user wishes to drag a window to a new location on the screen, most of
> the time the window immediately returns to its original position.
> 
> This bug is very difficult to diagnose. It cannot be reproduced reliably. There
> seems to be some automatic detection mechanism that tries to keep people from
> "accidentally" moving their windows around.
> 
> Some people hate to move any windows, anyway. I move my windows all the time.
> 
> When there are two or three windows open on my screen, it is absolutely
> essential for my efficient use of the computer that I can move them instantly
> anywhere, without an automatic response mechanism that restores them to their
> original location.
> 
> I tried to find out if this is a feature which exists in the preferences, but I
> found nothing mentioned. It may be an anomaly the cause of which does not exist
> in the Firefox/Mozilla source code.
> 
> But it is very real, and it is happening to me all of the time.
> 
> As I write, I tried to reproduce it again by dragging this window itself. The
> problem now does not manifest itself in this window only. This is one of the
> most infuriating things.
> 
> Any user action which the user believes will have occurred may result in the
> next moment an action being taken which depends on the result of the previous
> action. If the user's software denies the user from obtaining the first result,
> the second step may result in the user's click on their Desktop closing and
> deleting the text of a one-page email which they just wrote, because the window
> really didn't move, and their next click was directly on the close box.
> 
> Therefore, any bug is extremely severe which results in throwing away user
> input.
> 
> Comments: This bug is one of the most irritating bugs to someone who is
> affected
> by it. I feel like saying something really horrible.
> 
> 
> Reproducible: Sometimes
> 
> Steps to Reproduce:
> 


23-Oct-06 
I am running OS X 10.4.8 and FireFox 1.5.0.4.

I've found the same thing.  When I drag the FireDox window to a new location on the screen, it snaps back to the original location as soon as I release the mouse.  It does not happen 100% of the time, but more often than not.  I do not see a pattern that describes when it snaps back and when it doesn't.

I have been experienceing this problem for a few days now.  However I have read accounts on the web of people experiencing this bug back in Feb '06.

Can anyone explain what is going wrong?
Is it a bug in OS X or in FireFox?
Where is the fix?


Thank you,
Martin








 
When moving a window, if another window is loading, the upper-left corner of the one that I'm moving will 90% of the time snap to the top-left corner of the loading window. It was a bug in 1.5 and is still a bug in 2.
(In reply to comment #15 by Dave)
> When moving a window, if another window is loading, the upper-left corner of
> the one that I'm moving will 90% of the time snap to the top-left corner of the
> loading window. It was a bug in 1.5 and is still a bug in 2.

I have a NOC wall with 8 monitors running OSX 10.4.7 and Firefox 1.5.0.7
This happens to me constantly making Firefix completely unusable. 

I agree with Dave - this happens when a window reloads. I have about 14 windows open. All of them refresh at some rate. If I move a window while nothing is refreshing I am fine. If I move one or click on a title bar of one while a window is refreshing the window will snap somewhere else. Often on another monitor.

FYI Some of them refresh with <meta http-equiv="refresh"...
and some of them are refreshed using setTimeout('window.location.reload()'...

Rupert


I also want to confirm that this is still happening in Firefox 2.0.. I had seen it happen a few times when I was using 1.5, but now it seems far more frequent in 2.0. I.E., I only saw it like 2 or 3 times in the many months I was using 1.5, but since 2.0 was released last week, it happens almost every day.

I just tried reproducing it, and it does seem to happen more often when there is a page loading in the background. The front most window will snap back to the top left location as the loading page if you try to move it. I have also seen the front most window snap to the top left location of my downloads window.

Twice, though I don't know how this happened, I tried moving my browser window and when I let go after dragging, it jumped 1/2 way off the top of the screen. When this happened, I lost the ability to move it at all because the title bar and buttons were off the screen. I had to go to Window > Zoom to get it back on the screen. When this happened, I think it must not have been snapping to any other window, because I didn't have any other window with the title bar off the top of my screen, so it might be a separate bug.

P.S. This bug is super annoying.
I encounter this bug all the time, but I haven't found out how to reliably reproduce it.  I am running FF 2.0, Mac OS X 10.4.8 with an NVIDIA GeForce4 MX and an Apple Cinema Display.  I never had this problem with FF 1.0 and 1.5.

This problem is incredibly annoying and has caused me to revert to using Safari.  I would never be able to demo Firefox 2.0 on Mac OS X because this problem is such an egregious early beta type of issue.  It's embarrassing!

I'm not sure how the problem starts happening, but once it affects a given window, it tends to keep affecting it, albeit inconsistently.  At first, dragging the window to a new location results in it snapping back to its original position.  After a while, it stops doing this, but if the window is moved such that its top edge is close to the top of the screen, it will usually also move back.  It is usually consistent in where it moves back to, but not always.  Just now, a window repositioned itself such that the upper part of the window was completely off the screen!  I couldn't interact with that window anymore and had to close it with a keyboard shortcut.

Showing snapback bug occurring (and not)
Issue: newly opened window "snaps back" to overlay previous existing window.

Attached a screen movie of the bug. Here's additional information to hopefully help target the cause.

Firefox Window Snapback and occasionally snap to off screen only encountered by me AFTER upgrading to Firefox 2.0. 

Firefox About info:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

My Mac info:
MacBook Pro - 17in, 2.16 GHz, 2 GB RAM, OS 10.4.8, with attached Dell 2407FPW 24" LCD Monitor, Apple USB Mighty Mouse

Environment When occurred:
Apps Running (showing in dock): Dashboard, Safari, Adium, Entourage 2004, Firefox, Omni Outlined, Word 2004, Skype, Preview

Firefox:
One window open, two tabs. Opened new window manually (cmd+N) tired to move, snap back. Happens several times, seems to occur more often with a quick grab/drag, release. Once it stops can sometimes get the snap to start again if you drag second window top left corner to near original window top left coner position.

Have created screen grab which I will attach. Hope this helps. WHen occurs fire fox become fairly unusable.

Have encountered the Snap to off screen before as well, but currently can't recreate. 
I'm starting to lean towards the auto reloading as a cause. Today I'm watching a wootoff from woot.com. I'm using a couple woot watchers:

http://www.strasburgtech.net/woot/v2/  Meta data:
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="expires" content="Thu, 07 Dec 2006 17:55:55 -0600">
<meta http-equiv="refresh" content="15">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

http://yellowbkpk.com/wootcheck.html
This one uses a java script in the <head> vs the refresh above.

They both are auto loaders that reload every 15-30 seconds. Maybe in the last six months I've noticed this issue 3 or 4 times.

PowerBook G4, 667 MHz, 68 MB RAM, Mac OS X 10.4.8, FireFox 2.0
Currently running apps: Adium 0.89.1, Microsoft Entoruage 11.2.5, iTunes 7.0.1, Microsoft Excel 11.2.5.



This has been a problem since at least 1.0 for OX X and has plagued me for months.  
Occurs randomly - hard to reproduce. I am using a dual-monitor configuration (both digital).  

Browser: 
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

OS:
10.4.0 - 10.4.8
Many people comment that this is difficult to reproduce.  I find it to be quite reproducable.  See Bug: 342602 for the description.

https://bugzilla.mozilla.org/show_bug.cgi?id=342602
Related to
https://bugzilla.mozilla.org/show_bug.cgi?id=206649#c19
???
Hm... anchor didn't get linked. it's comment 16, about the "RepositionWindow" code.
This happens to me too, and sometimes (like right now) it positions the top of the window above the start of the screen, so there is no way for me to even move the window at all!!!  I have to quit firefox at this point...  I should add that the window should be moveable by clicking and dragging on the bottom of the window as well as the top.. that would be helpful..  But please please pleast fix this bug!!!!
This has happened to me in all versions of Firefox from 1.0.x through 2.x.

In my own limited experience, it is a far more severe problem on machines with multiple monitors, possibly because the non-rectangular desktop space allows the window to be moved to a location where the title bar is inaccessible.


Not a solution but I use this in a bookmark to reset the window position if it jumps off screen:

javascript:window.moveTo(0,0);

Someone fix this!  It's incredibly annoying.
I also have this bug and have had it for at least a year.  Dual 30-inch ACDs, Firefox 1.5/2.0.x, etc.  If a Firefox window is loading content, moving any other Firefox window usually causes it to snap back.  It sounds like maybe it's dual-monitor specific?
Don't think it's only on multiple monitors, as I only have a single 21" monitor.
Woops, accidentally pressed Commit...

If you want this bug fixed, you don't have to keep commenting about it. Vote for this bug.
if you open the openme.html file, and allow it to open it's little popup window - either by clicking the link, or allowing the javascript popup... then move the two windows around a bit... within a minute they will start snapping to each others position.  The one thing that seems to 'undo' the snapping is opening and closing the download window.  But once the download window is closed again, a few movements of the windows will make them snap again.
I have added some files in addition to Jay's example, this time using a meta refresh instead of javascript. (I just altered Jay's code because I was too lazy to write new pages).

I encounter this problem a lot because I often have a server status page refreshing on one monitor while I work on the other. My solution: open the refreshing page in Safari and work in FF :)
I just wanted to note that it doesn't seem to be specific to page reloads.  

I use some pages that use a lot of XMLHTTPRequest calls and they seem to cause the snapping problem too.

This window snap problem has made using Firefox a pain in the __s. If a window has  an active redraw or an incomplete window draw or a download acknowledgment dialog window, it triggers this new window to snap on top and covers over aformentioned window. Some times the window header if stretched over two displays will snap off the screen making it impossible to move with a mouse. And now I've just witnessed, as I am typing in this window, if I try to move any other window on the screen they snap over the top of this one with the active cursor/comments.

I've been waiting for about 4 or 5 versions for this to be fixed. I don't understand how it has gone this long without being addressed. 
Yes, I have had to nearly stop using Firefox for this reason. The most frustrating thing is that, according to the assignment field, it's not being worked on. I assume that's for priority reasons, and I cannot contribute because I don't have the application programming knowledge, so it's hard for me to complain further. Unfortunately, it stops me from using Firefox, so other fixes and upgrades and so on are useless to me.
It has been suggested that this bug might only affect PowerPC macs.  For the record, my machine is intel based - a Macbook Core 2 duo - and I am affected by this bug. 

Once again - it is not just page refreshing - XMLHTTPRequest calls trigger it as well. 
WFM Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a3pre) Gecko/20070215 Minefield/3.0a3pre.  I tried both testcases (loaded using jar: URLs).
I get this behavior a lot on PPC 10.4.8 with 2.0.0.1.  I notice it happens a good deal with I do View Source and open a web page in a new window, try to move that web page, and it will snap to the position of the view source window.  This isn't the only time it happens, but it happens a lot in this scenario.
Ok.  Here is what I've been able to determine from additional testing.

First, Camino is indeed unaffected by this bug.  I spent 20 minutes
testing all the things that usually cause the problem in Firefox - No
dice.  Can't cause it.  Takes all of about 30 seconds under Firefox.

Second, I've been able to narrow the behavior.

1) The window only snaps when you are attempting to move it.

2) It is not the opener that it snaps to.

3) When it happens the window that snaps always snaps into the top/
left position of the last window moved,   So as to directly overlay it
(the size is not changed)  I created a new window after the ajax-
active window, and moved it. Then moved the ajaxy-active window. It
snapped to the new window.

4) It isn't only the ajaxy window that snaps.  Other windows will snap
too, if there is an active ajaxy window... and it's always the last
window moved.

5) It doesn't require an active ajaxy window.  It just needs to have
happenned once with an ajaxy window - then it will keep happenning,
even if you close the ajaxy window.

6) As long as you have a window opened that was open when it happenned
it will keep hapenning.  If, however, you close all those windows and
open new ones, the problem goes away.

So - whatever it is - it is persistent after whatever triggers it
initially - tied to the windows that snapped / were snapped to.

Shed any light?

JayK
This bug seems to have gotten much worse with Firefox 2.0.0.2.  So much so that I am abandoning firefox for camino until it gets fixed.

Bruce

The Mac Firefox Window Jumping bug drives me crazy. It was in 5.5 and is still in 2.0.0.2. I drag a window and it jumps to a different position over and over again.

It doesn't happens some of the time it happens every time I open Firefox on both my PPC and Intel Macs. If I wasn't so married to my extensions in my work flow I would definitely choose another browser, that is how high my frustration is.

I know everyone is busy but if there are any answers out there I would dearly appreciate it.

Thanks
Scott
mike pinkerton: any idea who would be best qualified to look into this?  this seems to be a show-stopper for a bunch of mac users.
Bump. FF 2.0.0.2 OSX 10.4.8, Mac Pro 3Ghz
Bump, MBP C1D 17" 2gb - FF2.0.0.3
Windows spawned from other pages 99% of the time will snap to the top left main window position. This defeats the purpose of the pop-up especially when watching video. Imagine a main window open, on pop-up, mail, IM, etc. Now forced to use safari in addition....
(In reply to comment #43)
> mike pinkerton: any idea who would be best qualified to look into this?  this
> seems to be a show-stopper for a bunch of mac users.
> 
Mike, It is a show-stopper. I logged in to vote after finding this page through Google, while researching this frustrating problem, and I am now deleting Firefox from my mac. This problem comes up every 4 to 5 minutes and makes the Browser basically unusable for me. I won't use Firefox again until this is fixed. unfortunately I am not in a position to fix any bug in Firefox as I have no coding experience, but hopefully that vote counted for something.  

I concur... I am almost ready to jump to Safari because of this bug.
This is a constantly recurring problem when some window hasn't finished loading. 

With FF being used by so many people it is amazing that a useability bug like this hasn't been assigned for to be fixed.

How can this be escalated???
David, 

I think the only thing we can do is vote on this bug and hope it gets assigned to someone. 
Anyone else got an Idea, maybe we can get this dugg on digg hahah. That should get some attention. 

Jay Saenz

(In reply to comment #48)
> This is a constantly recurring problem when some window hasn't finished
> loading. 
> 
> With FF being used by so many people it is amazing that a useability bug like
> this hasn't been assigned for to be fixed.
> 
> How can this be escalated???
> 


Some questions that might help us track this down:

1. Can anyone reproduce this bug with the default Firefox theme in use?
2. Can anyone reproduce this bug *without* loading any sort of plugin?
3. Can anyone reproduce this bug *without* using any extensions?

(In reply to comment #50)
> Some questions that might help us track this down:
> 
> 1. Can anyone reproduce this bug with the default Firefox theme in use?
> 2. Can anyone reproduce this bug *without* loading any sort of plugin?
> 3. Can anyone reproduce this bug *without* using any extensions?

I just did a fresh download install of Firefox on a brand new user account.  Uninstalled all the add-ons (dom inspector and talkback) - restarted FF.  

Everything is disabled that I have an option to disable, including java.  The only thing that it's allowed to do outside of render html/css is run javascript.

The bug is still present.  Still produces the same results within 15 seconds of loading the sample files that were attached to this bug.

Jay

Jay - thanks for the info. Can you now post the following info about the same machine you tested on in comment #51:

1. Intel or PPC processor(s)?
2. Do you have any unsanity haxies or APE (Application Enhancer) installed on the system? This could affect event a fresh user account if you have them installed systemwide.
3. What Mac OS X version are you on?
4. What version of Firefox were you testing?

I can verify this with the default theme in use (not testing for no pugins or extensions).

1. Processor - PPC
2. No known APE.
3. 10.3.9
4. 1.5.0.11
> 1. Intel or PPC processor(s)?
   Intel (Macbook pro)

> 2. Do you have any unsanity haxies or APE (Application Enhancer) installed on
> the system? This could affect event a fresh user account if you have them
> installed systemwide.
   Have tested now both with and without APE - same result.

> 3. What Mac OS X version are you on?
   10.4.9

> 4. What version of Firefox were you testing?
   2.0.0.3


Also - I can tell you that in November, I had a G4 PowerBook and had the exact same issue.  I don't recall what version of Firefox it was, but I do know that I had the problem in the FF 1.5 series as well on that machine.  

Jay
Hm... It seems to WFM now. Haven't had the problem in a while. Default plugins and themes, 2.0.0.3.
Don't let Chris fool you...  it's still going strong for me, 2.0.0.3.  :)
Wait, it just happened to me again.

I think I got it. Have two pages load in 2 separate windows open. Make sure they constantly refresh, or are huge pages so there is enough time to test. (example of large page: http://worm.bluesfear.com/index2.html ) While they are loading, drag one window around in short amounts quickly. I THINK whenever the status bar updates, the window ends up snapping back.
This bug has been driving me insane forever! It has indeed gotten worse since 2.0 - it's at the point where the browser has become all but unusable. I only use it because Safari doesn't support rich text editing and I need it for Gmail.

For me, the bug most often occurs when I click to download a file. The download starts in the download manager - and if I try to move a window after that - it snaps to the upper left corner of the download manager.

If I very carefully move the window a tiny bit at a time, I can sometimes break it free from the snap. Otherwise, I have to quit the program.

Happens on my:
MacBook Pro
Powermac G5
Mac Pro

all running 10.4.9.

It's become so consistent that I dread having to download a file.

Good karma to the person who fixes it!


I found this bug from the blog post calling for users to let the developers know what's bugging them about Firefox for the Mac ( http://iamthewalr.us/blog/2007/04/20/firefox-on-the-mac/ ):

"So, fellow Appleites, I put it to you: What sucks about Firefox on the Mac? Send mail to macfirefox at this domain, and let me know what you think."

I just wanted to chime in and say that this bug has been affecting me since at least 1.5 as well. A couple things I've noticed:

* Having a View Source or DOM Inspector window open seems to be a big trigger for this bug for me (closing the View Source or DOM Inspector seems to almost always resolve the problem)

* Right-clicking on the web page to pull up the context window seems to stop the bug behavior as well (could be just a coincidence)

I used to think this was a dual monitor bug since I'm usually using my Powerbook and LCD screen as my two monitors when the bug occurs, but apparently some commenters further up said that it happens on single monitor setups. My setup:

* Powerbook G4 - PowerPC G4 (1.5)
* Firefox 2.0.0.3
Unfortunately I can't reproduce the bug using the test cases with Firefox 2.0.0.3 on Intel 10.4.9.
Forgot to mention that I am running OS X 10.4.9 (on PowerPC). 

I just tried the test files (first one attached by Jay Kurl) and was able to reproduce the problem after about 3 drags per the instructions in the HTML file.
Hi Josh,

If you open up the files I originally attached, it will open two windows.  If
you click-drag the title bar on either window, just for a moment, (say moving
in about 60 pixel increments) it should trigger.  Sometimes it helps to switch
between moving one window, then the other.  It is an elusive bug to replicate,
but if you do it for a minute or two, it should trigger the bug. (it does every time on every mac I try it on)

I've tried it on 3 different macs, intel and G4, fresh install, no add-ons, new
user account created specifically for the test, and they all exhibit the issue. 

Do you have any add-ons installed?  If there is an add-on that kills this bug -
We all would love to know what it is. ;-)

JayK
(In reply to comment #13)

> I don't believe it's always to the 0,0 position of a window, but a random
> relative location.

I've never had it jump to a random position on the screen, but have occasionally had it jump so that the grab bar is under the main menu bar so you can't grab it (which is one reason I hate the fact that mac windows are borderless).  Hide/Show repeatedly will eventually get it back on the screen though.  I'll upload a screenshot of the hidden grab bar...

Most of the time, however, it jumps to the position of another window that is currently loading, or in the case tonight, to the download window which was actively downloading.  If you minimize both windows, then restore them one at a time, you can position them where you want though (I usually restore the loading window last, I think it doesn't fix the problem if you don't).

I seem to recall having had another app jump to where the grab bar was inaccessible once, but the window snapping problem is something I only see in Firefox, though maybe that's because other apps I use don't have the plethora of windows coming and going as I usually have with Firefox...

  

  



    
    

    
  
It almost sounds like there are two different, but related bugs here from what I've  read. One bug leads to a child window being reset to point 0,0 (of the first window, if there is a page loading in that first window) after being dragged to a certain place on the screen; the other bug seems to be similar, but the window can have its position moved below 0,0 so that the titlebar / grabbar (mind my terminology) is off the screen or below the menu, where it is not accessible. The first bug (which I have only noticed occurring for myself very recently) is just annoying, but the second bug is pretty severe and is driving Mac users away from Firefox.
We know this is happening in both 10.3 and 10.4 (both PPC and Intel) and (I believe) with 1.5 and 2 code. We also know it isn't caused by an add-on as we've tried running completely clean. And after reading the comments here I have been able to reproduce this behaviour on two other Macs, so I suspect this is likely a code problem, not something external.

I've never done any work on the Mozilla codebase but this honestly doesn't seem like it should be TOO difficult to resolve, so I'd like to give it a shot - however, I have to figure out where things are in Mozilla. It's massive. If anybody knows where the windowing system is can you please point me in the right direction? Through random searching I've found nsCocoaWindow and widget/src/mac/nsChildWindow, but if anybody knows specifically where I should look please let me know. For now I'll scan through those files and see if I can find anything. If I come up with anything I'll share the patch here so whomever would like to may test (especially since I'm only encountering the first type of bug [child window position set to point 0,0] I'll need somebody to test against the other bug).
If anybody can give me some guidance / help let me know. Thanks in advance.

  

  



    
    

    
  
I see the windows getting moved to all different parts of the screen. My sense has been there is one bug and the window is being set to whatever values are in a particular variable (relative to some parent window). It's just that 0,0 happens to be in this variable a lot of the time, so it appears that is being set specifically to 0,0 and that it's not random. This implies there is some stray code that is overwriting this variable and oftentimes, it just happens to overwrite it to 0,0.

  

  



    
    

    
  
I had Thunderbird do the "snap to another window" today once also when I opened a window while a message was in the process of being sent, fwiw...  I don't know anything about the implementation, but have heard that mozilla et al are single threaded and wonder (complete SWAG) if the system is doing something automatically while the engine is busy with something else and not paying attention, using the last values it's seen?

  

  



    
    

    
  
Unfortunately, like the rest, it's not replicable...

  

  



    
    

    
  
cc'ing colin barrett per his statement of interest in making firefox on the mac suck less (http://iamthewalr.us/blog/2007/04/20/firefox-on-the-mac/)

colin: josh can't seem to be able to reproduce this.  hopefully you'll have better luck.

  

  



    
    

    
  
I'm not really able to reproduce this :( Is it still a problem with newer Minefields, esp ones with bug 376808 landed?

  

  



    
    

    
  
I was not able to reproduce the bug in the minefield build from this morning.  I have not tried earlier minefields - so I don't know if this changed recently.

Still present in 2.0.03 though.

Jay

  

  



    
    

    
  
This bug has been occurring on various macs for a while now. Currently I am using 10.4.9 Firefox 2.0.0.4

I can almost reproduce this issue, if a window is in the process of loading, then you move another open Firefox window it tends to snap over the window which is currently loading. BUT sometimes it just happens anyways... possibly the window behind is loading data (refreshing) which causes the snapping bug with other windows.

I hope this information helps, im not a coder, do not pretend to be one but would like to contribute as much as I can.

Thanks!

  

  



    
    

    
  
Please - someone have mercy. Fix this bug. It is driving me crazy. I am a designer that needs to have more than three or five windows at one given moment to compare work progress and the windows snap so much to the point of driving me crazy - interrupts my workload and hampers my efficiency. It also makes me look stupid with clients or other stakeholders cause I can't control Firefox... It is so irritating that's why I am venting right now right here  :-)   Thanks for any help provided asap!!!

- Ariel

  

  



    
    

    
  
This one constantly causes me grief also.

OSX 10.4.10
FF 2.0.0.6

I am having to use both FF and Safari to work and Safari just does not cut it...

  

  



    
    

    
  
If there is one thing that has disappointed me in the Mozilla project more than any other thing in FireFox, it is this bug and the lack of progress on it.  I used to work in software development, and I can tell you that any critical bug almost two years old would result in somebody being fired.  I know FireFox is supported by the community, but what does it take to get this community to fix something that affects SO many users?

  

  



    
    

    
  
Yep. This is horrible. I've held off commenting until now, because I assumed someone would take an interest in fixing this. I'm a web application developer and I constantly need to have multiple windows open in various load states. I'll always need to run Firefox for testing, but honestly I'm starting to run Safari 3 more and more. It faster and I don't have to put up with the awful snap back problem.

  

  


Flags: blocking-firefox3?

    
    

    
  
Is anyone able to see this bug using Firefox 3 alphas or nightly builds?

  

  



    
    

    
  
I am unable to reproduce the bug with Firefox 3.0a8pre.en.

It would be really lovely to see a patch for FF2, though.  FF3 is still a ways off (FF3 is unusable), and FF3 is enough bloated that many people will stick with FF2 for years to come.


  

  



    
    

    
  
This is fixed for Firefox 3. Do not reopen unless you see it appearing in Firefox 3. It will not be ported back to Firefox 2.

  

  


Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME

    
    

    
  
That attitude is a major roadblock for firefox.  Firefox 2 is still clearly beta, albeit probably late beta.  Trying to push people to 2 already is highly premature, and pushing people to 3 already is just crazy.  Do you want to provide a reputable, reliable, product that earns its reputation, or do you just want to play with bleeding edge toys?

  

  



    
    

    
  
Firefox 2 is actually a released product, at version 2.0.0.6. It's not a beta version -- I'm not sure where you're getting that from.

Firefox 2.0.0.x releases are only to fix crashes or provide security enhancements. This isn't a crash or a security issue, so it will need to wait for Firefox 3.

  

  



    
    

    
  
You can call it released if you like, but the level of the security issues recently exposed indicate it's still beta quality... IMHO...  I'm sticking with 1.5 until it stabilizes, as I do with any .0 product.  You're telling me that a .0 product isn't going to have any but the most severe bugs fixed, ever???  Maybe it's time to take a look at alternatives...

  

  



    
    

    
  
The "Is anyone able to see this bug using Firefox 3 alphas or nightly builds?" in comment #77 suggests to me no one has any idea is causing this bug. It appears to be fixed in Firefox 3 perhaps because either not enough people have used it to tickle the bug or a rewrite of some section of code has randomly fixed the problem.  I only use Firefox becasue of its extensions.  This bug however makes Firefox too irritating to keep using.  

How many votes does a bug need to get someone to take it seriously?



  

  



    
    

    
  
Colin, it's disappointing to read that a bug that has affected users for at least 2 years may have been fixed but  won't be applied  to the current user base. I'm sure it's not your intention, but you post comes off as "Well, we fixed it, but you can't have it. So Deal."

This bug is a problem that, for some of us, makes Firefox nearly as unusable as a crash. A fix in an alpha product with an uncertain release date isn't very helpful to those that need a stable, reliable browser today. 

Perhaps the bug is inherent in the 1.x/2.x code-base and can't be fixed, perhaps this bug occurs in such an extremely small case of users, the fix effort can't be justified (a sad possibility, but even in open source effort and focus are not free, unlimited resources), perhaps 3.x takes a different approach and makes the bug moot, perhaps the bug ISN"T fixed in 3.x and just hasn't reared it's ugly head, perhaps no one can determine why it occurs at all.

The point is we bug sufferers only have  insight into progress through these comments, which at this point are essentially:

Users: I encounter this bug.

Mozilla: We can't reproduce - can't fix what we can't see

Users: More encounters, - here's examples and steps to reproduce.

Mozilla: Can anyone reproduce in future version?

Unknown Poster: I can't.

Mozilla: It's fixed in the future, but we're not going to fix it for current users because it falls outside of out policy. Consider the issue dead unless you see it in the future.

Users: Frustration and great gnashing of teeth.

Perhaps if Mozilla could let us know at least WHY the bug occurs, HOW it's been fixed in 3.x and WHY it can't be applied to 2.x (besides "we don't want to make a 2.0.1 product." It could go a long way toward maintaining faith and support in Mozilla efforts.

  

  



    
    

    
  
This windowing problem has been seen on every single computer in our company.  However, not all our employees would login to bugzilla and signup to vote for repairing this bug because they are lucky to know how to use a mouse. So speaking honestly, in our case, only 1 percent of the people aware of and experiencing the bug are bugzilla reporting it here.

Thank you for addressing it in version 3.    :(    We're marginalized, we're the 5% of the market Macintosh users. We're lucky there's a Firefox for Mac. Use Safari if you don't like a buggy Firefox cause honestly the other %95 of Firefox users and %99 percent of Firefox for Mac OS X users aren't complaining about some "restricted window" problems. So %4 percent of the Firefox user base experiencing the problem aren't reporting it and we don't need to hear it from the less than 1/100th of %1 percent who have reported it.

  

  



    
    

    
  
The advantage of this kind of attitude from the lead developers is that it's self-fulfilling---by refusing to fix it you exclude those seriously affected from your user community.  I'm no longer a firefox user because of it.  Camino actually works.


  

  



    
    

    
  
ooh!!!  Thanks for the tip. I will try that out and forget about this awful bug...  Is Camino 99.99% compliant?

  

  



    
    

    
  
fed up. switched to camino

  

  



    
    

    
  
I bet there are tons of people experiencing this problem who never even think to file a bug on it.  I was describing this bug fiasco to my spouse and she said she has the same problem frequently with Firefox, but never mentioned it.  Sad state of software when people just accept this.

Anyway, this wont get any more attention, they've closed the bug.  Sucks to be the user.

  

  



    
    

    
  
Alright, here's the rundown:

We don't know why this bug is happening in Firefox. None of us can reproduce it reliably enough to test and fix it.

Because Firefox 3 has had a LOT of code for the Mac rewritten from scratch (in fact, almost all of the underlying code on the Mac is completely different), this bug is gone in Firefox 3.

We didn't specifically "fix it and not decide to help you guys out". I wish we could, but we are basically at square one here -- we have no idea what's causing this and no idea what made it go away.

I understand how frustrating this is, and I wish I could help you.

  

  



    
    

    
  
Thank you, that answer is perfectly reasonable...

  

  



    
    

    
  
Colin,

Ditto. Thanks for clarifying. We're an ornery bunch, but most of us appreciate straight answers - even if they aren't the ones we want to hear.

Thanks for your efforts.

  

  


Flags: blocking-firefox3?

    
    

    
  
There's a ton of people on a forum that I frequently visit complaining about this odd window movement bug. Doing a quick search of the site:
http://forums.macosxhints.com/showthread.php?t=63847
http://forums.macosxhints.com/showthread.php?t=51996
http://forums.macosxhints.com/showthread.php?t=79299


  

  



    
    

    
  
(In reply to comment #90)
> We don't know why this bug is happening in Firefox. None of us can reproduce it reliably enough to test and fix it.

Wow. Surprising. I can reproduce this on literally dozens of MBPros on FF or BonEcho.


> We didn't specifically "fix it and not decide to help you guys out".

It seems that "you guys" is a very quickly growing OSX userbase of developers and plain 'ole end users. A userbase that should not be ignored.

> but we are basically at square one here -- we have no idea what's
> causing this
I find that hard to believe given the level of debugging tools available these days!

I am just going to say that although the efforts of all FF development are very much appreciated, the fact that this bug has been "closed" is a very un-open-source-like response and attitude, blatantly ignoring a serious usability problem - one which negatively affects all FF adoption and perception, as well as the actual user experience. At the moment it's too risky to demo a web app on FF using your Mac to mgmt because of this bug. This bug also interrupts "real" work.

FF3 might be coming out and that's where the devs' heads are at - but FF2 will be out in the field and in use for quite some time. There should be /some/ slightly better commitment to fix bugs like this. Let us know if sending money, pizza, beer or all of the above will help?:):)

This does not mean your efforts are not appreciated. On the contrary!





  

  



    
    

    
  
Hi Harold,

We just simply do not have the resources to fix this bug for Firefox 2. Feel free to try a nightly of Firefox 3 though, you can get one here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Firefox 3 includes a completely re-written version of the low-level mac plumbing, which is where this bug is. There is no code shared between the two versions, so it's not a simple matter of just backporting the fix from one version to another.

There are only a couple of us working in this area, and everyone is trying really hard to get Firefox 3 and its awesome improvements ready for a release as soon as possible. I know this bug is frustrating, and if it's really bothering you, give Firefox 3 a try.

  

  



    
    

    
  
"I can reproduce this on literally dozens of MBPros on FF or BonEcho."

So can you think of something that those dozens of MBPros have in common? Because I have used quite a few Macs in the past year and haven't seen it on a single one. Do they all have a particular piece of software installed? One thing they have in common is you as a user, do you do anything with Firefox that isn't something most people would do?

  

  



    
    

    
  
(In reply to comment #95)
>give Firefox 3 a try.
I will do, thanks.


(In reply to comment #96)
>Do they all have a particular piece of software installed?
OSX 10.4.8 onward, all sorts of systems.

> do you do anything with Firefox
> that isn't something most people would do?
Yeah probably. Like open more than one FF window, and then try to move it to a different position. I'll stop doing that:)




  

  



    
    

    
  
Just to add my two pennies.

I have been a long time Firefox user on several macs in my history. I also have been experiencing this very common and almost predictable window snapping.

I get frustrated, but I live with it... would rather not though.

It has been here for some time, and through various versions of Tiger, up and till the most recent. Do not use Jaguar yet.

I also experience it on pre-intel and intel Macs from iMac to MacBook Pro and macBook. It's there and its there a hell of a lot.

Read with interest these comments, so tried Firefox 3 today. actually, just this evening, but already, with only 15mins on the clock I am confident in saying that this seems to have cured the window snapping. I may be  talking prematurely, but 15mins in Firefox 2 would have seen this snapping countless times. I have tried to invoke it, having many windows open, countless tabs, opening new windows from links, most combinations that I generally work with and so far... Fingers Crossed. Will be interesting to see if it 'creeps' back at some point, then it may be easier to see the connection. So will monitor with interest.

I do have lots of windows open, for research and work. And I want my windows to stay where I put them. I can add that the snapping usually occurs when there are other FF windows underneath. The top most active window, when you move, will snap to the window below, wherever that is. Only some cunning window movement and shuffling will reset the snapping.

Anyway, just wanted to add that for the moment, all looks great. Obviously none of my standard trusted plug-ins work, but for surfing and searching, I will be using FF3 mostly.

Thanks Guys,

Graham

  

  



    
    

    
  
This is happening to be on a daily (actually continuous) basis.

Happened in 2.0.0.12, 13, and is happening in 2.0.0.14.
Happened in Tiger, Happening in Leopard.
Happened with a Fox, happened in a Box, happened on a train, happened in the rain, happened here and there, happened everywhere!  (My apologizes to Dr. Seuss)... What I am trying to say is that this bug happens.  A lot.  And it is a royal pain.

Some things I have noticed:
 - It only happened when there are two or more Firefox windows open  (Download manager is sometimes sufficient.. but a preferences window (i.e. add-ons window) does not seem to be a problem) 
 - It seems that the longer that you take to drag the window, the higher the chances that the bug will occur.   For example, If you click, drag and release very quickly, the window usually stays where it is put, but if you click, drag for a while... and then release, it almost always snaps to another open window when you release the mouse button.
 - It seems to occur when one of open tabs in the windows you are NOT dragging updates during the drag, and it seems to always snap to whichever window updated.  For example: 
    - Begin dragging window A, while window B and C are open.
    - Before you finish dragging, Any tab of Window B updates (Does not need to be the active tab).
    - You release the button to end dragging window A.
    - Window A instantly jumps to the position of Window B. (Never C).

To reproduce this:
 - Run Firefox (1.x and 2.x. I haven't tried 3 yet) on OS X (Tiger or Leopard).  
 - Open a page which receives periodic updates.  (Gmail seems to be a good example, but any page which updates frequently works.. A download manager window that is in the process of actively downloading and updating works particularly well if the file is big)
 - Open a second window (it can be blank.. what is loaded is irrelevant).
 - Try to move the second window to a new position... take your time.. drag slowly... and release.  (might need to repeat this step, if the page in the first window does not update quickly enough)

I also would like to point out that the following bugs are all duplicates of this one.  This is really a "REAL" bug, and needs to be addressed.  It makes multi-window browsing on OSX completely impractical:  335023, 375919, 421759, 429335.


  

  



    
    

    
  
I've had this same problem for the past couple of years now as well. Charlie describes the problem the best. The window that snaps into a new location snaps to the x location of another open window. It's y location is the y location of the other open window + the height of the Firefox title bar. 

It is strange in that it happens all the time but with seemingly no pattern. I can sometimes move a window without the snap location occurring while at other times it seems as if it snaps to the location no matter what I do.

  

  



    
    

    
  
Hello everyone:

NOTE 1.: ---- THIS PROBLEM CAN BE REPLICATED AT ANY TIME VIA OPENING THE HELP WINDOW AS NOTED (BELOW).
NOTE 2.: ---- REPLICATION OF THE CAUSES OF WHAT EVERYONE HAS BEEN DESCRIBING AS "RANDOM" WINDOW MOVE PROBLEMS, ARE CAUSED BY PROBLEMS IN CODING OF THE FIREFOX SEARCH BAR, AS NOTED (BELOW).
NOTE 3.: ---- WORKAROUND: when switching between windows, always click in a non-TitleBar area (either the body of the other window or on the toolbars) because the problem occurs only when clicking within the rect of the TitleBar to switch to, or drag, another window, when the blinking cursor (or the focus) is inside the Firefox Search Bar's text field.  Hence, always click to set the blinking text cursor and its focus anywhere except the Firefox Search Bar's text field, as having the blinking cursor there in the active window when you grab or click any other window triggers the issues.
NOTE 4.: ---- IF THE DEVELOPERS WANTED TO QUICKLY FIX THIS PROBLEM IN VERSION 2.X.X.X OF FIREFOX, THEY COULD SIMPLY REMOVE THE FIREFOX SEARCH BAR FROM THE NAVIGATION TOOLBAR, SINCE IT IS THE CAUSE OF THE RANDOM MOVE WITH PHANTOM CLICK AND OTHER PROBLEMS. (I'm not sure if this would fix the same problems that occur each time browse windows are moved while the Help window is open, as the code for the Help window may be independent which, due to poor coding, also produces exactly the same issues plus others described (below)).

FYI:
I installed Firefox for the first time, on my Macbook a couple of days ago and started noticing the extremely un-Mac like window behaviors that seemed to occur randomly, but only in Firefox.
  Version: Firefox 2.0.0.14 running in Mac OS 10.4.11 (the latest Apple update applied was the "SecUpd2008-003Intel.pkg") Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
  Hardware: running on a MacBook 13" Intel at 2GHz, 1GB RAM, 80GB HD. {The hardware is not relevant to these bugs, nor is the OS version as the bugs are in Firefox}.


Replicating the behavior issues:
There are actually at least 3 bugs (created, as you'll see, due to very poor coding) where the behaviors can be replicated:
  #1. The snap-to movement issue ALWAYS occurs when and while the Firefox Help window is opened, and can be seen by attempting to drag a browser window around behind the Help window, with the problems starting on the second drag action on the browser window that is behind the Help window.
  Problems occur as long as the Help window is opened.
  Note: more problems (than just other windows snapping to the edges of the left edge (and/or top edge) of the Help window's current pane) occur once the "Mozilla Firefox Help" window is opened.  These other issues include:
- Unexpected restores of windows that were minimized to the Dock (even though you never clicked anything in the Dock or elsewhere to have them restore).
- Problems changing window focus
- Problems changing text selection focus
- Problems of having the blinking cursor shown in one window while the text selection is clearly active and working in another.
- Refusal of the Help window to release itself as the active (top most/front most) window thereby forcing other windows to move as if the command key is held down (when in fact it isn't) all combined with the unexpected window movement snap-to edge of pane problems.

  #2. The second set of issues covers the same problems that have been described by everyone as "appearing to occur at random times".  These are actually occurring all the time when certain specific conditions are met, and have to do with problems in the incorrect coding of the Firefox Search Bar.
The problem:
  The Search Bar incorrectly holds on to mouse clicks when the focus changes from one window to another, when one window has the blinking cursor sitting inside the Firefox Search Bar text field.  This is the Search field just to the right of the Location field where you type URL addresses (i.e. the text field with the magnifying glass icon on its right side where you choose from Google, Yahoo, Answers.com or etc. to search for info on the web).

Replicating the issue with the Firefox Search Bar.
- Open a browser window (we'll call this b1).  Move it so its TitleBar is on the right side of your screen and about halfway down. 
- Open another browser window (we'll call this b2).  Move it so its TitleBar is up near the menubar and on the left side of your screen.
- In b1 click inside the Firefox Location field (to place a blinking cursor there somewhere in the URL text). {This is to prove the point that only one of windows involved, needs to have the blinking cursor inside the Firefox Search Bar's field for the problems to begin}.
- In b2 click inside the Firefox Search Bar's text field (to place a blinking cursor there).  {This triggers the bugs}.
Now click the TitleBar of the b1 window and two things will happen very rapidly:
    1. The b1 window will become active (as expected).
    2. The b1 window will unexpectedly move (from its right side of screen halfway down position) suddenly snapping to the x,y coordinate of the top left corner of the active pane in the b2 window (which if the window only contains one pane, will align the left edge and top edge of the b1 window directly over the b2 window).

  #3. Replicating the third bug I'll call the click offset-y-time-buttonState bug (since there are three bugs that all occur together upon the user action):
  The click (mousedown then mouseup action) is expected to always be tied to the hotspot of the cursor, but here, the click is incorrectly buffered in time, and also shifted or offset vertically, from the location on the newly active window's titlebar, and down (on the y-axis) to the same y location on the "deactivating window's" titlebar, but the click itself ends up being sent into the newly activated window after it becomes active, but to a location in this newly activated window which is unchanged along the x axis (left and right), but offset from the cursor's visual hotspot location and onto the y location (within the newly active window) where the deactivating window's titlebar was previously drawn (even though the cursor is clearly on the titlebar of the newly activated window).
  To make the bug more confusing the mouse down action causes the background window to jump to the foreground (as expected upon mouse down) but upon the mouse *up* action, a mouse *down* action is incorrectly sent into the newly activated window at the x location of the cursor's hotspot's current x coordinate (which is correct), but at the y location of the previously active TitleBar's coordinate (which is incorrect).  This incorrect mouse down action goes into the newly activated window and on top of e.g. the "Latest Headlines button" (since that's where the deactivated window's TitleBar used to be) such that moving the cursor (remember the mouse button is up) down from the TitleBar of the newly activated window and moving the cursor left and right, gliding over the menu buttons on the toolbar of the newly activated window, shows that Firefox is incorrectly running a mouse *down* state, since, as the cursor glides over each menu button, each one activates, even though the button is no longer held down and is clearly in the *up* state.
  Again this click offset-y-time-buttonState bug occurs all the time when the currently active window has a blinking cursor in the Firefox Search Bar's field, but is only noticeable by the users when certain very specific TitleBar alignments occur.
E.g.: When the TitleBar of the front most (currently active) window, is placed directly above the toolbar buttons of another (currently inactive) background window.  Then when the background window's titlebar (seen e.g. located closer to the menubar than the currently active window) is clicked (so the background window jumps to the top of the stack and becomes active) the click action (mouseup) on the newly active window, is unexpectedly buffered in time and vertically offset down on the y, such that the toolbar button on the newly active window, gets sent the delayed as well as incorrect mouse *down* action, as well as the erroneous y coordinate, even as the true hotspot of the cursor is sitting on the TitleBar of the newly activated window (directly above (i.e. higher on the y (closer to 0)) than the location to which this phantom mouse down was actually sent, which activated e.g. the "Latest Headlines" toolbar button in the newly active window (phew!).


Bugzilla listings for this bug (of course there may be more):

https://bugzilla.mozilla.org/show_bug.cgi?id=306276
This appears to be the main listing for these bugs.

The status of this bug is now listed as: Resolved (but only for Firefox version 3 (which is still not a release version) since it uses all new code with nothing ported from version 2).

As for version 2.x.x.x Colin Barrett [:cbarrett]   2007-08-17 14:25:28 PDT, in Comment #90, claims that:
"We don't know why this bug is happening in Firefox. None of us can reproduce it
reliably enough to test and fix it."
  
  Odd, I had no trouble reproducing the lengthy list of weird behaviors, and figuring out what components they were tied to by playing with it for a couple of hours yesterday.  I'll give him this - the code is so appallingly poor that I'm Not sure any programmer would want to attempt to fix all the problems.
  The best solution would be to REMOVE the Firefox Search bar in the next 2.x release simply to eliminate these problems completely (The problems that happen while the Help window is opened, are annoying, but since they go away as soon as the Help window closes, people could just live with them until version 3 is released)).

These issues have existed since at least 04/21/2006 per a duplicate listing:
https://bugzilla.mozilla.org/show_bug.cgi?id=335023

Other duplicate listings are (per comment 99 from 306276, user Charlie (rossc@cs.colostate.edu)
335023, 375919, 421759, 429335.
and Per: 421759, comment #1 there is yet another listing for these same problems at 335608: where it says"*** This bug has been marked as a duplicate of bug 335608 ***"


Note: in 306276 Comment #24, Chris L (bpixeladmin@macintoshdevelopers.net) thought it was connected to:
https://bugzilla.mozilla.org/show_bug.cgi?id=206649#c19
It isn't.


Symptoms (quick summary):
Symptoms related to #1 the Help window:
  Once the Help window opens, moving any other browser windows snaps the browser window to the left edge of the current pane in the Help window (which may be the left edge of the Help window, or the left edge of the right pane inside the Help window, if that pane was the focus).
  The Help window becomes the top most window on the window stack and refuses to release control, even when you click in another window, or drag to move another window.  The click or drag also causes the other (non-Help window) to incorrectly snap its left or top edge to the alignment of one of the panes in the Help window).
  Minimizing windows will cause them to unexpectedly restore themselves from the Dock, without user intervention. And still they will not restore to the correct locations within the window stack, as the Help window will always be on top.
  After dragging other browser windows around they will also start to align with the top edge of the current pane in the Help window.
  Each drag of a non-Help window shows slightly different behaviors from the first time you attempt to drag a browser window while Help is open, vs the second time you attempt to drag a browser window while Help is opened (it then repeats the cycle over and over (see Detail Notes on the behaviors (below)).
  The text focus is also incorrectly held with a death grip as long as the Help window is opened and cannot be shifted to another window by any means (*even though* if you click in your browser window's Location field (anywhere in the URL's text) it will put a blinking cursor there, yet the focus for the current text selection hasn't changed (it's still locked inside the Help window).  This is confirmed via using Shift UpArrow etc. to create a selection: you will find that it always shows the text selection appearing in the Help window (until you eventually close the Help window).
  Resetting preferences does not affect the issue (not that I would expect it to, as it is clearly a very sloppy coding issue by whoever wrote the code to control the Help window.
  Once the Help window is opened, all other window operations (browser windows and other windows) are affected by this erroneous behaviors.  When the Help window is closed only issues #2 and #3 (above) remain problems.



Detailed notes on the replicating the behaviors are:

Key: Action notes - Results notes.

Replicating bug #1 the Help window:
Open Firefox.  The default web browsing window opens with one tab. - All is well.
Move the window around the screen - No problems occur as the window moves around the screen normally.

Click the yellow Minimize button and wait about 7 seconds to see if the window minimizes to the Dock, then unexpectedly restores itself while leaving the cursor untouched. - No problems the window minimizes normally and stays in the Dock as expected.

Now to create the Help window problems:
Choose Help > Firefox Help  from the Help menu. - The Help window opens and the problems begin.

Now move the web browser window generally down and to the right to another point on the screen - The very first time you try it Focus changes to your web browser window and the window moves to its new position without problems.

Now move your web browser window back to its original location - Upon releasing the mouse button (the physical trackpad button in my case (although the same problem occurs if you double tap the trackpad (to use the trackpad itself as the mouse button) to move the window, then lift your finger from the pad to release it)) the window unexpectedly snaps to a position near its previous location, down and to the right from where you just released it, with its leftside border aligned exactly with the leftside border of the Help window (or if you selected text within the right-side pane of the Help window then it aligns with the left edge of that pane).

Try clicking the TitleBar of the web browser window. - The focus does not change but instead quickly flicks back to the Mozilla Firefox Help window which unexpectedly snaps to the front, covering the web browser window.

Click the minimize button on the web browser window. - It correctly minimizes to the Dock.

In the Dock click its icon to restore it and bring it to the front of Firefox's window stack. - It restores back to its previous position but the Firefox Help window, again, unexpectedly jumps back in front of it and becomes the active window.

Grab the web browser window by its TitleBar and attempt to move it to a new location. - The first time the move is attempted Firefox incorrectly thinks you are holding the Command key while moving the window (which allows you to move windows to new locations without changing that window's location within the window stack).  This means it incorrectly moves the window around without it ever becoming the frontmost active window (the Help window incorrectly remains the top most window) since your are not holding down the command key.

Try again to move the web browser window to a new location.  - This second time, upon pressing the mouse button down to grab the web browser window's TitleBar, the web browser window snaps to the top of the window stack (covering the Help window) (which is what you expect to happen) BUT after moving the web browser window and releasing it, it unexpectedly jumps back to an alignment where now its top edge is aligned exactly with the top edge of the Help window, and its left edge is aligned exactly with the left edge of the Help window, and it incorrectly jumps back to its previous position in the Window stack, so the Help window again incorrectly maintains its position at the top of the window stack.

Now minimize the Help window. - It either minimizes to the Dock correctly, after which when you attempt to drag the web browser window around, upon release, the Help window unexpectedly restores itself and becomes the top most window again, OR it minimizes, then after 2 to 4 seconds it unexpectedly restores itself without you taking any actions.

Choose the Window menu. - You see that although the name of your web browser window and the Help window are both listed, that even though the Help window is clearly the top most window (covering your web browser window) that the menu shows a check mark to the left of the name of your web browser window (as if it thinks that your browser window is the top most window).

Now choose Window > {name of your web browser window}. - Instead of your web browser window jumping to the front to become the top most active window, instead nothing happens.  The Window menu is both: listing incorrect information, and is not working.

Hold the Shift Key and press the arrow keys (to find out where your current selection is located). - You see that the focus is still within the Help Window as that is where the selection appears.

Move your web browser window around until you can see the URL address, and click anywhere in the URL text. - Although the blinking cursor is within the text of your URL on your web browser window, you cannot select any text with your mouse, since the Help window stubbornly remains the active window.  Also, using Shift with any Arrowkey shows that the focus for the current selection is incorrectly still within the Help window, even as the text cursor itself blinks within your web browser window, still covered by the Help window.

I'm not sure what happens if one of your browser windows also has the blinking cursor placed inside the Firefox Search Bar's text field, since doing so actives the bugs listed as #2 and #3.  Presumably all these bugs would be operating simultaneously, creating even more havoc, if that's possible.


Solutions:
For the programmers of Firefox:
  The best solution to eliminate the #2 and #3 bugs, would be to remove the Firefox Search bar in the next 2.x release, simply to eliminate these problems entirely without spending endless amounts of time figuring out how to undo the nightmarish spaghetti code that probably created these problems.

Reasoning:
  The the cons, related to the operation of the Firefox Search Bar, are far worse than the pros of having this rather simple, additional functionality in Firefox remain around to mess up the overall workings of an otherwise good product.  People can search the web easily enough without this field anyway.

  As for the bugs that happen in issue #1 (while the Help window is opened) - these are annoying, but since they go away as soon as the Help window closes, people could just live with them until version 3 is released.
  Or, perhaps a simple dialog box could at least inform all users of the known problem, and that there is an upcoming solution:
E.g. a dialog simply saying:
  "Note: Window movement issues will occur while the Help window is opened.  If you need to move a window, please close the Help window first, then re-open Help afterwards.  These issues are resolved in the upcoming release of Firefox 3, which uses all new code." with checkbox "Don't show this dialog box again" so user's don't have to read about the Help window's problem each time they open the Help window.

Workarounds in the mean time:
Until a version of 2.x is released, that contains no Firefox Search Bar, users should:

- Never allow the blinking cursor to remain active in the Firefox Search Bar field, as this triggers the bugs.  Never click inside the Firefox Search Bar field.  Sometimes Firefox doesn't show the blinking cursor but the focus is within the Firefox Search Bar field, so, when in doubt, click in the Location field (where you enter URL addresses) to set the blinking cursor there.

- When switching between windows always click in a "non-TitleBar area" when you need to bring an inactive window to the front (either the body of the web page itself, or inside the blank areas in the rectangles of the toolbars).  This is because the problem occurs Only when clicking within the rectangle of the TitleBar, to switch to, or drag, and thereby make another window active, when the blinking cursor is present in the Firefox Search Bar on the currently active window.

- When you need to open the Help window, pre-position your browser window *prior* to opening the Help window.  Once opened, you can move the Help window around, but since Help always forces itself to be the active window, don't expect to be able to move any of the other windows, nor be able to click in them or even type in them.  Lookup your information in Help, then close the Help window.

Hope this helps,
   Robert Little

  

  



    
    

    
  
Robert - 

Just to let you know... The "blinking cursor in the search window" aspect, may
be *ONE* way to recreate this bug, but it is not even close to being the only
way.

I can replicate this behavior  even after disabling the search widget.

(For me anyway), the necessary condition is that the stationary window be
updating/redrawing in any way while in the process of dragging the other
window.  Perhaps your blinking cursor in the search window is a subset of this.


  

  



    
    

    
  
Robert - thanks for finding this one. That was the best response I have seen to date on this annoying issue. Thanks 

  

  



    
    

    
  
Agreed with Charlie ... Robert's reply is nice and detailed, but it doesn't completely characterize the problem.   *Any* updating window in the background can trigger it.

I find the most reliable way to reproduce the problem is to initiate a long download and open the Tools > Downloads window, then attempt to drag around any other window in the  foreground.  Because the downloads window is continuously updating (progress bar and progress %), other windows moved in the foreground will constantly snap to the download window's position when the mouse is released.   

This behavior will continue until the download completes, at which point the downloads window will stop updating.

  

  



    
    

    
  
This bug is 100% reproducible on my computer (Mac OS X 10.4.11 PPC, Mozilla 2.0.0.14) when:

- There is a full-sized background window;
- There is an active foreground window with embedded Flash;
- There is a second background window with embedded Flash; and,
- Either of those latter two windows is updating.

When that is true, any dragging of the frontmost window will cause it to snap-to random windows; sometimes it will be the "next window" tiling (that is, something like (+10,+10) pixels from the (0,0) point of the window), sometimes it will be the Firefox origin in the upper-left of the monitor immediately below the menu bar, and sometimes the most-background window as a "next window" tiling.

I do not believe that this is an OS issue, since the window repositioning should be getting passed down to FF from the OS (IIRC, aren't the FF windows getting the 'snap-to this location' command through FF as the last-able-to-handle-this-event object?), and I don't believe that Flash is the real culprit because it should not _by itself_ trigger a window to think it needs to be snapped-to anything ... 

  

  



    
    

    
  
I like it when I move my window.  I don't like it when my window moves wherever it wants to.  Do you like it?  Clearly you must ...  You also like snails dipped in chocolate don't you you dumb bunny ...

  

  



          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: