Open
Bug 265868
Opened 20 years ago
Updated 1 year ago
Page can stomp on PRIMARY clipboard by calling select() at the right time
Categories
(Core :: DOM: Selection, defect, P3)
Tracking
()
NEW
People
(Reporter: bzbarsky, Unassigned)
References
()
Details
Attachments
(2 files)
298 bytes,
application/vnd.mozilla.xul+xml
|
Details | |
11.93 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•20 years ago
|
||
Brian, any idea on this?
Reporter | ||
Comment 2•19 years ago
|
||
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.
Flags: blocking1.8b3?
Updated•19 years ago
|
Flags: blocking1.8b3? → blocking1.8b3+
Comment 4•19 years ago
|
||
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...
Updated•19 years ago
|
Assignee: pavlov → selection
Comment 5•19 years ago
|
||
daniel, or bryner (or bz) can any of you help with this? Is this even fixable?
Reporter | ||
Comment 6•19 years ago
|
||
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...
Updated•19 years ago
|
Flags: blocking1.8b4+
Flags: blocking1.8b3-
Flags: blocking1.8b3+
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.
Updated•19 years ago
|
Flags: blocking1.8b5+ → blocking1.8b5-
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.9a1?
Updated•18 years ago
|
Assignee: dbaron → bzbarsky
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
Updated•18 years ago
|
Whiteboard: [wanted-1.9] → [wanted-1.9] [sg:moderate]
Updated•17 years ago
|
QA Contact: selection
Updated•17 years ago
|
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
Updated•16 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9] [sg:moderate] → [sg:moderate]
Comment 13•16 years ago
|
||
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
Comment 14•16 years ago
|
||
Disregard comment 13. Boris helped me understand the testcase better and the distinction between PRIMARY and CLIPBOARD. The bug is definitely still valid.
Reporter | ||
Updated•14 years ago
|
Priority: -- → P2
Target Milestone: mozilla1.8beta3 → ---
Comment 15•14 years ago
|
||
It looks like a variant of Bug 55437.
Reporter | ||
Comment 16•14 years ago
|
||
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.
Comment 17•14 years ago
|
||
For me the text is just selected but not copied to PRIMARY. (Fedora13/x86_64/FF3.6.8)
Reporter | ||
Comment 18•14 years ago
|
||
It's entirely possible this got fixed somewhere along the line. I'll double check when I get the chance.
Reporter | ||
Updated•14 years ago
|
Priority: P2 → P3
Updated•12 years ago
|
Keywords: sec-moderate
Updated•11 years ago
|
Assignee: bzbarsky → bugs
Comment 19•11 years ago
|
||
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.
Comment 20•9 years ago
|
||
Hallvord, does the clipboard spec say anything about this, or should it?
Flags: needinfo?(hsteen)
Comment 21•9 years ago
|
||
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.
Updated•9 years ago
|
Flags: needinfo?(hsteen)
Comment 22•9 years ago
|
||
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)
Comment 23•3 years ago
|
||
We reviewed in DOM sec triage and think that this is not a sec bug. Martin, do you agree?
Flags: needinfo?(stransky)
Comment 24•3 years ago
|
||
Nika tested and said Chrome also reproduces. She used
data:text/html,<input value="hello, world" onfocus="this.setSelectionRange(0,this.value.length)">
Comment 25•3 years ago
|
||
(In reply to Neha Kochar [:neha] from comment #23)
We reviewed in DOM sec triage and think that this is not a sec bug. Martin, do you agree?
Agreed.
Flags: needinfo?(stransky)
Updated•3 years ago
|
Comment 26•1 year ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Severity: critical → --
Updated•1 year ago
|
Severity: -- → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•