Closed
Bug 68994
Opened 25 years ago
Closed 25 years ago
urlbar and other dialog text fields can't be selected/clicked in
Categories
(Core :: DOM: Editor, defect, P1)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: bbaetz, Assigned: rubydoo123)
References
Details
(Keywords: regression, smoketest, Whiteboard: FIX IN HAND)
Attachments
(1 file)
|
386 bytes,
patch
|
Details | Diff | Splinter Review |
Sometime today, the urlbar no longer works, and I can't click it to select text.
I can click at the end (but not anywhere else), and delete text.
bryner also sees this, and pinkerton says that smfr was seeing this as well.
URL field no longer detects insertion point when clicked on, meaning
-drag-select no longer works.
-double-click selection no longer works.
-CAN select by using context-menu "select all", but ..
-selection color is missing.
Typing in the field works, and one can maneuvre with arrow-keys.
..and everywhere else. (filepicker, prefs, all dialogs with text input fields..)
Modifying summary.
Summary: urlbar/dialog text field can't be selected/clicked in → urlbar and other dialog text fields can't be selected/clicked in
| Reporter | ||
Comment 5•25 years ago
|
||
Adding smoketest keyword. Backing out akkana's changes to /editor locally didn't
help, but there were other changes to editor as well which I somehow didn't
notice, so I'm reassigning to the default module owner.
Comment 7•25 years ago
|
||
I also see this in my Mac build this morning. One interesting thing I notice is
that it does work in bugzilla forms but not in xul text elements...
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla0.9
Comment 8•25 years ago
|
||
Simon saw this problem from his build yesterday which was pulled around 2:30pm
PST. I have tried backing out several people's checkins from yesterday but
haven't found the culprit yet. Trying hyatt's css changes now (which will take a
while to rebuild).
Comment 9•25 years ago
|
||
since it is still possible to move and type in the text fields, this is not a
blocker.
reducing severity and removing smoketest keyword
Severity: blocker → critical
Keywords: smoketest
Comment 10•25 years ago
|
||
*** Bug 69061 has been marked as a duplicate of this bug. ***
Comment 12•25 years ago
|
||
*** Bug 69067 has been marked as a duplicate of this bug. ***
Comment 13•25 years ago
|
||
*** Bug 69073 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
If hitting delete works, but drag-select with the mouse doesn't, then the
problem is likely not in editor code.
As a data point, I do not see this with my linux build pulled sometime around
10:30am Thursday morning. What platforms has this been seen on (besides Mac)?
When were the builds pulled? Opt as well as debug? Maybe we can narrow down
the time of the checkin that caused this.
I see this on both opt and debug builds on Linux and I first saw it in a build I
pulled at 8:30PM yesterday. I think smfr said he pulled sometime around noon,
but I'm not sure.
| Reporter | ||
Comment 16•25 years ago
|
||
I pulled sometime before the mailnews checkin at 18:05. (I know this because I
repulled to see if it had been fixed, and ran into a compile problem with that
checkin). I only got home just before 7pm Eastern, so I probably pulled sometime
arround 4:30 PST.
Linux debug.
Comment 17•25 years ago
|
||
*** Bug 69089 has been marked as a duplicate of this bug. ***
Comment 18•25 years ago
|
||
*** Bug 69087 has been marked as a duplicate of this bug. ***
Comment 19•25 years ago
|
||
Yesterday's gcc2.95 build, which is has a timestamp of 10:06 on ftp.mozilla.org
didn't have this problem (I pulled it shortly after midday CST)... today's does.
Comment 20•25 years ago
|
||
Just wanted to add that the problem started for me when I downloaded the first
nightly that was uploaded on Thursday 15 in the morning PST for win32.
Comment 21•25 years ago
|
||
i dont see this on a moz mac debug build from a pull of midnight on thursday
night.
Comment 22•25 years ago
|
||
*** Bug 69152 has been marked as a duplicate of this bug. ***
Comment 24•25 years ago
|
||
*** Bug 65275 has been marked as a duplicate of this bug. ***
Comment 25•25 years ago
|
||
this is really bad, blocker.
Severity: critical → blocker
Keywords: smoketest
Comment 26•25 years ago
|
||
In xul.css, try taking this line:
textfield[autocomplete="true"] {
-moz-binding: url(chrome://global/content/autocomplete.xml#autocomplete);
}
and adding to it...
textfield[autocomplete="true"] {
-moz-binding: url(chrome://global/content/autocomplete.xml#autocomplete);
-moz-user-select: text;
}
Comment 27•25 years ago
|
||
Doesn't seem to help in my build.
This seems to have been caused by revision 1.44 of xul.css, checked in by
hyatt%netscape.com with comment "Not part of build." Hmmm.
Comment 29•25 years ago
|
||
I traced into nsFrame::HandlePress() in nsFrame.cpp and the cause is this:
// check whether style allows selection
// if not, don't tell selection the mouse event even occurred.
PRBool selectable;
PRUint8 selectStyle;
rv = IsSelectable(&selectable, &selectStyle);
if (NS_FAILED(rv)) return rv;
// check for select: none
if (!selectable)
return NS_OK;
"selectable" is false, so we abort here
Comment 30•25 years ago
|
||
Comment 31•25 years ago
|
||
Good work David! That definitely caused this problem. r=cmanske or r=dbaron if
you want me to check it in.
Anyone want to sr=?
Whiteboard: FIX IN HAND
As I was saying before lots of mid-air collisions... I think we should backout
hyatt unless someone comes up with another fix in the next few minutes, so that
we get this bug off the radar and hyatt can figure out the problem at his
leisure. Backing out that one-line change doesn't seem to show any ill effects
in my tree.
Comment 33•25 years ago
|
||
sure. a=ben@netscape.com for this removal until hyatt can figure out why
textfields aren't working.
Marking this bug as fixed, since the change is checked in. Filed bug 69184 on
hyatt to remind him to reinstate the backed-out change once he's fixed the
problems it caused.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
| Reporter | ||
Comment 35•25 years ago
|
||
*** Bug 69181 has been marked as a duplicate of this bug. ***
Comment 36•25 years ago
|
||
*** Bug 69224 has been marked as a duplicate of this bug. ***
Comment 37•25 years ago
|
||
*** Bug 69257 has been marked as a duplicate of this bug. ***
Comment 38•25 years ago
|
||
Yes ,thanks for backing me out. I did not mean to check that patch into the build.
Comment 39•25 years ago
|
||
*** Bug 69232 has been marked as a duplicate of this bug. ***
Comment 40•25 years ago
|
||
*** Bug 69237 has been marked as a duplicate of this bug. ***
Comment 41•25 years ago
|
||
*** Bug 69297 has been marked as a duplicate of this bug. ***
*** Bug 69301 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•