Closed Bug 1375172 Opened 7 years ago Closed 7 years ago

Firefox not displaying mixed display content

Categories

(Core :: DOM: Security, defect)

56 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Mark12547, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170620030208

Steps to reproduce:

Either in Safe Mode, or with my current profile (extensions: uBlock Origin 1.13.0, SixOrNot 2.0.2), display this thread at DSLReports: https://www.dslreports.com/forum/r31475771-This-comic-made-me-giggle


Actual results:

The first post opens with a broken image indicator instead of the cartoon (.jpg file).


Expected results:

The cartoon (a .jpg file) should display in the first post.

It does display the cartoon in these browsers:

* Firefox 54.0 (64-bit)
* Google Chrome 59.0.3071.109 (Official Build) (64-bit)
* Internet Explorer 11.0.9600.18697

At least one other Nightly user observes the same issue and suggested installing extension HTTPS Everywhere as a temporary work-around. See: https://www.reddit.com/r/firefox/comments/6in1x6/firefox_nightly_mixed_passive_content_jpg_not/

System Information:

Firefox Nightly 56.0a1 (2017-06-20) (64-bit), Build ID 20170620030208.
security.mixed_content.block_display_content is at its default value of false.

Windows 7 Home Premium SP1 (64-bit).

If there is any additional information you would like, please let me know.

Thank you!
But is there when I create a brand new profile, close Nightly, then relaunch nightly with a shortcut pointing to the brand new profile and go directly to the DSLReports thread.
Component: Untriaged → DOM: Security
Product: Firefox → Core
Attached file Regression Log
REGRESSION RUN

I attempted to run the regression (Mozregression-gui), which had narrowed down the date range to 2017-06-19 (good) - 2017-06-20 (bad) before it crashed.

After rebooting my system, I reran with roughly those dates (I think I used one day earlier as the start), but it didn't indicate what information I should post, so I copied everything from the log window, stuck it in a text file, and uploaded that. It is this second run that apparently located the build where this went bad whose log I have attached.

If there is something more useful for me to post or upload, please let me know where to find it and I'll get that attached, too.

Thank you!
Maybe I should mention my regression methodology.

Using Firefox nightly, I copied the URL of the DSLReports thread into the Windows clipboard. Then I closed all browsers I had open.

After installing mozregression-gui, I took all the defaults on the first run. As each Firefox build came up, I opened a new tab, pasted in https://www.dslreports.com/forum/r31475771-This-comic-made-me-giggle into the address bar and pressed Enter, and waited to see if the cartoon (.jpg file) would display (good) or if I would get a broken image indicator (bad). Then I closed the Firefox build, and clicked on the red (bad) or green (good) button for that run. This ran until Mozregression-gui got stuck complaining that something had stopped responding. (Sorry, I didn't get the exact message.) At that point I thought maybe some resource got hung up and decided to reboot my machine.

For the second run, the only change was I specified a new starting date for the range, and it seemed to narrow the results down to a single build and came to a normal stop. It is the log window from that run that I had uploaded.

So, if Mozregression-gui is building new profiles at each run, then I was running with no extensions, no themes, and not being logged on to DSLReports. And the results were easily and solidly repeatable.
Another thread (same site): this is the start of a partial thread showing, or rather NOT showing, three screen shots (two .png, one .jpg) in just two consecutive posts:
https://www.dslreports.com/forum/r31480198-
The https://www.dslreports.com/forum/r31480198- link seems to no longer work; it was pointing to the 7th-9th posts of this thread: https://www.dslreports.com/forum/r31479559-Chromium-updated-to-59-0-3071-109 (the thread link works, not the subthread link in Comment 4.)
These all look fine to me, and I don't see any mixed-content warnings or errors in the web console. Is it still reproducible? I have no add-ons that would be converting http requests to https.
Flags: needinfo?(Mark12547)
Yes, the problem is still solidly reproducible.

Going to https://www.dslreports.com/forum/r31475771-This-comic-made-me-giggle with a new profile (no extensions, no customization) still doesn't show the image in the first post. This is Firefox Nightly 56.0a1 (2017-07-11) (64-bit) under Windows 7 Home Premium SP1 (64-bit). I have been testing this in Nightly on a customized profile almost every day that Nightly has been updated, starting back 20 days ago when I first reported it, and just now retested with a new profile.

Contrast that to Firefox (Release Channel) 54.0.1 (64-bit), which does show the image.

Chrome 59.0.3071.115 (Official Build) (64-bit) also shows the image.

In all three cases, starting position is without anything cached to disk.
Flags: needinfo?(Mark12547)
Fixed?

It appears that this morning's build, 56.0a1 (2017-07-14) (64-bit), has fixed the issue. The two test threads on DSLReports loaded correctly with the images right where they belong!
I tried another regression, this time to find the fix, limiting the range to 2017-07-13 through 2017-07-14. The regression got to:
    Build 16fb9739 (vredict: g)
    Build 8486950b (verdict: b)
before the regression gui produced an error about no push-log.

Maybe that info will be useful to someone.
If this comes back (since we don't know what change fixed it) we can reopen the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
I concur. No point in chasing down non-problems. :)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: