Skip to content
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

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

Open
Juraj-Masiar opened this issue Nov 22, 2023 · 5 comments
Open

Comments

@Juraj-Masiar
Copy link

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"?

@Rob--W
Copy link
Member

Rob--W commented Jan 4, 2024

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.

@Juraj-Masiar
Copy link
Author

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
Copy link
Author

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.

@Rob--W
Copy link
Member

Rob--W commented Jan 5, 2024

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 #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: #2829 (comment) . 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.

@Juraj-Masiar
Copy link
Author

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:

Juraj-Masiar added a commit to Juraj-Masiar/web-ext that referenced this issue Jan 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants