Bug 36914

Summary: select elements not updated incrementaly when doing lots of Javascript
Product: [Applications] konqueror Reporter: djoham
Component: khtml ecmaAssignee: Konqueror Developers <konq-bugs>
Status: RESOLVED WORKSFORME    
Severity: wishlist CC: finex
Priority: NOR Keywords: needs_verification
Version: unspecified   
Target Milestone: ---   
Platform: Mandrake RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Testcase

Description djoham 2002-01-06 23:12:13 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kjs
Version:           KDE 2.2.2 
Severity:          wishlist
Installed from:    Mandrake RPMs
Compiler:          Not Specified
OS:                Linux
OS/Compiler notes: Not Specified


Sorry for the crummy short description :(

Here's a better one...

I'm creating an HTML test suite for a project of mine. The test suite runs a ton of javascript that includes updating a <select> element with the results of the tests. 

Konqueror runs the test suite just fine with one annoying visual glitch. 

While the test suite is running there is no visual feedback to the user that anything is happening. Even though items are being added to the select box nothing shows up until the whole test suite is completed. 

In comparison Opera redraws at least the select box after every update to show that something is happening.

It would be nice if Konqueror would update the output of select boxes when the contents are changed. This wil allow users to know that something is going on.

Here's a test case that demonstrates what is going on. It adds 1500 items to a select box. Notice that nothing happens in Konqueror until the entire JavaScript function is complete.

Thanks in advance..

David


<html>
<body>
<form>
<select id="slct" size="2" style="width: 200px; height: 200px"></select><br>
<input type="button" onclick="go()" value="press me">
</form>
</body>
</html>

<script language="JavaScript">
function go() {
for (intLoop=0; intLoop < 1500; intLoop++) {
  var x = new Option(intLoop);
  if (navigator.appName.indexOf("Opera") > -1) {
    document.getElementById("slct")[document.getElementById("slct").length] = x;
  }
  else {
    document.getElementById("slct").add(xnull);
  }
}
}
</script>

(Submitted via bugs.kde.org)
Comment 1 Michael Jahn 2004-07-24 00:58:12 UTC
Created attachment 6813 [details]
Testcase
Comment 2 Maksim Orlovich 2006-01-25 18:41:28 UTC
I am not sure we can/want to do repaints in the middle of scripts --- it's generally slow. But on the plus size, this should be reasonably fast in 3.5.1..
Comment 3 Marijn Schouten 2006-04-18 17:22:14 UTC
the testcase runs instantly for me, possibly because all items are added in one go. Is the desired behaviour that every item should cause a repaint? and would I be able to see the difference? I get the same behaviour in firefox.
Comment 4 djoham 2006-04-20 05:45:58 UTC
On my new computer, the test case is almost instant as well. However, you can still see the problem on the page that inspired this bug report (http://xmljs.sourceforge.net/website/testSuites-w3cdom.html). Launch the level 2 test suite and then press the "Launch Tests" link. Depending on speed, your computer will spin for a bit and then refresh the page. The problem is that during the javascript operation, it doesn't actually appear that anything is going on since the page/option element doesn't refresh.

Opera will actually do a repaint after every operation so the user can see the page being updated. It's a nicer experience...
Comment 5 FiNeX 2008-11-20 00:14:14 UTC
Konqueror in KDE4 is perfect on all test and on testcase too. Lightspeedy! Please reopen if you still have this issue with Konqueror 4. (Konqueror 3 won't be fixed).