To try the thousands of add-ons available here, download Mozilla Firefox, a fast, free way to surf the Web!Close
Choose from thousands of extra features and styles to make Firefox your own.Close
|User since||July 20, 2011|
|Number of add-ons developed||0 add-ons|
|Average rating of developer's add-ons||Not yet rated|
> Another solution could be for Omnibar to accept a set of
> comma separated values that point to a URL in its preference
> that should perform default action instead of performing a
That would of course fall under "an configurable exception list or something similar" and therefore be a more than adequate solution ;) I wuold really appreciate something like that.
Advanced Settings (policies or whatever they're called in english version of this addon) seem to bebuggy in FF5. New policies are not saved. Can anyone confirm this?This user has a previous review of this add-on.
Advanced Settings (policies or whatever they're called in english version of this addon) seem to bebuggy in FF5. New policies are not saved. Can anyone confirm this?
Liked this addon since I discovered it about a year ago. Used Peers before but I never was really happy with that... So glad I found Omnibar.Reason I'm now writing this is a little annoyace I discovered a few days ago using Omnibar: Recoginzing if something entered in the Awesomebar is a URL or not seems Pattern-based. So anything wich does not have a Standard-TLD is not recognized as an URL, even if it were reachable in the local network... Example:Configuration interface of Fritz!Box Routers is reached via HTTP via the URL "fritz.box". This is not recognized by omnibar as an URL, so a search is started using the default searchengine.You could of course go round this by typing a fully qualified URL with the protocol in front, e.g. "http://fritz.box" - but this requires uneccessary extra-typing.So my question: is there any possibility to detect if an URL could be resolved to an IP and only starting a search if it could not be resolved? Or, even better, test if an URL is reachable via HTTP and start a search if it's not?If this is not possible, can you at least try to improve the pattern you use to recognize URLs? Of course it's not possible to successfully detect local URLs as they can basically be anything, even a single name (as for example "localhost" is, but that seems to work), but what about an configurable exception list or something similar?
[Edit]: Just worte the comment by Nestik from July, 15th. Seems he (or she) had the same problem. Tried "fritz.box/" instead and ir worked - but stilll it's unneccessary extra-typing. And it MAY (although I can not post an evicence for that as I'm to lazy to reconfigure my local webserver) not function if the local server you try to reach has a configuration wich does not treat the root directory as a directory but redirect somewhere else instead (apache mod rewrite can do this for example) and does not recognize the / at the end (of course this would be something you could change in the webservers config easily, but you have to do it).So as more people seem to have this prolbem with local URLs, would you think about the suggestions I made?
[Edit2]: thinking about it, I figured out another possbile solution for this. As (as you yourself point out in the addon description) everything works as expected if you disable the "default search" I came up with this: the only thing you loose disabling "default search" is the ability to seelct the serch engine wich is used for searches if you give no search-operator and the default search engine is used if the URL could not be resolved (or reached?), regardless of which search engine is selected in omnibar. But: the default search is stored in a pref: keyword.URL (or at least this value should be used). So why not change this pref everytime you select a searchengine in omnibar, so the "default search" implemented now would be obsolete? Of course search suggestions are still missing than... have to find a way.