BUILD: current trunk build (but this code has been around for a while...) STEPS TO REPRODUCE: 1) Make sure that you're running X (so highlighting text puts it in PRIMARY) 2) Load testcase (or URL in URL field) 3) Click in the textfield EXPECTED RESULTS: Text in textfield you click in is selected, but NOT in PRIMARY ACTUAL RESULTS: Text makes its way into PRIMARY Note: If the select() call is done in onclick, not onfocus, the bug is not present. So something is getting confused about the difference between user-initiated selections and scripted selections. I've not succeeded in getting this to reproduce by clicking outside the input yet, but making a 0.0001-opacity input (which _would_ receive the click) track the mouse pointer so it's below whereever the user clicks on the page is an easy DHTML exercise. Quite apart from the security implications, this makes the bugzilla sidebar a pain to use -- any time I do a search with it it stomps on my PRIMARY.
Brian, any idea on this?
Nominating this. Having pages be able to place arbitrary data into the clipboard is a problem. We really shouldn't ship any more releases with this.
Assignee: selection → pavlov
This isn't an X clipboard issue. This is a problem with the selection code. Presumably the code in http://lxr.mozilla.org/seamonkey/source/layout/generic/nsSelection.cpp#7424 shouldn't get called in this case...
daniel, or bryner (or bz) can any of you help with this? Is this even fixable?
It should be fixable, yes. I can't help until I get back. Then I wouldn't know where to start. Had I known where to even start looking at fixing this bug, I would have had it fixed months ago -- this bug is a serious issue for my daily bugzilla use...
14 years ago
Assignee: selection → dbaron
Target Milestone: --- → mozilla1.8beta3
That the event matters makes me suspect something funny with PostReason and PopReason, although I'm also somewhat suspicious of the SELECTALL_REASON check and the distinction between selection operations that post SELECTALL_REASON vs. NO_REASON.
Actually, I don't think it's either; just that the script runs first and the selection code tests whether the selection is collapsed rather than whether it created the non-collapsed selection.
Maybe nsSelection::HandleClick shouldn't call PostReason.
But really PostReason/PopReason are broken and the reasons should be passed as function arguments...
(In reply to comment #10) > But really PostReason/PopReason are broken and the reasons should be passed as > function arguments... Well, I just tried a patch to do this, and it actually didn't help.
Assignee: dbaron → bzbarsky
Flags: blocking1.9a1? → blocking1.9-
Summary: Page can stomp on clipboard by calling select() at the right time → Page can stomp on PRIMARY clipboard by calling select() at the right time
Whiteboard: [wanted-1.9] [sg:moderate] → [sg:moderate]
The testcase doesn't work for me in Fx 3. Is this still a valid bug? Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0
Disregard comment 13. Boris helped me understand the testcase better and the distinction between PRIMARY and CLIPBOARD. The bug is definitely still valid.
Priority: -- → P2
Target Milestone: mozilla1.8beta3 → ---
It looks like a variant of Bug 55437.
No, not the same. In this case, the text being selected is in fact what ends up in the PRIMARY... it's just not the _user_ who selected it.
For me the text is just selected but not copied to PRIMARY. (Fedora13/x86_64/FF3.6.8)
It's entirely possible this got fixed somewhere along the line. I'll double check when I get the chance.
I think this did get "fixed" at some point a few versions back, which broke sites like Google Maps since there's no longer any way of selecting the link text for the current map. Any field that calls select() from onclick becomes unselectable. See bug 926257 for details and test cases.
Hallvord, does the clipboard spec say anything about this, or should it?
No, this seems outside the scope of the clipboard spec. Also, in reply to comment 19, I don't think any intentional or unintentional "fix" for this caused bug 926257 - that's probably a separate bug that might mask this.
Created attachment 8569263 [details] [diff] [review] hack We could mark the selection as "tainted" if a script modifies the selection between mouse-down/mouse-up and notify that as a change- by-script rather than a change-by-user. Then the copy to PRIMARY thing does not occur. Or some variation thereof. (this hack seems to fix the bug for me locally, although I haven't tested if it breaks anything else)
You need to log in before you can comment on or make changes to this bug.