Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 52 users
Status: Duplicate
Merged: issue 143626
Owner: ----
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
cssRules null when stylesheets loaded from local disk
Reported by mbelshe@chromium.org, Jul 13 2010 Back to list
This code used to work, but now it fails.

I ran into this, and then searched and found that external users are hitting it too.

http://www.webdeveloper.com/forum/showthread.php?p=1095205



<html>
<head>
<link rel='stylesheet' type='text/css' href='test.css'>
<script type='text/javascript'>
window.onload=function()
{
	alert(document.styleSheets[0].cssRules);
}
</script>
</head>
<body>
</body>
</html>

 
Labels: -Area-Internals Area-WebKit
Comment 2 by karen@chromium.org, Jul 29 2010
Labels: CSS Mstone-7
Labels: WebKit-Core
Labels: -Mstone-7 Mstone-8
Labels: -Mstone-8 Mstone-9
Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting
Comment 6 by karen@chromium.org, Oct 21 2010
Labels: -Mstone-9 Mstone-X
Comment 7 by jpsyjo...@gmail.com, Nov 10 2010
This bug makes Chrome unusable for the TYPO3 backend. 
See: http://bugs.typo3.org/view.php?id=15633


This is not affecting only file urls - I can reproduce today on http://facebook.com/

1. Visit http://facebook.com/ (not logged in, just show the login screen)
2. Open the Developer Tools
3. Type: document.styleSheets[0].cssRules

Expected result: a CSSRuleList
Got instead: null

This works fine on other urls, e.g. http://google.com/

Summary: Regression: cssRules null when stylesheets loaded from cross-origin or local disk (was: NULL)
I tried document.styleSheets[0].cssRules on a bunch of sites, and about half of them failed.

I suspect that it's failing for any cross-origin CSS request.

Fails:
http://facebook.com/ (not logged in)
http://yahoo.com/
http://nytimes.com/
http://digg.com/
http://orkut.com/ (not logged in)
http://apple.com/

Succeeds:

http://google.com/
http://cmu.edu/
http://reddit.com/
http://amazon.com/
http://stanford.edu/
http://android.com/

I'm modifying the summary to change the text "when loading style sheet from local disk" to "when stylesheets loaded from cross-origin or local disk"

Summary: Regression: cssRules null when stylesheets loaded from local disk (was: NULL)
Update: I just learned that styleSheet.cssRules is supposed to respect the same-origin policy, because of the following security issue:

http://arstechnica.com/microsoft/news/2010/09/microsoft-investigates-public-ie-css-xss-flaw-twitter-hotmail-vulnerable.ars

...so, the only issue is whether an exception should be made for file:/// urls.

Changing subject to say "local disk" again.

Could it also be allowed for extension content scripts if extension has needed permissions?
Any chance of progress on this bug?  It's six months old and still not triaged. 

Unfortunately, it is currently breaking an app I'm writing with CEF that relies on local files.  In my case, both the html and the css are local files, so the same-origin policy shouldn't apply. I'm forced to instantiate an object that will trigger the rules I'm looking for, then pull out the rules from the DOM, which obliviates the entire reason for having rulesheet access in the first place.

Any help bumping this up would be appreciated.
cross-origin stylesheets are pretty common, as a lot of sites have a special domain for loading static resources (including but not limited to sites that use frameworks loaded from a CDN).

This is blocking an app of mine as well. This might actually be a webkit bug, though - I'm seeing some of the same problems in Safari...
Comment 14 by kareng@google.com, May 13 2011
Status: Available
Comment 15 by Deleted ...@, Jun 9 2011
This is a bug. If the stylesheet and the HTML are both on local disk, this bug occurs (i.e. you get a null stylesheet from document.styleSheets). This is INCORRECT as both the .html and stylesheet have the SAME origin. The same-origin policy should allow this.
I have a simple web application I also let users download onto their hard drive.

This works fine on FireFox 11 and Safari 5.1.5

On FireFox and Safari executing the following in the console returns 108:

  document.styleSheets[1].cssRules.length
  => 108

While on Chrome it returns an error because the returned cssRules is null:

  document.styleSheets[1].cssRules.length
  => TypeError: Cannot read property 'length' of null

--- 

The site in question is: http://lab.dev.concord.org/

