User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 When dragging a draggable GUI element like selected text or link, the marquee stops from scrolling. This happens for any marquee no matter at which mozilla window (browser, editor, ...) the drag has originated. Similar problem with animated gif. Look at http://www.animationfactory.com/. Reproducible: Always Steps to Reproduce: 1. Select a text and drag it at a mozilla window which contains marqee. 2. 3. Actual Results: The marquee stopped scrolling Expected Results: Marquee continue to scroll I have tried to do some debugging and IMHO at the windows message processing loop which handles timers as well, the priority given to process windows messages is too high (windows messages always processed before timers). When dragging is applied windows sends so many messages that the timer code is never being executed.

I believe we prioritize windows messages higher so that the UI is more responsive.

imho, wouldnt you want the marquee to stop? in case youre dragging something TO the marquee, for some strange (unfathomable to me, but I wont discount the possibility) reason?

(In reply to comment #2) What you say makes some sence, however the animated gifs also don't work and I can't see any reason which will justify that. In any case, the real problem AFAICT is the general internal handling of D&D events and not some interaction with a specific widget. BTW, isn't it time to either confirm this bug or close it?

*** Bug 294272 has been marked as a duplicate of this bug. ***

This is a bug (and a big one, imho). In IE6, timers and animated gifs don't suddenly stop when you start a drag. I've tested Mozilla on Linux for this and there also, timers and animated gifs don't stop when performing a drag. So something is definetely not working on the windows platform. This bug can even be seen in Mozilla1.0. ->Widget win32 issue.

Note there is already some code in Mozilla that works around this bug: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/components/bookmarks/content/bookmarksMenu.js&rev=1.47&root=/cvsroot#699

*** Bug 311783 has been marked as a duplicate of this bug. ***

(In reply to comment #6) > Note there is already some code in Mozilla that works around this bug: While your comment helped me to solve bug 232795; I believe the workaround can't be applied here: for internal drags, the workaround fires events after the end of the drag session only. For Trunk, I wonder if darin's new "ThreadManager" could help to improve/solve this bug ?

I think this one causes bug #337761 as well. When I drag an link to my Bookmarks menu item, it will only open when I end the drag, resulting in that the bookmarks menu is displayed briefly and closed again, and the links is added on the bottom of the bookmarks.

Read my comment there: [ This can not be bug 203573, as there was no patch submitted there (yet) ! ]

This is the bug I was rambling about yesterday ;)

I wouldn't actually care if it was only marquee ;)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070227 SeaMonkey/1.5a] (nightly) (W2Ksp4) Bug still there.

It's not the message priorities but the fact that DoDragDrop that starts the actual D&D operations blocks and spins its own message loop. Perhaps we could process the messages for example in nsNativeDragSource::QueryContinueDrag but I'm not sure what should be done there.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022702 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) R.Fixed, by bug 389931: tested with URL (marquee) and comment 0 site (gif, and Flash).