Closed Bug 1354563 Opened 3 years ago Closed 3 years ago
CSS file from localhost is not loaded
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170407030233 Steps to reproduce: I tried to load a website on http://localhost/ or http://192.168.1.1/. Actual results: The CSS is not loaded (nothing in the network panel). Expected results: The CSS is downloaded and interpreted (like in Firefox 53).
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 I could not reproduce this issue, tried using the latest Nightly 55.0a1 (Build ID: 20170412030252) and latest Firefox 53 Beta (Build ID: 20170411024320) and a very simple CSS like the one from here: https://www.w3schools.com/css/tryit.asp?filename=trycss_syntax_element Reporter, could you please provide a test case with the site that contains the CSS you are having this issue with?
Hello, I can still reproduce the problem with build 55.0a1 (2017-04-12)(64 bits). I have a web server on localhost, and on each local website, the CSS is not loaded. If I try to connect to my router web interface (192.168.1.1), it's the same problem : the CSS is not loaded. The CSS are correctly loaded on all other website. And it works fine on Firefox 53 for localhost. 1. I have tried to load my other Firefox profile in nightly, and the localhost CSS is ___correctly___ loaded. So it seems to be a local profile config, but I don't remember having changing something. 2. I have tried to load my Nightly profile, but without extension : the problem is still here : no CSS 3. If I download (Ctrl + S) the local webpage, the CSS is correctly downloaded in the folder 4. If I load a file:// document, the CSS is correctly loaded 5. http://localhost or https://localhost : same problem, the CSS is not loaded 6. In the devtools network panel, no CSS request is done 7. Sometimes I use a SOCKS 5 proxy, but with the proxy disabled, the problem is still here How can I help you more ?
It's pretty hard to diagnose what's wrong with your locale profile. It might be related to preferences setting (but that is just a wild guess). Could you compare your pref.js file between the 2 profiles (the one that is working and the one that is not working)? The pref.js file is located in the profile folder (go to about:support -> Open folder). IMHO, the issue you are experiencing is something related to a customization, either done by you or some extension. Based on this, until you can compare the 2 local profiles I'm marking as a WFM. Please reopen if you think that this was caused by a Firefox malfunction.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
I'm trying to compare the 2 pref.js files... But, interesting thing : I have loaded my Firefox Nightly profile in Firefox Beta and the localhost CSS is well displayed. So it seems to be a change in nightly. And I have found the problematical property with the diff ! Nightly : --------- network.http.referer.XOriginPolicy = 0 CSS OK network.http.referer.XOriginPolicy = 1 CSS NOK Beta : ------ network.http.referer.XOriginPolicy = 0 CSS OK network.http.referer.XOriginPolicy = 1 CSS OK But now, why ? :)
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Operating System:windows 10 Firefox version:52.0.2 I tried to get the CSS reader in my Firefox browser and the CSS reader is not loading and it shows error. The given bug should be RESOLVED. [bugday-20170410]
I still could not reproduce this issue, even after setting preference network.http.referer.XOriginPolicy to 1 - tried on the latest Nightly 55.0a1 (Build ID: 20170418030220) on Windows 10 x64. Patrick, could you please take a look on this? Is it expected in any way for the CSS to fail to load on the latest Nightly when network.http.referer.XOriginPolicy = 1?
Component: Untriaged → Networking
Product: Firefox → Core
does the webserver care about referer? That's what that pref controls. You can try capturing an nspr log (see about:networking) and upload it so we can diagnose how it fails - but presumably it is the server refusing to serve the content based on the referer header - there won't be anything we can do about that.
Msd+bugzilla, could you please try the suggestions from Comment 7 and post here the results?
For me, it is not the server because on Firefox Beta, it works. Easy to reproduce for me : - Create a new profile - With Nightly 55.0a1 (2017-04-18) (64 bits) - Navigate to http://localhost - CSS is OK - Change network.http.referer.XOriginPolicy from 0 to 1 - Navigate to http://localhost - CSS is NOK - Create a new profile - With firefox 53.0 (64 bits) - Navigate to http://localhost - CSS is OK - Change network.http.referer.XOriginPolicy from 0 to 1 - Navigate to http://localhost - CSS is OK I have tried what comment 7 suggest. log.txt-main.4988 is the log file on a new Firefox Nightly profile. First, I have loaded https://localhost/plop/test.html with network.http.referer.XOriginPolicy = 1. So css is not loaded. Then I have changed network.http.referer.XOriginPolicy from 1 to 0 (default) and loaded again https://localhost/plop/test.html. The CSS is now correctly loaded. I also attached the 2 files : test.html and test.css.
I could reproduce the issue on the latest Nightly 55 (Build ID: 20170419030223) using the provided test case in Comment 9. Therefore I'm setting the status of this issue to NEW. As the reporter mentioned, this issue is not reproducible on the Beta Version 53.0 - Build ID 20170413192749.
Status: UNCONFIRMED → NEW
Ever confirmed: true
thomas do you have any idea?
Assignee: nobody → tnguyen
In localhost, nsIEffectiveTLDService may fail to extract domain level then we could not set referrer of a channel. However, I am a bit surprised we bailed out of loading style if we fail to set referrer. Setting referrer failure only means we will send empty header to request. This occurs after bug is landed 1310127, that said, apparently we asserted some functions that may return false and it might have side effect sometimes. Should we use Unused in these case? I doubt we may have many other failures similar to this bug.
ni wcpan who landed bug 1310127
https://searchfox.org/mozilla-central/rev/ce5ccb6a8ca803271c946ccb8b43b7e7d8b64e7a/layout/style/Loader.cpp#1685 This line will bail out and we could not load style in some cases
(In reply to Thomas Nguyen[:tnguyen] ni plz from comment #14) > However, I am a bit surprised we bailed out of loading style if we fail to > set referrer. Setting referrer failure only means we will send empty header > to request. Sorry, it should be "Setting referrer failure only means we will not add referer header to the request". imo, the header is optional field (missing this will not break things unless the webserver care about referer :)) and we don't have to forcibly stop doing things if we fail to set the header.
Just talked to :heycam, we both agreed that return values could be ignored in layout/style/FontFaceSet.cpp and layout/style/Loader.cpp. Having a testcase for this would be good, but I'm not sure how to write one. I'll write a patch for this.
(In reply to Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] from comment #18) > Just talked to :heycam, we both agreed that return values could be ignored > in layout/style/FontFaceSet.cpp and layout/style/Loader.cpp. > I agree with that.. you might also consider whether SetReferrerWithPolicy() should be returning NS_ERROR_* here. imo the method applied the policy (even if it that means it didn't set a header as a result) and can return NS_OK. > Having a testcase for this would be good, but I'm not sure how to write one. > > I'll write a patch for this.
The referrer header is optional field and it should not block loading style MozReview-Commit-ID: fgm5A2MjRW
Attachment #8862706 - Flags: review?(cam) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/95858fbd467f Return value of setting referrer could be ignored when loading style. r=heycam
You need to log in before you can comment on or make changes to this bug.