1198472 - API for inspecting loaded content

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Runtime, defect)

Description

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

For example atom-shell webview exposes API similar to frame scripts, that lets you interact with a DOM loaded in the web view and communicate with a web view embedder via message passing. For we already have a use case where we would like to grab twitter cards from the loaded page and only way for this would be to change an API to add more metadata. But this won't scale there always may be a new thing that embedder may need to do with in the web view. I think web view should be a able to contain a script element that would be evaled in the shell of the web view. I imagine something along these lines:

<webview>
    <script>
      const isTwitterCard = node =>
        node.tagName === "meta" &&
        node.getAttribute("name").startsWith("twitter:")
      const toInnerHTML = node => node.innerHTML

      content.addEventListener("DOMContentLoaded", () => {
        const cards = Array.from(document.querySelectorAll("meta"))
                          .filter(isTwitterCard)
        postMessage(cards.map(toInnerHTML))
      })
    </script>
</webview>
<script>
    document.querySelector("webview").addEventListener("message", handleCrads)
</script>

Basically the way I propose model web view is like an iframe with nested content iframe with in it. So scripts could run in the outer iframe and messages could be exchanged with it like with regular iframes now. Outer iframe also should be able to interact with (content) sub iframe as more privileged iframes can with less privileged iframes if they're with in the same process.

Comment 1

[Ben Francis [:benfrancis]]

I just wanted to mention that this was an explicit non-goal of the original Browser API design.

Early in the life of the Browser API we considered two options:
1) Allow the browser web app to inject JavaScript into embedded iframes in order to access and modify anything it wants to about the embedded content
2) Build an explicit API to poke holes in the cross-origin boundary for specific pieces of metadata and functions the browser needs

We chose option 2 because we wanted to build a safe API which third party browser web apps could use to build alternative browser apps for Firefox OS.

I wrote about this in more length in this blog post https://hacks.mozilla.org/2014/08/building-the-firefox-browser-for-firefox-os/

Things have changed a little now because the browser in Firefox OS has merged with the system app and it doesn't make a whole lot of sense to build an alternative browser for that OS. But I still think that if we ever want to standardise a <webview> HTML tag the ability to inject JavaScript into cross-origin frames is impossible to make safe. This is much more privileged than any of the other Browser API capabilities and if this API is created it should probably require a separate permission. (I think getScreenshot should be a separate permission too).

For the specific use case you mention of accessing Twitter meta tags in web pages, we have a very similar requirement in Firefox OS to access Open Graph metadata. For this we are adding to the existing metachange event in bug 1178484 to fire an event when an og: meta tag is added into the DOM. We could extend this to Twitter meta tags as well, or in fact all meta tags. If the events become too frequent and start to effect performance (is that really likely?), we could build a getMetadata() method, but bear in mind the reason we use events is that meta tags can be inserted into the DOM at any time, so you'd only get a snapshot of the current page.

Comment 2

[[:fabrice] Fabrice Desré]

What's missing from bug 1174733 that you still need?

Comment 3

[Paul Rouget [:paul]]

bug 1174733 doesn't run as a worker. It runs to completion and return the final value of the script to the parent.

Comment 4

[[:fabrice] Fabrice Desré]

But the script is still injected in the page right? It can still listen to events etc. Also it could spawn a worker ;)

Comment 5

[Paul Rouget [:paul]]

But once it runs completion, there's not way to talk back to the parent process.

Comment 6

[BMO Automation]

Firefox OS is not being worked on