8

I found another odd bug... but I can only repro it in Firefox (40.0.2 for OSX). It doesn't occur in Chrome or Safari. I understand that, if it is a FF only thing, there's possibly nothing you guys can do about it, but I thought I'd put this out here anyway.

I use the magic hyperlink button to create links because they're pretty. Recently I've been noticing that, when I use it, I can't use until I click outside the text area.

The process is pretty simple:

  1. Write two lines of text (to make sure you have a "down" to go to).
  2. Highlight some of the text on the upper line.
  3. Click the hyperlink button or use Ctrl + L.
  4. Paste the link into the text area.
  5. Hit Enter/Return to close the dialogue. (Hitting the OK button will not repro the issue.)
  6. Try to use the down arrow….
  7. No response.

As long as you don't click out of the text input area, you will not be able to use the down button. Even using your mouse to move the cursor to another spot doesn't make it work. The other three direction arrows work fine.

This may or may not be related to this previous issue... I don't remember running into this issue until the last week or so.

  • 1
    Not repro'd on FF 36 (since I seldom to use it, until it asked to me update), but repro'd on FF 40 (Windows 7) – Meta Andrew T. Aug 27 '15 at 7:19
  • Thanks @AndrewT. Glad to know it's not only my computer with this issue. – Catija Aug 27 '15 at 7:20
  • 2
    Update: in my case, I cannot use both vertical arrows (up & down) after closing the dialogue without mouse click (e.g. either Enter or Esc). Left & right arrow, and mouse click to move the cursor work though. – Meta Andrew T. Aug 27 '15 at 7:47
  • FWIW, I can also repro this (and there's some discussion of this bug in the comments here). It seems that the trigger is closing the dialog popup while the URL entry field has focus. (Pressing Esc while the field doesn't have focus won't trigger this.) I've spent an hour or two trying to debug this, and I've got absolutely nowhere; I'm starting to suspect that this is a Firefox bug. – Ilmari Karonen Sep 18 '15 at 18:39
  • I can reproduce this with FF 46.0.1 on Windows. It's not just the Ctrl-L shortcut; the same thing happens with the link button in the toolbar, too. And it's just up and down; left and right still work. Switching to a different tab and back again gets my up and down arrows working again. – Joshua Taylor Jun 1 '16 at 15:16
6

Well, the bad news is that I suspect this is a Firefox bug. The good news is, I figured out what's causing it and how to work around it.

Basically, if you remove an <input> element from the DOM while it has the focus, then no focusout event will be sent for that element, and I suspect that some internal focus-related code also fails to run. In particular, if you then immediately call .focus() on a <textarea> (as the Markdown editor code does) it seems as if Firefox gets confused about what kind of an element has the focus and still thinks we're editing a single-line <input> where the up and down arrow keys don't work.

Or I might be wrong, and it might be some weird keypress event handler in SE code that gets confused. But I suspect Firefox here, since 1) this bug does not occur on Chrome, and 2) I've looked very hard for that keypress handler, and I just can't find one.

In any case, explicitly calling .blur() on the URL input box before removing the dialog from the DOM fixes this bug.

Here's a single-line patch against Markdown.Editor.js that should solve this:

--- Markdown.Editor.js  2015-09-19 00:02:09.762614897 +0300
+++ Markdown.Editor.new.js  2015-09-19 00:01:19.362615469 +0300
@@ -1102,6 +1102,7 @@
                     text = 'http://' + text;
             }

+            input.blur();  // work around Firefox bug, see https://meta.stackexchange.com/q/264307
             dialog.parentNode.removeChild(dialog);

             callback(text);

I'd submit this directly to the Pagedown project, but the Google Code project is frozen, and AFAIK there isn't an official GitHub repo yet. Hopefully balpha or someone will see this here and can apply it.


Ps. The way I ended up fixing this in SOUP is a bit more thorough:

var proto = document.body;
while ( proto && proto.removeChild && !proto.hasOwnProperty('removeChild') ) {
    proto = Object.getPrototypeOf( proto );
}
if ( !proto || !proto.removeChild ) return;

var oldRemoveChild = proto.removeChild;
proto.removeChild = function ( removed ) {
    var active = document.activeElement, node = active;
    while ( node && node !== removed ) node = node.parentNode;
    if ( node ) active.blur();
    return oldRemoveChild.apply( this, arguments );
};

Basically, this patches Node.removeChild() so that, if the currently focused element is a child of the element being removed, it will be properly defocused before it gets removed from the DOM. This seems to fix the problem, and hopefully may also proactively fix similar bugs lurking in other parts of the SE interface.

  • Bugzilla link please? – Nathan Tuggy Sep 18 '15 at 22:45
  • @NathanTuggy: I haven't checked if this has been reported as a Firefox bug yet. If not, it would be useful to try to come up with a stand-alone test case that doesn't require the whole SE JS framework. I might try to do that, but probably not today -- it's getting rather late here. – Ilmari Karonen Sep 18 '15 at 22:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .