Closed
Bug 24597
Opened 25 years ago
Closed 25 years ago
[PP]Text field has image from area behind window
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
M14
People
(Reporter: nbaca, Assigned: kmcclusk)
References
Details
(Keywords: platform-parity, Whiteboard: [PDT+])
Build 2000012009M13: NT4 Overview: Go to create a New Address Book and garbage appears in the "Address Book Name" field. It looks like the menu from the Address Book is appearing in the field. Steps to reproduce: 1. Launch the Address Book 2. Select File|New|Address Book Actual Results: Notice the garbage in the "Address Book Name" field. Expected Resultss: The "Address Book Name" field should appear white. If I switch to another window and select the minimized "New Address Book" icon from the windows taskbar then the field looks white as expected. Additional Information: - Linux build 2000012008M13, no garbage appears. - Mac build 2000012008M13, no garbage appears.
Reporter | ||
Updated•25 years ago
|
QA Contact: lchiang → nbaca
Changing the Summary and sending to buster (hopefully the right person). This problem is happening in a number of dialogs. Open Web Location and the two dialogs mentioned in the address book. The image that was directly behind the html:input type="text" is still there when the dialog is displayed. This does not happen on Mac.
Assignee: hangas → buster
Status: ASSIGNED → NEW
Component: Address Book → XP Toolkit/Widgets: XUL
Product: MailNews → Browser
Summary: [PP]Garbage appears in New Adddress Book dialog → [PP]Text field has image from area behind window
since this only happens on windows, I'm guessing the text control isn't doing anything wrong -- it's setting up the right frames in the right location with the right size. I'll bet it has something to do with the view system, though I don't know what. Kevin suggested I try nsViewManager2 to see if it made any difference, and it did not. After a little more experimenting, Kevin says "assign it to compositor."
Assignee: buster → beard
Component: XP Toolkit/Widgets: XUL → Compositor
QA Contact: nbaca → petersen
Migrating whiteboard status, keywords, and Cc list from bug #24835.
Keywords: beta1
Whiteboard: [PDT+]
Migrating Cc list from bug #24425.
This bug will happen when we programitcally set focus (via JS) to a textfield in a dialog that we are displaying. (examples include: Find Dialog, most Composer dialogs, etc.) I've spent some time looking at the problems this week and noticed a few peculiarities in some ViewManager code. Like the fact that some update rects for the ClipView of Scrolling views get converted to (0,0) 1x1 during the initial reflow because we haven't set the ClipView's size. Perhaps beard@netscape.com and I can get together to look at this one.
Comment 10•25 years ago
|
||
Note to QA: when fixed, should check various cases/dialogs mentioned in the duplicate bugs.
Comment 11•25 years ago
|
||
This is likely a race condition between reflow and painting. Kevin McCluskey is looking into these issues. This really isn't a compositor issue at all, but perhaps a fundamental interaction between the text widget and layout.
Assignee: beard → kmcclusk
Component: Compositor → Layout
Comment 12•25 years ago
|
||
*** Bug 26621 has been marked as a duplicate of this bug. ***
Comment 13•25 years ago
|
||
*** Bug 26731 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
This seems to work in todays build. I'm not sure what changed. In yesterday's build, it looked like nsWindow::Invalidate() was being called to invalidate the textfield's entire content window, but a WM_PAINT message for the content window was never dispatched, eventhough UpdateWindow() was called on the content window's parent window. In today's build, the WM_PAINT message seems to be getting generated.
Assignee | ||
Comment 15•25 years ago
|
||
I no longer see this problem as well. I'm not sure what changed to fix it, but I'm marking it WORKFORME
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 16•25 years ago
|
||
*** Bug 26362 has been marked as a duplicate of this bug. ***
Comment 17•25 years ago
|
||
Verified WORKSFORME on 2000022608 W95 for the dialog detailed in the description. I haven't seen this problem for a few weeks either. Gerv
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•