1254415 - Firefox changes string and adds http:// and / when I copy non-url string in urlbar to clipboard

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect, P3)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160229030448
STR:
1. Type/paste string "Unique20160308080328" to urlbar.
2. Press Down key
3. Press Up key
4. Select all text in urlbar: press Shift+Home
5. Copy selected text (Ctrl+C)
6. Paste selected text (Ctrl+V)

AR:  Pasted string is   "http://Unique20160308080328/"
ER:  Pasted string should be "Unique20160308080328"

Notes:
1) This happens with almost every string, not necessarily unique
2) Step 3 isn't necessary if you use the string suggested by me ("Unique20160308080328")

Comment 1

[arni2033]

Correction:
AR:  Pasted string is   "http://unique20160308080328/"
    (i.e. offending bar replaced character "U" with "u" and added "http://" and "/")
ER:  Pasted string should be "Unique20160308080328"

Comment 2

[Daniel Holbert [:dholbert]]

I've been noticing this recently as well, though it's not a recently-introduced bug -- I can reproduce it in 2004-06-01 Nightly, for example.

Anyway, marking as NEW.

Comment 3

[arni2033]

Thanks, Daniel. Using your info, I found regression range using another scenario. I still think that now with that fancy 1st suggestion in urlbar this bug is very easy to encounter (comment 0)

STR_2:
1. Open http://example.org/ in a new tab
2. Open new tab, type "ample" in urlbar
3. Press Down, then Up
4. Select text in urlbar (Ctrl+A), then paste it into urlbar (Ctrl+V)

AR:  Text in urlbar is "http://ample/"
ER:  It should be just "ample"

This is regression from bug 668019 (which itself was caused by well-known firefox regression: one day
it stopped showing http:// in urlbar. That's a long-standing regression causing bugs like this one)
Regression range:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5319b0100025&tochange=2a4671d164b4

Comment 4

[Daniel Holbert [:dholbert]]

[Apologies, I apparently marked this as FIXED in comment 2 when I meant to mark it as NEW. Thanks for reopening; resetting to NEW to clarify that no one ever actually intended to close this bug.]

Comment 6

[avada]

Shouldn't this block bug 1262507?

Comment 7

[Daniel Holbert [:dholbert]]

I don't think so. Per comment 3, this is an old regression (from bug 668019 in Firefox 9).  So, it's not specific to the "new awesomebar design" that's covered by the tracking bug that you linked to.  (This is still worth fixing; just, unrelated to that bug.)

(Side note / correction: in comment 2, I mentioned a build from "2004-06-01" -- I'm pretty sure I must've meant "2014" there.  I don't think Firefox builds from 2004 would actually run on any Linux system that I'm running today, what with different library versions etc. :))

Comment 8

[avada]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> I don't think so. Per comment 3, this is an old regression (from bug 668019
> in Firefox 9).  So, it's not specific to the "new awesomebar design" 

Bug 1071461 then?

Comment 9

[Daniel Holbert [:dholbert]]

(Sure, that makes more sense.)

Comment 10

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I cannot reproduce this in Nightly. Feel free to reopen if you can provide STR to reproduce it.