Closed Bug 1503852 Opened 2 years ago Closed 2 years ago

Perma /fetch-destination.https.html | HTMLLinkElement with rel=prefetch fetches with an empty string Request.destination - expected TIMEOUT when Gecko 65 merges to Beta on 2018-12-03


(Core :: DOM: Networking, defect)

Not set



Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 + verified


(Reporter: RaulG, Assigned: mconley)




(1 file, 1 obsolete file)

[Tracking Requested - why for this release]:

Regression from Bug 1501044

Central as beta simulation:

Log link:

Log snippet: 
[task 2018-11-01T11:49:50.862Z] 11:49:50     INFO - TEST-PASS | /fetch/api/request/destination/fetch-destination.https.html | HTMLLinkElement with rel=preload and as=manifest fetches with a "manifest" Request.destination 
[task 2018-11-01T11:49:50.862Z] 11:49:50     INFO - TEST-UNEXPECTED-PASS | /fetch/api/request/destination/fetch-destination.https.html | HTMLLinkElement with rel=prefetch fetches with an empty string Request.destination - expected TIMEOUT
[task 2018-11-01T11:49:50.863Z] 11:49:50     INFO - TEST-INFO | expected TIMEOUT
[task 2018-11-01T11:49:50.864Z] 11:49:50     INFO - TEST-UNEXPECTED-OK | /fetch/api/request/destination/fetch-destination.https.html | expected TIMEOUT
[task 2018-11-01T11:49:50.864Z] 11:49:50     INFO - TEST-INFO expected TIMEOUT | took 2049ms
Component: DOM → web-platform-tests
Product: Core → Testing
From the behavior, it ignores the browser.tabs.remote.separatePrivilegedContentProcess set to true in bug 1501044.
Component: web-platform-tests → DOM: Networking
Flags: needinfo?(mconley)
Product: Testing → Core
Assignee: nobody → mconley
A more robust solution is probably to disable the preloaded about:newtab for this test. That way, it's far less likely to pass accidentally, instead of timing out (which it should be doing, due to bug 1500089.

Beta simulation try push:

mozilla-central try push:
See Also: → 1500089
Cripes, it still fails. :(

What would be truly lovely is the ability to just _disable_ this subtest, but (unless jgraham can correct me here), there's no way to disable a subtest, right?
Flags: needinfo?(mconley) → needinfo?(james)
The prefetch test is pretty flake-y, and when it passes, it's only by accident.

See bug 1500089 for details.
Yeah, if the test timing out is causing the entire file to time out there isn't a good and easy solution (subtests and the whole file have different statuses). At the moment the only possibilities are 
1) Disable the whole file
2) Move the problematic subset out into a seperate test file and disable that subtest

Obviously the second one is better since we avoid losing coverage for the other tests, but it's also more work.
Flags: needinfo?(james)
Attachment #9027055 - Attachment is obsolete: true
Pushed by
Split out prefetch test from fetch-destination.https.html, and disable for Firefox. r=jgraham
Created web-platform-tests PR for changes under testing/web-platform/tests
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.