We have a large grant from the google Foundation to develop HTML5-based scientific models, visualizations, graphing, and probeware.

You can replicate the problem easily by downloading the generated examples distribution by opening the gh-pages branch and downloading a ZIP archive bly clicking the "ZIP" link in the middle of the top of the page.

https://github.com/concord-consortium/lab/tree/gh-pages

Expand the archive and open the index.html page. Then click on the "Simple Atoms Model" link. The error I described above will prevent the page from loading properly.


You can open this page directly to see how it should work:

http://concord-consortium.github.com/lab/examples/simple-atoms-model/simple-atoms-model.html





Comment 17 by deve...@gmail.com, May 12 2012
Firefox and Safari work as expected. Why Chrome is so stupid? "Access-Control-Allow-Origin *" is not working too.
Comment 18 by deve...@gmail.com, May 14 2012
special flag is required: "-allow-file-access-from-files" (mac os x: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome -allow-file-access-from-files)
Comment 19 by amti...@gmail.com, Feb 14 2013
Firefox handles this in the following way: https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs

Should chromium handle this in the same way, or just make an exception for style-sheets?
Project Member Comment 20 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-WebKit -WebKit-Core Cr-Content Cr-Content-Core
Comment 21 by Deleted ...@, Apr 4 2013
nice posts.http://www.fuoye.edu.ng
Project Member Comment 22 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
I can confirm this problem still exists. This tool doesn't work doesn't properly with file:// because of this. https://github.com/philipwalton/html-inspector

There seem to be some other reports about this issue:
 bug 49001 
 bug 45786 
 bug 143626  
Guys, get your act together as this is blocking local apps from being compatible with Chrome, and even the new Opera builds with the new engine. Horrible..
I am building a javascript bookmarklet, but this bug is preventing me from getting all the css from a page.

If I knew how to, I would fix this bug - but I don't think I know the required programming languages :(
Fact is, they don't consider this to be a bug. This is deliberate to prevent local pages from being used as a security vulnerability. They'll never fix this, unless they change their minds. I think things like web-workers are also being blocked, but am not quite sure. I am going to rebuild my apps around this issue... Sucks but true
It seems like the only way I have then to grab all the css from a page in a javascript bookmarklet is to call a php script....That is rather annoying.

Thank you for the clarification though.
2015 and the problem continues. document.styleSheets[0].cssRules is still null when the html, css and javascript are in files on the local drive (e.g. C:\page.html, C:\page.js and C:\page.css). The odd thing that I didn't see mentioned in any of the previous posts is that the css styles are still applied to the page (e.g. color and position, etc...) but the cssRules object is still null in javascript. Is there some other property that I should be checking in the javascript or does chrome really apply the css rules without providing access to js?
The styles are applied, but they can not be accessed via cssRules. This is intentional, however you can still manipulate styles by creating a style element and editing it's textContent..
Comment 30 by tkent@chromium.org, Jul 15 2015
Labels: -Cr-Content-Core
Components: -Blink Blink>Bindings
Labels: -Mstone-X -CSS mstone-X css
Status: Untriaged
Components: Blink>CSS
Cc: yukishiino@chromium.org
Components: -Blink>Bindings
Due to a quick investigation,

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/CSSStyleSheet.cpp&q=CSSStyleSheet::canAccessRules&sq=package:chromium&l=237

CSSStyleSheet::canAccessRules() defines what can access to the property.  If we really want to allow the access to the style sheed loaded from file://, this seems the part to work on.  But, I'm suspicious, probably we shouldn't allow it.

For the general solution, if users specify --allow-file-access-from-files command-line flag to Chromium, you can access to style sheets loaded from file:// from html loaded from file://.

Maybe, this issue would be WontFix, but I defer the decision to Blink>CSS owners, just in case that we'd like to allow file-to-file access for stylesheets by default.
Labels: -css -mstone-X Hotlist-Interop OS-All
Status: Available
Summary: cssRules null when stylesheets loaded from local disk (was: Regression: cssRules null when stylesheets loaded from local disk)
Components: -Blink>CSS Blink>SecurityFeature
Mergedinto: 143626
Status: Duplicate
This was wontfixed in https://bugs.chromium.org/p/chromium/issues/detail?id=143626#c11
Sign in to add a comment