Emit will-navigate for server side generated target (aka JSWindowActor based targets) and stop clearing panels from onTargetAvailable
Categories
(DevTools :: Framework, enhancement)
Tracking
(Not tracked)
People
(Reporter: ochameau, Assigned: ochameau)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(1 obsolete file)
We started clearing panels from onTargetAvailable in case of top level target switching, but is causes some troubles with tests and/or clear the panel too late and make us miss early resource related to the new page we navigate to.
A stop-gap solution is to ensure will-navigate is emitted for all types of navigation and only and always clear panels based on this early event. As that's what DevTools has always been doing, tests are happier with such timing. And it helps a bit intercepting correctly the first top level navigation http request, which starts to be notified before onTargetAvailable is fired.
Assignee | ||
Comment 1•3 years ago
|
||
I'm dropping all clearing done from onTargetAvailable as:
- that doesn't fire for reload and same process navigations
(until we enable JSWindowActor based target for the first target) - it actually happens too late. Many tests assume the clearance is done very early on navigation.
And it's not impossible some resources, especially requests?
Comes in between will-navigate and target-available.
We at least have notification about the first document request which are notified before target-available.
But we may later switch from TargetFront's will-navigate to either onTargetDestroyed, onTargetAvailable,
or a new DOCUMENT_EVENT "will-navigate" ressource.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
Bug 1712592 will replace this bug.
Trying to make target's will-navigate event work wasn't solving all issues, or required too many hacks.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•