Closed
Bug 231381
Opened 21 years ago
Closed 21 years ago
Alt+D no longer selects all text in Location Bar -- it moves cursor to the end of the text there
Categories
(Firefox :: Toolbars and Customization, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ali, Assigned: p_ch)
References
()
Details
(Keywords: regression)
Attachments
(1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040118 Firebird/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040118 Firebird/0.8.0+
Alt+D no longer selects the entire URL in the location bar. It merely moves the
caret focus to the end of the URL in the location bar.
Reproducible: Always
Steps to Reproduce:
1. Press Alt+D (while on any site that doesn't remap Alt+D to something else)
2.
3.
Actual Results:
Caret focus is moved to the end of whatever URL or text is in the Location Bar
Expected Results:
The entire contents of the Location Bar should be selected so that they can be
overwritten by immediately typing.
Reporter | ||
Comment 1•21 years ago
|
||
Confirming bug on:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040118 Firebird/0.8.0+
The bug has been introduced in the last day, because the following build worked
fine for me:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040117 Firebird/0.8.0+
--> All/All
OS: Windows XP → All
Hardware: PC → All
Updated•21 years ago
|
Keywords: regression
Comment 2•21 years ago
|
||
This checkin appears to be the cause:
http://bonsai.mozilla.org/cvsquery.cgi?date=explicit&mindate=01%2F17%2F2004+22%3A20%3A00&maxdate=01%2F17%2F2004+22%3A20%3A00
Comment 3•21 years ago
|
||
I also see this bug if I click the address bar.
pch checked that in, so assigning to him.
pch's patch looks correct except that it mixes #ifdef with #elif. It should use
#if and #elif, or #ifdef and #elifdef. I don't know if using the wrong
preprocessor command would cause this bug.
Assignee: hyatt → p_ch
Comment 4•21 years ago
|
||
I tried changing it to #elifdef, and still got two gClickSelectsAll lines in the
output (first is true, second is false). I think this is likely a pre-processor bug.
When it reaches the elifdef, it takes the true value off (if we're on Windows,
of course), and pushes false onto it's stack
(http://lxr.mozilla.org/mozilla/source/config/preprocessor.pl#350). Then, when
it gets to the #else, it simply assumes that inverting the stack's value is
correct (http://lxr.mozilla.org/mozilla/source/config/preprocessor.pl#334).
I don't know if this is expected behaviour, but it seems wrong to me.
Comment 5•21 years ago
|
||
Reporter | ||
Comment 6•21 years ago
|
||
Pierre has checked in a fix for Windows (and I've confirmed that it works):
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/base/content&command=DIFF_FRAMESET&file=browser.js&rev1=1.267&rev2=1.268&root=/cvsroot
We still need a fix for Linux. Am setting bug to All/Linux.
OS: All → Linux
Reporter | ||
Comment 7•21 years ago
|
||
Comment on attachment 139399 [details] [diff] [review]
Repaces #elif usage with only #ifdef/#else/#endif
Making patch obsolete, since Pierre has already checked in an equivalent fix.
Attachment #139399 -
Attachment is obsolete: true
Assignee | ||
Comment 8•21 years ago
|
||
James: sorry, I haven't seen your patch
that's fixed on linux (branch+trunk) as well, but please, test well the *branch*
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
QA Contact: bugzilla → toolbars
You need to log in
before you can comment on or make changes to this bug.
Description
•