267821 - Misplaced context menu - appears offscreen if larger than default

Status: VERIFIED DUPLICATE of bug 245163

(Firefox :: General, defect)

Description

[Igor Levicki]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

In 800x600 resolution which I use because I am visually impaired, right clicking
on the bottom part of hyperlinked image on any page often makes context menu top
invisible. When a right click ends low enough on the thumbnail image Firefox
decides to pop the context menu above the cursor. Problem is that the menu is
too big so it's top is not visible. One way to fix this would be to restructure
the context menu to always fit vertical screen size. Note that this doesn't
happen when you right-click on the page background because page context menu is
considerably shorter. I have tried this in Internet Explorer and Opera and --
their context menus always fit in the available vertical screen size. You should
mimic that if possible. Thanks.

Reproducible: Always
Steps to Reproduce:
1. Set your display to 800x600
2. Open some image gallery
3. Try right-clicking on upper and lower parts of each image and observe how the
context menu behaves.

Actual Results:  
Top few entries in the context menu are not always visible.

Expected Results:  
To work the same way as in Internet Explorer and Opera.

Comment 1

[Comio]

same problem with 1024x768 resultion...

I have several entry in context menu and firefox wrongs the placemente of the
context menu... It decides to allocate the context-meno on the top of the
screen... cutting the first one-two entry of the menu...

thanks
comio

Comment 2

[Troodon]

Dupe of bug 175568.

Comment 3

[Troodon]

I'm sorry, bug 175568 has nothing to do with this one.
Also, I haven't been able to reproduce this bug with Mozilla/5.0 (Windows; U;
Windows NT 5.0; es-ES; rv:1.7.5) Gecko/20041108 Firefox/1.0 but I think it could
be a dupe of bug 255571.

Comment 4

[Igor Levicki]

(In reply to comment #3)
> I'm sorry, bug 175568 has nothing to do with this one.
> Also, I haven't been able to reproduce this bug with Mozilla/5.0 (Windows; U;
> Windows NT 5.0; es-ES; rv:1.7.5) Gecko/20041108 Firefox/1.0 but I think it could
> be a dupe of bug 255571.

Well, I have read that bug report but it also contained some discussion about
totally unrelated bug with themes. Plus it has been marked as fixed then as new.
I strongly believe this buh has nothing to do with extensions. Firefox does
wrong calculation when deciding where to put the context menu. Opera and IE do
not have that problem. I am mentioning IE because its context menu can also be
extended with various download managers but it still works correctly afterwards.
I have only two extensions anyway (adblock and flashgot). Bug can probably be
triggered without them.

Try this:

1. switch to 800x600 screen resolution
2. Open http://www.prodikeys.com/
3. scroll the page so that top navigation menu just disappears
4. rightclick near the top of the second image on the right -- the one that says
BEST of CES and you will get cropped context menu.

Comment 5

[Troodon]

Attachment: Screenshot

Finally, I think I've been able to reproduce this bug, but it's VERY HARD to
reproduce, as for me it works fine 99% of times when right-clicking the
uppermost visible image line. Plus as you can see in the screenshot, even when
misplaced, I can see the full menu - please note that I have NO extensions
installed. If with extensions the menu isn't fully visible, then it would be
more a bug 255571 related issue.
Thus, I would change the summary of this bug to something like "Context menu
misplaced when right-clicking the uppermost visible image line" and it's
severity to trivial or minor.

Reproduced with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041115
Firefox/1.0
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041116
Firefox/0.9.1+
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041124

Comment 6

[Igor Levicki]

Attachment: Handling of context menu in IE

Comment 7

[Igor Levicki]

Attachment: Handling of context menu in Opera

Comment 8

[Igor Levicki]

Attachment: BROKEN Handling of context menu in Firefox

Comment 9

[Igor Levicki]

Ok, it definately has to do with the number of options in the context menu. You
have 14 entries and my context menu has 19. Of course, that depends on installed
extensions. BUT... I do not agree about this bug being trivial or minor. What
good is the possibility to have extensions when browser gets screwed if you
actually use them?

Check the screenshots from Opera and IE. I have marked cursor hotspot (i.e. the
place where I right clicked) with an arrow. On Firefox image I rightclicked on
the small arrow image in left frame.

From what I have observed I presume that Firefox is using TPM_BOTTOMALIGN flag
when the y coordinate falls in the lower half of the screen and TPM_TOPALIGN
when y coordinate falls in the upper half of the screen. Note that I am guessing
this without looking at the source solely by the context menu behavior. There is
also a third flag for TrackPopupMenu() API -- TPM_VCENTERALIGN but I am not sure
how it works. Feel free to experiment with it.

