browser_styleeditor_inline_friendly_names.js fails with server side target switching enabled
Categories
(DevTools :: Style Editor, defect)
Tracking
(Fission Milestone:MVP, firefox92 fixed)
Tracking | Status | |
---|---|---|
firefox92 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
Details
(Whiteboard: dt-fission-m3-mvp)
Attachments
(2 files)
$ ./mach mochitest --headless devtools/client/styleeditor/test/browser_styleeditor_inline_friendly_names.js --setpref devtools.target-switching.server.enabled=true
This is mostly because previous target is being destroyed after the new one initializes itself.
More concretely here, with this test, styleSheetChangeEventsEnabled
is being set to false by previous target page style actor:
https://searchfox.org/mozilla-central/rev/79a3ae0b0fa6abeca2cb7cf220df293c8dec9207/devtools/server/actors/style-sheets.js#74
after the new target (of the page we navigate to) set this same attribute to true:
https://searchfox.org/mozilla-central/rev/79a3ae0b0fa6abeca2cb7cf220df293c8dec9207/devtools/server/actors/utils/stylesheets-manager.js#144
This ends up disable notifications of new stylesheet, which is why this test doesn't see new stylesheets on navigations. The platform code won't fire StyleSheetApplicableStateChanged
because of that.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Assignee | ||
Comment 2•3 years ago
|
||
Destroy previous target before instantiating a new one.
Otherwise we will destroy it after having setup the new one
and the teardown sequence of the previous may undo the setup of the second.
Typically, in styleeditor, the styleSheetChangeEventsEnabled
boolean would be toggled
to true by the new target and reset back to false by the old target.
Updated•3 years ago
|
Comment 4•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b23689338b30
https://hg.mozilla.org/mozilla-central/rev/2730382d175b
Description
•