504412 - Firefox 3.5 copy/paste URL incorrectly substitutes %28 and %29 for parenthesis open/close

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect)

Description

[Steven Rowat]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

Name an html (or php) file including parentheses characters in the filename, view the file in FF 3.5, and copy the entire path from the topbar and paste it right back in or elsewhere; the paste substitutes %28 and %29 for parenthesis characters.

AFAIK parenthesis characters are permitted in filenames, so this is a bug and unacceptable behavior.

Reproducible: Always

Steps to Reproduce:
1. name a file such as Testfile(3).html
2. open in FF 3.5 
3. Copy URL from topbar.
4. Paste back in, or elsewhere.
Actual Results:  
Result is something like: 
"Testfile%283%29.html"

Expected Results:  
Testfile(3).html

This does not occur on FF 3.0 on Windows. 

I don't have any other FF installations, so I don't know if it's a Mac behavior or a Ff3.5 core behavior that has appeared since 3.0.

Comment 1

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

That's intentional - despite () being valid in URLs, many external programs that parse URLs don't support them properly (omitting the trailing ")", e.g.). So when you copy the entire URL (as opposed to copying only a portion of it), we encode the URL.

As far as I know, we did that in 3.0 as well, though. Are you sure this behavior was different then?

Comment 2

[Dão Gottwald [:dao]]

(In reply to comment #1)
> despite () being valid in URLs, many external programs
> that parse URLs don't support them properly (omitting the trailing ")", e.g.).

And it should be noted that this is probably intentional as well, as ")" is punctuation that doesn't belong to the URL most of the time. So we don't just work around a dysfunction of some external programs.

Comment 3

[Steven Rowat]

(In reply to comment #1)
> That's intentional - despite () being valid in URLs, many external programs
> that parse URLs don't support them properly (omitting the trailing ")", e.g.).
> So when you copy the entire URL (as opposed to copying only a portion of it),
> we encode the URL.
> 
> As far as I know, we did that in 3.0 as well, though. Are you sure this
> behavior was different then?

No, but I can tell you this much:
--I've been copying URLs with parentheses regularly for over a year as part of a web development (pasting them between Mac OS and Windows while checking display of html), using 2.0 and 3.0, and this is the first time I've noticed this (with 3.5)
--I still have 3.0 on the Windows machine, and testing with several pastes, it doesn't happen, even with a new test file and making sure I'm clicking in the blank space to the right of the URL so I'm definitely selecting 'the whole URL' and not dragging over it. Copy/Paste works normally.

--I have 3.0 on windows, and

Comment 4

[Steven Rowat]

(In reply to comment #2)
> (In reply to comment #1)
 
> And it should be noted that this is probably intentional as well, as ")" is
> punctuation that doesn't belong to the URL most of the time. So we don't just
> work around a dysfunction of some external programs.

OK, I can see there are reasons for this 'feature'. :-)

However, in further testing, I'm getting this peculiar behavior:

--Using 3.5, yes, I can copy and paste and keep the parentheses if I copy only part (even if I just leave out 1 character). Good to know for a workaround.

--However, the 'whole URL' copy that puts %28 and %29 into the parenthesis positions is not consistent. It works for the first one or two copy/pastes. Then it disappears. Thereafter, I can select and copy the whole URL and paste it, without % characters showing up. Is this, too, intentional? (And if it is, I'll suggest it would be hard for a user to understand when it will appear, without some kind of meaningful direction from the program.)

[BTW, is it possible to edit posts? I'd like to remove that unintentional trailing part-sentence in my previous post.]

Comment 5

[Dão Gottwald [:dao]]

(In reply to comment #4)
> --However, the 'whole URL' copy that puts %28 and %29 into the parenthesis
> positions is not consistent. It works for the first one or two copy/pastes.
> Then it disappears. Thereafter, I can select and copy the whole URL and paste
> it, without % characters showing up. Is this, too, intentional?

No, that would be a bug. Have you by chance modified the address, i.e. added or removed a letter? We only decode if the value actually references the current page.

Comment 6

[Steven Rowat]

(In reply to comment #5)
> (In reply to comment #4)
> > --However, the 'whole URL' copy that puts %28 and %29 into the parenthesis
> > positions is not consistent. It works for the first one or two copy/pastes.
> > Then it disappears. Thereafter, I can select and copy the whole URL and paste
> > it, without % characters showing up. Is this, too, intentional?
> 
> No, that would be a bug. Have you by chance modified the address, i.e. added or
> removed a letter? We only decode if the value actually references the current
> page.


No, but I think I've figured it out:
--with 3.5, a refreshed page pastes "%28" if I copy the whole URL, and "(" if I copy anything less
--however, if I copy the whole URL, paste gettiing "%28", hit undo to return it to the original, and then copy and paste, I get "(" from now on, until I hit refresh again. So for some reason the 'undo' puts it into a different category and it copies and pastes like ordinary text, without the '%28'. 
--still doesn't happen at all on 3.0 for Windows, so I still believe (for lack of other evidence) the '%28' behavior is either new with FF 3.5 or only occurs with Mac; probably the former.

Anyway, you've convinced me that this is not a bug. Just a new feature that I don't like. :-)

Comment 7

[Dão Gottwald [:dao]]

(In reply to comment #6)
> So for some reason the 'undo' puts it into a different category
> and it copies and pastes like ordinary text, without the '%28'. 

Right, we still consider that a user-modified value.

I also don't think 3.0 behaved differently in that regard.

Comment 8

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.10 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

Comment 9

[Steven Rowat]

I no longer find this on brief testing with 3.6.1

Comment 10

[Steven Rowat]

Changed to Resolved: Fixed.

Comment 11

[Steven Rowat]

Changed to Resolved: WorksForMe