JavaScript limits to prototype-based inheritance?

Question

This is not a question about how to extend JS natives and I am well aware of the "dangers" involved with such activity. I am only trying to get a deeper understanding of how JavaScript works. Why is it that if I write the following:

CSSStyleSheet.prototype.sayHi = function() {
    console.log('CSSStyleSheet says hi!');
};

var test = new CSSStyleSheet;
test.sayHi();  // Console output: CSSStyleSheet says hi!

I get the expected output from the sayHi function. But if I then query a style element and produce a CSSStyleSheet object from it via the sheet property, the sayHi function is not defined:

var styleElm = document.querySelector('style'),
    sheet = styleElm.sheet;
console.log('sheet', sheet)  // Console output: sheet CSSStyleSheet {ownerRule: null,...
sheet.sayHi();  // Console output: Uncaught TypeError: sheet.sayHi is not a function

What is the reason for this? What would I have to do to make the sayHi function available to a CSSStyleSheet object produced via the sheet property - is it even possible?

The test was run in Chrome.

EDIT:

The reason I am looking into this is because I am trying to weigh my options when it comes to simplifying existing code. I have made an API to manipulate internal styles of a document loaded in an iFrame. It works as intended, but I would like to simplify the code if possible. It builds on the CSSOM API, which allows access to individual CSS style rules via numerical indexes. Having numerical indexes as the only way to access CSS rules seems quite rudimentary since you would never request a particular index unless you knew what rule the index pointed to. That is, you would always need to have info about the selector text. But it is the only way that makes sense in a broad context given the cascading nature of CSS (where you can have the same selector text as many times as you like).

However, my API keeps things in order so that every selector text is unique. Therefore, it makes sense to index the rules so that the main way of accessing them is via their selector text and my API does just that. However, things can quickly get less elegant when more than one level of rules are in play, i.e. if you have a number of media query rules containing their own index of CSS rules.

So I am just wondering if I can do anything to simplify the code and I must admit that were it not for the in this thread illustrated problems with hosted objects, i might have considered extending the CSSStyleSheet object.

Are there any other approaches, I might consider?

Answer 1

As it turned out, the issue is not about hosted object prototype limitations: while there are truly some, your particular example should work fine. The real problem is attempting to access this augmented prototype within iframe, which has its own global object. While there's a link between iframe's window and its host window, it's not used in the name resolving mechanism (few exceptions aside).

So the real challenge is to access host properties from within iframe. Now there are two ways of doing this: the easy one and the usual one.

The easy one is based on assumption that host and iframe share the same domain. With CORS concerns out of the way, you can connect those through parent property, as...

When a window is loaded in an <iframe>, <object>, or <frame>, its parent is the window with the element embedding the window.

For example:

// host.html
<script>
CSSStyleSheet.prototype.sayHi = (space) => { 
  console.log(`CSSStyleSheet says hi! from ${space}`);
};
</script>
<iframe sandbox="allow-same-origin allow-scripts" src="iframe.html" />

// iframe.html
<button>Say Hi!</button>
<script>
  Object.setPrototypeOf(CSSStyleSheet.prototype, parent.CSSStyleSheet.prototype);
  document.querySelector('button').onclick = () => {
    new CSSStyleSheet().sayHi('inner space');
  };
</script>

... and it should work. Here, Object.setPrototypeOf() is used to connect CSSStyleSheet.prototype of a parent (host) window to iframe's own CSSStyleSheet.prototype. Yes, garbage collector suddenly has got more work to do, but technically this should be considered a problem of browser writers, not yours.

Don't forget to test this on proper HTTP(S) Server locally, as file:/// based iframes are not really cors-friendly.

---

If your iframe is from another castle domain, things get way more interesting. In particular, any attempt to access parent directly is just blocked with that nasty Uncaught DOMException: Blocked a frame with origin "blah-blah" message, so no free cookies.

Technically, however, there's still a way to bridge that gap. What follows is some food for thought, showing that bridge in action:

console.clear(); // check the browser console; iframe's one won't be visible here
CSSStyleSheet.prototype.sayHi = (space) => { 
  console.log(`CSSStyleSheet says hi! from ${space}`);
};
document.querySelector('button').onclick = () => {
  new CSSStyleSheet().sayHi('outer space');
};

const html = `<button>Say Inner Hi!</button><br />
<script>
  parent.postMessage('PING', '*'); // HANDSHAKE
  document.querySelector('button').onclick = () => {
    new CSSStyleSheet().sayHi('inner space');
  };

  addEventListener('message', (event) => {
    const { data } = event;
    if (data === null) {
      delete CSSStyleSheet.prototype.sayHi;
    }
    else {
      CSSStyleSheet.prototype.sayHi = eval(data);
    }
  }, false);
<` + `/script>`;

const iframe = document.createElement('iframe');
const blob = new Blob([html], {type: 'text/html'});
iframe.src = window.URL.createObjectURL(blob);
document.body.appendChild(iframe);

let iframeWindow = null;
addEventListener('message', event => {
  if (event.origin !== "null") return; // PoC
  if (event.data === 'PING') {
    iframeWindow = event.source;
    console.log('PONG');
  }
}, false);

document.querySelector('input').onchange = ({target}) => {
  if (!iframeWindow) return;
  iframeWindow.postMessage(target.checked 
    ? CSSStyleSheet.prototype.sayHi.toString()
    : null, 
  '*'); // augment the domain here
};

<button>Say Outer Hi!</button> 
<label><b>INCEPTION MODE</b><input type="checkbox" /></label><br/>

The key part here is passing the stringified function from host to iframe through postMessage mechanism. It can (and should) be hardened:

• using proper domain instead of '*' on postMessage and checking event.origin within eventListener is A MUST; never ever use postMessage in production without that!
• eval can be replaced with new Function(...) with some additional parsing for that handler code; as that prototype function should live until the page does, GC shouldn't be a problem.

Still, using this bridge may not be particularly less complicated than the approach you employ right now.

Answer 2

Your code should work.

You can also call it using sheet.__proto__.sayHi()

Answer 3

Your code (as written in the question) will work, because you are modifying the prototype object that is linked to by all instances of CSSStyleSheet (no matter when they were created).

The reference to the prototype object (more precisely: the [[Prototype]]) is examined dynamically every time a property look-up is attempted on an object without an own property that matches the requested property name. An own property is a property directly situated on an object.

In your case you are using the dot property accessor syntax sheet.sayHi. Property sayHi is not found as an own property, and so the prototype chain is traversed. It is then found on the prototype object that you modified on line 1. You then invoke the method located on that property using (), and 'CSSStyleSheet says hi!' is printed out.

Try it!

CSSStyleSheet.prototype.sayHi = function() {
    console.log('CSSStyleSheet says hi!');
};

const test = new CSSStyleSheet;
test.sayHi();  // Console output: CSSStyleSheet says hi!

const styleElm = document.querySelector('style'),
      sheet = styleElm.sheet;
sheet.sayHi()