Closed Bug 531210 Opened 15 years ago Closed 13 years ago

When accessing urls in SeaMonkey with %20, it is replaced with a whitespace. Breaks other software if you try to copy-paste part of the url out of SeaMonkey

Categories

(SeaMonkey :: Location Bar, defect)

defect
Not set
normal

Tracking

(status1.9.1 ?)

VERIFIED FIXED
Tracking Status
status1.9.1 --- ?

People

(Reporter: glgxg, Unassigned)

References

Details

(Whiteboard: [Sm 2.0.x] [Workaround see comment #10])

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091124 NOT Firefox/3.5 Lightning/1.0pre SeaMonkey/2.0.1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091124 NOT Firefox/3.5 Lightning/1.0pre SeaMonkey/2.0.1pre

See:
https://bugzilla.mozilla.org/show_bug.cgi?id=475896
https://bugzilla.mozilla.org/show_bug.cgi?id=475896#c22
https://bugzilla.mozilla.org/show_bug.cgi?id=475896#c23

Reproducible: Always
Summary: When accessing urls in firefox with %20, it is replaced with a whitespace. Breaks other software if you try to copy-paste part of the url out of SeaMonkey → When accessing urls in SeaMonkey with %20, it is replaced with a whitespace. Breaks other software if you try to copy-paste part of the url out of SeaMonkey
Your User-Agent string seems to have been "doctored". Mine is:
User-Agent:	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091125 SeaMonkey/2.0.1pre
Build ID:	20091125001037

With "Copy Link Location" the clipboard gets

https://help.ubuntu.com/community#Getting%20to%20know%20and%20work%20with%20your%20system

which is appropriate, since that menu item's purpose is usually to allow pasting as a link, e.g. into the URL bar, in the href= attribute of some HTML element, or in an email whose addressee wil be able to access the link by clicking.

If I click the link the URL bar gets the human-readable equivalent, i.e., 

"https://help.ubuntu.com/community#Getting to know and work with your system" (without quotes of course),

which allows me to see what the location bar is pointing at, even if it is in Russian or Chinese.

It seems to me that the difference is probably intentional, which would imply a RESOLUTION of either INVALID or WONTFIX. I'm not setting it yet though, I'd rather wait for confirmation from "on high", especially since this bug is inspired by a Firefox bug which has seen vivid discussion but no open-and-shut resolution.
Component: General → Location Bar
QA Contact: general → location-bar
Hardware: x86 → All
Version: unspecified → SeaMonkey 2.0 Branch
> With "Copy Link Location" the clipboard gets

I'm not sure what you're suggesting here.  The problem is seen when copying the URL out of the URL bar.  Where do you get "Copy Link Location" on the URL bar?
We currently don't remangle the URL at all when copying it, even for things like parentheses which Firefox already mangles (even though it wouldn't normally be mangled) to make things easier for pastees. So one approach would be to wait for Firefox to come up with a fix and appropriate some of their URL copy code.
Additional examples w/parentheses:

In a Google search enter:
ubuntu +karmic +"D-link DSL-502T"
That is s typical and valid search string in Google. Now copy & paste the result from the url address bar into an email etc. 

SM 1.1.18

<http://www.google.com/#hl=en&source=hp&q=ubuntu+%2Bkarmic+%2B%22D-link+DSL-502T%22&aq=f&aqi=&oq=&fp=6b22d27f49a5e7dd>

SM 2.0
<http://www.google.com/#hl=en&source=hp&q=ubuntu+%2Bkarmic+%2B"D-link+DSL-502T"&aq=f&aqi=&oq=&fp=6b22d27f49a5e7dd>
(In reply to comment #2)
> > With "Copy Link Location" the clipboard gets
> 
> I'm not sure what you're suggesting here.  The problem is seen when copying the
> URL out of the URL bar.  Where do you get "Copy Link Location" on the URL bar?

"Copy Link Location" is when I try to "copy-paste the URL out of SeaMonkey" (as this bug's Summary says) by right-clicking the link.
Ummm.... 
"Breaks other software if you try to copy-paste part of the url out of SeaMonkey"

Right click & copy url in the location/address bar =
<http://www.google.com/search?hl=en&source=hp&q=ubuntu+%2Bkarmic+%2B"D-link+DSL-502T"&aq=f&aqi=&oq=&cad=h>

You only get "Copy Link Location" when you right click a link in a message or on a page (like this one).

You can easily test by clicking on this url and then pasting back here:
<http://www.google.com/#hl=en&source=hp&q=ubuntu+%2Bkarmic+%2B%22D-link+DSL-502T%22&aq=f&aqi=&oq=&fp=6b22d27f49a5e7dd>
the result will be as I've shown above.
This bug not only affects the space character %20 but also some international accented letters. Try searching for the term "Świętokrzyskie" in google. The correct url is (copied from the Page Info dialog):

http://www.google.pl/search?hl=pl&source=hp&q=%C5%9Awi%C4%99tokrzyskie&lr=&aq=f&aqi=g10&aql=&oq=&gs_rfai=

Now when I select the url in the location bar and copy, the url is different when I paste it:

http://www.google.pl/search?hl=pl&source=hp&q=Świętokrzyskie&lr=&aq=f&aqi=g10&aql=&oq=&gs_rfai=

Now when I try to paste this url in the location bar of another SM window, the search term in google is corrupted - in this case the first letter is missing.

When you go to the correct sample url above, you can see that the url gets corrupted also in the following scenarios:

1. Open another SM tab or window and drag the url by the url handle in the location bar from the original window to the new tab/window - the url gets corrupted and the search term in the new tab/window is truncated

2. Drag the url by the url handle to the Manage Bookmarks window - a corrupted url gets bookmarked

3. Drag the url handle to the desktop to create a link (Windows). The url in the link is also corrupted, however in a different way.

I know it comes from Firefox which included this 'nice' url-encoding for readability but this behaviour is evil and unless a fix can be made I think it should be turned off completely.
If this is fixed in Firefox can someone find the equivalent bug? It'd be easier to look at how they fixed it than trying to come up with our own solution.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b2pre) Gecko/20100701 Lightning/1.1a1pre SeaMonkey/2.1a3pre - Build ID: 20100701101320

I'm seeing this on trunk too (only, of course, when copying from the URL bar).

In reply to comment #8: see comment #0 above. It is NEW (not RESOLVED) in Firefox too.

Since comment #1 (and its last paragraph) my opinion has changed: now I think it would probably be better to have something "copyable" in the URL bar, maybe with the human-readable address in a tooltip (but that would mean removing the present "Enter search term, keyword, or web address" tooltip which looks ominously new which would mean whoever may allow the tooltip change would probably be unwilling to do so.
Status: UNCONFIRMED → NEW
status1.9.1: --- → ?
Ever confirmed: true
Whiteboard: [Sm 2.0.x and Trunk]
Version: SeaMonkey 2.0 Branch → Trunk
Workaround (cf. bug 475896 comment #23) copy the URL from the "View => Page Info" popup (the "Address" entry, near the top of the "General" tab).
Whiteboard: [Sm 2.0.x and Trunk] → [Sm 2.0.x and Trunk] [Workaround see comment #10]
The Firefox bug is a related bug. Our URLbar code is different but apparently suffers from a similar bug.
See Also: → 475896
Depends on: 475896
See Also: 475896
This has been a major annoyance for me  too. When will it be fixed or made optional again.
Fixed in SeaMonkey 2.1b2pre via Bug 613199
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Whiteboard: [Sm 2.0.x and Trunk] [Workaround see comment #10] → [Sm 2.0.x] [Workaround see comment #10]
Why has this been marked as a dup of 613199? This bug is still not fixed in:
Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101123 Lightning/1.0b1 SeaMonkey/2.0.11

Cut & pasted from the url bar:
https://help.ubuntu.com/community#Getting to know and work with your system

Comment #10 is not an acceptable "workaround"
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Mozilla practice is to mark bugs as FIXED if it is fixed on trunk.

The SeaMonkey 2.0.x branch is in maintenance mode. Only security and stability fixes are allowed.

To get this fix into the 2.0 branch (doubtful) change the blocking1.9.1 flag to "?". This means you are nominating the fix to be backported to the 2.0 branch. Also add a comment in this bug explaining why you think this is a security or stability bug, or why there is an overwhelming reason to do so. Thank you.
(In reply to comment #13)
> Fixed in SeaMonkey 2.1b2pre via Bug 613199
> 
> *** This bug has been marked as a duplicate of bug 613199 ***

The bug is not present on
Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110417 Firefox/6.0a1 SeaMonkey/2.2a1pre ID:20110417003006
a trunk build from a week or two ago.
Status: REOPENED → RESOLVED
Closed: 14 years ago13 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Verified work for me on
Mozilla/5.0 (X11; Linux i686; rv:2.0pre) Gecko/20110406 Firefox/4.0pre SeaMonkey/2.1b3pre
You need to log in before you can comment on or make changes to this bug.