Links with target="_blank" don’t work when inside a frame

[Olivier Tilloy]

Steps to reproduce:

 1) Open the browser
 2) Go to http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_a_target
 3) Tap the link that reads "Visit W3Schools!" in the right frame

Expected result: http://www.w3schools.com/ is opened in a new tab
Current result: nothing happens

[Olivier Tilloy (osomon)]

The custom 'click' handler (in hyperlinks.js) is not even called when clicking inside a frame. Instead of installing it on the documentElement, it probably needs to be installed on every frame inside the page.

[Olivier Tilloy (osomon)]

In the linked branch, I’m installing the custom handler for hyperlinks on every frame in the page, as well as on the top-level document. Still this doesn’t work, for some reason the handler is never invoked when the clicked element is inside a frame. Using the inspector to inspect the event handlers (using chrome’s builtin function getEventListeners(…), see https://developers.google.com/chrome-developer-tools/docs/commandline-api#geteventlistenersobject), it appears that the frames don’t have any listeners registered, so somehow the addEventListener(…) on each frame’s document is silently failing. Needs further investigation.

[Olivier Tilloy (osomon)]

Interestingly, if I alter the contents of the frame’s document (by e.g. doing doc.write("")) in the loop that iterates over the list of frames, then the event listeners are correctly registered.

I’m also observing that if I do doc.bgColor="red" before registering the event listener, when the page is loaded the background color is red for a split second and then white again, so I’m suspecting that at the point where I’m installing the event listener the contents of the frame haven’t finished loading yet, and that for some related reason the event listener is discarded. Needs further evidence.

[Olivier Tilloy (osomon)]

Indeed, the event listener was registered too early, before the frame was fully loaded. Waiting for the frame to be loaded (listening the 'load' event) before registering the click event handler fixes the issue.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:webbrowser-app at revision 169, scheduled for release in webbrowser-app, milestone ubuntu-13.04-month-5

[Launchpad Janitor (janitor)]

This bug was fixed in the package webbrowser-app - 0.20daily13.06.11-0ubuntu1

---------------
webbrowser-app (0.20daily13.06.11-0ubuntu1) saucy; urgency=low

  [ Olivier Tilloy ]
  * Ensure that the chrome won’t be automatically hidden while testing
    interaction with the toolbar. This should fix flaky autopilot tests.
  * More reliable way of asserting that a page has finished loading.
    This should make tests more robust.
  * Always format the suggestions as rich text, to ensure ampersands are
    not incorrectly escaped. (LP: #1187432)
  * Add translators comments for the keywords associated to HUD actions.
  * Enable multiple tabs in the browser. Only the basic functionality is
    in place, further iterations will refine the functionality and the
    visuals.
  * Make as many test cases as possible inherit from
    StartOpenRemotePageTestCaseBase. This should make them overall more
    robust by avoiding race conditions with the chrome automatically
    hiding when the homepage has finished loading.
  * Ensure the suggestions list is hidden when the panel is hidden. (LP:
    #1187871)
  * Open links with target="_blank" in a new tab.
  * Install custom click event handler on all frames as well as on the
    top-level document. (LP: #1159857, #1188575)
  * Escape some special characters before highlighting them. (LP:
    #1180521)
  * Add a webbrowser-app.pot target to the build system and integrate
    with dh_translations. Also internationalize the desktop file and
    strings in C++ code.

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 171
 -- Ubuntu daily release <email address hidden> Tue, 11 Jun 2013 05:03:08 +0000