It would be nice to have the option (maybe default behavior?) of activating the header for a single tab, rather than the entire browser window. I've been bitten more than once by leaving the header active while browsing in other tabs, and in my usage (SWAT windows) I really only need to use this extension for a single tab.
Description
Description
Event Timeline
Comment Actions
I'm not sure what the UI/UX would be for this. @kostajh do you have an example of some other webextension that has a per-tab functionality that feels easy to use and understand?
Something like VueJS devtools, for instance, only makes its icon "glow" on a page where Vue.js is detected. I think using the existing "On" label with the Wikimedia icon as we currently have it would be sufficient to understand it's enabled for the current tab?
Comment Actions
Showing when the active tab is displaying an URL that is subject to manipulations of the add-on is not what I understood the original request to have been for. I took "activating the header for a single tab, rather than the entire browser window" to mean that you wanted to be able to mix tabs connecting to the debug servers and tabs connecting to the general purpose wikimedia servers in the same browser. Did I misunderstand the request?
Comment Actions
Sorry if I am not communicating clearly!
In the example above there are three tabs open: en.wiki, de.wiki, and test.wikipedia
Switching WikimediaDebug to "On" means traffic for all three tabs now flows through the debug server.
My request is to make it possible so that only the tab where I switch WikimediaDebug to "On" has traffic flowing through the debug server. So in my screenshot, the first two tabs (enwiki + dewiki) would not go through the debug server, while test.wikipedia would.
Comment Actions
I'm about 80% sure that this is possible in a reasonable non-hacky way with the WebExtension API that browsers provide. tabId is indeed provided.
It is however my understanding that there is conceptually only one shared instance of the icon and popup process, so the implementation would likely have to be something like this:
- Change boolean state in memory to set of tab IDs.
- Listen to relevant events that inform us of tab focus, tab opens, tab closures etc and decide in all relevant scenarios what the visual appearance of the badge should be ("ON" or "OFF").
- Change the HTTP request hook and determine the origin tab for a given request and check the state for that.
I believe inherent in this will be three side-effects.
- There will be visual ambiguity. E.g. two windows that each have their own focussed tab, and the user can see the icon in both windows. Even if we know which of the two windows is in the foreground (can we know that?) it would mean that the icon will be "wrong" in one of the windows. This would be an inherent limitation to the browser extension platform, on we can't workaround afaik. Although this impact would be scoped to the visual appearance of the badge.
- There will be a discrepency between the visual indicator and the actual HTTP request logic. The actual HTTP request would be "correct" in terms of applying to tabs where you enabled it.
- Opening a link in a new tab from the enabled tab would run outside the debug session with no way to have it within the session until it is enabled there first. There would essentially be no way to open multiple links within a debug session unless we had a second mode that behaves like what we have today. If we do that, we'll need to come with some intuitive way to communicate and manage that state within the popup window.
A possible compromise might be to utilize windowId and e.g. apply to all tabs within a given browser window. It might also be possible through some combination of successorTabId and openerTabId to implement some kind of viral state where we automatically consider new tabs originating from an enabled tab as well. However, this is only possible if there is a way to synchronously identify this information during a webrequest hook as it will fail to apply in time if we wait for the regular tab events to spread this state.
Comment Actions
This sounds like it might be more complicated than it's worth.
My original motivation for this request is that I sometimes forget that WikimediaDebug is on. Injecting a small banner at the top of the page HTML would probably suffice for that end, something like this?
