Closed
Bug 72097
Opened 24 years ago
Closed 17 years ago
opening file in composer takes a long time
Categories
(Core :: DOM: Editor, defect, P3)
Core
DOM: Editor
Tracking
()
RESOLVED
WORKSFORME
mozilla1.5alpha
People
(Reporter: bugzilla, Unassigned)
References
()
Details
(Keywords: perf)
the editor takes an awfully long time to open a medium-sized file [about 80kb].
1. launched ./netscape -P [profile] -edit
2. clicked Open button to bring up file picker.
3. double-clicked the file in the URL [in my local tree] to open it.
result: it took 11 seconds to load the file --from the time i double-click its
name in the file picker to when i finally got a cursor. even subsequent attempts
to open the file [after exiting and restarting composer] take about 11sec.
this, imho, is way too long to wait: after all, i'm running 2001.03.12.12 comm
[modern theme] bits on a decently-spec'd linux box [HP Kayak 500Mhz PIII, 256M
RAM, Redhat 6.2 w/gnome desktop; running sawmill].
Reporter | ||
Comment 1•24 years ago
|
||
oops, almost forgot the url to the sample file.
also, this might be related to bug 29584 and bug 28783.
Severity: normal → major
By the way, that page doesn't even load on a Mac with N6.
all kinds of code spits out in the window. someone may wanna
file a bug on this...
Comment 3•24 years ago
|
||
This page loads fine in my debug tip Mozilla build, and takes about 10 seconds. I
don't see "all kinds of code spits out in the window".
I also tried on another Mac and it works fine...I will reinstall
the build on my mac...thanks Simon.
Reporter | ||
Comment 5•24 years ago
|
||
timings for win32 and mac:
* using 2001.03.19.09 comm verif bits on winNT, it took 9sec to open the file in
the editor. [also on a not-so-bad machine: HP Kayak, 500MHz PIII, 128M
RAMrunning winNT 4.0.]
* using 2001.03.19.12 comm verif bits on Mac OS 9.0, it took ~10sec to open the
file in the editor. [450MHz G3, 128M RAM.]
more info: i've been timing these using the modern theme, btw.
OS: Linux → All
Hardware: PC → All
Comment 6•24 years ago
|
||
this may be from populating all those empty table cells with br's, though i don't
know why that would take 10 seconds.
Comment 8•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 9•23 years ago
|
||
don't move bugs that are in the 1.0 dependency tree. sorry.
Target Milestone: mozilla1.0.1 → mozilla1.0
Comment 10•23 years ago
|
||
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any
questions or feedback about this to adt@netscape.com. You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.5alpha
Updated•20 years ago
|
Assignee: sfraser_bugs → mozeditor
QA Contact: sujay → bugzilla
Comment 11•19 years ago
|
||
WFM ~1sec http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060101 SeaMonkey/1.5a
Updated•18 years ago
|
QA Contact: bugzilla → editor
Updated•18 years ago
|
Assignee: mozeditor → nobody
Comment 12•17 years ago
|
||
=> WFM (trunk)
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•