670531 - Copying the URL bar content to the clipboard after modifying it results in missing http:// in the clipboard

Status: REOPENED

(Firefox :: Address Bar, defect, P5)

Description

[Eric Sauvageau]

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.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 4

[Fred Wenzel [:wenzel]]

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

Comment 5

[:Gavin Sharp [email: [e-mail]]]

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)

Comment 7

[B.J. Herbison]

(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.)

Comment 8

[Fred Wenzel [:wenzel]]

(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 :)

Comment 9

[Stefan]

(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.

Comment 11

[Justin Lebar (not reading bugmail)]

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.

Comment 12

[alex_mayorga]

(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 =(

Comment 13

[Nick]

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?

Comment 14

[Matt Brubeck (:mbrubeck)]

(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.

Comment 15

[John Hopkins (:jhopkins)]

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.

Comment 18

[Timothy Nikkel (:tnikkel)]

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.

Comment 21

[Julien Wajsberg [:julienw]]

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

Comment 22

[John Schoenick [:johns]]

Attachment: Remove the this.valueIsTyped bailout

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 23

[Dão Gottwald [:dao]]

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.

Comment 24

[John Schoenick [:johns]]

(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"

Comment 25

[Dão Gottwald [:dao]]

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

Comment 26

[Jasper St. Pierre]

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.

Comment 27

[John Schoenick [:johns]]

(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.

Comment 28

[posita]

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)

Comment 29

[John Schoenick [:johns]]

(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'

Comment 30

[Reuben Morais [:reuben]]

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?

Comment 31

[Julien Wajsberg [:julienw]]

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

Comment 32

[posita]

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.)

Comment 35

[nemo]

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

Comment 39

[nothanksmojo]

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.

Comment 40

[Clément Lefèvre]

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.

Comment 41

[:Gijs (he/him)]

(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.

Comment 42

[gandalf3]

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>.

Comment 43

[BMO Automation]

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.

Comment 44

[Florencia Di Ciocco, NI to vbalducci]

Hi, I'm closing this bug as WFM since I think this has been done. If I'm wrong, please do reopen it.

Comment 45

[B.J. Herbison]

I'm still able to reproduce this with http://example.com and other HTTP sites. On that site control-L-control-c will copy "http://example.com/" but control-L-END-<typing>-control-c will copy "example.com-<typing>".

Note that the issue doesn't affect HTTPS sites.

Comment 46

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 9 duplicates and 16 votes.
:adw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 47

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 48

[Shevaun]

Description:
Please provide an explanation of the feature or change. Include a description of the user scenario in which it would be used and how the user would complete the task(s).
Screenshots and visual UI specs are welcome, but please include sufficient accompanying explanation so that blind members of the accessibility team are able to understand the feature/change.

How do we test this?
If there is an implementation to test, please provide instructions for testing it; e.g. setting preferences, other preparation, how to trigger the UI, etc.

When will this ship?
Tracking bug/issue:
Design documents (e.g. Product Requirements Document, UI spec):
Engineering lead:
Product manager:

The accessibility team has developed the Mozilla Accessibility Release Guidelines which outline what is needed to make user interfaces accessible:
https://wiki.mozilla.org/Accessibility/Guidelines
Please describe the accessibility guidelines you considered and what steps you've taken to address them:

Describe any areas of concern to which you want the accessibility team to give special attention:

Comment 49

[Shevaun]

The https:// is still missing once you copy paste the url.

Comment 50

[Daniel Holbert [:dholbert]]

Yes, that's why this bug is still open. Please stop changing random fields on the bug - thanks.