245163 - (ContextMenuOffScreen) Right-click context menu is cut off/disappearing/offscreen when it contains too many items (items added by extensions)

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Otana]

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

After installing several extensions that increased the length of the right click
menu for images, the menu has a tendency to disappear off the top of the page
when clicked in a certain place.  This can only be reproduced (to my knowledge)
when right-clicking an image.

Reproducible: Always
Steps to Reproduce:
1. Go to any webpage with an image link around the middle of the page.
2. Right-click.

Actual Results:  
When the image is in the top or bottom third of the page, the menu will adjust.
 If in the middle third, the top simply vanishes off the top of the screen.

Expected Results:  
I would have expected the menu to adjust and rather than beginning exactly where
the mouse pointer is, to move so that all menu choices are available.

With extensions such as AdBlock, Copy Image and Image Zoomer installed, the menu
has been lengthened considerably.  This occurs in several themes I have tried. 
I have a screenshot of the bug here:
http://img18.photobucket.com/albums/v54/Otana/menu_screenshot.png

Comment 1

[Mike Connor [:mconnor]]

basically the problem only occurs if your context menu height is more than half
of the total screen height.  Of course, based on the code we have, it should
give you scrollarrows at the top and bottom, which the extensions seem to be
interfering with somehow.

I would recommend disabling extensions one at a time until you can figure out
what is preventing the scrollboxes from appearing, but this doesn't appear to be
a Firefox bug.

Comment 2

[Simon Paquet [:sipaq]]

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

Comment 3

[Phil Ringnalda (:philor)]

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

Comment 4

[Phil Ringnalda (:philor)]

Attachment: Adds 40 useless items to context menu

Unless I'm being dense, our code to scroll the context menu isn't actually
working right. The attached extension just adds 40 items, copied from the best
and simplest code I could steal, and for me in Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0 while the selection
scrolls, only the bottom scroll-button appears: the top scroll-button and at
least one item appear off the top of the screen (I assume there's an item or
more up there, because scrolling with the arrow keys takes the selection
offscreen).

I actually tried three ways, this current

<popup id="contentAreaContextMenu">
  <menuitem id="contextbloat-1" label="&contextbloat-1.label;"
	    insertafter="context-bookmarklink"/>
  <menuitem id="contextbloat-2" label="&contextbloat-2.label;"
	    insertafter="context-bookmarklink"/>
  ...
</popup>

way, and also one <popup> per menu item, which does the same thing, and a
separate .xul for each menuitem, which results in absolutely no scrolling, just
cut off inaccessible items. I suppose for completeness I need to create 40
separate extensions that each add one item, and 20 that each add two items?

Comment 5

[Phil Ringnalda (:philor)]

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

Comment 6

[Simon Paquet [:sipaq]]

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

Comment 7

[Phil Ringnalda (:philor)]

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

Comment 8

[Dan Fischbach]

I voted for this bug, as it is annoying to get my cursor in the right position
to get to the item I want.  The context menu should have scrollability.  This is
useful for people with large fonts.

Note: should we let the context menu overlap the taskbar?

Comment 9

[Troodon]

Dupe of bug 255571?

Comment 10

[Simon Paquet [:sipaq]]

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

Comment 11

[Troodon]

I'm copying here bug 255571, comment 17 because I think it could be useful here:

I think there are two issues here:
1) The context menu is sometimes misplaced. This a both Seamonkey and Firefox
issue and bug 267821 is much more clear about it (see comments and attachments).

2) There isn't any mechanism for handling the context menu when it gets too big
to fit in the screen due to extensions, even if it's correctly placed. This is
mainly a Firefox issue (but can also happen in Seamonkey).

Thus, I think the best would be to use this bug for the second issue and mark it
as dependant of bug 267821 for the first issue.

The second issue it not a theme issue neither an extensions issue, but a Firefox
one, which is not well prepaired for handling expanded context menus.
A solution could be to group the items added by extensions inside an
"extensions" submenu when the number of added items is bigger than X (a number
which could be either resolution dependant, either choosed by the user - I
prefer the second way) AND show in the main context menu the last Y (choosed by
the user) used extension items.

So my proposal would be something like:
*******************************
* Undo			
* Redo
*------------------------------
* Cut
* Copy
* Paste
* Delete
*------------------------------
* Select All
*------------------------------
* Last used extension item #1
* Last used extension item #2
* ...
* Last used extension item #Y
*------------------------------
* All extensions items ->	*********************
*******************************	* Extension 1 item 1
				* Extension 1 item 2
				* Extension 1 item 3
				*--------------------
				* Extension 2 item 1
				* Extension 2 item 2
				*--------------------
				* Extension 1 item 1
				*--------------------
				* ....
				*--------------------
				* Extension N item P
				*********************

In the extreme case the extensions menu gets so bigger that it doesn't fit the
screen, it could be made scrollable (like the bookmarks menus in Seamonkey).

Comment 12

[Phil Ringnalda (:philor)]

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

Comment 13

[Phil Ringnalda (:philor)]

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

Comment 14

[charlie]

Comment 11 is the most helpful here.
If Firefox is going to let you add extensions ad infinitum, and add those
extensions to the context menu, then the program needs a way of dealing with
that long list of extensions.
Grouping the extensions into a submenu would work for me, but if my ccllection
of extensions grows will I have the same issue in the submenu.
The addition of most recently used extensions on the context menu as well as an
extension submenu is a nice touch.

Regarding the description, I am producing the problem by right-clicking a URL
that I want to save rather than open so the issue is not confined only to graphics.

Comment 15

[Phil Ringnalda (:philor)]

Yup, the only problem with comment #11 is that it isn't true: there is a
mechanism for dealing with it, there are scrolling arrows on both ends when it's
too large, just like the Bookmarks menu. The problem is that it's not correctly
calculating the space available, so it doesn't put them in when the menu's only
a bit too large, and displays the top items (and the top scrolling arrow) off
the top of the screen. A fancy item-shuffler would make a great extension, but
all the bug needs is to make the menu short enough to fit onscreen.

Comment 16

[charlie]

How do you keep the menu short enough to fit on the screen when you are telling
me mine is too big already and there is nothing preventing me from adding more
to it?  The menu needs to be aware of the bounds of the screen and either live
within them or have a way of getting me to the options that are off screen.  

* An up scroll button at the top of the screen that lets me get to the upper 
* menu items doesn't do me a lot of good if I can't see the button because it 
* is off screen too.

Comment 17

[RenegadeX]

This is the single most annoying bug in Firefox (/Mozilla?).
I downloaded the Jan 2 nightly and it STILL has not been addressed.

Comment 18

[Phil Ringnalda (:philor)]

Per an IRC tester, same behavior on Linux, and per the rather suspicious bug
255571 comment 16 it's the same on Mac, so -> All/All.

Comment 19

[cyberneticloop]

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

Comment 20

[Phil Ringnalda (:philor)]

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

Comment 21

[earthsound]

(In reply to comment #11)
> I think there are two issues here:
> 1) The context menu is sometimes misplaced. This a both Seamonkey and Firefox
> issue and bug 267821 is much more clear about it (see comments and attachments).
> 
> 2) There isn't any mechanism for handling the context menu when it gets too big
> to fit in the screen due to extensions, even if it's correctly placed. This is
> mainly a Firefox issue (but can also happen in Seamonkey).
> 
> Thus, I think the best would be to use this bug for the second issue and mark it
> as dependant of bug 267821 for the first issue.

I think both of these points are part of the same problem and should be solved
with one solution. Could we please mark this as a dup of bug 267821, as it has
comments on the code involved? 

If this is marked as a dup, I would suggest those who voted on this bug move
their vote to bug 267821.

Comment 22

[Phil Ringnalda (:philor)]

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

Comment 23

[Igor Levicki]

