1776555 - DOMException.data sometimes throws error on assignment

Status: REOPENED

(Core :: DOM: Events, defect)

Description

[toasted.nutbread]

Attachment: domexception-bug.html

DOMException's data field cannot always be assigned to, and this seems to depend on whether the function is part of a class or not. The error thrown is:

TypeError: setting getter-only property "data"

A test case file is included which has two functions: Test.test() and test(). The non-class function does not exhibit the bug and the class function does have the bug. The bodies for both functions are identical. Code is also included below:

// This works
function test() {
  const error1 = new DOMException();
  console.log({error1});
  try {
    error1.data = 'data';
  } catch (error2) {
    console.log({error2});
  }
}

// This throws error2
class Test {
  static test() {
    const error1 = new DOMException();
    console.log({error1});
    try {
      error1.data = 'data';
    } catch (error2) {
      console.log({error2});
    }
  }
}

Object.defineProperty can be used to avoid the error, but this feels like a hack.

---

Something which may or may not be related is that passing these errors across frame boundaries can generate this warning on the destination if it tries to read the object. I had this happen in the context of passing the DOMException from a WebExtension's background page to a frame on a webpage.

Security wrapper denied access to property "error" on privileged Javascript object. Support for exposing privileged objects to untrusted content via __exposedProps__ has been removed - use WebIDL bindings or Components.utils.cloneInto instead. Note that only the first denied property access from a given global object will be reported.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Kris Maglione [:kmag]]

This is the expected behavior. The data property is meant to be readonly.

The reason that you see different behavior in the class version is that class functions are automatically compiled in strict mode, which throws an error for assignments to readonly properties rather than failing silently.

Comment 3

[toasted.nutbread]

Thanks, that makes sense with regard to the different behaviour. Is this documented anywhere? I'm assuming that this is a legacy Firefox-only thing, but wasn't able to find anything about it online.

Comment 4

[Kris Maglione [:kmag]]

(In reply to toasted.nutbread from comment #3)

Thanks, that makes sense with regard to the different behaviour. Is this documented anywhere? I'm assuming that this is a legacy Firefox-only thing, but wasn't able to find anything about it online.

The behavior related to strict mode and readonly properties, and the fact that classes default to strict mode, is part of the ECMAScript specification and is documented in a number of places.

Looking closer, the data property isn't part of any specification, and it could be a valid expando property that might be accepted by other implementations, so perhaps we should consider making it writable. That said, adding unprifixed expandos to native types is always risky, particularly in the face of future interface changes.

Comment 5

[toasted.nutbread]

Sorry, I should have clarified that I was only referring to the existence of the data property; the strict mode stuff I understand and makes sense.