Bug 1387023 - initialize devtools before asserting menu items in browser_989751_subviewbutton_class.js;
59 bytes, text/x-review-board-request
After Bug 1359855 devtools are only initialized when the user first interacts with a valid entry point such as : - a devtools keyboard shortcut - a devtools menu entry - a devtools command line option The devtools initialization is responsible of filling the menuWebDeveloperPopup based on the currently enabled tools. In the test browser/components/customizableui/test/browser_989751_subviewbutton_class.js we try to add a class to an item in this popup before displaying the developer menu (which contains items copied from menuWebDeveloperPopup). If this test is run in isolation (or is the first to run in its chunk) it will fail. Ideally, as devtools should move to an addon, we should make the test rely on another set of buttons/popups. I tried to migrate it to use the history button / panels, but it doesn't seem to be using the same mechanism as the devtools one. For the time being, in order to avoid inconsistent failures, we should at least initialize devtools at the beginning of the test by requiring devtools-browser.
Comment on attachment 8893356 [details] Bug 1387023 - initialize devtools before asserting menu items in browser_989751_subviewbutton_class.js; https://reviewboard.mozilla.org/r/164446/#review169728 Nice, thanks!
Attachment #8893356 - Flags: review?(gijskruitbosch+bugs) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/f66e161dd72f initialize devtools before asserting menu items in browser_989751_subviewbutton_class.js;r=Gijs
You need to log in before you can comment on or make changes to this bug.