Closed Bug 393828 Opened 17 years ago Closed 17 years ago

double clicking the url in the location bar looks like it places the text in the X selection but doesn't

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3 alpha8

People

(Reporter: karlt, Assigned: dao)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

cleaned patch
3.28 KB, patch
Details | Diff | Splinter Review
Steps to reproduce: 1 - Drag-select a portion of the url in the location bar. (The portion is highlighted.) 2 - Double click the url in the location bar. (The whole url is highlighted.) 3 - Open a new tab. 4 - Press mouse button 2 with the pointer over the location bar. Expected results: * The whole url from 2 is pasted. Actual results * Only the portion of the url from 1 is pasted. (Mysteriously triple-clicking selects the whole url.) Worked as expected in granparadiso-alpha7. Regressed by 2007-08-05-04-trunk.
The bug apparently showed after checkin from bug 190615.
Blocks: 190615
How does Firefox 2 behave if you set browser.urlbar.clickSelectsAll to true?
(In reply to comment #2) > How does Firefox 2 behave if you set browser.urlbar.clickSelectsAll to true? > The first click behaves similarly: it looks like it selects the whole url, but doesn't modify the X selection. Subsequent double-clicking places the text in the X selection.
I guess it's a Core:Selection bug then. Or, if textbox.select() is not expected to write to the X selection, we have a design problem. I don't know a way to do that kind of copying explicitly from script.
If I read this code correctly: http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLInputElement.cpp#1359 http://lxr.mozilla.org/seamonkey/source/layout/forms/nsTextControlFrame.cpp#1895 calling select() from JS is not supposed to overwrite the current X selection. See also bug 226853 for the browser.urlbar.clickSelectsAll behaviour.
Depends on: 226853
textbox.select() called by an untrusted web page should not write to the X selection, IMO.
Sure thing. But would a different policy for chrome make sense? If not, how about an explicit scriptable method?
Assignee: nobody → dao
Attached patch patch (obsolete) — — Splinter Review
Attachment #278656 - Flags: review?(mano)
Blocks: 226853
No longer depends on: 226853
Comment on attachment 278656 [details] [diff] [review] patch >Index: browser/base/content/urlbarBindings.xml >=================================================================== >RCS file: /cvsroot/mozilla/browser/base/content/urlbarBindings.xml,v >retrieving revision 1.19 >diff -u -8 -p -r1.19 urlbarBindings.xml >--- browser/base/content/urlbarBindings.xml 27 Aug 2007 18:05:40 -0000 1.19 >+++ browser/base/content/urlbarBindings.xml 28 Aug 2007 21:58:29 -0000 >@@ -433,17 +433,18 @@ > </method> > > <method name="handleEvent"> > <parameter name="aEvent"/> > <body><![CDATA[ > if (aEvent.type == "mousedown" && > aEvent.button == 0 && aEvent.detail == 2 && > this.doubleClickSelectsAll) { >- this.inputField.select(); >+ this.inputField.QueryInterface(Components.interfaces.nsIDOMNSEditableElement) >+ .editor.selectAll(); or just this.editor.selectAll() (inherited from the textbox binding), in both places. r=mano otherwise.
Attachment #278656 - Flags: review?(mano) → review+
Attached patch cleaned patch — — Splinter Review
Attachment #278656 - Attachment is obsolete: true
Keywords: checkin-needed
Status: NEW → ASSIGNED
Patch works great here, thanks.
I checked this in to tthe trunk.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 M8
Flags: in-litmus?
Verified fixed in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007093004 Minefield/3.0a9pre
Status: RESOLVED → VERIFIED
Depends on: 403471
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: