Last Comment Bug 21081 - A way to force a repaint or refresh via js
: A way to force a repaint or refresh via js
Status: NEW
: dom0
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- enhancement with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 415479 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 1999-12-07 14:59 PST by andreww
Modified: 2016-01-27 02:49 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Demonstration of the problem and current workaround for IE (1.21 KB, text/html)
2008-02-04 07:13 PST, VK
no flags Details

Description andreww 1999-12-07 14:59:50 PST
There are a number of cases where it would be great if I as a js programmer
could force the page to "refresh" or repaint - in order to get some pages which
do dom changes to update properly
Comment 1 Mike McCabe 1999-12-07 15:13:59 PST
Reassigning to DOM component and marking as enhancement.  Thanks for the
suggestion -

Andrew - the JavaScript Engine component is for bugs concerning the language
itself (e.g. how a 'for' loop works) and for core language APIs like String,
Array, Date and Object.

Mike
Comment 2 andreww 1999-12-07 15:20:59 PST
Thanks for clarification - I wasnt sure which component would own something like
this.  Note this would not be "reload()" because reload would blow away all the
dom changes and reset the page back to it's initial state.
It would be akin to IE's "refresh".
Comment 3 vidur (gone) 1999-12-08 15:26:59 PST
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
Comment 4 vidur (gone) 1999-12-09 09:36:59 PST
If updates aren't happening when they should as a result of DOM changes, the
specific cases should be filed as bugs. The DOM standard doesn't support
anything like this and I don't want to produce something proprietary. LATERing
this one.
Comment 5 Blake Ross 2000-09-29 14:15:55 PDT
reopening and marking Future...
Comment 6 Jesse Ruderman 2000-10-12 23:29:30 PDT
see also bug 40093, which wants a way to do this through the debug menu.
Comment 7 Tim Powell 2000-12-15 23:55:29 PST
I'm trying to understand this and I gather that history.go(0) does not already 
do this. With history.go(0) it acts like IE's refresh in that the page 
reloads, but form field values are not wiped out except for hidden fields as 
described in bug 55988. Is what you want something that maintains JavaScript 
variable values and prevents the DOM from being wiped out while forcing a 
repaint? For what purpose? I'd think DOM changes would update correctly without 
needing an explicit refresh/repaint.

I often use history.go(0) to work around NS4's DHTML and window resize problems. 
 I haven't seen any need for this in Mozilla.
Comment 8 Brian Nickel 2002-03-23 12:55:00 PST
Using self.status= (something) after the change has taken place will doe a repaint.
Comment 9 David Martinez 2003-12-17 11:17:49 PST
I also need this for Xul. I have a JS/XUL application (on its own XUL Window) 
with some processing that takes a long time. I want to be able to update a 
label with the current status, but I can't get it to repaint, even when using 
the nsIBaseWindow's repaint method like this:

// Do something like this inside a for that does a bunch of stuff...
document.getElementById("mylabel").setAttribute("value", "My new value");
repaintXulWindow(force);


function repaintXulWindow(force) {
  var baseWindow = getBaseWindowFromWindow(window);
  baseWindow.repaint(force);
}


function getBaseWindowFromWindow (win)
{
    var rv;
    try
    {
        var requestor = win.QueryInterface
(Components.interfaces.nsIInterfaceRequestor);
        var nav = requestor.getInterface
(Components.interfaces.nsIWebNavigation);
        var dsti = nav.QueryInterface
(Components.interfaces.nsIDocShellTreeItem);
        var owner = dsti.treeOwner;
        requestor = owner.QueryInterface
(Components.interfaces.nsIInterfaceRequestor);
        rv = requestor.getInterface(Components.interfaces.nsIBaseWindow);
    }
    catch (ex)
    {
        rv = null;
        /* ignore no-interface exception */
    }

    return rv;
}


on this context, I don't really have a self.status
Comment 10 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-02-03 16:38:55 PST
*** Bug 415479 has been marked as a duplicate of this bug. ***
Comment 11 Brendan Eich [:brendan] 2008-02-03 17:28:32 PST
With a proper separating of painting from script execution, we wouldn't need this. Unless the script is so long-running, in which case we have UI starvation issues anyway. Cc'ing roc and vlad for comments or disposal based on compositor futures.

/be
Comment 12 Vladimir Vukicevic [:vlad] [:vladv] 2008-02-03 23:19:43 PST
I don't think this really has anything to do with separating painting from script execution -- the script is long-running, and the event queue is being starved.  Oddly enough, we actually do have a way to force a repaint, that I added as a way to benchmark painting; but it doesn't force a reflow, so DOM changes won't really get picked up.

In any case, I think this is a WONTFIX -- the right solution here really ought to be worker threads for the long-running script processing.
Comment 13 VK 2008-02-04 05:58:36 PST
(In reply to comment #11)
> With a proper separating of painting from script execution, we wouldn't need
> this.

I would insist on "regular separating" rather than "proper separating". A forced workaround is no way a "proper action" but merely a "workable solution".
Just like "var $this = this;" to fight with the incontinence of [this] in Javascript is not a "proper programming" but a "standard workaround" ;-)
For all problems is Javascript such or such solution is found long ago: this is why we are talking about an enhancement, not some burning bug.

> Unless the script is so long-running, in which case we have UI starvation
> issues anyway.

What "long running script" as such? It maybe just 2-5 secs delay before XHR/parsing operations, it is still necessary to show to user that something is going on and did not hang up. Currently it is often have to be done with window.setTimeout and may quickly become a royal headache because of the necessity to preserve [this] context so parasite closures just multiplying like cockroaches. :-)  :-(
 
(In reply to comment #12)
> In any case, I think this is a WONTFIX -- the right solution here really ought
> to be worker threads for the long-running script processing.

That would be a killing way to do things : by trying to imitate some pseudo-threading in a single-threaded environment.

All what is really needed here is a "virtual window.alert with autoclick" over say newly added window.repaint() method. So just like in
 // DOM scripting
 window.alert('foobar'); // gc updated
 // keep on scripting
so pretty much like the known workaround for IE over showModalDialog, see 
http://groups.google.com/group/microsoft.public.scripting.jscript/msg/8ebbc51dfbfd6a35


Comment 14 VK 2008-02-04 07:13:54 PST
Created attachment 301274 [details]
Demonstration of the problem and current workaround for IE

To make clearer what I'm talking about, I have made a demo HTML page. It shows the current graphics context default and possible workaround for IE. So we don't really need any threading here: just a programmatic emulation of what user is allowed to do left and right any way.

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