1427416 - [FF58] Console showing output from other tabs for "blocked mixed-content" when stylo is enabled

Status: RESOLVED DUPLICATE of bug 1420680

(DevTools :: Console, defect)

Description

[Ashutosh Sharma]

Attachment: screenshots.tar.xz

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171226085105
Firefox for Android

Steps to reproduce:

I just migrated a website from staging server (HTTP) to the live server (HTTPS) and when I open the console on HTTPS, i.e., is the live website, it shows "blocked mixed-content" warning from the staging website (which is using HTTP.) Both the websites are on different servers and different domains. I have already checked the links and they are all correct (HTTPS)


Actual results:

Somehow Firefox is requesting the content from both the websites (opened in different tabs) on the same tab.


Expected results:

Console should only show the messages for current opened tab.

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

Hello Ashutosh, thanks for filing this bug.
I can't open the attachment file. Could you upload a jpeg file showing the error please ?
Also, is there a way I can go to the page you are working on so I can see the errors ?

Thanks

Comment 2

[Matt Cosentino]

I see this too, I'll attach a screenshot.

Comment 3

[Matt Cosentino]

Attachment: Blocked active content from another tab

This current tab is

https://support.mozilla.org/en-US/kb/mixed-content-blocking-firefox

The other tab is a video stream from mlb.com

Comment 4

[Jean-Philippe Eisenbarth]

Attachment: Blocked mixed content errors from another tab

I noticed this issue too, I attached a screenshot.

My current tab was https://support.mozilla.org/en-US/kb/mixed-content-blocking-firefox and the other tab was http://pm2.keymetrics.io

It happens when I specifically browsed pm2.keymetrics.io without HTTPS.

support.mozilla.org isn't the only site where the console displays these errors, if I remember correctly it happened also with https://community.letsencrypt.org/ (not with the pm2 website but I do not remember which one).

I can reproduce with Firefox 58, 59 and 60 but cannot with Firefox 52 (ESR version)

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

Jean-Philippe, are you reproducing this every time ?
I tried but failed, and it would really help if we have a way to reproduce

Comment 6

[Matt Cosentino]

I can reproduce it every time with those two URLs.

Comment 7

[Jean-Philippe Eisenbarth]

Yes, I can reproduce this everytime.

My OS is GNU/Linux Debian 9 and as I said above with Firefox ESR (the version in the Debian repo) I cannot reproduce.

