Closed Bug 1177795 Opened 4 years ago Closed 4 years ago
Access to post
Message denied when used by unprivileged frame inside chrome:// tab
@bholley: I cannot access bug 1126911, this one should be blocking it. I strongly suspect that making window.postMessage() inaccessible was an unintended side-effect of your change there, please confirm. As things are now, it seems that an unprivileged frame inside a privileged frame has no good way of communicating with its parent. WebChannel API would be an option but from what I can tell it will only work in the desktop Firefox (not Fennec or SeaMonkey for example).
Status: UNCONFIRMED → NEW
Component: Untriaged → XPConnect
Ever confirmed: true
Product: Firefox → Core
Actually, this isn't limited to the 38 branch - reproducible in the nightly as well (tested in 41.0a1 2015-06-29 on OS X). It did start with Firefox 38 however.
Version: 38 Branch → Trunk
> I strongly suspect that making window.postMessage() inaccessible was an unintended > side-effect Not entirely. It was a secondary effect in the sense that it's not immediately fixing a known bug, but very much intended, because it would be quite easy for serious problems to arise from untrusted content posting messages to chrome code that does not expect them to come from untrusted content. We really don't want to allow that. > it seems that an unprivileged frame inside a privileged frame has no good way of > communicating with its parent. You can fire an event on yourself and the parent can register an event listener? This has the benefit of making the whole setup opt-in...
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
(In reply to Boris Zbarsky [:bz] from comment #4) > You can fire an event on yourself and the parent can register an event > listener? This has the benefit of making the whole setup opt-in... As noted in Comment 1, this is unfortunately not a complete solution for us since the same issue occurs within that iFrame for third-party scripts we have no control over.
(In reply to thomas from comment #5) > (In reply to Boris Zbarsky [:bz] from comment #4) > > You can fire an event on yourself and the parent can register an event > > listener? This has the benefit of making the whole setup opt-in... > > As noted in Comment 1, this is unfortunately not a complete solution for us > since the same issue occurs within that iFrame for third-party scripts we > have no control over. I don't understand - what does window.postMessage buy you in this case that event dispatch does not?
My impression is that these scripts are simply using top.postMessage() to see whether they will get a response - they don't expect it to throw. But I think that's something we can solve.
This change should be documented IMHO. We did study both https://developer.mozilla.org/en-US/Firefox/Releases/38 and https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/#firefox38 - no indications that this change was intended.
This means that twitter widgets don't work in nested chrome iframes and browsers. Kind of unfortunate. See bug 1185985.
Mike, we "solved" the issue with this hack: https://hg.adblockplus.org/adblockplusui/file/tip/common.js#l67. We mark the frame as running an app which makes Gecko establish a security boundary there. For the page inside the frame everything looks like it is the top frame, good enough to make Twitter widgets work.
You need to log in before you can comment on or make changes to this bug.