Closed Bug 89734 Opened 23 years ago Closed 23 years ago

Window updating/initial drawing probs under Mac OS X

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: chrispetersen, Assigned: sfraser_bugs)

References

Details

(Whiteboard: [OSX+][ETA 09.28], [PDT+])

Attachments

(3 files)

screen shot of problem
73.36 KB, image/jpeg
Details
Screenshot showing bad port management under X still exists
25.60 KB, image/png
Details
nsWindow.cpp fix
917 bytes, patch
mikepinkerton
: review+
Details | Diff | Splinter Review 
Build: 200107515
Platform:All
Expected Results: Window's contents should be completely displayed.
What I Got: Portions of window are not painted correctly. 

Icons on the bottom left corner are almost completely missing.
To : recipient field is partially missing.

Steps to reproduce:

1) From the New menu ,choose  New - Message

2) Compose window appears.
Attached image screen shot of problem — 

    
    

    
  
Attached screen shot of problem. This issue is a Mac OS X only and happens in
both skins (Modern and Classic).


    
    

    
  
*** Bug 89512 has been marked as a duplicate of this bug. ***

    
    

    
  
Platform: PowerBook G3/300/192Mb/25Gb, MacOS X 10.0.4
Fizzilla Build ID: 2001070318

All my accounts are POP, and I have the same issue when creating a new email
message. Various areas of the window are missing. Usually mousing over, or
clicking the collapse bar twice (once to close, once to open) to the left of the
button or address/attachment bars forces a redraw. See my notes in the bug I
resolved against this one.

- Adam

    
    

    
  
over to dagley for a look. i've seen this bug myself.

Assignee: trudelle → sdagley

    
    

    
  
does re-sizing the window also fix the problem for everyone?  It looks like we're 
failing some sort of calculation in the initial layout of the window.


    
    

    
  
Yup, simply clicking the grow box forces a redraw on the window. Looks normal
after doing that.

- Adam

    
    

    
  
Yes, resizing the window is the workaround soultion. It just looks bad when the
window is first opened.

    
    

    
  
I think whatever is going on here may be similar to what's happening in bug 90769.

- Adam

    
    

    
  
(Same issue on IM compose window using 2001-07-17 commercial carbonized builds. 
Must resize the window to fully display contents.)

    
  
Summary: Mail compose window is not completely displayed → Window updating/initial drawing probs under Mac OS X

    
    

    
  
May God have mercy on us all. The 212 bug spam-o-rama is Now!
QA Contact: aegis → jrgm

    
    

    
  
*** Bug 97029 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 97328 has been marked as a duplicate of this bug. ***

    
    

    
  
Nominating nsbranch because of it's affect in IM.
Severity: normal → major
Keywords: nsbranch

    
    

    
  
The IM bug in Bugscape is http://bugscape.netscape.com/show_bug.cgi?id=7352
It's marked nsenterprise +

    
    

    
  
Changing milestone to 0.9.5.  Anybody got any suggestions where to look on this one?
Target Milestone: --- → mozilla0.9.5

    
    

    
  
Bad port management? (The kind of thing that causes Mozilla to stomp over Finder 
windows sometimes on 9.)


    
    

    
  
this is blocking an nsenterprise+ bug in bugscape.
http://bugscape.mcom.com/show_bug.cgi?id=7352
nominating here.
Keywords: nsenterprise
Whiteboard: OSX++

    
    

    
  
*** Bug 98517 has been marked as a duplicate of this bug. ***

    
  
Priority: -- → P1

    
    

    
  
*** Bug 99394 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 99396 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 99980 has been marked as a duplicate of this bug. ***

    
    

    
  
