[Bug 448044] Problem with apostrophe in URL

gnome-terminal (GNOME Bugzilla) bugzilla at gnome.org
Sun Dec 17 23:37:21 UTC 2017


https://bugzilla.gnome.org/show_bug.cgi?id=448044

Egmont Koblinger <egmont at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egmont at gmail.com

--- Comment #6 from Egmont Koblinger <egmont at gmail.com> ---
Apostrophes are not uncommon at the end of URLs either, e.g.
  https://en.wikipedia.org/wiki/Cryin'

In Chromium, go to wikipedia.org, type Cryin' and press Enter. The URL bar will
show Cryin%27 and it copy-pastes accordingly. Go again to wikipedia.org and
type again Cryin' and this time choose the first autocomplete dropdown with the
mouse. The URL bar will say Cryin' and it'll copy-paste accordingly as
apostrophe. (You're taken to the same page. I haven't compared the HTTP
traffic.)

In Firefox, the URL bar shows an apostrophe but the address copy-pastes as %27.
That is as long as you don't tamper with the URL bar. Retype any part of the
URL (either the apostrophe or an irrelevant segment) and from then on it's an
apostrophe. Then try to undo it: remove the apostrophe from the URL and start
typing %27, as soon as you press % it recognizes it has the apostrophe-version
in its history and replaces the % by that ' so you cannot type %27.

Double quotes seem to always get copy-pasted from browsers' URL bar as %22, so
hopefully we don't need to worry about them. Wikipedia doesn't like it either,
e.g. 12" redirects to 12-inch_single, etc.

Well, I was copying the entire URL in all these examples. Copying a part of
them behaves differently, then it's the visible string that's copied.

Such a freaking mess... I'm cryin'...

Anyway, our takeaway is that we should probably add support for apostrophes
(and probably double quotes aren't needed).

In the mean time, it's essential for URLs within single quotes, e.g.
'http://example.com' not to grab the trailing apostrophe.

The balanced pair approach (bug 763980) obviously cannot work.

I can see two possible approaches:

- Have a branch at the outmost level, pretty much duplicating the entire big
regex. One variant that doesn't allow embedded apostrophes, OR another variant
that allows, but begins with a lookbehind that there isn't an apostrophe.

- Regex conditionals, http://www.rexegg.com/regex-conditionals.html. At the
beginning "define a variable" containing whether there's a preceding apostrophe
(a named capture group doing lookbehind, or something like that) and then based
on this variable do inner small local branches to allow/forbid apostrophes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20171217/934edfdb/attachment-0001.html>


More information about the pkg-gnome-maintainers mailing list