I would like to see this fixed soon. It happens to me 50% of the rightclicks and
I have to cancel the menu, scroll the page and try again until I get the whole
menu to show. Annoying.

UNRELATED TO THE BUG:
There is also a feature I would like to see and its realization is trivial --
when the mouse hovers over horizontal scroll bar and you spin the scroll wheel
browser should scroll the page horizontally instead of vertically. Opera and
Photoshop are two examples of this excelent feature.

---start code snippet---
	if (uMsg == WM_NCHITTEST) {
		LRESULT rv = DefWindowProc(hWnd, uMsg, wParam, lParam);
		if (rv == HTHSCROLL) {
			g_WheelDirection = WHEEL_HORIZONTAL;
		} else {
			g_WheelDirection = WHEEL_VERTICAL;
		}

		return rv;
	}
---end code snippet---

Contact me if you need additional info.

Comment 10

[Troodon]

(In reply to comment #9)
> Ok, it definately has to do with the number of options in the context menu. You
> have 14 entries and my context menu has 19. Of course, that depends on installed
> extensions. BUT... I do not agree about this bug being trivial or minor. What
> good is the possibility to have extensions when browser gets screwed if you
> actually use them?

> I would like to see this fixed soon. It happens to me 50% of the rightclicks and
> I have to cancel the menu, scroll the page and try again until I get the whole
> menu to show. Annoying.


As I said, the underlying problem here is the misplacement of the conxtext menu
under certain conditions. Even when that happens, the "default size" menu is
fully showed so it's not a big issue. This is only a big issue when the menu is
larger than the default one, due to extensions, as the upper part appears offscreen.
So I would said it's minor for the default context menu and normal for an
expanded one :-).

In order to make this bug about the real problem (which will be more helpful for
the developers), I recommend you again to change the summary to something as
"Misplaced context menu - appears offscreen is larger than default", the product
to "Core" (it has been reporduced in both Seamonkey and Firefox - comment #5),
and the component to "XP Toolkit/Widgets: Menus".


> UNRELATED TO THE BUG:
> There is also a feature I would like to see and its realization is trivial

It isn't good to mix more than one problem/issue per bug, so please open another
 report and select "enhancement" as its severity.

Comment 11

[Igor Levicki]

(In reply to comment #10)
> As I said, the underlying problem here is the misplacement of the conxtext menu
> under certain conditions. Even when that happens, the "default size" menu is
> fully showed so it's not a big issue. This is only a big issue when the menu is
> larger than the default one, due to extensions, as the upper part appears
offscreen.
> So I would said it's minor for the default context menu and normal for an
> expanded one :-).

Ok, tell me how many people use vanilla browser without at least one extension?
Or even better, tell me how to mark it minor for you and normal severity for me
at the same time?

>I recommend you again to change the summary to something as
> "Misplaced context menu - appears offscreen is larger than default", the product
> to "Core" (it has been reporduced in both Seamonkey and Firefox - comment #5),
> and the component to "XP Toolkit/Widgets: Menus".

Done.

> It isn't good to mix more than one problem/issue per bug, so please open another
>  report and select "enhancement" as its severity.

I know. I will open it.

Comment 12

[Igor Levicki]

> It isn't good to mix more than one problem/issue per bug, so please open another
>  report and select "enhancement" as its severity.

Oh and could you please suggest category? I am unsure where it belongs.

Comment 13

[Troodon]

(In reply to comment #11)

> Ok, tell me how many people use vanilla browser without at least one extension?
I don't have numbers, but I think there may be many Firefox average users w/o
any extension. Plus all the Mozilla Application Suite users.

> Or even better, tell me how to mark it minor for you and normal severity for me
> at the same time?

:-) you can only mark it with one severity. Leave it at normal, as it is.


(In reply to comment #12)
> 
> Oh and could you please suggest category? I am unsure where it belongs.

I like the idea and I see it was already reported before. See bug 71464 and bug
143038 and give them a vote if you want :-).

Comment 14

[Igor Levicki]

Shouldn't status of this bug change to something else than UNCONFIRMED now?

Comment 15

[Troodon]

(In reply to comment #14)
> Shouldn't status of this bug change to something else than UNCONFIRMED now?
> 

I don't have the permissions to change the status of bugs. Anyway, I think it
would be good a third person to look at this.

Comment 16

[Igor Levicki]

(In reply to comment #15)
> I don't have the permissions to change the status of bugs. Anyway, I think it
> would be good a third person to look at this.

Well does ANYONE actually EVER looks at this? I mean developers? Come on people,
please, confirm this bug!

Comment 17

[Aaron Leventhal]

This is not specific to visually impaired users -- it's an issue for lower
monitor resolutions.

I was not able to directly confirm it myself because I don't have all of the
Firefox exensions you have, which are making your context menu long.

However, I believe you based on your screenshot and the behavior I see on my screen.

Comment 18

[Aaron Leventhal]

Confirmed -- not that you may need to install some extensions to make your
context menu long enough to duplicate the problem.

Comment 19

[Igor Levicki]

(In reply to comment #17)
> This is not specific to visually impaired users -- it's an issue for lower
> monitor resolutions.

And guess who is using lower resolutions? And there is a comment above which
says it is reproducible in 1024x768 too.

> I was not able to directly confirm it myself because I don't have all of the
> Firefox exensions you have, which are making your context menu long.

I have just two of them. FlashGot, and AdBlock. Both are extremely usefull.
Other browsers have long context menus too but they handle it correctly as you
may see from included screenshots of IE 6.0 and Opera 7.54.

> However, I believe you based on your screenshot and the behavior I see on my
screen.

If I understand correctly, Firefox tries to align either top or the bottom of
the menu with the cursor hotspot. However, there are situations where menu
doesn't fit on either side of the cursor hotspot. In such situations it should
displace the menu from the hotspot like IE or Opera.

I have just downloaded and unpacked the Firefox 1.0 source tree. I believe that
the problem is in:

mozilla/embedding/browser/activex/src/control/MozillaBrowser.cpp

in the function:

void CMozillaBrowser::ShowContextMenu(PRUint32 aContextFlags, nsIDOMEvent
*aEvent, nsIDOMNode *aNode)

at the beginning there is:

POINT pt;
GetCursorPos(&pt);

and later in the code is the call to TrackPopupMenu() itself:

UINT nCmd = TrackPopupMenu(hPopupMenu, TPM_NONOTIFY | TPM_RETURNCMD, pt.x, pt.y,
0, m_hWnd, NULL);

Check the description of the API and available flags:
[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/menus/menureference/menufunctions/trackpopupmenu.asp]

Presuming that I am looking at the right piece of code, this should be pretty
easy to fix either by adding flags or by changing y position manually.

Also, note that TrackPopupMenu is considered obsolete. You should use
TrackPopupMenuEx instead.

Comment 20

[Aaron Leventhal]

(In reply to comment #19)
> (In reply to comment #17)
> And guess who is using lower resolutions? And there is a comment above which
> says it is reproducible in 1024x768 too.

Why the negative attitude? I'm just agreeing with you that it's a problem, and
saying it affects a wider variety of users than those who are visually impaired.
For example, my mom uses a lower resolution even though she is not visually
impaired. Some older laptops are only capable of lower resolution.

What's the negativity for? All I did was confirm your bug and state the facts
that some extensions were required to repro it. I did not belittle the
importance of it. Sorry that I couldn't help confirm while on vacation. If you
want your bug fixed you should try having some etiquette.

Comment 21

[Igor Levicki]

(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #17)
> > And guess who is using lower resolutions? And there is a comment above which
> > says it is reproducible in 1024x768 too.
> 
> Why the negative attitude?

Offtopic:
What is negative in those two sentences? It is true that people with older
hardware and smaller screens use lower resolutions too, but that can be remedied
in other ways and visual impairment sometimes cannot like in my case.

> I did not belittle the importance of it.

Last thing I want is to argue with someone on the project, but it sounded to me
that way. But then, maybe I am too sensitive.

> If you want your bug fixed you should try having some etiquette.

I am sorry if I sounded rude but I got annoyed because despite the fact that I
have followed all the rules for reporting the bug and even gone further by
taking a peek at the source code in attempt to pinpoint the problem it seemed
that nobody cares. I could have been selfish and could have recompiled a private
build of Firefox with "my bug" fixed without bringing it here. Feel free not to
fix it if you want.

Comment 22

[Phil Ringnalda (:philor)]

Re: comment 19 - that can't be the code that does it, since
mozilla/embedding/browser/activex/ is the ActiveX support that isn't even built
with Firefox.

*** This bug has been marked as a duplicate of 245163 ***

Comment 23

[Igor Levicki]

(In reply to comment #22)
> Re: comment 19 - that can't be the code that does it, since
> mozilla/embedding/browser/activex/ is the ActiveX support that isn't even built
> with Firefox.
> 

My mistake, I presumed that TrackPopupMenu is used for menu drawing -- now I see
that there must be some custom code doing it. Talk about reinventing wheel.

> *** This bug has been marked as a duplicate of 245163 ***

And the bug #245163 will be marked as duplicate of what?

Seems that this issue will never get fixed.