User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:220.127.116.11) Gecko/2008070208 Firefox/3.0.1 Firefox randomly messes up the pasted URL before actually loading the content. This happens randomly, but can be repeated several times on will. The only requirement is that the pasted url contains a space as the first character. This happens quite often when copying a url manually from a text, and pasting the url in a new tab window. Reproducible: Sometimes Steps to Reproduce: 1. Select a URL including the first space and copy it to clipboard (ctrl-c, without quotation marks): " http://www.google.com" 2. Open a new tab in firefox (ctrl-t) 3. Paste (ctrl-v), enter 4. If the google loads fine, then repeat from 2, leaving the old tab open. You might have to repeat it 2-5 times. Actual Results: Firefox loads URL "http://www.http:.com//www.google.com" Expected Results: Firefox should dismiss the space character and load the correct URL "http://www.google.com"
This might be happening because you hold Ctrl (from Ctrl+V) when you press enter. Can you confirm that that's what makes it seem to happen "sometimes"?
Oh, that might actually be it! But it's still bugged, as nobody wants to "autocomplete" their urls with www.http:.com. I never use that feature anyway. Can it be turned off completely, as first workaround?
I don't know how easy it is to work around the bug. It's easy to fix, though -- patch coming up.
Assignee: nobody → jruderman
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows Vista → All
Hardware: PC → All
Summary: Random URL mess up with prefixed space character (www.http:.com//www..) → Ctrl+Enter messes up complete URL that is prefixed with space character (becomes "www.http:.com//www..")
Created attachment 339630 [details] [diff] [review] Patch: ignore leading whitespace in determining whether the string is "already URL-like" The history of this line of code includes bug 338864 and bug 177618.
Attachment #339630 - Flags: review?(gavin.sharp)
Attachment #339630 - Flags: review?(gavin.sharp) → review+
It would be nice to have a browser chrome test for this method that covers examples from this bug and the others you mentioned.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
For testing, would it make sense to refactor canonizeUrl into a pure function and one with side effects, and test the pure function directly?
We could do that, though I'm not sure what's hard about the current setup. All canonizeUrl does right now is read and set gURLBar.value, right? Should be able to just write a test that sets gURLBar.value, calls canonizeUrl, and then reads the value back repeatedly.
Philip, I'm not sure why you CC'ed me. If you meant that SM should port/add canonizeUrl() to its handleURLBarCommand(), please file a SM bug.
Target Milestone: --- → Firefox 3.1b1
Version: unspecified → Trunk
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre. This was originally reported on the branch, so nominating to get it on that radar.
Status: RESOLVED → VERIFIED
Not blocking on branch, sorry.
Flags: blocking18.104.22.168? → blocking22.214.171.124-
You need to log in before you can comment on or make changes to this bug.