Closed Bug 35450 Opened 24 years ago Closed 24 years ago

resizeBy is not working as desired

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: nshankar, Assigned: danm.moz)

References

Details

(Keywords: testcase, Whiteboard: [nsbeta2+][6/15])

Attachments

(2 files)

testcase
82 bytes, text/html
Details
screenshot of problem
2.48 KB, image/gif
Details 
The below screen kind of garbles the screen.
<html>
<Script language="javascript">
self.resizeBy(-15,10);
</Script>
</html>
confirmed with 200041108 with win98, will attach testcase and image of problem
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file testcase — 

    
    

    
  

      
      
      
      

        Attached image
          
        screenshot of problem
        — 
      

    


  

    
    

    
  
there's also some oddities when clicking up near the minimize/maximize/restore 
buttons, i.e. a new minimize button that appears to be part of a different 
window appears if you left click on the menubar in the space next to the normal 
minimize button. other strange behavior is encountered when moving the window 
around.

it appears to just be a simple problem in dynamically updating/refreshing the 
screen, since switching to a different program and switching back fixes the 
problem.

i dont believe this to be a problem with the javascript engine, its parsing 
correctly and so forth, the screen just isn't updating correctly.

    
  
Keywords: testcase

    
    

    
  
Agreed it's not JS engine, don't really know the componenet for overall Window 
drawing issues.
Assignee: rogerl → asadotzler
Component: Javascript Engine → Browser-General
QA Contact: pschwartau → jelwell

    
    

    
  
Layout or compositor maybe?  Giving it a shot
Assignee: asadotzler → troy
Component: Browser-General → Layout
QA Contact: jelwell → petersen

    
    

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

    
    

    
  
I don't think this is a layout problem. Looking at what happens when resizeBy is 
called we go into the DOM and then we call the widget code and have it do the 
resize
Assignee: troy → trudelle
Component: Layout → XP Toolkit/Widgets
QA Contact: petersen → jrgm

    
    

    
  
reassigning to danm for triage. Dan, is this a window problem or a widget 
problem?
Assignee: trudelle → danm

    
  
Target Milestone: --- → M17

    
  
Blocks: 30249

    
    

    
  
moving to m18
Target Milestone: M17 → M18

    
    

    
  
Nominating nsbeta2. We have to start drawing a line on DOM0 backward 
compatibility; these bugs are supposed to be a high priority for nsbeta2 per the 
beta2 criteria.
Keywords: nsbeta2

    
    

    
  
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21

    
    

    
  
Setting to [nsbeta2+][6/15]. M17. nsbeta3 stopper if misses nsbeta2.
Whiteboard: [nsbeta2+][6/15]
Target Milestone: M21 → M17

    
    

    
  
on linux, this javascript doesn't appear to have any effect

    
  
Status: NEW → ASSIGNED
Whiteboard: [nsbeta2+][6/15] → [nsbeta2+][6/15] M17 and low priority? oops. still, fix awaiting review.

    
    

    
  
If this doesn't work on linux as pavlov said, then this is a lot more of a 
problem [the original issue is just that the window doesn't properly refresh, 
which has an easy workaround].  Pav - are you sure nothing's changing within 
the window at all in the testcase?  It's a subtle resize, and on win32 you 
can't even see a change unless you move the window a little, which reveals that 
it's changed size and messed up a bit.

    
    

    
  
Yes, I'm not sure what Pav is seeing. When I tried this on Linux, it gave me no 
problems. Maybe his machine is too fast. On my Linux box, you could watch every 
resize coming through, one by one. Another test case controlled by buttons rather 
than executed automatically on page load also works fine on linux and the Mac, 
but fails on Windows. It's just a refresh problem on Windows, by my testing.


    
    

    
  
With some trepidation because I don't see what Pavlov described above, I claim 
this is fixed now. The JS routines that resizing goes through weren't requesting 
a redraw; now they are.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+][6/15] M17 and low priority? oops. still, fix awaiting review. → [nsbeta2+][6/15]

    
    

    
  
Looking good. verified fixed win32/mac/linux 20000607nn M17 builds.
Thanks for the testcase Shankar N.
Status: RESOLVED → VERIFIED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: