Network event requestTime is sometimes set to 0
Categories
(Remote Protocol :: WebDriver BiDi, defect, P2)
Tracking
(firefox-esr115 unaffected, firefox-esr128 unaffected, firefox132 wontfix, firefox133 wontfix, firefox134 fixed)
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | unaffected |
| firefox132 | --- | wontfix |
| firefox133 | --- | wontfix |
| firefox134 | --- | fixed |
People
(Reporter: jdescottes, Assigned: jdescottes)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [webdriver:m13][webdriver:relnote])
Attachments
(1 file)
Since switching to asyncOpenTime instead of channelCreationTime, we sometimes get network events with a requestTime of 0, which means asyncOpenTime was set to 0.
This seems to happen intermittently on the following website, but probably happens in other situations: https://www.hs.fi/
|
||
Updated•9 months ago
|
|
Assignee | |
Comment 1•9 months ago
|
||
It seems the issue triggers more consistently with the following STRs:
- open new tab
- load
data:text/html;charset=utf-8,<html><body></body></html>in the new tab - navigate to https://www.hs.fi/
The URLs for which this happens seem to change from reload to reload, I've seen it occur on the following URLs so far:
- https://www.hs.fi/api/laneitems/1152954?nodeType=normal
- https://www.hs.fi/
- https://er.sanoma-sndp.fi/v2/stats/other-view-end
Using devtools netmonitor in parallel to inspect the problematic requests, it seems that there is usually caching involved, but no service workers (there doesn't seem to be any on the page anyway).
Valentin, any idea in which situation we might have 0 as asyncOpenTime? I'm guessing we can fallback to channelCreationTime in that case, but maybe this is a bug which should also be investigated on necko's side?
|
|
Assignee | |
Comment 2•9 months ago
|
||
The root cause for asyncOpenTime = 0 should be investigated, but this leads to missing events in har recordings so we should try to fix it as soon as possible.
|
||
Updated•9 months ago
|
|
|
Assignee | |
Updated•9 months ago
|
|
||
Updated•9 months ago
|
|
||
Comment 4•9 months ago
|
||
| bugherder | ||
|
|
||
Updated•9 months ago
|
|
|
||
Comment 5•9 months ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #1)
Valentin, any idea in which situation we might have 0 as asyncOpenTime? I'm guessing we can fallback to channelCreationTime in that case, but maybe this is a bug which should also be investigated on necko's side?
This needinfo is still valid and we would like to hear from Valentin. What we landed is just a workaround.
|
||
Comment 6•9 months ago
|
||
Julian, I did a try push with this line commented:
https://treeherder.mozilla.org/jobs?repo=try&revision=0e479c1ed57b194274bdf537190e2594e9129b8b
Could you check if fixes the problem?
|
|
Assignee | |
Comment 7•9 months ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #6)
Julian, I did a try push with this line commented:
https://treeherder.mozilla.org/jobs?repo=try&revision=0e479c1ed57b194274bdf537190e2594e9129b8b
Could you check if fixes the problem?
Thanks! Looks like this fixes the issue, I no longer see asyncOpenTime=0 on https://www.hs.fi/
Do you want me to file another bug to handle the fix?
|
|
||
Comment 8•9 months ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #7)
Do you want me to file another bug to handle the fix?
I filed bug 1931514 for this.
|
||
Comment 9•9 months ago
|
||
The patch landed in nightly and beta is affected.
:jdescottes, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox133towontfix.
For more information, please visit BugBot documentation.
|
||
Updated•9 months ago
|
|
|
||
Updated•9 months ago
|
|
|
||
Updated•8 months ago
|
Description
•