From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.5) Gecko/20011015 BuildID: 2001112020 Getting the stored data takes about 2-3 minutes. Reproducible: always Steps to Reproduce: 1. Choose Edit > View Saved Data 2. Select 'Other Form Data' Submenu (click triangle) 3. Select URL Specific 4. wait Actual Results: Watched the beach ball spin for about 2-3 minutes Expected Results: Should not take more than 2 seconds to get data. This is just a symptom of what every user knows about Mozilla -- it's slow! Maybe the program could be redesigned in some way.
Assignee: pchen → morse
Component: XP Apps → Form Manager
QA Contact: sairuh → tpreston
Garrett, you're sure you can always reproduce this? Even after a restart and with Mozilla the only app running? The colored "beach ball" cursor is usually evidence that the System itself is grinding away, not Mozilla. Anyway, I'm unable to reproduce this since I have no such saved data. ^_^
WFM Mac OS X build 2001120308
Garrett, could you give me a specific URL where you are seeing this behavior and the information that you have saved? thanks
"Garrett, could you give me a specific URL where you are seeing this behavior" I went to http://www.mozilla.org/start/ , chose Edit > View Saved Data. When the Form Manager popped up, I clicked the triangle next to Other Information and selected URL Specific. This bug is not url specific, It has to do with the Form Manager's URL Specific option. Kind of confusing; I see why you asked. Build id: 20001112020 Mac osx. I have about 89 fields from various forms online here. It took Mozilla 2 min, 12 sec (2:12) to display that data. The data in each feild is text, I would guess an average of 20 characters per field.
I have quite a large amount of URL specific data. Around 120 entries in the URL specific data. The .w file is 12 Kb. Clicking "URL Specific" takes around 2 min to load. While loading the data, Mozilla tops the Task Manager with 100% and becomes totally unavailable. build 20020104
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All
*** Bug 122450 has been marked as a duplicate of this bug. ***
nsbeta1- per Nav triage team, adding helpwanted keyword
Keywords: nsbeta1 → helpwanted, nsbeta1-
moving out per the nsbeta1- decision
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Priority: -- → P2
Target Milestone: mozilla1.1alpha → mozilla1.1beta
The UI has changed, I think you now need to do Edit > Preferences... > Privacy & Security > Forms > Manage Stored Form Data > Other Saved Information > URL-Specific . Is this correct? We need some more numbers to determine how important this is. Everyone please report how many items you have in that category, and approximately how long did it take on your system, and specify your system. Also, how often do you use this feature? I have 20 items, and it takes about 2 seconds on Win2k, 1.5GHz, 512 MB RAM. I have never used this feature before.
Preferences... > Privacy & Security > Forms > Manage Stored Form Data > Other Saved Information > URL-Specific . Is this correct? Env: ac g3/os x 350 256mb under. Time: about 4 sec. Records: 18 4 seconds (2 seconds on Heikki's windows machine) may seem trivial. If you consider what it actually does -- populate a ui from a file -- it is still pretty slow. Going to add more records...
dveditz is the new module owner, reassigning. This does not seem like a stopper, so Future.
Assignee: morse → dveditz
Status: ASSIGNED → NEW
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.2beta → Future
The current satchel implementation is based on sqlite, and does not have this problem. Wallet is depreciated.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
QA Contact: tpreston → form-manager
Resolution: --- → WORKSFORME
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: form-manager → form.manager
Target Milestone: Future → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.