Closed Bug 22422 Opened 20 years ago Closed 20 years ago

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

Categories

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

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.Splinter Review
Status: ASSIGNED → RESOLVED
Closed: 20 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.