Any update to this?  Makes IM pretty unusable under OS X :-(

    
    

    
  
--> attinasi
Assignee: sdagley → attinasi

    
  
Blocks: 92736

    
    

    
  
*** Bug 100602 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 92736 has been marked as a duplicate of this bug. ***

    
  
Whiteboard: OSX++ → [OSX+]

    
    

    
  
The screenshot that I just attached shows that we still have port management
issues under Mac OS X. These have also been discussed in bug 46662 and bug
58104. In addition, bug 100700 describes a problem with blank XP menus and new
windows which occurred just before the bad drawing in my screenshot, leading me
to assume that it's a related problem.

    
    

    
  
Should  bug 46662, bug 58104, and bug 100700 be marked as depdencies for this
bug to be resolved, or are they just related information (FYI)? Should we mark
these bugs as [OSX+]? Questions, questions, ex-marketing folks are always loaded
with questions ... blah, blah, blah.



    
    

    
  
Mark - Status pls ... Simon's fixes did not affect your bug.

    
  
Whiteboard: [OSX+] → [OSX+][ETA?]

    
    

    
  
Pierre - pls check with karnaze and see if you you can accept this one. PDT
really needs your help.

    
    

    
  
*** Bug 100632 has been marked as a duplicate of this bug. ***

    
    

    
  
Taking the bug: I installed OS X, got a build, and I can reproduce the problem.
It will be a long and painful campaign: no ETA.
Assignee: attinasi → pierre

    
  
Whiteboard: [OSX+][ETA?] → [OSX+][ETA10.01]

    
  
Keywords: nsenterprise+

    
    

    
  
marking nsenterprise- to get off the enterprise stop ship list.
Keywords: nsenterprise-

    
    

    
  
adding PDT for review
Whiteboard: [OSX+][ETA10.01] → [OSX+][ETA10.01], PDT

    
    

    
  
If I build Carbon with paint flashing on, double buffering off, and run it under 
9, I can see that we have some coordinate problems when we update the IM window.


    
    

    
  
*** Bug 98814 has been marked as a duplicate of this bug. ***

    
    

    
  
Well, this is very odd. I can see a problem in nsWindow::InvalidateRegion() in 
carbon builds. We set up the port correctly, set the origin to (0, 0), and then 
call InvalWindowRect() on a correct region. However, if I look at the window's 
update region immediately after this call, it's offset by {16,73} pixels. This 
{16,73} does not appear to correspond with any of the offsets between views in 
the window, and remains even if I resize things or collapse toolbars.

Other code paths call nsWindow::InvalidateRegion(), and in those cases there is 
no weird offset; things work correctly.


    
    

    
  
Oh, it does happen in other windows (like the browser). And the offset is the 
offset of the global bounds of the window. Hrmm.


    
    

    
  
Here is an easier way to track down the problem:
- turn double-buffering off
- launch carbon-viewer under debugger and OS 9
- set a breakpoint at debug_GetCachedBoolPref() in order to manually turn 
flashing on
- remove the breakpoint and run
- load Test 8
- scroll a bit and type some text in any editable field
===> Invalid rects are flashed all over the place.  As you pointed out, the 
offsets within the window correspond to the global coordinates of the editable 
fields.

I first noticed the problem in Mozilla when playing with the URL field or any 
editable field in the content area.  Did you see coordinate problems that were 
not related to editable fields?

Other thoughts:
- We should pay attention to the code in nsWindow.cpp that is #if TARGET_CARBON, 
particularly the patch for bug 31131.
- There is also the possibility that nsWindow::Flash() might not be correct for 
Carbon builds.  I haven't looked into it, it just came up to my mind.

Status: NEW → ASSIGNED

    
  
Whiteboard: [OSX+][ETA10.01], PDT → [OSX+][ETA10.01], [PDT]

    
    

    
  
The flashing code that I was using doesn't use nsWindow::Flash, but rather 
blink_rect and blink_rgn. I verified that this was doing the right thing (origin 
had been set to 0,0 before blinking).

I also verified that if I draw just before the bad InvalWindowRgn, the drawing 
happens in the right place, so it's not a general coordinate problem; it really 
does seem that InvalWindowRgn/InvalWindowRect (I tested both) are broken.


    
    

    
  
Note for future fix verification:
Please check also 'Reply' and 'Reply All' windows since bug 98814 has been
marked as a duplicate of this bug.
Currently recipient field(s) is empty when Reply or Reply All.  Work around:
Double click in the field or resize the window.


    
    

    
  
I have been misled. GetWindowUpdateRegion() returns a region which is in _global_ 
coords, so one cannot just blink it without a GlobalToLocal transform. In 
addition, this code will thus do the wrong thing:

#if TARGET_CARBON
		//•PINK - hrm, can't do this in Carbon for re-entrancy reasons
		// ::CopyRgn(saveUpdateRgn, ((WindowRecord*)mWindowPtr)->updateRgn);
		::InvalWindowRgn(mWindowPtr, saveUpdateRgn);
#else
...


    
    

    
  
Fix coming, mine.

Assignee: pierre → sfraser
Status: ASSIGNED → NEW

    
    

    
  
Fix is simple. 'saveUpdateRgn' is in global coordinates (since window update 
regions are stored in global coordinates), so we need to offset it to local 
coords before calling InvalWindowRgn (which takes a region in local coords).

Status: NEW → ASSIGNED

    
    

    
  
Comment on attachment 51129 [details] [diff] [review]
nsWindow.cpp fix

wahooo!

        Attachment #51129 -
        Flags: review+

    
    

    
  
oh, and by 'wahooo' i meant 'r=pink' ;)

    
    

    
  
sr=scc

    
    

    
  
We are so there.

Whiteboard: [OSX+][ETA10.01], [PDT] → [OSX+][ETA 09.28], [PDT]

    
    

    
  
Checked in on the TRUNK


    
    

    
  
check it in - PDT+
Whiteboard: [OSX+][ETA 09.28], [PDT] → [OSX+][ETA 09.28], [PDT+]

    
    

    
  
I'm just seeing the comments that followed the ones at [14:41].  The solution I 
got is the following, which seems more correct in case someone calls Invalidate() 
or InvalidateRegion() synchronously:

    nsRect localRect, globalRect;
    WidgetToScreen(localRect, globalRect);

    PRInt32 offsetX, offsetY;
    CalcOffset(offsetX, offsetY);

    ::OffsetRgn(saveUpdateRgn, offsetX - globalRect.x, offsetY - globalRect.y);
    ::InvalWindowRgn(mWindowPtr, saveUpdateRgn);


    
    

    
  
To be more accurate, the solution above is probably more correct if someone calls 
Update() or Invalidate/InvalidateRegion() synchronously on anything else than the 
top level window.


    
    

    
  
Pierre: I think what you suggest will amount to the same thing as what I did. I 
think my solution is OK, because this method is explicitly saving and restoring 
the old update region (which is not a gecko-maintained region), and my code is 
closest to the non-Carbon code (which just slams the region back into windowpeek-
>updateRgn). Either way should work if the origin is not {0, 0}.


    
    

    
  
Checked in on the branch.

Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
> It will be a long and painful campaign

May they all be so long and painful...

    
    

    
  
verified on branch build 2001-09-28-04-0.9.4
Status: RESOLVED → VERIFIED

    
    

    
  
Great work!

    
    

    
  
sending IM messages UI looks great! 
Yeah! Thanks guys!

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: