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

VERIFIED FIXED in Firefox 3 alpha8

Status

()

VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: karlt, Assigned: dao)

Tracking

({regression})

Trunk
Firefox 3 alpha8
x86
Linux
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
The bug apparently showed after checkin from bug 190615.
Blocks: 190615
(Assignee)

Comment 2

11 years ago
How does Firefox 2 behave if you set browser.urlbar.clickSelectsAll to true?
(Reporter)

Comment 3

11 years ago
(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.
(Assignee)

Comment 4

11 years ago
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.

Comment 5

11 years ago
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.
(Assignee)

Updated

11 years ago
Depends on: 226853

Comment 6

11 years ago
textbox.select() called by an untrusted web page should not write to the X selection, IMO.
(Assignee)

Comment 7

11 years ago
Sure thing. But would a different policy for chrome make sense? If not, how about an explicit scriptable method?
(Assignee)

Updated

11 years ago
Duplicate of this bug: 394056
(Assignee)

Updated

11 years ago
Assignee: nobody → dao
(Assignee)

Comment 9

11 years ago
Created attachment 278656 [details] [diff] [review]
patch
Attachment #278656 - Flags: review?(mano)
(Assignee)

Updated

11 years ago
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+
(Assignee)

Comment 11

11 years ago
Created attachment 278660 [details] [diff] [review]
cleaned patch
Attachment #278656 - Attachment is obsolete: true
(Assignee)

Updated

11 years ago
Keywords: checkin-needed
(Assignee)

Updated

11 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 12

11 years ago
Patch works great here, thanks.
I checked this in to tthe trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Target Milestone: --- → Firefox 3 M8
(Assignee)

Updated

11 years ago
Flags: in-litmus?

Comment 14

11 years ago
Verified fixed in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007093004 Minefield/3.0a9pre
Status: RESOLVED → VERIFIED
(Assignee)

Updated

11 years ago
Depends on: 403471
https://litmus.mozilla.org/show_test.cgi?id=5088

in-litmus+
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.