Suggestion: Don't close urlbar results and don't reset urlbar when opening a background tab.

[mzso]

Hi!
I see some script to change to the urlbar, I think this would be a worthy addition.

Is your feature request related to a problem? Please describe.
Even explicitly opening tab in the background, the urlbar results are closed and the bar is reset.

Describe the solution you'd like
When opening tabs in the background the urlbar and results should remain as they are, so I can open more results, etc.
Which would be the main point in opening them in the background in the first place.

Additional context
This feature Mozilla failed to implement for years (136445...), there's even a patch for it in a never bug they didn't bother to do anything with.

On a related note, I need to use modifiers like (ctrl+)shift+alt+enter, shift+middle-button, (ctrl+)shift+left-button to get things from the urlbar to open in a background tab, even if browser.tabs.loadDivertedInBackground is enabled. Which is pretty much a bug they didn't bother to fix. Maybe the script could also avoid forcing me to use clumsy and inconsistent modifiers as well, and just open in background via plain middle click and ctrl enter (or alt+enter as it once did).

[aminomancer]

Is there a bug report for urlbar results not obeying loadDivertedInBackground? I was under the impression that pref only affects tabs with an opener that are opened from a browser, so I didn't expect it to affect urlbar results. I personally wouldn't want it affecting my urlbar, since they are very different kinds of affordance. Bookmarks have their own pref for that, and I had to make a new script to get similar behavior with history and synced tabs, because they're semantically not the same as links.

Anyway, sounds like there are multiple issues here:

1. When using a keyboard shortcut that opens a urlbar result in a background tab (like the ones you mentioned e.g. Shift + MMB), the urlbar results popup should remain open like the bookmarks popup does. But what should happen to the actual results? What should happen to text in the urlbar, and what should happen to the search mode? Should all that stuff remain exactly as it was before you activated the result? Or should it be reset, but the popup kept open?

   • It's difficult to do this perfectly with a script because this behavior extends to about:newtab, which autoconfig scripts have a very hard time hacking into. I think this enhancement would be accepted so if I do this, I would most likely just submit it as a patch.

2. There isn't any way to make "load in background" the default behavior for urlbar results, unlike for bookmarks.

3. However, 2 is a multifaceted issue, because bookmarks have two prefs that control where they open:

   • browser.tabs.loadBookmarksInTabs
   • browser.tabs.loadBookmarksInBackground

   The first pref determines whether the bookmark loads in current or in tab by default, and the second pref determines whether the bookmark loads in tab or tabshifted in the event that the open behavior has been modified by a keyboard modifier or by the first pref. That's important here because urlbar results are something that normally open in current. So if we only added a pref to switch from tab to tabshifted that wouldn't affect the default behavior, that would only affect the middle click behavior, such that MMB opens in a background tab and Shift + MMB opens in an active tab.

4. An issue with Ctrl + Enter is that it has its own behavior, at least provided browser.urlbar.ctrlCanonizesURLs is true (which it is by default). However, I don't see any reason why Ctrl + Shift + Enter can't open the result in a background tab.

5. It sounds like you're proposing that we add a pref that changes the left mouse button behavior but not the Enter behavior. I wouldn't want to change the Enter behavior either, since most of the time I use the urlbar I'm not trying to open background tabs. So I understand why you'd want to use Ctrl + Enter instead. But in almost every case, unmodified LMB and unmodified Enter do the same thing, because LMB and Enter/Spacebar both ultimately propagate to command events. It would be confusing for clicking an element to do something different than keyboard activating it. That has accessibility implications because many people use the keyboard as an alternative to the mouse. If they hear that left clicking something does such-and-such, they are expecting Enter to do the same thing.

   So I'm a lot more inclined to use two prefs, just like the bookmarks prefs. One determines whether left click and Enter open the result in the current tab or in a new tab (this pref already exists: browser.urlbar.openintab); and the other determines whether the result opens in an active tab or a background tab. That would yield the following options:

   1. Default state
      1. current = Left click or Enter
      2. new active tab = Ctrl + left click, Alt + Enter, or middle click
      3. new background tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
   2. browser.urlbar.openinbackground = true
      1. current = Left click or Enter
      2. new active tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
      3. new background tab = Ctrl + left click, Alt + Enter, or middle click
   3. browser.urlbar.openintab = true
      1. current = Ctrl + left click, Alt + Enter, or middle click
      2. new active tab = Left click or Enter
      3. new background tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
   4. browser.urlbar.openinbackground and browser.urlbar.openintab = true
      1. current = Ctrl + left click, Alt + Enter, or middle click
      2. new active tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
      3. new background tab = Left click or Enter

Does that sound about right?

[aminomancer]

After looking into this issue more closely I think both of these issues will be solved without an autoconfig script. Mozilla has been really busy and backlogged, and this issue is pretty complicated, so it's understandable that it's been collecting dust for so long. But I'm confident we can get a patch accepted and landed quickly. None of this is unconventional or opinionated stuff, and mak has expressed approval of both ideas, so I'm pretty sure this can be landed quickly with the right focus

[mzso]

@aminomancer commented on 2022. febr. 5. 13:35 CET:

After looking into this issue more closely I think both of these issues will be solved without an autoconfig script. Mozilla has been really busy and backlogged, and this issue is pretty complicated, so it's understandable that it's been collecting dust for so long. But I'm confident we can get a patch accepted and landed quickly. None of this is unconventional or opinionated stuff, and mak has expressed approval of both ideas, so I'm pretty sure this can be landed quickly with the right focus

I highly doubt it. He wasn't against it 4-5 years ago either. Yet nothing became of it. Mozilla is apparently perpetually backlogged.
I saw a bunch of times annoying bugs/issues beeing left to rot for years. Until mostly it was closed when it stopped being applicable because they removed or changed features from under it.

@aminomancer commented on 2022. febr. 5. 12:55 CET:

Is there a bug report for urlbar results not obeying loadDivertedInBackground? I was under the impression that pref only affects tabs with an opener that are opened from a browser, so I didn't expect it to affect urlbar results. I personally wouldn't want it affecting my urlbar, since they are very different kinds of affordance. Bookmarks have their own pref for that, and I had to make a new script to get similar behavior with history and synced tabs, because they're semantically not the same as links.

Here's one that I know of: https://bugzilla.mozilla.org/show_bug.cgi?id=1748115
It has around zero activity, but I do believe a Mozilla dev filed it.

I thought it worked for history by default. Maybe some other stuff that I have does it.

Anyway, sounds like there are multiple issues here:

1. When using a keyboard shortcut that opens a urlbar result in a background tab (like the ones you mentioned e.g. Shift + MMB), the urlbar results popup should remain open like the bookmarks popup does. But what should happen to the actual results? What should happen to text in the urlbar, and what should happen to the search mode? Should all that stuff remain exactly as it was before you activated the result? Or should it be reset, but the popup kept open?

I think everything should be left the same. For doing it with results I see no logic in anything changing.
When doing it in the urlbar itself I found it practical sometimes (when an addon made this possible) I could search variations of a search term or just different searches by changing the keyword. And I don't see how the results be the same if the urlbar content changes.

*   It's difficult to do this perfectly with a script because this behavior extends to about:newtab, which autoconfig scripts have a very hard time hacking into. I think this enhancement would be accepted so if I do this, I would most likely just submit it as a patch.

2. There isn't any way to make "load in background" the default behavior for urlbar results, unlike for bookmarks.

3. However, 2 is a multifaceted issue, because bookmarks have two prefs that control where they open:

   • browser.tabs.loadBookmarksInTabs
   • browser.tabs.loadBookmarksInBackground

   The first pref determines whether the bookmark loads in current or in tab by default, and the second pref determines whether the bookmark loads in tab or tabshifted in the event that the open behavior has been modified by a keyboard modifier or by the first pref. That's important here because urlbar results are something that normally open in current. So if we only added a pref to switch from tab to tabshifted that wouldn't affect the default behavior, that would only affect the middle click behavior, such that MMB opens in a background tab and Shift + MMB opens in an active tab.

Well, I could live with that if it didn't override a modifier I don't need to use. I'm especially not used to using MMB with a modifier.

4. An issue with Ctrl + Enter is that it has its own behavior, at least provided browser.urlbar.ctrlCanonizesURLs is true (which it is by default). However, I don't see any reason why Ctrl + Shift + Enter can't open the result in a background tab.

5. It sounds like you're proposing that we add a pref that changes the left mouse button behavior but not the Enter behavior. I wouldn't want to change the Enter behavior either, since most of the time I use the urlbar I'm not trying to open background tabs. So I understand why you'd want to use Ctrl + Enter instead. But in almost every case, unmodified LMB and unmodified Enter do the same thing, because LMB and Enter/Spacebar both ultimately propagate to command events. It would be confusing for clicking an element to do something different than keyboard activating it. That has accessibility implications because many people use the keyboard as an alternative to the mouse. If they hear that left clicking something does such-and-such, they are expecting Enter to do the same thing.

I was more thinking of ctrl+enter, middle mouse, ctrl+left. Because ctrl normally implies new tab (as does the middle click). Except the jumble it up in the urlbar with that pointless ancient canonize feature, that I never saw anyone use in the past 20 years.

So I'm a lot more inclined to use two prefs, just like the bookmarks prefs. One determines whether left click _and_ Enter open the result in the current tab or in a new tab (this pref already exists: `browser.urlbar.openintab`); and the other determines whether the result opens in an active tab or a background tab. That would yield the following options:

1.  Default state
    1.  current = Left click or Enter
    2.  new active tab = Ctrl + left click, Alt + Enter, or middle click
    3.  new background tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
2.  `browser.urlbar.openinbackground` = true
    1.  current = Left click or Enter
    2.  new active tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
    3.  new background tab = Ctrl + left click, Alt + Enter, or middle click
3.  `browser.urlbar.openintab` = true
    1.  current = Ctrl + left click, Alt + Enter, or middle click
    2.  new active tab = Left click or Enter
    3.  new background tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
4.  `browser.urlbar.openinbackground` and `browser.urlbar.openintab` = true
    1.  current = Ctrl + left click, Alt + Enter, or middle click
    2.  new active tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
    3.  new background tab = Left click or Enter

Does that sound about right?

It looks a tad complicated and hard to follow.
I guess, though it doesn't look like alt+enter even works anymore for a new tab like you stated in default state. AFAIk it's shift+alt or ctrl+shift+alt... Or maybe I just had to disable the canonize feature...

I have no opinion on browser.urlbar.openintab because I never used it. I just want when I open new tabs (via usual methods like MMB ctlr+click, alt|ctrl+enter) to be opened in the background and for the urlbar/results to remain the same. If I need to use an extra modifier I can live with that.
So I guess when browser.urlbar.openintab is enabled it would do it by default. (or based on the new setting you proposed)

[mzso]

@aminomancer commented on 2022. febr. 5. 13:35 CET:

After looking into this issue more closely I think both of these issues will be solved without an autoconfig script. Mozilla has been really busy and backlogged, and this issue is pretty complicated, so it's understandable that it's been collecting dust for so long. But I'm confident we can get a patch accepted and landed quickly. None of this is unconventional or opinionated stuff, and mak has expressed approval of both ideas, so I'm pretty sure this can be landed quickly with the right focus

Hmm. Rereading your comment it seems like you didn't notice that there is a patch, and the bug collected dust with that patch present. (Not sure if it bit-rotted in the year it was last touched...)
I wonder if that patch (or a fixed one) can be made into a XUL addon in the meanwhile. I have no high hopes for the bug to progress at all.
Well, maybe if someone actively starts poking Mozilla members with patches and review requests.

[aminomancer]

I did notice there is a patch. I asked her last night if she wants to rebase it. I can take it over if she doesn't. There is no such thing as XUL addons anymore for many many versions. That's why people use autoconfig to load scripts.

When doing it in the urlbar itself I found it practical sometimes (when an addon made this possible) I could search variations of a search term or just different searches by changing the keyword. And I don't see how the results be the same if the urlbar content changes.

The user can't change the input without changing the results, but that's on purpose. They're not one and the same. Typing in the input updates the results. But javascript can transform the text without updating the results. It already does this when you use arrow keys to cycle through results.

I was more thinking of ctrl+enter, middle mouse, ctrl+left. Because ctrl normally implies new tab (as does the middle click). Except the jumble it up in the urlbar with that pointless ancient canonize feature, that I never saw anyone use in the past 20 years.

I don't think anyone's gonna go for this since it's a highly opinionated change that would disrupt a lot of people, and those shortcuts aren't documented in the browser anywhere, only on a SUMO page. I don't think they're gonna get rid of canonize since there's already a pref that disables it. It wouldn't be that difficult to make a script that changes the shortcut modifier from Alt to Ctrl if the canonize pref is disabled.

Idk what you mean since I don't have the canonize pref disabled. I just wrote down the keyboard shortcuts as I was testing them.

The point of my comment is that there are 2 different things that you're conflating. 1) is whether urlbar results should open in tab or tabshifted (active or background tab) and 2) is your complaint about keyboard shortcuts requiring too many modifiers. It sounded to me like you want there to be simpler shortcuts or for background tab to even be the default behavior for left click/Enter. The way I see it, that can only happen if 2 prefs are combined. Just like I said in my previous post.

[aminomancer]

Here's my task for this issue. I am almost done with my initial patch and then I'll submit it for review. I'm just working on test files now.

[aminomancer]

And here's my patch rev1

[mzso]

@aminomancer commented on 2022. febr. 5. 23:28 CET:

I did notice there is a patch. I asked her last night if she wants to rebase it. I can take it over if she doesn't. There is no such thing as XUL addons anymore for many many versions. That's why people use autoconfig to load scripts.

Well, some also use auto-config to restore XUL addons: https://github.com/xiaoxiaoflood/firefox-scripts/tree/master/extensions
I've been using some of these and others (around six) since leaving the 56 branch behind. So I was thinking if it's not difficult to transform a patch into an addon it could be used in the meanwhile, because I don't have good experiences with stuff landing in Mozilla time. (It was only a vague idea.)

When doing it in the urlbar itself I found it practical sometimes (when an addon made this possible) I could search variations of a search term or just different searches by changing the keyword. And I don't see how the results be the same if the urlbar content changes.

The user can't change the input without changing the results, but that's on purpose. They're not one and the same. Typing in the input updates the results. But javascript can transform the text without updating the results. It already does this when you use arrow keys to cycle through results.

In this part I was talking about keyword searches, but it applies to deafault search as well. Such as if I have g for google. I could search "g something" then "g something similar" or "g something" then "d something" for Duckduckgo. Without the URLbar being cleared.
I see what you mean. I though see no point doing anything with the urlbar in this case.
What would you do with it anyway, reload the current tab's url? I see no point. Clear the bar? Doesn't seem to accomplish anything in particular only showing results without for a search term that's not there anymore.
But it does break the use cases I detailed above.
As for opening a new background tab from results, it would make even less sense to clear away their search term.

By the way I don' know what you meant by "and what should happen to the search mode?" in your previous comment . What do you mean by search mode?

I was more thinking of ctrl+enter, middle mouse, ctrl+left. Because ctrl normally implies new tab (as does the middle click). Except they jumble it up in the urlbar with that pointless ancient canonize feature, that I never saw anyone use in the past 20 years.

I don't think anyone's gonna go for this since it's a highly opinionated change that would disrupt a lot of people, and those shortcuts aren't documented in the browser anywhere, only on a SUMO page. I don't think they're gonna get rid of canonize since there's already a pref that disables it. It wouldn't be that difficult to make a script that changes the shortcut modifier from Alt to Ctrl if the canonize pref is disabled.

Oh well. I got used to alt+enter anyway,even though it makes no sense, since everywhere else ctrl is the modifier. (I also remember that other platforms do use ctrl...)

Idk what you mean since I don't have the canonize pref disabled. I just wrote down the keyboard shortcuts as I was testing them.

The point of my comment is that there are 2 different things that you're conflating. 1) is whether urlbar results should open in tab or tabshifted (active or background tab) and 2) is your complaint about keyboard shortcuts requiring too many modifiers. It sounded to me like you want there to be simpler shortcuts or for background tab to even be the default behavior for left click/Enter. The way I see it, that can only happen if 2 prefs are combined. Just like I said in my previous post.

Ah, okay. Must have given a slightly wrong impression. I don't mind the simple (new tab) modifiers. And with the browser.urlbar.openinbackground setting you propose there should be no others needed.
(The ctrl/shift inconsistency is a little annoying as mentioned, but tolerable.)

[aminomancer]

I wouldn't recommend using legacy extensions unless you have an old one that already exists. I wouldn't bother making a new one, everything that can be done with a legacy extension can be done with autoconfig.

I'm not sure what you're talking about in your second paragraph. Maybe we have a different idea of what we're talking about.

By the way I don' know what you meant by "and what should happen to the search mode?" in your previous comment . What do you mean by search mode?
Idk how else to say it. Search mode is which engine you have active. If you click a one-off search engine button (google, amazon, bing, whatever) it changes the search mode. The identity icon changes into a little box that shows the name of the engine. Anyway, these questions probably aren't important anymore since I made my patch and basically made these decisions already.

If you set up build tools you can test my patch. With the repo cloned you can run

./mach install-moz-phab

then

moz-phab patch D137946

It'll apply the patch to your working directory. Then you can go into your working directory (mozilla-central) and find a file called mozconfig and replace the content with this:

ac_add_options --enable-artifact-builds
mk_add_options AUTOCLOBBER=1

And then you can run

mach build

and when that's done, run

mach run

and you'll be able to test it for yourself.

Yes, I also find the ctrl/shift inconsistency irritating. However, it should probably be pretty easy to make a patch that will eliminate the inconsistency (make the modifier Ctrl for both click and Enter) if the canonize pref is disabled. Or another idea would be to flip the two so that Alt canonizes the URL and Ctrl gets to have the same behavior as it does when clicking. I can start a task for that. If it isn't accepted, it could be turned into an autoconfig script.

[mzso]

@aminomancer commented on 2022. febr. 6. 13:24 CET:

I wouldn't recommend using legacy extensions unless you have an old one that already exists. I wouldn't bother making a new one, everything that can be done with a legacy extension can be done with autoconfig.

I'm not sure what you're talking about in your second paragraph. Maybe we have a different idea of what we're talking about.

How so? You were talking about clearing the urlbar, or changing the content, and I merely argued that it's detrimental to usability.

• In the urlbar itself, with keyword searches it pretty much prevents me from using multiple search engines conveniently for the same search term, or multiple related searches. Which is what I made the examples for.
• As for opening results in a new background tab, I was wondering what would you change the urlbar content, and why.

Idk how else to say it. Search mode is which engine you have active. If you click a one-off search engine button (google, amazon, bing, whatever) it changes the search mode. The identity icon changes into a little box that shows the name of the engine. Anyway, these questions probably aren't important anymore since I made my patch and basically made these decisions already.

Ah, I see. I didn't think of that because I don't use them, and I'm unfamiliar with how they affect the urlbar. I use keyword searches since more than a decade ago.
I just disabled one-offs in settings which disabled their bar altogether.

If you set up build tools you can test my patch. With the repo cloned you can run

I never had any success at building anything, whenever I was forced to do so. Something always fails in the scripts or libraries or whatever.

What did you went with anyway? What happens to the urlbar when you open new background tabs via urlbar or results? Does it remain as it is?

Yes, I also find the ctrl/shift inconsistency irritating. However, it should probably be pretty easy to make a patch that will eliminate the inconsistency (make the modifier Ctrl for both click and Enter) if the canonize pref is disabled. Or another idea would be to flip the two so that Alt canonizes the URL and Ctrl gets to have the same behavior as it does when clicking. I can start a task for that. If it isn't accepted, it could be turned into an autoconfig script.

Sounds cool.

[aminomancer]

No, I said:

The user can't change the input without changing the results, but that's on purpose. They're not one and the same. Typing in the input updates the results. But javascript can transform the text without updating the results. It already does this when you use arrow keys to cycle through results.

When you activate a result by any means it will change the text in the urlbar input. But it only updates the results if you activate a search mode result or one-off search button. Otherwise it's just the same as arrow keying or tabbing through the results. Obviously the results don't update when the text changes or else you wouldn't be able to tab through them as your selected view index would keep getting reset to 0. The results only update when 1) you manually type into the urlbar, or 2) you change search modes.

Ah, I see. I didn't think of that because I don't use them, and I'm unfamiliar with how they affect the urlbar. I use keyword searches since more than a decade ago.
I just disabled one-offs in settings which disabled their bar altogether.

Keyword searches are a different thing from search engines. There is no special behavior needed for keyword searches, they use the same system as all other kinds of urlbar results. Search engines launch URLs on a particular path according to a set of POST request and pattern properties. So you activate an engine by typing its alias or clicking its button, and then you type a search string and it generates a URL leading to search results for that string on the engine's website. I have a bunch of them hosted on this repo or on AMO. Some only have one type of URL so they just lead to a results page. But others have a results URL and an x-suggestions URL. So they create suggestion results in the urlbarview generated from the domain in question. Like Wikipedia has an x-suggestions API, if you type "Moz" it can guess "Mozilla" and return that in a list of suggestions that Firefox will generate results from.

There's no formal limit to the number of search engines a user can have installed, and Firefox includes several pre-installed. So you can only be using one search engine at a time, which requires means to switch between them as well as an indication of which one you're using. The results have to be updated when switching between search engines, because search engines provide different suggestions. If I type "Moz" into my default search engine (Google) that's gonna give me different x-suggestions than if I type "Moz" into my wikipedia engine. So clicking a one-off search button or a search engine provider or onboarding result will update the results as well as the indicator. That's inevitable though, if we didn't do that it would be considered a bug by most users.

I never had any success at building anything, whenever I was forced to do so. Something always fails in the scripts or libraries or whatever.

What did you went with anyway? What happens to the urlbar when you open new background tabs via urlbar or results? Does it remain as it is?

Well this is why I recommended testing it. This is a complicated and large javascript patch. I don't really wanna spend time typing out every aspect of it after I already spent several hours typing out the actual code. The build tools shouldn't fail if you follow the instructions. They're very sophisticated. Firefox has many thousands of active volunteer contributors who would not be able to contribute if the build tools just randomly or arbitrarily failed for some users.

What happens to the urlbar is exactly as I said. The urlbar input text changes when you click a result, just like it changes when you arrow key into a result. Neither action updates the results, they only change the text. Only user actively typing in the urlbar updates the results. That, or changing search mode. So what happens to the text depends on which way you activated the result. If you picked the first result then nothing happens to the input text, since Firefox was already autofilling the input text based on the heuristic result which is always the 1st result. If you picked the 2nd result, it's gonna depend on whether you arrow keyed/tabbed into it, or clicked it with the mouse.

When you arrow key/tab into a result, it "selects" the result without "activating" it. When you select a result, it changes your input text to match the result's. Just because the text changes doesn't mean the results change. That's why I said the input text and the results are separate issues. I already said all this. It's obvious if you just use Firefox and pay attention to what's happening. When you mouse click a result, it both selects the result and activates the result. Virtually simultaneously. Normally the urlbarview closes before you can notice anything happening. But now that the urlbarview stays open and you remain on your current tab, you can see that this changes your input text. Because you selected the result, didn't just activate it. When you use the keyboard, you always select the result before you activate it, so it's noticeable. But when you use the mouse, they happen at the same time. Anyway, just as with the keyboard, activating a result with the mouse changes the input text but doesn't update the results.

So the results popup stays open, the results that are present remain present, and the text changes to match the result you selected, irrespective of how you selected it (arrow keys, tab key, or mouse). The result you clicked now becomes "selected" so it's the one that's virtually focused. So if you had the 1st result selected and then you clicked the 5th result, it'll open that result and the 5th result will remain selected. If you now hit arrow key down, the selection will jump to the 6th result.

Like I said before, it's a complicated and large patch. It's not easy to describe this in words but it's all very self-explanatory if you test the patch. It takes like 15-30 minutes to clone the source on a decent connection, but you only have to clone the source once and you're basically set for life because you can update it very quickly. After cloning the source it takes like 30 seconds to apply the patch to your working folder, and then, as long as you set the mozconfig file the way I said, to enable artifact builds, you don't have to build the binary code, so it only takes like 2-5 minutes to build. At least on my computer, artifact builds are very fast. Then you just type mach run and you're running your custom patched build

[mzso]

@aminomancer commented on 2022. febr. 7. 18:11 CET:

But it only updates the results if you activate a search mode result or one-off search button.

You said, changing a search mode is basically changing to a different one-one off search by clicking it. So I don't know how to interpret "activate a search mode result"

Anyway, just as with the keyboard, activating a result with the mouse changes the input text but doesn't update the results.

Now that you say this... I found this incredibly frustrating, when trying to upen multiple results. The search term is vanquished, and the tab's url is restored. So I had to press ctrl+z twice in the urlbar to get it back, and find the other item which maybe now in a different position due to frecency change (and repeat for every result I want to open).

