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

REOPENED
Unassigned

Status

()

Firefox
Location Bar
REOPENED
6 years ago
10 months ago

People

(Reporter: Eric Sauvageau, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
All
Other
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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.

Updated

6 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 666964
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.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Duplicate of this bug: 670714
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)
Duplicate of this bug: 671929
Blocks: 670714
Blocks: 665580

Comment 7

6 years ago
(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 :)

Comment 9

6 years ago
(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.

Updated

6 years ago
Duplicate of this bug: 673839
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

6 years ago
(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

6 years ago
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.

Updated

6 years ago
Duplicate of this bug: 695329

Updated

6 years ago
Duplicate of this bug: 695621
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.

Updated

6 years ago
Duplicate of this bug: 697853
Version: 7 Branch → Trunk
Duplicate of this bug: 720282
ok, so, is somebody working on this ?
5 duplicates, 10 votes, it seems to be a quite important bug.
Created attachment 610617 [details] [diff] [review]
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.
Attachment #610617 - Flags: feedback?(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.
Attachment #610617 - Flags: feedback?(dao) → feedback-
(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"?

Comment 26

5 years ago
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.

Comment 28

5 years ago
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.

Comment 32

5 years ago
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.)

Updated

5 years ago
Duplicate of this bug: 786260

Updated

5 years ago
Duplicate of this bug: 786268

Comment 35

5 years ago
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
Duplicate of this bug: 826453

Updated

5 years ago
Duplicate of this bug: 734662

Updated

4 years ago
Duplicate of this bug: 849574

Comment 39

4 years ago
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

2 years ago
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.
Flags: needinfo?(gijskruitbosch+bugs)

Comment 41

2 years ago
(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.
Flags: needinfo?(gijskruitbosch+bugs)

Comment 42

10 months ago
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>.
You need to log in before you can comment on or make changes to this bug.