21081 - A way to force a repaint or refresh via js

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, enhancement, P5)

Description

[andreww]

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]

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]

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)]

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

Comment 4

[vidur (gone)]

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]

reopening and marking Future...

Comment 6

[Jesse Ruderman]

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

Comment 7

[Tim Powell]

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]

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

Comment 9

[David Martinez]

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 11

[Brendan Eich [:brendan]]

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] (needinfo me, slow to respond)]

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]

(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]

Attachment: 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.

Comment 15

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.

Comment 16

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Attachment from comment 14 worked for me on Fx 125. Also, since the bug was reported, there are a lot of new features, such as requestAnimationFrame(), which support repaint. Please file a new bug if you see more support for your new use cases.

Comment 17

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/5912368864f0
[fenix] Update Android Components version to 93.0.20210830143255. (https://github.com/mozilla-mobile/fenix/pull/21081)