User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 This is actually a problem that I have observed for quite some time now: Whenever I keep Mozilla running for more than 2-3 weeks, the clipboard becomes unavailable/unreliable in Mozilla, basically I cannot copy/paste anything from/to a webpage - except if I'm trying to paste contents that I have copied to the clipboard using a different application - this applies to the navigator component as well as all other Mozilla components (composer,mail etc.) I can easily reproduce the same behaviour within *hours* if I use multiple Mozilla windows at once with numerous tabs open, i.e. 5 windows and about 120 tabs total. (BTW: in that regard it would be very useful if there was a scrollbar for tabs ;-) Likewise, after about 4-5 weeks, Mozilla will either crash totally - or won't quit at all (5-10 zombie processes) I have observed this behaviour with either, the static build as well as custom builds from cvs/source. So I think that this is somehow related to the underlying memory management code, however the machine is fully capable of dealing with the described load (> 1 GB RAM) Also, the behaviour does NOT occur with any other applications on this system. I'm currently using Mozilla 1.7.7, I would copy/paste the full information from Help/About *if* my Mozilla-clipboard hadn't quit working ;-) Reproducible: Always Steps to Reproduce: see above, but for example: 1. bookmark 20-30 webpages as tab group 2. open this tab group in 3-5 different browser windows 3. wait some time 4. try to copy/paste within mozilla 5. => enjoy :-) Actual Results: Usually, the clipboard won't be accessible within Mozilla - i.e. I would not be able to copy anything from a webpage, however PASTING contents from other applications to Mozilla would still work Expected Results: copy/paste as usual :-) The problem seems only to occur when Mozilla is either extensively used or when the same instance is used for a relatively long period of time (i.e. Mozilla instances that were started several weeks ago won't work reliably)
Assignee: general → jag
Component: General → XP Toolkit/Widgets
Product: Mozilla Application Suite → Core
QA Contact: general → jrgmorrison
Version: unspecified → 1.7 Branch
I'm seeing this or a very similar problem, but on Win98. More specifically: * Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.7.10) * Gecko/20050717 Firefox/1.0.6 I noticed it after trying to make a screenshot (Windows places one on the clipboard when you press PrintScreen) illustrating a more serious Firefox display corruption problem. The screenshot turned out to be even more corrupted than the display - and black-and-white on top of that. The Firefox display-corruption problem is the most common reason for rebooting an otherwise stable Win98 session - many other applications still work properly at the time. I've been experiencing it for quite some time, and have suspected the cause to be a memory management problem in some component of (or relied upon by) Firefox. I have a debugger running (Soft-Ice), and at times that the above symptoms appear, it reports something about LogError ERR_GALLOC - apparently an error condition that may be returned by the Windows API function GlobalAlloc(). I'm not particularly familiar with either X11 or Windows programming, nor with the Firefox source code, but if there's any system information I could monitor or debugger tricks I could try in order to further our understanding of this problem, I might be able to help. -aw
bug 244598 is similar to this one
Mozilla 1.7 and Firefox 1.0.6 are obsolete by now. I'm not seeing this in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008060701 SeaMonkey/2.0a1pre Does anyone still experience the bug with a recent build (and which one) of Firefox or SeaMonkey?
OS: Linux → All
Hardware: PC → All
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.