Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.After upgrading to Media 7.x-2.0 my users are getting a blank white Media browser screen in FireFox:
In chrome, the Media popup displays normally:
In firefox, the following error displays in the console:
Error: Permission denied to access property "Drupal"
Drupal.media.popups.mediaBrowser.mediaBrowserOnLoad
x.event.dispatch
x.event.add/v.handle
The line:character where the problem is identified is 131:1 of media.popups.js which is this:
// Ensure that the iFrame is defined.
if (this.contentWindow.Drupal.media == undefined) {
return;
}
Here's what FireFox says about the error: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors...
I did some more testing on Chrome, this time on a different content type that has six fields all that use media browser, and I found some more strange behaviors. (All six "Browse" buttons in FireFox produce the same blank white screen as pictured above, and the same permission denied message.)
The first time I click a "Browse" button in Chrome, I see the Media pop-up, which shows the usual file-upload dialog, as well as a file entity form (with all the fields I've attached to Document file entities) but I also get a javascript Alert: You have not selected anything!
After dismissing the Alert, the iFrame in the media browser reloads, removing the file-entity form, and showing only the upload dialog:
Possibly Related: #1918006: JS Error when uploading new file in Media Browser on pages using SSL
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | chrome-new-dismiss.png | 47.67 KB | jenlampton |
| #7 | chrome-new.png | 91.55 KB | jenlampton |
| chrome.png | 46.96 KB | jenlampton | |
| firefox.png | 25.3 KB | jenlampton |
Comments
Comment #2
thoughtcat CreditAttribution: thoughtcat commentedI just got a similar problem in Chrome, but after clicking "upload". I am able to browse for a file but I get the blank box after clicking "upload". Both the "upload" and "web" options give this problem, but going to "library" or "my files" and selecting an existing image work fine. I have 7.x-1.4 installed on another site I manage and tested this and the process works fine there.
Comment #3
jenlamptonAdding more details of the problem to the summary...
Interesting, I'm not even getting tabs to click on. My whole iFrame fails to load at all.
Comment #4
joseph.olstadCould this be related to web server settings for X-Frame-Options and SAMEORIGIN ?
Using Firefox, check the error console , specifically 'Network' and 'XHR'
refresh the page, look for errors.
Seems like it might be related to web server settings.
Comment #5
joseph.olstadnot sure yet if this is a bug , see my comment just previous ( above ) .
Comment #6
jenlamptonUnder Network and XHR I see one single request, response 200.
Re server settings, this same problem is happening consistently across local/dev/test/live environments. It's also a new problem relating only to Media 2.0, as everything was working as expected before the security update last week (when we were running Media 1.6). No server settings have changed (on any environment) since then. (changing back to a bug report)
Comment #7
jenlamptonAdding more details to the parent issue after further testing in chrome...
Comment #8
jenlamptonAdding a better description of the double-form that appears when the dialog first opens...
Comment #9
jenlamptonAdd similar testing results in FF
Comment #10
jenlamptonI've started doing some testing by setting
X-Frame-Optionsheaders, and so far I have had limited success. I think @joseph.olstad may not be far off, though I'm pretty sure these are application-level settings, which is why I'm seeing the same thing across all environments.I expect perhaps Media 2.0 respects these headers where Media 1.6 version did not, making it appear as though there is a bug in how 2.0 works, but perhaps the bug was actually in the 1.6 version. (changing this back to a support request for now)
Comment #11
jenlamptonIt was in fact the
X-Frame-Optionsheader that was causing the problem. In my case, that header was being set by the localizejs contrib module, which prevented the site from being able to open it's own pages in iFrames. I've posted a new patch to that module that sets theX-Content-Security-PolicyandContent-Security-Policyheaders instead. Those headers can have more than a single origin -- allowing both the site itself and the localize service to open these pages in iFrames -- and their presence will supersedeX-Frame-Options.If anyone else is using this module as well as Localizejs, you may be interested in this patch: #2862735: Add X-FRAME-OPTIONS header so that localize.js can iFrame the site