26226 - Cannot display correctly www.oracle.com

Status: VERIFIED DUPLICATE of bug 27775

(Core :: JavaScript Engine, defect, P3)

Description

[Mihail Daskalov]

When trying to load www.oracle.com for a second I see part of page trying to
load and the it's all blank.

In the console the following messages appear:

FindShortcut: in='http://www.oracle.com/'  out='null'
JavaScript Error: TypeError: redeclaration of const content
URL: http://www.oracle.com/

Document http://www.oracle.com/ loaded successfully
Document: Done (0.501 secs)

(and many ...)
nsLayoutHistoryState::GetState, ERROR getting History state for the key
nsLayoutHistoryState::GetState, ERROR getting History state for the key
nsLayoutHistoryState::GetState, ERROR getting History state for the key

This happens always with M13 build with M12 it was working.
The page Loads correctly with Netscape 4.7

Comment 1

[Mike McCabe]

Could this be a reflection of Brendan's recent constipation work?

view-source:http://www.oracle.com/jscripts/frame.js gives js that seems to be
used by the toplevel page.

This script has 'var content;' midway thru, and also has '<FRAME SRC=...
name="content" ...>' somewhat later.  Could the frame name be interfering with
the var?

Wish we had Brendan around.  Shaver, did you follow any of Brendan's const
changes?

Roger, passing to you...

Comment 2

[Brendan Eich [:brendan]]

const uses JSPROP_READONLY and only that flag to distinguish const from var, so 
any properties defined by native code, such as frames in frameset-loading window 
scopes, must be defined without preempting user-defined variables.  This bug is 
a problem even without const: it means our C++ code is preempting a name that a 
user's script declares as a read-write variable.

Either predefine frames as read/write, or define them lazily.  It appears to me 
that dom/src/base/nsGlobalWindow.cpp nsGlobalWindowImpl::Resolve does the latter 
and without any JSPROP_READONLY attribute.  So the problem must lie elsewhere, 
perhaps in code that eagerly defines frame-namad properties?

Cc'ing vidur.

/be

Comment 3

[jmmrb]

With Mozilla Build ID: 2000020608 it simply doesn't show any page.

Comment 4

[rogerl (gone)]

The conflict is with the name 'content' which has been defined as a property of 
the Window class already. i.e. the simple script 

var content = 3;

will fail. Is this a bug? Isn't it right that read-only properties be protected?

Comment 5

[Brendan Eich [:brendan]]

It's not right to break backward compatibility with web pages that predate 
Mozilla 5.0.  Therefore, if Mozilla 5.0 wants to add a readonly property of the 
window object named content, it must avoid predefining it.  It should define it 
lazily, via nsGlobalWindowImpl::Resolve.  That throws this bug into DOM-land, 
where other variations on it should already exist (e.g., screen is predefined as 
readonly, which breaks pre-4.x content; 4.x used a lazy resolve hook, so should 
Mozilla 5.0).

/be

/be

Comment 6

[Cyril Bortolato]

Duplicate of bug #27775

Comment 7

[Dan M]

This is my problem, not a general JS problem. Thanks to borto for pointing this 
out. What's happened is, chrome windows have a few properties that classic 
content windows have not had. There was bound to be a naming conflict sooner or 
later. This should be fixed by special-casing chrome windows.


*** This bug has been marked as a duplicate of 27775 ***

Comment 8

[Robert Ginda]

Vidur and I spoke about this problem yesterday.  damn, you're not alone, I 
introduced a window.sidebar property for bug 20721, and window.controllers was
added some time ago.  Our idea was to add a keyword to idlc, so that you could
declare selected window properties as read/write.

Comment 9

[Brendan Eich [:brendan]]

Making predefined properties read-write isn't completely compatible, because 
there are pages (see bug 21618) that do things like this:

<script language=funky>foo=1;</script>
<script>var foo; if (!foo) ...</script>

The var foo; does not change the predefined (object-type) value of foo, if there 
is a predefined foo ('content', 'sidebar', etc.), and if language=funky is not 
supported.  So the if (!foo) fails, as does the ... bootstrapping code.

I still think (for 'screen' as well, which was added in 4.x but done lazily in 
MozillaClassic, so as not to preempt user variables from 2.x and 3.x era web 
pages; Mozilla does 'screen' eagerly now, which is bad) that the right general 
solution is to define certain properties lazily, via generated JSClass resolve 
hooks.  So DOM idlc might do better to offer a 'lazy' keyword for attributes.

/be

Comment 10

[Matt Perry]

Verified duplicate.