135.97 KB, image/jpeg
37.90 KB, image/png
216.65 KB, image/jpeg
Created attachment 545602 [details] [diff] [review] Unbenannt.jpg User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2 Build ID: 20110706120824 Steps to reproduce: In former versions it was able with right mouse click to insert text without formatting. But this command is missing now (See attachment). Now it is necessary to go over the edit menue. It's the same problem in german as well as the english version.
IanN: Did your Composer overlay refactoring cause this?
(In reply to comment #2) > IanN: Did your Composer overlay refactoring cause this? Well I've tested with 2.2 on both Windows XP and Windows 7 and it is still in the context menu for me, so not sure what is happening here. Does it happen in safe mode or with a new profile?
Looks to be a transient issue, because sometimes the context menu item does display. Thinking it may also be related to this, "2.2 right click menu expanded?". http://forums.mozillazine.org/viewtopic.php?f=40&t=2250815
Yes, that's true. After I changed to the english language, I realized that expanded right click menue (in the browser)with that plenty of useless stuff, too. In this case the Command "Paste without Formatting" in the right click menue of the composer was there again, but e.g. the comand for Google text search in the expanded right click menue (in the browser) was missing. After changing between the languages several times, I had this shortened menue version (see the right insertion in the screen shot) back again.
STR ... Create new Profile Start SeaMonkey Open Mail, set up a mail account (bogus information, non-working, suffices) Quit Start SeaMonkey (browser opens, SeaMonkey start page loads) [DO *NOT* right-click within the browser window] Open Error Console Open Mail (from taskbar icon) Click Compose (in Mail) (verify that expect context menu displays, including 'Paste Without Formatting') Return to the browser window, right-click to display context menu (verify that the context menu is entirely wrong [see mozillazine link above]) [each browser right-click action should generate a repeatable set of Error Console messages] Quit Start SeaMonkey (browser opens, SeaMonkey start page loads) Right-click within the browser window (verify that the context menu displays normally) Open Error Console Open Mail (from taskbar icon) Click Compose (in Mail) (verify that a right-click context menu displays 'Paste', that 'Paste Without Formatting' has gone AWOL) Return to the browser window, right-click to display context menu (verify that the context menu is normal) Quit File STR :-)
Created attachment 545830 [details] Screenshot. One funky looking (browser right-click) context menu.
I don't want THAT extended version for the broswer. I just would like the former versions for composer and browser (the browser version is okay right now). Left version ist the incomplete composer right mouse click menue and right version is the preferred (and active)version for the browser.
Created attachment 545855 [details] paste without formatting - Einfügen ohne Formatierung - is missing
This is a regression. A quick check shows it broke sometime after Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 Firefox/4.0.1 SeaMonkey/2.1 http://hg.mozilla.org/releases/mozilla-2.0/rev/ac9cf29de0d2 (I'll try to get a window later.)
Issue did not exist in SeaMonkey 2.1 release of 06/08/2011. As far as I can tell, the first 2.2 build was of 05/25/2011 & the bug does exist there. Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110525 Firefox/7.0a1 SeaMonkey/2.2a1pre http://hg.mozilla.org/mozilla-central/rev/2667493a7c91
Issue persists on the Trunk. Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110713 Firefox/8.0a1 SeaMonkey/2.5a1 http://hg.mozilla.org/mozilla-central/rev/0ac4818e5b4b
(In reply to comment #2) > IanN: Did your Composer overlay refactoring cause this? It did not cause it, but it has exposed a bug I think. The issue is that both the mail compose window and browser window have a context menu with the same id, which should not cause a problem, but does. The browser window for some reason ends up calling the onpopupshowing from the mail compose window instead of its own one.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110720 SeaMonkey/2.5a1 I see the bug and the following error messages: Error: gContextMenu is null Source file: chrome://navigator/content/mailNavigatorOverlay.js Line: 179 ---------- Error: openEditorContextMenu is not defined Source file: chrome://messenger/content/messengercompose/messengercompose.xul Line: 1
OK, I see the problem now; I normally run with the XUL cache disabled...
OK, so this seems to be some sort of weird event handler prototype problem. Since both popups are initially created by the same overlay, they presumably have the same prototype node. The event handler for the popup is not compiled until the popup is first opened (in either window). However the handler appears to get set on the prototype and reused for other instances of the popup in other windows, even though (due to subsequent overlays) the handler text itself differs. Errors thus ensue. You can work around the problem by disabling the XUL cache.
Potentially bug 672258 could now be duplicated against this (or the other way round).
OK, so here's how we can work around the bug in code. The bug depends on the nodes for the event handler having the same original prototype node (even though the nodes are no longer lightweight since the event handler attribute has since changed). So the idea is to add a dummy node in each XUL document where we overlay the event handler attribute. This dummy node should then have a unique prototype since it is not shared between different documents (except multiple instances of the same document, but that's OK since we're expecting them all to have the same event handler code anyway).
Another symptom of this bug is that center-clicking the mouse scroll-wheel on a link no longer opens the link.
(Sorry about that, Comment 21 is wrong. I picked a poor example when I tested. In Add-ons Manager, pick an Extension, then 'more', center-clicking a link in that window [like Homepage] is ineffectual, but not as a result of this bug.)
From time to time (but not very often) I've seen gigantic context menus with lots of irrelevant entries _in addition_ to the relevant entries (and maybe twice as numerous or more), in trunk builds of SeaMonkey for linux-x86_64. For instance click right in a textarea in the browser, and get a menu which is taller than the whole screen and requires scrolling to see everything — while normally, and in spite of added menuitems due to extensions, my textarea context menu is only slightly under 50% of the height of the screen. No idea what could have been different to make it happen. Usually, once it happened it remained that way for the course of the session, and went away at the next startup.
I'm getting very large context menus or incorrect context menus in SeaMonkey 2.7, they don't occur in SM 2.6.1. Seems like a regression. anyone else seeing this? Regards, Dave.
For more information, see the MozillaZine topic: [url=http://forums.mozillazine.org/viewtopic.php?f=5&t=2423081]Large or incorrect context menus in SeaMonkey 2.7[/url] Regards, Dave.
Bug 773945 might have fixed this.
Yes, this was fixed by bug 773945.