MonkeeSage,

About bug 323 - no context menu for images when there's a background image present - can you verify that this is still a problem in Mozilla 1.4a builds ?

If not then forget this, if so then the problem seems to be in Mozilla file embedding/browser/webBrowser/nsDocShellTreeOwner.cpp, routine ChromeContextMenuListener::ContextMenu - it looks like once a background image is detected (which would be right away) the do while loop is exited via break and no other elements are searched for.

Change:

if (!(flags & nsIContextMenuListener::CONTEXT_IMAGE)) {
// first check if this is a background image that the user was trying to click on
// and if the listener is ready for that (only nsIContextMenuListener2 and up)
if (menuInfoImpl && menuInfoImpl->HasBackgroundImage(node)) {
flags2 |= nsIContextMenuListener2::CONTEXT_BACKGROUND_IMAGE;
}
}
break; // exit do-while

to: (add the else goto)

if (!(flags & nsIContextMenuListener::CONTEXT_IMAGE)) {
// first check if this is a background image that the user was trying to click on
// and if the listener is ready for that (only nsIContextMenuListener2 and up)
if (menuInfoImpl && menuInfoImpl->HasBackgroundImage(node)) {
flags2 |= nsIContextMenuListener2::CONTEXT_BACKGROUND_IMAGE;
}
else
goto test_element;
}
break; // exit do-while

The label test_element should be placed just before the following which is about 8 lines further down and after the last else if:

test_element:
// Test if the element has an associated link
nsCOMPtr<nsIDOMNamedNodeMap> attributes;
node->GetAttributes(getter_AddRefs(attributes));

asmpgmr:

I followed the test case over at Bugzilla:
http://bugzilla.mozilla.org/show_bug.cgi?id=178988

Steps to Reproduce:
1. Launch MFCEmbed and browse to http://www.penny-arcade.com/view.php3
2. Right-click on main cartoon image

I get the correct context menu. So this bug appears to be fixed in the 1.4b branch. Though the bug is still very much there that no matter where you click on the page, you always get the image context menu.

In a day or so I will try incorporating your fix into the 1.2.1 mozilla tree and see what happens.


Shelumi`El
Jordan

S.D.G

MonkeeSage,

If you right click on the main logo on this page do you get a context menu in 1.4b - http://members.aol.com/AXCEL216/

As for getting an image context menu for the background image, once the Mozilla code is definitely working then the issue as to what context menu appears can be easily changed in K-Meleon.

MonkeeSage,

The Mozilla 1.2.1 nsDocShellTreeOwner.cpp code is slightly different, the relevant section of code in routine ContextMenu was moved around for the fix. Based upon the change log for that file it should be possible to simply incorporate the current file into 1.2.1 and rebuild whatever dll (docshell.dll ?) it's part of.

Maybe nsDocShellTreeOwner.cpp is part of webbrwsr.dll ?

MonkeeSage,

Did you get a chance to look at this yet ? It's probably better to use the nsDocShellTreeOwner.cpp code from 1.4 if it works and rebuild the .dll and then address any remaining issues in K-Meleon code.

asmpgmr:

The page you linked to works correctly in 1.4b, and the right context menu shows up anywhere on the page. So I'll try the 1.4 code in 1.2.1 and see what happens. I'll let you know if it compiles.


Shelumi`El
Jordan

S.D.G

Using the header from 1.4b didn't work, I will try your fix and see if that works.


Shelumi`El
Jordan

S.D.G

MonkeeSage,

My code change probably won't work, can you make the minor change in the 1.2.1 nsDocShellTreeOwner.cpp routine ContextMenu to make it like 1.4b and recompile it ?

Here's the link which shows the differences:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsDocShellTreeOwner.cpp&root=/cvsroot&subdir=mozilla/embedding/browser/webBrowser&command=DIFF_FRAMESET&rev1=1.71&rev2=1.72

This link will probably make this thread really wide unfortunately.

See Bugzilla:

http://bugzilla.mozilla.org/show_bug.cgi?id=194954

asmpgmr:

OK, replacing the 1.2.1 routine ChromeContextMenuListener::ContextMenu with the one from 1.4b works. Seems that the bug is fixed. Tested against thw Moz test case as well as the page you linked to above. The mozilla build process is all one unit, so I had to rebuild the whole thing and let it build any files with newer access dates than the last build date (i.e., nsDocShellTreeOwner.cpp) and re-link them with all the other objects (otherwise lots of linker errors). I would assume that you are correct; that it is webbrwsr.dll that the code from nsDocShellTreeOwner.obj ends up being linked in.

The 1.2.1 installer is updated with the fixed mozilla dll(s?).Confirm if it is working correctly and I'll mark this on the list of changes.


Shelumi`El
Jordan

S.D.G