Closed Bug 22422 Opened 25 years ago Closed 25 years ago

Text fields in mail news wizard only display first few characters typed

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

x86
Linux

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: slogan, Assigned: kinmoz)

References

Details

Attachments

(1 file)

Linux, 12/22 M13 tip of tree, mozilla build. I was trying to set up a profile for mail news on my home machine. Typing in server names, users names, etc. I would only ever see the first 1 or two characters typed. Dragging an xterm or some other app window over the dialog would cause the entire text to display.
Assignee: phil → alecf
QA Contact: lchiang → nbaca
Account Manager -> Alec.
Assignee: alecf → buster
editor/paint bug -> buster
Assignee: buster → kin
linux-only paint bug. assigned to kin, cc akkana and pav.
Target Milestone: M14
setting this to m14
Status: NEW → ASSIGNED
Accepting bug.
Target Milestone: M14 → M13
received some additional data on just how annoying this on is -- the perception that the editor isn't working due to the lack of visual feedback -- so, I'm setting this one back to m13.
The same behavior happens in HTTP password authentication dialogs; so this may be not just a MailNews problem. Eg: point your browser to http://www.dmoz.org Click on "Editor Login" Password dialog comes up, where only first character of name and password are displayed.
*** Bug 22919 has been marked as a duplicate of this bug. ***
The damage rects are being recorded by each nsWindow. The problem seems to be that the Gtk implementation of nsWindow::Update() only updates it's associated native window. The view manager assumes that updating a window will also force/flush any pending updates for child windows too.
Attached patch Proposed fix. (deleted) — Splinter Review
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Checked in fix: mozilla/widget/src/gtk/nsWindow.cpp revision 1.227 r=blizzard@redhat.com,pavlov@netscape.com
Blocks: 14845
No longer blocks: 14845
This problem was noted in bug 14845, which was reopened. 14845 is now marked as depends on this bug and that bug should be retested when this is tested.
Using linux build 2000011313m13 this is working OK. I tested this scenario along with the scenario in 14845 and all text field entries are working. Just to double check, syd could you please confirm yours is fixed too.
Per Esther's claim that this bug is fixed, I am verifying this bug. If the problem occurs again then please reopen.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: