[Issue] Edit hyperlink: End key mangles the path!

[Crotchety]

Hi All,

Apologies if this is a known issue but I've searched the bugbase and this forum for as long as I could bear before posting...

When editing a hyperlink, under certain circumstances, pressing the End key mangles the path. It seems to be triggered by spaces in the name, which makes me think I can't be the only one to have noticed this, surely...

Anyway, here's my repro:

Target files, all in My Documents, all txt but it happens with odt too:
New Text Document
New Text Document - Copy
New Text Document - Copy, 2

In a new document, type "test", select it, open the hyperlink panel and browse to "New Text Document".
The path field now reads "<YourDocs>\New Text Document.txt".
In the field, press End to show that nothing wrong happens.
Apply, Close and re-open.
The path field now reads "<YourDocs>\New%20Text%20Document.txt".
In the field, press End (highlit or not, doesn't matter)
The path field now reads "<YourDocs>\New%New Text Document.txt
Apply and test the link to show that this mangled path has in fact been written.

Below is a summary of the results for all three files:

originally <YourDocs>/New%20Text%20Document.txt
+ End key <YourDocs>/New%New Text Document.txt

originally <YourDocs>/New%20Text%20Document%20-%20Copy.txt
+ End key <YourDocs>/New%20TeNew Text Document – Copy.txt

originally <YourDocs>/New%20Text%20Document%20-%20Copy,%202.txt
+ End key <YourDocs>/New%20TextNew Text Document - Copy, 2.txt

[Hagar Delest]

With AOO 3.4.0 on Ubuntu 12.04, no problem (I don't even have the %20 string for spaces.

[Crotchety]

...the %20 string for spaces.

I wonder if that's the problem. Wish I could turn it off so I could try it but I can't see a pref for it. I thought there was but I must be thinking of something else.

[Crotchety]

Still happening under AOO 3.4! This is a nasty bug, suddenly your links stop working and it's hard to spot unless you're looking for it.

[acknak]

Oops, no, wait. I see it now. You have to follow the exact sequence of steps.

The "%" escape sequences are only visible at certain points.

Here's what I did:

1) File > New > Text Document
2) Insert > Hyperlink
3) Link Type: Document; select a file that has spaces in the name; finish with "Open"

File path appears in dialog with normal space characters; same path as "URL" appears with %20 for spaces.

4)Click "Apply"

The hyperlink is inserted in the document; in the dialog, spaces in the path now appear as %20

Click in the path; press "End".

The %20 escapes disappear from the path being edited, but the path itself is now corrupted.

It really seems to be something specific to the "End" key--I can't make it happen with any other editing key.

I see it with OOo 3.3 and 3.2 so it's not a new problem.

[Hagar Delest]

OK, I see it too on Windows XP.
Seems there is no trend for the string repeated before the filename. Can be 2 or 10 characters, not linked with the first space.

-> Bug 120550 - End key corrupts path in hyperlink dialog.

[Crotchety]

Glad you've spotted it and thanks for registering it, Hagar, although I wouldn't call it minor, having just converted a large set of documents over to odf!

If it's any consolation, LibreOffice 3.6 also has it (yes, I was prepared to jump ship over this one) so it's either very old or maybe something to do with Windows, seeing as you don't get it under Ubuntu.

Why doesn't this happen for all OS? And is there no hidden pref to stop the %20 substituting the spaces?

[Hagar Delest]

I'll check again with Ubuntu, perhaps I did not exactly the same.
But I'm rather surprised that it appears for acknak too since he's running GNU/Linux too (Fedora).

[acknak]

I saw it in LibO as well--I think it's been around a while, although I didn't go back further than 3.2.

Maybe related to the difference in length with/without the escapes? I.e. someone's counting characters with the escapes and applying that to the string with only spaces? Just a guess; I haven't looked at it.

I found several bugs related to paths with spaces in them, and converting them back and forth. Strange that this is such a problem; I don't understand why they ever want the user to see those escaped spaces? And on top of it, they're only doing it with spaces--not all the other characters that aren't allowed in URLs. Looks like a mess.

[Crotchety]

Maybe related to the difference in length with/without the escapes? I.e. someone's counting characters with the escapes and applying that to the string with only spaces? Just a guess; I haven't looked at it.

You might have something there, acknak. The escaped string and the corrupt string are exactly the same length. The corrupt part is the characters in the escaped filename that precede the length of the unescaped filename (perhaps easier to see in Notepad than explain, just copy the examples from the OP).

[Crotchety]

I'll check again with Ubuntu, perhaps I did not exactly the same.

You need to Accept to get the escapes. Using End after simply selecting the file doesn't illustrate the issue.