Form Manager loses data ("Access to restricted URI denied")




Form Manager
16 years ago
10 years ago


(Reporter: Greg K., Assigned: sicking)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020718
BuildID:    2002071808

The Form Manager fails to store entered data. After attempting to re-enter the
lost data, clicking the "OK" button on the Form Manager window crashes Mozilla.

Reproducible: Always
Steps to Reproduce:
1. Summon the Form Manager window
2. Enter your first and last name
3. Click OK; notice nothing happens
4. Click OK again; notice window dismisses
5. Summon Form Manager window again; notice previously entered data is missing
6. Re-enter first and last name
7. Click OK

Actual Results:  Mozilla loses the entered data and crashes.

Expected Results:  Mozilla should have stored the entered data from step 2 the
first time, and should not have crashed on subsequent re-entry attempt.

Crash report forthcoming.

Comment 1

16 years ago
Created attachment 91841 [details]
(stack for crash @nsXULElement::GetOwnerDocument - Bug #158202)


16 years ago
Keywords: crash, dataloss

Comment 2

16 years ago
Note: I duplicated this using a new Mozilla user profile.

Comment 3

16 years ago
okay, this works just fine for me, using mac OS X branch build 2002-07-18-05,
reporter, when you say summon the form manager window, do you mean From the
Tools Drop Down menu, select Form Manager ->Edit Form info????

Comment 4

16 years ago
Yes; Tools/Form Manager/Edit Form Info.

Comment 5

16 years ago
I am seeing this on trunk builds today on all platforms.

-goto Tools | Form Manager | Edit Form Info
-enter a first and last name
-click "okay"
-go back to "Edit Form Info"
the data you just entered is gone.
-attempt reenter the names then click okay....crash
OS: MacOS X → All
Hardware: Macintosh → All

Comment 6

16 years ago
odd thing is...if you do a Edit | Fill in form,  the data is there and can be
filled into a form...otherwise this would be a blocker.

Comment 7

16 years ago
Aha, it's trunk only, I see this as well with Trunk build 2002071808
OS: All → MacOS X
Hardware: All → Macintosh

Comment 8

16 years ago
I see something similar with today's trunk build as well.  I enter the data, 
close the dialog, return to the dialog, and the data is not there.

But I am not observing a crash.  I reentered the data a second time, clicked ok, 
and the dialog closed the second time.  Of course when I went back to the dialog 
for the third time, it was still blank.

Also I did not have to press OK twice to get the dialog to close (step 3 in the 
description) -- it closed on the first click.

This is on winnt.

Comment 9

16 years ago
this is a blocker on OSX.  the field data is not remembered at all.  

-after filling in names in edit form info go to Edit | Fill In Form
you can't because the data isn't there to make the selection available. (the
selection is greyed out)
Severity: critical → blocker
Keywords: smoketest

Comment 10

16 years ago
Mitch, did you change something in the security module on the trunk in the last 
few days that could account for this.  The javascript console is giving the 
following messages:

Security Error: Content at 
   may not load data from

Error: uncaught exception: [Exception... "Access to restricted URI denied"  
   code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)"
   location: "chrome://communicator/content/wallet/WalletViewer.js Line: 243"]

To reproduce I did the following:
1. Create fresh profile
2. open form-manager dialog with TOOLS -> FORM-MANAGER -> EDIT-FORM-INFO
3. type some characters into any field
4. click OK and form-manager dialog closes
5. again open form-manager dialog with TOOLS -> FORM-MANAGER -> EDIT-FORM-INFO

Error messages appear after step 5
OS: MacOS X → All
Hardware: Macintosh → All

Comment 11

16 years ago
Error is occuring on the following line in walletviewer.js

              for (var j = 0; j<strings.length-1; j++) {
                var menuItem = ...
                 if (menuItem) {
                  menuItem.setAttribute("label", strings[j]);
                  menuItem.setAttribute("len", strings[j].length);
 >>>>>>           menuPopup.insertBefore(menuItem, menuPopup.lastChild);

This code executes when WalletName.xul loads.  The sequence is as follows:

   WalletName.xul from locale/US/communicator-region/wallet/:
   walletviewer.js from content/communicator/wallet/:
      function initPanel() {
         menuPopup.insertBefore(menuItem, menuPopup.lastChild);

Comment 12

16 years ago
the stack trace is bug 158202 - there's a patch w/ r+sr+a waiting for a
sheriff/buildmonkey to approve in it. sicking is responisble for messing with
security recently :)

Comment 13

16 years ago
As per Comment #12, should this be marked as a dup of Bug #158202?

Comment 14

16 years ago
No. If that covers the crash, this bug should remain to cover the dataloss.

Comment 15

16 years ago
That's true, however if it fixes both the crash and the dataloss, then it should
be a dup. I hope it fixes both problems, but maybe I'm just being an optimist ;-)
still have data loss in form manager with respins:

windows 2002-07-19-11-trunk
linux 2002-07-19-11-trunk
max osx 2002-07-19-11-trunk

However, the builds are no longer crashing when trying to reenter data in the
form manager, just not remembering what was input.

crashing was not what made this a blocker, ugly, but the data loss is the
blocker cause.


16 years ago
Keywords: crash
Summary: Form Manager loses data, then crashes Mozilla → Form Manager loses data ("Access to restricted URI denied")


16 years ago
Attachment #91841 - Attachment description: Crash report generated by FizzillaCFM/2002071808 showing crash in nsXULElement::GetOwnerDocument → (stack for crash @nsXULElement::GetOwnerDocument - Bug #158202)
Attachment #91841 - Attachment is obsolete: true

Comment 17

16 years ago
Let me repeat.  The dataloss is being caused by the security violation described 
in comment 10.  Here's hoping that mitch knows what changed in this area 

I'm still investigating.


16 years ago
Depends on: 156452
This may have been caused by sicking's security changes, bug 156452.
We recommend this be downgraded from blocker. jst is working on the problem and
opening the tree will not make the fix any more difficult.

Comment 20

16 years ago
Downgrading severity per recommendation.
Severity: blocker → critical
Keywords: smoketest


16 years ago
Depends on: 158202
Created attachment 92042 [details] [diff] [review]
patch to fix

Allows "chrome-nodes" to do anything.
ccing for reviews


16 years ago
Keywords: review
Comment on attachment 92042 [details] [diff] [review]
patch to fix

r=bzbarsky.  On trunk we should consider pushing that logic down into the
security manager.....
Attachment #92042 - Flags: review+
Comment on attachment 92042 [details] [diff] [review]
patch to fix

Attachment #92042 - Flags: superreview+

Comment 25

16 years ago
Comment on attachment 92042 [details] [diff] [review]
patch to fix

a=asa (on behalf of drivers) for checkin to 1.1
Attachment #92042 - Flags: approval+

Comment 26

16 years ago
Bug #158432 may be related to or a duplicate of this bug.
err.. should have taken this before
Assignee: morse → sicking
checked in
Last Resolved: 16 years ago
Keywords: review
Resolution: --- → FIXED

Comment 29

16 years ago
tpreston - pls verify this on the trunk and to be safe, on the branch also,
since the fix which caused this regression is also planned for the branch.
this works fine with trunk builds from 0722-0723 and on branch builds from 0722

marking verified

Comment 31

16 years ago
thanks tracy


10 years ago
Component: Form Manager → Form Manager
Flags: approval+
Product: Core → Toolkit
QA Contact: tpreston → form.manager
You need to log in before you can comment on or make changes to this bug.