Open Bug 418864 Opened 17 years ago Updated 2 years ago

Star panel is not resizable

Categories

(Firefox :: Bookmarks & History, defect, P5)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect

Tracking

()

Milestone:
Future
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: jamesrome, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(4 files)

Picture of the menu
(deleted), image/png
Details
Added resizer element at the bottom of bookmarksPanel.xul
(deleted), application/vnd.mozilla.xul+xml
Details
txt version of previous file
(deleted), text/plain
Details
(bug 418864) prototype for add bookmark editor resizer button to browser.xul
(deleted), text/x-review-board-request
Details 
I am running FF 3.0 Beta3 on Leopard.

When I want to add a new bookmark
1) The window is not resizable. This makes it really hard to scroll through a long list of folders. It was resizable in 2.0
2) It is impossible to create a new folder for the new bookmark! Why?

This almost makes bookmarks unusable.
Issue 2 is Bug 394252.
Attached image Picture of the menu (deleted) — 
No resize handle, and no add folder
Component: Bookmarks → Places
QA Contact: bookmarks → places
Summary: Add bookmark not resizeable, and no new folder → Add bookmark not resizeable
Target Milestone: Firefox 3 beta3 → ---
OS: Mac OS X → All
Hardware: PC → All
Version: unspecified → Trunk
Needs to be resizable, always open expanded, and select last folder bookmarks where saved into. 

And Cancel/Done buttons are backwards,  Cancel buttons go on the right per normal gui applications.
This really should block the release of 3.0. Makes bookmarks unusable if you have a lot of them.
Severity: normal → major
Target Milestone: --- → Firefox 3
Flags: blocking-firefox3?
(In reply to comment #4)
> Needs to be resizable, 

Can <panel>s be resized? Hm. Anyway, that's what this is about, and it's not a blocker.

> always open expanded, 

This would be a separate bug. Might already be on file. I disagree that it should always open expanded, but we might want to remember the last state. I don't know though, because ...

> and select last folder bookmarks where saved into. 

This is always shown, along with the most recently used target folders, in the drop down beneath a separator after the "Choose..." entry.

> And Cancel/Done buttons are backwards,  Cancel buttons go on the right per
> normal gui applications.

This is fixed.
Flags: blocking-firefox3? → blocking-firefox3-
Its not fixed in beta 5. In FireFox 2, you could resize the add bookmark panel. In FF3, you cannot. This makes about 8 lines viewable, and it is very hard to navigate things. Sure panels can be resized.
Have you tried the mac version to test this?
The problem is there should be a resizer at the bottom of panel so that it can be resizable, this addition should fix the problem.
Attached file txt version of previous file (deleted) — 
Previous attachment could not be seen on firefox because it is a xul file so I am sending txt file
(In reply to comment #14)
> Created an attachment (id=316006) [details]
> txt version of previous file
> 
> Previous attachment could not be seen on firefox because it is a xul file so I
> am sending txt file
> 

Sorry, you changed the bookmarks tree shown in the sidebar. The "Add bookmark" panel is <panel id="editBookmarkPanel"> at
http://mxr.mozilla.org/firefox/source/browser/base/content/browser.xul#105, the content is overlaid from
http://mxr.mozilla.org/firefox/source/browser/components/places/content/editBookmarkOverlay.xul#52

And you should create your attachment as a patch using diff...
Sorry to have missed the Duplicate, Marco. But it is really, really NASTY to use the current editBookMarkPanel, at it's fixed size, on a "big" screen. (Mine is 1920x1200.) I'm voting for this bug.
This bug is still there in Firefox 3 RC1 on MacOS X, and it's very annoying with my long list of bookmark folders.
Even if the new look has been made to imitate the dark OSX panels like Quicklook, this does not mean it should not be resizable: even Quicklook panels are resizable after all.
And even worse, the panel is transparent and dark which makes it really hard to see. There is absolutely NO advantage to transparency here, and it makes it hard to read. At the very least, this needs to be a defeatable option. This is a step backwards.
Is it reasonable to assume that this bug "not resizable" also covers "not movable"? 
Probably not. I would like them to be movable too, but on a Mac, menus seem to "pop up" from the App's title bar. So not sure if it can be changed. But I do agree that a floating window would be better.
(In reply to comment #13)
> Created an attachment (id=316001) [details]
> Added resizer element at the bottom of bookmarksPanel.xul
> 
> The problem is there should be a resizer at the bottom of panel so that it can
> be resizable, this addition should fix the problem.
> 

So how do we get this added into the distribution? Or can we patch our versions with this code?
(In reply to comment #21)
> Is it reasonable to assume that this bug "not resizable" also covers "not
> movable"? 

No, IMHO.
That the panel is not movable looks fine, if you think that it should appear
like "hanging"/coming out from the star in the location field - although I
admit, on MacOS X, I did not realize this until I saw some Windows screenshots;
I thought the panel was just accidentally "appearing in a strange place at the
top right".
Note for end users with big screens: You can at least force the tiny panel to pop up a taller, bigger "tree display" when you click the "show all the bookmarks folders" icon by adding this to userChrome.css:

/* 
 * FF3.0, CREATE TALLER DISPLAY OF FOLDER TREE FROM 'BOOKMARK THIS PAGE' POP-UP
 */

#editBMPanel_folderTree
{
min-width:400px !important;
min-height:500px !important;
}

And Marco, thanks for describing the desing decision behind location of the pop-up-- that makes good sense.
Another workaround, widening the initial pop-up to create room for longer bookmark names and more tags (without even pressing the button to expand the tag area):

#editBookmarkPanelContent
{
min-width:600px !important;
}

This isn't a major loss of function. Resetting severity back to normal.

(In reply to comment #11)
> Can <panel>s be resized? Hm.

Neil, could you give a comment here?
Severity: major → normal
Target Milestone: Firefox 3 → ---
Unbelievable Comment! Sorry, but this IS a "major loss of function". 

For everyone who uses more than 6 bookmarks (which is probably anyone on earth) this bug makes Firefox 3 the worst browser in the market.

As James Rome said: This almost makes bookmarks unusable.

Setting the bug fix status to normal means that you havn't understood the severety of this bug.

This bug is TOP PRIORITY. Until this bug exists Firefox 3 doesn't exist for me as a "heavy bookmark user"...



(In reply to comment #29)
> This isn't a major loss of function. Resetting severity back to normal.


And this should be really easy to fix.

The hint in #2-26 works, so it should at least be an option
This is only a workaround. At least we should try to fix the widget code instead of doing that for an instance only. Until this isn't fixed you can safely place your mentioned code into your %profile%/chrome/userChrome.css. This will fix the issue locally for the current profile.

userChrome.css:
===============

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* set default namespace to XUL */
                                                                
/* Taller bookmarks folder tree */
#editBMPanel_folderTree                                                                                                 
{                                                                                                                       
  min-width: 400px !important;
  min-height: 500px !important;
}
Summary: Add bookmark not resizeable → Bookmark contextual dialog is not resizable
It should work to put a <resizer> in the panel, or if not, fix nsResizerFrame to do this. A related fix was needed to make <titlebar> work in panels in bug 377663.



I don't even understand why a window that displays content that doesn't completely fit inside itself would be set as "not resizeable"?

I know the UI in Windows regularly does this, they seem to like their users to use tiny views and poke at scrollbars horizontally and vertically. I might have seen it in MacOS, I'm not sure, haven't used it in a while.

In the Unix desktops it's exceedingly rare. Should the worst usability examples out there really be copied ?
(In reply to comment #31)
> And this should be really easy to fix.
> The hint in #25-26 works, so it should at least be an option....

It only a workaround, creating a more adequate FIXED size for the panel. The panel REALLY, REALLY needs resize-ability, but I didn't know how to do that. (I'm not much of a coder, and it took me a long time to figure out the workarounds which I did use.)

Of course, new users from IE, bloggers and columnists reviewing FF3.x on the web, and *regular* users aren't going to log into bugzilla AND find this bug AND add userchrome. Thanks, Henrik and Neil, for coming on board with thse UI complaints.

 


Hi, this problem annoys me too. I do agree that a resizer handle needs to be add and also allow the dialog as moveable. A workaround solution or extension shouldn't be require to fix this issue.

Some additional comments here..
1) when I expand the Tag dropdown list, I'd like to see the tags side-by-side (i.e. dynamically add more columns depending on the dialog's width after resizing it) instead of seeing one single column of tags in one long list.

2) add the option to "remember" the size and position of bookmark dialog after resizing it. It's a good idea to add an option to reset the size & position somewhere in the Preferences panel in situation when we open our portable browser on another computer with smaller monitor or at a different resolution.

Joerg Gastmann (#30) is correct that this problem should be fix asap.
(In reply to comment #36)
> 1) when I expand the Tag dropdown list, I'd like to see the tags side-by-side
> (i.e. dynamically add more columns depending on the dialog's width after
> resizing it) instead of seeing one single column of tags in one long list.

This should be in a separate bug.


Hey in connection to this one, maybe some of you would find this bug created by me interesting: Bug 434359 (CTRL+D "Page Bookmarked" Add Bookmark Dialog can't be repositioned/moved/dragged around)
Hi, I've found a workaround. Add the code to Stylish:

Edit Bookmark Dialog : Tags in line
http://userstyles.org/styles/10353#review-7623


(In reply to comment #37)
> (In reply to comment #36)
> > 1) when I expand the Tag dropdown list, I'd like to see the tags side-by-side
> > (i.e. dynamically add more columns depending on the dialog's width after
> > resizing it) instead of seeing one single column of tags in one long list.
> 
> This should be in a separate bug.
Stylish hangs my Firefox 3 every time when I go into its preferences and click Advancd. So this is no solution.
You can put the code in userChrome.css instead of using Stylish.  Or you can work with np to figure out why Stylish hangs for you ;)
I'd just like to point out that for accessibility reasons this is quite a severe issue.

Anyone who is hard of seeing and has the desktop font on a larger dpi than the default will have significant problems navigating their bookmarks.

I've tested this on twice the dpi of ubuntu's regular desktop, and it then can only fit something like 3-folders in the Folders list which makes it pretty ridiculous to use.
Alex, something for your polish list?
The way the contextual dialog is docked to the star icon makes resizing kind of problematic.  I wonder if we could place the resize widget on the bottom left corner, so that the user could still make the dialog wider and taller, but it would still be able to be docked to the star icon.  Kind of an unusual interaction.  Placing the control on the bottom left side might work if we still had a visual cue to associate the dialog with the star (bug 462650).
I agree that having a dialog dock to the star icon is an unusual interaction.

I think it's a poor design not to provide the user an option to *undock* and revert things back to the way it was before in older Firefox version.

If Mozilla would like us to know about the icon, they could have done it by using non-intrusive method instead of forcing us to put up with this new feature.
This is possibly the single most annoying "enhancement" in Firefox 3.  

Why would you want to stop me from resizing this window?  It is a major
detriment to browser usability.

People are discussing this mis-feature in forums and blogs:
http://www.thedreaming.org/2008/06/18/things-i-hate-about-firefox-3-and-how-to-fix-them/
http://anotherlab.rajapet.net/2008/06/resizing-bookmark-this-page-dialog-in.html
http://episteme.arstechnica.com/eve/forums/a/tpc/f/99609816/m/718006882931/p/5
http://forums.mozillazine.org/viewtopic.php?f=8&t=679275
etc.

Please fix.
I think everyone is in agreement that we need to get around to making the panel resizable, so no need to provide extensive supporting evidence :)

The one stipulation though is that the panel still needs to remain visually associated with the star (since it is click outside to close to streamline the interaction, and the user needs to understand how to get the interface back).  In the case of bug 462650 we are adding the planned half diamond arrow pointing to the star.

So if we add the resize widget to the bottom left, as is standard, the half diamond image would need to stay in position as the panel resizes.
"we are adding the planned half diamond arrow pointing to the star."

Thanks, but I have no idea what this is talking about.

"So if we add the resize widget to the bottom left, as is standard"

I don't think I've ever seen a resizing control on the bottom left.  If resizing is limited to only a single corner (which it shouldn't be), that corner is normally the bottom right.

What was wrong with the old design, anyway?
>I don't think I've ever seen a resizing control on the bottom left.

yeah, I meant right, I'm in need of more caffeine and sleep.  For the details on the half diamond thing just check out the attachments in the bug: 

https://bugzilla.mozilla.org/attachment.cgi?id=345976

>What was wrong with the old design, anyway?

we wanted to make bookmarking as fast as possible, this isn't necessarily something that people who spend a lot of time bookmarking are interested in, but we wanted to make bookmarking more approachable for the majority of users who don't bother to bookmark pages.  So to this end we created the star icon that fills out when you click it, and doesn't show you any additional UI.  If you click it again you can make minor changes, like changing the title, and then click anywhere outside of the panel to dismiss it (which is a lot faster than trying to target a small ok button).

The previous dialog implied that you had to fill out all of the information, which made bookmarking a long and burdensome process.  Also there wasn't a target that is visually associated with the previous interface, you had to remember the keyboard shortcut, or dig through the menus to bookmark a page.
There's another problem here: We should enforce a sensible minimum size for the panel, and that probably needs bug 357725. Otherwise you'd be able to make the panel vanish by resizing it to 0x0.
>There's another problem here: We should enforce a sensible minimum size for the
>panel

Yeah, we probably want to make that the same as the default size
One other item on the resizable dialog, its user set size must be persistent within FireFox sessions and between FireFox sessions. Meaning the user selection of dialog size must be saved somewhere and either read on startup or read on dialog access. It would be a pain to have to resize it every time you open the dialog or every time you restart FireFox.
Amen to comment #58 from David. 
Additionally, it should not be regarded as sufficient that the dialog box be resizable. It must also be movable!
I surely agree about the movable part. Even if it violates (for example) Apple OS X guidelines. Lots of times in Mozilla apps, the box pops up covering the information I need to enter into it!

For me, the whole new bookmark dialog is a step backwards. It is harder to read, harder to use, ugly.
Marco: given the code reuse in bug 459958, could we potentially display a traditional dialog when the user selects the "Bookmark this page" menu command, or hits control-d without introducing too much additional code complexity?

Some of the design decisions of the current interface are based on the user's hand starting on the mouse, and a desire to quickly bookmark a page, that don't really mesh well with the minority use case concerns being voiced above.

Everyone else: we are already very aware of the specific reasons some people find the current interface inferior to the previous one, so there is really no reason to reiterate them in the bug comments.
What about; click on the star to instant-bookmark the page, click the star again to bring up an edit/remove bookmark dialog (a real dialog)?  Is there any reason why the "Edit This Bookmark" panel has to be glued to the bottom of the star?  Why does the user click once outside the panel to make it disappear?  Why is this behavior desirable?

If we need to keep this behavior, how about something like this; click the star to make the "panel" appear, and the panel has a blue-background strip across the top with "Edit This Bookmark" written in it.  The panel is attached to the star, and clicks outside the panel will close it (assumedly this close behavior is the same as clicking "done"?).  But if the user clicks and drags inside the blue strip, the panel is detached from the star, and then doesn't close when you click outside it, effectively becoming a dialog, with a resize handle in the bottom right.

Then the user could move the panel out of the way to read the title of the page they're bookmarking, so they could type it into the "Name", or they could even scroll around on the page they're trying to bookmark without the panel vanishing mysteriously.  We could add an option to about:config, if we want to get fancy, that makes it detached by default for those who prefer the dialog.  Ideally, of course, we'd want to change that blue strip to be some arbitrary background/foreground color, based on the OS theme.

And finally; the comment from Alex (#62) seems to suggest that the new star panel is only disfavored by a small minority.  Do we have any numbers to back this up?  There's obviously a vocal group who dislikes it.  Is there a larger vocal group somewhere that likes it?  Are we beating ourselves up here trying to make this star panel feature work when no one wants it?
(In reply to comment #62)
> Marco: given the code reuse in bug 459958, could we potentially display a
> traditional dialog when the user selects the "Bookmark this page" menu command,
> or hits control-d without introducing too much additional code complexity?

i guess so, should not be a big problem, hwv we also have the issue with clicking the "bookmarks" menu on start executes the first option (Bookmark this page) so that would practically open a modal window then.
Bookmark THIS page is binded to the star, and personally i think the association between the choice and the star is cleaner as it is and helps explaining what is the star for, and why it's there.
Imho we should fix <resizer> to work on <panel>and remember the panel size, as originally requested... Hwv if UX team thinks it would be better discarding all and going back to a classic dialog, it should not be a problem.
Clearly there are some issues to be sorted out with how best to organize bookmarks. For example, whether or not users prefer tags or folders or both, and resizing panels etc (it might be better for those preferring to folders to use the 'organize bookmarks' window).

*** Wouldn't it be an easy solution to this bug, just to make the size of the 'choose folder' window that appears a bit more dynamic? I.E. it currently displays a minimum of 8 folders, but if users have more than 8 root folders, make it bigger, expanding up to a more reasonable size (maybe calculated somehow by the available window space)?
(In reply to comment #65)
> *** Wouldn't it be an easy solution to this bug, just to make the size of the
> 'choose folder' window that appears a bit more dynamic?...

So if I've got 300 bookmarks in three branches I get to play around in only 3 lines? I don't think that will catch on.

Why not just let the user decide and allow him to re-size the window as he sees fit - as it was - please! 

Is it so difficult to understand - the client is always right!
>Is it so difficult to understand - the client is always right!

Not to be overly flippant, but it turns out that our hundreds of millions of users are not all of one mind when it comes to the interface they want for bookmarking (in terms of the default).  However, letting the user resize and having that value stick obviously makes a lot of sense.
Hey Alex,

Good thinking here. My suggestion is to keep the traditional bookmark dialog (with all info pre-filled) and by default, will be place into the "Unsorted Bookmarks" folder.

Add a ticker at bottom of dialog to enable/disable the star icon for quick bookmarking. In addition, can assign a shortcut key (i.e. F2) if user don't wish to see the dialog when bookmarking. Hit the same key twice to bring up the dialog for editing (exact same behaviour as using the star icon).

To let user know about the shortcut key, it can be shown in the alert if user wish to enable quick bookmarking. The alert will contain the link to help on how to use the star icon and to also display the shortcut key. This "extra" dialog won't be so much of an issue because user don't usually change their preference often.

HTH

(In reply to comment #55)
> >I don't think I've ever seen a resizing control on the bottom left.
> 
> yeah, I meant right, I'm in need of more caffeine and sleep.  For the details
> on the half diamond thing just check out the attachments in the bug: 
> 
> https://bugzilla.mozilla.org/attachment.cgi?id=345976
> 
> >What was wrong with the old design, anyway?
> 
> we wanted to make bookmarking as fast as possible, this isn't necessarily
> something that people who spend a lot of time bookmarking are interested in,
> but we wanted to make bookmarking more approachable for the majority of users
> who don't bother to bookmark pages.  So to this end we created the star icon
> that fills out when you click it, and doesn't show you any additional UI.  If
> you click it again you can make minor changes, like changing the title, and
> then click anywhere outside of the panel to dismiss it (which is a lot faster
> than trying to target a small ok button).
> 
> The previous dialog implied that you had to fill out all of the information,
> which made bookmarking a long and burdensome process.  Also there wasn't a
> target that is visually associated with the previous interface, you had to
> remember the keyboard shortcut, or dig through the menus to bookmark a page.
Well, I guess we don't have to worry about this bug anymore: chuonthis has updated the OpenBook extension for Firefox 3. The resizing control is on the bottom left, and it allows a vertical stretch of the Add Bookmarks window.

As usual, an extension writer leads the way. 

At least those of us who want the feature can get it now.
>As usual, an extension writer leads the way.

That's because there are more extension writers than Firefox developers, and they can do things like break compatibility with other extensions late in the game, while we can't.

Anyway, no need to confuse lack of resources with a lack of motivation.
Thanks for these words - you're perfectly right! The clients/users are always right! Any other way to deal with bugs will lead to a well deserved death for every product. What a shame if Firefox will die because of the ignorance of developers who created a new problem that made Firefox impractical for ALL professional/heavy users.

I have to keep working with Microsoft IE as long as this bug is not fixed.

And please: No developer should even think about any new handling ideas (e.g. new short cuts / key combinations).

The success formula for Firefox and any kind of open software can only be the KISS concept. Keep It Simple and Stupid.

So can anyone please fix this bug?



(In reply to comment #66)
> (In reply to comment #65)
> > *** Wouldn't it be an easy solution to this bug, just to make the size of the
> > 'choose folder' window that appears a bit more dynamic?...
> 
> So if I've got 300 bookmarks in three branches I get to play around in only 3
> lines? I don't think that will catch on.
> 
> Why not just let the user decide and allow him to re-size the window as he sees
> fit - as it was - please! 
> 
> Is it so difficult to understand - the client is always right!
Over a year to make a simple dialog box at least resizable ? :-((
Where's your patch to fix it then?  Bugzilla is for developers to do work not for nagging.  There are bigger fish to fry than this.
I don't call myself a Mozilla developer.
I'm just a user spending my free time to improve a product I like to use to see requests being ignored over issues which shouldn't have been there in the first place.
If indeed bugzilla is developer only, then I suppose you are one. This is a fix a freshman does eyes closed.
well, the fix is suggested above -- editing userChrome.css. But no one but this buglist knows about it, and this is too hard for the usual person.

It certainly affects usability of Firefox, and hence its acceptance in the marketplace. At the very minimum, make the default bigger!
Brian Polidoro: I am officially charging you with incompetence--you and anyone else who thinks that either this is a non-issue or that basic features common to all modern Graphical User Interface environments are the domain of user-based add-ons. 

This is not a 1988 MS-DOS program. If we were talking in the year 1990 and this was an early Windows 3.0 program, I could countenance this deficiency, but this is 2009 and all programs in all visual environments have the ability to move and resize windows--all except the "Bookmark This Page" window in FF3. Even within FF3, if I go to the "Downloads" window (Ctrl+J), the window is movable and resizable; if I go to the "Error Console" (Ctrl+Shift+J), the window is movable and resizable; if I go to the "Organize Bookmarks" window (Ctrl+Shift+B), the window is movable and resizable. The "Bookmark This Page" window was movable & resizable in FF2 and every earlier version. This bug is nearly singular in the entire computing world. It is absurd beyond belief. 

This window is used by massive numbers of users on a daily basis. It is a foundational feature of any internet browser, not some peripheral program capability. I am a dedicated Open Source software user with a special hatred for Microsoft, but even I am tempted to return to IE by this bug. 

When people leave Microsoft IE to try Firefox for the first time, I can scarcely believe that they are not significantly and negatively impressed by this bug. It is heinously obnoxious. It simply HAS to be warding people off of switching to Firefox from IE. As Mozilla FF is one of the most visible and widely used Open Source programs in use today, this is a black mark right on the face of the entire Open Source community. Mozilla's inability to match Microsoft in this most basic regard of making the bookmarking window movable and resizable is analogous to a normal, healthy athlete losing at the Special Olympics. 

The mere fact that this should need to be explained to you (or to anyone for that matter) proves incompetence on your part. If you can't understand it after reading this, you should seriously consider putting yourself to sleep like an animal. 

"There are bigger fish to fry than this," you say? Here's the reality: 

Mozilla's first priority in fixing bugs is to fix any security vulnerabilities that crop up, so that people's computers don't get compromised. After that, this bug is priority number 2. The only other bug in this program that could even be fathomed to compete for priority are the massive memory leaks in FF3 that eat up all our RAM as we run the program throughout the day, but frankly, even that takes a back-seat to this. 

If you are so threatened by people posting about this bug that you need to retort with insults about nagging, then you need to reign in your ego. You're insulting yourself. You're not being nagged. You're being called back to reality. Just do the right thing and fix this bug so that 20% of the internet browsing community can rejoin the modern world.
Alright, I don't think there's any need to start slinging words like "incompetence".  This particular bug gets under my skin too, but let's all take a deep breath here and remember that there are real people on the other side of the screen.

That said, if you search bugzilla for open Firefox bugs, and rank by number of votes, you get 4724 bugs, of which only 31 have more votes than this one.  So yes, there are bigger fish to fry, but there aren't very many.  (Obviously votes aren't the only criteria.)
Hey guys,

Anyone commenting here should probably read the bugzilla etiquette page:
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Ye have been warned.  If it happens again, you bugzilla account will be disabled.

While this may be a very important bug to you, please remember that there are other bugs that are more important than this.  Right now there are over 1400 open bugs just relating to bookmarks, history, and the location bar.

Let's keep it calm in here please, and unless you have something new to add to this (and it's not "this bothers me too"), please do not comment and simply vote for the bug.
Please just roll the dialog back to the old design, unless there was some massive change to the underpinnings.
Everyone here vote for this bug!
Responding to the call to vote I checked my vote on this issue and found out that I had already voted for my initial bug report on this issue. However my vote was not transferred to this bug ID when my bug report was marked as a duplicate of this bug! 

Can anyone consolidate the vote for all the duplicates - and there must be a bunch - onto this ID? 

Everyone else - please vote for _this_ bug ID!
Reiterating Shawn's comments, increased chatter on the bug doesn't really help anyone. It slows developers down who are reading the comments (we are well aware that people want this changed), and it doesn't provide any new information (we are well aware that people want this changed).

Regarding the question of why it has been a year and this bug hasn't been fixed yet, the best place for prioritization debates is mozilla.dev.apps.firefox, since otherwise every individual bug would contain a "hey, this is really important" series of comments, instead of looking at the relative prioritization from a broader perspective in a higher level forum.
and btw b4 will have a small enhancement, the panel enlarges when you open the folder picker.
patch in bug 357725 should allow panels resizing
Depends on: 357725
Can't believe it takes so long to make a window resizable.
Yes I agree it's taking a while. Unfortunately, the latest beta v3.5 is still showing no sign of improvement on this area.

At present, I'm using the OpenBook extension to get around this.

Unless someone else have better suggestion, why don't we try Mozilla's feedback form at http://hendrix.mozilla.org and report this bug. We can only hope that they'll do something about it before the next major release.
GUI should be 'elastic'

Follow the lead of the GreaseMonkey UserScript manager
Depends on: 511011
Yeah, I vote for this feature since I have been waiting for this feature. I would like Firefox to remember the size too.
will be done when dependancies are fixed, we actually lack platform support to do that properly, and hacking out a workaround would only be bad.
Targeting this for the set of changes scoped for 3.7, with the following suggested modifications to the UI:

-Bookmarks contextual dialog picks up a small control to detach it in the upper right hand corner
-Once detached:
--The panel turns into an actual window which is non modal but will stay on top, and is re-sizeable
--The window has an inverse control that will reattach it to the star
--The window picks up the description field (as well as keyword and load in sidebar behind a progressive disclosure control that holds state)
--The folder and tags areas are automatically expanded (first detach, later they hold state)
--The window and panel maintain attached or detached state, so the next time a bookmark is created (accelerator-D or click on star), the correct UI will display for the user

Marco: since we are using a window, we can drop the dependencies on bug 357725 and bug 511011, right?
Blocks: 523519
Summary: Bookmark contextual dialog is not resizable → Places UI (3.7): Bookmark contextual dialog should be detachable and then re-sizable
Target Milestone: --- → Firefox 3.7
Summary: Places UI (3.7): Bookmark contextual dialog should be detachable and then re-sizable → Bookmark contextual dialog is not resizable
Disregard morph (just trying to keep people in the loop and figured expanding scope wouldn't be controversial), recommend wontfix in favor of new bug 524071
No longer blocks: 523519
I should note that I'm not particularly against the panel itself being re-sizable, for the set of users who actually want to resize but not detach, but that would of course block on the underlying platform issues (which for those curious, is I believe why this is taking so long).
>recommend wontfix in favor of new bug 524071

that is assuming we pick up panel resizing over there, otherwise obviously need to keep this open
I reopened bug 490445 for the default width being too narrow.
Just as an OT heads up:
Daniel Glazman reported success with resizable panels on trunk/3.7, although not using the <resizer> yet.
http://www.glazman.org/weblog/dotclear/index.php?post/2009/10/15/Resizable-popups-and-panels-in-Firefox-37
(In reply to comment #96)
> Just as an OT heads up:
> Daniel Glazman reported success with resizable panels on trunk/3.7, although
> not using the <resizer> yet.
> http://www.glazman.org/weblog/dotclear/index.php?post/2009/10/15/Resizable-popups-and-panels-in-Firefox-37

i saw that, that's what i was thinking when i said that we don't want to "hack a workaround".
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
I just upgraded to 3.6 from 2 and this bug (lack of resizable bookmarks popup window panel) still exists. As a heavy user of bookmarks, the previous advanced features of FF's bookmarks manager were what kept me using FF (since the first Netscape version). Can this simple request, which obviously many users want,not be developed in?
Firefox has had this horrendous, unusable, bookmarking dialog for TWO YEARS. But hey, we have themes now. Mighty useful.
Please -- Pretty Please -- at least give us the option of expanding the list vertically so we can see at least a reasonable part of our bookmark tree. Right now it is like trying to view your bookmark folders through the eye of a needle.

While we're on mozilla - Can we encourage some of the tbird theme developers to update a few themes? Firefox is fine on themes, tbird is down to stems & seeds :p
I am uninstalling 3.6.X FF because of this bug. The OpenBook extension handled this problem but is no longer usable with 3.6.X. I will continue using 3.5.X until this bug is fixed, or until 3.5.x is no longer supported, in which case I will be forced to begin searching for a usable browser.

I also intend to comment extensively about this bug in multiple locations on the internet to raise user awareness of this problem and the fact that no action has been forthcoming from Mozilla for over 2 years.
(In reply to comment #106)
> I also intend to comment extensively about this bug in multiple locations on
> the internet to raise user awareness of this problem and the fact that no
> action has been forthcoming from Mozilla for over 2 years.

Quite right, they are simply not listening to the users. 

THE CUSTOMER IS ALWAYS RIGHT!!!
I understand that when a bug gets past 100 comments it is hard to go back and track exactly what is going on, so here is a quick summary:

1) resizing the bookmarks interface is blocked on the ability to have the platform literally resize panel style windows

2) Neil is currently working on this, in addition to a number of other platform level changes to panel windows: https://wiki.mozilla.org/XUL:Panel_Improvements

3) Once the platform supports it, we'll get the interface modified to be resizeable
Why do we have to use panel-style windows? They obscure the things that I am trying to bookmark! The window should be floating. Why not?
It would be a simple change that could be revisited when you get resizing of panels to work.
Please transfer the votes from all the bugs that are closed as duplicates, across to this bug.  You will get many, many more than 34....
(In reply to comment #113)
> Please transfer the votes from all the bugs that are closed as duplicates,
> across to this bug.  You will get many, many more than 34....

Yeah, except that votes don't mean much for the severity of a bug (only a very specific group of users know and use them, so the sample is too biased to be meaningful, sorry).

If you really need a bigger folder list put this in your userchrome.css:
#editBMPanel_folderTree
{
  min-height:500px !important;
}
Such workaround is unacceptable from the usability point of view.

For me as professional software developer is really intriguing how hard it can be to make a window resizeable in Firefox, specially since before 3.x series it used to work.

It is not like you don't have other windows in the same browser with resize functionality.
If Firefox 4.0 does not have this, I am going to be disappointing. I have so many bookmarks that the small window to add bookmarks in is very frustrating. I always tell myself, "v4 is coming soon...".
After more than 2 ½ years this major bug is still not fixed. Surprised? No! The usual lack of leadership within OpenSource projects. No focus on the important stuff (fixing ergonomic failures). You guys need a dictator like Steve Jobs. Democracy just don't works. Churchill's camel analogy comes to mind: "A camel is a horse designed by a committee." Or brushed up: "A Firefox is a web browser designed by a community."
A reply that it's not an important issue, because not many people use bookmarks... I can't believe it. Who doesn't use bookmarks? Noobs? For the first 2 days, until they learn to press CTRL+D.

This ergonomic problem is so "unimportant" that even if duplicates are constantly removed, it gets regularly reported again. Here's the latest search:

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=bookmar+window+resizable
Noticed that "Target Milestone = Firefox 4.0" so I just downloaded 4.0 beta 6 to try out.  What do you know, the dialog is *still* not resizable on there.
Hi everyone.  I'd like to point out that the vast majority of the recent comments are in violation of bugzilla etiquette (specifically, section 1.1):
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Please refrain from continued violations of bugzilla etiquette.  Thank you.
blocking2.0: --- → -
Target Milestone: Firefox 4.0 → Future
I gave up on Firefox's bookmarks since the window became impossible to resize, and I only use delicious.com now.
Everybody who wants this fixed should just edit userChrome.css It is a nice fix. Finally after 2 years! This workaround should be more prominent here. Search for userChrome.css here with Ctrl+F then go to http://www.gemal.dk/mozilla/profile.html, then http://www.mozilla.org/unix/customizing.html. On Win7 x64 go to the Roaming folder under AppData. This folder is hidden by default. Make sure you are able to see hidden folders by setting up your Folder Options in order to see it.
I agree that this should have been fixed long ago but I found a simple solution. I'm using Firefox 3.5.13 with the OpenBook 2.0.1.1 add on. 

chet
Not that simple. OpenBook 2.0.1.1 was last updated two years ago. See - https://addons.mozilla.org/en-US/firefox/addon/42/versions/ and is not available for Firefox 3.6.12.
can I just point everyone back to comment #108 again: https://bugzilla.mozilla.org/show_bug.cgi?id=418864#c108

It has taken a while to get this implemented, yes, but it *is* being worked on
Why not just pop it up as a separate window? Then we could see what the page says to fill in the bookmark information properly.
(In reply to comment #124)
> Not that simple. OpenBook 2.0.1.1 was last updated two years ago. See -
> https://addons.mozilla.org/en-US/firefox/addon/42/versions/ and is not
> available for Firefox 3.6.12.

I understand but sometimes you have to downgrade when the upgrade loses previous functions you need. I was happy using Firefox 2.+ until just a few months back. I've been using PCs on a regular basis since '92 (and have been using Mozilla since Netscape 1) and my experience is that about 50% of the time an "upgrade" loses some previous feature or function that I relied on. So I am very slow to upgrade to the latest version of any software. I tried 3.6 but, finding the OpenBook add on was not working, I went down to 3.5.13 solely for the purpose of being able to use OpenBook so I can see several bookmark folders in the dialog window. I'm sure that there are many, many Firefox fans like me and those commenting here that use Firefox bookmarks much more than apparently the developers of recent upgrades who don't understand such use or don't rely on huge numbers of bookmarks and bookmark folders. So, downgrading works for me.
Please stop this bug spam, please please follow bugzilla etiquette:

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

There are 10s of thousands of bugs, all with various levels of impacts and various levels of priority, these are not ordered by time but by priority, workload, risk, cost etc... for the developers. I have seen bugs which lead developers think is important to fix take over 10 years, that's just reality.

In the mean time this is not a forum for rantings, workarounds or any opinions or superfluous information. If you want this fixed fast then I would suggest 1 of 2 things:

1) Fix it yourself, it's open source
2) Find a quiet day on an IRC chat room and find a developer amenable to some rational arguments about polish and usability

I've had a number of personally invested bugs I've wanted fixing and I've found developers far more willing to listen to rational benefits and improvements at little cost vs. insulting Mozilla's workflow.
Listing workarounds is absolutely necessary in this forum.
I believe, that with Firefox 3.6, the menu is no longer resizable, ignoring all the hints given it.  I'm still still working on proving that.  But all the workarounds I've found don't work.  Listing the workarounds gives me hints as to where to look though.

With Firefox version 3.6, the menu now changes width to PARTIALLY compensate for wide data.  The data is still clipped because there is still not enough room.  This seems to be on purpose, since it seems to be trying unsuccessfully to display "unique prefixes" instead of the whole string, even when there is plenty of room.

Moreover, when you scroll in FF 3.6 (or the 4.x I've tried), with tags of varying lengths in the expanded tags view, the menu re-sizes (changes width) for each and every wheel mouse event.  On Linux and on MacOSX, this apparently results in the window disappearing for an event cycle before the new window appears, and I think that is what results in the window often disappearing COMPLETELY when scrolling: the mouse event outside the window boundary closes the window:  no window, no boundary.  I'm including this in this bug because I feel the whole thing is very painfully wrong.
Why is it so hard to fix this? Making something resizeable seems trivial to do.
And on a Mac, bookmarks are unusable. Forget the %^&*( Apple Guidelines, and pop up a separate window like you do in Windows. That works. The windows attached to the title bar prevent a user from seeing what it is he wants to bookmark!
Problem is that someone made the "Edit This Bookmark" window self-resizing in 3.6.1 or so, and it makes itself as small as possible (apparently ignoring min-width !important hints).  No-one is assigned to the bug, so it doesn't get "fixed" again.

Me?  I find the tiny window feature quite excruciatingly painful on a daily basis, so I'm minded to try to fix it myself (though the mozilla source currently boggles my mind).  So I need help.  

Can someone help me find the source to the widget that does this automatic resizing?  Its apparently the same widget on both linux and macosx.  I'm slowly figuring this out myself, but you'd speed it up by helping.
(In reply to comment #132)

> Can someone help me find the source to the widget that does this automatic
> resizing?  Its apparently the same widget on both linux and macosx.  I'm slowly
> figuring this out myself, but you'd speed it up by helping.

The bookmark panel code is located at:
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.xul#176

The panel needs to have a resizer placed in it and the contents adjusted in some way such that the resizing works as expected.
(In reply to comment #133)
> (In reply to comment #132)
> The panel needs to have a resizer placed in it and the contents adjusted in
> some way such that the resizing works as expected.

Last time I checked (early december) adding a bottom-left resizer to a top-right attached panel (with a min-width) was still broken.
One of my plans is to make it so that the automatic resizing pays attention to ALL the values in the scrollable region, not just the currently visible ones.  And that truncation of the values displayed doesn't take place unless its up against a max-width. 

I'm more concerned with permanent changes to the min-width than temporary ones, though I'll try to pay attention to wish lists as I learn to grok xul code.
I am using the OpenBook extension 2.0.1.1. I can resize my addBookmarks window. It is not current, but changing the maxversion makes it usable.

I am no longer suggesting that one use this as a workaround, but looking at it can give you ideas on how to code your own workaround.
Just in case I get run over by a bus: the xmarks plugin sometimes has suggested tags in this window, which changes (increased) the min-width.
I can't believe it. Just installed an uninstalled Firefox 4.0 - the bug ist still there! Why can't this problem be solved? Why can't the feature be included that worked so fine until Firefox 2.0.0.20?
The OpenBook extension is no longer working (or working properly if forced install) so I went and found a new workaround.

Download the appropriate one for your Firefox version:
https://addons.mozilla.org/en-us/firefox/addon/add-bookmark-here-2/versions/

Set your preference via the ABH2 interface and if you'd like to change the bookmark width/height, simply locate abhere2.js and change the value (i.e. abhere2.starUI.width to 750)

Locate file at path something like this:
Firefox\Data\profile\extensions\abhere2@moztw.org\defaults\preferences

In the meantime, we're going to have to continue relying on workaround until developer address this issue.
(In reply to comment #114)
> If you really need a bigger folder list put this in your userchrome.css:
> #editBMPanel_folderTree
> {
>   min-height:500px !important;
> }

Can also add #editBMPanel_tagsSelector for the tag list too.
Scratch the userchrome.css as everything is controllable in abhere2.js
Where is abhere2.js?

But nonetheless, this bug should be a stopper for Firefox 4.0. The average user can't edit files, and the default window is unusable.
Everyone should please vote for this bug.
There is something odd about the number of votes for the annoying bug - there are only 34 votes cast!? By the number of annoyed comments, it surely must be much higher. All interested parties are thus requested to check that their votes are on the record to get this shameful bug finally fixed.
(In reply to comment #145)
> There is something odd about the number of votes for the annoying bug - there
> are only 34 votes cast!? By the number of annoyed comments, it surely must be
> much higher. All interested parties are thus requested to check that their
> votes are on the record to get this shameful bug finally fixed.

Let me assure you that voting doesn't change the priority of a bug, at best it plays a small role in the big picture. And endless commenting - reiterating known opinions - only helps to annoy other people on the project.

If it's such a big group who really needs this changed (in light of the existence of the mentioned add-ons and workarounds), there should be someone in it who can just attach a patch and flag it for review. That's how things roll in open source.

And please don't see this as an invitation for another discussion - no more noise is needed here, period. Just attach a patch with the fix.
Margret and Frank: this is a very old and often requested improvement to our bookmarking interface that required that we first implement re-sizable arrowpanels.  Would be a high value fix (albeit for a smallish subset of users), and would also help us test out how well resizable arrowpanels work ahead of using them for things like a more transient download manager UI.

Platform support: https://bugzilla.mozilla.org/show_bug.cgi?id=511180
Documentation: https://developer.mozilla.org/en/XUL/resizer
To me, the problem is not so much that its not resizable, but that it decides to make itself too small to use effectively.  In my case, I use bookmark tags extensively.  When XMARKS has tags to suggest, it puts them in that window, often causing it to expand its width, *sometimes* making it *USABLY* wide.  When you start editing tags, and your tags are long, then it *PARTIALLY* widens to almost, but not quite compensate.  That it doesn't permit draggable resizing on the fly is just bonus badness.

The problem is also that its a windows style window (one of the things keeping me from *EVER* using windows).  Tiny, unmovable, and non-resizable.  The *KEY* problem is that someone out there thought this was a good idea on UNIX.  Its a popup that does not play by the UNIX (Linux, MacOSX, etc) rules.  Its not a real window.  Its tiny.  It can't be moved.  It can't be resized.  It goes away on the slightest provocation, making otherwise reversible changed permanent.  And so is quite extremely maddening.

While this new popup style is flashy, its a regression from past usability.  Whoever did it needs to be in this conversation, since whoever they are keeps making the dialog less and less usable over the past 2-3 years.
(In reply to comment #145)
> There is something odd about the number of votes for the annoying bug - there
> are only 34 votes cast!? By the number of annoyed comments, it surely must be
> much higher. All interested parties are thus requested to check that their
> votes are on the record to get this shameful bug finally fixed.

This is probably because the counter-intuitive old-school Bugzilla interface doesn't register your vote when you click "vote". It rather takes you to the list of bugs you voted for. There, you have to check a checkbox next to this bug, then click "Change My Votes". From a UX designer perspective, this flow is rather stupid, I believe.
Depends on: 652115
I just installed Firefox 5 on a machine and am surprised/dismayed to find that the bookmark window issue is still not fixed.  This seems like such a simple thing to fix and such an obvious flaw.  ON my Firefox 3 installation I used the fix described in Comment 25 that works great, but of course only let's you pre-select one larger size.  Has anyone tried this fix on Firefox 5?
I took the trouble to count the votes for the duplicates and it came to 32. So there are actually 40 + 32 = 72 votes for this annoying bug which is now three and a half years old. Does that merit upping the priority?

PS If you use the number of people on the CC list - 66 - that would make it 98 interested parties...
(In reply to comment #148)
> To me, the problem is not so much that its not resizable, but that it
> decides to make itself too small to use effectively.  In my case, I use
> bookmark tags extensively....

Perry, the workaround (comment 25 with comment 26, use BOTH) should be a solution for "too small" portion of the problem. Although it still remains fixed size, and unmovable.
------
And for eberger (comment 151): Yes, it still works.
I was woken up because "Bug 357725 - Top-level XUL windows should support size constraints" was added.  Since ff14 breaks my "I use it continuously" extension (Tagsieve), it may be some time before I stop using ff13.

(In reply to Rick Stockton from comment #153)
> (In reply to comment #148)
> > To me, the problem is not so much that its not resizable, but that it
> > decides to make itself too small to use effectively.  In my case, I use
> > bookmark tags extensively....
> 
> Perry, the workaround (comment 25 with comment 26, use BOTH) should be a
> solution for "too small" portion of the problem. Although it still remains
> fixed size, and unmovable.


Rick, I remember trying something like that, but not succeeding.  In the meantime, I've been using my own modification of editbookmarkplus (https://addons.mozilla.org/en-us/firefox/addon/edit-bookmark-plus/) to automatically display as many tags as possible (he uses folders, so he ignores tags, I concentrate on tags).  It tends to keep track of the size of the widget (forgetting now about it when restarting the main window).  I haven't gotten around to adding back the longer-term persistence. 

The apparent fix may obsolete part of editbookmarkplus.
The priorities of the Firefox team are incredible. If so many people needs it and the fix is so simple, why not make it? They added themes, which must had taken lots of time, they are cool, but didn't increase usability. Why not invest 5 hours in making the GUI much better? Is it just laziness or plain stupidity?
"Top-level XUL windows should support size constraints"

What does that mean? Usually there is plenty of room on a screen. If there is a problem, Fx can observe the size of the screen and trim the box accordingly.
(In reply to Zex from comment #155)
> The priorities of the Firefox team are incredible. If so many people needs
> it and the fix is so simple, why not make it? They added themes, which must
> had taken lots of time, they are cool, but didn't increase usability. Why
> not invest 5 hours in making the GUI much better? Is it just laziness or
> plain stupidity?

I think it's just that they don't give a toss about users.
(In reply to johnmuir from comment #157)
> I think it's just that they don't give a toss about users.

The reason is that Mozilla is not working in the free market economy. They don't need to care about their product and their users because the money is rolling in anyway. But this will soon be over since Chrome became the leader in the browser wars. It's just a question of time until Google drops their multi-million dollar support for Mozilla. I don't like Chrome, but Firefox gets worse with every new version (loss of status bar, images centered on black background, background tabs not anymore loaded after restart, unwanted new features instead fixing old and important bugs, version number silliness). It sucks. This ages old unsolved "Bookmark contextual dialog is not resizable" is just one annoyance and sign of the un-professionalism of Mozilla.
(In reply to rotis from comment #158)
> (In reply to johnmuir from comment #157)
> > I think it's just that they don't give a toss about users.
> 
> The reason is that Mozilla is not working in the free market economy. They
> don't need to care about their product and their users because the money is
> rolling in anyway. But this will soon be over since Chrome became the leader
> in the browser wars. It's just a question of time until Google drops their
> multi-million dollar support for Mozilla. I don't like Chrome, but Firefox
> gets worse with every new version (loss of status bar, images centered on
> black background, background tabs not anymore loaded after restart, unwanted
> new features instead fixing old and important bugs, version number
> silliness). It sucks. This ages old unsolved "Bookmark contextual dialog is
> not resizable" is just one annoyance and sign of the un-professionalism of
> Mozilla.

This is all off-topic and not really a good discussion for here but... Firefox is open source. You know you could always implement the change yourself and then submit that code for approval by Mozilla. If you (or someone you know) can actually fix this problem, have them create the code/patch and submit it here and chances are Mozilla will accept it.
Just a little note/reminder that this bug depends on this bug [https://bugzilla.mozilla.org/show_bug.cgi?id=652115] which seems to be getting little attention and chat on which has gone cold. Devs it would be awesome if you could have a look if you have time (assuming you haven't done so); users, it might be worth subscribing (though not just to vent, haha)
I have a plugin that permits resizing this window.  Its not currently certified because its original author has gone missing (website gone, doesn't respond to email, etc).  What would be the obstacles to my just applying the part that resizes the window to the firefox master branch (modulo getting it okayed, etc)?
Try the Edit Bookmark Plus extension.
I have a modification to Edit-Bookmark-Plus that lets the region for tags resize.  He received it several months ago, but disappeared before committing it.  It does several things, but I'm just concerned about the ability to resize that window, which I claim is a major reason causing people to not use tags.  Developers notice this lack-of-use and eliminate important features for tags, which is a negative feedback loop.

I'm trying now to push back against the 8-year trend (group think, no one person) to deprecate bookmark tags.  They aren't ideal in their present form, but they are better than nothing.  I think I know now how to actually make them useful to a reasonable number of people, and so I'm looking to clean up some of the long standing bugs so we can see how people use them when they are actually usable, and attract people wanting to use tags instead of folders back to firefox.
(In reply to Perry Wagle from comment #162)
> I have a plugin that permits resizing this window.  Its not currently
> certified because its original author has gone missing (website gone,
> doesn't respond to email, etc).  What would be the obstacles to my just
> applying the part that resizes the window to the firefox master branch
> (modulo getting it okayed, etc)?

you can try posting a patch and asking for review, but note there is already a patch in bug 652115, but it has some defects as stated in https://bugzilla.mozilla.org/show_bug.cgi?id=652115#c4 and https://bugzilla.mozilla.org/show_bug.cgi?id=652115#c8
More specifically, we should set min-width on the buttons, have a min/max-width on the panel, figure out the arrow flicker. Then either the panel is only allowed to grow/shrink horizontally (I didn't find a way years ago, may now it's possible?), otherwise if it can also grow vertically, we need a strategy to fill up the available space, for example if the tags picker or the folder picker are open, they should grow. If they are closed we should snap back the panel height to the contents height.
And then there is RTL to handle.
These are not trivial tasks if you don't have good xul knowledge.
Okay, I'm going to now isolate the part of Edit-Bookmark-Plus that resizes the edit bookmark window here in this bug (asking an occasional question maybe) and when I finish, I will see what it takes to modify the source directly instead of extending it, in that bug there.

Sound like a plan?
Yes, provided the plan is not hoping I can find the time to take an half-made patch and fix it by myself :) I can't make that promise at this time.
Nono.  I'm just breaking this up into small enough steps that I can do them myself.
I'm finally well enough to make some progress.

I whittled everything out of my version of edit-bookmarks-plus except the parts that handled resizing the bookmark editor popup.  It's still legacy Xul overlay, but I think its as simple as a prototype can get.  Works fine on MacOS, but the borders bounce around a bit while dragging the resizer element on Linux; is that the flicker you are talking about?

Given that its a legacy Xul overlay, it still needs to be vetted as a prototype for *me* to finish off I think by either patching it into Firefox proper, making it into a WebExtension (?), or something else I didn't think of.

At this point, I'm interested in seeing what criticisms of my prototype there are, polish it, then port it to modern Firefox technology when some consensus seems to be formed as to which direction to port it.

The source is at:

    https://github.com/wagle/resize-bookmarks-editor

which has you create xpi's using grunt.  What should I used instead for packaging legacy extensions?
I've been advised to directly modify Firefox source, so I'll do that.
Should I be assigned to this bug?
If it's useful for your tracking purposes you can assign to this bug (or I can do that).
I don't see how to set "assigned".  I suspect I don't have the permissions.
There is an edit bug button at the top, and then an assignee field becomes visible.
Assignee: nobody → wagle
Thanks!  Already found the Edit button, but no means of editing the field was apparent.  Oh well.
Works now though.
I have a lot of it now working in pure XUL overlay (browser.xul and editBookmarkOverlay.xul) I can't get the resizer to pack the descendants of the bookmark popdown correctly.  The listboxes etc can get truncated when squeezed width wise.  The classic fix was to set min-width on the panel to 30.75em, which seems kinda brittle to me.

Given that things are moving from XUL to XHTML, should I bother fixing the packer, or just leave the 30.75em hack?
Oki.  I have an alpha version that needs polish, but it generally works.  Before polishing, I'd like to know where it is on the "completely boneheaded" to "just right" scale, so I don't waste time polishing junk.

What form do you want my patch in?  A full fledged MozReview?
mozreview wfm.
Also, please use needinfo when you have questions, since it's sometimes easy to lose them in the middle of hundreds other bugmails.
I'm looking for reviewers for https://reviewboard.mozilla.org/r/121128/ (hmm, see comment 180 which is hidden?)

I now seem to lack the permissions to set status to set NEEDINFO, so don't know if its got an anyone value.
Everyone votes for mak as reviewer
Flags: needinfo?(mak)
Does mak == mak77?  we shall find out
Flags: needinfo?(mak77)
Comment on attachment 8848178 [details]
(bug 418864) prototype for add bookmark editor resizer button to browser.xul

Just need someone to take quick glance to say whether my solution is in the right ballpark, and/or what I'm missing.  I think it basically works now, but there are still a few quirks to comb out.  I'm also learning bugzilla, so sorry for the spam.
Flags: needinfo?(mak)
Attachment #8848178 - Flags: feedback?(mak77)
I'm currently abroad and may have to delay this until next week, since my agenda for this week is pretty much full.
Flags: needinfo?(mak77)
Comment on attachment 8848178 [details]
(bug 418864) prototype for add bookmark editor resizer button to browser.xul

https://reviewboard.mozilla.org/r/121128/#review126342

Unfortunately this is very bogus. I tested it on Win10 so far.
The resizer is shown on the wrong side of the panel, it's shown bottom-right, but the panel enlarges bottom-left.
On resizing, the arrow at the top of the panel jumps left and right like crazy, and as a consequence the right border flickers. This may need platform help.
Folder and Tags picker should open automatically when there's "enough" free space, otherwise we end up with a giant panel containing nothing more than 3 input fields. For this you need to listen to the resize and figure out a strategy to tell when there's enough space to uncollapse them. Or alternatively, you should figure out a way to only allow to resize the panel horizontally when the pickers are closed, while allowing diagonal resize when any of them is open. This would also allow to have a polished enough UI.
I tried resizing the panel in the default condition (folder and tags picker closed) and the only thing I obtained is increased space between the input fields (I can attach sshot if you wish), that looks quite bad, input fields should stay packed at the top, not float around.

::: browser/app/profile/firefox.js:930
(Diff revision 1)
>  
> +// see mozilla-central/browser/app/profile/firefox.js
> +pref("browser.bookmarks.editDialog.toggleCollapsedFolderTree", true);
> +pref("browser.bookmarks.editDialog.toggleCollapsedTagsSelector", true);
> +pref("browser.bookmarks.editDialog.width", "0");
> +pref("browser.bookmarks.editDialog.height", "0");

To store the previous state of a UI component you should use xulstore, not a pref, since this is not something for the user, it's just to retain previous state of a UI piece. That's what xulstore (once called localstore.rdf) is for.

::: browser/components/places/content/editBookmarkOverlay.js:22
(Diff revision 1)
>    _observersAdded: false,
>    _staticFoldersListBuilt: false,
> -
>    _paneInfo: null,
> +
> +  handlePopupShowing: function (evt) {

editBookmarkOverlay is a reusable component that is also used in the library and in properties dialogs (edit properties of a bookmark from the context menu)

As such, it should not handle any details about a popup, since it could even not be in a popup at all.
If you need to handle popup events for the star panel, your code should be in browser-places.js

::: browser/components/places/content/editBookmarkOverlay.xul:16
(Diff revision 1)
>  <?xml-stylesheet href="chrome://browser/skin/places/places.css"?>
>  
>  <overlay id="editBookmarkOverlay"
>           xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
>  
> -  <vbox id="editBookmarkPanelContent" flex="1">
> +  <vbox id="editBookmarkPanelContent" style="min-width: 32em" height="" flex="1">

I understand this is proof of concepts, just want to clarify we don't use inline styles in the ui.
Attachment #8848178 - Flags: feedback?(mak77)
The resizing works fine (ie, smoothly) on MacOS, but it looks like you got past that problem.  I did as much as I could in XUL, and it looks to me like resizing is broken in XUL for MacOS.  How should I handle that bug?  Are there any XUL gurus left?

The rest of the problems seem to be of the "you did this wrong" type, as expected.  So I'll get to work doing it the right way.

Are there build farms for Windows and Linux?  I can build for Linux, maybe not Windows though.  What other platforms should I try?

Having the resizer work right while the expandables are both closed was a problem that I was waiting to try to fight XUL for a fix.  I have some ideas now.
(In reply to Perry Wagle from comment #187)
> The resizing works fine (ie, smoothly) on MacOS, but it looks like you got
> past that problem.  I did as much as I could in XUL, and it looks to me like
> resizing is broken in XUL for MacOS.  How should I handle that bug?  Are
> there any XUL gurus left?

resizing is partially broken, but maybe you can have a look at my old example in bug 652115. IIRC that was going towards the right direction. Also https://bugzilla.mozilla.org/show_bug.cgi?id=652115#c6.

> Are there build farms for Windows and Linux?  I can build for Linux, maybe
> not Windows though.  What other platforms should I try?

Windows, MacOS and linux at a minimum. But you should first of all have a perfectly working implementation on your OS. The TryServer can generate builds if you have the first commit privilege.
Actually, resizing doesn't flitter around on MacOS.  Maybe Linux and Windows though.

What are you using as a Windows build environment?
If the RESIZER function in XUL is broken, do I fix XUL?  Or given that XUL will go away at some point, should I do it some new way?

I got a windows build environment to work in a virtualbox instance.  Resizing wobbles a bit while dragging.  Going back to the MacOS edition, I find that I was ignoring the wobbling, since I generally resize once per run of firefox.

I'm not sure that the wobbling is so bad.  Agree?  Disagree?  Is fixing it (ie, XUL) this bug, or another bug?
As an end-user who has been waiting for this a long, long time, it's the resizability that matters.
I'd rather have a resizable box that wobbles a bit when I resize it, than a fixed-size box.
If the cause of that wobble lies deep within XUL, it's a separate XUL bug, (which you could raise, and save any information you have discovered there, for another time).
Are you able to save the size of the resized box in end-user preferences/state (with sensible bounds-checking in case it gets corrupted)?  This way the user may not even need to resize the next time, it becomes almost a one-time-wobble.
(In reply to Perry Wagle from comment #190)
> If the RESIZER function in XUL is broken, do I fix XUL?  Or given that XUL
> will go away at some point, should I do it some new way?

fixing xul would be fine. Xul is not going away anytime soon from the core of Firefox.

> I'm not sure that the wobbling is so bad.  Agree?  Disagree?  Is fixing it
> (ie, XUL) this bug, or another bug?

It looks really bad. This is not something we could enable for all the users with this quality, at a maximum it could be enabled behind a pref, but at least it should visually look correct. Having the resizer on the wrong side of the panel, and inverted, is not acceptable. As well as having the fields that on resize float free in the panel, is not something we could take.
If you are unable to get a resizing function working, just make the window higher at all times with no resizing function. The result is the same.
Given that the list of bookmarks window is already higher, this one can be made higher as well.
Resizing works fine, just that its wobbly (a bug is XUL, I think), and whatever the window/panel packer does is bizarre and pretty much undocumented online.  Bought two books which might explain it better, which I'm doing now.

Question of the day is: with quantum/flow coming, is my work here for naught?  Should I concentrate on flow, or stay with whatever name "mozilla-central" has?
Sorry for the delay.  Chemo threw me for a loop.  I've also been stumped as to what to do about XUL.  Is there a replacement yet, or do I just try more things?
no replacement for XUL atm, experimentation is in progress but it will require time.
Summary: Bookmark contextual dialog is not resizable → Star UI dialog is not resizable
Summary: Star UI dialog is not resizable → Star panel is not resizable
I'm trying to do bookmark editing now as a webextension (modulo missing features, like access to tags), and will not continue my mortal combat with XUL.  I currently can list all bookmarks in a fast (15000+ bookmarks) scrollable region on the sidebar.

Should I unassign myself from this bug, or somehow merge my webextension when/if it works as a complete replacement?
Flags: needinfo?(mak77)
(In reply to Perry Wagle from comment #201)
> Should I unassign myself from this bug, or somehow merge my webextension
> when/if it works as a complete replacement?

I'm happy to see your extension being released and used, and then we could surely check the traction it will get among our users.
It's unlikely we can just merge a WebExtension, since there are a lot of UX questions and problems that must be handled by our UX team first. Also Mozilla's Test Pilot extensions are usually not merged as-is, but they are used to better design the final feature.
I don't see a strict reason why you should stay assigned to this bug, that for now it's unlikely to move on.
Flags: needinfo?(mak77)
Priority: -- → P5

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: wagle → nobody
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 30 duplicates, 47 votes and 73 CCs.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(mak)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: