Clarify error message for cross-domain JS access




DOM: Core & HTML
8 years ago
8 years ago


(Reporter: zwol, Unassigned)



Firefox Tracking Flags

(Not tracked)




8 years ago
Suppose this HTML document is accessible as either or, and /testB.html exists on the same server:

    <!doctype html>
    <iframe id="x" src=""></iframe>
    <script type="application/javascript;version=1.7">
    window.onload=function() {
    let x = document.getElementById("x");
    let a = x.contentDocument.getElementsByTagName('a');

If you load this as https://... the Javascript works.  If you load it as http://..., however, you get this error message:

Permission denied for <> to get property HTMLDocument.getElementsByTagName from <>

The problem is not very obvious, and you might think there was something wrong with the browser.  It would be helpful if we told people exactly which part of the origin didn't match, so in this case

Permission denied for <> to get property HTMLDocument.getElementsByTagName from <>. Protocols don't match.

There are only a half-dozen sentences required, so I think we might as well just spell out all the possibilities as we hit them:

Protocols don't match.
Hosts don't match.
Ports don't match.
Protocols and hosts don't match.
Protocols and ports don't match.
Hosts and ports don't match.
Protocols, hosts, and ports don't match.
So... For what it's worth, there are currently 4 different possible strings here (thanks to document.domain).  This is for property gets.  There are also 4 for property sets, and 4 for function calls.  Total of 12.

If we added differentiation as above (7 clarifying strings saying what didn't match), then we'd need 84 different strings, right?

There's got to be a better way of doing this....
Oh, and in the code that constructs this there are actually more cases than the 12 I listed, because there is sometimes no object principal or some such....

Comment 3

8 years ago
We could treat the clarifying strings as separate l10n tags from the "what wasn't allowed" strings, concatenating them after translation but before passing to the console message constructor?  Like what I did in bug 524223 for the clarification messages that couldn't be translated.  And hopefully l20n gives us better options...?
Concatenation after translation is pretty chancy.  It often gives .... suboptimal output.

Comment 5

8 years ago
I don't think that edge cases like this in the setup are really worth going into the trouble of adding tons of more strings, or ughly hacks in our current infra.

We can revisit this once l20n is ready for production, though. That doesn't imply that I'm really convinced this is good to do even then.
This isn't an edge case, though.  This is a fundamental issue of us reporting not-very-useful error messages when we have more information that could make them more useful...

If it weren't for l10n issues, I'd do this in a heartbeat, using the approach from comment 3.  Maybe we should just do that and ignore the l10n problems it causes?
You need to log in before you can comment on or make changes to this bug.