Talos server should be accessible via several domains to test Fission scenarios
Categories
(Testing :: Talos, task, P2)
Tracking
(Fission Milestone:M6)
| Fission Milestone | M6 |
People
(Reporter: jdescottes, Unassigned)
References
(Blocks 1 open bug)
Details
In order to get ready for Fission and track the impact, we want to start updating the DevTools Talos tests (aka DAMP) to involve iframes that will be remoted once Fission is activated.
This means the iframes should appear to come from different sites, and therefore point to different domains. For now I think the server used during Talos tests is only available at http://127.0.0.1:someport, which makes it challenging to write test scenarios for Fission.
It would be nice if we could configure the host so that the server can be accessed via multiple domains, similarly to what is available when writing mochitests.
|
Reporter | |
Comment 1•5 years ago
|
||
Hi Robert, I was pointed at you for talos-related questions, I hope it's correct :) (also wanted to ping jmaher, but on PTO at the moment apparently)
Do you know if there is a way during talos tests to access test pages via different domains?
As I said in the summary, I've only ever seen test urls such as http://127.0.0.1... but maybe I missed something.
If not, any idea how difficult it will be to provide this feature?
Thanks!
|
||
Comment 2•5 years ago
|
||
Hi Julian!
Yes you have the correct person :) I looked at the talos code to refresh my memory, yes as you noted talos currently just uses that one web server URL [0] [1] [2].
Talos uses mozhttpd [3] maybe we could just startup additional webservers with different host values or something? I've never tried that. Or would be even better if there's a way to use the one mozhttpd server but with multiple hosts (if that's even possible?). Thanks for mentioning mochitests, maybe we could take a look at how it is done there.
:davehunt, do you want someone on our team to take some time to look into this further? I can unless there's someone else you have in mind for some talos work.
[0] https://searchfox.org/mozilla-central/rev/f1e99da78fe6c3c68696358dac06aed90f8112d3/testing/talos/talos/config.py#141
[1] https://searchfox.org/mozilla-central/rev/f1e99da78fe6c3c68696358dac06aed90f8112d3/testing/talos/talos/run_tests.py#212
[2] https://searchfox.org/mozilla-central/rev/f1e99da78fe6c3c68696358dac06aed90f8112d3/testing/talos/talos/run_tests.py#81
[3] https://firefox-source-docs.mozilla.org/mozbase/mozhttpd.html
|
||
Comment 3•5 years ago
|
||
After talking with :nika it sounds like multiple web servers on the same host would not satisfy Fission's criteria for starting a separate process. Alternate options that might work are using a proxy, or the DNS trick that WebPageReplay uses with Chrome as described in bug 1523367. Have I got that right :nika?
|
||
Comment 4•5 years ago
|
||
The important thing is that the URL which Firefox sees loading (from the DOM point of view) has a distinct eTLD+1 (e.g. example.com vs mochi.test). Unfortunately, port # and subdomains don't count as different sites, so won't get different processes.
|
|
||
Updated•5 years ago
|
Hi Nika, all -
:bebe and I discussed this, and we thought as a first step, getting pointed to a minimized testcase (or suggestions on where/how to dig, besides efforts to update DAMP, etc. which are much bigger tests/suites) would be most appreciated.
He and I also briefly looked through the raw recording/playback scripts, from our mitmproxy-run tests, and part of what we need to do for bug 1585598 assessment's is look at unique site origins, but IIRC, that info isn't immediately exposed (:bebe, can you help clarify, here?) Not sure if all <iframe>s are getting shown.
A minimized testcase will help us hone in on what we need from either/both tooling (mitmproxy + Raptor) or the recordings and scripts themselves.
Thanks!
|
|
||
Comment 6•5 years ago
|
||
I don't know much about how talos is implemented, so I cannot provide a test-case here.
The important piece here is the presence of multiple content processes due to multiple domains being used for performing the loads. This could be validated by hovering over the tab to cause the tab's tooltip to appear. When running under Fission, a [F ...] will appear in the tooltip, listing the PIDs of all processes involved in drawing that tab. If there are more than one of them, then that would imply that you've successfully triggered an out-of-process iframe.
|
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 7•5 years ago
|
||
A simple page with cross-origin iframes is https://hsivonen.fi/fission-host.html. Is that what you're looking for, Stephen?
I have no idea how best to store such content for serving from multiple (synthetic, I guess) origins. Something like this?
a.com/index.html // has an iframe that points to ---v
b.com/index.html
|
||
Comment 8•5 years ago
|
||
If I understand correctly from the test wiki: https://wiki.mozilla.org/TestEngineering/Performance/Talos/Tests#DAMP
We load the tp5 pages and measure with Talos some different test scenarios for DAMP (Developer Tools toolbox startup, shutdown, and reload performance)
As tp6 tests are a "evolution" of tp5 difference being we use a proxy server to replay the page data (tp6) not a local webserver and downloaded web pages as in (tp5)
If we modify the damp tests to use the tp6 webpages and generate a selection of webpages that would match the condition to trigger the fission multi process we should be OK
:nika are there any other areas where we should have eTLD+1 ?
|
||
Comment 9•5 years ago
|
||
DAMP may be slightly more special than the other Talos jobs (well... each talos test suite is a bit special I imagine ;))
Florin, you were right in indentifying this codepath:
const webserver = Services.prefs.getCharPref("addon.test.damp.webserver");
exports.COMPLICATED_URL =
webserver + "/tests/tp5n/bild.de/www.bild.de/index.html";
This is where we are struggling.
The preference is being controlled by python
We do use only one arbitrarity choosed website out of TP5. The Bild.de copy.
And we were looking into loading this bild.de copy within an iframe. The whole document. Not just find one website out of TP5/TP6 which could possibly trigger fission/cross-domain.
So, our goal is to have a custom document with an iframe loading bild.de and to trigger fission, that custom document has to be loaded from another domain.
To be even more concrete, here is what we would like to do in pseudo-code:
- /tests/devtools/addon/content/pages/index.html:
<iframe src="${Services.prefs.getCharPref("addon.test.damp.webserver.domain2") + "/tests/tp5n/bild.de/www.bild.de/index.html"}"></iframe>
- from damp test script,
openUrl(Services.prefs.getCharPref("addon.test.damp.webserver.domain1") + "/tests/devtools/addon/content/pages/index.html");
where python would provide two preferences:
- addon.test.damp.webserver.domain1
- addon.test.damp.webserver.domain2
mapped to two distinct domains, to trigger fission.
And: - /tests/devtools/addon/content/pages/index.html is a file from mozilla-central,
- /tests/tp5n/bild.de/www.bild.de/index.html comes from the tp5 bundle as today.
We would like to have such fine grained control over the domains as we have various custom test documents, where we wish we could control exactly which iframe uses what domain.
(In reply to Andrew Overholt [:overholt] from comment #7)
A simple page with cross-origin iframes is https://hsivonen.fi/fission-host.html. Is that what you're looking for, Stephen?
<snip for brevity>
Thanks, yes - this looks like a great minimized testcase to get us focused on a smaller set, for starters!
|
|
Reporter | |
Comment 11•5 years ago
|
||
Since I opened the bug, I would like to make sure the original intent is still matching the current discussion here.
I feel like we now are talking about what a "fission" test scenario should look like and how to provide one easily?
We don't need pre-built pages that contain cross-origin iframes, we need the server capabilities to create such pages.
If, within a Talos test, I can target the content of testing/talos/talos/tests/devtools/addon/content/pages via several hosts (ideally many hosts so that we can really stress test things), then we will write the test page to make sure it is exercising Fission. Other test suites might have different needs, but as far as DAMP is concerned, we will write our own test pages as long as we can target our files via several hosts.
Robert: your comment #2 seemed to be inline with my description of the problem. Are we still on the same page about what should be implemented here?
|
||
Comment 12•5 years ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #11)
Since I opened the bug, I would like to make sure the original intent is still matching the current discussion here.
I feel like we now are talking about what a "fission" test scenario should look like and how to provide one easily?We don't need pre-built pages that contain cross-origin iframes, we need the server capabilities to create such pages.
If, within a Talos test, I can target the content of testing/talos/talos/tests/devtools/addon/content/pages via several hosts (ideally many hosts so that we can really stress test things), then we will write the test page to make sure it is exercising Fission. Other test suites might have different needs, but as far as DAMP is concerned, we will write our own test pages as long as we can target our files via several hosts.Robert: your comment #2 seemed to be inline with my description of the problem. Are we still on the same page about what should be implemented here?
It should be noted that I think this patch addresses a large part of the need here? This would let us hit pages from any domain within talos.
|
|
||
Comment 13•5 years ago
|
||
Hi Doug, :stephend and :bebe are looking after this work, so I will defer to them, thanks!
|
|
Reporter | |
Comment 14•5 years ago
|
||
(In reply to Doug Thayer [:dthayer] from comment #12)
It should be noted that I think this patch addresses a large part of the need here? This would let us hit pages from any domain within talos.
Thanks for the pointer! It looks very promising and I think it addresses what I had in mind for this bug. Will mark this as blocked on the other bug for now. Unless we need anything more than https://phabricator.services.mozilla.com/D50707 for DAMP, I would be tempted to close as duplicate but I am not sure if others wanted to repurpose this bug for something else?
(In reply to Robert Wood [:rwood] from comment #13)
Hi Doug, :stephend and :bebe are looking after this work, so I will defer to them, thanks!
I've reviewed and run https://phabricator.services.mozilla.com/D50707; it can land any time, so followup patches like https://phabricator.services.mozilla.com/D50708 et al can use it; clearing need-info, since I think we're on-track, here.
|
||
Comment 16•5 years ago
|
||
Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.
This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:
0ee3c76a-bc79-4eb2-8d12-05dc0b68e732
|
|
||
Comment 17•5 years ago
|
||
Enabling Talos is a prerequisite for enabling Fission in Nightly (M6).
|
|
||
Comment 18•5 years ago
|
||
Looks like Stephen reviewed and the change request got merged.
Stephen is there anything else we need to do on this bug?
|
|
Reporter | |
Comment 19•5 years ago
|
||
(since I opened the bug, I just wanted to confirm that for me Bug 1588203 implemented everything needed by DAMP in terms of domains)
(In reply to Florin Strugariu [:Bebe] (needinfo me) from comment #18)
Looks like Stephen reviewed and the change request got merged.
Stephen is there anything else we need to do on this bug?
I don't believe so, as talos-cpstartup, talos-DAMP, and talos-tabswitch have all been successfully modified to take advantage of Doug's patch, here.
Doug, mind taking this bug as assignee, since you did the core enabling work, here, and resolving as FIXED, if you concur? Thanks!
|
|
||
Comment 21•5 years ago
|
||
cpstartup is done, the tabswitch tests are being updated to represent fission in bug 1588223, but I'm not familiar enough with the DAMP tests off the top of my head to know if they are ready as is. I would expect they would need similar changes to the ones in bug 1588223 - specifically, this would need to end up pointing into the fis/tp5n/ directory added in D53065, and the addon.test.damp.webserver pref would need to point to, I believe, "http://www.bild.de-talos".
|
|
Reporter | |
Comment 22•5 years ago
|
||
I can give a small status on DAMP+fission:
The DAMP fission meta is https://bugzilla.mozilla.org/show_bug.cgi?id=1454025.
We split our tests in three main categories simple, complicated and custom. The complicated are the ones using bild.de, but we are not migrating those tests to use remote frames. Instead we are migrating our custom tests, because they cover a lot more scenarios. Since we are keeping complicated without any remote frame, the complicated will also act as a non-fission baseline.
The work to add iframes in our custom tests is in progress at Bug 1589011 (just blocked on another bug for now). In the bug you can find comments that explain what motivated our decision. After bug 1589011 lands, all tests will target http://damp.top.com instead of the value of addon.test.damp.webserver. We are removing this preference since we can just target any http URL. All this is based on your patches from Bug 1588203.
the addon.test.damp.webserver pref would need to point to, I believe, "http://www.bild.de-talos"
From what I understand reading https://phabricator.services.mozilla.com/D53065, it seems tp5n can now automatically make some iframes use absolute URLs with a different eTLD+1? That's really nice! As I said above, we didn't actually plan to make the tests that use tp5n use remote frames. From a DevTools point of view they don't cover much compared to our custom.* tests. But we didn't consider that they could have remote iframes automatically added in the page, we were just thinking about wrapping them in iframes. So I am happy to file a follow up about that and discuss again with the team.
However for the current bug, the initial intent was "provide a way to use several domains in Talos". For me this was fixed by the proxy added in Bug 1588203 and we should close this as duplicate. Is it ok?
|
|
Reporter | |
Comment 24•5 years ago
|
||
Perfect thanks!
Description
•