But does the same will happen when I open the new background tab from the urlbar directly? I find this even more annoying because I keep losing my search term even though I remain in the URL-bar. Prevents me from doing related searches efficiently (as described above) for no good reason.

So the results popup stays open, the results that are present remain present, and the text changes to match the result you selected, irrespective of how you selected it (arrow keys, tab key, or mouse).

But that is not what happens, at least right now. (If I understand you correctly) The selected item's URL only loads if I actually load it in the current tab. If it's a new tab, then I get back the current tab's URL.

By the way. Isn't there a way to make a build on via bugzilla/mozilla? I think I tested such before.

[aminomancer]

You said, changing a search mode is basically changing to a different one-one off search by clicking it. So I don't know how to interpret "activate a search mode result"

When you have browser.urlbar.suggest.engines enabled and you type the alias of a search engine (e.g., "goo" for Google), Firefox will create a suggestion result for the engine. Activating it will activate that engine's search mode. This is just standard Firefox behavior.

Now that you say this... I found this incredibly frustrating, when trying to upen multiple results. The search term is vanquished, and the tab's url is restored. So I had to press ctrl+z twice in the urlbar to get it back, and find the other item which maybe now in a different position due to frecency change (and repeat for every result I want to open).

But does the same will happen when I open the new background tab from the urlbar directly? I find this even more annoying because I keep losing my search term even though I remain in the URL-bar. Prevents me from doing related searches efficiently (as described above) for no good reason.

I'm really not sure what you're talking about. The thing I'm referring to can't be seen in Firefox right now because the urlbar results always close when activating a result. I was talking about my patch, which is awaiting review. Anyway, I can't keep talking about this, I've already spent way too much time on this. You can test my patch, or wait for it to land in Nightly.

But that is not what happens, at least right now. (If I understand you correctly) The selected item's URL only loads if I actually load it in the current tab. If it's a new tab, then I get back the current tab's URL.

Like I said, I'm talking about my patch. We already know what happens right now, bugs have already been reported, and that's the whole point of making a patch. You asked how my patch works, I told you how it works. But if you don't understand my description then you can always try testing the patch for yourself using the instructions I gave you before.

By the way. Isn't there a way to make a build on via bugzilla/mozilla? I think I tested such before.

I have no idea what you mean. The only way to test my patch is to clone the source, apply the patch, and build it. So that involves installing MozillaBuild and then following the instructions.

It seems like we're talking in circles. Idk what you're trying to ask me about

[mzso]

@aminomancer

You can test my patch, or wait for it to land in Nightly.

Cool. I'll test when it'll becoma available.

Firefox will create a suggestion result for the engine. Activating it will activate that engine's search mode. This is just standard Firefox behavior.

Okay. It may be. I just don't use suggestions and one-offs, but now I get it.

[mzso]

So I guess this stalled indefinitely on Mozilla's side, as usual?

[aminomancer]

Maybe, but it's also a less tractable problem than I anticipated. I'm not perfectly happy with my patches, could use another pair of eyes looking really closely at it. It got dissected into a bunch of separate patches but some of them kinda depend on more opinionated changes like changing how the canonization shortcut and the switch-to-tab "action override" shortcut work. I'll try to get it looked at by someone at Mozilla, at least the patch to keep the urlbar view open. If there isn't any progress for a couple weeks, I'll look into how feasible it would be to convert the patches to an autoconfig script. Seems like a pretty huge project but I guess it should be possible

[mzso]

@aminomancer
Yeah, I wasn't hopeful about Mozilla getting (or allowing) stuff implemented. Probably why it didn't occur to me to prompt on Bugzilla.
I was thinking it's not a big as a scirpt if you don't want to deal with every single possible use case. One is not forced to use a UC script. I'm thinking it would be fine if it plainly opened tabs in background without closing the results by resolving whatever's in the urlbar. No particular need to deal with special things like one-off searches and such.

[mzso]

So it looks like this is not happening withing Firefox. As I've come to expect from mozilla, no-one bothered with it (even to review).
Are you still inclined to make an uc.js script to open tabs via alt+enter and middleclick/ctrl+click in a background tab, while leaving the the urlbar/results as they are?

[aminomancer]

I'm pretty busy with work so it's unlikely

[mzso]

@aminomancer commented on Jan 7, 2023, 1:36 AM GMT+1:

I'm pretty busy with work so it's unlikely

Ah, I see. Oh, well...