User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150514102509 Steps to reproduce: I tried to use DNS aliases for our company internal websites. Actual results: Instead of resolving the aliases, the aliases were searched with the default browser. Expected results: In my opinion, as Firefox ESR is primarily meant for companies and not individual users, aliases should be resolved first before searching the term on the internet in Firefox ESR. This behavior has changed between Firefox ESR 31 and Firefox ESR 38.

ERRATA: Actual results: Instead of resolving the aliases, the aliases were searched with the default *search engine*.

"jira" alias searched with the default search engine instead of resolving it. http://jira however resolves the DNS alias.

Lawrence, what are our criteria for having different prefs specifically for ESR?

We can specify different prefs for ESR (for ex, Hello and EME are disabled in ESR38). Our preference is to keep ESR as close to mainline Firefox as possible. I don't think it's correct to say that ESR is primarily for companies. It is an extended support release for organizations that includes for profit, not for profit, and education. I don't know the preferences of all of these orgs but this is the first bug report that I've seen about this. Before we flip a pref, I suggest that we poll on the enterprise list. As an alternative to setting a global default, is there a way for an individual organization to revert this behaviour?

Thank you for looking into this. :) @Lawrence: Yes, my wording was not correct, "Organizations" is what I meant. I was just wondering how you decided to switch this setting in the first place, did you also organize a poll to switch it in order to evaluate its impact on organizations (this setting has been changed globally somewhere between versions 31 and 38)? My point is, I did not see extensive information about switching this setting in the first place. I was confronted with it when I ordered a new package to our partner company and observed a behavior change. I know you did this to improve the performance for standard Firefox users, but as soon as you work in an organization which has a domain and aliases, you break the standard behavior for resolving DNS aliases. Yes, there is still the solution to put http:// in front of the alias which resolves it correctly, but it is a noticeable change which, again in my humble opinion, shouldn't have been made so lightly for ESR. And to answer your question: yes, the setting in the title of this post is the way to revert the this behavior for individual organizations.

(In reply to Patrick Althaus from comment #5) > Thank you for looking into this. :) > > @Lawrence: > > Yes, my wording was not correct, "Organizations" is what I meant. > > I was just wondering how you decided to switch this setting in the first > place, did you also organize a poll to switch it in order to evaluate its > impact on organizations (this setting has been changed globally somewhere > between versions 31 and 38)? The setting didn't exist in 31, so it is not so much that we "switched a setting" - we implemented this feature in bug 693808 and then added the pref in bug 1088050. At the point where I added the pref, I did not think about ESR (nor, frankly, was I aware we even shipped that with different defaults). > My point is, I did not see extensive information about switching this > setting in the first place. Where did you look for this information? The bug was relnoted for Firefox 33, though I suppose you could have missed it considering the (purposefully) non-technical description (https://www.mozilla.org/en-US/firefox/33.0/releasenotes/ - "Improved search experience through the location bar"). Maybe we should consider doing a technical version of these notes. :-\ > I know you did this to improve the performance for standard Firefox users, > but as soon as you work in an organization which has a domain and aliases, > you break the standard behavior for resolving DNS aliases. Right. Not all organizations use domains and aliases in this way, or with a sufficient number of websites to make it worth turning this behaviour off, though. Especially on Windows, the slowdown for single-word searches in on the order of several seconds, depending on how slow your DNS is to respond. That is really terrible UX, so we fixed what we considered a bug in our search detection code. > Yes, there is > still the solution to put http:// in front of the alias which resolves it > correctly You could also use whatever enterprise method you use to stick Firefox on users' machines to extend the host whitelist for this feature (which just has localhost by default). Or just let the users in question click the notification bar that comes up ("Did you mean to go to foo?"), which will also whitelist that host for the future. > but it is a noticeable change which, again in my humble opinion, > shouldn't have been made so lightly for ESR. Again, we didn't explicitly change something for ESR. ESR 38 is essentially the same as "regular" Firefox 38, as much as possible, and we make explicit changes for ESR if/when the need arises. Lawrence, can you write the email to the esr list for this? Let me know if you need help phrasing bits of it or if anything is still unclear.

Hi Gijs Thanks for your extensive reply. :) > Where did you look for this information? The bug was relnoted for Firefox > 33, though I suppose you could have missed it considering the (purposefully) > non-technical description > (https://www.mozilla.org/en-US/firefox/33.0/releasenotes/ - "Improved search > experience through the location bar"). Maybe we should consider doing a > technical version of these notes. :-\ Honestly, I would have missed the info anyway as we have a whole back-end outsourcing project running at the time. However, some technical release notes would be very useful and welcome. > Right. Not all organizations use domains and aliases in this way, or with a > sufficient number of websites to make it worth turning this behaviour off, > though. Especially on Windows, the slowdown for single-word searches in on > the order of several seconds, depending on how slow your DNS is to respond. > That is really terrible UX, so we fixed what we considered a bug in our > search detection code. I totally agree with you on a private level, however the weighting of such decisions may be worth to be put into perspective and to be reconsidered for "... groups who deploy and maintain the desktop environment in large organizations such as universities and other schools, county or city governments and businesses." (Scope definition of Firefox ESR). > You could also use whatever enterprise method you use to stick Firefox on > users' machines to extend the host whitelist for this feature (which just > has localhost by default). Or just let the users in question click the > notification bar that comes up ("Did you mean to go to foo?"), which will > also whitelist that host for the future. Our company IT software distribution policy states that user interaction must be avoided during distribution and the software must be pre-configured. This means that the whitelisting (maintaining another list is to be avoided) and clicking (each company user would have to do it for each alias) are no options. In the end, I have a solution with the setting written in the bug subject and I ordered a new package with that setting configured. I just find it interesting to give some thoughts about the configuration of Firefox "standard" compared to Firefox ESR which definitely targets another user group (which I applause and welcome by the way ;)). So for me the case can be closed. :)

(In reply to Patrick Althaus from comment #7) > So for me the case can be closed. :) Thank you for your thoughtful comments Patrick. I think we should resolve this bug as wontfix at this point because our preference is to keep ESR as close to mainline Firefox as possible (to limit maintenance costs) and because we only have a single report for this issue. If this issue becomes more pervasive with the ESR audience we should then follow up with a post to the enterprise list and consider whether to flip the pref by default. Gijs - Does this work for you?

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #8) > (In reply to Patrick Althaus from comment #7) > > So for me the case can be closed. :) > > Thank you for your thoughtful comments Patrick. > > I think we should resolve this bug as wontfix at this point because our > preference is to keep ESR as close to mainline Firefox as possible (to limit > maintenance costs) and because we only have a single report for this issue. > If this issue becomes more pervasive with the ESR audience we should then > follow up with a post to the enterprise list and consider whether to flip > the pref by default. > > Gijs - Does this work for you? I feel bad because I think my response to Patrick was probably on the defensive side, and certainly less thoughtful then his response to mine. Notwithstanding my earlier comments, I expect that for medium-large enterprises with N+ (*) of these servers that they'd like to access by just typing "bugzilla" or "jira" or "mail" or whatever in their address bar, turning this off is probably the right thing. (*) don't ask me what N is. Maybe 10, or 20. I dunno how quickly people get bored of clicking the buttons on those notification bars. For everybody else, I would lean towards not changing it. What that means for ESR then depends on three things, I think: 1) how many users are in the circumstance where this feature is hurting them (ie they want the pref flipped by default) and how many are happy with this feature (don't want the pref flipped) 2) how do those groups correlate with an environment where it's easy for the IT/admin folks to distribute copies with the pref changed if they want to (it tends to be easier in larger corps because they have more infrastructure to deploy software, making it easier to deploy a custom package, rather than in small places that do not have said infra and manually download and customize, or something). 3) how heavily do we lean towards "don't want to change from mainline Firefox". While I am not yet convinced that toggling the pref for all ESR users is right, asking on the list doesn't seem like it would hurt (though I don't know how that list is skewed and how we would come to a decision either way). Sorry for my indecisiveness here. I'm just aware that my personal bias skews towards the individual side of the spectrum (and the "if you're a big org, you will need to do stuff to your Firefox anyway"). That shouldn't be the deciding factor, though. :-) I also suspect that asking might be positive because even if we decide against changing anything, there will be a reasonably public announcement that indicates 38 is doing this, and some orgs may need to adjust because of this.

LOL I'm perfectly comfortable with any decision as long as it is justified and useful to the community. And I also perfectly understand and support your strategy of standards and your wish to improve transparency on this topic. Thank you for this constructive debate. :) Greetz