Closed Bug 99655 Opened 23 years ago Closed 23 years ago

Switching between Preview and show all tags causes composer to run extremly slow

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.7

People

(Reporter: TucsonTester2, Assigned: cmanske)

References

Details

(Keywords: perf, Whiteboard: EDITORBASE) 

In a page with a background and switching from Preview to Show All Tags view in
Composer the processor usage goes to 100% and composer becomes unstable.

Build: 2001091003

Reproducibility: Every time

Steps to Reproduce:
1. Open Netscape Browser
2. Open Composer
3. Insert a background image
4. Switch from "Preview" to "Show All Tags" to "Preview" and back to "Show All Tags"
5. Click on the text color button on the toolbar6. Switch to the browser

Actual Results:
The menu will not come up right away, once you switch to the browser it will let
the text color property menu display.  Once you choos a color and click ok it
will go away but everything will be slow or unstable.  Menus and mouse function
may be unavailable, (highlighting, right clicking, etc.)
Expected Results:
I would expect that composer would not become unstable and increase it's
processor and memory usage so greatly.
-->syd
Assignee: brade → syd
Keywords: perf
Confirmed on Win 2k and Win 98 both using build 20010927.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 99659 has been marked as a duplicate of this bug. ***
As was noted on bug 99655, another symptom of this issue is that if you try to
click on Bold, Italic, or Underline, those buttons disappear when you click on them.
*** Bug 99637 has been marked as a duplicate of this bug. ***
Akkana, reassign if this is not something you can deal with.
Assignee: syd → akkana
Whiteboard: EDITORBASE
Target Milestone: --- → mozilla0.9.6
Charley, can you take a look at this?  The only platforms reporting this are
Windows though the platform says All (we really need platform entries like "All
Windows" or "All Unix" in bugzilla), and you know a lot more about what happens
when switching to Show All Tags.  Send it back if you don't have time or think
it's more my area.
Assignee: akkana → cmanske
I could have sworn I commented on this bug or a dup of it!
This is serious, and I think it's a treading issue in CSS. As Daniel can attest,
setting the background image seems to be a very tricky and fragile area of 
the layout code. I did see this, but I can't reproduce it in my build that is
updated as of 10/3.

I am still seeing this on Win 2k using Netscape QA Trunk build 20011003,
Netscape QA Branch build 20011002, and on Mozilla build 20012004.  Though, the
hanging does not seem as bad as it was last week.  If you pause between steps 5
and 6, you can really see that it is hanging up before bringing up the color
selection screen.
Blocks: 91351
My current build from 10/16 still doesn't show this problem.
Severity: normal → major
The steps to reproduce don't say anything about when you went into preview mode.
After inserting the image as background?
Yes, after inserting the background image.  Step 3 should read: Switch TO
"Preview" to "Show All Tags" to "Preview" and back to "Show All Tags".

I am still seeing this on Win XP, and 98 using 20011017 build.  The slowness
seems to be worse on XP.  It should also be noted that you have to pause between
steps 5 and 6 in order to see that the text color box isn't popping up right
away.  So after you click on the text color button, wait a few seconds, and then
switch to the browser.  Notice that the color picker won't come up until you
change to the browser.


cannot reproduce bug on win2k with build 20011017...
Sujay: Please continue testing this on all Windows versions. We have not been
able to reproduce recently.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
I am still seeing this problem on the 20011022 branch build, but this is not
happening on the 20011029 trunk build.  Both using Win 2k.
Is that the 0.9.5 milestone branch? If yes, and it doesn't happen on the 
trunk, then hopefully we don't have to worry about it. We definitely will not
fix anything on branch builds.

ooohhhhh, weird, bug **CONFIRMED** on Win2k 20011029 !!! I just used an old build
from the 16th I left on another disk : confirming too !
11-12-01, debug build: still can't reproduce this.

I am not seeing this problem anymore on Win 2k using build 2001111305.  

I am resolving WORKSFORME.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.