ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

Public bug reported:

On trunk, I'm getting the following random test failure:

FAIL!  : qml-core-test::ScriptMessageRouting_direct::test_ScriptMessageRouting_no_match(row 1) Unexpected error type
   Actual   (): 5
   Expected (): 3
   Loc: [/home/chr1s/src/oxide/class-hierarchy-cleanliness/qt/tests/qmltests/core/tst_ScriptMessageRouting_no_match.qml(44)]

The test is checking the response of the browser-side message routing
when there are no handlers available by sending a message to the frame
and having it loop back to the browser. When the browser returns an
error for the looped back message, the frame is then meant to reply to
the original request by sending the error code (which we expect to be 3
- ErrorNoHandler). In this case though, we're getting a genuine error
from the message transaction to the frame (5 -
ErrorHandlerDidNotRespond).

The content-side handler for this test that loops back to the browser
looks like this:

oxide.addMessageHandler("SEND-MESSAGE-TO-SELF", function(msg) {
  var r = oxide.sendMessage(msg.args.id, msg.args.args);
  r.onreply = function(response) {
    msg.reply({error: 0, response: response});
  };
  r.onerror = function(error, desc) {
    msg.reply({error: error, response: desc});
  };
});

What happens is that when the handler has executed, "r" goes out of
scope and then sometimes gets garbage collected before we get a reply or
error from the browser. When it gets garbage collected, we automatically
send the "DidNotRespond" error to the message source in the browser.

I'm amazed we've only just started hitting this.

This is likely to be an issue for existing consumers of Oxide, and could
affect the browser side too

** Affects: oxide
     Importance: Critical
         Status: Triaged

** Affects: webbrowser-app
     Importance: Undecided
         Status: New

** Changed in: oxide
   Importance: Undecided => Critical

** Changed in: oxide
       Status: New => Triaged

** Changed in: oxide
    Milestone: None => branch-1.7

** Also affects: webbrowser-app
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1438412

Title:
  tst_ScriptMessageRouting_no_match.qml random test failure

Status in Oxide Webview:
  Triaged
Status in Web Browser App:
  New

Bug description:
  On trunk, I'm getting the following random test failure:

  FAIL!  : qml-core-test::ScriptMessageRouting_direct::test_ScriptMessageRouting_no_match(row 1) Unexpected error type
     Actual   (): 5
     Expected (): 3
     Loc: [/home/chr1s/src/oxide/class-hierarchy-cleanliness/qt/tests/qmltests/core/tst_ScriptMessageRouting_no_match.qml(44)]

  The test is checking the response of the browser-side message routing
  when there are no handlers available by sending a message to the frame
  and having it loop back to the browser. When the browser returns an
  error for the looped back message, the frame is then meant to reply to
  the original request by sending the error code (which we expect to be
  3 - ErrorNoHandler). In this case though, we're getting a genuine
  error from the message transaction to the frame (5 -
  ErrorHandlerDidNotRespond).

  The content-side handler for this test that loops back to the browser
  looks like this:

  oxide.addMessageHandler("SEND-MESSAGE-TO-SELF", function(msg) {
    var r = oxide.sendMessage(msg.args.id, msg.args.args);
    r.onreply = function(response) {
      msg.reply({error: 0, response: response});
    };
    r.onerror = function(error, desc) {
      msg.reply({error: error, response: desc});
    };
  });

  What happens is that when the handler has executed, "r" goes out of
  scope and then sometimes gets garbage collected before we get a reply
  or error from the browser. When it gets garbage collected, we
  automatically send the "DidNotRespond" error to the message source in
  the browser.

  I'm amazed we've only just started hitting this.

  This is likely to be an issue for existing consumers of Oxide, and
  could affect the browser side too

To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1438412/+subscriptions