Bug 166099 - [regression] hixie benchmark script doesn't work anymore
Summary: [regression] hixie benchmark script doesn't work anymore
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Unclassified
Component: kjs (show other bugs)
Version: 4.0
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-08 23:14 UTC by Germain Garand
Modified: 2008-08-23 22:49 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Germain Garand 2008-07-08 23:14:17 UTC
Version:           4.0 (using Devel)
Installed from:    Compiled sources

Hixie's 'marching skeleton' benchmark scripts (e.g. http://www.hixie.ch/tests/adhoc/perf/video/001.html) don't seem to work anymore, though IIRC they worked in 4.0.

the script gets stuck at "Loading, please stand by... (this may take some time)"
and never reaches a running state.

Ennoying, because it prevents us to kick some asses in kestrel's performance benchmark :-/
Comment 1 Maksim Orlovich 2008-07-08 23:27:13 UTC
Seems like it's relying on 'var frames = ..' to shadow the FrameArray property.
However, it's ReadOnly. (sigh). I could never figure out IceWeasel behavior on this stuff cleanly (it seems to be different for every property!), but in this case, I think removing ReadOnly from the frames property in kjs_window.cpp ought to be OK. 


Comment 2 Germain Garand 2008-07-11 02:55:09 UTC
do I understand you correctly that you mean it's using the 'frames' variable name, and expects that to hide not-fully-qualified calls to the 'window.frames' property, but that it should not work because the latter is read-only?

mmh right, I see renaming this 'frames' variable to 'xframes' does make the script work.

it does sounds strange to the layman that I am though that setting a property read-only, would make it immune to being hidden by a variable name in any case O_o
Comment 3 Maksim Orlovich 2008-07-11 03:46:28 UTC
There isn't really any hiding going on at the conceptual level --- the global variables and magic things like "document" are just properties of the same object, the global object, aka the Window object. So if the property is readonly, writing to it should not make a difference. Well, under the normal ES model, anyway. (And ignoring 'delete'. <sigh>)

Iceweasel makes things messier since it views some of the readonly things 
as consts (a language extension of theirs), so saying "var document" actually issues an error, while document = 42 is ignored. Further, some readonly-type things are implemented like dynamic properties (think location) w/o setter portion, so saying closed = 5 throws an exception (while saying "var closed" doesn't --- the exact opposite of the behavior for "document")

As a compatibility hack, KJS used to permit ReadOnly to be ignored if one were to declare a variable with "var"; this made some of the core variable code rather... interesting. I think the proper thing to do is go through and remove ReadOnly from a bunch of things. frames would be one (actually, that's supposed to return the window itself, not a separate collection....), others seem to be "external", 
"event" (gotta be careful with that one...), innerHeight, innerWidth, length, navigator, opener... At about this point I realized that I was testing IW2 and not 3, and there are actually changes -- navigator is const in 3. Anyway, continuing on outerHeight/Width, parent, personalbar, screenX/Y, scrollbars, scrollX, scrollY, self, top, sidebar, Image, Option, XMLHttpRequest, XMLSerializer and DOMParser all look like read-write properties to me.
Though, some of this may be complicated by the odd way in which they do XSS...

IceWeasel also doesn't have Audio, clientInformation and offscreenBuffering.