browser_device_change.js (and many other RDM tests) fail with server targets
Categories
(DevTools :: Responsive Design Mode, defect)
Tracking
(Fission Milestone:MVP, firefox92 fixed)
Tracking | Status | |
---|---|---|
firefox92 | --- | fixed |
People
(Reporter: ochameau, Assigned: nchevobbe)
References
Details
(Whiteboard: dt-fission-m3-mvp)
Attachments
(1 file, 1 obsolete file)
This fails because we are closing the RDM over here:
https://searchfox.org/mozilla-central/rev/072710086ddfe25aa2962c8399fefb2304e8193b/devtools/client/responsive/test/browser/browser_device_change.js#110-112
And expect it to reload the page. We then assert values which depends on reloading the page.
But we don't reload with server targets, because over there:
https://searchfox.org/mozilla-central/rev/072710086ddfe25aa2962c8399fefb2304e8193b/devtools/client/responsive/ui.js#252-259
this.responsiveFront
is destroyed...
I imagine that during a target switch, when doing a reload this front may be destroyed during a short period of time.
We should probably change this check to something else.
Reporter | ||
Comment 1•3 years ago
|
||
This test expect RDM to reload the page on destroy,
but because of a race condition -or- because of a behavior change with target switching,
responsiveFront ends up being destroyed and we don't reload.
(And may be also browser_max_touchpoints.js, browser_page_redirection.js, browser_touch_event_should_bubble.js, /browser_touch_pointerevents.js, ...)
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
Depends on D121059
Updated•3 years ago
|
Updated•3 years ago
|
Comment 4•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Description
•