New Firefox HAR do not generate new pages in spa example

[soulgalore]

New Firefox HAR do not generate new pages in spa example

[soulgalore]

Great that worked fine, thank you @juliandescottes !

[juliandescottes]

I checked and we get a Page.navigatedWithinDocument event that we use.

Thanks for the info. Filed w3c/webdriver-bidi#402 for BiDi

[juliandescottes]

Do you know if maybe we need to change something in Browsertime?

I don't think so, it's most likely a bug in the way we detect pages. Right now we attempt to match load & domContentLoaded events with a request by comparing the URL, which is probably fragile at best.

Can I more or less reproduce that by trying to load https://dashboard.sitespeed.io/d/9NDMzFfMk/page-metrics-desktop?orgId=1&var-base=sitespeed_io&var-path=desktop&var-testname=spa&var-group=dashboard_sitespeed_io&var-page=pageTimingMetricsDefault&var-browser=chrome&var-connectivity=cable&var-function=median&var-resulturl=https:%2F%2Fdata.sitespeed.io%2F&var-screenshottype=jpg ?

[juliandescottes]

I can reproduce consistently on this page, that's a bug on our side.

[juliandescottes]

@soulgalore

The root cause of the issue is that we try to match a pair of load and domContentLoaded events to a first "request" in order to create our pages array. To do so, we use the document's baseURI from the load/domContentLoaded events, and try to find the last request which attempted to load this same URI.

Here the page uses <base href="/"> which makes the document's base URI "https://dashboard.sitespeed.io/" whereas the request to load the document hits https://dashboard.sitespeed.io/d/9NDMzFfMk/page-metrics-desktop?orgId=1&var-base=sitespeed_io&var-path=desktop&var-testname=spa&var-group=dashboard_sitespeed_io&var-page=pageTimingMetricsDefault&var-browser=chrome&var-connectivity=cable&var-function=median&var-resulturl=https:%2F%2Fdata.sitespeed.io%2F&var-screenshottype=jpg

Overall until we have a correct navigation id which can allow us to clear link together network events and load events, we have to workaround.

In that case, I guess we need a fallback in case we can't match any URL.

Another option would be to remove <base href="/"> but I guess that's important for other reasons and in any case I don't think it's reasonable for you to modify your test pages to accommodate our export helper.

I'll try to find a workaround.

[juliandescottes]

I actually think this is a bug in the bidi events themselves... we should not use the baseURI for those events. I can still try to roll out a workaround in the bidi-har-export helper, will be faster than waiting for a fix to ride the trains with Firefox.

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1825634

[juliandescottes]

@soulgalore you could try to update to version 0.0.6, it should have a workaround for this issue.

[soulgalore]

Hi @juliandescottes so I think something is still not working perfectly here so re-opening. I can see that we get errors on the test server. When I run like this in main:
bin/browsertime.js --spa spa.js -b firefox --firefox.bidihar

And look in the HAR file:

At the end there's three pages, it should be two (we access one page, click on one navigation)? And there's some request at the top that misses any page.

[juliandescottes]

@soulgalore thanks for the ping!

Few questions first.

From what I can see, we actually only get 1 page if we run with -n 1. So it seems the 3 pages are just because of the 3 iterations. How is browsertime merging the different pages for the different iterations?

Regarding the orphaned requests, after the second measure starts, I do not detect any navigation in the bidi-har-recorder. I guess that since this is a single-page-app test, I can't really expect to get a domContentLoaded or a load event? In that case what do we expect to find in the har? Just a page entry corresponding to the current page?

[juliandescottes]

Tried to compare with 0.0.6 of bidi-har-export, and I get the same output, so at least it's not a regression due to the recent changes.

Comparing with the current devtools firefox har solution, I get 6 pages, so 2 per iteration. But they are completely wrong. The second page for each iteration still contains all the requests for the first page, fully duplicated.

[juliandescottes]

I can see that chrome also has 6 pages, 2 per iteration, so I don't think the number of pages is the problem here. The main issue is that we have orphaned requests for the second measure, because we failed to identify any navigation.

I imagine in this case we should still try to group all those orphaned requests under a single page entry. Now to get the good "url" in this case, I would have to know the URL at the end of the recording, whereas in most cases if we have orphaned requests before a navigation starts, they should be attached to the "initial" url.

I think I can provide a workaround in the exporter here, but we might need to clarify how HAR is expected to work in this case.

[soulgalore]

True, it does't work in the old exporter.

I think it should be like this in a perfect world:

In Chrome I think we internally get an event that we navigate, even though that is a spa, but I need to look in the code. I guess there's no smart way to handle that today?

[juliandescottes]

In Chrome I think we internally get an event that we navigate

If you find it, I'd be interested to know which even it is. If it's a CDP event we might be interested to bring it to BiDi.

Otherwise, yes for now this area is not clearly covered in the specs, but I still think we can make the bidi-har-exporter smart enough to handle those cases.

Basically there are 2 use cases which we can better handle:

• all requests are orphaned (no page recorded at all)
• some requests are orphaned (happened before the first page navigation was detected)

In the first case, I think we should pick the url + title of the page when the recording stopped and use that to build a page entry. In the second case, we should pick the url + title of the page when the recording started.

This means the har recorder will need a bit more data, but in the selenium node case, I hope I can just get it from selenium. And otherwise I can still create "dummy" pages, which will be better than not grouping at all.

[soulgalore]

I checked and we get a Page.navigatedWithinDocument event that we use.

[juliandescottes]

@soulgalore you can try to update to 0.0.9, it should now bundle orphaned requests correctly in the spa example.

[soulgalore]

Thanks that worked (no orphan requests). Got one error with missing onLoad onContentLoad when I tried to verify it.

[juliandescottes]

Oh right, I am not trying to compute those since I really don't have any meaningful way to compute them. For a history pushState navigation, I'm not sure what load and domContentLoaded should be? Maybe setting 0 to both would be meaningful?

[juliandescottes]

Ah I see the chrome har is not having any load or domContentLoaded for those pages, whereas the bidi har has the properties, but set to null. If that works I can just exclude them fully, that's not a problem.

[juliandescottes]

@soulgalore Fixed that in 0.0.10. I am usually validating the HAR files using the HAR viewer at http://www.softwareishard.com/har/viewer/

Is there anyway I can locally check that the HAR won't trigger errors for you?

[soulgalore]

Thanks let me run an update. I use http://www.softwareishard.com/har/viewer/ :)

[juliandescottes]

Oh my bad, I had unchecked

a while ago to test something, and I didn't notice it remained unchecked since then!