570222 - nsIURIContentListener not consulted for dragged link clicks

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Ben Bucksch (:BenB)]

Reproduction:
1. Write your own nsIURIContentListener, where onStartURIOpen() dumps
   something on the console.
2. Create a <browser> and hook up your listener to the <browser>'s docshell.
3. Click on links normally
4. Over a link, press the left mouse button, hold it, move the mouse
   slightly (but not enough for drag&drop to get activated), and release the
   mouse button. Try it a few times (I can't reliably reproduce it every time).

Actual result:
In step 3, your listener is consulted.
In step 4, it is not.

Expected result:
All loads (primary page changes, not embedded images or scripts) call the listener.

Importance:
I try to use the nsURIContentListener for a window which should render a small HTML page (shipping with the extension) in a small window, but want all external URLs to load in the main browser. Examples are help windows or generated rich content. The window is typically too small to browse normal webpages, and has no navigation features, so a normal webpage loading in that window looks broken and is considered a bug.

In some use cases (e.g. when you cannot ensure that the Gecko of your XULRunner app has the latest security fixes, but the main browser hopefully does), this is security relevant that no external URLs load in this window and all are intercepted.

The circumstance to trigger the bug does happen during normal use, with normal users. Even though it's hard to specifically reproduce it, it's easy to run into it by accident once in a while.

Code:
var browser = document.getElementById(...);
browser.setAttribute("src", "file://...");
new BlockContentListener().hookUpIFrame(browser);

/**
 * nsIURIContentListener which allows only certain
 * URLs to load in the docshell, and calls you when
 * other URLs are attempted.
 * This is useful for small page windows, where you display rich content,
 * but want to redirect link clicks (and other types of load) into
 * the main browser window.
 */
function BlockContentListener()
{
}
BlockContentListener.prototype =
{
  QueryInterface: XPCOMUtils.generateQI([Ci.nsIURIContentListener,
      Ci.nsISupportsWeakReference ]),

  onStartURIOpen: function(uri)
  {
    dump("Shall I load <" + uri.spec + ">?\n");
    if (uri.scheme == "file") // whatever rule you like
      return false; // false = allow
    openUILinkIn(uri); // or external browser
    return true; // true = block
  },
  doContent: function(contentType, isContentPreferred, request, contentHandler)
  {
    return true;
  },
  isPreferred: function(contentType, desiredContentType)
  {
    return false;
  },
  canHandleContent: function(contentType, isContentPreferred, desiredContentType)
  {
    return true;
  },

  loadCookie: null,
  parentContentListener: null,

  hookUpIFrame: function(iframe)
  {
    iframe.docShell
        .QueryInterface(Ci.nsIInterfaceRequestor)
        .getInterface(Ci.nsIURIContentListener)
        .parentContentListener = this;
  },
}

Comment 1

[Boris Zbarsky [:bzbarsky]]

I don't see how this can possibly happen on the docshell end; any load in the docshell will call onStartURIOpen....

If you can come up with steps to reproduce that actually reproduce the problem, I'll look into it, but your steps work fine for me so far.

Comment 2

[Ben Bucksch (:BenB)]

OK, I'll check further