1354563 - CSS file from localhost is not loaded

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[msd+bugzilla]

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).

Comment 1

[Simona Badau, Desktop QA]

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?

Comment 2

[msd+bugzilla]

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 ?

Comment 3

[Simona Badau, Desktop QA]

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.

Comment 4

[msd+bugzilla]

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 ? :)

Comment 5

[Aravind Arul]

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]

Comment 6

[Simona Badau, Desktop QA]

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?

Comment 7

[Patrick McManus [:mcmanus]]

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.

Comment 8

[Simona Badau, Desktop QA]

Msd+bugzilla, could you please try the suggestions from Comment 7 and post here the results?

Comment 9

[msd+bugzilla]

Attachment: test.html test.css log.txt-main.4988

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.

Comment 10

[Simona Badau, Desktop QA]

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.

Comment 11

[Patrick McManus [:mcmanus]]

thomas do you have any idea?

Comment 13

[Thomas Nguyen (: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 used Unused in these case?

I doubt we may have many other failures similar to this bug.

Comment 14

[Thomas Nguyen (: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.

Comment 15

[Thomas Nguyen (:tnguyen)]

ni wcpan who landed bug 1310127

Comment 16

[Thomas Nguyen (:tnguyen)]

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

Comment 17

[Thomas Nguyen (:tnguyen)]

(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.

Comment 18

[Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] (left Mozilla)]

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.

Comment 19

[Patrick McManus [:mcmanus]]

(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.

Comment 20

[Thomas Nguyen (:tnguyen)]

Attachment: Return value of setting referrer could be ignored when loading style The referrer header is optional field and it should not block loading style

MozReview-Commit-ID: fgm5A2MjRW

Comment 21

[Thomas Nguyen (:tnguyen)]

Attachment: Return value of setting referrer could be ignored when loading style

The referrer header is optional field and it should not block loading style

MozReview-Commit-ID: fgm5A2MjRW

Comment 22

[Thomas Nguyen (:tnguyen)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a7042e75ac53d3c40d97035c97fddc6f426c2a17

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/95858fbd467f
Return value of setting referrer could be ignored when loading style. r=heycam

Comment 24

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/95858fbd467f