Smart keywords, "window.location.hostname" and new tabs about uc.css.js HOT 7 OPEN

Yeah I see what you mean. It's a good point, this is a very unfortunate limitation of the javascript scheme feature. So, it's not quite ignoring the hostname part, more like the hostname is just evaluating to an empty string. So that javascript location.href=('http://www.google.com/search?q=site:'+window.location.hostname+'%20%s') is basically saying to combine the string http://www.google.com/search?q=site: with the value of window.location.hostname and then append the string %20%s which is a space + the search string.

The problem is that the target browser (a new tab) is empty at the time this property's value is evaluated. Instead of checking the current browser's location, it's creating a new tab first, then loading the bookmark URL into it, which is parsing the javascript encoded in the URL, and that javascript is then checking the current browser's location — from within the new tab, where it's running. So because the javascript is loaded inside the context of a new tab instead of the current browser, the window refers to a completely different object with a different location property. Not really a simple way around this because the whole "opening a new tab" thing is way upstream of the execution of the JS code inside the bookmark URL. The sequence basically goes

1. Hit Enter
2. Open new tab
3. Load parsed URI in the new browsing context
4. Parsed URI is of javascript scheme...
5. Evaluate the "path" of the URL string in the new browser
6. That javascript evaluation references window.location.hostname which, from this execution context, refers to the empty browser we just opened. So it returns "" (empty string)
7. The javascript further sets location.href equal to 'http://www.google.com/search?q=site:'+''+'%20%s'
8. We therefore load http://www.google.com/search?q=site:%20%s which means the google input field should say site: {search string}

When you just hit Enter, you're basically executing the javascript in the current selected tab. So location.hostname returns the hostname for the current browser's doc. But when you use a modifier key, you're causing it to open the result in a new tab/window, which means a new browser. And the javascript URL is evaluated in the browsing context associated with that new browser. So at the time of execution it's gonna be an empty string I believe.

There might be solutions or workarounds though. It might seem like we could just change the behavior in some way so that these URLs are parsed in the parent process or something. The main issue I see is that we can't make assumptions about where the execution should happen. Even in just this one example, we need to execute inside the browser in which the content should load, because that's how the google search is initiated. See where it says location.href=...? That's how it's launching google. It just means change the URL to the following string.

But we can't have it both ways. For that to successfully change the URL of the new browser, it needs to be executed inside the new browser. But that means when we query location.hostname we're going to get the hostname for the new browser. So you can see the problem. We're asking for information about the current browser's location and then we're trying to use that information to set a new browser's location. So those would need to refer to the location property of 2 different window objects. But that's not possible from within the very restrictive context in which these javascript URLs run.

Technically I think it's possible to write a keyword bookmark in such a way that it will open a new tab, but that wouldn't have anything to do with whether a modifier key is pressed. It would just be the normal behavior of the bookmark. And that would be done by using something like javascript:window.open('http://www.google.com/search?q=site:'+window.location.hostname+'%20%s', '_blank'); location.href = location.href;. Unfortunately that reloads the current tab in addition to opening a new tab, which sucks. I don't think that's avoidable since this relies on a new URI being loaded in the first place.

Overall I just don't think the keyword bookmark feature is very practical for this kind of feature. I think an extension would have a much easier time doing something like this, though address bar extensions are quite rare. It would also be possible to make something like this with autoconfig, but it would need to be incredibly sophisticated to integrate with the urlbar. We'd need to basically let the user create a "bookmark" whose only content is parent-process JS instructions. That way we can create all the parameters before even making a new tab. But that would be quite a project. A new urlbar result provider, a new UI for creating templates, etc. I don't think I'll have enough down time to produce and maintain something so massive by myself.

I'll show this to a few people and see what they think. This is a pretty open-ended idea so I'm sure there are lots of possibilities I'm not thinking of.

from uc.css.js.

Hey let me know if this new script does what you're looking for. You can use the same keyword bookmark, but just replace the URL field with this:

ucjs:let where = gURLBar._whereToOpen(event); openWebLinkIn("https://www.google.com/search?q=site:" + gBrowser.currentURI.host + " %{searchString}", where);

from uc.css.js.

Here try this instead. I improved the keyword code so it should feel more professional

ucjs:let where = gURLBar._whereToOpen(event); let typedValue = "%{searchString}"; let {host} = new URL(gBrowser.currentURI.spec); let pathString = typedValue.trim().length ? "/search?client=firefox-b-1-d&q=" : ""; let hostString = pathString && host && ["https", "http"].includes(gBrowser.currentURI.scheme) ? "site:" + host + " " : ""; gURLBar.handleRevert(); gURLBar.blur(); openWebLinkIn("https://www.google.com" + pathString + hostString + typedValue, where);

from uc.css.js.

Remind me to look into setting custom favicons for ucjs: bookmarks. I assume they are seeking icons with page-icon: or moz-anno:favicon: and since these aren't really URLs, we just get a default globe favicon. Ideally we'd intercept the creation of the bookmark somehow and give it a custom icon if it matches /^ucjs:/, like the console icon I set for the ucjs: urlbar results. Not sure if that's possible and I gotta crash but I'll look into that when I get a chance.

note: PlacesUIUtils.loadFavicon

from uc.css.js.

Thank you so much for your well-explained and well-defined spot on explanation.

from uc.css.js.

Man, you are a LEGEND! Thank you so much!!! It worked flawlessly :)

from uc.css.js.

Great 😊

from uc.css.js.