← Back to team overview

ubuntu-webapps-bugs team mailing list archive

[Bug 1495284] [NEW] Allow ScriptMessageHandlers to be registered with WebContext

 

Public bug reported:

Currently UserScripts are registered with WebContext, but
ScriptMessageHandlers (the bit that allows user scripts to communicate
with message handlers in the browser) are registered with individual
WebViews (or even WebFrames). I'm not sure this makes complete sense -
imagine the following scenario:

- An embedder wants to provide a simple extension mechanism.
- The extension mechanism allows for UserScripts to be installed.
- The extension mechanism provides a simple browser-side script environment for running extension code in.
- The browser-side script environment allows the extension code to add message handlers to receive messages from its user script.

Today, the embedder would have to create a ScriptMessageHandler on every
WebView in response to the extension code adding a message handler. It
would also add extra complexity when initializing new WebViews.

We could avoid this by allowing ScriptMessageHandlers to be registered
with the WebContext. In some ways this makes sense, given that
UserScripts are already registered there, and ScriptMessageHandler is
the mechanism by which UserScripts interface with browser code.

** Affects: oxide
     Importance: Medium
         Status: Triaged

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

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

-- 
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/1495284

Title:
  Allow ScriptMessageHandlers to be registered with WebContext

Status in Oxide:
  Triaged

Bug description:
  Currently UserScripts are registered with WebContext, but
  ScriptMessageHandlers (the bit that allows user scripts to communicate
  with message handlers in the browser) are registered with individual
  WebViews (or even WebFrames). I'm not sure this makes complete sense -
  imagine the following scenario:

  - An embedder wants to provide a simple extension mechanism.
  - The extension mechanism allows for UserScripts to be installed.
  - The extension mechanism provides a simple browser-side script environment for running extension code in.
  - The browser-side script environment allows the extension code to add message handlers to receive messages from its user script.

  Today, the embedder would have to create a ScriptMessageHandler on
  every WebView in response to the extension code adding a message
  handler. It would also add extra complexity when initializing new
  WebViews.

  We could avoid this by allowing ScriptMessageHandlers to be registered
  with the WebContext. In some ways this makes sense, given that
  UserScripts are already registered there, and ScriptMessageHandler is
  the mechanism by which UserScripts interface with browser code.

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