A way to force a repaint or refresh via js

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
--
enhancement
18 years ago
a year ago

People

(Reporter: andreww, Unassigned)

Tracking

({dom0})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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

Updated

18 years ago
Assignee: mccabe → vidur
Severity: normal → enhancement
Component: Javascript Engine → DOM Level 0

Comment 1

18 years ago
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
(Reporter)

Comment 2

18 years ago
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

18 years ago
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → LATER

Comment 4

18 years ago
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

17 years ago
reopening and marking Future...
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: --- → Future

Comment 6

17 years ago
see also bug 40093, which wants a way to do this through the debug menu.

Comment 7

17 years ago
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.
Keywords: dom0

Comment 8

16 years ago
Using self.status= (something) after the change has taken place will doe a repaint.

Comment 9

14 years ago
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

Updated

12 years ago
Assignee: vidur → general
Status: REOPENED → NEW
OS: Windows 95 → All
QA Contact: rginda → ian
Assignee: general → nobody
QA Contact: ian → general
Duplicate of this bug: 415479
Priority: P3 → --
Summary: [feature] A way to force a repaint or refresh via js → A way to force a repaint or refresh via js
Target Milestone: Future → ---
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
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

10 years ago
(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

10 years ago
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.
You need to log in before you can comment on or make changes to this bug.