(In reply to comment #22)
> *** Bug 267821 has been marked as a duplicate of this bug. ***

@Everyone

Context menu from Internet Explorer can also be extended but IE handles that
correctly by displacing a menu from the cursor hotspot. That is IMO enough to
make reasonably sized menu appear correctly. For anything bigger, submenus are
required.

I do not like the idea of scrolling menus. It is too annoying to have to scroll
the menu up and down depending on where you click on the screen and whether you
need topmost or the item at the bottom. Bear in mind that people with visual
impairment (and others perhaps as well) are often relying on counting instead of
actually reading the names of items. If the numbers of items or their position
is changing either by scrolling or by having "favorites" system that shortcut is
not possible and leads to frustration. Also, having morphable menus disables use
of keyboard navigation via hotkeys.

The most idiotic thing I ever saw is the one from the Opera context menu. If you
right click on the picture which is not hyperlinked "Save Image..." is mapped to
"S" key. But if you right click on the picture which is hyperlinked then "Save
Image..." is mapped to "v".

User interface design is not a job for everyone. You have to think about the way
people interact with things in nature and try to implement the least intrusive
system. We can all hate Microsoft but in MSDN you can read great guidelines on
UI design. Too bad that even their programmers do not follow them all the time.

Also, it would be much better if bugs here get solved istead of being marked as
duplicates for n-th time. I agree this is the most annoying bug in Firefox.

Comment 24

[RenegadeX]

According to www.spreadfirefox.com there have been over 10-MILLION downloads of
Firefox since Nov 9th (that's exactly 2 months) -- and yet that bug only has
SEVEN votes for it at the present time.

I can reproduce the bug with as few as **14 items** in the right-click context
menu. (can anyone beat that?.. that's 14 + 4 seperators,btw)

In other words, there are over 9,999,993 users who either are accepting the bug
as "that's just how it is", haven't noticed it, or don't know what they can do
about getting it fixed.

SOLUTION: VOTE FOR THIS BUG!!(above)
I don't care which bug# it gets fixed under, someone just fix it already!!
I'd fix it myself but haven't a clue how to code it.

I tried upgrading the priority but don't have permission (can someone who does
please do it?!) -- it's only a matter of time before the majority of  users have
more than 14 items in their context menus..

Comment 25

[David L. Mohn]

With ref to Comment #24, I think _most_ users could beat his record of "only 14"
items!  I have been able to do it with as few as **3 items** (maybe less, I
haven't checked exhaustively).

Comment 26

[Igor Levicki]

(In reply to comment #24)
> SEVEN votes for it at the present time.

It is because people keep reporting it, time passes, no one pays attention to
it, people report it again, they keep marking it as a duplicate of a duplicate
of a duplicate of a duplicate of a ... I think you got the point -- how can you
vote for something that keeps getting away? This bug tracking system sucks.

> I can reproduce the bug with as few as **14 items** in the right-click context
> menu. (can anyone beat that?.. that's 14 + 4 seperators,btw)

I can beat it with only two extensions installed -- AdBlock and FlashGot. They
are essentials for me and I am very annoyed with this bug.

> or don't know what they can do
> about getting it fixed.

Most likely this is the cause.

> SOLUTION: VOTE FOR THIS BUG!!(above)

Tes, but I have voted at least three times for three different bug reports
concerning this issue. Each time I vote they mark it as duplicate. It is of no use.

> I'd fix it myself but haven't a clue how to code it.

To be honest me neither even though I am programmer. It seems that some smart@ss
decided to write custom menu drawing code (who knows how many kilobytes of it)
instead of using NATIVE solution for popup menus in Windows (TrackPopupMenu API).

> I tried upgrading the priority but don't have permission

When I submitted it my report had normal priority and then some shortsighted
person decided to mark it as duplicate of this one which has minor priority. I
totally disagree that this is minor.

PLEASE consider people who use older hardware and have limited screen resolution
or those that are visually impaired and are forced to use lower resolution
(800x600 like me for example). With only two extensions I don't see the damn top
of the menu. Plus the scrolling idea is bad and the arrows are too small and
hard to hit. Come on people use your brains when writing programs!!! PLEASE!!!

Comment 27

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #26)
> It is because people keep reporting it, time passes, no one pays attention to
> it, people report it again, they keep marking it as a duplicate of a duplicate
> of a duplicate of a duplicate of a ... I think you got the point -- how can you
> vote for something that keeps getting away? This bug tracking system sucks.

Those bugs are all marked as duplicates of this one bug. Are you suggesting that
we keep 20 bugs describing the same issue open? The point of marking duplicates
is to ensure that one issue is tracked/managed at one place. If you want your
vote to count, vote for this bug.

> Tes, but I have voted at least three times for three different bug reports
> concerning this issue. Each time I vote they mark it as duplicate. It is of no
use.

I'm not sure you understand the point of bug tracking. There is a use in voting
for the bug. Marking a bug a duplicate does not mean the bug report is of no
value. It means the bug is already reported. 
 
> To be honest me neither even though I am programmer. It seems that some smart@ss
> decided to write custom menu drawing code (who knows how many kilobytes of it)
> instead of using NATIVE solution for popup menus in Windows (TrackPopupMenu API).

I hope that you realize that blindly making statements such as these without
knowledge of the code certainly does not encourage progress nor does it add any
value to this report.

> When I submitted it my report had normal priority and then some shortsighted
> person decided to mark it as duplicate of this one which has minor priority. I
> totally disagree that this is minor.
> PLEASE consider people who use older hardware and have limited screen resolution
> or those that are visually impaired and are forced to use lower resolution
> (800x600 like me for example). With only two extensions I don't see the damn top
> of the menu. Plus the scrolling idea is bad and the arrows are too small and
> hard to hit. Come on people use your brains when writing programs!!! PLEASE!!!

While you personally feel that this bug is of high importance, I hope that you
understand that the severity field must be kept to a certain scale. A menu
display issue does not in the same severity as a crash or a failure to launch of
the browser. See https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity .

Bottom line is, that while you may be angry and feel like the bug is being
ignored, posting comments such as yours do nothing to encourage anyone to fix it.

Comment 28

[charlie]

I can understand users getting angry over this.  The perception on our side of
the screen, and rightly so, is that nothing is being done to address the issue.
 We keep seeing "this is another version of that same old complaint" messages
but that same old complaint doesn't seem to be going anywhere.  We hear that it
isn't a problem or that it is not a Firefox program.  Somebody needs to take
ownership of this thing and either do something to fix it or fix the context
menu so that nothing can be added to it.  I hope you don't take the easy way out
and do the later.

Comment 29

[Phil Ringnalda (:philor)]

Attachment: Context bloat for all

Bloats into offscreen display not just the context menu for Firefox, but also
Thunderbird and Seamonkey (where uninstallation doesn't seem to be as easy, so
installing to the profile of a new and disposable user is probably best).

Comment 30

[Phil Ringnalda (:philor)]

And since it works the same for everyone, it must be something Core, my guess
being nsMenuPopupFrame.cpp. Yes, I know that the default assignee for the new
component isn't going to please you, but again, bitching about it will only
drive away the volunteers who might otherwise consider fixing it.

bz, sorry to cc you on such a spammy bug, but I can't see anyone else who's
shown any willingness to touch things around menu positioning: if you decide to
bail on it, 'tis quite understandable.

Comment 31

[charlie]

does Mozilla really consider user complaints about things that aren't working
and nobody is fixing spam
if so we might as go back to using IE

Comment 32

[David L. Mohn]

Gavin Sharp in Comment #27 wrote: "A menu display issue does not [rank?] in the
same severity as a crash or a failure to launch of the browser."

Does this mean then, that y'all been having a rash of bugs filed regarding
"crashes" or "failure to launch of the browser" over the past several months???

Regardless, I can understand that Firefox is a complicated set of coding, but
clearly there's quite a few users who have encountered this one single bug on a
cross platform basis.  

And just so you'll know, I tested FF with a screen res of 1024 x 768 (the max
for my monitor & vid card) and my context menu still overfloweth!

Comment 33

[Igor Levicki]

(In reply to comment #27)
> If you want your vote to count, vote for this bug.

As I said I have already voted for at least two versions of this bug -- BOTH OF
THEM were marked as duplicates. Why don't you transfer all the votes from those
20 duplicates you are mentioning to this bug report then?

> It means the bug is already reported.

Yes, but votes are for it are lost because not too many people will return to
check and reassign their votes to the other bug. Not to mention that the other
may soon become duplicate itself and the process of reassigning votes just never
ends and the bug does not get fixed in the meantime.

> I hope that you realize that blindly making statements ...

Well, guess what. I have downloaded the Firefox 1.0 source tree BEFORE I POSTED
and did a search for TrackPopupMenu API in ALL files. Results are as following:

- four results are in the embedding tree:

embedding/browser/activex/src/control/MozillaBrowser.cpp
embedding/browser/activex/tests/cbrowse/CBrowserCtlSite.cpp
embedding/qa/testembed/BrowserFrameGlue.cpp
embedding/tests/mfcembed/BrowserFrameGlue.cpp

I was suspecting that the first one is the buggy one because I believed that
native API was used. In my bug report which you marked as duplicate of this one
someone told me that I wasn't looking at the correct code and that the embedding
(ActiveX) code is not used at all.

- there are two other places where TrackPopupMenu shows up:

tools/preloader/preloader.cpp
xpfe/bootstrap/nsNativeAppSupportWin.cpp

I have checked both and as for prelader.cpp TrackPopupMenu call is part of the
tray notification handling code so is not the one we need.
As for nsNativeAppSupportWin.cpp -- it is the same thing. TrackPopupMenu is the
part of some totally irrelevant code.

So what I have stated here is based on my personal observation and analysis of
the source code and not just a blind statement. If you read MY bug report before
it has been marked as duplicate you would know it.

What I strongly suggest is that when the bug reports get collapsed into one by
marking other reports duplicate someone should merge all the posts and votes
into the remaining bug report. Otherwise, I have full right to keep my opinnion
that this bug tracking system is useless for both reporters and developers.

> While you personally feel that this bug is of high importance, I hope that you
> understand that the severity field must be kept to a certain scale. A menu
> display issue does not in the same severity as a crash or a failure to launch of
> the browser.

Those who experience crashes have the alternative to use another browser that
doesn't crash and I don't have the alternative way to get to the menu option I
need when it is drawn offscreen. Also, most common cases of application crashes
are either with inexperienced (ignorant?) users or with users who have problems
with their hardware or software setup.

It may seem logical to fix show-stoppers first but what actually happens as a
result is that you are increasing the number of inexperienced users (those who
never used the program before) in your user base and driving away experienced
ones (those who use it every day). You think about the net result of this.
Eventually you will get it some day.

> posting comments such as yours do nothing to encourage anyone to fix it.

Frankly, after waiting few months for someone to even notice this I don't give a
sh*t as I am sure you don't care whether I am encouraged to continue using
Firefox after having this stupid debate and after having to deal with this
amount of ignorance and BS here where I least expected it.

If it doesn't get fixed I won't use Firefox anymore and I believe many others
will do the same because the bug is too annoying. And when all those folks that
couldn't even start Firefox eventually get to right clicking on the page I am
pretty sure they will do the same.

Comment 34

[Mike Connor [:mconnor]]

note that the biggest context menu we have shouldn't overflow even on 640x480,
so this is limited to users of extensions that add on to the context menu.  This
is, in comparision, a much smaller section of our userbase than that affected by
crashes.  While I would hope that individual extensions would only add a single
menuitem, I know this isn't the case, which only exacerbates the problem for
affected users.

Speaking as one of the Firefox peers, while we do care about the self-described
"power users" who like to tweak and extend Firefox heavily, we have to be
realistic about where we put our time.  If something affects ALL users (like
crashes, broken features, important improvements in functionality) then we'll
give it our priority over something that affects a fraction of users (context
menu issues when using (probably) multiple extensions that extend the context
menu).  We have to make use of our relatively limited resources in the manner
that benefits the most users, not simply the most vocal ones.

Comment 35

[Igor Levicki]

(In reply to comment #34)
> so this is limited to users of extensions that add on to the context menu.

So basically you suggest us to use vanilla version of the browser without
extensions? Well, guess what? Firefox DOESN'T OFFER MUCH or at least DOESN'T
OFFER MORE than any other browser out there without extensions. So we can as
well get back to using Maxthon, Opera, or even IE.

> much smaller section of our userbase than that affected by crashes.

If that is true then Firefox version does not deserve to be 1.0 -- 1.0 means the
program is STABLE. Get the version number to 0.5 if you have so much crashes and
I will get back to using it when it reaches 1.0 again. This way it is misleading.

> ... hope that individual extensions would only add a single menuitem

That would be rediculous. Take download managers as an example. They need at
least two entries "Get link" and "Get all links".

> "power users" who like to tweak and extend Firefox heavily,

What is so "heavily" in installing TWO extensions, namely AdBlock and FlashGot
in my case?

> that benefits the most users, not simply the most vocal ones.

Thanks for calling me most vocal user of Firefox. Is there any sort of reward
for being such a loud bastard? :-) You could at least give me a hint where in
those ~192 MB of code I should look for context menu drawing code? File path and
function name would suffice. Thank you.

Comment 36

[RenegadeX]

Something just occurred to me - why is it that the menu only ever extends off
the TOP of the screen, and not the bottom??

And to Mike Connor (Comment#34), while you make your case, may I remind you that
Firefox's "attraction" AND SUCCESS is due to its configurability due to add-on
extensions!! Do you not expect people to install any extensions??

Re: your argument about users experiencing crashes & hence that is a priority
over a 'minor' display issue - would you say that of the 10,000,000+ possible
Firefox users there are more people experiencing regular crashes, or more people
with 1 (ok let's say 2+) extensions installed?

I would bet on the latter.

Btw, FF has crashed on me numerous times, inexplicably.
I still vote for getting this bug fixed first!

Comment 37

[Mike Connor [:mconnor]]

This is getting way offtopic, but our estimates based on traffic to UMO and
other bits of tid is that extensions are really limited to 10-15% of our user
base.  Our success is driven by the OOB experience, not by the extensibility or
UMO's collection of extensions.  I've yet to see a Firefox review from a major
outlet do more than mention extensions being available.

And of course, of that 10-15%, not all are using extensions that add context
menu items.  So even being liberal on the subject, I would probably say, at the
extreme, 5% of users are potentially affected.  Yes, those 5% may choose their
extension features over a stability fix or two, but the other 90-95% won't
agree, since they never see the bug.

Anyway, back on topic, the relevant code would live around
http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsMenuPopupFrame.cpp
which should allow for repositioning the element down/up by enough to fit.  If
you're really overflowing the screen height with the context menu (top and
bottom) then that's a bit of overkill.

Comment 38

[Igor Levicki]

(In reply to comment #37)
> I've yet to see a Firefox review from a major outlet do more than mention
> extensions being available.

IMO that is a Firefox web team fault for not trumpeting extensions on the front
page.

> If you're really overflowing the screen height with the context menu
> (top and bottom) then that's a bit of overkill.

Well, such an overflow would be rare at least in my case. I mostly have
situations where menu takes roughly a bit more than half of screen and instead
of having it offset by few pixels from the hotspot in order to see it's top I
either have to scroll the page (if possible) or to resize and reposition Firefox
window to be able to get menu top into the screen.
Btw, 79 KB of code for popup menu is also a bit of an overkill :)

Comment 39

[Phil Ringnalda (:philor)]

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

Comment 40

[RenegadeX]

I asked before - but can anyone explain why the problem does not occur at the
BOTTOM of the screen (only at the top)?

Comment 41

[RenegadeX]

Ok, I have no C++ programming knowledge (only Basic & Turing), but after reading
Igor's post a while back about the source code, I took a look a quick look for
myself at the Aviary branch, specifically lines 399-407 which deal with drawing
the context menu and it got me thinking. 
This is the code found at
(http://lxr.mozilla.org/aviarybranch/source/embedding/qa/testembed/BrowserFrameGlue.cpp#405
:
---- original code snippet ----
CMenu ctxMenu;
     if(ctxMenu.LoadMenu(nIDResource))
     {
         POINT cursorPos;
         GetCursorPos(&cursorPos);
 
         (ctxMenu.GetSubMenu(0))->TrackPopupMenu(TPM_LEFTALIGN, cursorPos.x,
cursorPos.y, pThis);
     }
---- end original code snippet ----

IS THE HEIGHT OF THE CONTEXT-MENU-TO-BE-DRAWN ABLE TO BE READ **IN ADVANCE** OF
IT BEING DRAWN.. AND ITS VALUE THEN ASSIGNED TO A VARIABLE??? 

The reason I ask is this:
- I see no TPM_TOPALIGN or TPM_BOTTOMALIGN or TPM_VCENTREALIGN flags mentioned,
only TPM_LEFTALIGN.
I gather that the TOP flag would result in a menu being drawn 'down' from the
cursor/mouse location and the 'BOTTOM' flag would result in a menu being drawn
'up' from the location - setting one flag permanently would not work as the
menu-draw direction depends on the current cursor position. Now I don't know why
the command is not working properly as is (not recognizing the top y bound,
hence the menu goes off the top of the screen), but *IF the height of the menu
to be drawn is known*, then a simple workaround would be something like this
(paraphrased as I don't know the correct C++ language)
(note: I am assuming y-value of 0 is bottom of screen, not top)

----- code -------
// FIRST 6 LINES SAME AS ORIGINAL CODE //
CMenu ctxMenu;
     if(ctxMenu.LoadMenu(nIDResource))
     {
         POINT cursorPos;
         GetCursorPos(&cursorPos);

// DETERMINE IF MENU WILL EXTEND OFF TOP OF SCREEN //
IF cursorPos.y + menuheight >= max_screen_y_value then
   
    // IF IT IS CONFIRMED THAT IT WILL, WE NOW DETERMINE IF WE CAN DRAW DOWN
FROM CURRENT Y-POSITION
    If cursorPos.y - menuheight > 0 then
    // MENU CONFIRMED SHORT ENOUGH TO DRAW DOWN FROM CURRENT Y-POS
    (ctxMenu.GetSubMenu(0))->TrackPopupMenu(TPM_LeftAlign, TPM_TopAlign,
cursorPos.x, cursorPos.y, pThis);
       else
    // MENU WOULD EXTEND OFF BOTTOM SO WE WILL DRAW IT FROM THE BOTTOM-UP
    var new_y_value : int := 1
    (ctxMenu.GetSubMenu(0))->TrackPopupMenu(TPM_LeftAlign, TPM_BottomAlign,
cursorPos.x, cursorPos.new_y_value, pThis);
    End If

  // NOW DEAL WITH CASE#2 - Y-VALUE IS ACCEPTABLE, USE ORIGINAL CODE
  else
    (ctxMenu.GetSubMenu(0))->TrackPopupMenu(TPM_LeftAlign, TPM_BottomAlign,
cursorPos.x, cursorPos.y, pThis);
End If
----- end code ------

So to explain that:
Imagine that you have a screen with a res of 1024x768, and we know that the
context menu to be drawn has a height of 400 pixels.
** EX1) - Mouse cursor is at (1, 200).
200 + 400 = 600, which is less than our max_screen_y_value (of 768);
.. menu CAN be drawn upwards from the current location(BOTTOMALIGN) without
going off the top
** EX2) - Mouse cursor is at (1, 700)
700 + 400 = 1100, which is > 768; .. menu will extend off the top, but can it be
drawn down(TOPALIGN)? YES, as 700-400 = 300 (which is greater than y=0, the bottom).
** EX3) - Mouse cursor is at (1, 370)
370 + 400 = 770, which is just off the top of our screen, but can it be drawn
down? NO, as 370 - 400 not> 0. However, knowing this, we CAN INSTEAD draw the
menu 1 pixel from the bottom of the screen UPwards (BOTTOMALIGN). The top of the
menu will appear at (1,401).

--
DOES THAT MAKE SENSE? IS IT DO-ABLE??

Comment 42

[Igor Levicki]

(In reply to comment #41)
> specifically lines 399-407 which deal with drawing the context menu

Are you sure that this is the right code?

If you are, first thing you should consider is that 0,0 is at the top left so
you would have to change your formulas accordingly.

Second thing is that I believe that current decision whether to draw the menu
downwards or upwards is correct. Problem is that y coord should be adjusted only
if the menu does not fit in ANY direction.
What I am talking about is this:

- You have screen height of 600 pixels.
- You have menu which is 400 pixels tall (must be more than half screen height).
- You click at 0, 300 -- now what?

IMO, only option is to make it appear offset from the hot spot (the point you
clicked) in the opposite direction from being drawn like Opera or IE do it. So
if you decide to draw it downwards you should adjust y like this:

y = pt.y - (menuheight - (screen_y / 2))

That would be just a quick hack which would cover cases where menu height is
smaller than screen height.

Comment 43

[RenegadeX]

(In reply to comment #42)
> (In reply to comment #41)
> > specifically lines 399-407 which deal with drawing the context menu
> 
> Are you sure that this is the right code?

No, I'm not. In fact, now that I asked someone on #mozilla who knows what they
are doing, they've pointed me in the right direction: nsMenuPopupFrame.

See the code here:
http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsMenuPopupFrame.cpp#417
Interesting that there are so many remarks in this file about taking into
consideration menus extending off the top of the screen.

In an attempt to take a look for myself, I've downloaded the source and spent
14hrs building it (PII-233, 320MB ram)!! It runs, now I want to start changing
stuff... only I've realized why I didn't earlier- - cos the code is so damn big
& I have no clue what I'm doing!! LOL

Comment 44

[Boris Zbarsky [:bzbarsky]]

Attachment: Temporary hack

Brian, could you please review?  The problem is a regression from the
insufficiently-tested patch for bug 120226.  Please note that I'm not cced on
this bug, due to all the shouting, rude comments, and general inanity taking
place, so please make sure to change the review flags if you comment on the
patch?	I won't get mail otherwise....

Phil, thank you for attaching a way to easily reproduce the bug.  That was very
helpful when debugging this.

Mike, thanks for pointing to the right code!

For some of the other commenters on this bug, I would highly recommend reading
<http://bugzilla.mozilla.org/page.cgi?id=etiquette.html>.  You have
successfully violated every single rule in the "Commenting" section.  In the
future, please keep in mind that this is a bug database, not a discussion or
advocacy forum.  If you want to advocate fixes to particular bugs, please do so
outside of bugzilla.

As food for thought, this bug might have gotten fixed two weeks ago when Phil
first cced me on it, but the flood of incredibly rude mails that I received
immediately thereafter made me uncc myself, put this bug on my "look at
sometime, maybe" list, and forget about it.

Comment 45

[Mats Palmgren (inactive)]

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

Comment 46

[Mats Palmgren (inactive)]

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

Comment 47

[Mats Palmgren (inactive)]

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

Comment 48

[Boris Zbarsky [:bzbarsky]]

If we want this fixed for 1.1, we really need to take the patch for 1.8b....

Comment 49

[Phil Ringnalda (:philor)]

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

Comment 50

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 172228 [details] [diff] [review]
Temporary hack

Could this please be approved for 1.8b?  The patch is reasonably safe, but it
should get _some_ testing, in my opinion...

Comment 51

[Phil Ringnalda (:philor)]

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

Comment 52

[Asa Dotzler [:asa]]

Comment on attachment 172228 [details] [diff] [review]
Temporary hack

a=asa for checkin to 1.8b

Comment 53

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 54

[RenegadeX]

(In reply to comment #53)
> Fixed.

AWESOME... I'll check it out tomorrow (it'll be in the 20050216 nightly, right?).
Many thanks to all who voted, nagged - helped - and fixed! That way my personal
'Most Annoying Bug' .. and now I'm very happy & have no complaints :o)

Comment 55

[Boris Zbarsky [:bzbarsky]]

> (it'll be in the 20050216 nightly, right?)

Not unless the nightlies are made in the evenings (and some are not).  Test a
2005-02-17 nightly.

I'd like to second the thanks, except to those who (unnecessarily, rudely, and
counter-productively) nagged.  ;)

Comment 56

[Simon Paquet [:sipaq]]

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

Comment 57

[:Gavin Sharp [email: [e-mail]]]

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

Comment 58

[solvents]

Fixed? Incredible! But please let me know, how can I install this patch in my
Firefox to fix it (maybe I am stupid, sorry for this question).

Comment 59

[:Gavin Sharp [email: [e-mail]]]

The fix is available in the latest nightly builds, which can be obtained at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

These builds are not releases and therefore aren't intended for daily use. It is
advised to wait until Firefox 1.1 is released to upgrade.

Comment 60

[solvents]

(In reply to comment #59)
> The fix is available in the latest nightly builds, which can be obtained at:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
> 
> These builds are not releases and therefore aren't intended for daily use. It is
> advised to wait until Firefox 1.1 is released to upgrade.

Thank you for the information. But there is not czech version and if I
understand it well, there will probably be some other changes in those nightly
builds which I do not want. I only would like to fix this one "Right-Click"
problem. So I will wait untill official version 1.1 - When it is planned to be
issued?
PS: If 1.1 will be issued after long period, is it possible now to make the
extension, which can be installed and which will fix this problem?

Comment 61

[Boris Zbarsky [:bzbarsky]]

Trying to avoid the spamfest that's irrevocably tied to this bug.

Comment 62

[:Gavin Sharp [email: [e-mail]]]

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

Comment 63

[:Gavin Sharp [email: [e-mail]]]

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

Comment 64

[Simon Paquet [:sipaq]]

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

Comment 65

[Jesse Ruderman]

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

Comment 66

[Phil Ringnalda (:philor)]

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

Comment 67

[nrlz]

Is this a dup of 190160?

Comment 68

[:Gavin Sharp [email: [e-mail]]]

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

Comment 69

[solvents]

When RESOLVED, why didn't you include the patch to new released versions 1.0.1
and  even not in 1.0.2 which was released just yesterday?

Comment 70

[Mike Connor [:mconnor]]

the 1.0.x branch is a stable branch with only limited checkins for
stability/security fixes.  General fixes, especially those that change the
backend, will ship in 1.1.

Comment 71

[solvents]

Thank you for the information. And when do you plan to evaluate version 1.1?

Comment 72

[RenegadeX]

I'd thought the 'fix' that is in the trunk builds was just a temporary patch..
because the implementation - though 1000x better than the 'broken' right-click
dialogs in the release versions - still sucks. Sorry to be harsh, but:
1) scrolling arrows should not appear unless there is something to scroll to.
2) the content-menu box seems to be a 'fixed(maximum) height'
3) the menu is still incorrectly positioned too high on the screen,
necessitating scrolling when there is plenty of room for the menu to be drawn
below it. (due in part to #2).

As I said, i am thankful for the fix, but to include it that way for v1.1 is
c-r-a-z-y.

Comment 73

[Mike Connor [:mconnor]]

This will do for 1.1, but it is a temporary solution.  The problem is that
fixing this "right" requires a much larger set of changes, at much more risk
than we're going to assume at this stage in the cycle.  This is something that
can be revisited in the Gecko 1.9 cycle when we have a lot more time to test and
mitigate risk, but no earlier.  Risking breaking our entire menu code and
dealing with continued regressions is less sane than shipping a band-aid.

And suggestion #3 (repositioning downward) breaks a lot of user expectation.  We
rejected that as a solution, despite it having some appeal.  This isn't up for
debate, so please don't spam this bug further.

1.1 is currently looking like the end of June.

Comment 74

[:Gavin Sharp [email: [e-mail]]]

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

Comment 75

[AJ]

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

Comment 76

[Simon Paquet [:sipaq]]

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

Comment 77

[:Gavin Sharp [email: [e-mail]]]

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

Comment 78

[José Jeria]

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

Comment 79

[:Gavin Sharp [email: [e-mail]]]

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

Comment 80

[Phil Ringnalda (:philor)]

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

Comment 81

[Steve England [:stevee]]

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

Comment 82

[Simon Paquet [:sipaq]]

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

Comment 83

[José Jeria]

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

Comment 84

[Phil Ringnalda (:philor)]

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

Comment 85

[Matthias Versen [:Matti]]

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

Comment 86

[:Gavin Sharp [email: [e-mail]]]

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

Comment 87

[:Gavin Sharp [email: [e-mail]]]

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

Comment 88

[stefan]

I would love for this to be fixed! This has occured consistently through various
versions (at 1.03 now). I tried the nightly build, but I got errors (probably an
extension) and I'm not power-user nor obsessive enough to fix it, nor do I know
how to apply the suggested patch.

I think the description of this bug is inherently misleading. The bug is the
"context menu is cut off" - period. Everything else is supporting information.
Adding "when too many items..." dismisses the bug and makes it the users' fault
("well, don't have so many items, idiot!")

Looking forward to 1.1 - yucky scroll arrows or not it'll actually solve the
problem, right?

Comment 89

[Tony Mechelynck [:tonymec]]

(In reply to comment #88)
> I would love for this to be fixed! [...]
Me too.
> 
> I think the description of this bug is inherently misleading. The bug is the
> "context menu is cut off" - period. Everything else is supporting information.
> Adding "when too many items..." dismisses the bug and makes it the users' fault
> ("well, don't have so many items, idiot!")

I don't agree. The bug is not that all menus are always cut off. A menu is cut
off only when it's longer than half the total height of the monitor _and_ it is
triggered by a mouse near enough to the middle that the distance from the mouse
to the farthest of the top and bottom edges is shorter than the menu. Most of
the default menus are short enough; but, especially in Firefox, extensions can
add menu items. It is of course the user who chooses which extensions to add and
which ones not to, and in addition, the user has the possibility to modify the
menu font size by means of userChrome.css, so it is indeed in part the user's
"fault". Yet IMHO, whatever the user does, there ought to be a way to access all
items of any menu however long, so the user's "fault" is not really a fault in
my eyes. I still believe that mentioning "...when it contains too many items..."
in the bug summary is both truthful (if interpreted as "too many for the browser
as it is now to display them", not as "more than are permitted") and helpful (to
whoever is in the position to fix this bug).
> 
> Looking forward to 1.1 - yucky scroll arrows or not it'll actually solve the
> problem, right?

Hopefully so. Let's hope it doesn't introduce new problems elsewhere (like, for
instance, breaking themes because they don't expect the Options menu tabs to be
across the top instead of down the left).

Best regards,
Tony.

Comment 90

[:Gavin Sharp [email: [e-mail]]]

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

Comment 91

[:Gavin Sharp [email: [e-mail]]]

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

Comment 92

[Kevin Brosnan]

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

Comment 93

[Kevin Brosnan]

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

Comment 94

[Kevin Brosnan]

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

Comment 95

[SRFKOFDDR]

that was rally inconvienient to me.
Hope you could improve it .
thank you :)

Comment 96

[SRFKOFDDR]

that was rally inconvienient to me.
Hope you could improve it .
thank you :)

Comment 97

[José Jeria]

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

Comment 98

[Jaime Mitchell (use [e-mail] for email)]

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

Comment 99

[Jaime Mitchell (use [e-mail] for email)]

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

Comment 100

[Phil Ringnalda (:philor)]

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

Comment 101

[Phil Ringnalda (:philor)]

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

Comment 102

[Adam Guthrie]

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

Comment 103

[Phil Ringnalda (:philor)]

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

Comment 104

[Jaime Mitchell (use [e-mail] for email)]

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

Comment 105

[Phil Ringnalda (:philor)]

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

Comment 106

[Phil Ringnalda (:philor)]

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

Comment 107

[Phil Ringnalda (:philor)]

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

Comment 108

[Phil Ringnalda (:philor)]

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

Comment 109

[Peter Craig Martin]

This bug is still alive and well in Firefox 1.0.6.  *Everyone* I know who uses
Firefox with extensions says it is Firefox's single most annoying,
usability-impairing bug and that it affects them every session.  

In my experience, when the right-click context menu runs off the screen, a
properly functioning scroll-down arrow appears at the bottom of the menu and it
is possible to scroll down all the way to the bottom of the menu.  However, no
equivalent scroll-up arrow appears, and it is only possible to scroll up (with
the mouse wheel or cursor keys, I think) as far as you have already scrolled
down.  In short, you can't scroll any higher in the context menu than what was
visible when you right-clicked.  On smaller screens, it is sometimes impossible
to reach items at the top of the right-click context menu no matter *how* low on
the page you right-click.  

Again, I believe this is Firefox's NUMBER ONE USABILITY BUG for anyone who uses
extensions and that it merits the developers' full attention.  It should be
upgraded from minor to MAJOR and changed from verified fixed to REOPENED/NOT
FIXED.  

Thanks!

Comment 110

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #109)
> extensions and that it merits the developers' full attention.  It should be
> upgraded from minor to MAJOR and changed from verified fixed to REOPENED/NOT
> FIXED.

Please read comment 59 and comment 70. It is fixed.

Comment 111

[Dave Land]

> Please read comment 59 and comment 70. It is fixed.

It most certainly is NOT fixed for those many thousands who download and use the
browser.

I'm using "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6" and it is STILL annoying as heck.

I'm tempted to click Reopen bug, but I know that someone will just change it
back to VERIFIED FIXED, even though it is definitely not fixed for the majority
of us.

Comment 112

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #111)
> It most certainly is NOT fixed for those many thousands who download and use the
> browser.

By that definition, it will not be "fixed" until Firefox 1.5 is released.
Commenting in this bug will not help.

> I'm tempted to click Reopen bug, but I know that someone will just change it
> back to VERIFIED FIXED, even though it is definitely not fixed for the majority
> of us.

The FIXED status in Bugzilla means that the bug is fixed on the trunk. This bug
is fixed on the trunk. The fact that you don't agree with that definition of
"fixed" does not allow you to incorrectly change the resolution of bugs.

Comment 113

[Dave Land]

(In reply to comment #112)

> The FIXED status in Bugzilla means that the bug is fixed on the trunk. This bug
> is fixed on the trunk. The fact that you don't agree with that definition of
> "fixed" does not allow you to incorrectly change the resolution of bugs.

I didn't change it. Thank you for making the definition of "FIXED" and its
relationship to 1.0.6 and 1.5 clear.

Comment 114

[Peter Craig Martin]

My apologies for not catching comments 59 and 70 and for misinterpreting the
meaning of "fixed."  No petulance on my part was intended.  

Perhaps, for the benefit of casual bugzilla visitors like me, the "Resolution"
field at the top of the bug page could be more informative, e.g.:

FIXED in Firefox v. 1.1 and higher (when released) and in nightlies xyz and
higher.  

     or:

FIXED in nightly beta releases and in upcoming final release.

     or simply:

FIXED in upcoming release.

Just a thought...

Thanks very much for clearing up my misunderstanding; I apologize for the wave
of frustration I seem to have triggered!  

Comment 115

[Phil Ringnalda (:philor)]

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

Comment 116

[RenegadeX]

(In reply to comment #112)
> (In reply to comment #111)
> > It most certainly is NOT fixed for those many thousands who download and
> > use the browser.
> 
> By that definition, it will not be "fixed" until Firefox 1.5 is released.
> Commenting in this bug will not help.

Umm... I downloaded & am using the 1.5Beta -- it should be 'fixed' in this
version, right?

***
I'm REQUESTING THIS BUG TO BE REOPENED - the original complaint is that the
right-click context menu 'disappears off the screen if too long'. This complaint
is still valid - we have nice fancy arrows to allow us to view the 'offscreen',
but the point is they should never have 'disappeared'/been cut-off/not be
displayed in the first place!!
***

See my post #72 (from March '05).. it still holds true):
- I don't need/want arrows at the top and bottom when the menu is short enough
to display properly
- I don't need/want a 'fixed height' context menu necessitating scrolling when
there's plenty of vertical screen space left that could be used to display the
extra few items.
- What I do WANT is for Firefox to figure out how much room up or down it needs
to draw the menu from the current location, and if it's going to extend too far
off the bottom, then it should draw it from the
bottom-of-the-screen-coordinate->UP (and vice-versa if going down). Internet
Explorer does this. Word does this. Wordperfect does this.. heck, EVERY friggen
program I've ever used in Windows does this.. why does Firefox have to be difficult?

Comment 117

[Adam Guthrie]

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

Comment 118

[Andrew]

This problem can be recreated by right clicking a hyperlinked image close-ish to
the top of your screen, and trying to select 'open in new tab'.

I believe this problem should be reopened, as clearly stated by me - it is still
an unfixed problem.

Comment 119

[Phil Ringnalda (:philor)]

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

Comment 120

[James B. Higgs]

This is the second time that I have been told that a bug I am experiencing has been "fixed on the Trunk" and to please download a trunk version and install it.

I don't know from trunks. The only way I know of to download Mozilla is to go to http://www.mozilla.org/, click on the "Mozilla 1.7.x" link under the "Other Mozilla Software" heading, then click the "Windows, English" link in the "Download Now" box. If that doesn't get me "The Trunk", I suggest that somebody needs to correct what is being distributed by these links.

And, if I understand correctly from reading further comments, the "Fix" only applies to Firefox, not Mozilla Application Suite, and is a Kludge, anyway. Putting "Scroll Arrows" at the top and bottom of the context menu is a solution that should only be resorted to if there are so many entries in the context menu that there actually isn't room for them on the screen. Otherwise, the context menu should simply be repositioned so that the top menu item is at the top of the screen.

I believe that the status of this bug should be changed from verified fixed to reopened not fixed, at least for Mozilla Application Suite if not for Firefox.

Jim H. (aka CuriousJ)

Comment 121

[Tony Mechelynck [:tonymec]]

(In reply to comment #120)
> This is the second time that I have been told that a bug I am experiencing has
> been "fixed on the Trunk" and to please download a trunk version and install
> it.
> 
> I don't know from trunks. The only way I know of to download Mozilla is to go
> to http://www.mozilla.org/, click on the "Mozilla 1.7.x" link under the "Other
> Mozilla Software" heading, then click the "Windows, English" link in the
> "Download Now" box. If that doesn't get me "The Trunk", I suggest that somebody
> needs to correct what is being distributed by these links.
> 
> And, if I understand correctly from reading further comments, the "Fix" only
> applies to Firefox, not Mozilla Application Suite, and is a Kludge, anyway.
> Putting "Scroll Arrows" at the top and bottom of the context menu is a solution
> that should only be resorted to if there are so many entries in the context
> menu that there actually isn't room for them on the screen. Otherwise, the
> context menu should simply be repositioned so that the top menu item is at the
> top of the screen.
> 
> I believe that the status of this bug should be changed from verified fixed to
> reopened not fixed, at least for Mozilla Application Suite if not for Firefox.
> 
> Jim H. (aka CuriousJ)
> 

The trunk is, by definition, the least stable of all branches in the development tree. It is the "bleeding edge" of audacious development, and at the moment it corresponds to what is otherwise known as Firefox 1.6 (alpha) and I'm not sure which version of Mozilla (Seamonkey).

The next branch (just slightly stabler) currently corresponds to Firefox 1.5 beta, Firefox 1.5 RC and Mozilla 1.8 beta. The build I am using ("Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051027 Firefox/1.5", build ID:2005102703) belongs to that branch, and its menus have scrollbox arrows at top and bottom, so menus which are too long for the screen can be scrolled. I regard this as a satisfactory if not perfect fix to this bug; IOW, IMO the build I'm using does not exhibit the present bug.

Still more stable is the "release" branch, which includes Firefox 1.0.7 and Mozilla 1.7. IIUC _only_ security bugs are going to be fixed on that branch, which will be abandoned as soon as one of the other two becomes stable enough, with a wide enough array of extensions and themes.

Therefore the present bug is indeed fixed, just not on the current "release" builds, but only on the alpha and beta builds. If you want to install a build with the fix, I suggest that you search the subdirectories of http://ftp.mozilla.org/pub/mozilla.org/ for something corresponding to your OS, your preferences, and your audacity or prudence.

Best regards,
Tony.

Comment 122

[Mark Metcalf]

I consider the scrolling when a menu is longer than the screen a necessary evil albeit an annoying one. Scrolling when a menu's height is less than half the screen is silly and very annoying.

Comment 123

[Tony Mechelynck [:tonymec]]

When the menu's height is less than half the screen, my current Firefox build will display it either above or below the mouse pointer, whichever is wide enough in the vertical direction, and no scrolling will be necessary. If the menu's height is more than one-half of the screen height but less than the full screen height, it may be fully displayed without scrolling, or not, depending in part on the mouse pointer location. If the menu height is more than the screen height, scrolling is always required -- but with a little luck you may find the item you need in the part of the menu which is accessible without scrolling. I'm not overjoyed by this solution but it's good enough for me.

Comment 124

[Mark Metcalf]

That makes sense and should be good enough for me also . In any case even if I had been understanding correctly my previous comments were rude and harsh I regret and apologise for them.

Comment 125

[RenegadeX]

(In reply to comment #121)
> The next branch (just slightly stabler) currently corresponds to Firefox 1.5
> beta, Firefox 1.5 RC and Mozilla 1.8 beta. The build I am using ("Mozilla/5.0
> (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051027 Firefox/1.5", build
> ID:2005102703) belongs to that branch, and its menus have scrollbox arrows at
> top and bottom, so menus which are too long for the screen can be scrolled. I
> regard this as a satisfactory if not perfect fix to this bug; IOW, IMO the
> build I'm using does not exhibit the present bug.
> 
> Still more stable is the "release" branch, which includes Firefox 1.0.7 and
> Mozilla 1.7. IIUC _only_ security bugs are going to be fixed on that branch,
> which will be abandoned as soon as one of the other two becomes stable enough,
> with a wide enough array of extensions and themes.
> 
> Therefore the present bug is indeed fixed, just not on the current "release"
> builds, but only on the alpha and beta builds. 

Tony, I just downloaded the latest Deer Park Alpha 2 nightly, as you suggested (and before you posted your later reply). It's *exactly* the same as before.

Again, what is the bug, as originally defined (in the title of 245163)?
Answer: Context menu is cut off when too many items are added by extensions.

Current situation: context menu is cut off when too many items are added by extensions - necessitating unnecessary scrolling.

Raise your hand if that = "fixed" to you.
Let's start counting..

** THE BUG IS NOT FIXED **
Screenshots from DPA2:
1. Hey look - I have to scroll down, but the menu is cut off abruptly (for no reason) and I have to scroll in order to see the rest of the options:
http://renegadex.miscstuff.cjb.net/Bug245163_DPA2_a.jpg
2. After scrolling, there they finally are.. up & down we go!
http://renegadex.miscstuff.cjb.net/Bug245163_DPA2_b.jpg

3.Even if I click lower down, menu items still get cut off with extra screen real-estate to spare:
http://renegadex.miscstuff.cjb.net/Bug245163_DPA2_c.jpg

and finally, one from Internet Explorer, where menus are displayed 'correctly':
http://renegadex.miscstuff.cjb.net/Bug245163_InternetExplorer-CORRECT.jpg

Notice the difference? (look at the positioning of the mouse pointer in the IE pic).

Comment 126

[Tony Mechelynck [:tonymec]]

(In reply to comment #125)

RenegadeX, I remember how this bug looked when I first encountered it, on pre-1.0 builds of Firefox. At that time, when the menu was long (significantly longer than half the screen height), and the mouse pointer was about halfway between top and bottom of screen, part of the menu disappeared offscreen and _could not_ be scrolled back -- there were *no* scrolling arrows, and the only hack which I could apply in order to try to make the bug less painful, was to edit userChrome.css in order to reduce the menu font size.

Nowadays, all menu items are always accessible (sometimes with scrolling) so yes, the way I see it, the bug is fixed. Maybe not in the best possible way (though different people may disagree about exactly what would be the "best possible" fix) but in a manner which I can stomach. If you can't, well, you're free to write a patch or an extension yourself: according to the "Bugzilla etiquette" page https://bugzilla.mozilla.org/page.cgi?id=etiquette.html nobody other than you has any duty to fix any bug that you want fixed. Good luck.

Best regards,
Tony.

Comment 127

[Phil Ringnalda (:philor)]

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

Comment 128

[jigar]

(In reply to comment #125)
> (In reply to comment #121)
> > The next branch (just slightly stabler) currently corresponds to Firefox 1.5
> > beta, Firefox 1.5 RC and Mozilla 1.8 beta. The build I am using ("Mozilla/5.0
> > (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051027 Firefox/1.5", build
> > ID:2005102703) belongs to that branch, and its menus have scrollbox arrows at
> > top and bottom, so menus which are too long for the screen can be scrolled. 



> > regard this as a satisfactory if not perfect fix to this bug; IOW, IMO the
> > build I'm using does not exhibit the present bug.
> > 
> > Still more stable is the "release" branch, which includes Firefox 1.0.7 and
> > Mozilla 1.7. IIUC _only_ security bugs are going to be fixed on that branch,
> > which will be abandoned as soon as one of the other two becomes stable enough,
> > with a wide enough array of extensions and themes.
> > 
> > Therefore the present bug is indeed fixed, just not on the current "release"
> > builds, but only on the alpha and beta builds. 
> 
> Tony, I just downloaded the latest Deer Park Alpha 2 nightly, as you suggested
> (and before you posted your later reply). It's *exactly* the same as before.
> 
> Again, what is the bug, as originally defined (in the title of 245163)?
> Answer: Context menu is cut off when too many items are added by extensions.
> 
> Current situation: context menu is cut off when too many items are added by
> extensions - necessitating unnecessary scrolling.
> 
> Raise your hand if that = "fixed" to you.
> Let's start counting..
> 
> ** THE BUG IS NOT FIXED **
> Screenshots from DPA2:
> 1. Hey look - I have to scroll down, but the menu is cut off abruptly (for no
> reason) and I have to scroll in order to see the rest of the options:
> http://renegadex.miscstuff.cjb.net/Bug245163_DPA2_a.jpg
> 2. After scrolling, there they finally are.. up & down we go!
> http://renegadex.miscstuff.cjb.net/Bug245163_DPA2_b.jpg
> 
> 3.Even if I click lower down, menu items still get cut off with extra screen
> real-estate to spare:
> http://renegadex.miscstuff.cjb.net/Bug245163_DPA2_c.jpg
> 
> and finally, one from Internet Explorer, where menus are displayed 'correctly':
> http://renegadex.miscstuff.cjb.net/Bug245163_InternetExplorer-CORRECT.jpg
> 
> Notice the difference? (look at the positioning of the mouse pointer in the IE
> pic).
> 


I RenegadeX,
I totally agree with you. Even in FF 1.5RC3 This issue is not addressed correctly. Unnecessary scroll buttons just little better. but IE placement of context menu is perfect!

Comment 129

[Kevin Brosnan]

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

Comment 130

[ttech5593]

Um, what version are you using ? Because it the stable version of FF 1.5 it seems works fine. The context menu expands as it needs to and if there is no room I can use the scroll arrows always on the context menu to go up or down. But this may be just me...

Comment 131

[Tony Mechelynck [:tonymec]]

(In reply to comment #130)
> Um, what version are you using ? Because it the stable version of FF 1.5 it
> seems works fine. The context menu expands as it needs to and if there is no
> room I can use the scroll arrows always on the context menu to go up or down.
> But this may be just me...
> 

It's not just you: me too. However, there are some users out there who won't agree that this bug is fixed until or unless the context menu expands both above and below the mouse pointer, to top and bottom of the screen, before scroll arrows become useful. Me, I'm perfectly content with the present 1.5 behaviour, and even so, I don't even need to use the scroll arrows very often, in part because I have reduced the menu font size by means of userChrome.css

Comment 132

[Phil Ringnalda (:philor)]

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

Comment 133

[Kevin Brosnan]

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

Comment 134

[Andrew]

What some people want, is for the right-click menu to behave exactly like IE's right-click menu, except in the case that the vertial space is too large for all of the menu items.

Comment 135

[jigar]

> What some people want, is for the right-click menu to behave exactly like IE's
> right-click menu, except in the case that the vertial space is too large for
> all of the menu items.


Exactly..!! Thats what we expect.(In reply to comment #134)

Comment 136

[Andrew]

I suggest that this situation is finally fixed correctly once and for all. 

In summary, the facts are that the menu was being cut off the top of the screen in some cases. This was fixed by adding the arrows.

If possible, many members of this thread would also like to reopen this bug - with the fact that the arrows inhibit a users experience.

We would like to have the menu go from the top of the screen to the bottom of the screen if there are too many menu items on the menu.

We would also like to have the arrows added to the menu only if the menu has enough items so that it takes up the full height of the screen.

Discussion is now open, PLEASE reopen the bug with these points - as all other bugs similar to this bug are pointing towards this thread, this thread is our only chance to fix this 'perceived' problem that would improve Firefox users user-experience.

Comment 137

[Tony Mechelynck [:tonymec]]

This bug is fixed well enough for my satisfaction: I don't believe that it should be reopened. However, that doesn't necessarily mean that I want to constrain everyone else to the possibly untasty choice: "be content with the present state of affairs or go back to IE". Firefox is an extensible browser (and so are the other Mozilla browsers), there are ways to extend its menu systems. Would it be possible to make the menus behave differently by means of an extension? If it is at all possible, IMHO that's the way to go for those who want the menus to extend farther up and down than they do now.

Comment 138

[:Gavin Sharp [email: [e-mail]]]

This bug, as summarized, is fixed. If there are issues with the current implementation, new bugs should be filed, if they aren't already. Continuing discussion here won't lead to anything being fixed.

Comment 139

[RenegadeX]

(In reply to comment #138)
> This bug, as summarized, is fixed. If there are issues with the current
> implementation, new bugs should be filed, if they aren't already. Continuing
> discussion here won't lead to anything being fixed.

You guys will give me **** for chiming in again saying what's already been said, but someone has to, so I'll volunteer - the Bug as summarized, is *not* fixed:

Comment#1:
----
Expected Results:  
I would have expected the menu to adjust and rather than beginning exactly
where the mouse pointer is, to move so that all menu choices are available.
-----

Has the original issue been fixed? NO.
That is - does the position of the menu move (as required) "so that all menu choices are available" (<--- inferred: 'all visible at the same time').

When I break my leg and the bone extends out of my skin - do we put a bandaid on it and say "there, that's fixed"? No! You first put a bandage on so you don't get blood all over the car/ambulance and then you get it taken care of properly. And until it is properly healed, the doctor won't give you a clean bill of health. This is no different.

Additionally, I understood from previous discussion that in the upcoming Gecko cycle, menu-drawing is to be revamped. If this Bug is marked 'FIXED', then it is no longer an outstanding issue. It IS clearly an outstanding issue, otherwise some of us wouldn't be discussing it...

Comment 140

[Mike Connor [:mconnor]]

I think you meant comment 0, not comment 1, but aside from that you're not being realistic if you think that bugs can only be resolved fixed if the fix exactly matches the reporter's expectations, especially in something that's basically a UI design decision.

File a new bug requesting the change in behaviour if you want reconsideration in any refactoring of menu code.

Comment 141

[James B. Higgs]

(In reply to comment #116)
> Umm... I downloaded & am using the 1.5Beta -- it should be 'fixed' in this
> version, right?
> 
> ***
> I'm REQUESTING THIS BUG TO BE REOPENED - the original complaint is that the
> right-click context menu 'disappears off the screen if too long'. This complaint
> is still valid - we have nice fancy arrows to allow us to view the 'offscreen',
> but the point is they should never have 'disappeared'/been cut-off/not be
> displayed in the first place!!
> ***
> 
> See my post #72 (from March '05).. it still holds true):
> - I don't need/want arrows at the top and bottom when the menu is short enough
> to display properly
> - I don't need/want a 'fixed height' context menu necessitating scrolling when
> there's plenty of vertical screen space left that could be used to display the
> extra few items.
> - What I do WANT is for Firefox to figure out how much room up or down it needs
> to draw the menu from the current location, and if it's going to extend too far
> off the bottom, then it should draw it from the
> bottom-of-the-screen-coordinate->UP (and vice-versa if going down). Internet
> Explorer does this. Word does this. Wordperfect does this.. heck, EVERY friggen
> program I've ever used in Windows does this.. why does Firefox have to be difficult?

Hear, Hear!

What was that movie? "We don't wanna eat this slop! Yarg, yarg, yarg!"
:)

I, too, feel that this bug deserves some other status than "FIXED". Perhaps we
need a new status, "KLUDGED".

:) Jim H. (aka CuriousJ)

Comment 142

[James B. Higgs]

(In reply to comment #138)
> This bug, as summarized, is fixed. If there are issues with the current
> implementation, new bugs should be filed, if they aren't already. Continuing
> discussion here won't lead to anything being fixed.
> 

We *can't* file  a new bug on the subject, they all get marked as DUPEs of THIS
bug.

Jim H. (aka CuriousJ)

Comment 143

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #142)
> We *can't* file  a new bug on the subject, they all get marked as DUPEs of THIS
> bug.

If the bug you file has a summary of "context menu overflow should be handled better", with some suggestions on how that can be done, then it will not be duped to this bug. The problem described in this bug no longer exists - the fact that you disagree with the solution is another issue entirely, and thus should be filed as a new bug. That bug may be marked WONTFIX, however.

Comment 144

[James B. Higgs]

> If the bug you file has a summary of "context menu overflow should be handled
> better", with some suggestions on how that can be done, then it will not be
> duped to this bug.

See Bug #342619 - "Solution to Bug #245163 is a KLUDGE"

Jim H. (aka CuriousJ)