Closed Bug 470321 Opened 13 years ago Closed 7 years ago

Security exception with document.styleSheets.cssRules (was 'Cannot view trailers')


(Web Compatibility :: Desktop, defect, P2)

Windows Vista


(Not tracked)



(Reporter: bufftallica, Unassigned)




(Keywords: top100)


(1 file)

652 bytes, application/octet-stream
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2

QuickTime doesn't work properly. For instance, it will open but no trailer will play.

Reproducible: Sometimes

Steps to Reproduce:
1.Go to
2.Try to view any trailer at any quality rate.

Actual Results:  
Quick time opens and the movie trailer cannot be played back.

Expected Results:  
Played the trailer.
Version: unspecified → 3.1 Branch
Just noticed this today on my Mac. Firefox 3.1, Build 20081201061100. Have Adblock installed but whitelisted the whole site just in case. Have noticed as well that sites sometimes don't think I have Flash installed (same build). Not sure if this is related. See

Sorry if that is unrelated.
This is a Firefox bug.  No extensions required.  Happens on all platforms.

The following exception appears in Error Console:

Error: uncaught exception: [Exception... "Security error"  code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location: " Line: 459"]

It is also a regression, but I don't have time to search for the regression range.
Flags: blocking-firefox3.1?
By the way, this also happens on the nightly trunk builds

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090302 Minefield/3.2a1pre ID:20090302033741
Hm. I see this, but only on the large size trailers. Medium and small works fine for me. When I try large, I get the Quicktime-Questionmark icon. I had been assuming it was caching errors, but I see the same error in the console

Line 459 is:

function preloadCssImages() {
	var styles = '';
	$A(document.styleSheets).each(function(sheet, i) {
		if(i != 0) {
			if(!AC.Detector.isIE()) {
>>				$A(sheet.cssRules).each(function(rule, i) {
			} else {

Which makes me suspect that this is a UA sniffing thing.

Works with and without JITing.
Ever confirmed: true
Sorry - "happens" and without JITing on, is what I meant.
Flags: blocking-firefox3.1?
Product: Firefox → Core
QA Contact: general → general
Version: 3.1 Branch → Trunk
Flags: blocking1.9.1?
So it looks like we're throwing a DOM security error here when the script attempts to grab stylesheets. Is it possible that this is running into problems due to new DOM security restrictions?
Component: General → DOM
QA Contact: general → general
Summary: Cannot view trailers. → Security exception with document.styleSheets.cssRules (was 'Cannot view trailers')
Sounds like a blocker to me.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1
On further investigation, this is NOT a Minefield regression.

It is entirely Apple's doing and as Mike Beltzner stated, "a UA sniffing thing."

Scanning the code at issue, trailer.js, it is almost as though Apple is thumbing their noses at every browser but Safari, IE, and iPhone.  I see nothing there that suggests any effort to support any other browser; but then, I'm practically a JavaScript virgin. :-)

So this might be an evangelism bug, unless there is something the devs see an actual bug somewhere.
Over to tech evangelism then. Let me know if you need contacts at apple.
Assignee: nobody → english-us
Component: DOM → English US
Flags: blocking1.9.1+
Product: Core → Tech Evangelism
QA Contact: general → english-us
Target Milestone: mozilla1.9.1 → ---
Version: Trunk → unspecified
(In reply to comment #9)
> Over to tech evangelism then...

Please also remove the Keywords: "regression" and "regressionwindow-wanted"
This should be marked RESOLVED.  Issue no longer exists.
I see this running while running Mozilla/5.0 (Windows; U; WindowsCE 6.0; en-US;
rv:1.9.2a2pre) Gecko/20090904 Namoroka/3.6a2pre
I have managed to produce a simple test case to reproduce this. The problem no longer exists on the Apple site so I don't know if this is exactly the same issue that they had, but it is the same symptoms (attempting to reference cssRules produces security error 1000).

The test case contains an external CSS file, some JavaScript to count the rules in the CSS file and a button to run the JavaScript.

function countRules() {
	var link = document.getElementById("testSheet");
	var sheet = link.sheet;
	var rules = sheet.cssRules;
	alert("There are " + rules.length + " rules in the stylesheet.");

The key to making this fail is to modify document.domain (in this case I just do document.domain = document.domain). Once this is done, all attempts to access sheet.cssRules produce a security error.

So, load the test page and click "Count Rules". An alert tells you there are two rules. Now click "Set Domain" and try the count again.

The test case is attached. You can also view it at

Why is this considered an evangelism bug?

It is an actual bug:
1. document.styleSheets[index].cssRules throws an exception if a stylesheet is loaded from another domain.
2. Exception is thrown for every stylesheet after modifying document.domain.

This prevents from parsing actual CSS; nowadays it is a common practice to host CSS on another (sub)domain or CDN.

Specs (, do not say anything about such security restrictions.
The site has possibly changed a couple of times design since the opening of this bug.
Going to the current site doesn't exhibit any issues in the logs.
Assignee: english-us → nobody
Closed: 7 years ago
Component: English US → Desktop
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.