User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110706 Firefox/7.0a2 Build ID: 20110706042005 Steps to reproduce: 1. Visited a website 2. Website redirected to a different page, changing the URL path a bit 3. I edited the Location bar content to put back the original URL 3b. Note: I did not press Enter after modifying the URL, as I didn't want the redirection to happen again 4. I copied the (modified) Location bar content to the clipboard using Ctrl-C. 5. I pasted the clipboard content to another application (tested with different applications: Notepad, and Trillian - an IRC client). I visited a website, which then redirected to a different page, changing the URL a bit. I then edited the URL to put back the original URL (before the redirect), and then I copied the location bar content to the clipboard using Ctrl-C (without pressing enter so the URL wouldn't get modified again by the redirection). Actual results: When pasted, the URL was missing the http:// part in the URL. Expected results: http:// (or whichever protocol the original URL used before editing it) should be present at the start of the pasted URL. This is the actual behaviour that happens if you copy/paste without editing the location bar content.

This isn't a duplicate. Once the location bar is modified, we no longer fall back to using the loaded URL, and just copy what is selected.

I can confirm this on tonight's Aurora. Little sad how the feature landed with most use cases broken :-/

That isn't a fair characterization; "most use cases" aren't broken. Editing the URL (without loading it) and then trying to copy it is an edge case. (that isn't to say we shouldn't fix this - it's just tricky to do reliably)

(In reply to comment #5) > Editing > the URL (without loading it) and then trying to copy it is an edge case. > (that isn't to say we shouldn't fix this - it's just tricky to do reliably) An alternative approach that could simplify some cases: Add back the "http://" when the URL bar gets focus. The only state to be maintained is whether the "http://" has been stripped off. Implementation detail: Add it to the left of the visible area of the URL bar (i.e., increase the scroll position of the URL bar by 7 characters). That way there wouldn't be a visible position change to annoy someone trying to select characters in the URL, and a mouse drag to the left would pick up the characters. Or, even simpler: Never remove the "http://". Just change the initial shift position of HTTP URLs in the URL bar so 7 characters aren't visible on initial load but are always available to shift into view or select before of after editing. (I can think of one "edge case" where these two approaches fail: Someone sees "mozilla.org" in the URL bar and isn't aware of the "http://" to the left. The mouse is positioned to the left of the "m" and "http://" (or "https://") is typed followed by <SelectAll><Copy>. The copied UTL has two protocols. I think this requires an experience but naive user. Hmmm, sounds like something I'd do.)

(In reply to comment #5) > That isn't a fair characterization; "most use cases" aren't broken. Editing > the URL (without loading it) and then trying to copy it is an edge case. Right, apologies, I spoke too generally. I guess I was more unhappy to see that this feature has so many edge cases to consider. Thanks for working on it, Gavin :)

(In reply to comment #5) > That isn't a fair characterization; "most use cases" aren't broken. Editing > the URL (without loading it) and then trying to copy it is an edge case. Another use case of URL editing is: "Add an 's' to the protocol" in order to switch to HTTPS. This will be covered by B.J.s proposal.

Note that the STR in bug 673839 doesn't require you to edit the location bar's text -- just type something, press down to select the first awesomebar result, press ctrl-l, ctrl-c.

(In reply to comment #7) > (In reply to comment #5) > > Editing > > the URL (without loading it) and then trying to copy it is an edge case. > > (that isn't to say we shouldn't fix this - it's just tricky to do reliably) > > An alternative approach that could simplify some cases: Add back the > "http://" when the URL bar gets focus. The only state to be maintained is > whether the "http://" has been stripped off. Big +1 This would also fix the only gripe I have due to vanishing http:// breakage of bit.ly functionality described here http://maketecheasier.com/quickly-shorten-links-from-address-bar =(

I'm going to add that http:// fails to get copied if you try to copy a URL before the page has loaded fully, even without modifying it. This is very annoying because I either have to wait for the page to load fully or add the http:// manually when copying a URL, happens to me about a dozen times per day. I'm going to disable the URL-shortering feature for now because it's simply not working correctly. Should I file this as a separate bug or not?

(In reply to Nick from comment #13) > I'm going to add that http:// fails to get copied if you try to copy a URL > before the page has loaded fully, even without modifying it. [...] > > Should I file this as a separate bug or not? At least some of these cases are covered by bug 668019.

One usability issue I have with the http protocol being hidden is that "what I see is not what I get" when I copy a link from the location bar to the clipboard. I find it mildly disconcerting.

Bug 697248 is a special case of this where we use undo to go back to the original contents of the location bar but still don't copy the http.

ok, so, is somebody working on this ? 5 duplicates, 10 votes, it seems to be a quite important bug.

We're bailing out in _getSelectedValueForClipboard if the url has been edited by the user. However, our fixups below account for issues this could cause (such as a new protocol being added). Someone more familiar with this code would need to take a look at if this can be safely removed.

Comment on attachment 610617 [details] [diff] [review] Remove the this.valueIsTyped bailout This looks like it would copy "http://foo/" when typing "foo" in the location bar and selecting everything.

(In reply to Dão Gottwald [:dao] from comment #23) > Comment on attachment 610617 [details] [diff] [review] > Remove the this.valueIsTyped bailout > > This looks like it would copy "http://foo/" when typing "foo" in the > location bar and selecting everything. What behavior would we want here? We could extend the check for if they've selected through what looks like a full domain, such that "foo" would yield "foo" but "foo.foo/blee" would yield "http://foo.foo/blee"

Where exactly would you draw the line? What about "foo.foo" and "localhost"?

The behaviour should be consistent with what was there before the protocol hiding existed: if there's a hidden protocol, it should be copied, otherwise no. I don't know the internal code, but it doesn't seem that hard to me -- add the hidden protocol when the browser resolves it, and remove it when the user blanks or replaces the text in the entry.

(In reply to Dão Gottwald [:dao] from comment #25) > Where exactly would you draw the line? What about "foo.foo" and "localhost"? Requiring a selection through a slash in the case the user has edited the field seems reasonable. The case where "foo/foo" yields "http://foo/foo/" is much less of a user experience hit than the current behavior -- I think assuming users copying out of the URL bar generally want a URL is fairly sane. A bare+edited "foo.foo" or "localhost" would still fail to prepend the protocol. As is, touching the URL at all removes your ability to copy it in a sane fashion -- If I want to share a link to a google search I've just performed in IRC: I select the blob of useless parameters google appends and press cut-selectall-copy. Now my clipboard has no protocol, and the result wont be linkified by most IRC clients. I've been hitting this a lot lately linking people to specific views of areweslimyet.com - I'll add or remove some parameters and copy it, only to be given a link I need to manually fix up more after pasting.

Once you magically hide the protocol in the URL bar (like Chrome does, instead of like iOS Safari does), THERE IS NO CORRECT BEHAVIOR FOR CUT/COPY. See, e.g., <http://code.google.com/p/chromium/issues/detail?id=131143>. If you choose to omit the protocol, you're screwed because there's no way to cut/copy the protocol (since it's magically hidden). If you choose to include the protocol, you're screwed, because people expect what is visibly selected to end up on the clipboard. <Rant>Either way, it's broken, broken, broken. This is what happens when people get "clever" and "fix" things that aren't in need of repair, like working magic to "make things easier" without fully considering all the ways in which people actually use the interface. It's arrogant and often harmful. The ONLY way to do this right is to do URL hiding a la iOS Safari, which Chrome and Firefox both have explicitly rejected. (Sadly, it appears that Mountain Lion might adopt the same asinine behavior as Chrome; see <http://mountain-lion.en.softonic.com/mac>.)</Rant> Just my $1.05.... ;o)

(In reply to Matthew Bogosian from comment #28) > Once you magically hide the protocol in the URL bar (like Chrome does, > instead of like iOS Safari does), THERE IS NO CORRECT BEHAVIOR FOR CUT/COPY. > See, e.g., <http://code.google.com/p/chromium/issues/detail?id=131143>. > > If you choose to omit the protocol, you're screwed because there's no way to > cut/copy the protocol (since it's magically hidden). If you choose to > include the protocol, you're screwed, because people expect what is visibly > selected to end up on the clipboard. > > <Rant>Either way, it's broken, broken, broken. This is what happens when > people get "clever" and "fix" things that aren't in need of repair, like > working magic to "make things easier" without fully considering all the ways > in which people actually use the interface. It's arrogant and often harmful. > The ONLY way to do this right is to do URL hiding a la iOS Safari, which > Chrome and Firefox both have explicitly rejected. (Sadly, it appears that > Mountain Lion might adopt the same asinine behavior as Chrome; see > <http://mountain-lion.en.softonic.com/mac>.)</Rant> > > Just my $1.05.... ;o) Discussing features would be more productive on the mailing list, rather than a random bug about said feature: https://lists.mozilla.org/listinfo/dev-apps-firefox Additionally, you can disable this functionality in Firefox entirely by going to about:config and setting browser.urlbar.trimURLs to 'false'

I still believe we should show the protocol when the urlbar is focused. I believe Opeara does this. It is simple and the results of text operations are very clear to the user. Does this sound reasonable to the UX people?

+1, I believe this is the only sane way to implement the feature.

This bug only deals with the clipboard aspects of cutting/copying "magically" hidden URLs. It does not deal with hiding (or showing if the URL bar has focus). That is bug 665580 which has been marked as fixed. While I agree with the last two comments, they are more appropriately made either in bug 665580 or in a new bug upon which this one depends. In response to comment 29, my comment 28 is actually on point for this bug. My point was that this bug *cannot* be fixed with the current (broken) scheme-hiding behavior. Until that aberration is removed (or at least fixed to reveal the scheme when the URL bar has focus), no matter which behavior one picks for resolving this bug (either RESOLVED as FIXED or WONTFIX), it's the wrong behavior (see my comments here <http://code.google.com/p/chromium/issues/detail?id=131143>). There can be no correct behavior as long as you need something copied that isn't seen and where (simultaneously) you shouldn't copy something that isn't seen. (And no, requiring all users to set browser.urlbar.trimURLs to false is *not* a fix.)

I agree with comments #30 and #31 It would probably also fix the performance problem with URL trimming. However, that bug was closed WONTFIX - sorry guys. bug #667271

This seems to be two separate issues: 1) The behaviour of select+copy is different before and after editing the URL. Before editing, any selection which goes to the far left, includes the hidden protocol; after editing, it doesn't. This can be improved by making it consistent. 2) Select+copy includes hidden information. Comment 30 is a real fix.

Need info on you, in case you would know a bit more about who can take a look at this, working on this component as there were no real changes on this bug recently.

(In reply to Clément Lefèvre from comment #40) > Need info on you, in case you would know a bit more about who can take a > look at this, working on this component as there were no real changes on > this bug recently. I don't understand what the question is, or what people actually want at this point. Many comments are contradictory (e.g. comment #26 seems to just suggest that changing the text should stop copying the protocol, whereas this bug as filed was about how editing the URLs breaks this; other comments now want to re-show the protocol immediately on focus (which will change what e.g. "select all" does) ). We already have a pref to turn this feature off completely. What this bug needs is a concrete summary of what it wants to do, with agreement from core Firefox (UX) people that that is a sensible plan. I also don't understand why you picked me to comment here, having previously not had anything to do with this bug.

I agree with the behavior described in comment 30 and comment 7. The addition of the 7 char offset described in comment 7 makes sense to me: * It preserves any url shortening benefits of the current behavior * Is mostly WYSIWYG and always consistent when copy+pasting, assuming a Ctrl+A (select all) shifts the true beginning of the selection into view, just as a right-to-left mouse-drag would. (Unless the URL is too long for the URL bar and the view is scrolled to the right, in which case the usual behavior of leaving the view where it is should be preserved) It even caters to the use-case described in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=666964#c33">comment 33 of 6669644</a>.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.