All users were logged out of Bugzilla on October 13th, 2018
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 In Internet Explorer 6, single-clicking in the URL widget results in selecting the entire URL. The same holds in Firefox. In Internet Explorer 6, double-clicking in the URL widget results in selecting the entire URL. The same DOES NOT hold in Firefox; because in Firefox, double-clicking only selects the current word in the URL. I submit that it is unlikely that anybody would want to only select one word in a URL by double-clicking since most people do this a different way: if somebody is looking to change the text of a URL, (s)he usually does it by using a slow double-click to get the insertion point placed in the right area, and then proceeds by using the arrow keys, backspace, and delete to change the URL to what is desired. This results in substantial annoyance when one is conditioned to the convention in Internet Explorer and other standard Windows applications. I request that this behavior be changed to match the convention or made configurable for those who are accustomed to one particular URL text widget. Reproducible: Always Steps to Reproduce: 1. Try single-clicking and double-clicking in both Firefox and IE URL text widgets. 2. Note that IE and other Windows applications respond identically to single-clicks and fast double-clicks. 3. Note that Firefox responds quite differently, in a way that is not conventional for Windows applications. Actual Results: Firefox selects what it thinks is the nearest "word" contained in the URL. Expected Results: Firefox should have selected the entire URL. This bug has occurred in both the 0.8 Standard theme and the 0.9 standard theme. I normally have UN*X style X-Mouse (focus follows mouse) enabled, but have tried this both ways, resulting in identical widget behavior.
3-clicks selects the whole line. there are plenty of windows programs where doubleclick does not select a line either. (like MS-Word)
Actually, I just tried this in IE 6 on my WinXP system, and double-clicking in the location bar will select just one word, not the entire line. On my Win9x system, however, double-clicking the location bar selects the entire line. So IE 6 seems to be strangely inconsistent in its behavior.
Mr. van der Woude: 3 Clicks does not select the whole line in my version of Firefox on my system. Saying this doesn't work in Word is not comparing apples to oranges because Word's dialog text widgets (which are synonymous with the URL text widget) actually DO follow the convention. The in-document text widget is different, but so is the one in Firefox. This is not surprising. Mr. Warner: IE does not do that on my system.
It's a feature, not a bug. If you want to select the entire address (very common), you can single-click. If you want to select a word (almost as common), you shouldn't have to go through the painful process you described. People only use that process because there's no easier way to select a word in the URL in IE.
Component: OS Integration → Location Bar and Autocomplete
QA Contact: firefox.os-integration → davidpjames
Mr. Ruderman: It is not a feature for me when I am accustomed to another convention that is more standard across Windows applications, which is why I would sincerely appreciate it if this were made configurable. I did not ask that it necessarily be completely changed, thereby causing problems for other users. Also, please note that if one "clicks by" the opportunity to select the whole URL in Firefox, there is no way to cycle through and reselect the whole URL at any point later on, without defocusing from the widget and clicking back, because Firefox has forced you into "word" mode permanently. Please do not attempt to convince me that not following interface precedents set by other applications and not allowing for configuration is the right way to handle this issue because it is obvious that is not the case. I am not asking for much, this should be pretty easy to solve.
> Please do not attempt to convince me that not following interface precedents set > by other applications and not allowing for configuration is the right way to > handle this issue because it is obvious that is not the case. When our behavior can be much better by differing from the standard behavior, we differ. When providing a pref would be ridiculous, we don't provide a pref. Your generalized argument is incorrect.
based on last comment assuming WONT
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.