Resizing add Bookmarks with tree view open begins to expand empty portion of dialog

RESOLVED FIXED in Firefox1.0beta

Status

()

defect
P3
trivial
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: lindyboi, Assigned: mconnor)

Tracking

({fixed-aviary1.0})

unspecified
Firefox1.0beta
Points:
---
Bug Flags:
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Resizing the "Add Bookmarks" dialog to see the full tree only works correctly
when growing the widnow up to 25 displayed lines of the tree. After that point,
both the tree pane and the space immediately above it seem to grow equally,
making poor use of screen real estate.

Reproducible: Always
Steps to Reproduce:
1. Press ^-d
2. Click on down arrow "Show all the bookmarks folders"
3. Resize the window to the full scren size

Actual Results:  
The tree table size was the only one that changed until 25 rows of bookmarks
were shown, and then a blank part of the window began to expand as well.

Expected Results:  
Only the tree table pane should expand, because that's the only one that adds
information.

If I didn't have many nested bookmarks folders this probably wouldn't be very
annnoying.

Comment 2

15 years ago
Yep same here and I can't find a duplicate. It's a trivial fix, just remove
flex="1" from the grid element in addBookmark2.xul, since that part shouldn't
stretch.

Comment 3

15 years ago
I see this also on Windows 2000, OS should be changed to ALL.

Updated

15 years ago
Flags: blocking0.9?

Comment 4

15 years ago
Confirming
Severity: normal → trivial
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All

Comment 5

15 years ago
It appears that mconnor wants to take this bug. So we'll let him have it. :)
Assignee: p_ch → mconnor
(Assignee)

Comment 6

15 years ago
not a blocker for 0.9
Status: NEW → ASSIGNED
Flags: blocking0.9? → blocking0.9-
Priority: -- → P3
Target Milestone: --- → Firefox1.0beta

Updated

15 years ago
Flags: blocking1.0?
Flags: blocking1.0? → blocking1.0+
*** Bug 242851 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 8

15 years ago

Comment 9

15 years ago
simple patch is ready. blocking0.9?
Do you need review for this, Mike?
Flags: blocking0.9- → blocking0.9?
(Assignee)

Comment 10

15 years ago
not really, no.  its still not a blocker, but I'll land it if I get a chance to.
Flags: blocking0.9?

Comment 11

15 years ago
*** Bug 247380 has been marked as a duplicate of this bug. ***
It's not a blocker, but it's esthetically awful. Hope it will be patched one day ;)
(Assignee)

Comment 13

15 years ago
fixed branch and trunk
Whiteboard: fixed-aviary1.0
(Assignee)

Updated

15 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 14

15 years ago
i still experience the same thing on 0.9.2
Update to the latest nigthly. I'm using 20040712 Firefox/0.9.1+ and it is indeed
fixed. Thanks Mike Connor.

Comment 16

15 years ago
*** Bug 252820 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Keywords: fixed-aviary1.0
Whiteboard: fixed-aviary1.0
I upgraded from 0.9 to 0.9.3 and I see this still.

Comment 18

15 years ago
> I upgraded from 0.9 to 0.9.3 and I see this still.
Then upgrade to Firefox Preview Release:
http://www.mozilla.org/products/firefox/
(Assignee)

Comment 19

13 years ago
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
You need to log in before you can comment on or make changes to this bug.