User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: 5.0b When I try to paste a url into the link window it will not let me. Reproducible: Always Steps to Reproduce: 1.Go to write click link icon 2.type title to link 3.right click to paste link into line. Actual Results: get a message "no named anchors or headings on this page". Expected Results: right click and paste url into link window

This Works For Me in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110620 Thunderbird/5.0b2pre. Does it work in -safe-mode (see http://support.mozillamessaging.com/en-US/kb/Safe-Mode) ?

Confirmed on both Linux and Windows 7 platforms, the context menu is missing in the Link Location field. Instead you get the NoNamedAnchorsOrHeadings message which is supposed to show up if you click on the drop-down menu. Ctrl+V still works after clicking into the text field to focus it. Last build I have for which the context menu still works: Mozilla/5.0 (X11; Linux x86_64; rv:2.0pre) Gecko/20110404 Thunderbird/3.3a4pre First build for which it does no longer work for me: Mozilla/5.0 (X11; Linux x86_64; rv:5.0a2) Gecko/20110504 Thunderbird/3.3a4pre Also not working on today's 7.0a1 nightly, so valid for trunk.

Also observed in SeaMonkey 2.2 beta 2 (X11; Linux x86_64; rv:5.0) Gecko/20110626 but not in the SeaMonkey 2.1 release build. Thus, possibly a Gecko 2.0/5.0 issue given that there are no related editor/ui changes. Moving to MailNews Core.

So this is about the Link Properties window, and there is a context menu, just not the usual one. Adapting summary. It's the same with SeaMonkey Composer (the HTML page editor), which is using the same file (chrome://editor/content/EdLinkProps.xul). The input field is a textbox element, ID hrefInput, class uri-element, type autocomplete. Neil, I'd bet you remember what caused this. ;-)

Comparing this to url bar, where the menupopup sits in xul is different.

Fallout from bug 642420, which we'll need to back out...

(In reply to comment #5) > Comparing this to url bar, where the menupopup sits in xul is different. Would there be a way to fix this issue on the "client" code side (later)? (In reply to comment #6) > Fallout from bug 642420, which we'll need to back out... I assume this is at least the easiest solution (in order to release SeaMonkey 2.2 (and TB 3.3) asap).

Serge, Thunderbird 5.0 (was 3.3) is out already, thus too late for it. However, the fix should land on mozilla-aurora at least...

I see, SeaMonkey 2.2 has its own relbranch on mozilla-beta, so this should work without making the Firefox people unhappy.

(In reply to comment #7) > (In reply to comment #5) > > Comparing this to url bar, where the menupopup sits in xul is different. > Would there be a way to fix this issue on the "client" code side (later)? I'm not sure what you mean; the menupopup is needed for the dropmarker, however the XBL has to be careful not to insert it as a child of the textbox-input-box because that makes it override the context menu.

Note that keyboard shortcuts still works on Mac (cmd-V) at least.

(In reply to comment #10) > (In reply to comment #7) > > Would there be a way to fix this issue on the "client" code side (later)? > I'm not sure what you mean I don't have any specific clue: I simply meant something like "without reverting bug 642420 (XPFE autocomplete.xml)"...

This was fixed by bug 642420: - TB 7.0, SM 2.4: http://hg.mozilla.org/mozilla-central/rev/29bc151be813 - TB 6.0, SM 2.3: http://hg.mozilla.org/releases/mozilla-beta/rev/a49dce91dc3c The push for mozilla-central was migrated to mozilla-aurora with the last cycle, thus all versions are covered now.

This problem has reappeared in Daily 33.0a1 in both normal and safe modes. If the keyboard workaround is "Control+P" that does not work either.

(In reply to David A. Marks from comment #20) > This problem has reappeared Please, file a new bug. (This one is archived now.)