Open
Bug 59999
Opened 24 years ago
Updated 4 years ago
Address Bar Does Not Keep Selection When Leaving Mozilla
Categories
(Core :: DOM: Selection, defect, P5)
Tracking
()
NEW
Future
People
(Reporter: lloy0076, Unassigned)
Details
(Keywords: platform-parity)
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.17 i686)
BuildID: Mozilla 17 to 18
When you have highlighted an address in the address bar and you leave Mozilla,
the highlight just vanishes. This doesn't happen in ANY of my other programs
(including Netscape) and it breaks the "highlight a piece of text and use the
third mouse button to paste it somewhere else" under X.
Reproducible: Always
Steps to Reproduce:
1. Highlight some text to copy (eg a URL from Netscape)
2. Tab out or move the cursor out of mozilla
Actual Results: See the description.
Expected Results: Make sure the highlight is sticky.
I'm running XFree86-4.0.1 but it used to happen under 3.3.6 as well...under RH
6.2.
Comment 1•24 years ago
|
||
->XPToolkit/widgets
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Toolkit/Widgets
Ever confirmed: true
Comment 2•24 years ago
|
||
Reporter, you are using a _very_ old build if it's between M17 and M18! Do you
see this problem with newer builds?
Mozilla-Source-20002510.tar.gz...I'm not sure whether it still exists at the
moment however I don't judge it as a problem that will just go away without
looking. I'll download the latest soonish...
Comment 4•24 years ago
|
||
The reason I ask is that it works just fine for me under linux... :)
RedHat 6.2, XFree86-4.0.1, kernel 2.2.16.
So two things:
1) Try with a new build
2) Try with a new build _and_ a fresh profile (just do 'mv ~/.mozilla
~/dot-mozilla-old' or something like that...
Thanks for using Mozilla and reporting bugs!
Comment 5•24 years ago
|
||
Worksforme with 110308 mozilla trunk build on redhat 6.2
I have just cvs updated at about 5:44 pm Australia CST Summer Time. The issue is
still there. If it occured with other windows and programs I would assume that
it is a "Windows Manager" issue but it doesn't so I can only assume that Mozilla
isn't behaving the way I, at least, would expect it to.
Comment 7•24 years ago
|
||
Have you tried a fresh profile?
This sounds like a Selection bug, not a XPToolkit/Widgets bug, by the way...
I removed .mozilla as suggested. It still occurs...
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 10•24 years ago
|
||
um... i presume you did not mean to resolve this if it still happens?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 12•24 years ago
|
||
Reassign bug to owner of selected component
Assignee: asa → mjudge
Status: REOPENED → NEW
QA Contact: doronr → blakeross
Updated•24 years ago
|
Assignee: mjudge → anthonyd
Target Milestone: --- → mozilla0.9.1
Comment 13•24 years ago
|
||
setting to moz0.9 and reassign to anthonyd, cc akkana for input
Comment 14•24 years ago
|
||
In today's build, I do see the selection color disappear (not go grey, but go
back to the default, so it looks like nothing is selected) when I mouse out of
the window, which is a regression and should not happen. Whatever was selected
still is, though -- I can middlemouse-paste into other windows with no problem.
It's just the appearance of the selected text in text controls which is the
problem. Might be a change in the content style sheets ...?
Comment 15•24 years ago
|
||
move to mozilla 0.9.2
shorten summary just to one issue
Does this happen in any editfield or just in the urlbar or ?
Keywords: pp
Summary: Address Bar Does Not Keep Selection When Leaving Mozilla, nor is "copy" enabled in the edit menu when it is highlighted even though "ctrl-c" does actually work, same goes with "paste" → Address Bar Does Not Keep Selection When Leaving Mozilla
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 17•23 years ago
|
||
after reading this bug report i am very confused. i got boris saying it
worksforme, and akkana saying it works fine but looks a little wierd and that
maybe its a style problem. is this a real bug?
my poor brain :-(
anthonyd
Status: NEW → ASSIGNED
Comment 18•23 years ago
|
||
I see the behavior akkana is describing in today's build too. ccing dbaron --
this looks like a system color issue.
Comment 19•23 years ago
|
||
BTW, what I described (which still happens) seems exactly the same as what the
original poster reported: the highlight vanishes (it goes back to the normal
unselected color). The original poster wasn't complaining that the X selection
went away, but that the visual indication of selection went away. I'd be happy
to demonstrate if that might help clear up the confusion.
Comment 21•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 24•20 years ago
|
||
This Worksforme in Windows 2000
Updated•15 years ago
|
Assignee: mjudge → nobody
QA Contact: tpreston → selection
Comment 25•4 years ago
|
||
Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.
If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.
Severity: minor → S4
Priority: P3 → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•