440075 - Location bar doesn't encode the address when using UNIX copy/paste (selecting)

Status: VERIFIED FIXED

Description

[Raúl Porcel]

So, on UNIX when you select something, it gets copied to the clipboard. So if we select the url in the location bar, and it has spaces, the clipboard paste shows spaces literally, not with %20 like it does when doing ctrl-c.

Feature or bug?

Steps to reproduce:
1. Go to http://dev.gentoo.org/~armin76/space%20plop.html
2. Select all the url, the URL gets copied to the clipboard
3. Paste the clipboard somewhere else using the middle button of the mouse
4. You get: http://dev.gentoo.org/~armin76/space plop.html

Bug reported by Andrew Gaffney <agaffney at gentoo dot org>

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Drag copying doesn't go through the copy command controller, I guess? Not sure how that works.

Comment 2

[Tim Starling]

Obviously copying with the register should use the fully encoded URL, the problem isn't confined to spaces. 

Can we have an about:config option in the next minor release to disable the decode feature, while we're waiting for this bug to be fixed properly?

Comment 3

[Jonathan S Abrams]

Changing hardware and OS to all, as this is being observed with v3.0.1 on Mac OS X v10.4.9.  Is this related to bug #416144?

Comment 4

[Raúl Porcel]

In fact this is a dupe of that one, thanks :)

Comment 5

[Dão Gottwald [::dao]]

Created attachment 337350 [details] [diff] [review]
patch

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 337350 [details] [diff] [review]
patch

>diff --git a/browser/base/content/urlbarBindings.xml b/browser/base/content/urlbarBindings.xml

>+      <handler event="select"><![CDATA[

This relies on the fact that the select event fires after the editor code does it's usual clipboard handling, right? Is that guaranteed? I suppose the existing copy controller already relies on running after the native editor code.

As written this will mean that keyboard selections (e.g. Ctrl+Arrow) will also add items to the selection clipboard, which I don't think is expected. The only editor code that sets kSelectionClipboard seems to be in mouseclick.

Comment 7

[Dão Gottwald [::dao]]

(In reply to comment #6)
> This relies on the fact that the select event fires after the editor code does
> it's usual clipboard handling, right? Is that guaranteed?

Probably not, in the sense that it's not documented anywhere, but it seems to be implemented this way.

> I suppose the
> existing copy controller already relies on running after the native editor
> code.

That's guaranteed, though, because the controller is inserted at the first position.

Comment 8

[Dão Gottwald [::dao]]

Comment on attachment 337350 [details] [diff] [review]
patch

(In reply to comment #6)
> As written this will mean that keyboard selections (e.g. Ctrl+Arrow) will also
> add items to the selection clipboard,

Actually this seems to be the correct behavior. Firefox 3, gedit and Nautilus behave this way.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 337350 [details] [diff] [review]
patch

OK

Comment 10

[Dão Gottwald [::dao]]

http://hg.mozilla.org/mozilla-central/rev/7b2a03375806

Comment 11

[Stephen Donner [:stephend]]

Verified FIXED using:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081009 Minefield/3.1b2pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081009 Minefield/3.1b2pre

-and-

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081009 Minefield/3.1b2pre

Also, in-litmus+:

https://litmus.mozilla.org/show_test.cgi?id=7053