Closed Bug 883222 Opened 9 years ago Closed 6 years ago
Firefox 21 and Ember
.js calls on an event throws 'Permission denied to access property' error
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36 Steps to reproduce: On marqueed.com, when you click an image in a collection to view it which uses Ember.js to build the element, it throws an error. Actual results: In the console we get this error: Error: Permission denied to access property '__ember1370634036480_meta' Expected results: It should load the ember object and insert it into the DOM.
Thanks for reporting! Karl, can you provide an url for that? Have you had this problem with older Firefox versions?
Assignee: nobody → general
Product: Firefox → Core
Thanks for the response! No we never had this issue with older versions of Firefox. It only appeared on the latest version 21. I created a temporary workaround but here is a link where it will occur occasionally: https://www.marqueed.com/collections/51534 Thanks!
Bogus permissions checks are troubling.... :(
Too late to fix a FF21 regression in FF22. Apologies.
Thanks Alex, any idea when this issue will be able to be addressed?
(In reply to Karl Gusner from comment #5) > Thanks Alex, any idea when this issue will be able to be addressed? Depends on the priority/investigation we give - we'll have a better idea over the next couple of weeks. Would be great to get resolved in FF23.
I can't seem to reproduce by just clicking around on the images in comment 2. Karl, can you give more precise steps to reproduce?
Here is an example without the workaround I created on our production site: https://mq-staging.herokuapp.com/collections/547 Click any of the images to see the error: Error: Permission denied to access property '__ember1371587940456_meta' I think this issue might be related to how FF21 handles events with ember as this isn't an issue when we load the ember object on page load rather than on an event, which you can see when you visit this URL: https://mq-staging.herokuapp.com/collections/547/images/4509
(In reply to Karl Gusner from comment #8) > Here is an example without the workaround I created on our production site: > > https://mq-staging.herokuapp.com/collections/547 I just played with this in a debugger. The issue is that (at least) one of your subframes is cross-origin, which causes Ember to bork (as it should) when trying to attach expandos to it. In the above, window is the cross-origin window in question. Do you expect the subframe to be cross-origin?
No I don't expect the subframe to be cross-origin, how exactly can you tell that its cross-origin? Also why would it be cross-origin when reacting to an event but not cross-origin when auto-loaded like in this case: https://mq-staging.herokuapp.com/collections/547/images/4509 Also, why does this work in Chrome, Safari and older versions of FF but not FF21?
(In reply to Karl Gusner from comment #10) > No I don't expect the subframe to be cross-origin, how exactly can you tell > that its cross-origin? By doing window.document in the web console, and observing the subsequent permission error. > Also why would it be cross-origin when reacting to an > event but not cross-origin when auto-loaded like in this case: > > https://mq-staging.herokuapp.com/collections/547/images/4509 From debugging this in C++, it appears that the cross-origin frame's principal is about:blank. This means that a new frame was created that didn't inherit the caller's principal. There are a number of reasons why this can happen, many of them per-spec. > Also, why does this work in Chrome, Safari and older versions of FF but not > FF21? Presumably because the behavior in Firefox changed. Figuring out whether the new or old behavior is spec correct involves reducing the testcase. This is hard for me to do myself, because the JS is minified and uses a bunch of other goop. Once you can confirm you observe the cross-origin behavior, would you mind reducing the testcase?
If we now have a reliable way to reproduce, finding the first nightly (or even tinderbox) build the problem appeared in, and the last one it did not appear in, would also be very helpful...
Thanks for testing and debugging! I will make a reduced testcase as soon as I can to help determine if the behavior is spec correct.
Try as I might I've been unable to reproduce this issue. I tried loading https://mq-staging.herokuapp.com/collections/547 and clicking on several images but it doesn't throw the error for me. I checked Browser Console, Web Console, and Firebug but in neither case do I see this error being thrown. I've tested Firefox 21, 22.0, 23.0a2, and 24.0a1 on Windows 7, Ubuntu 12.04, and Mac OSX 10.8. Unfortunately, QA will be unable to assist in finding a regression window until a reliable minimized testcase can be provided.
This has been in releases for two releases, so no need to track further. We would take a low risk uplift though.
Resolving this as incomplete due to inactivity. If there is still a reproducible issue here, feel free to reopen the bug (and bonus points for including a minimal testcase!).
You need to log in before you can comment on or make changes to this bug.