User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Trying to create an internal link to an anchor or heading by choosing it from the drop-down list fails because the OK button is disabled. Reproducible: Always Steps to Reproduce: 1. Create a new mail message. 2. Create an anchor in the message. 3. Attempt to insert a link to the anchor by clicking Insert > Link. 4. Choose the anchor from the drop-down list. Actual Results: The OK button remains disabled, preventing the insertion of the link. Expected Results: The OK button should be enabled, allowing the creation of the link. There is a workaround to this UI problem, but because it is not exactly intuitive I've selected normal priority for this bug. The user must edit the anchor name manually, either by typing the whole thing or by selecting the anchor from the list, then editing with the keyboard in any way. For example, select it from the list, backspace over the last character, then type it back again.
See also bug #317364, "Internal links created to anchors or headings do not appear in compose window".
Hm. Reproduced with TB 1.6a1-1117, TB 1.5-1025, Seamonkey 1.0a-1013 (HTML mail and Composer), and NVu 1.0 (all Win2K). However, TB 1.0.7 and Mozilla 1.7.12 behave correctly.
This bug exists on the MAC version too. I am not sure what the mentality of the Seamonkey crew is about this issue. I have been using Netscape/Mozilla for years to create my websites, and it seems to me that the Composer component of Seamonkey is one of the most important differences between Seamonkey versus Firefox for instance. So why is no one bothering to fix this problem which has existed for well over a year? I continue to use Mozilla instead of Seamonkey for this reason. And I surely do not recommend Seamonkey to anyone new until Composer works. Yeah... I am irritated. I reported this bug as soon as Seamonkey was born, and this bug continues to be ignored. I checked out Seamonkey 1.1b... and the bug is still there.
Problem still exists in Thunderbird 18.104.22.168. I reported this bug over a year and a half ago. If we can just get a developer to look at it I imagine it would be a fairly easy fix.
bz, did we stop generating input events for scripted value changes with focus?
Uh... I have no idea. I wouldn't expect an input event in that case, however! I would be easy to check if desired by finding the regression range, if someone is willing to do that.
I thought this looked familiar...