2003091704 trunk 1. Open an HTML mail composition and insert a named anchor (Insert -> Named Anchor). 2. Now, do Insert -> Link. 3. Select the named anchor from the dropdown FIRST, and then type in the text for the link. RESULT: It is now IMPOSSIBLE to get the OK button to activate. EXPECTED: Activation of OK button should not depend on the order in which you complete fields.
xref bug 244020: same bug for Composer, except it doesn't matter whether text is entered first: selecting the anchor from a dropdown always prevents the OK button from enabling.
*** Bug 350468 has been marked as a duplicate of this bug. ***
The autocomplete part has worked because typing in the textbox to active autocomplete enables the button
Comment on attachment 236543 [details] [diff] [review] patch > <textbox id="hrefInput" type="autocomplete" > searchSessions="history" timeout="50" maxrows="6" > disablehistory="false" class="uri-element" > oninput="ChangeLinkLocation();"> > <menupopup class="autocomplete-history-popup" > popupalign="topleft" popupanchor="bottomleft" >- oncommand="this.parentNode.value = event.target.getAttribute('label');"/> >+ oncommand="this.parentNode.value = event.target.getAttribute('label'); doEnabling()"/> Why do you think we don't use oninput="doEnabling()"? Hint: there are two reasons, one logical, one of style.
It is very hard to find this bug based on the title of the big, even though that title is accurate. I would describe this bug as "Problem inserting link in e-mail". I'm entering this comment hoping that if others do a search on this problem this comment will make it more likely that people will find it and VOTE for it. The problem persist in Thunderbird 1.5 and 184.108.40.206
(In reply to comment #5) [fixed typo] > It is very hard to find this bug based on the title of the bug, even though > that title is accurate. I would describe this bug as "Problem inserting link > in e-mail". I'm entering this comment hoping that if others do a search on > this problem this comment will make it more likely that people will find it and > VOTE for it. > > The problem persist in Thunderbird 1.5 and 220.127.116.11 >
Contrary to the original report it is possible to get the OK button to activate. It's unacceptable, of course, but a workaround nonetheless. Copied from Bug 317363: 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.
No wonder ajschult couldn't work out what my issue was - I'd accidentally broken the ChangeLinkLocation function so that it had the same effect as doEnabling :-( Line 251 contains the correct invocation, which I have copied. Setting a textbox's value from script no longer triggers input events (bug 272002) so to fix this bug we have to call ChangeLinkLocation manually.
Comment on attachment 279905 [details] [diff] [review] Fix broken function too r=me
Attachment #279905 - Flags: review?(daniel) → review+
Comment on attachment 279905 [details] [diff] [review] Fix broken function too switching to a 18.104.22.168 nomination flag. Low risk correctness patch that shouldn't effect Firefox.
Comment on attachment 279905 [details] [diff] [review] Fix broken function too approved for 22.214.171.124, a=dveditz for release-drivers
Attachment #279905 - Flags: approval126.96.36.199? → approval188.8.131.52+
Fix checked in to the branch.
verified fixed 184.108.40.206 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:220.127.116.11pre) Gecko/20070910 Thunderbird/18.104.22.168pre Mnenhy/0.7.5.666 ID:2007091103 OK button works fine with the steps to reproduce from this bug. -> Adding verified keyword
You need to log in before you can comment on or make changes to this bug.