`network.preload` preference is set to true in wpt
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
People
(Reporter: koddsson, Assigned: koddsson)
References
Details
Attachments
(1 obsolete file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36 Edg/81.0.416.53
Steps to reproduce:
I ran the Web Platform Tests for the preload link headers.
Actual results:
The passed on Firefox 75
Expected results:
They should have failed since rel=preload
isn't enabled in Firefox 75
Assignee | ||
Comment 1•5 years ago
|
||
Here's the issue that I filed in WPT. This seems to be because the network.preload
user preferences are enabled in Firefox when it runs in WPT.
Assignee | ||
Comment 2•5 years ago
|
||
network.preload
is off by default and there for not representative of a user of Firefox. By removing that user preference we are more in line
Updated•5 years ago
|
Comment 3•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 4•5 years ago
|
||
Why would we want to lose test coverage?
Comment 5•5 years ago
|
||
Emilio, thanks for catching this bug and reaching me! This is a wontfix now, we want that coverage for sure when I'm about to land the new preload implementation soon and also enable it by default for the next realse. This coverage is vital to have.
Comment 6•5 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #5)
Emilio, thanks for catching this bug and reaching me! This is a wontfix now, we want that coverage for sure when I'm about to land the new preload implementation soon and also enable it by default for the next realse. This coverage is vital to have.
Note that this patch is doing something different (in the end) though, it's enabling it in the relevant subdirectories instead of in WPTRunner.
Comment 7•5 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #5)
Emilio, thanks for catching this bug and reaching me! This is a wontfix now, we want that coverage for sure when I'm about to land the new preload implementation soon and also enable it by default for the next realse. This coverage is vital to have.
The reason I mentioned was... do you want it on everywhere (In which case we should add it to the global __dir__.ini
)? Or do something else?
Comment 8•5 years ago
|
||
OK, timing for changes to this right now is really bad and unnecessary.
Let's deal with this in bug 1626997. It's enabling preload by default, so I will remove the pref changes to WPT as part of it. Would that work for you?
Assignee | ||
Comment 9•5 years ago
|
||
Let's deal with this in bug 1626997. It's enabling preload by default, so I will remove the pref changes to WPT as part of it. Would that work for you?
Sure, would! I saw that bug but wasn't sure when that would be resolved and figured that we'd want to get the correct thing showing up in WPT just as soon as possible.
Comment 10•5 years ago
|
||
Comment 12•5 years ago
|
||
Please back this out IMMEDIATELY. This bug has been closed as a duplicate and will conflict with my changes to preload I'm just about to land.
Comment 14•5 years ago
|
||
Backed out changeset 6a71491c39a4 (bug 1631816) as requested by dev. CLOSED TREE
Push that got backed out:
https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=7aa7584b8e0ea376f52ca4684ac44cf73408a611
Backout:
https://hg.mozilla.org/integration/autoland/rev/5d2555b77d8ef29019694238bc08e796e7c65818
Comment 16•5 years ago
|
||
Thank you! I will now abandon the revision here.
Kristian, please let you know that the patch is made obsolete by a patch I'm about to submit in bug 1626997. It's the last one to go for the preload work.
Updated•5 years ago
|
Assignee | ||
Comment 17•5 years ago
|
||
Ok sounds good. I'll watch bug 1626997.
Description
•