-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Introduce webext run --devtools to open DevTools for the installed add-on right away. #2488
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ochameau thank you so much for looking into the improvements to the webextensions debugging, I just tried this patch locally combined with (most of) the changes from Bug 1787409 (and the other patch in that stack) and it definitely provides a nicer developer experience.
It seems also (at least if I'm not mistaken) that on older Firefox versions where the changes from Bug 1787409 will not be available the additional openDevTools
property in the installTemporaryAddon RDP request is just ignored, and so it looks that we will not need to do any runtime detection and fallback, which is also great.
Follows a couple of small tweaks to let the PR to run all tests in the CI job (fixing linting and flow error, and an unrelated test failure due to the change to the method signature that the sinon stub wasn't expecting).
Would you mind to also remove the package-lock.json change? that is unrelated (and pretty big because running npm install
with an older npm version rewrite the entire lock file to lockfileVersion 1).
You should be able to avoid the automatic rewite of the lock file by running npm ci
instead of npm install
.
Yes I confirm, no backward compat is needed, unless we want to warn when using --devtools on an unsupported version. Thanks for all the suggestion to fix all ci issues \o/ |
…led add-on right away. This depends on bug 1787409.
2de9030
to
94989fa
Compare
I only started asking for review on https://bugzilla.mozilla.org/show_bug.cgi?id=1787409 |
I added a new changeset to promote this new command line argument and also mention https://extensionworkshop.com/documentation/develop/debugging/ |
Document the new command line argument introduced in mozilla/web-ext#2488
I'm also trying to document this new command line argument over there. |
81a0f49
to
1f14786
Compare
I pushed a change to fix lint issues, but jobs are still failing whereas |
@ochameau sorry for not having got back to this sooner, I noticed it and I was meant to comment but didn't got back to this quickly enough (or at least not as quickly as you ;-)) Those failures are coming from the function, which are the ones that can be also run locally using
The following one line patch should fix that remaining CI job failure:
|
1f14786
to
87e5423
Compare
Thanks for the investigate. I hope jobs will be green now. |
Codecov Report
@@ Coverage Diff @@
## master #2488 +/- ##
=======================================
Coverage 99.52% 99.52%
=======================================
Files 32 32
Lines 1677 1681 +4
=======================================
+ Hits 1669 1673 +4
Misses 8 8
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ochameau looks pretty great, I have just one more thoughts described in the inline review comment below (I'm basically wondering if we really need to condition those logs, if we think it is not necessary we can revert a couple of changes related to propagating verbose and avoid the codecov failure as a side effect).
src/firefox/index.js
Outdated
if (!verbose && !devtools) { | ||
log.info('Use --verbose or --devtools to see logging'); | ||
} | ||
if (devtools) { | ||
log.info('More info about WebExtension debugging:'); | ||
log.info('https://extensionworkshop.com/documentation/develop/debugging/'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ochameau I'm thinking that we may as well always log this couple of messages, instead of condition them on the verbose and devtools flags.
wdyt?
As a side-effect, that may also make codecov to don't complain about these logs emitted on devtools === true
not being covered in tests (which are not a big deal on their own, given that its just two informative logs I wouldn't definitely block on that codecov coverage failure).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH, I'm not working enough with this tooling to have a strong opinion.
So I would prefer to defer to you/your team judgement.
I'm fine removing, or adding proper coverage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, let's remove the verbose
flag propagation and keep that log unconditioned, while condition the new one to the devtools
flag.
Let's also change WebExtension
to WebExtensions
in the new logged message and let's add something like this to test.firefox.js
to explicitly cover it and make codecov happy again:
import {
consoleStream, // instance is imported to inspect logged messages
} from '../../../src/util/logger.js';
...
it('logs link to debugging docs', async () => {
const runner = createFakeFxRunner();
consoleStream.flushCapturedLogs();
consoleStream.startCapturing();
const expectedMessage = 'More info about WebExtensions debugging:';
const expectedURLToDocs =
'https://extensionworkshop.com/documentation/develop/debugging/';
await runFirefox({fxRunner: runner, devtools: false});
assert.notOk(consoleStream.capturedMessages.find(
(msg) => msg.includes(expectedMessage)
));
assert.notOk(consoleStream.capturedMessages.find(
(msg) => msg.includes(expectedURLToDocs)
));
consoleStream.flushCapturedLogs();
await runFirefox({fxRunner: runner, devtools: true});
const foundMessage = consoleStream.capturedMessages.find(
(msg) => msg.includes(expectedMessage)
);
const foundDocURL = consoleStream.capturedMessages.find(
(msg) => msg.includes(expectedURLToDocs)
);
// Expect the logs to be found.
assert.ok(foundMessage);
assert.ok(foundDocURL);
// Expected to be emitted as info level logs.
assert.ok(foundMessage?.includes('[info]'));
assert.ok(foundDocURL?.includes('[info]'));
});
src/firefox/index.js
Outdated
if (!verbose && !devtools) { | ||
log.info('Use --verbose or --devtools to see logging'); | ||
} | ||
if (devtools) { | ||
log.info('More info about WebExtension debugging:'); | ||
log.info('https://extensionworkshop.com/documentation/develop/debugging/'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, let's remove the verbose
flag propagation and keep that log unconditioned, while condition the new one to the devtools
flag.
Let's also change WebExtension
to WebExtensions
in the new logged message and let's add something like this to test.firefox.js
to explicitly cover it and make codecov happy again:
import {
consoleStream, // instance is imported to inspect logged messages
} from '../../../src/util/logger.js';
...
it('logs link to debugging docs', async () => {
const runner = createFakeFxRunner();
consoleStream.flushCapturedLogs();
consoleStream.startCapturing();
const expectedMessage = 'More info about WebExtensions debugging:';
const expectedURLToDocs =
'https://extensionworkshop.com/documentation/develop/debugging/';
await runFirefox({fxRunner: runner, devtools: false});
assert.notOk(consoleStream.capturedMessages.find(
(msg) => msg.includes(expectedMessage)
));
assert.notOk(consoleStream.capturedMessages.find(
(msg) => msg.includes(expectedURLToDocs)
));
consoleStream.flushCapturedLogs();
await runFirefox({fxRunner: runner, devtools: true});
const foundMessage = consoleStream.capturedMessages.find(
(msg) => msg.includes(expectedMessage)
);
const foundDocURL = consoleStream.capturedMessages.find(
(msg) => msg.includes(expectedURLToDocs)
);
// Expect the logs to be found.
assert.ok(foundMessage);
assert.ok(foundDocURL);
// Expected to be emitted as info level logs.
assert.ok(foundMessage?.includes('[info]'));
assert.ok(foundDocURL?.includes('[info]'));
});
…g online documentation
87e5423
to
6f58053
Compare
Thanks a lot for the test snippet! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@ochameau thank you so much for the work you have done on both Firefox and web-ext side for introducing this new option! ❤️
I am going to land this PR to avoid future conflicts. |
Document the new command line argument introduced in mozilla/web-ext#2488
This depends on bug 1787409 and aims at addressing issue #759.