Closed Bug 1311807 Opened 3 years ago Closed 2 years ago
Some images and media players delayed for minutes
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20161020030211 Steps to reproduce: On https://www.franceinter.fr/ page, click headphone icone to start audio player This opens audio player in the bottom , Actual results: audio playing won't start before several minutes Expected results: audio playing starts within 1 or 2 seconds
mozregression gives this result: 016-10-20T21:32:32: INFO : application_version: 52.0a1 2016-10-20T21:32:32: INFO : platform_buildid: 20160927125019 2016-10-20T21:32:32: INFO : platform_changeset: 689f6fee184628d3dd968e3b6518cc811cfb3e43 2016-10-20T21:32:32: INFO : platform_repository: https://hg.mozilla.org/integration/mozilla-inbound 2016-10-20T21:32:32: INFO : platform_version: 52.0a1 2016-10-20T21:32:33: INFO : ATTENTION: default value of option force_s3tc_enable overridden by environment. 2016-10-20T21:32:33: INFO : ATTENTION: default value of option force_s3tc_enable overridden by environment. 2016-10-20T21:32:34: INFO : ATTENTION: default value of option force_s3tc_enable overridden by environment. 2016-10-20T21:33:05: INFO : Narrowed inbound regression window from [9dfac0d1, e1b0aaa2] (4 revisions) to [689f6fee, e1b0aaa2] (2 revisions) (~1 steps left) 2016-10-20T21:33:05: DEBUG : Starting merge handling... 2016-10-20T21:33:05: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=e1b0aaa20f1098b08537b2e13f9e97ee9759d4c7&full=1 2016-10-20T21:33:06: DEBUG : Found commit message: Bug 1302414 - Theme preview is not working. r=sebastian 2016-10-20T21:33:06: INFO : The bisection is done. 2016-10-20T21:33:06: INFO : Stopped
Summary: audio player delayed for minutes working on https://www.franceinter.fr/ (mozregression result) → audio player delayed for minutes on https://www.franceinter.fr/ (mozregression result)
ok with chrome
ok with FF nightly before 2016/09/27 as shown by mozregression
[Tracking Requested - why for this release]: performance regression on the certain site I can reproduce on Windows10 home 64bit Nightly52.01 32bit. Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=689f6fee184628d3dd968e3b6518cc811cfb3e43&tochange=e1b0aaa20f1098b08537b2e13f9e97ee9759d4c7 Suspect: 380eebfd9d89 Kate McKinley — Bug 1246540 - HSTS Priming Proof of Concept. r=ckerschb, r=mayhemer, r=jld, r=smaug, r=dkeeler, r=jmaher, p=ally Setting security.mixed_content.send_hsts_priming=false seems to fix the issue.
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Security
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
Version: 52 Branch → 51 Branch
Setting security.mixed_content.send_hsts_priming=false is ok for me too
The audio player loads the mp3 content over HTTP, which HSTS priming attempts to upgrade to HTTPS. When it makes the HSTS priming request to https://direct.franceinter.fr/live/franceinter-midfi.mp3, the HTTPS connection times out. Then it requests HTTP, which results in a 302 redirect to http://aifae8cah8.lb.vip.cdn.dvmr.fr/franceinter-midfi.mp3. Since HSTS priming has not seen this new domain, a new priming request is sent, which also times out. Then the stream starts to play. Bug 1310955 fixed an issue where the cached result was not being properly read, and a new request was sent each time. In the current macOS Nightly, the first time I load the page it takes about a minute to load the audio, but subsequent loads are nearly instantaneous. Timeouts like this can be fixed by the site owner by one (or more) of the following: * Migrate the content to HTTPS and use HSTS * Change the firewall to not drop packets to unused ports, but instead send RST (nothing listening) * Have an HTTPS server listening which returns 404
Depends on: 1310955
Edge and Chrome Dev55.0.2883.11 on Win10 are working properly(fast).
Whiteboard: [parity-chrome] [parity-edge]
(In reply to Kate McKinley [:kmckinley] from comment #6) > but subsequent loads are nearly instantaneous. I can still reproduce the slow connection the subsequent load. Steps 1. Open https://www.franceinter.fr/ and Click headphone icon --- Toooooooo slow 2. Open https://www.franceinter.fr/ again and Click headphone icon --- Still Toooooooo slow
This fix landed on Nightly on the 20th, so it will depend on whether a new build is up. With a macOS build I downloaded just prior to my comment, the behavior was correct.
(In reply to Kate McKinley [:kmckinley] from comment #9) > This fix landed on Nightly on the 20th, so it will depend on whether a new > build is up. With a macOS build I downloaded just prior to my comment, the > behavior was correct. Confirmed on Windows10 build(m-c f0f1aaf051d6798e1e73d1feee07ca847333167a). The first loading is still extremely slow. However, the subsequent load is normal.
Chrome and Edge is fast, even if it is first loaded.
It is ok for me (including 1st load) since this morning with build 20161021030210 ( "security.mixed_content.send_hsts_priming" back to true of course)
(In reply to laugeo from comment #12) > It is ok for me (including 1st load) since this morning with build > 20161021030210 > ( "security.mixed_content.send_hsts_priming" back to true of course) The first load means using new profile or profile that expired the HSTS cache.
Ok, trying with new profile, problem remain .
Kate, does it make sense to back this out of 51 while we're sorting things out? Bug 1246540 comment 145 is where the request for the uplift was made, but it looks like we're running into some problems. And by "backing out", I mean flip the preference, if that's enough to stop this regression in 51.
Another example with this video embedded in the page: http://www.geenstijl.nl/mt/archieven/2016/10/geweldsmonopolie.html
Summary: audio player delayed for minutes on https://www.franceinter.fr/ (mozregression result) → Some media players delayed for minutes
It is fine to turn security.mixed_content.send_hsts_priming off in Release. Keeping it on in Nightly/Aurora will help us to identify these types of issues and how widespread they are. As noted in comment 6, this is ultimately something site owners can and should fix.
Tracking 52+ so we can keep an eye on the scope of how many sites might be affected.
Assignee: nobody → kmckinley
Priority: -- → P2
Whiteboard: [parity-chrome] [parity-edge] → [parity-chrome] [parity-edge][domsecurity-active]
Whiteboard: [parity-chrome] [parity-edge][domsecurity-active] → [parity-chrome] [parity-edge][domsecurity-active] [hsts-priming]
Hi :kmckinley, per comment #18, does that mean the issue will be disappeared when 51 enters beta?
We will still send the priming request in beta and release. Since the priming request timing out is the root cause, setting security.mixed_content.send_hsts_priming is set to false in all.js for beta/release will make this will go away. Bug 1313595 will reduce the timeout to default 3s, and the timeout will be adjustable.
Patch up for review in bug 1313595
Because things landed around the train changes, can we be explicit about where bug 1313595 landed - it looks it's currently at 52+53, and it should go to 51 as well. At which point, we should be able to close this bug, or wontfix it for 51.
If possible, I would like to get bug 1313595 uplifted, but if not, we can turn it off via pref. I want to make sure no new problems are cropping up, and there are a few tests that have started to orange, I need to make sure they are not broken. Sometimes the priming request shows up in a test as an unexpected request, even though it has no impact on the result.
This feature is disabled in release, which means that we won't have the problem as 51 hits release, and the problem (see bug 1313595) is fixed in 52.
patch from bug #1313595 was backed out, what's more it still adds delay (like 3s), so it's not perfect fix, but workaround
[Tracking Requested - why for this release]: Regression
Kate, as we're getting close to merge day is the plan still to fix this for 52 (via bug 1313595?), or are we going to pref hsts priming off? It seems like it would be better to do something about this bug before we go to beta. Thanks.
I am hopeful that 1313595 can be landed since the rework is completed, but until it is, I think hsts priming should be pref'd off.
I talked to Kate about this and HSTS priming isn't going to be enabled on 52 past Aurora, so this will become a non-issue for that release.
[Tracking Requested - why for this release]: Regression Unfortunately this is still enabled in release and it's still the issue, same as bug #1334074.
Confirmed the issue with the steps from comment 0, in 52.0b1. It seems we still need to pref off security.mixed_content.send_hsts_priming?
Bug 1335134 has been created to disable it in the codebase, and bug 1335224 has been created to create a go-faster addon to disable the pref.
Disabled on release (via system add-on) and beta (as of 52.0b3).
3 years ago
See Also: → 1335083
3 years ago
3 years ago
Status: NEW → ASSIGNED
3 years ago
3 years ago
Are we still planning to ship with this disabled in 55 and 56?
This will still be disabled on Release in 55 and 56. It will be enabled in Beta 56 for data gathering. However, the underlying problem causing the delay has been fixed, so we should be able to close this.
The problem was fixed , but re-appeared some days ago . Try the audio player on https://www.franceinter.fr/
laugeo, what version of Firefox are you using, where you see the issue?
Problem fixed using today Nightly ( August 4 )
Kate, want to close this now?
I think we can close this.
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Noting this was disabled in 56 in bug 1385035 (after EARLY_BETA_OR_EARLIER).
You need to log in before you can comment on or make changes to this bug.