Closed
Bug 158167
Opened 22 years ago
Closed 22 years ago
Form Manager loses data ("Access to restricted URI denied")
Categories
(Toolkit :: Form Manager, defect)
Toolkit
Form Manager
Tracking
()
VERIFIED
FIXED
People
(Reporter: bugmail, Assigned: sicking)
References
Details
(Keywords: dataloss)
Attachments
(1 file, 1 obsolete file)
864 bytes,
patch
|
bzbarsky
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
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 3•22 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 5•22 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•22 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•22 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•22 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•22 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•22 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 chrome://communicator-region/locale/wallet/WalletName.xul may not load data from chrome://communicator/content/wallet/WalletViewer.xul. 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•22 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/: onload="parent.initPanel();" walletviewer.js from content/communicator/wallet/: function initPanel() { hWalletViewer.onpageload(tag) } ... onpageload: ... menuPopup.insertBefore(menuItem, menuPopup.lastChild);
Comment 12•22 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•22 years ago
|
||
As per Comment #12, should this be marked as a dup of Bug #158202?
Reporter | ||
Comment 14•22 years ago
|
||
No. If that covers the crash, this bug should remain to cover the dataloss.
Comment 15•22 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 ;-)
Comment 16•22 years ago
|
||
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.
Keywords: crash
Summary: Form Manager loses data, then crashes Mozilla → Form Manager loses data ("Access to restricted URI denied")
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•22 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 recently. I'm still investigating.
Comment 18•22 years ago
|
||
This may have been caused by sicking's security changes, bug 156452.
Comment 19•22 years ago
|
||
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•22 years ago
|
||
Downgrading severity per recommendation.
Severity: blocker → critical
Keywords: smoketest
Assignee | ||
Comment 21•22 years ago
|
||
Allows "chrome-nodes" to do anything.
Assignee | ||
Comment 22•22 years ago
|
||
ccing for reviews
Comment 23•22 years ago
|
||
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 24•22 years ago
|
||
Comment on attachment 92042 [details] [diff] [review] patch to fix sr=jst
Attachment #92042 -
Flags: superreview+
Comment 25•22 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•22 years ago
|
||
Bug #158432 may be related to or a duplicate of this bug.
Assignee | ||
Comment 28•22 years ago
|
||
checked in
Comment 29•22 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.
Comment 30•22 years ago
|
||
this works fine with trunk builds from 0722-0723 and on branch builds from 0722 marking verified
Status: RESOLVED → VERIFIED
Comment 31•22 years ago
|
||
thanks tracy
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.
Description
•