Closed Bug 146859 Opened 22 years ago Closed 21 years ago

File Bookmarks (CTRL+SHIFT+D) default vertical size is too small

Categories

(SeaMonkey :: Bookmarks & History, defect, P3)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4beta

People

(Reporter: Peter, Assigned: janv)

References

Details

(Whiteboard: [adt2])

Attachments

(3 files)

Example with redesigned File Bookmarks dialog
1.84 KB, image/png
Details
current screen shot
27.83 KB, image/jpeg
Details
Screenshot of how it SHOULD look like
8.73 KB, image/png
Details 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020518

File Bookmarks (CTRL+SHIFT+D) default vertical size is too small

Subject says all. 

This bug is a "spinoff" from bug 99860. The following comment from bug 99860
comment #57 prooves that this bug is *not* a duplicate of that bug: "This patch
doesn't fix the size problem of the 'File Bookmark' dialog. That is a separate
issue and should not be handled here."
Blocks: RememberPosition
Keywords: mozilla1.0, ui
did you read  bug 99860 comment #55 ?
Yes I did, but I didn't consider it explicit enough. I just want to keep one
issue per bug; and bug 99860 is trying to do too much. That bug can depend on
this bug.
I have to assume you did not in fact read that comment....
Status: UNCONFIRMED → NEW
Depends on: 123207
Ever confirmed: true
I did read it, but perhaps I didn't understand it. To me, "I got the height
property" doesn't necessarily have to mean "the default vertical size is now fixed".
*** Bug 146990 has been marked as a duplicate of this bug. ***
OS -> all
OS: Windows 98 → All
See also bug 152727 which I just filed. Even worse case of this, but only can
happen once per Mozilla run.
Keywords: mozilla1.0
Keywords: mozilla1.0.1, mozilla1.1, nsbeta1, nsbranch
Nav triage team: nsbeta1-.  Let's address this in the next release.
Keywords: nsbeta1 → nsbeta1-
I don't mean to be disrespectful (and I am no programmer), but doesn't fixing
this involve changing just *one* number in *one* line of code? (i.e., the
default vertical size in pixels)

Also, this bug is particularly nasty because of bug 145941.
I agree with comment #1, this is a separate issue from bug 99860. I was about to
file this myself but Peter for faster.

