671192 - Command "Paste without Formatting" in message window is missing

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Glutton.Vidal]

Attachment: 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.

Comment 1

[Glutton.Vidal]

Attachment: Screenshot

Comment 2

[Philip Chee]

IanN: Did your Composer overlay refactoring cause this?

Comment 3

[Ian Neal]

(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?

Comment 4

[therube]

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

Comment 5

[Glutton.Vidal]

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.

Comment 6

[therube]

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 :-)

Comment 7

[therube]

Attachment: Screenshot. One funky looking (browser right-click) context menu.

Comment 8

[Glutton.Vidal]

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.

Comment 9

[Glutton.Vidal]

Attachment: paste without formatting - Einfügen ohne Formatierung - is missing

Comment 10

[therube]

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.)

Comment 11

[therube]

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

Comment 12

[therube]

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

Comment 13

[Ian Neal]

(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.

Comment 15

[Philip Chee]

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

Comment 16

[[e-mail]]

OK, I see the problem now; I normally run with the XUL cache disabled...

Comment 17

[[e-mail]]

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.

Comment 18

[Ian Neal]

Potentially bug 672258 could now be duplicated against this (or the other way round).

Comment 20

[[e-mail]]

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).

Comment 21

[therube]

Another symptom of this bug is that center-clicking the mouse scroll-wheel on a link no longer opens the link.

Comment 22

[therube]

(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.)

Comment 25

[Tony Mechelynck [:tonymec]]

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.

Comment 26

[Dave Young]

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.

Comment 27

[Dave Young]

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.

Comment 29

[[e-mail]]

Bug 773945 might have fixed this.

Comment 30

[[e-mail]]

Yes, this was fixed by bug 773945.