Closed Bug 112758 Opened 23 years ago Closed 16 years ago

View Saved Data > URL Specific takes about 2 minutes

Categories

(Toolkit :: Form Manager, defect, P2)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dhtmlkitchen, Unassigned)

References

Details

(Keywords: helpwanted, perf)

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.
form mgr.
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
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
*** Bug 122450 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Blocks: 74634
nsbeta1- per Nav triage team, adding helpwanted keyword
Keywords: nsbeta1helpwanted, nsbeta1-
moving out per the nsbeta1- decision
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
Priority: -- → P2
Target Milestone: mozilla1.1alpha → mozilla1.1beta
Keywords: nsbeta1-nsbeta1
Target Milestone: mozilla1.1beta → mozilla1.2beta
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: nsbeta1nsbeta1-
Target Milestone: mozilla1.2beta → Future
Assignee: dveditz → nobody
The current satchel implementation is based on sqlite, and does not have this problem. Wallet is depreciated.
Status: NEW → RESOLVED
Closed: 16 years ago
QA Contact: tpreston → form-manager
Resolution: --- → WORKSFORME
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.