1072421 - <video> element causes mixed-content warning on page reload.

Status: RESOLVED DUPLICATE of bug 947079

(Core :: Security, defect)

Description

[Ralph Giles (:rillian)]

I've intermittently seen mixed-content warnings with no console message or resources loading over http. Today I was able to trace and instance of this to a video element.

Visiting https://people.xiph.org/~jm/daala/paint_demo/ and hitting reload, the gray ssl lock in the url bar changes to a gray warning triangle. If I comment out the HTML <video> element, I cannot trigger the warning.

Some interaction with the media cache perhaps?

Comment 1

[Ralph Giles (:rillian)]

I made a simple reproduction case.

1. With a clean profile, visit https://people.mozilla.org/~rgiles/2014/media-nowarn.html
2. Verify green lock icon in url bar.
3. Click reload.
4. Verify gray mixed-content warning triangle in url bar.

To verify it's the video element, try the same steps with https://people.mozilla.org/~rgiles/2014/media-nowarn.html which replaces the video element with an image.

Seems to be related to range requests against the media cache:

- No mixed-content warning is shown on the first visit. (no resources in cache)

- Mixed-content warning is always shown after the first visit when only enough of the media resource to display a starting frame has been loaded. (partial resource in cache)

- No mixed-content warning is shown when reloading after the video has completed playback. (full resource in cache)

Comment 2

[Ralph Giles (:rillian)]

Oops, the STR url is https://people.mozilla.org/~rgiles/2014/media-warn.html !

Comment 3

[Tanvi Vyas[:tanvi]]

At first glance, this looked like a duplicate of bug 947079.  Bug 947079 is fixed and now this issue is too in Firefox 39.  But, it does look like there is another underlying problem here.  There is no unload event or http request made at all between going to https://people.mozilla.org/~rgiles/2014/media-warn.html and reloading.  So I'm not sure why this issue existed in the first place.  Bug 947079 is probably a bandaid for the problem, but there may be another underlying issue with <video> code or with nsSecureBrowserUIImpl (or both).

Comment 4

[:Cykesiopka]

FWIW, I can't get this to reproduce on a DevEdition 46 win64 build with either the link in Comment 2 or the link in Comment 0.

Comment 5

[Ralph Giles (:rillian)]

Yep, looks like this is fixed. Thanks for checking!