83935 - Add/File/Manage bookmark should be fixed while bookmarks scroll

Status: NEW

(SeaMonkey :: Bookmarks & History, enhancement)

Description

[Mike Kowalski]

Whenever I open the bookmarks menu and I scroll all the way down to view my
bookmarks and then I close the menu, I have to scroll to the top the next time I
want to add a bookmark. I think only the bookmarks should scroll and at the top
Add Bookmark, Manage Bookmarks, and File Bookmark menuitems shouldn't scroll
with the menu.

Comment 1

[Brian 'netdragon' Bober]

We had a discussion about this in #mozillazine, and a question was asked about 
whether you could just close the menu and reopen it. It seems from my testing 
that the menu on the menu bar has memory (which is good - like ie) of where it 
was when reopened. But, I cannot figure out if the bookmark button on the pt 
bar has the same because it is horked on my build. Therefore I am getting a new 
build. 

I would like to comment on this bug, though. I think this is a very good idea. 
What he basically wants is for the items he listed not to scroll, and for the 
other items to scroll. Maybe IE shortcuts shouldn't scroll either.

I believe this is a good idea since it makes it so you don't have to either 
scroll up or close the menu (if that even works).

I talked to kowalski, and he is willing to try to fix this himself. All we need 
is for someone to check it in. 

Comment 2

[Mike Kowalski]

Netdemon is willing to take the bug, so I'm reassigning it to him.

Comment 3

[Brian 'netdragon' Bober]

Ben, this bug fix won't in any way interfere with anything you are doing, will 
it? Thanks.

Comment 4

[doctor__j]

Kinda like the Viewer Demos #11, #12.  That'd be cool...

Comment 5

[Brian 'netdragon' Bober]

Ben: I have no idea how to do this. Is there a possibility that you might be 
able to do this? It probably wouldn't take long if you know what you are doing. 
I do not have much experience with the bookmarks code.

Comment 6

[Mike Kowalski]

Reassigning to Pinkerton. He'll fix it.

Comment 7

[Mike Pinkerton (not reading bugmail)]

|----------------
|
|
|------------
|
|
|
| u t u r e

Comment 8

[Mike Jaques]

This bug irks me. The second I open my IE bookmarks which is large (and 
therefore needs scroll arrows at top and bottom) the menu closes focus goes 
back to the previous main bookmark menu. And the menu slides so the mouse 
pointer is over "Mozilla Project" and pops open its submenu too.  The main 
bookmarks window shouldnt take scroll arrows unless it needs them, not just 
cause a child menu needs scroll arrows.

Future is a bad thing for this,   Most people have large IE Favorite lists, and 
lets face it, how many people organize it into folders nicely to keep from 
scrolling.  I think this should be marked as a Moz1.0 blocker as its very 
visible UI "flaw" in my eyes.

Comment 9

[Mike Jaques]

Oh sorry for the spam, but I forgot to mention, the scroll arrows atm persist 
until you open a new browser window, which is a work-around, till I want to 
look at my IE faves again. very annoying.

Comment 10

[Mike Jaques]

Attachment: before

Comment 11

[Mike Jaques]

Attachment: after

Comment 12

[R.K.Aa.]

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

Comment 13

[Claudius Gayle]

borrowing summary from dupe

Comment 14

[David Hallowell]

This also applies to a long 'Tasks' menu. If you have loads of Windows open then
you want the default items fixed and the list of open windows scrollable.

Comment 15

[:deanis74]

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

Comment 16

[R.K.Aa.]

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

Comment 17

[Chris Lyon]

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

Comment 18

[R.K.Aa.]

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

Comment 19

[Daniel Wang]

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

Comment 20

[R.K.Aa.]

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

Comment 21

[Jason Pell]

Hi,

This was marked as a future enhancement over two years ago, I would appreciate
an indication of when it might be looked at.

At the very least, could someone indicate whether this is a C++ / JavaScript /
XUL fix.

Thanks
Jason

Comment 22

[Jason Pell]

Attachment: Example IE favourites - how mozilla should work

