886083 - Drag and drop stops working after awhile

Status: RESOLVED INCOMPLETE

(SeaMonkey :: General, defect)

Description

[Vaghut Nady]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17 (Beta/Release)
Build ID: 20130331201104

Steps to reproduce:

I use Seamonkey for both browser and mail usage. I have a rather large number of windows and tabs open, and my mailbox is large too.

I am using the 64bit version of Seamonkey on Linux, but this problem was observed with the 32bit linux version as well, and it was even more pronounced on 32bit and took less time to trigger.

This problem occurs after normal usage and does not appear to be specific to any single feature and is difficult to reliably reproduce.

I suspect this is some memory problem but I don't have any evidence of that claim.


Actual results:

After some time, usually a few days of uptime, but sometimes only a few hours, drag and drop functionality will stop working.  This is mostly observed by the inability to move tabs and mail/folder items in mail.  When I click on an item/tab to be moved, no animation occurs and nothing happens.  There is no more specific behavior which I can point to which may be initiating the problem.

FYI this problem has been occurring for many months or possibly up to two years.  I don't remember when it first started, but I did notice it when it first occurred and then continued occurring.


Expected results:

Drag and drop should continue to work as it does when I first start the program.

Comment 1

[Vaghut Nady]

It should be noted that I have taken a number of basic steps already, including starting over with a new profile and importing only the most basic of config items (bookmarks).  I previously used the 32bit version of Seamonkey but moved to 64bit since I have so many windows and tabs open all the time.  It feels like this problem occurs much less frequently in 64bit than 32bit, but it still happens once a week or so.

Comment 2

[Philip Chee]

1. Do you have any extensions installed?
Try starting in safe mode: Help->Restart with Addons Disabled.

2. Go to about:memory
Click on "Minimize memory usage"
Does this help?

Comment 3

[Vaghut Nady]

I have previously turned off all addons and the problem still occurs as described above.  I have also cleaned up memory and it does not fix the problem.

It should be noted, however, that I have experienced that the problem will sometimes go away for a short while if I close a significant number of windows and tabs.

Comment 4

[therube]

> the problem will sometimes go away for a short while if I close a significant
> number of windows and tabs

The at these times, about how much memory is SeaMonkey using?
It is not unexpected that a Mozilla browser gets "squirrelly" when reaching the memory limits of an application (~2GB Win x86 or ~4GB Win x64 with a 32-bit app, not familiar with Linux).

In times past, it was not unusual for me to get things "loaded up", where the browser was not reacting correctly, & where closing windows, tabs, may help, for a period of time.  But in the end the only recourse would be to Quit & restart, till I'd get things "loaded up" again.

That used to be the normal, a long while back.  It would be quite irregular to see anything like that currently.  What is more apt to happen now is for the browser to perform normally, until the very end where some oddities may be observed, but by that point it is too late, because shortly thereafter the browser will simply quit due to OOM related issues.

Comment 5

[Vaghut Nady]

I just restarted Seamonkey this morning and here is the about:memory summary.  Things are working normally for now. It will probably take a few days before things go bad again, but I will come back and post the updated info when that happens.


    6.46 MB ── canvas-2d-pixel-bytes
2,624.11 MB ── explicit
   19.08 MB ── gfx-surface-image
   50.77 MB ── gfx-surface-xlib
    0.00 MB ── gfx-textures
          0 ── ghost-windows
1,701.30 MB ── heap-allocated
1,767.37 MB ── heap-committed
   65.79 MB ── heap-committed-unused
      3.85% ── heap-committed-unused-ratio
    2.34 MB ── heap-dirty
  223.53 MB ── heap-unused
   19.48 MB ── images-content-used-uncompressed
  798.00 MB ── js-gc-heap
        326 ── page-faults-hard
 21,492,378 ── page-faults-soft
2,605.95 MB ── resident
2,593.04 MB ── resident-unique
   17.20 MB ── storage-sqlite
3,981.34 MB ── vsize


If you want info from me, just ask for it. I'm technical. I just don't know what is or is not helpful.

Comment 6

[Philip Chee]

> but I will come back and post the updated info when that happens.
It's been a while and 2.19 is now out. Is there still a problem with 2.19?

Comment 7

[Vaghut Nady]

Oh give me a break. 2.19 was released 48 hours ago, and this bug requires about a week to trigger. Also, the Linux 64 version doesn't have auto updating, so I was not even aware that 2.19 had been released.

Is there any substantive reason to believe that 2.19 might have fixed this issue?

I will update today.

Comment 8

[Rainer Bielefeld]

@reporter:
Anything new here?

Comment 9

[Rainer Bielefeld]

Never confirmed by a second user, No response, so I close this one for now.

@Reporter: Please feel free to reopen this Bug if you still can reproduce the problem with a current SeaMonkey version and a current OS and if you can contribute a step by step instruction due to <https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines>  (containing every key press and every mouse click) how to reproduce the problem reliably.