Closed Bug 123207 Opened 23 years ago Closed 22 years ago

file bookmark dialog window resizes itself after every use from the bookmark manager

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mozbugz, Assigned: neil)

References

Details

(Keywords: polish)

Attachments

(3 files, 3 obsolete files)

Fixed patch
6.05 KB, patch
p_ch
: review+
Details | Diff | Splinter Review
Removed comment as requested
6.34 KB, patch
asa
: review+
asa
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Test case for sizeToContent bug
458 bytes, application/vnd.mozilla.xul+xml
Details 
I see this only affecting from using file bookmark from the toolbar or context
menu in the bookmark manager: The dialog decides to resize itself after every
use if you are re-filing bookmarks, you see this right away.  Browser window
pull-down menu file bookmark dialog doesn't appear to have this problem.
Works for me 2002020103 on WinXP.

Dennis, please include the build id and detailed steps to reproduce this bug.
this is been around a long time, w2k builds are affected.  I've was using latest
nightly build 2-2-08, and was using bookmark manager to file current bugs in a
'needs filing folder' to new folders.

I click on either the toolbar's 'file bookmark(s)' or the context menu's 'file
bookmark(s)' menu item, which fires the 'file bookmark dialog'.. if you do like
any normal window in windows' you want a window to persist it's size, you click
on the window 'x' in the upper right.  Which should save its size.  Now, if try
to go thru such a folder you file one bookmark at a time using this, you would
see that the file bookmark dialog moves, and expands it size vertically and
horizonally, in different ways.. I could add several screenshots.  There is a
pattern to how it gets resized.  One that is noticable, is it gets resized on
the left side, so on subsequent firing, it incrementally will get larger towards
the left side of the screen.  I would have to really write down and take screen
shots of each one to get to be reproduceable that way..

the real problem is that the file bookmark dialog doesn't persist its size, from
one use to the next.
Ok, I'm now seeing this.  More specifically, every time the dialog is 
launched, it grows both vertically and horizontally based on where it is on 
the screen. 

Nice catch Dennis!
Status: NEW → ASSIGNED
Target Milestone: --- → Future
removing self from cc list
see bug 119599 comment 42.. 

Ok for a minute here if its the change to move code into SizeToFit(), I'm just
thinking maybe then the code to determine it persisted size lies inside
OpenDialog Function or Call?

The last days i allways had the effect, that the first few hours I worked with
the new nightly, the window allways resiezed to a very small size, when I opened.
After few hours (and several closes and reopen), the function was ok and
furtheron the window reopened always with the size as it had when I closed it
for the last time.

Actual:
Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020410
Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020410

Now I am shure!
Resizing (to minimum-size) only happens, when I want to file a Bookmark of a
Window with minimum a second TAB opened.

Preference "hide the tab bar when only one ...." is without influence to this
Problem.
this bug was just for the file bookmark from the Bookmark Manager is my testcase.
comment #6, #7 is about the new problem seen from bookmark groups bug 119599.
comment 5-7, I filed bug 136835 for the menus file bookmark.. not this BM file
bookmark.
added myself to CC
I believe, bug 136835 or bug 123207 shold be marked as DUP of the other one
*** Bug 136835 has been marked as a duplicate of this bug. ***
*** Bug 136835 has been marked as a duplicate of this bug. ***
Likely a dup of bug 99860 outright....
Depends on: 99860
The File Bookmark window is too small by default.

1. Bookmarks -> File Bookmark...

In the Create in... list, only two folders are shown.
There is a considerable space between the list and the check boxe above it. I
suggest enlarging the list of folders.
I have the same problem as comment 15. Using 1.0 RC2 on Linux.
Blocks: 146859
*** Bug 147550 has been marked as a duplicate of this bug. ***
Blocks: RememberPosition
This has been bugging me for so long. Adding myself to CC-list.
I get the problem whenever I have more than 1 tab open.  I first noticed the
problem when Mozilla started offering the "File as group" option for multiple tabs.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
Comment to #19
So it is.
Attached patch Proposed patch (obsolete) — — Splinter Review 
This patch moves the persist from the dialog to the tree so that when the file
as group checkbox is enabled the whole dialog gets bigger.
Keywords: patch, polish, review, ui
*** Bug 153365 has been marked as a duplicate of this bug. ***
<neil@parkwaycc.co.uk>'s patch in attachment 87507 [details] [diff] [review] works for me in fixing this
bug *and* bug 146859.  See bug 146859 comment 14 to 17.

However, I noticed that attachment 87507 [details] [diff] [review] broke bookmarking a group of tabs. 
When you type in a name for the group, the OK button isn't reenabled.  Here's
an extra patch, to be applied on *top* of attachment 87507 [details] [diff] [review], that fixes this.
Attached patch Fixed patch — — Splinter Review 
Thanks to Kevin for pointing out the problem, the actual fix simplifies the
addingGroup function so much that I've inlined it instead.
Attachment #87507 - Attachment is obsolete: true
Attachment #89485 - Attachment is obsolete: true
Again and again the problem with this bug is discussed in
"de.comm.software.mozilla".
This bug should have (if no quick solution is possible
- A Priority
- A target milestone
*** Bug 139591 has been marked as a duplicate of this bug. ***
Shouldn't 'OS' set to 'All', because the bug is not only specific to Windows
2000 (maybe also 'Platform' should be changed)?
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 158939 has been marked as a duplicate of this bug. ***
There is a patch here.  Is it ready for review?  (Probably some bitrot by now.)
 This is a high visibility problem.  Anyone who uses tabs will see this.  If a
fix is mostly ready then someone please review it.  If we're just waiting for
Neil to return then say so.
I just tried this patch on my up to date Linux CVS build, it applies cleanly and
fixes the problem of the file bookmarks dialog being too small.  This is very
visible and very annoying, can we get this in soon, please?  Neil, did you
already try getting reviews for this?
Blocks: 123569
Keywords: mozilla1.2
Build 2002072804 Win98se

I hope this bug is fixed now.  I have been re-sizing the file bookmark window in
order to use it.  I have a better work-around now - right-click on the title
bar, select "Maximize".
To neil.
Assignee: ben → neil
Status: ASSIGNED → NEW
*** Bug 163479 has been marked as a duplicate of this bug. ***
*** Bug 168245 has been marked as a duplicate of this bug. ***
*** Bug 170158 has been marked as a duplicate of this bug. ***
Comment on attachment 89526 [details] [diff] [review]
Fixed patch

r=chanial@noos.fr
Make sure the patch still apply
Attachment #89526 - Flags: review+
Attached patch Updated for merge conflict (obsolete) — — Splinter Review 

    
    

    
  
Comment on attachment 100873 [details] [diff] [review]
Updated for merge conflict

You're packing a few other changes in this patch too. You might want to make
sure that the changes from .setAttribute("checked", ...) to .checked = ... work
in the code that gets run from onload, I recall that in certain cases the
checkbox binding wasn't quite ready yet (a bug, I believe) and .checked
wouldn't have the desired effect.

Hmmm... I'm trying to recall why I check for the checkbox's visibility
(indirectly through showaddgroup's) before checking its checked state. Is there
any way the checkbox can be checked and hidden?

The comment after |else if (gFld_URL.value)| seems rather odd, just drop it.

    
    

    
  
> You're packing a few other changes in this patch too. You might want
> to make sure that the changes from .setAttribute("checked", ...) to 
> .checked = ... work in the code that gets run from onload, I recall
> that in certain cases the checkbox binding wasn't quite ready yet
> (a bug, I believe) and .checked wouldn't have the desired effect.

That's fixed by the removal of hidden="true" from the broadcaster that ensures
that the XBL gets bound to the checkbox before the onload handler, primarily so
that the dialog will resize properly, but incidentally allowing the use of the
.checked property.

> Hmmm... I'm trying to recall why I check for the checkbox's visibility
> (indirectly through showaddgroup's) before checking its checked state.
> Is there any way the checkbox can be checked and hidden?

It is never checked before it is hidden. And it is never unhidden. So...

> The comment after |else if (gFld_URL.value)| seems rather odd, just drop it.

Actually that was moved from line 251.

    
    

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

    
    

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

    
    

    
  
You're right, starting with it showing probably fixes the xbl binding thing.

I know the comment was moved, it just seems odd there, since the comment says do
nothing followed by us doing something. The comment is technically correct since
it speaks about the else case for that if-else-if, but I think it would be more
confusing to leave it there than to just remove it at this point.

sr=jag with the comment removed.

    
    

    
  


  

        Attachment #100873 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 102568 [details] [diff] [review]
Removed comment as requested

a=asa for checkin to 1.2beta (on behalf of drivers)

        Attachment #102568 -
        Flags: superreview+

        Attachment #102568 -
        Flags: review+

        Attachment #102568 -
        Flags: approval+

    
    

    
  
fix checked in


    
    

    
  
Still not working in one (bizarre) specific case.

1. Run Mozilla.
2. Open a new tab (so you now have two).
3. Go to Bookmarks -> File Bookmarks...

The dialog will always be too small, cutting off the OK and Cancel buttons.  It
does NOT do this when only one tab is open (there, it works properly).

    
    

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

    
    

    
  
Re: Comment 46 - that's bug 146859.  Sorry for the SPAM.

    
    

    
  
Really marking fixed as per comment 45.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
This still happens, although very subtly.

It happens about one or two pels at a time with each open.

Try it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
I can confirm this behavior, but it may be a different bug than this one.
I'm on Win2k 2003012607 and each time I open Bookmarks -> File Bookmark, the
resulting dialog is one pixel larger horizontally each time.

    
    

    
  
Confirm #51 with
Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.3b) Gecko/20030125
Window is getting larger at the right side.
I also confirm #50
My "File Bookmarks"-Window normally opens in the same size as the last time
(+1px on the right side), but very seldom it opens with quite another size.

    
    

    
  
Must be a layout bug - if you compare the height and width attributes with the
actual height and width computed by layout you'll see that the heights agree but
the widths don't.

    
    

    
  


  

    
    

    
  
Comment on attachment 112871 [details]
Test case for sizeToContent bug

To demonstrate the bug, turn on dump (if you don't already have it on), open
the JS console, evaluate
openDialog('http://bugzilla.mozilla.org/attachment.cgi?id=112871', '_blank',
'chrome,all,dialog=no') and look at the dump output. On Windows and Linux I see
a width of 257 but both height and width should be 256.

    
    

    
  
Here's your problem:

http://lxr.mozilla.org/seamonkey/source/content/base/src/nsDocumentViewer.cpp#27
09

nsDocumentViewer has a +1 fudge factor.

    
    

    
  
Reresolving; the new problem is caused by a bad fix to bug 68352 and/or others.

    
    

    
  
Really resolving :-/
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED

    
    

    
  
*** Bug 193009 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey

    
    

    
  
VERIFIED Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091019
Status: RESOLVED → VERIFIED
Target Milestone: Future → ---

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: