When dragging elements using a combination of JavaScript and the DOM, the element is not painted until the user pauses. The mouse events starve out the paint events so the in between positions are not rendered.

Any testcase or URL that showed this problem? What Build ID # are you using?

Duplicate of bug #163526???? (Different setting of this and bug #163528)

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

This bug was split off from bug 157144

Added URL, just drag around the windows to see bug. Bug visible in Windows 2000, not on Mac OS 9.

Same here: http://blatek.board.pl/javascript/free/dragdrop/dragdrop.html

Is this related or even a dupe of bug 69354?

http://webfx.nu/dhtml/genresize/genresize.html is also fixed by attachment id=96501. Without the patch the div does not display until the mouse stops moving. With the patch it continuously updates as the mouse is moved.

CC'ing others who might be interested in this patch.

Comment on attachment 99599 [details] [diff] [review] improved patch which filters out non-user generated mouse moves generated by window creation r=rods

Comment on attachment 99599 [details] [diff] [review] improved patch which filters out non-user generated mouse moves generated by window creation sr=kin@netscape.com Are there any perf issues introduced by the code that crawls up and down the widget/window hierarchy when trying to synchronously paint on pages with a lot of animation (animated gifs, etc) that are constantly invalidating the page, while we type or move the mouse around?

Using http://www.sohu.com/ which has text fields and a bunch of animated gifs: without patch ------------- no mouse or keyboard input (CPU utilization 7-12%) typing (CPU varies from 15%-22%) moving mouse (CPU varies from 20%-35%) with patch ---------- no mouse or keyboard input CPU utilization 7-12% typing (CPU varies from 14%-23%) moving mouse (CPU varies from 20%-33%) I don't see any additional CPU utilization as the result of the extra code to force the synchronous paint of the invalidated windows.

Fix checked into the trunk.

Something seems to be wrong. On http://www.dhtmlcentral.com when you drag a "window" you now see it be dragged, but there is a big white block underneath it only when you drag it. This did not happend before. Also on bug 154568 (see bug 154568, comment 26), the url doesnt even diplay the page anymore. Build 20020920, Windows 98.

with moz 2002-09-20-08 I see what looks like a 2nd area starting just at the bottom of the dragged box that is being cleared occasionally.

It looks like there is a clipping problem when updating the windows which scroll. Dragging "Forums" around doesn't display the problem. Scrolling one of the other windows to the bottom and dragging it around produces an opaque white area when dragging which is above the window. This may be an existing problem that was not visible before because we never painted the window until the mouse stopped moving. I'm not sure why painting just before each mouse move event should be any different then painting in response to the generated WM_PAINT event that occurs after the mouse has stopped moving. I'll investigate further

There is some seriously ugly repainting going on since this fix was applied. Case-in-point, look at: http://www.visi.com/~hoju/barracuda/barracuda.html Use the rado buttons at the top to switch the stylesheets. Before, the switch was smooth. The only repainting that happened was when the stylesheet actually switched. Now you see the transition in between painting with different color boxes and stuff. It all works in the end, but it used to look more smooth in the transition. Tested using build 2002092008 on Win2k (sp2sr1) Jake

http://www.visi.com/~hoju/barracuda/barracuda.html. WFM. using 2002092008 build on WinXP, 750Mhz AMD. Clicking on the radio buttons "snaps" to the next page without any in-between painting. hoju@visi.com: Are you sure it was this fix that caused the repaint problem your seeing? Does a build from 9/18 have the same painting issue for you?

Note: the problem on http://www.dhtmlcentral.com goes away if I process pending PL_Events before the synchronous paint. This is necessary to prevent reflows from being starved.

>hoju@visi.com: Are you sure it was this fix that caused the repaint problem your >seeing? Does a build from 9/18 have the same painting issue for you? Nope, the 9/18 build works the way it used to. There are no intermediate color changes. It just switches when it has everything processed and ready to change. It seems to me that it probably starts repainting faster with the newer builds, but the result is that more of the ugly transition is seen. So, given that the 9/18 build is a smooth changes for me, does that mean that the fix for this bug is the culprit. BTW, I'm using a PII 266 with 128Meg RAM. Jake

Jake: Yes. this checkin probably caused the regression your seeing. The problem is that its now painting before all of the reflowing in some cases. The fix I mention in comment 21 should fix your problem as well as the white areas when dragging on dhtmlcentral. I'm re-opening bug.

http://www.dhtmlcentral.com works fine with attachment id=100652. http://www.visi.com/~hoju/barracuda/barracuda.html also works fine. But it was Working for me before I applied the patch as well.

I just tried large number of demos on http://www.dhtmlcentral.com with the lastest patch installed and I don't see any problems. All the demos that allow you drag a element around are working. The element continuously updates as the mouse pointer is moved.

Comment on attachment 100652 [details] [diff] [review] Forces pending PL_Events to be processed after each mouse and keyboard event. Force pending event dispatch *after* the event is processed instead of before r=rods

Comment on attachment 100652 [details] [diff] [review] Forces pending PL_Events to be processed after each mouse and keyboard event. Force pending event dispatch *after* the event is processed instead of before ==== I'm assuming that in mozilla and in an embedded context, there will only ever be one nsToolkit instance, so it's ok to null this global out in the destructor? + // Remove reference to cached event queue + gEventQueueService = nsnull; + ==== Fix indentation for |userMovedMouse|: if ((gLastMouseMovePoint.x != mp.x) || (gLastMouseMovePoint.y != mp.y)) { - CheckForStarvedPaints(); + userMovedMouse = PR_TRUE; }

Comment on attachment 100652 [details] [diff] [review] Forces pending PL_Events to be processed after each mouse and keyboard event. Force pending event dispatch *after* the event is processed instead of before sr=kin@netscape.com

Checked in attachment 100652 [details] [diff] [review]. Marking fixed. rakeshmishra: This bug can not be verified until bug 171228 is fixed.

Wooh !!! This patch really rocks and improve DHTML performances (dragging) a lot.

verified on latest trunk build 2002122608