As to question of simplicity (comment #9): we cannot set explicit height for the
file bookmark window because the window is used in four different modes (modes
are listed in addBookmark.js).

I'll assign this to myself because I will try to fix this. I hope that Ben
doesn't mind.
Assignee: ben → Kalle.Valo
I had a typo in comment #10. I meant to say:

I agree with comment #0, this is a separate issue from bug 99860. I was about to
file this myself but Peter for faster.
Kalle: There is no "addBookmark.js" on my harddrive. Would you be so kind as to
say what the four modes are? (just out of curiosity) Thanks.
Perhaps this may help find the problem.  Under the Modern theme, I find that the
Bookmark -> File Bookmark... dialog comes up with insufficient height *if more
than one tab is active*.  If only one tab is active (and it doesn't matter if
the "Hide the tab bar when only one tab is open" preference is checked or not),
then the dialog can be resized, and the new size will persist.  If two or more
tabs are active, the dialog comes up too short and size changes will not persist.
Ack!  I spoke too soon.  It seems others already observed this phenomenon in bug
123207 comment 7 and bug 123207 comment 19.  What's more, the patch in
attachment 87507 [details] [diff] [review] from bug 123207 comment 21 fixes *this* bug for me.  After a
restart, the bookmark dialog comes up too small the first time, but size changes
persist after that regardless of how many tabs are open, and it works correctly
in the <default> and "New Bookmark" modes.  (I'm not sure how to test the other
two modes.)  There's still the cosmetic issue that the *first* time the dialog
comes up, it seems too small.
One last note...  My last comment applied to the MOZILLA_1_0_BRANCH.  On a June
19 pull of Seakmonkey, the patch only half works.  With two or more tabs open,
the dialog opens with its last size (rather than always opening too small) *but*
changes made to the size do not persist.  Changes made to size with one tab open
*do* persist.
On a June 27 pull of Seamonkey, the problem mentioned in comment 16 is resolved.
 However, I noticed that the patch broke bookmarking a group of tabs.  I'll
submit a fixed patch under bug 123207 that works with group bookmarking, too.
Nominating for buffy; good usability/polish fix.
Keywords: nsbeta1- → nsbeta1
*** Bug 157426 has been marked as a duplicate of this bug. ***
While I was trying to fix bug 99860 I took this screenshot. I was taken with a
new clean profile with default bookmarks. I had applied attachment 93758 [details] which
moves 'Use Default' and 'New Folder' buttons below of bookmarks tree. 

For some reason bookmarks tree just shows it's heading row but not the content
itself. After window is resized, tree's content is shown without problems. 

Because of bug 123207 this is a huge usability problem for people who are using
tabbed windows. They (myself included) have to resize File Bookmarks window
every time it's opened.
Keywords: mozilla1.1 → mozilla1.2
*** Bug 169234 has been marked as a duplicate of this bug. ***
*** Bug 171573 has been marked as a duplicate of this bug. ***
*** Bug 174267 has been marked as a duplicate of this bug. ***
Can't reproduce this anymore with 1.2b on Windows 2000. Now the dialog remembers
its size.
Seems to. The default size still needs to be increased, certainly.
Re comment #24:
That was bug 123207.
This bug is about the initial default dialog size, which is still too small.
Keywords: mozilla1.0.1 → mozilla1.3
Can't someone just fix this... it's been like this forever....
*** Bug 152727 has been marked as a duplicate of this bug. ***
I'm under the impression that now that (according to comments) the dialog
remembers its size some people think this bug is not important anymore. This is
not true! My window manager (Ion) does not let me resize the dialog because it
is what I think is called a "transient" in X11 terms and Ion creates transients
as sub-panes of the parent window without their own title bar (which is very
useful as it reduces screen clutter). So I'm stuck with the too small dialog
until someone finally checks in a (probably trivial) fix. To hell with not
harcoding sizes. Maybe this is not a pretty solution but this issue needs to be
fixed one way or another and an ugly temporary fix is better than none at all!

Can't someone at least post instructions here how to either hack the source code
or your preferences to get the dialog (the "Create in" part) larger?

Assigning bug back to the componen owner. I can't fix this.
Assignee: Kalle.Valo → ben
QA Contact: claudius → kasumi
Nav triage team: need info.  Kasumi, is this fixed now?
Whiteboard: [need info]
Nav triage team: need info.  Grace, is this fixed now?
QA Contact: kasumi → gbush
Attached image current screen shot — 
Hard to tell from comments what correct size should be- this is what today's
trunk build 'file bookmarks' looks like
I had problems before with this, but it seems fine now. 

One might argue that the treeview should be more than two lines high to be a bit
more usable, but that should probably be in another bug...
No, I filed *this* bug because the *initial* vertical size of the tree view
being (much) too small. The screenshot in comment #33 shows no improvement.
A minimum of 10 lines of directories are needed to be usable, IMO.
*** Bug 196458 has been marked as a duplicate of this bug. ***
Nav triage team: nsbeta1+/adt2
Assignee: ben → varga
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [need info] → [adt2]
Blocks: 196756
Priority: -- → P3
Target Milestone: --- → mozilla1.4alpha
1. This is not a PC-only issue, it also affects the Mac version of Mozilla.
Please change Hardware to All.
2. IMO, the default *horizontal* size is also too small. Ideally, the horizontal
width should automatically match the widest entry in the list.

Prog.
Keywords: mozilla1.2, mozilla1.3
Hardware: PC → All
Flags: blocking1.4a?
Flags: blocking1.4a? → blocking1.4a-
I'm still having a problem with the vertical height of the Move Bookmarks
dialogs under Windows XP. This causes a problem since I can't get focus on the
OK/cancel button. If I manually resize the height of this dialog, I can close it
by  clicking OK. This only happens with classic theme only.
Target Milestone: mozilla1.4alpha → mozilla1.4beta
I'm going to close this one. 
Post-branch file bookmark issues are being addresseded in bug 199524, bug
199520, bug 199915 and bug 199531.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
This bug is not a dupe of any of the others (none of them discuss the default 
vertical size of the File Bookmarks dialog).
It is definitely not fixed. I just tested the latest Win32 nightly (20030417) 
and this bug is still alive and kicking.

So... if it's not a dupe and it hasn't been fixed, why exactly is this bug 
closed?

Prog.
I closed this one because the original problem has beeen fixed by using the
|rows| attribute. As far I know there are still problems only on Win XP.

all platforms- 4/18
Status: RESOLVED → VERIFIED
This bug is present in:
Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8a) Gecko/20040430

It should be reopened.
I can't reproduce it on linux with new profile.

> I can't reproduce it on linux with new profile.

True. Ditto here (after copying my long list of bookmarks to the new profile).

However, there is a bug since the problem occurs with my old profile and Mozilla
doesn't provide a way to fix it (AFAIK).
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: