1702319 - Consider making searchfox aware of other open tabs and dynamically updating titles to reflect what's displayed and in response to hover and offering to bounce to an already open tab

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

Context

Browsers provide us with a means of knowing what other searchfox tabs exist that are alive/unfrozen. (In Firefox, this generally means any tabs that have been displayed this session. The "BarTab" optimization means that Firefox only restores pinned tabs at startup, plus tabs are restored as they are displayed.) We could do more with these capabilities, our knowledge of what's focused-ish based on position:sticky (or highlighted lines) which we already poll for, as well as our ability to dynamically update document.title.

I use the amazing, phenomenal, super-great, cannot-say-enough-things-about-it Tree Style Tab vertical hieriarchical tabs extension, and I frequently find myself getting lost amongst all my open tabs. Given that I don't think anyone really wants their searchfox experience to be a Single-Page-App which reinvents all the wheels, I think we could probably lean more into assuming the assumption that searchfox users may use multiple tabs.

Possible UI Things

Title / Favicon Tricks

• Dynamically update the document.title to reflect the current position:sticky'd line if no line is selected (as displayed in the anchor). In the event a line is anchored, do the position:sticky calculation to name the symbol on the line or its enclosing position:sticky.
  • That is, if you click on a method's line number, we show the method. If you click on a line inside the method, we still show the method. If you click just above the method inside the class definition block, we show the class.
• When hovering over menu items like the "go to definition" or the related "search for" options, we could potentially make the favicons/titles for pages that are currently displaying those search results or pages that have the definition or the declarations visible (or selected via anchor) change to make it clear that they are already displaying the target.
• "Sticky highlight" could gain a friend like "title this page after this symbol" but more terse.

WindowClient.focus Tricks

WindowClient.focus with a client obtained via Clients.matchAll lets us use a ServiceWorker to find an existing window (does not include tabs that Firefox knows about but have not actually been restored) and ask the browser to focus it.

• Menu options like "go to definition" or the related "search for" option that contain pages that are directly the result or include expected results from the given search could gain an additional action icon segment on the right side of the menu that is a button that will attempt to client.focus() the existing tab.
• When landing on a page that is effectively a known duplicate of an existing page (as determined by the clients API), we could put an info box in the navigation sidebar that says "hey, you have the following overlapping pages available, click to close this page and go to whichever one you click on."

WebExtension tricks

It might also be most pragmatic to just create a WebExtension since:

• It can have a more omniscient understanding of what searchfox tabs are open, even if they haven't been restored/have live windows.
• It could try and more proactively influence the selection of existing tabs via the omnibox API
• Tree Style Tabs has an extension API that can do fancy things like contribute custom styling for tabs.
• People may already use :Marco's cool https://github.com/marco-c/mozsearch-phabricator-addon and maybe we could just have a one-stop searchfox webext experience
• Similarly, pernosco searchfox integration would be a neat thing and that may end up requiring a webext.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Landed GitHub Pull Request to do dynamic document.title stuff

An enhancement to dynamically update document.title landed and is in effect as of this morning. I'm going to leave this bug here and open (and unassigned) to track ideas about referencing existing opened tabs, which is a more involved enhancement.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

From my own dog-fooding of these changes, I think it probably makes sense to:

• Implement the settings page.
• Have the default either be the original ${filename} - mozsearch or a new hybrid of ${filename} - ${symbol no namespaces} - mozsearch.
  • I don't want to be constantly changing the defaults out from under people, but my expectation is that most people's tabs will usually be truncated by the end of the filename, so the inclusion of the symbol could still represent something useful for awesombar tab completion purposes while otherwise representing a return to the original behavior.
• Bias the settings UX to not include the namespace. For example, it could be a checkbox that defaults to unchecked rather than an equivalent choice amongst radio button options.

Comment 3

[Shug Miles]

Attachment: same problem

Thanks from anerrietran1973.