profile
viewpoint

mozilla/web-ext 1034

A command line tool to help build, run, and test web extensions

mozilla/addon-sdk 649

The Add-on SDK repository.

bard/mozrepl 512

[NB: END-OF-LIFE, SEE README] Remotely control Firefox and other Mozilla apps with JavaScript.

mozilla/FirefoxColor 270

Theming demo for Firefox Quantum and beyond

mozilla-extensions/secure-proxy 122

Firefox Private Network Web Extension

harthur/firefox-client 100

[UNMAINTAINED] Node.js remote debugging client for Firefox

rpl/angularjs-batarang 32

Firefox port of "AngularJS WebInspector Extension for Chrome"

eolo999/Italian-Erlang-User-Group 12

Italian Erlang User Group Site

mozilla/OpenWPM-WebExtension-Experiment 3

SUPERSEEDED/REPLACED this approach by using the existing WebExtension APIs directly (previous explanation: WebExtension experiments API for privacy-related browser instrumentation that requires privileged code)

rpl/coffee-script 3

Unfancy JavaScript

PR opened mozilla/application-services

webext-storage: Do not check total bytes quota on storage.sync.remove operations

Changes related to Bug 1656947.

Pull Request checklist

<!-- Before submitting the PR, please address each item -->

  • [ ] Quality: This PR builds and tests run cleanly
    • automation/all_tests.sh runs to completion and produces no failures
    • Note: For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
  • [ ] Tests: This PR includes thorough tests or an explanation of why it does not
  • [ ] Changelog: This PR includes a changelog entry in CHANGES_UNRELEASED.md or an explanation of why it does not need one
    • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
  • [ ] Dependencies: This PR follows our dependency management guidelines
    • Any new dependencies are accompanied by a summary of the due dilligence applied in selecting them.
+76 -12

0 comment

2 changed files

pr created time in a day

push eventrpl/application-services

Luca Greco

commit sha 829e9055487e65c8f3d6feee3f6ffba658b235fe

webext-storage: Do not check total bytes quota on storage.sync.remove

view details

push time in a day

push eventrpl/application-services

Luca Greco

commit sha 9e8c92f8dc3f97d34cea61aa7694d8ae2642531e

webext-storage: Do not check total bytes quota on storage.sync.remove

view details

push time in a day

Pull request review commentmozilla/extension-activity-monitor

feat: load logs from json file

 class Controller {     }   } +  async loadLogs(file) {+    try {+      const logStr = await load.loadLogAsText(file);+      const logs = JSON.parse(logStr);++      const storedFileName = await browser.runtime.sendMessage({+        requestTo: 'ext-monitor',+        requestType: 'setLoadedLogs',+        detail: { fileName: file.name, logs },+      });+      const searchParams = `file=${storedFileName}`;++      this.view.setError(null);++      const tab = await browser.tabs.create({+        url: getActivityLogPageURL(searchParams),+      });++      await browser.runtime.sendMessage({+        requestTo: 'ext-monitor',+        requestType: 'setLoadedLogsTabId',+        detail: { tabId: tab.id, fileName: storedFileName },+      });

yeah that's right (but I notice that you did already proceed to implement it, and so my reply did come late :-P)

atiqueahmedziad

comment created time in 2 days

Pull request review commentmozilla/extension-activity-monitor

feat: load logs from json file

 import { getActivityLogPageURL } from './ext-listen.js';+import { load } from './save-load.js';  export default class ExtensionMonitor {+  // Map<number, Array>+  loadedLogs = new Map();

The inline comments does explicitly mention what is the type of the key, but not what it does represents, and the name of the property does not make it clear neither.

Calling this property loadedLogsByTabId would be making it clear enough without having to spelling that again in the inline comment. The property is used only in 4 places and so even if the name is a bit longer it shouldn't make the core too much more verbose.

Otherwise you should at least mention it nearby the inline comment.

atiqueahmedziad

comment created time in 2 days

Pull request review commentmozilla/extension-activity-monitor

feat: load logs from json file

 export default class ExtensionMonitor {     }   }; +  onRemovedListener = (tabId) => {+    // When we close any tab which was loaded with logs from a log file.

Nit, // Remove the loaded logs related to the closed tab may be slightly more clear and as short as yours.

atiqueahmedziad

comment created time in 2 days

Pull request review commentmozilla/extension-activity-monitor

feat: load logs from json file

 describe('messageListeners functionalities test', () => {   }); }); -test('onMessage listener is registered at initialization', () => {+test('listeners are registered at initialization', () => {   const addListener = jest.fn().mockResolvedValue();    window.browser = {     runtime: { onMessage: { addListener } },+    tabs: { onRemoved: { addListener } },   };    const extMonitor = new ExtensionMonitor();   extMonitor.init(); -  expect(addListener).toHaveBeenCalled();+  // runtime.onMessage.addListener and tabs.onRemoved.addListener are called.+  expect(addListener).toHaveBeenCalledTimes(2);

the change applied to the test is workarounding the failure instead of aligning the test to the expected new behavior, as an example the test would not fail if the ext-monitor module does subscribe two runtime.onMessage listeners or two tabs.onRemoved listeners but not both as expected.

you should create two separate mocked addListener functions and then assert that each one of them has been called exactly once.

atiqueahmedziad

comment created time in 2 days

Pull request review commentmozilla/extension-activity-monitor

feat: load logs from json file

 export default class ExtensionMonitor {     startMonitor: () => this.startMonitor(),     stopMonitor: () => this.stopMonitor(),     sendAllLogs: () => ({ existingLogs: this.logs }),+    setLoadedLogs: (detail) => this.setLoadedLogs(detail),+    getLoadedLogs: (detail) => this.getLoadedLogs(detail),+    setLoadedLogsTabId: (detail) => this.setLoadedLogsTabId(detail),   }; +  setLoadedLogs({ fileName, logs }) {+    let repeatTimes = 0;+    for (const storedFileName of this.loadedLogs.keys()) {+      if (storedFileName.includes(fileName)) {+        repeatTimes++;+      }+    }++    // if file exists with same name+    if (repeatTimes) {+      fileName = `${fileName}-${repeatTimes}`;+    }++    this.loadedLogs.set(fileName, logs);+    return fileName;+  }++  getLoadedLogs({ fileName }) {+    const logs = this.loadedLogs.get(fileName);+    if (!logs) {+      throw new Error(`The following log file is not found: ${fileName}`);+    }+    return logs;+  }++  setLoadedLogsTabId({ fileName, tabId }) {+    this.loadedLogsTabIds.set(tabId, fileName);+  }+   messageListener = (message) => {-    const { requestType, requestTo } = message;+    const { requestType, requestTo, detail } = message;

Let's rename detail to something like requestParams, in the end it is what we pass to the requestType method and so it should be easier to understand what that property is.

atiqueahmedziad

comment created time in 2 days

Pull request review commentmozilla/extension-activity-monitor

feat: load logs from json file

 import { getActivityLogPageURL } from './ext-listen.js';  export default class ExtensionMonitor {+  // Map<string, Array>+  loadedLogs = new Map();+  // Map<number, string>+  loadedLogsTabIds = new Map();

Given that we agreed to clear the logs automatically when the tab we have opened has been navigated or closed, it may be better to:

  • keep the loaded logs in a map keyed by tabId, as the value of the map we could store an object that contains both the filename and the loaded logs in two separate properties

does that sounds reasonable?

(this should, at least at a first glance, also simplify a bit setLoadedLogs, e.g. we will not need to care about the unique file name thing)

atiqueahmedziad

comment created time in 2 days

Pull request review commentmozilla/extension-activity-monitor

feat: load logs from json file

 class Controller {     }   } +  async loadLogs(file) {+    try {+      const logStr = await load.loadLogAsText(file);+      const logs = JSON.parse(logStr);++      const storedFileName = await browser.runtime.sendMessage({+        requestTo: 'ext-monitor',+        requestType: 'setLoadedLogs',+        detail: { fileName: file.name, logs },+      });+      const searchParams = `file=${storedFileName}`;++      this.view.setError(null);++      const tab = await browser.tabs.create({+        url: getActivityLogPageURL(searchParams),+      });++      await browser.runtime.sendMessage({+        requestTo: 'ext-monitor',+        requestType: 'setLoadedLogsTabId',+        detail: { tabId: tab.id, fileName: storedFileName },+      });

Instead on being the activitylog page to send the logs to the background page, then create a new tab and then send another message to the background page to associate the tab.id to the loaded file, this could actually be a responsibility of the background page (or the ext-monitor module actually), as part of what it does to handle a single 'openLoadedLogsTab`.

(Let me know if my request isn't clear enough as described above)

atiqueahmedziad

comment created time in 2 days

Pull request review commentmozilla/extension-activity-monitor

feat: load logs from json file

 class Controller {     }   } +  async loadLogs(file) {+    try {+      const logStr = await load.loadLogAsText(file);+      const logs = JSON.parse(logStr);

Nit, we do have a load ESM module, I think that JSON.parse should be a responsibility of that module instead of being a responsibility of the Controller class.

atiqueahmedziad

comment created time in 2 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

 <h2>Activity Logs</h2>       </div>     </template>   </body>++  <template id="filterTimestampTemplate">+    <link+      rel="stylesheet"+      href="/lib/web-component/filter-timestamp/filter-timestamp.css"+    />+    <div class="timestamp-filter-container" hidden>+      <div class="label">+        Timestamp Filter Applied+        <div id="clearBtn" title="Clear timestamp filter"></div>

As a user I feel that I may want to also clear the start and stop timestamps separately. It's fine to deal with this in a separate follow up and pull request (just file the issue for now and come back to it when you are not busy with other higher priority issues we do have in the backlog, anyway implementing it shouldn't require too many changes).

atiqueahmedziad

comment created time in 2 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

+export class FilterTimestamp extends HTMLElement {+  constructor() {+    super();++    this.timeStamp = {};+    this.onHiddenListener = () => browser.menus.removeAll();++    const shadow = this.attachShadow({ mode: 'open' });++    const filterTSWrapper = document+      .querySelector('#filterTimestampTemplate')+      .content.cloneNode(true);++    this.filterTSContainer = filterTSWrapper.querySelector(+      '.timestamp-filter-container'+    );++    this.startTimeLabel = filterTSWrapper.querySelector('#startTimeLabel');+    this.stopTimeLabel = filterTSWrapper.querySelector('#stopTimeLabel');+    this.clearTSFilterBtn = filterTSWrapper.querySelector('#clearBtn');++    shadow.appendChild(filterTSWrapper);+  }++  setFilterRange = (info, tab) => {+    if (tab.id !== this.tab.id) {+      return;+    }++    const selectedEl = browser.menus.getTargetElement(info.targetElementId);+    const selectedRow = selectedEl.closest('tr');++    if (!selectedRow) {+      return;+    }++    const chosenTimestamp = selectedRow.querySelector('.timestamp').textContent;+    if (info.menuItemId === 'startTime') {+      this.timeStamp.start = Date.parse(chosenTimestamp);+      this.startTimeLabel.textContent = chosenTimestamp;+    } else if (info.menuItemId === 'stopTime') {+      this.timeStamp.stop = Date.parse(chosenTimestamp);+      this.stopTimeLabel.textContent = chosenTimestamp;+    }++    this.filterTSContainer.hidden = false;+    this.disptachTSFilterEvent();+  };++  disptachTSFilterEvent() {

This method name does also have a type (disptach => dispatch), we should fix that and remove the TS part from the method name (as also mentioned in a previous review comment).

I would name it dispatchFilterChange.

atiqueahmedziad

comment created time in 2 days

issue closedmozilla/web-ext

Feature request: TypeScript definition

I found this project is written in flow, so I use https://github.com/Khan/flow-to-ts and https://api-extractor.com/ to generate a single .d.ts file but it will be nice to have an official type definition file!

closed time in 2 days

Jack-Works

issue commentmozilla/web-ext

Feature request: TypeScript definition

@Jack-Works thanks for looking into this, I was not even aware of flow-to-ts.

During our triaging yesterday I discussed about this issue with the rest of the team and we agreed that our preference would be to not integrate the generated file into this repo but as a separate npm package, for a couple of reasons:

  • providing the typescript type signature as part of the web-ext npm package would actually require us to create some new automation to regenerate it as part of the regular developer workflow for this project (and also test that the generated type definitions are correct).
  • there is also a chance that in some cases (probably not many, but still not completely impossible) a change to the flow types may trigger an unexpected issue in the automated type definition conversion (that would also need to be investigated).

Nevertheless, this may be a good addition to the type definitions npm packages that are being created from the DefinitelyTyped repository and we would be glad to help you with feedback comments on the pull request you could create in the DefinitelyTyped repo (if you like this idea and decide to create it) and then we would be open to link the official type definition npm package in our README.

I'm going to close this issue as wontfix, but feel free to mention me in the DefinitelyTyped pull request (and to open a new pull request to link that package in our README once a web-ext type definitions package is being released from that repo).

Jack-Works

comment created time in 2 days

issue commentmozilla/web-ext

JSON_INVALID lint error returns null file name instead of actual JSON file name

@pdehaan this is going to be technically an addons-linter issue, would you mind to file this issue in that repo?

pdehaan

comment created time in 2 days

delete branch mozilla/web-ext

delete branch : renovate/flow-bin-0.x

delete time in 2 days

push eventmozilla/web-ext

renovate[bot]

commit sha 9353e260d016a6c301cac520fbdc57d5e3e89375

chore(deps): update dependency flow-bin to v0.131.0 (#1992) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 2 days

PR merged mozilla/web-ext

chore(deps): update dependency flow-bin to v0.131.0

This PR contains the following updates:

Package Type Update Change
flow-bin (changelog) devDependencies minor 0.130.0 -> 0.131.0

Release Notes

<details> <summary>flowtype/flow-bin</summary>

v0.131.0

Compare Source

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

1 comment

2 changed files

renovate[bot]

pr closed time in 2 days

delete branch mozilla/web-ext

delete branch : renovate/babel-monorepo

delete time in 2 days

push eventmozilla/web-ext

renovate[bot]

commit sha 44593707f770dd0bd30f8780ae0a9adac20cf2e0

fix(deps): update dependency @babel/runtime to v7.11.2 (#1989) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 2 days

PR merged mozilla/web-ext

fix(deps): update dependency @babel/runtime to v7.11.2

This PR contains the following updates:

Package Type Update Change
@babel/runtime (source) dependencies patch 7.11.1 -> 7.11.2

Release Notes

<details> <summary>babel/babel</summary>

v7.11.2

Compare Source

:bug: Bug Fix

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

1 comment

2 changed files

renovate[bot]

pr closed time in 2 days

push eventmozilla/web-ext

Makoto Motohashi

commit sha b40f9cece541ff1543c9834843aae35821c6ca51

fix: Wrong example of requiring web-ext (#1991)

view details

push time in 2 days

PR merged mozilla/web-ext

fix: Wrong example of requiring web-ext

Fixes #1990

+1 -1

3 comments

1 changed file

mmktomato

pr closed time in 2 days

issue closedmozilla/web-ext

Wrong example of requiring web-ext in README.md

Is this a feature request or a bug?

Bug

What is the current behavior?

<!--

  • If this is a bug, please explain how to reproduce the problem and include the web-ext commands you ran.
  • Do not include sensitive information like API secrets.
  • Upload a text log created with the verbose flag if possible.
  • Upload a zip file of your web extension source if necessary. --> I found a wrong example of requiring web-ext in README's Using web-ext in NodeJS code section. https://github.com/mozilla/web-ext#using-web-ext-in-nodejs-code
// const webExt = require('web-ext').default;    <----- this
// or...

What is the expected or desired behavior?

By #1934 , this should be:

// const webExt = require('web-ext');
// or...

Version information (for bug reports)

Not related to versions of web-ext, Node or browser because this is a document mistake.

closed time in 2 days

mmktomato

issue commentmozilla/extension-activity-monitor

ActivityLog DevTools panel

@atiqueahmedziad yep, it looks right, that's a summary of the plan.

Follows answers to the two questions:

Question:

1. I will be matching [`this tabId`](https://searchfox.org/mozilla-central/source/toolkit/components/extensions/schemas/activity_log.json#63) property from logs with `TabId` from `filterTabId=TabId` to filter the logs. Am I right?

yes, that's the idea.

2. Should I use "Extension Activity Monitor" OR "EAM" as name to create the panel in developer toolbox ?

I think that the label should be "Extension Activity Monitor".

rpl

comment created time in 3 days

issue closedmozilla/web-ext

Signing fails with "Signing took too long to complete" but also succeeds

Is this a feature request or a bug?

Bug

What is the current behavior?

When running the webExt.cmd.sign({...}) command, we're seeing an intermittent behavior where the response comes back with a "Signing took too long to complete" error, but the signing also succeeds and downloads the signed extension.

The code being executed is:

const response = await webExt.cmd.sign({
      apiKey: FIREFOX_ADDON_MANAGER_KEY,
      apiSecret: FIREFOX_ADDON_MANAGER_SECRET,
      artifactsDir: SIGNED_EXTENSION_DIR,
      sourceDir: UNSIGNED_EXTENSION_DIR,
      timeout: 300000,
});

if (response.errorDetails) throw new Error(response.errorDetails);

When this code runs, sometimes everything works just as expected. There are no errors and the signing process is flawless. However, periodically (I would say 1 out of every 5 times) we get the following output:

Building web extension from /code/built/firefox
Validating add-on [...................................................................................................]
Validation results: https://addons.mozilla.org/en-US/developers/upload/78b76011e24a409cbafcae1266cd7abe
Signing add-on [......................................................................................................]

(node:62975) UnhandledPromiseRejectionWarning: Error: Signing took too long to complete; last status: {"guid":"hidden@hidden.io","active":false,"automated_signing":true,"url":"https://addons.mozilla.org/api/v4/addons/hidden@hidden.io/versions/2.45.14/uploads/78b76011e24a409cbafcae1266cd7abe/","files":[{"download_url":"https://addons.mozilla.org/api/v4/file/3612605/hidden-2.45.14-an+fx.xpi?src=api","hash":"sha256:74b15e530b05209e63a49a740eda8aec87f0aa534c2d699562b3e548aabc5d1b","signed":false}],"passed_review":false,"pk":"78b72222e24a409cbafcae1266cd7abe","processed":true,"reviewed":false,"valid"...
    at Object.exports.sign (/extension/scripts/publishFirefox.ts:200:15)

Signing add-on [......................................................................................................]
Downloading signed files: 100%
Downloaded:
    /code/built/zip-ff-signed/hidden-2.45.14-an+fx.xpi

Note that we get both an error, and a successful response.

This creates a problem from us in terms of recovery. We can't simply retry the script again because the version has now been added to AMO so we need to re-bump the version number in order to retry from start to finish.

What is the expected or desired behavior?

Either success every time, or (if there is an error), then return an error and abort the signing process.

Version information (for bug reports)

  • Firefox version: N/A
  • Your OS and version: MacOS 10.15.6
  • Paste the output of these commands:
node --version && npm --version && web-ext --version

v10.17.0 6.14.7 5.0.0

closed time in 3 days

EvHaus

issue commentmozilla/web-ext

Signing fails with "Signing took too long to complete" but also succeeds

@EvHaus I'm closing this issue as invalid for now (based on the previous comments), feel free to reopen if increasing the timeout didn't fix the issue for you and we can evaluate what to do next.

EvHaus

comment created time in 3 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

+export class FilterTimestamp extends HTMLElement {+  constructor() {+    super();++    this.timeStamp = {};+    this.onHiddenListener = () => browser.menus.removeAll();

this onHiddenListener doesn't seem to be using this anywhere, could just be a method of the FilterTimestamp class instead of an arrow function set on a class instance parameter?

atiqueahmedziad

comment created time in 3 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

+export class FilterTimestamp extends HTMLElement {+  constructor() {+    super();++    this.timeStamp = {};+    this.onHiddenListener = () => browser.menus.removeAll();++    const shadow = this.attachShadow({ mode: 'open' });++    const filterTSWrapper = document+      .querySelector('#filterTimestampTemplate')+      .content.cloneNode(true);++    this.filterTSContainer = filterTSWrapper.querySelector(+      '.timestamp-filter-container'+    );++    this.startTimeLabel = filterTSWrapper.querySelector('#startTimeLabel');+    this.stopTimeLabel = filterTSWrapper.querySelector('#stopTimeLabel');+    this.clearTSFilterBtn = filterTSWrapper.querySelector('#clearBtn');++    shadow.appendChild(filterTSWrapper);+  }++  setFilterRange = (info, tab) => {+    if (tab.id !== this.tab.id) {+      return;+    }++    const selectedEl = browser.menus.getTargetElement(info.targetElementId);+    const selectedRow = selectedEl.closest('tr');++    if (!selectedRow) {+      return;+    }++    const chosenTimestamp = selectedRow.querySelector('.timestamp').textContent;+    if (info.menuItemId === 'startTime') {+      this.timeStamp.start = Date.parse(chosenTimestamp);+      this.startTimeLabel.textContent = chosenTimestamp;+    } else if (info.menuItemId === 'stopTime') {+      this.timeStamp.stop = Date.parse(chosenTimestamp);+      this.stopTimeLabel.textContent = chosenTimestamp;+    }++    this.filterTSContainer.hidden = false;+    this.disptachTSFilterEvent();+  };++  disptachTSFilterEvent() {+    const filterDetail = {+      updateFilter: {+        timeStamp: this.timeStamp,+      },+    };++    this.dispatchEvent(+      new CustomEvent('filterchange', { detail: filterDetail })+    );+  }++  onClearTSFilter = () => {+    this.startTimeLabel.textContent = 'From Beginning';+    this.stopTimeLabel.textContent = 'Up to End';+    this.filterTSContainer.hidden = true;++    this.timeStamp = {};+    this.disptachTSFilterEvent();+  };++  async connectedCallback() {+    browser.menus.onClicked.addListener(this.setFilterRange);+    browser.menus.onHidden.addListener(this.onHiddenListener);+    this.clearTSFilterBtn.addEventListener('click', this.onClearTSFilter);++    this.tab = await browser.tabs.getCurrent();

@Rob--W sigh... choosing to use the browser-.menu API for the timestamp filter context menu isn't going to work once we try to use the activitylog page inside a devtools panel...

atiqueahmedziad

comment created time in 3 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

+export class FilterTimestamp extends HTMLElement {+  constructor() {+    super();++    this.timeStamp = {};+    this.onHiddenListener = () => browser.menus.removeAll();++    const shadow = this.attachShadow({ mode: 'open' });++    const filterTSWrapper = document+      .querySelector('#filterTimestampTemplate')+      .content.cloneNode(true);++    this.filterTSContainer = filterTSWrapper.querySelector(+      '.timestamp-filter-container'+    );++    this.startTimeLabel = filterTSWrapper.querySelector('#startTimeLabel');+    this.stopTimeLabel = filterTSWrapper.querySelector('#stopTimeLabel');+    this.clearTSFilterBtn = filterTSWrapper.querySelector('#clearBtn');

the TSFilter part of this property name doesn't seem to be needed, it is inside a webcomponent that is called FilterTimestamp, and so that part of the name seems just redundant to me.

(and we could also lose the TS part of filterTSWrapper and filterTSContainer and some of the methods of this webcomponent).

atiqueahmedziad

comment created time in 3 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

 class Model {     return logDataStr.includes(this.filter.keyword);   } +  matchFilterTimestamp(logTimestamp) {+    const logTime = Date.parse(logTimestamp);

I think that I may be ok on deferring this optimization, but I wanted to mention it: the log's timestamp isn't going to change and so it would be a reasonable optimization trying to avoid to parse it every time we have to match a timestamp filter.

Another simple case where we can avoid to parse the date is if there isn't any timeStamp filter set at all. This optimization may be even simpler to apply, if we use a null timestamp filter as the default empty timestamp filter, we can just check if this.filter.timeStamp is defined before parsing the logTimestamp and just return true in that case (if there isn't a timeStamp filter set, all logs are going to match).

atiqueahmedziad

comment created time in 3 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

 class View {     this.apiTypeFilter = document.querySelector(       'filter-option[filter-key="type"]'     );+     this.keywordFilter = document.querySelector('filter-keyword');+    this.tsFilter = document.querySelector('filter-timestamp');

Nit, I think that I would call this this.timeFilter (or even this.timestampFilter given that it isn't much longer than this.keywordFilter), it is a bit longer but it would be immediately clear what it is about (ts may not immediatelly suggest that if in the context around the far there isn't anything else that makes it clear).

atiqueahmedziad

comment created time in 3 days

issue commentmozilla/webextension-polyfill

RuntimeMessage: message reply cannot be cloned

@davidb1 I filed the issue on bugzilla as Bug 1657384 - runtime messaging API does throw "Error: Conduits:RuntimeMessage: message reply cannot be cloned.".

Would you mind to add to that issue a link to the extension that does already trigger the issue and the steps to reproduce it consistently? (or even here on this issue, or send it to me by email, I'll take care of updating the issue with those additional details)

The additional details will help us to look for investigate the issue further and identify the exact patch that introduced the change in behavior.

Thanks in advance!

davidb1

comment created time in 4 days

push eventmozilla/web-ext

renovate[bot]

commit sha 3cf1b47a449f74f644db6b91671347ab8f7ce68a

chore(deps): update babel monorepo to v7.11.1 (#1988) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 4 days

delete branch mozilla/web-ext

delete branch : renovate/babel-monorepo

delete time in 4 days

PR merged mozilla/web-ext

chore(deps): update babel monorepo to v7.11.1

This PR contains the following updates:

Package Type Update Change
@babel/core (source) devDependencies patch 7.11.0 -> 7.11.1
@babel/runtime (source) dependencies patch 7.11.0 -> 7.11.1

Release Notes

<details> <summary>babel/babel</summary>

v7.11.1

Compare Source

:bug: Bug Fix
  • babel-parser
  • babel-core
  • babel-plugin-transform-block-scoping, babel-standalone
:memo: Documentation
:house: Internal

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about these updates again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+15 -15

1 comment

2 changed files

renovate[bot]

pr closed time in 4 days

push eventmozilla/web-ext

renovate[bot]

commit sha 4d7c0c94eaed7806329e8929ac93f69104a14669

chore(deps): update dependency mocha to v8.1.1 (#1987) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 4 days

delete branch mozilla/web-ext

delete branch : renovate/mocha-8.x

delete time in 4 days

PR merged mozilla/web-ext

chore(deps): update dependency mocha to v8.1.1

This PR contains the following updates:

Package Type Update Change
mocha (source) devDependencies patch 8.1.0 -> 8.1.1

Release Notes

<details> <summary>mochajs/mocha</summary>

v8.1.1

Compare Source

:bug: Fixes

  • #​4394: Fix regression wherein certain reporters did not correctly detect terminal width (@​boneskull)

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

1 comment

2 changed files

renovate[bot]

pr closed time in 4 days

issue closedmozilla/webextension-polyfill

RuntimeMessage: message reply cannot be cloned

After latest Firefox 79.0 update started getting this error from sendMessage

Code:

import browser from "webextension-polyfill";

export const background_script_api = new Proxy(
  {},
  {
    get(target, command) {
      return (data) => browser.runtime.sendMessage({ command, data })
    },
  }
);

Throws:

Error: Conduits:RuntimeMessage: message reply cannot be cloned.
 get background-communicator.js:7

closed time in 4 days

davidb1

issue commentmozilla/webextension-polyfill

RuntimeMessage: message reply cannot be cloned

@davidb1 The webextension-polyfill does not have anything to do with that error, when running on Firefox the polyfill turns itself into a no-op (see the related section of the README file in this repo), and so I'm going to close this issue as invalid for this repo.

The issue is very likely triggered by the extension itself by trying to reply to a message with an object that can't be send across the processes, and so it is expected to fail in that case, but the error message isn't supposed to expose the "Conduits::RuntimeMessage" part because it is an internal implementation detail, and so it may be worth reporting it on bugzilla (possibly by also attaching a minimal test extension that reproduce the issue and the steps to reproduce it consistently), a link to a partially pre-filled form to file the bug is available in the section of the readme linked above.

davidb1

comment created time in 4 days

Pull request review commentmozilla/extension-activity-monitor

load logs from json file

 class Model { class View {   constructor() {     this.logView = document.querySelector('log-view');+    this.menuContainer = document.querySelector('.menu-container');     this.clearLogBtn = document.querySelector('#clearLogBtn');     this.saveLogBtn = document.querySelector('#saveLogBtn');+    this.loadLogFile = document.querySelector('input[name="loadLogFile"]');+    this.clearLoadedLogBtn = document.querySelector('#clearLoadedLogs');

If I recall correctly, when we discussed about this during the last meeting we agreed that clearing the loaded logs may not make sense.

Nevertheless, given that we are storing those logs in the background page, at some point we should be removing them, otherwise we may keep all of the loaded files around until Firefox is being restarted.

As a user, I would expect to "close the loaded file" more than "clear the loaded logs", but from an implementation perspective they are basically the same thing, just named differently to match what is more likely the user expectation.

And so (I'm basically thinking about this aloud) I feel that, when the activitylog page is this kind of "view logs from file" mode, it may be reasonable to:

  • list the logs loaded from file (maybe in a select input element), and allow the user to switch between the loaded logs files
  • have a button to "close the loaded logs file", which would remove the entry for that loaded logs from the background page

@wagnerand what do you think about this? would the behavior described above match your expectation as a user (also @Rob--W for his opinion on this).

atiqueahmedziad

comment created time in 4 days

Pull request review commentmozilla/extension-activity-monitor

load logs from json file

 import { getActivityLogPageURL } from './ext-listen.js';  export default class ExtensionMonitor {+  /**+   * @type {Array.<{logs: Array<Object>, fileName: String}>}+   */+  loadedLogs = [];

@atiqueahmedziad ah, I see. Thanks for pointing it out!

Wouldn't be reasonable to store the logs in a map keyed by the filename string?

atiqueahmedziad

comment created time in 5 days

issue commentmozilla/extension-activity-monitor

ActivityLog DevTools panel

As we discussed in the weekly meeting:

The activitylog page itself would not be using the devtools API directly, it will just look to the search params and if there is a search param like filterTabId=... then it would use that to filter the tab Id (and also make it visible in the page that the logs are being automatically filtered by tabId.

To learn more about the devtools API and how to integrate an extension page into the developer tools you may take a look to the following doc page on MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Extending_the_developer_tools

Some other details that may be useful to you:

  • the extension manifest should include a devtools_page manifest property and it should be set to an html file packaged in the extension
  • the devtools page is invisible (similarly to a background page), and it is created automatically when a developer toolbox is opened on a Firefox tab (there will be 1 devtools page instance per developer toolbox, and no more than 1 developer toolbox per tab)
  • the devtools page is one of the extension pages that can use the devtools API, and our devtools page should use it to:
    • retrieve the tabId for the tab where the developer toolbox has been opened using browser.devtools.inspectedWindow.tabId (that tabId doesn't change, it will stay the same even if the page is navigated, every devtools_page instance is related to a different developer toolbox, each developer toolbox is related to a different tab and so the tabId will be different only in those cases)
    • the devtools page will use that tabId to compute the search params to add to the url of the activitylog page registered by the extension a devtools panel for the current developer toolbox
    • then it will use the computed activitylog page url to register the devtools panel on the current developer toolbox using the browser.devtools.panels.create API method

Once the panel is registered, a new tool will be available to the user, the actual activitylog page will be loaded lazily when the user selects the panel.

Let me know if you need any additional detail or if any of the detail above are not clear enough.

rpl

comment created time in 6 days

Pull request review commentmozilla/extension-activity-monitor

load logs from json file

 class Controller {   }    async init() {-    this.view.clearLogBtn.addEventListener('clearlog', this);-    this.view.saveLogBtn.addEventListener('savelog', this);     this.view.keywordFilter.addEventListener('filterchange', this);     this.view.extFilter.addEventListener('filterchange', this);     this.view.viewTypeFilter.addEventListener('filterchange', this);     this.view.apiTypeFilter.addEventListener('filterchange', this);+    const searchParams = window.location.search; -    browser.runtime.onMessage.addListener((message) => {-      const { requestTo, requestType } = message;+    if (searchParams.includes('page=loadLog&file=')) {+      this.view.menuContainer.hidden = true; -      if (requestTo !== 'activity-log') {+      const fileName = searchParams.substring(+        searchParams.indexOf('file=') + 5+      );+      if (!fileName) {         return;       }

We could use URLSearchParams to more easily parse the URL search params, see https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/get.

Also, it may be better to make the condition we check in the if at line 163 to do not depend from the order of the search params (I mean that we may not need the page=loadLog search param and the the searchParams.includes(...) condition could be replaced by checking that we do have a file search param).

atiqueahmedziad

comment created time in 6 days

Pull request review commentmozilla/extension-activity-monitor

load logs from json file

 import { getActivityLogPageURL } from './ext-listen.js';  export default class ExtensionMonitor {+  /**+   * @type {Array.<{logs: Array<Object>, fileName: String}>}+   */+  loadedLogs = [];

Similar to my other comment, if the activitylog.html page opened for a loaded log file is only being used to review those logs, we may not need both loadedLogs and logs (eg. that instance of the activitylog.html page is not meant to subscribe to receive realtime logs at all).

atiqueahmedziad

comment created time in 6 days

Pull request review commentmozilla/extension-activity-monitor

load logs from json file

 class Model { class View {   constructor() {     this.logView = document.querySelector('log-view');+    this.menuContainer = document.querySelector('.menu-container');     this.clearLogBtn = document.querySelector('#clearLogBtn');     this.saveLogBtn = document.querySelector('#saveLogBtn');+    this.loadLogFile = document.querySelector('input[name="loadLogFile"]');+    this.clearLoadedLogBtn = document.querySelector('#clearLoadedLogs');

If the activitylog.html page for a loaded log file is only being used to review the logs in the loaded file, we may not need to different clear logs buttons, I have the feeling that it may just be confusing and the user may clear the logs being collected by mistake if it clicks the wrong button.

atiqueahmedziad

comment created time in 6 days

push eventmozilla/web-ext

renovate[bot]

commit sha 793c7ae74b04910becd61f89c7293e5782a633a3

chore(deps): update dependency eslint to v7.6.0 (#1985) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 6 days

delete branch mozilla/web-ext

delete branch : renovate/eslint-7.x

delete time in 6 days

PR merged mozilla/web-ext

chore(deps): update dependency eslint to v7.6.0

This PR contains the following updates:

Package Type Update Change
eslint (source) devDependencies minor 7.5.0 -> 7.6.0

Release Notes

<details> <summary>eslint/eslint</summary>

v7.6.0

Compare Source

  • ecb2b73 Update: require meta for fixable rules in RuleTester (refs #​13349) (#​13489) (Milos Djermanovic)
  • 6fb4edd Docs: fix broken links in developer guide (#​13518) (Sam Chen)
  • 318fe10 Fix: Do not output undefined as line and column when it's unavailable (#​13519) (haya14busa)
  • 493b5b4 Sponsors: Sync README with website (ESLint Jenkins)
  • f100143 Sponsors: Sync README with website (ESLint Jenkins)
  • 16b10fe Fix: Update the chatroom link to go directly to help channel (#​13536) (Nicholas C. Zakas)
  • f937eb9 Sponsors: Sync README with website (ESLint Jenkins)
  • e71e298 Update: Change no-duplicate-case to comparing tokens (fixes #​13485) (#​13494) (Yosuke Ota)
  • 6c4aea4 Docs: add ECMAScript 2020 to README (#​13510) (Milos Djermanovic)

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+90 -52

1 comment

2 changed files

renovate[bot]

pr closed time in 6 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

 class Model {     return logDataStr.includes(this.filter.keyword);   } +  matchFilterTimestamp(logTimestamp) {+    return (+      Date.parse(logTimestamp) >=+        Date.parse(this.filter.timeStamp.startTime || this.logs[0].timeStamp) &&+      Date.parse(logTimestamp) <=+        Date.parse(this.filter.timeStamp.stopTime || new Date())

We shouldn't need to create a fake range (e.g. by considering the stopTime the current time), if there is no startTime filter, we should just check the stopTime, and if there is no stopTime we should just be checking the startTime,

The logic above may be expressed in multiple ways, one option could be to early return false as soon as we verified that the log timestamp is not in the range by doing something like:

// Assume that this.filter.timeStamp.startTime/stopTime has been converted into number
// with Date.parse when they have been set.
const logTime = Date.parse(logTimestamp);

if (this.filter.timeStamp?.startTime != null  && logTime < this.filter.timeStamp.startTime) {
  return false;
}

if (this.filter.timeSTamp?.stopTime != null && logTime > this.filter.timeSTamp?.stopTime) {
  return false;
}

// The log timestamp is in range or there was no timestamp filter.
return true;
atiqueahmedziad

comment created time in 6 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

 <h2>Activity Logs</h2>     <template id="logTableTemplate">       <link rel="stylesheet" href="/lib/web-component/log-view/log-view.css" />       <div class="activity-log-container">+        <div class="timestamp-filter-container" hidden>+          <div class="label">+            Timestamp Filter Applied+            <div id="clearBtn" title="Clear timestamp filter"></div>+          </div>+          <div class="timestamp-filter-options">+            <div class="start-time-container">+              <div class="title">Start Time:</div>+              <div id="startTimeLabel">From beginning</div>+            </div>+            <div class="stop-time-container">+              <div class="title">Stop Time:</div>+              <div id="stopTimeLabel">Up to End</div>+            </div>+          </div>+        </div>

It feels like this should be with the other filter options:

  • defined to be outside of the log view table, part of the filter wrapper defined between lines 30-41
  • defined as its own webcomponent, in this version of the patch it seems that the webcomponent that manage the table view is also managing this part of the DOM and it does feel a bit outside of the responsabilities of the LogView webcomponent
atiqueahmedziad

comment created time in 6 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

 export class LogView extends HTMLElement {   constructor() {     super();++    this.timeStamp = {+      startTime: null,+      stopTime: null,+    };+     this.isFilterMatched = () => true;+    this.menuOnCickListener = (info, tab) => this.setFilterRange(info, tab);

typo in the property name.

atiqueahmedziad

comment created time in 6 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

 export class LogView extends HTMLElement {   constructor() {     super();++    this.timeStamp = {+      startTime: null,+      stopTime: null,+    };

why do we need a timestamp object defined on the LogView elements?

atiqueahmedziad

comment created time in 6 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

 export class LogView extends HTMLElement {     this.tableBody.appendChild(rowsFragment);   } +  handleEvent(event) {+    if (event.type === 'click') {+      const logDetails = event.target.closest('tr')?._log;++      if (logDetails) {+        this.openDetailSidebar(logDetails);+        return;+      }++      switch (event.target) {+        case this.closeBtn:+          this.closeDetailSidebar();+          break;+        case this.clearTSFilterBtn:+          this.hideTSFilter();+          break;+        default:+          throw new Error(`wrong event target found: ${event.target.tagName}`);+      }+    } else if (event.type === 'contextmenu') {+      browser.menus.overrideContext({});+      this.createContextMenu();+      browser.menus.refresh();+    }+  }+   openDetailSidebar(logDetails) {     const logString = JSON.stringify(logDetails);     this.logDetails.textContent = logString;     this.logTableWrapper.classList.add('width-60');+    this.timeStampFilterContainer.classList.add('width-60');     this.logDetailWrapper.hidden = false;   }    closeDetailSidebar() {     this.logDetailWrapper.hidden = true;     this.logTableWrapper.classList.remove('width-60');+    this.timeStampFilterContainer.classList.remove('width-60');   } -  handleEvent(event) {-    if (event.type === 'click') {-      const logDetails = event.target.closest('tr')?._log;+  hideTSFilter() {+    this.timeStamp.startTime = null;+    this.timeStamp.stopTime = null;+    this.disptachTSFilterEvent(); -      if (logDetails) {-        this.openDetailSidebar(logDetails);-        return;-      }+    this.startTimeLabel.textContent = 'From Beginning';+    this.stopTimeLabel.textContent = 'Up to End';+    this.timeStampFilterContainer.hidden = true;+  } -      if (event.target === this.closeBtn) {-        this.closeDetailSidebar();-      }-    }+  createContextMenu() {+    browser.menus.create({+      id: 'startTime',+      title: 'Start from this timestamp',+      contexts: ['page'],+      viewTypes: ['tab'],+      documentUrlPatterns: [+        `moz-extension://${location.host}/activitylog/activitylog.html`,+      ],+    });++    browser.menus.create({+      id: 'stopTime',+      title: 'Stop at this timestamp',+      contexts: ['page'],+      viewTypes: ['tab'],+      documentUrlPatterns: [+        `moz-extension://${location.host}/activitylog/activitylog.html`,+      ],+    });   }    clearTable() {     this.tableBody.textContent = '';   } -  connectedCallback() {+  async connectedCallback() {+    browser.menus.onClicked.addListener(this.menuOnCickListener);     this.tableBody.addEventListener('click', this);+    this.tableBody.addEventListener('contextmenu', this);     this.closeBtn.addEventListener('click', this);+    this.clearTSFilterBtn.addEventListener('click', this);++    browser.menus.onHidden.addListener(() => {+      browser.menus.removeAll();+    });

when is the browser.menus.onHidden removed? it would also be removed automatically when the extension page is closed, but given that in the disconnectedCallback we are also removing other API event explicitly it may be good to remove this one too.

atiqueahmedziad

comment created time in 6 days

Pull request review commentmozilla/extension-activity-monitor

feat: filter option with timestamp in context menu

 class Model {    * @param {Set<string>} [updateFilter.type] - It contains api types that    * includes api_call, api_event, content_script, user_script.    * @param {string} [updateFilter.keyword]+   * @param {object} [updateFilter.timeStamp] - It contains two string+   * properties i.e. startTime & stopTime.+   * @param {Date|null} [updateFilter.timeStamp.startTime] - It is Date+   * when filter it set and null when filter is cleared.+   * @param {Date|null} [updateFilter.timeStamp.stopTime] - It is Date when+   * filter it set and null when filter is cleared.

the jsdoc here seems to be wrong: updateFilter.timestamp currently says that it contains two strings, then right after that the jsdoc for the startTime and stopTime says that they are Date or null.

Given that we are converting the date string into a timestamp number to match the filter in
matchFilterTimestamp it may be reasonable to do that conversion once when we do set the filter in the model.

If we do that, startTime and stopTime would be both of type number.

Nit:

  • no need to spell the time of the timestamp property in the description, we could omit its description (and just let the jsdoc for those two properties to describe their type and their meaning)

  • startTime and stopTime may also be called start and stop or from and to, the fact that they are timestamps is already clear by being properties of the timestamp object

atiqueahmedziad

comment created time in 6 days

issue commentmozilla/web-ext

Unable to open the Extensions page with --start-url when running in Chrome

Chrome extensions can open many chrome:-pages.

that's true, and I just verified that chrome://extensions is one of those that can be opened successfully using chrome.tabs.create, and so one option to fix this in web-ext would be to special case the chrome://extension url (or any chrome url) in the chrome extension runner and make the companion extension that we install automatically to auto-reload the target extension able to call chrome.tabs.create for us.

ghostwords

comment created time in 9 days

issue commentmozilla/web-ext

Signing fails with "Signing took too long to complete" but also succeeds

Interesting... Ok. We'll try that for the next few days and see how that goes. Thanks.

Thanks! I'll keep this issue open in the meantime. Let me know how it goes so that we can then decide if we should do more triaging for this issue or just close it.

EvHaus

comment created time in 9 days

issue commentmozilla/web-ext

Unable to open the Extensions page with --start-url when running in Chrome

It seems that Chrome does ignore chrome://extensions (also other chrome:// urls, like chrome://version) passed on the command line, e.g. executing on the command line

google-chrome http://developer.mozilla.org

does start Chrome with the given url loaded in the first tab

On the contrary:

google-chrome chrome://version

does start Chrome but it doesn't load that chrome url in the first tab.

I have the feeling that this may be an intended behavior, I briefly looked if Chrome does provide a command line flag to override this behavior, but at the moment I haven't spotted any that may be related.

We may have to close this as a wontfix if we don't have a way to tell Chrome to allow chrome:// urls as start urls, but for now I'm keeping this open to take another look and think a bit if there may be other options to achieve that.

ghostwords

comment created time in 9 days

issue commentmozilla/web-ext

Signing fails with "Signing took too long to complete" but also succeeds

@EvHaus the default timeout for the sign command is bit higher then the value passed in the snipped above (the default is 900000, 15 minutes, see sign-addon sources here or the backport of the longer timeout in web-ext v3.2.1).

Have you already tried to leave it to the default value or to pass an higher timeout value?

EvHaus

comment created time in 9 days

push eventmozilla/web-ext

renovate[bot]

commit sha bd2974b47c2ed80dd5f6d7b3afb755aed6660c61

chore(deps): update babel monorepo to v7.11.0 (#1983) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 9 days

delete branch mozilla/web-ext

delete branch : renovate/babel-monorepo

delete time in 9 days

PR merged mozilla/web-ext

chore(deps): update babel monorepo to v7.11.0

This PR contains the following updates:

Package Type Update Change
@babel/core (source) devDependencies minor 7.10.5 -> 7.11.0
@babel/plugin-transform-runtime devDependencies minor 7.10.5 -> 7.11.0
@babel/preset-env (source) devDependencies minor 7.10.4 -> 7.11.0
@babel/runtime (source) dependencies minor 7.10.5 -> 7.11.0

Release Notes

<details> <summary>babel/babel</summary>

v7.11.0

Compare Source

:eyeglasses: Spec Compliance
:rocket: New Feature
:bug: Bug Fix
  • Other
  • babel-helper-skip-transparent-expression-wrappers, babel-plugin-proposal-optional-chaining, babel-plugin-transform-spread
  • babel-helper-member-expression-to-functions, babel-plugin-proposal-class-properties, babel-plugin-proposal-logical-assignment-operators
  • babel-plugin-transform-typescript
  • babel-plugin-transform-runtime
  • babel-parser
    • #​11862 Correctly check reserved word for PropertyDefinition: IdentifierReference (@​JLHwung)
    • #​11847 fix: correctly set innerEndPos in CoverParenthesizedExpressionAndArrowParameterList (@​JLHwung)
  • babel-generator, babel-parser, babel-plugin-transform-typescript
  • babel-generator
:nail_care: Polish
:house: Internal
  • Other
  • babel-standalone
  • babel-compat-data, babel-helper-compilation-targets, babel-preset-env
  • babel-compat-data, babel-core, babel-helper-module-transforms, babel-helper-split-export-declaration, babel-parser, babel-plugin-proposal-object-rest-spread, babel-plugin-transform-classes, babel-preset-env, babel-traverse, babel-types
  • babel-types
  • babel-compat-data

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about these updates again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+363 -284

1 comment

2 changed files

renovate[bot]

pr closed time in 9 days

push eventmozilla/web-ext

renovate[bot]

commit sha 159cc1c43aa6f87a6c7b6245ae384e4e29b90ce1

chore(deps): update dependency mocha to v8.1.0 (#1982) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 9 days

delete branch mozilla/web-ext

delete branch : renovate/mocha-8.x

delete time in 9 days

PR merged mozilla/web-ext

chore(deps): update dependency mocha to v8.1.0

This PR contains the following updates:

Package Type Update Change
mocha (source) devDependencies minor 8.0.1 -> 8.1.0

Release Notes

<details> <summary>mochajs/mocha</summary>

v8.1.0

Compare Source

In this release, Mocha now builds its browser bundle with Rollup and Babel, which will provide the project's codebase more flexibility and consistency.

While we've been diligent about backwards compatibility, it's possible consumers of the browser bundle will encounter differences (other than an increase in the bundle size). If you do encounter an issue with the build, please report it here.

This release does not drop support for IE11.

Other community contributions came from @​Devjeel, @​Harsha509 and @​sharath2106. Thank you to everyone who contributed to this release!

Do you read Korean? See this guide to running parallel tests in Mocha, translated by our maintainer, @​outsideris.

:tada: Enhancements

:bug: Fixes

:lock: Security Fixes

:book: Documentation & Website

:nut_and_bolt: Other

  • #​4293: Use Rollup and Babel in build pipeline; add source map to published files (@​Munter)

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+40 -83

1 comment

2 changed files

renovate[bot]

pr closed time in 9 days

delete branch mozilla/web-ext

delete branch : renovate/webpack-4.x

delete time in 9 days

push eventmozilla/web-ext

renovate[bot]

commit sha 4116eb60e38e1c905ee90251d522c884dd21ef56

chore(deps): update dependency webpack to v4.44.1 (#1980) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 9 days

PR merged mozilla/web-ext

chore(deps): update dependency webpack to v4.44.1

This PR contains the following updates:

Package Type Update Change
webpack devDependencies patch 4.44.0 -> 4.44.1

Release Notes

<details> <summary>webpack/webpack</summary>

v4.44.1

Compare Source

Bugfixes

  • fix bug in sideEffects optimization when using export * from "non-esm" and a default export.
  • add missing optional peerDependencies for webpack-cli and webpack-command to support Yarn 2

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

1 comment

2 changed files

renovate[bot]

pr closed time in 9 days

push eventmozilla/web-ext

Renovate Bot

commit sha 5cf782b4e152efd6c7a0ee54018e25a2b0822995

fix(deps): update dependency sign-addon to v3

view details

Luca Greco

commit sha 8cc266953c1ec2c988cd780c1e33d6cb401e3fb7

chore: Updated cmd/sign to use named export from sign-addon v3

view details

Luca Greco

commit sha 94eab872fc378e65ad96dfcec60b226ebebdfdc8

chore(audit): Temporarily add dot-prop adv url to nsprc

view details

push time in 9 days

delete branch mozilla/web-ext

delete branch : renovate/sign-addon-3.x

delete time in 9 days

PR merged mozilla/web-ext

fix(deps): update dependency sign-addon to v3

This PR contains the following updates:

Package Type Update Change
sign-addon dependencies major 2.0.6 -> 3.0.0

Release Notes

<details> <summary>mozilla/sign-addon</summary>

v3.0.0

Compare Source

  • Breaking Change: expose a consistent API for both ESM and CJS (#​555)
  • Some dependencies have been updated (lockfile maintenance)

See: https://github.com/mozilla/sign-addon/compare/2.0.6...3.0.0

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+9 -6

1 comment

4 changed files

renovate[bot]

pr closed time in 9 days

push eventmozilla/web-ext

Luca Greco

commit sha a1342245adbffdeeb9edef01c0bd9645168a1e72

chore(audit): Temporarily add dot-prop adv url to nsprc

view details

push time in 9 days

push eventmozilla/web-ext

Luca Greco

commit sha d35c57bba6a3f9816dd7f9f44824e269e7811018

chore: Updated cmd/sign to use named export from sign-addon v3

view details

push time in 9 days

Pull request review commentmozilla/sign-addon

Update travis-ci config

 deploy:     secure: OEtTl1c/grWh7YsgOJBQrkV/b3t5a13IvbNkjOf3S2HP7JDh9zhqzDZFATgHVpsX1Z6/33eh+gvJ5n4T9VF6OGdYEP40QdEnO7+uWYLEUCWQ7u2lWNRpix4opgRos/M8CJ8vPFbermb2/SnFS9B/ree7xru50pg4w51+T5lyxZnQWuXXU5S44Ywvg+p4KZq8YzkNU5VSmneQK3CTKniaVnAMlcf8p4UmCilDn5LYbjg4x5yOf4OTaup7oU2IAypgsDfYYCcOSpCuuBdGZMvC8IRDUFpQ1RCMKfOCdpX+M2ejxvVbIGVlg+OcL0+xaQtxjBAAEmbquB7+AVsnQ9I6VaENtmzMQJthWawiEqSQJISCoVwhJ87YvGol6Qdo9/7KyTn82mB2AzbxcxI6XZcjACe0qj2IGvWNPtkZ/aIwL4oc2JaeucFZOBwqs6eWiSHNQ/4pqVwzsDz4EXLtR+j+twS6ulywIIgr1u5D5Zryi5r/qCJXgH+bq3yZ65GmRd+Oz1G5xztYe/nX8z4yWkUnVDE23GlDvptytaSjGmO8yx1Bqc6ehuWgC/kx8rX+1JSfNFycDphFmuyxzAV8b/XWWbAH7i1cz60Se42cOwFtJ0zi4G87/+/GeksrRaK2T8v8eBuLWJ1eXUY6HKoXWBMVpitZfmnoV++vFSbhA+MHXNA=   on:     tags: true+    node_js: 10

Nit, it may be reasonable to set it to the last version listed in the matrix (but also fine to leave it as it is).

willdurand

comment created time in 11 days

Pull request review commentmozilla/sign-addon

Update travis-ci config

 language: node_js-sudo: false+ node_js:-- 10-- 12+  # When updating the value below, make sure to update the `node_js` version in+  # the `deploy` section at the bottom of this file too.+  - 10+  - 12  before_install:-# Create a master branch for conventional-changelog-lint-- git remote set-branches origin master && git fetch-- git checkout master-# Check out the commit that TravisCI started on:-- git checkout --- npm install -g npm;+  # Create a master branch for conventional-changelog-lint+  - git remote set-branches origin master && git fetch+  - git checkout master+  # Check out the commit that TravisCI started on:+  - git checkout -+  - npm install -g npm;+ script:-- npm run build-- npm run test-ci-- npm run lint-- npm run prettier-ci-- npm run typecheck-# Run changelog-lint but only on newer versions of Node (because of syntax errors)-- if [[ ${TRAVIS_NODE_VERSION:0:1} -ge "8" ]]; then-    npm run changelog-lint;-  fi-notifications:-  irc:-    channels:-    - irc.mozilla.org#amo-bots-    on_success: change-    on_failure: always+  - npm run build+  - npm run test-ci+  - npm run lint+  - npm run prettier-ci+  - npm run typecheck+  # Run changelog-lint but only on newer versions of Node (because of syntax+  # errors)+  - if [[ ${TRAVIS_NODE_VERSION:0:1} -ge "8" ]]; then+      npm run changelog-lint;+    fi

Nit, I think that we can also remove the if..;then... fi part here (given that we are now only running this on nodejs >> 8) and turn it into just npm run changelog-lint.

willdurand

comment created time in 11 days

issue commentmozilla/addons-linter

Unknown optional_permissions are being classified as errors by the addons-linter and as warnings by Firefox

@caitmuenster I'm going to mentor this issue as we agreed.

@bhushan-borole Follows some additional details to help a contributor to have a better understanding of the issue and what parts of the addons-linter are more likely going to need some changes (there would be very likely other parts that may require changes, but this should be enough to get the work started, and don't spoil everything up front :-P, more details will be provided as needed based on questions and code reviews).

Understanding the issue

To better understand the issue it may be good to try to run the addons-linter (as it is, without any changes) on a small test extension that would trigger the issue. A minimal example of an extension manifest that would trigger this issue would look like:

{
  "manifest_version": 2,
  "name": "addons-linter-issue-3060",
  "version": "0.1",
  "permissions": ["unknown_permissions"],
  "optional_permissions": ["unknown_optional_permission"]
}

The manifest is pretty bare, and contains an unknown permission (a permission that doesn't exist based on the list of permissions supported by Firefox) in both the "permissions" and "optional_permissions" manifest properties (to know more about these and other manifest.json properties you can take a look to this doc page on MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json).

The manifest contains both "permissions" and "optional_permissions" to make it easier to compare how the addons-linter is handling the two properties.

Let's put this manifest in a file named manifest.json in a directory (e.g. one named addons-linter-issue-3060) and then we can check what is the result of running addons-linter ./addons-linter-issue-3060, without any changes applied to the addons-linter here is the result that we currently get:

errors          5
notices         0
warnings        1

ERRORS:

Code           Message                                    Description                           File   Line   Column
JSON_INVALID   "/optional_permissions/0" should be        Your JSON file could not be parsed.
               equal to one of the allowed values
JSON_INVALID   "/optional_permissions/0" is not a valid   Your JSON file could not be parsed.
               key or has invalid extra properties
JSON_INVALID   "/optional_permissions/0" should match     Your JSON file could not be parsed.
               pattern
               "^(https?|wss?|file|ftp|\*)://(\*|\*\.[…
               ^*/]+|[^*/]+)/.*$"
JSON_INVALID   "/optional_permissions/0" should match     Your JSON file could not be parsed.
               pattern "^file:///.*$"
JSON_INVALID   "/optional_permissions/0" should match     Your JSON file could not be parsed.
               pattern
               "^resource://(\*|\*\.[^*/]+|[^*/]+)/.*$…
               |^about:"
WARNINGS:

Code                   Message                             Description                                                   File            Line   Column
MANIFEST_PERMISSIONS   /permissions: Unknown permissions   See https://mzl.la/1R1n1t0 (MDN Docs) for more information.   manifest.json
                       "unknown_permissions" at 0.

This shows that (quite surprisingly for an addon developer):

  • the unknown permission string used in the "permissions" manifest property is triggering a warning (and instead of an error) and has a nicer description (something that should be pointing the addon developer directly to what has to be done to fix it if it was a mistake, e.g. it is possible that the permission is unknown for Firefox but supported by Chrome), and it isn't going to block the addon submission to addons.mozilla.org because it is just a warning).

  • the unknown permission string used in the "optional_permission" manifest property has instead triggered 5 errors (which means that the addon cannot be submitted successfully on addons.mozilla.org until the validation error is fixed) and the errors description are not really that nice.

What we would like to get as a result instead (after this issue is fixed) would look more or less like the following:

Validation Summary:

errors          0
notices         0
warnings        2

WARNINGS:

Code                   Message                               Description                                                   File            Line   Column
MANIFEST_PERMISSIONS   /permissions: Unknown permissions     See https://mzl.la/1R1n1t0 (MDN Docs) for more information.   manifest.json
                       "unknown_permissions" at 0.
MANIFEST_OPTIONAL_PERMISSIONS   /optional_permissions: Unknown        See https://mzl.la/otherurl (MDN Docs) for more information.   manifest.json
                       optional_permissions
                       "unknown_optional_permission" at 0.

Basically we should align the addons-linter behavior on the validation results for the "permissions" and "optional_permissions" manifest properties, and as a result trigger similar warnings (with just a slightly different code and a https://mzl.la shortened urls that points to the optional_permissions docs on MDN).

Parts of the addons-linter to look into to fix this issue

The manifest.json file is parsed and validated by the module named src/parsers/manifestjson.js, inside that module there are parts that are special casing the errors triggered by the "permissions" manifest property (e.g. here and here).

From a test coverage perspective, there are some existing tests for the behavior expected on invalid values in the "permissions" manifest property (in particular the ones grouped in the "bad permissions" describe here) that should be likely repeated for both "permissions" and "optional_permissions" (to verify that the validation for these two manifest properties is aligned as expected).

rpl

comment created time in 11 days

issue commentmozilla/web-ext

Add --no-default-ignore-files option

@bmwalters have you tried with the -i cli option and negated pattern? e.g. something like web-ext lint -i !build/node_modules/packagename/dir/**

kumar303

comment created time in 11 days

issue commentmozilla/web-ext

After updating to 5.0.0 all JS files return `JS_SYNTAX_ERROR` on `npx web-ext lint`

Hi @birtles I took a look into this by reproducing it using your add-on repo (birtles/rikaichamp + the changes in birtles/rikaichamp#332) and it turned out that the issue is triggered because of the web-ext-webpack-plugin dev dependency:

  • web-ext-webpack-plugin directly depends from an older web-ext version
  • the older web-ext version depends from an older version of the addons-linter version and this makes two different addons-linter versions to be listed in the yarn.lock file, 1.0.0 and 2.1.0 after birtles/rikaichamp#332, 1.0.0 and 1.26.0 in the current master:
    • https://github.com/birtles/rikaichamp/blob/ab51ad719e51c2734daab74619110d71b9455702/yarn.lock#L1517
    • https://github.com/birtles/rikaichamp/blob/ab51ad719e51c2734daab74619110d71b9455702/yarn.lock#L1560 (and this then brings into node_modules an older eslint version and the related older espree version)

This is now my favorite "node packages dependencies hell" issue of the month :-)

I quickly tried to just (temporarily) remove web-ext-webpack-plugin from the rikaichamp devDependencies and refresh the node_modules dir using yarn install and at that point web-ext lint does pass successfully as it should, and so it should be enough to update the web-ext dependency in the web-ext-webpack-plugin package to fix the issue in your repo.

Based on the above analysis, this issue may be invalid from a web-ext standpoint, but I'll keep this open for now, so that you can give a try and confirm that what I described above is right and you have been able to fix the issue as expected, and also in case this may be a more common scenario than we may expect and other users may run into it.

birtles

comment created time in 11 days

Pull request review commentmozilla/sign-addon

Expose a consistent API for both ESM and CJS

     "build": "rimraf dist/ && webpack",     "changelog": "conventional-changelog -p angular -u",     "changelog-lint": "commitlint --from master",-    "eslint": "eslint .",+    "eslint": "eslint . --ext mjs --ext js",     "lint": "npm run eslint",     "prettier": "prettier --write '**'",-    "prettier-ci": "prettier --list-different '**' || (echo '\n\nThis failure means you did not run `yarn prettier-dev` before committing\n\n' && exit 1)",+    "prettier-ci": "prettier --list-different '**' || (echo '\n\nThis failure means you did not run `npm run prettier-dev` before committing\n\n' && exit 1)",     "prettier-dev": "pretty-quick --branch master",     "test": "jest",-    "test-ci": "yarn test --coverage && codecov",+    "test-ci": "npm run test --coverage && codecov",     "typecheck": "tsc"   },   "dependencies": {+    "@types/shelljs": "0.8.8",+    "@types/tmp": "0.2.0",

I think that we can move also these two to the dev dependencies.

willdurand

comment created time in 11 days

Pull request review commentmozilla/sign-addon

Expose a consistent API for both ESM and CJS

+import path from 'path';+import { execSync } from 'child_process';++import shell from 'shelljs';+import tmp from 'tmp';++describe(__filename, () => {+  const node = shell.which('node');+  const npm = shell.which('npm');+  const fixturesDir = path.join(__dirname, '..', 'fixtures');+  const fixtureEsmImport = path.join(fixturesDir, 'import-as-esm');+  const fixtureCjsRequire = path.join(fixturesDir, 'require-as-cjs');++  const makeTempDir = () =>+    new Promise((resolve, reject) => {+      tmp.dir(+        {+          prefix: 'tmp-sign-addon-',+          // This allows us to remove a non-empty tmp dir.+          unsafeCleanup: true,+        },+        (err, aPath, aCleanupCallback) => {+          if (err) {+            reject(err);+            return;+          }++          resolve([aPath, aCleanupCallback]);+        },+      );+    });++  describe('imported as a library', () => {+    beforeAll(() => {+      execSync(`${npm} link`, {+        cwd: path.resolve(path.join(__dirname, '..', '..')),+      });+    });++    afterAll(() => {+      execSync(`${npm} unlink`, {+        cwd: path.resolve(path.join(__dirname, '..', '..')),+      });+    });++    it('can be imported as an ESM module', async () => {+      const [cwd, cleanupCallback] = await makeTempDir();++      execSync(`${npm} link sign-addon`, { cwd });+      shell.cp('-rf', `${fixtureEsmImport}/*`, cwd);+      execSync(`${node} --experimental-modules test-import.mjs`, { cwd });++      cleanupCallback();+    });++    it('can be imported as a CommonJS module', async () => {+      const [cwd, cleanupCallback] = await makeTempDir();++      execSync(`${npm} link sign-addon`, { cwd });+      shell.cp('-rf', `${fixtureCjsRequire}/*`, cwd);+      execSync(`${node} --experimental-modules test-require.js`, { cwd });

Nit, on this test --experimental-modules may not be actually needed (my mistake actually, I should remove it from the similar test that I added in the web-ext repo).

willdurand

comment created time in 12 days

Pull request review commentmozilla/sign-addon

Expose a consistent API for both ESM and CJS

+import path from 'path';+import { execSync } from 'child_process';++import shell from 'shelljs';+import tmp from 'tmp';++describe(__filename, () => {+  const node = shell.which('node');+  const npm = shell.which('npm');+  const fixturesDir = path.join(__dirname, '..', 'fixtures');+  const fixtureEsmImport = path.join(fixturesDir, 'import-as-esm');+  const fixtureCjsRequire = path.join(fixturesDir, 'require-as-cjs');++  const makeTempDir = () =>+    new Promise((resolve, reject) => {+      tmp.dir(+        {+          prefix: 'tmp-sign-addon-',+          // This allows us to remove a non-empty tmp dir.+          unsafeCleanup: true,+        },+        (err, aPath, aCleanupCallback) => {+          if (err) {+            reject(err);+            return;+          }++          resolve([aPath, aCleanupCallback]);+        },+      );+    });++  describe('imported as a library', () => {+    beforeAll(() => {+      execSync(`${npm} link`, {+        cwd: path.resolve(path.join(__dirname, '..', '..')),+      });+    });++    afterAll(() => {+      execSync(`${npm} unlink`, {+        cwd: path.resolve(path.join(__dirname, '..', '..')),+      });+    });++    it('can be imported as an ESM module', async () => {+      const [cwd, cleanupCallback] = await makeTempDir();++      execSync(`${npm} link sign-addon`, { cwd });+      shell.cp('-rf', `${fixtureEsmImport}/*`, cwd);+      execSync(`${node} --experimental-modules test-import.mjs`, { cwd });++      cleanupCallback();

I think that we may also want to call tmp.setGracefulCleanup(); (e.g. right before the describe at line 7) to make sure we cleanup the temporary files when the node process exit in case one of these test did fail and never reached the cleanupCallback call.

willdurand

comment created time in 12 days

Pull request review commentmozilla/sign-addon

Expose a consistent API for both ESM and CJS

+const assert = require('assert');++// @ts-ignore+const signAddon = require('sign-addon'); // eslint-disable-line import/no-unresolved

@willdurand out of the curiosity, I was wondering: why the commonjs test needs the @ts-ignore annotation and the esm one doesn't?

willdurand

comment created time in 12 days

Pull request review commentmozilla/sign-addon

Expose a consistent API for both ESM and CJS

     "jsonwebtoken": "8.5.1",     "mz": "2.7.0",     "request": "2.88.2",+    "shelljs": "0.8.4",

I think I missed to notice this in the previous round, shouldn't shelljs and tmp just be dev dependencies? they are only being used in the new functional test.

willdurand

comment created time in 12 days

Pull request review commentmozilla/extension-activity-monitor

feat: pre tag is added in log detail view of sidebar

 class LogView extends HTMLElement {   }    openDetailSidebar(logDetails) {-    const logString = JSON.stringify(logDetails);+    const logString = JSON.stringify(logDetails, null, 4);

Nit, 2 (instead of 4) may be enough for the indentation, and it would spare a bit of horizontal space.

atiqueahmedziad

comment created time in 12 days

Pull request review commentmozilla/extension-activity-monitor

feat: pre tag is added in log detail view of sidebar

 }  .log-details {-  margin: 50px 15px 10px;+  margin: 40px 0 10px;+  white-space: pre-wrap;+  max-height: 450px;+  overflow-y: scroll;

have you checked what happens if the json log contains something (e.g. a very long string value or a very long object property name)? would it has to also scroll horizontally? would setting the overflow to auto also work and made the scrollbar hidden when the json fits into the available space?

atiqueahmedziad

comment created time in 12 days

pull request commentmozilla/extension-workshop

Added --adb-remove-old-artifacts to web-ext cli options reference

@caitmuenster This PR is ready to be merged on master, but it requires a sign-off from a reviewer with write access on the repo. Would you mind to approve and merge it? Thanks!

rpl

comment created time in 13 days

push eventrpl/extension-workshop

Luca Greco

commit sha 27b1c58c8362853bf17c349c1390fe522a0a4e73

Added --adb-remove-old-artifacts to web-ext cli options reference

view details

push time in 13 days

Pull request review commentmozilla/extension-workshop

Added --adb-remove-old-artifacts to web-ext cli options reference

 Network port to use when connecting to an Android device with [ADB (Android Devi  Environment variable: `$WEB_EXT_ADB_PORT` +#### \--adb-remove-old-artifacts++Removes automatically any old artifacts dir left on the target adb device by a previous `web-ext run` command.

@Rob--W I tweaked the description a bit, it is slightly different from the version you have proposed (e.g. web-ext run does actually automatically detect if there are old artifacts left on the device by default, but it doesn't remove them unless the user has explicitly asked it with this flag).

Let me know how the new versions looks to you.

rpl

comment created time in 13 days

push eventrpl/extension-workshop

Luca Greco

commit sha 310d7fb90c0b190c86d81be193fda8f63795e4b6

Added --adb-remove-old-artifacts to web-ext cli options reference

view details

push time in 13 days

pull request commentmozilla/extension-workshop

Added --adb-remove-old-artifacts to web-ext cli options reference

@caitmuenster it looks that I can't select @Rob--W as a reviewer on this PR (I guess that both me and Rob may have to be added explicitly to this repo?), would you mind to take a look into that?

rpl

comment created time in 13 days

PR opened mozilla/extension-workshop

Added --adb-remove-old-artifacts to web-ext cli options reference

As stated in the subject, this PR updates the web-ext command line reference to add the --adb-remove-old-artifacts CLI option.

+6 -0

0 comment

1 changed file

pr created time in 13 days

create barnchrpl/extension-workshop

branch : docs/web-ext-issue-1591

created branch time in 13 days

created tagmozilla/web-ext

tag5.0.0

A command line tool to help build, run, and test web extensions

created time in 13 days

release mozilla/web-ext

5.0.0

released time in 13 days

push eventmozilla/web-ext

Luca Greco

commit sha cfc49ce803a9a320d06af5871a2e3aa8a8c533b5

chore: Bump package version for release 5.0.0

view details

push time in 13 days

more