The favourites menu in IE works in the way that Mozilla should.

Comment 23

[Alex Hirzel]

Jason: this would be an XUL thing -- i'll play around with it, and then i'll see
if i can get a review for it.

Comment 24

[Jason Pell]

Hi,

Since I would like to have a go at fixing myself, could someone please indicate
whereabouts in the chrome directory I would find the XUL / JS to play around with.

Are the arrows at the top and botton of the bookmarks menu generic for Menu
popups, or specific to Bookmarks?

If its generic, then the code to change would be in the Popup Menu or Menu
widget area - could someone indicate where I might find it.

I do not have a lot of experience with Mozilla code base, but as long as it does
not extend to C++, I will give it a go.

Thanks
Jason

Comment 25

[Alex Hirzel]

Going on the little XUL I have coded in, it'd be in one of the main Mozilla
interface files -- go into the IRC channels to ask which one -- but it should be
as simple as moving one line of code (the scrollarea start tag) and reindenting
everything else that was effected -- at least if I remember correctly :D

Comment 26

[timeless]

For my reference the macie i used on os9 behaves just like we do today.

Comment 27

[Brian 'netdragon' Bober]

Comment #25 - its not that simple or it would have been done already. I gave
this a look over a couple years back and saw that as far as I can tell, because
it involves bindings and whatnot. But since my knowledge is in the C++, I am not
exactly sure. If you need any C++ rewritten, I can do that.

If I can remember what the issue was, I believe it was that you can't have a
scrolling popup menu section and a nonscrolling one as part of the same popup
menu, but it was so long ago I can't remember.

BenGoodger would probably be the one to ask if he's still around.

Comment 28

[Brian 'netdragon' Bober]

If anyone does find out, please put a comment in the bug saying what needs to be
done. All too often, people find out information and just keep it to themselves
because they are planning to fix it, but never do so then we are back at square one.

Comment 29

[Alex Hirzel]

Comment #27:  If it doesn't work (for whatever reason), it may merit a bug 
report of it's own :-/

Comment 30

[Brian 'netdragon' Bober]

Definately, because Mozilla is supposed to be a toolkit for other applications. 


<offtopic> Its just like you can't click on menu entries that also open cascaded
menus. There might be such an entry you'd also like to be able to click on too.
I brought that up when we were talking about the "File > New" submenu. Clicking
on "File > New" would be a nice shortcut for "File > New > Navigator Window".
Such abilities should be possible within the browser and even if we can get
along without it, such picky things might be annoying to other people using the
toolkit. 

One thing I'm going to tackle very soon is making text selectable within Alert()
boxes for javascript. A probably small fix that will have significant uses for
debugging </offtopic>

Comment 31

[Alex Hirzel]

<offtopic>
Comment #30:  I have never tried it, but I think it would be possible to click
the  File -> New menu item and have a new browser window open up by simply
adding an onclick event handler and filling in the appropriate JavaScript --
call me a newbie -- but I think that would work :-/
</offtopic>

Comment 32

[Brian 'netdragon' Bober]

Maybe, but a couple years ago jst or someone told me it wouldn't work. That
means they could have put a condition where the event is ignored. Anyway, let's
not take this offtopic conversation too far because its irrelevant and will
start to bother people. I was just providing another example of the kinds of
things you'd have to file against the toolkit :-)

Comment 33

[Bogdan Stroe]

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

Comment 34

[Martijn Wargers (dead)]

I guess bug 169837 is the Firefox counterpart of this bug.

Comment 35

[Martijn Wargers (dead)]

Attachment: Seamonkey patch

Well, this is the seamonkey patch, it is more or less based on the patch for
bug 169837. I only have tested this on windows.

Comment 36

[Frank Wein [:mcsmurf]]

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

Comment 37

[Martijn Wargers (dead)]

Comment on attachment 162045 [details] [diff] [review]
Seamonkey patch

This is not good (enough).
See bug 169837, comment 9 and further.

Comment 38

[Phoenix]

Still valid RFE