Closed Bug 393828 Opened 16 years ago Closed 16 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: 16 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.