web-ext icon indicating copy to clipboard operation
web-ext copied to clipboard

Re-opening tab developer console after addon reload (brainstorming)

Open Juraj-Masiar opened this issue 1 year ago • 5 comments

Is this a feature request or a bug?

Feature / discussion

What is the current behavior?

If you are developing an addon page, you quickly notice that your tab is closed each time web-ext reloads your addon. You may hotfix it by adding await browser.tabs.create({url: 'options.html'}) into your background script, but that won't re-open developer console in that tab.

What is the expected or desired behavior?

I want the developer console to be opened after the reload.

I would like to brainstorm possible solutions for this problem. For example:

  1. prevent closing tab when the addon is reloaded - I guess Firefox would have to implement something (which would actually fixed the issue with "pinned addon page disappearing after addon update")

  2. web-ext could maybe open dev-tools if it has permission for that (I'm not sure how the integration with Firefox works and what are the capabilities). Also the question is, how to configure it... maybe new parameter "on-reload-dev-url=options.html"?

Juraj-Masiar avatar Nov 22 '23 12:11 Juraj-Masiar

If you are only modifying the extension page and not manifest.json, then you can achieve the desired effect by passing --no-reload : web-ext run --no-reload

This will start Firefox with the extension installed (directly pointing to the source directory), and not auto-reload. When you reload the page, it will read the content from the disk.

An alternative (without sacrificing the auto-reload option) is to do something like this (manual or automated):

  1. Navigate all extension pages of the extension to a temporary destination (e.g. about:blank) -- this step is needed because upon unloading an extension, all extension tabs are usually closed.
  2. Trigger a reload of the extension.
  3. Navigate all tabs from step 1 back.

Rob--W avatar Jan 04 '24 14:01 Rob--W

Whoa, those are some seriously good looking out of box ideas! Sacrificing reload is indeed bad. And it would also kept the background page un-reloaded if I change it, right? This caused me a lot of troubles already in Chromium browsers where I didn't used web-ext.

But the second idea is just amazing! But is it possible to automate it? The web-ext could send a message "reload-imminent" and addon could listen to "onMessageExternal" and perform the trick with the "about:blank". Or the web-ext could do it fully automatically. Get the list of opened extensions tabs and use "tabs.update" to move them away and then back after reload.

Juraj-Masiar avatar Jan 04 '24 16:01 Juraj-Masiar

I've been looking at the source code here and although I did find where the reloading happens, I have no idea how to fetch existing tabs.

Is that even possible? I thought web-ext is injecting also itself as an extension but I see that's not what's happening. Is there some API documentation for the RDP messaging?

PS: any plans to switch to TypeScript? It greatly helps with development. I could help with that, we could have a long pair-programming online session and migrate all code here in a several hours :). In TypeScript, most types is inferred so most of the code doesn't need any change.

Juraj-Masiar avatar Jan 05 '24 09:01 Juraj-Masiar

I've been looking at the source code here and although I did find where the reloading happens, I have no idea how to fetch existing tabs.

Is that even possible?

Yes it is! The "listTabs" request does what you want. Details below.

I thought web-ext is injecting also itself as an extension but I see that's not what's happening. Is there some API documentation for the RDP messaging?

High-level documentation is at https://firefox-source-docs.mozilla.org/devtools/backend/protocol.html

I found the goForward, goBack and navigateTo methods in a part of the protocol spec at https://searchfox.org/mozilla-central/rev/9c509b8feb28c1e76ad41e65bf9fd87ef672b00f/devtools/shared/specs/targets/window-global.js#50-53,62-69,79-84 Looks like these primitives are what you need.

PS: any plans to switch to TypeScript? It greatly helps with development. I could help with that, we could have a long pair-programming online session and migrate all code here in a several hours :). In TypeScript, most types is inferred so most of the code doesn't need any change.

We used to use Flow for typing before, but removed it in https://github.com/mozilla/web-ext/pull/2765 because its presence was interfering rather than helping with maintainability. There has also been a request to export TypeScript definitions, but we closed these because of concerns about long-term correctness and maintenance: https://github.com/mozilla/web-ext/issues/2829#issuecomment-1781165181 . Migrating everything to TypeScript could reduce that concern, but I don't know if that's something that we want to do given our experience with Flow types here.

Rob--W avatar Jan 05 '24 10:01 Rob--W

Firefox has some projects build with TypeScript, maybe you ask them how they feel about it. But in general, based on StackOverflow survey, TypeScript is one of the most loved languages, more than JavaScript and way more than Flow: https://survey.stackoverflow.co/2023/#section-admired-and-desired-programming-scripting-and-markup-languages

In any case, I'm trying to develop locally the web-ext based on the docs on my Windows but I'm having hard time :( For example:

  • many tests are failing: https://pastebin.com/LrJJ52Bb
  • after each change, this page opens: https://extensionworkshop.com/documentation/develop/getting-started-with-web-ext/
  • when I use npm run start, how do I test in on an extension? I suppose it's build in the "lib" folder, but how do I use it from there? This is not my area of expertise and I don't see it in the docs.

Juraj-Masiar avatar Jan 05 '24 14:01 Juraj-Masiar