43327 - history[0] is undefined when it shouldn't be

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[cathy zhang]

load 6/20 build on NT
go to the page in URL above, the code is
----------------------------------------------
<script>
  netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
  document.write("<h1>"+history[0]+"</h1>");
</script>

I assume that the page served from SSL server is signed, but javascript console 
says "uncaught exception: enableprivilege not granted". it is working fine with 
NS4.7

Comment 1

[Mitchell Stoltz (not reading bugmail)]

Signing a page and serving it from an SSL server are two different things. In 
4.x, scripts could derive a signature from the server SSL certificate, not so in 
Seamonkey. I considered this feature, but there wasn't time and I'm told some 
people don't want it to be there. To use enablePrivilege, you must either sign 
your scripts with signtool (I'll show you how to do this, Cathy), or enable 
codebase principal support. SSL doesn't work for this purpose. Marking WONTFIX.

Comment 2

[cathy zhang]

Mitch, I turned on signed_applets_codebase_prinple_support in all.js to be true, 
but it does not help, the variable is undefined, there is no error in 
javascript console though

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Sorry, signed scripts and codebase principals have both regressed in the few 
weeks since I last dealt with them. Cathy, I'll let you know when they're fixed 
and we can work on testcases.

Comment 4

[cathy zhang]

change the bug summary.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Adding nsbeta2...I will fix this within a few days providing I can get jar:http 
URLs working. This is an important piece of security functionality which is 
broken right now.

Comment 6

[Jay Patel [:jay]]

Putting on [NEED INFO] radar. PDT needs to know impact to user and risk of fix 
to make a call on this bug. Will this break netcenter activation?  

Comment 7

[Mitchell Stoltz (not reading bugmail)]

The problem here is not with the caps code, I think. Enabling other privileges
using codebase principals works fine. For example, try
http://warp/u/mstoltz/tests/pref.html , which contains the following code:
---------------------------
<script>
netscape.security.PrivilegeManager.enablePrivilege("UniversalPreferencesRead");
document.write("<h1>"+navigator.preference("browser.history.last_page_visited")+"</h1>"); 
</script>
---------------------------
I believe the problem is specifically with the history object, as the security
check on access to history returns success. Reassigning to DOM and changing
summary. Try the URL in the URL field above for a demonstration of the history
problem.

Clearing nsbeta2 because I don't see this as a beta stopper. It's not a security
problem.

Comment 8

[racham]

Johnny,

Is it anyway linked to bug 21373 ?

Currently, in the activation process we try to execute history.back() which may 
be trying to load history[0] (bugscape bug 1231). Nothing happens at that point. 
In bug 21373, Ihave explained the problem further. If you see any relation, 
please do take a look as  it is one of the commonly used piece of code in 
activation scripts.

Comment 9

[Johnny Stenback (:jst)]

Radha, looks like this could be related to the session history history bugs you're
working on, if not give this back to me.

Comment 10

[Radha on family leave (not reading bugmail)]

history.go(0) will now work. I'm not sure if that will give history[0]. Can 
someone verify this. I can't go to the url provided.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Tested it on today's Linux build, history[0] is still undefined.

Comment 12

[Radha on family leave (not reading bugmail)]

jst, nisheeth,
I don't know how the work we did for 18321 helps here. Can you throw some light 
here. Thanks,

Comment 13

[Johnny Stenback (:jst)]

Ok, I see the problem with history[0], the mozilla history object is not defined
to be accessible as an array and that's why history[0] is always undefined. I
don't know how frequently the history object is accessed as an array but it
seems like something we should fix for beta3 for backwards compatibility (it's
defined in the javascript docs that history is accessible as an array).

I'm grabbing this bug off your list Radha, I hope you don't mind :)

Eric, please advice on the severity of this, it's pretty simple to add, + or -?

Comment 14

[ekrock's old account (dead)]

DOM0 backward compatibility. Recommend nsbeta3+.

Comment 15

[Nisheeth Ranjan]

Marking nsbeta3+

Comment 16

[Johnny Stenback (:jst)]

Attachment: Proposed fix.

Comment 17

[Johnny Stenback (:jst)]

Turns out we also need to make a minor modification to the IDLC compiler to make
it generate security checks around array access calls before this can be checked
in...

Comment 18

[Johnny Stenback (:jst)]

Attachment: Proposed fix with the added security check

Comment 19

[Johnny Stenback (:jst)]

Ok, the last patch should fix this, review and checkin pending...

Comment 20

[Johnny Stenback (:jst)]

Attachment: all.js diff to turn on the correct security checking for history[0]

Comment 21

[Johnny Stenback (:jst)]

Fix checked in, marking FIXED.

Comment 22

[Prashant Desale]

Verified with 2000-09-13-09.