275194 - problem using javascript on text-input elements of forms from a different servers even when using CAPS

Status: RESOLVED DUPLICATE of bug 219848

(Core :: Security: CAPS, defect)

Description

[kevin]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041117 Firefox/1.0

I created a policy which allows a lokal html file to change the form values of a
form in a different frame containing a page from a different server, as
described in:
http://www.mozilla.org/projects/security/components/ConfigPolicy.html

This works fine for checkboxes/radiobuttons. Concerning text input elements
there are two problems:
- setting the value using ...myInputElement.value = "anything, even numbers and
empty strings"; does not replace the value, but concatenates the current string
with the new value (which is set by a value= attribute in the input-tag).
- doing a ...myForm.submit(); or a ...mySubmitButton.click(); creates a request
to the server, ignoring the values of text input fields completely.

This makes JS for some projects unusable.

Comment 1

[kevin]

Attachment: File containing javascript and the policy.

Comment 2

[kevin]

Attachment: frameset wrapping the first attachement

Comment 3

[kevin]

Is someone able to reproduce this using the example files? If not, I would be
interested in the used version.
Where in the source could the bug be located? I would like to have a look on
this, but don't know where to start. I'm even not sure if it is in caps...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk since June....

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

Comment 5

[kevin]

Sorry, I need to reopen the bug. I updated/cleaned/rebuilt my cvs version and it
is not working. 
On a first glance, I spotted some of the code of the proposed patch of #219848.
So it is probably something different.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Kevin, did you update to a trunk build (not 1.7.5)?  And then tried asking for
UniversalBrowserRead priveleges?  And it still failed?

Comment 7

[kevin]

used version:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050119 Firefox/1.0+

using this, I just get the property denied error message (after allowing the
privileges):
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead
UniversalBrowserWrite");

Using the capabilities like described in the example I don't get an error
message, but ff still has the wrong behaviour.

Comment 8

[Boris Zbarsky [:bzbarsky]]

kevin, I just downloaded your testcase and tried it.  It works if I put the
enablePrivilege call where it should be -- in the searchGoogle function, right
before the action that requires the expanded privileges.

The result of enablePrivilege has function scope, so it needs to be called any
time you'll do something that needs the privilege, not just once up front per
script....

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