Unclear how enabling a Sourcegraph extension on Sourcegraph affects the browser extension

[chrismwendt]

Currently, adding/removing a Sourcegraph extension on the Sourcegraph instance may or may not actually cause it to be active when viewing code because it depends on the settings of higher-precedence settings in the cascade (global/org/user/client). It's not clear how the settings on the Sourcegraph instance affect the browser extension's behavior.

Ideas to solve/mitigate this confusion:

• Show "Client" in the drop-down list on the Sourcegraph instance when the user has the browser extension installed (indicates that the browser extension settings are related to other settings)
• Show "Everyone"/orgs/ (in addition to "Client") in the drop-down list in the browser extension when the user is signed in (same reasoning as above)
• Completely remove the registry from the browser extension, and instead redirect the user to their Sourcegraph instance's registry (this is more radical, and could prompt other questions such as "Where are the Client settings actually stored?")

Regarding the last idea, I believe the main reason we opted to put a Sourcegraph extensions list in the browser extension was to avoid making it appear tied so closely to Sourcegraph. @sqs @KattMingMing Does open sourcing much of Sourcegraph change this decision?

[chrismwendt]

Just chatted with @sqs in person and this will greatly simplify the UX, so I'm going to tackle this now.

[chrismwendt]

Should I also remove this sidebar now that the "Extensions" tab no longer exists? @francisschmaltz

[ijsnow]

So, if you look at a public repo, Sourcegraph extensions will be pulled from the user's sourcegraph.com settings and if they're looking at a private repo, it'll pull from the respective instance?

[chrismwendt]

No, Sourcegraph extensions will always be pulled from the single Sourcegraph URL specified on the options page.

The browser extension doesn't know ahead of time which Sourcegraph instance the repository lives on (public vs private is independent of the Sourcegraph instance). Instead of trying each Sourcegraph instance in the list, the browser extension only communicates with one Sourcegraph instance.

[ijsnow]

Just for extensions? Or even code intelligence?

I think that simplifying the logic for checking multiple instances(or even getting rid of retrying) would be great for the code base but losing how it "just works" when looking at private vs public code would be a pretty huge regression in user experience. And in this case by "it" I mean hovers. I know I definitely don't want to keep going and switching back and forth from .com and our private instance

[chrismwendt]

Good point, I think this warrants its own discussion. It could be possible to forward code intelligence requests for public repositories from a private Sourcegraph instance up to Sourcegraph.com when the repository doesn't exist.

[francisschmaltz]

@chrismwendt If there is only one page we should remove the sidebar

[ijsnow]

Good point, I think this warrants its own discussion

Cool, we can discuss tomorrow since the PR that brought me to this issue said to hold off on merging.

If there is only one page we should remove the sidebar

How will browser extension user's get to the extensions page? Should there be a link in the side bar?

[francisschmaltz]

Yes! So if that is an option, then we should have a sidebar. If it is not, then there shouldn't be a sidebar visible.

[chrismwendt]

I'm planning on putting a link in the feature flag check box and removing the sidebar for now

[chrismwendt]

I found an example of how to use message passing to communicate between the browser extension and a web page https://github.com/mdn/webextensions-examples/tree/master/page-to-extension-messaging

[chrismwendt]

Client settings got revamped since opening this issue.