Closed Bug 14845 Opened 25 years ago Closed 25 years ago

[DOGFOOD] [PP] linux only typed text doesn't display until you press <enter> and start typing again

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: esther, Assigned: kinmoz)

Details

(Whiteboard: [PDT+] Can't reproduce. Might have been fixed by fix for bug #22422.) 

Using 1999092408m11 builds on linux typed text in HTML compose window does not
show up until you press <enter> and start typing again.   fyi...Quick testing of
editor doesn't have this problem.

1. Launch Messenger
2. Click New Msg  (be in HTML format)
3. Fill in To: and subject move cursor to Message Body and start typing.

result:  cursor move to right but characters don't show up
expected:  typed text to display as typed
workaround: press <enter> then start typing again or select the text and press
<enter>
Severity: normal → blocker
Hardware: HP → PC
This bug was not in yesterday's builds.
Note: happens on both commercial and mozilla builds for 9/24.
Update:  does not happen on Mac
Assignee: ducarroz → pavlov
Per Kathy Brade who checked for me - assign to pavlov.  Kathy checked in the
build logs: " pavlov checked in some code with a comment: "'make painting on
linux not suck'"
Summary: [PP] linux only typed text doesn't display until you press <enter> and start typing again → [DOGFOOD] [PP] linux only typed text doesn't display until you press <enter> and start typing again
This there any update on this?  cc: phil as well.  marking Dogfood bug.
Target Milestone: M11
We will relase note for M10...setting on M11.
I'm not seeing this using 10-11-08m11 commercial build.
I'm not seeing this in the 19991012m11 mozilla linux build either, based on
laurels comment and mine this can now be resolved as Worksforme if there was no
known fix.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Linux (1999-10-11-14-M11) Commercial
Win32 (1999-10-11-15-M11) Commercial
Mac (1999-10-11-14-M11) Mozilla
I do not see this problem in these builds.  Mark it worksforme.
Is it OK to mark it fixed??
Status: RESOLVED → VERIFIED
I am going to mark it verified since this problem has been fixed.
good...
Status: VERIFIED → REOPENED
This has come back (I saw it all through the M12 freeze and still see it on the
tip) and is pretty annoying.  One good way to see it: hold down the backspace key.
Whiteboard: PDT+
marking PDT+
Resolution: WORKSFORME → ---
Clearing WorksForMe resolution due to reopen.
Whiteboard: PDT+ → [PDT+]
Using the 20000104 linux build I'm seeing this too.  It's really bad, I typed
"esther" in the To: field and only the "e" displayed.  I then put focus in the
Subject field and typed "subject", only the "s" displayed, I then put focus in
the body and typed "This is a test"  nothing displayed.
need a new target milestone since this bug was reopened since M11.
Target Milestone: M11
I see a delay in displaying the text, but it appears when I stop typing.  I see
this in the other, plain text edit fields in that window too.  Pav, why is this
assigned to you?  Shouldn't the editor team own this? cc beppe, clearing target
milestone.
It's not an editor issue, it's a Linux repaint problem.  Repainting is on some
sort of a timer (in gtk?) and doesn't happen until the user goes idle for some
length of time.

Cc'ing kin because he was asking about the status of this bug.
On my system a Compaq 166, the characters never show up, if I wait too long for
them to display, my system freezes.  In a New Card for Address Book, the
characters don't display while I'm in that dialog, but will show up in the
Results pane after I have closed the dialog.  Just and FYI...
My PC is also a Compaq P166...
OK, I'm still using the 1/5 linux netscape build, I will try this agian with the
1/6 build and check with others in my group.  For me, on my system it's really
bad so I need to find out if my system is acting up, thanks for the info Peter.
Assignee: pavlov → kin
Status: REOPENED → NEW
kin - I see this on my machine too.  The area where the new text is supposed to
be getting drawn is never being invalidated... any ideas?
Status: NEW → ASSIGNED
Target Milestone: M13
Accepting bug.
I can't reproduce this in any of my builds. This could be related to bug #22422
which I checked in a fix for today. The fix should appear in 01/13/2000
Seamonkey builds.

Could someone in QA please verify that it is fixed? Or show me how to reproduce
this?
Depends on: 22422
I will mark this depends on 22422 and retest when we get a build with the fix.
No longer depends on: 22422
QA Contact: lchiang → esther
esther, after you check tomorrow build, if this works but a bit delayed, then
change to [PDT-].  pdt would not call that dogfood.  thanks!
Whiteboard: [PDT+] → [PDT+] Can't reproduce. Might have been fixed by fix for bug #22422.
QA, any news on reproducing this? I can't reproduce it, and would like to close
this down as fixed for M13 if possible.
Using linux build 2000011313m13 this is working OK.  Per Jans comment on
20000113, there is no delay either so this is basically fixed no need to PDT-
it.  Note: I can't test is on today's builds 1/14, because their broken.  So
this can be resolved and I will verify based on the 1/13 builds.  If it comes
back again, I will reopen.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Marking fixed based on esther's comments above. :-)
Verifying
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.