A few weeks ago I wanted to try Firefox 58 (and 59, 60), I manually downloaded and installed (from here https://www.mozilla.org/fr/firefox/new/ and here https://www.mozilla.org/fr/firefox/channel/desktop/#beta for Beta and Nightly) . I started to notice this issue last week but I wasn't really paying attention before.

I also tried with Firefox 58 on Windows 10 and surprisingly I could't reproduce ...

Comment 8

[Nicolas Chevobbe [:nchevobbe]]

Jean-Philippe, it would help us tremendously if you could use mozregression[1] to see what changes caused this issue

https://mozilla.github.io/mozregression/quickstart.html

Comment 9

[pieter]

I see the same issue. But in the scenario I am describing below. I didn't notice (yet) in other situations...

When I have a site that shows mixed content (in dutch: Laden van gemengde actieve inhoud ‘http://cadet.nl/media/jui/fonts/IcoMoon.woff’ geblokkeerd) then it happens...

When on another tab with another site opened I expect console to show the messages from that tab/site.


What also is weird in this case is that above site is accessed over http:// (http://cadet.nl) and loads "/media/jui/fonts/IcoMoon.woff" allright. In the debugger tab "Network" it shows status 200. Console says it is blocked......

This is FF 59.0.1 (64bits) just upgraded from 58 (same issue though).

Soon as I have blocked (mixed) content that by defenition of both is not mixed being the same protocol (http://), in the console, it happens that the tab console becomes sticky to the site... any other site I check on other tabs, show console messages of the "error" site not the site in the active tab.

All other tabs in the debugger like "inspector" seem to do ok.

This happened on two different computers.. 

I hope this can point, or at least hint, into some direction that helps.. If you need me to show more do ask.. 

Tx,

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

(In reply to pieter from comment #9)
> I see the same issue. But in the scenario I am describing below. I didn't
> notice (yet) in other situations...
> 
> When I have a site that shows mixed content (in dutch: Laden van gemengde
> actieve inhoud ‘http://cadet.nl/media/jui/fonts/IcoMoon.woff’ geblokkeerd)
> then it happens...
> 
> When on another tab with another site opened I expect console to show the
> messages from that tab/site.
> 
> 
> What also is weird in this case is that above site is accessed over http://
> (http://cadet.nl) and loads "/media/jui/fonts/IcoMoon.woff" allright. In the
> debugger tab "Network" it shows status 200. Console says it is blocked......
> 
> This is FF 59.0.1 (64bits) just upgraded from 58 (same issue though).
> 
> Soon as I have blocked (mixed) content that by defenition of both is not
> mixed being the same protocol (http://), in the console, it happens that the
> tab console becomes sticky to the site... any other site I check on other
> tabs, show console messages of the "error" site not the site in the active
> tab.
> 
> All other tabs in the debugger like "inspector" seem to do ok.
> 
> This happened on two different computers.. 
> 
> I hope this can point, or at least hint, into some direction that helps.. If
> you need me to show more do ask.. 
> 
> Tx,

Hello pieter, thanks for offering help.
It would be really really helpful if you could use https://mozilla.github.io/mozregression/quickstart.html to see when the issue was introduced.

Comment 11

[pieter]

Hi Nicolas,

I will try and see if I can find any using mozregression.
As I do not know when this started.. somewhere between now and half a year ago. It may take some time.

As I understand it is just repeating al steps every possible update, the click good or bad, right?

Tx,

Pieter

Comment 12

[Nicolas Chevobbe [:nchevobbe]]

(In reply to pieter from comment #11)
> Hi Nicolas,
> 
> I will try and see if I can find any using mozregression.
> As I do not know when this started.. somewhere between now and half a year
> ago. It may take some time.
> 
> As I understand it is just repeating al steps every possible update, the
> click good or bad, right?
> 
> Tx,
> 
> Pieter

Yes ! Thanks a lot

Comment 13

[pieter]

I am puzzled.. I started according to that Youtube tutorial.. selected a period between now and a year ago and it starts checking just one build from that period and the rest is from before..See my attachment..

Comment 14

[pieter]

Attachment: mozregression.jpg

see my comment

Comment 15

[pieter]

It may be me not understanding this.. All I know the latest version is NOT ok and the version that IS ok is at least showing OK end of last summer... after that there was no development done.. so I never checked console after that.

Should I then add other dates in those fields?

Comment 16

[Brian Grinstead [:bgrins]]

(In reply to pieter from comment #15)
> It may be me not understanding this.. All I know the latest version is NOT
> ok and the version that IS ok is at least showing OK end of last summer...
> after that there was no development done.. so I never checked console after
> that.
> 
> Should I then add other dates in those fields?

If I'm understanding the issue: you would set the last known good build as sometime around the end of summer and the first known bad as today.  Then you will be asked to test builds one by one and report if they are good and bad until it narrows down to a single day (or even better a single pushlog).

Comment 17

[pieter]

I did that.. it now says: Bisecting on mozilla central [2018-03-19 - 2017-08-19]
but starts at 2017-12-03 to today now bisecting on "autoland" only I can see it now not only comes closer to "now" but also adds time to it.... But nothing starting or moving towards 2017-08-19....

Should I try using build numbers?

Comment 18

[Brian Grinstead [:bgrins]]

(In reply to pieter from comment #17)
> I did that.. it now says: Bisecting on mozilla central [2018-03-19 -
> 2017-08-19]
> but starts at 2017-12-03 to today now bisecting on "autoland" only I can see
> it now not only comes closer to "now" but also adds time to it.... But
> nothing starting or moving towards 2017-08-19....
> 
> Should I try using build numbers?

Using dates and autoland is fine. If 2017-12-03 is "good" then it will move forward halfway towards 2018-03-19 and let you test again. Then if that's good it will again bring you halfway to 2018-03-19, but if it's bad it will bring you back halfway towards 2017-12-03. This way you will do the minimum number of tests before you narrow the breakage down to a single set of commits.

Comment 19

[pieter]

all where bad... from 2017-12-03 till now... so when all has been tested between then and now, will it then jump to builds before 2017-12-03?

Comment 20

[Brian Grinstead [:bgrins]]

(In reply to pieter from comment #19)
> all where bad... from 2017-12-03 till now... so when all has been tested
> between then and now, will it then jump to builds before 2017-12-03?

If 2017-12-03 is bad then it should take you backwards (closer to the starting date, not closer to today).

Comment 21

[pieter]

Hi Nicolas, Hi Brian,

Using the mozregression I found this: 

2018-03-20T22:58:57: DEBUG : Starting merge handling...
2018-03-20T22:58:57: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=62cebea1d1578461a423a9ca7848706455db9ea5&full=1
2018-03-20T22:58:58: DEBUG : Found commit message:
Bug 1330412 - Clean up Stylo Treeherder symbols. r=jmaher

Clean up and standardize Treeherder symbols for Talos and AWSY tasks:

* Stylo disabled groups include `sd`
* Stylo sequential groups include `ss`

MozReview-Commit-ID: 7cl6e0XvXNO


The right pane shows:

app_name: firefox
build_date: 2017-09-05 20:58:08.122000
build_file: C:\Users\Pieter\.mozilla\mozregression\persist\5f721a664bf6--autoland--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/DhrHDxitStikmjRf-RID6g/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: 5f721a664bf64fed99184a866b60c24a6afcb3a0
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5f721a664bf64fed99184a866b60c24a6afcb3a0&tochange=62cebea1d1578461a423a9ca7848706455db9ea5
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: DhrHDxitStikmjRf-RID6g

Is that of any help? I checked the big with that ID but it beyond any of my knowledge...  Sure you know what it is about...

Comment 22

[Brian Grinstead [:bgrins]]

Thank you for doing that. Interesting - that's when we enabled Stylo by default. Can you confirm that the problem goes away for you if you set the `layout.css.servo.enabled` pref to false in about:config? You may need to restart the browser after changing it.

Comment 23

[pieter]

Hi Brian,

I did what you asked. Did not have to restart.. Now I checked with `layout.css.servo.enabled` pref to false and indeed there is no message my font is blocked anymore.

When I return to true, it shows the message again.. though when I check network it is not blocked, status 200.

I haven't got any idea what stylo nor what servo is.... so there my brains go blank... sorry.. 

Tx,


Pieter

Comment 24

[Brian Grinstead [:bgrins]]

I did some searching around and I think this is a duplicate of Bug 1420680, which has to do with loading woff fonts in stylo

Comment 25

[pieter]

Hi Brian,

I checked that before. When I eliminate the .woff font from my css, I get a message the .ttf font is blocked.. and it is not as it has status 200 and loaded allright...

this is the usual css code:
@font-face {
	font-family: 'IcoMoon';
	src: url('../fonts/IcoMoon.eot');
	src: url('../fonts/IcoMoon.eot?#iefix') format('embedded-opentype'),
                url('../fonts/IcoMoon.svg#IcoMoon') format('svg'),
		url('../fonts/IcoMoon.woff') format('woff'),
    		url('../fonts/IcoMoon.ttf') format('truetype');
	font-weight: normal;
	font-style: normal;
}

Taking out the .woff font makes it message for the .ttf
Changing the order, putting the .ttf above the .woff also makes it whine about the .ttf.



Tx,

Pieter