User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.81 Safari/537.1 Build Identifier: Thunar 1.2.3 after http: is typed in the toolbar, thunar freezes for quite some time. Reproducible: Always Steps to Reproduce: 1.type http: in the toolbar (or https:) Actual Results: after the : is typed, thunar freezes I am on #!(crunchbang linux).
I can reproduce on Manjaro/ArchLinux with Thunar 1.4.0-2
Fixed in exo, commit d11199b.
This fix breaks uri scheme handling since it assumes a valid uri must contain a slash after a colon (In reply to comment #2) > Fixed in exo, commit d11199b.
(In reply to comment #3) > This fix breaks uri scheme handling since it assumes a valid uri must > contain a slash after a colon Maybe reopen a new bug and reference this one in it. Well, W3C writes the following. Notice that they say something about the *first* ":" character to be found. 3.1.1 Find the scheme To find the scheme, the user agent must use the following steps: If the remaining string does not contain a ":" character, the URL is invalid; abort these steps. Consume characters up to, but not including, the first ":" character. These characters are the scheme. Consume the ":" character. The remaining characters are the after-scheme. http://www.w3.org/TR/url/#find-the-scheme See also RFC 3986, Section 3: The following are two example URIs and their component parts: foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose http://tools.ietf.org/html/rfc3986#section-3
(In reply to comment #3) > This fix breaks uri scheme handling since it assumes a valid uri must > contain a slash after a colon > > (In reply to comment #2) > > Fixed in exo, commit d11199b. Indeed, perhaps: return (s[0] == ':' && s[1] != '\0'); This way "mailto:foo" would be valid, but "http:" wouldn't.
(In reply to comment #5) ... > Indeed, perhaps: return (s[0] == ':' && s[1] != '\0'); > > This way "mailto:foo" would be valid, but "http:" wouldn't. No, this would be wrong. Please read my comment #4 about the W3C standardization and the RFC. After the colon, there have to be two slashes ("<scheme>://") to indicate a correct scheme (the protocol). Besides that, a colon can also be used to separate a special port from the server host name. So, more valid would be maybe: return (s[0] == ':' && s[1] == '/' && s[2] == '/' && s[3] != 0 ); I doubt that Thunar wants to support mailto: URI in the location bar. Mails can't be browsed like or as file systems. :) See also special RFC http://tools.ietf.org/html/rfc2368
RegEx: ^(http|https|ftp)\://([a-zA-Z0-9\.\-]+(\:[a-zA-Z0-9\.&%\$\-]+)*@)*((25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9])\.(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|0)\.(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|0)\.(25[0-5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[0-9])|localhost|([a-zA-Z0-9\-]+\.)*[a-zA-Z0-9\-]+\.(com|edu|gov|int|mil|net|org|biz|arpa|info|name|pro|aero|coop|museum|[a-zA-Z]{2}))(\:[0-9]+)*(/($|[a-zA-Z0-9\.\,\?\'\\\+&%\$#\=~_\-]+))*$ from
(In reply to comment #6) > (In reply to comment #5) > ... > > Indeed, perhaps: return (s[0] == ':' && s[1] != '\0'); > > > > This way "mailto:foo" would be valid, but "http:" wouldn't. > > No, this would be wrong. Please read my comment #4 about the W3C > standardization and the RFC. > After the colon, there have to be two slashes ("<scheme>://") to indicate a > correct scheme (the protocol). Wrong. The W3C standarization is for *URLs* not *URIs*, as the RFC clearly states, a URI without two slashes is a non-hierarchical URI, and as you described in comment #4, is even listed as an example: urn:example:animal:ferret:nose > Besides that, a colon can also be used to > separate a special port from the server host name. So, more valid would be > maybe: > > return (s[0] == ':' && s[1] == '/' && s[2] == '/' && s[3] != 0 ); > > I doubt that Thunar wants to support mailto: URI in the location bar. Mails > can't be browsed like or as file systems. :) Who cares what Thunar wants to support? exo_str_looks_like_an_uri() is used by more clients than Thunar. See bug #9597.
(In reply to comment #7) > RegEx: > > ^(http|https|ftp)\://([a-zA-Z0-9\.\-]+(\:[a-zA-Z0-9\.&%\$\-]+)*@)*((25[0- > 5]|2[0-4][0-9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9])\.(25[0-5]|2[0-4][0- > 9]|[0-1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|0)\.(25[0-5]|2[0-4][0-9]|[0- > 1]{1}[0-9]{2}|[1-9]{1}[0-9]{1}|[1-9]|0)\.(25[0-5]|2[0-4][0-9]|[0-1]{1}[0- > 9]{2}|[1-9]{1}[0-9]{1}|[0-9])|localhost|([a-zA-Z0-9\-]+\.)*[a-zA-Z0-9\-]+\. > (com|edu|gov|int|mil|net|org|biz|arpa|info|name|pro|aero|coop|museum|[a-zA- > Z]{2}))(\:[0-9]+)*(/($|[a-zA-Z0-9\.\,\?\'\\\+&%\$#\=~_\-]+))*$ The function is called exo_str_looks_like_an_uri(), not exo_str_is_definitely_a_valid_url().
(In reply to comment #6) > return (s[0] == ':' && s[1] == '/' && s[2] == '/' && s[3] != 0 ); Moreover, that would crash with "http:".
(In reply to comment #9) ... > The function is called exo_str_looks_like_an_uri(), not > exo_str_is_definitely_a_valid_url(). $ exo-open --launch MailReader $ xdg-open mailto:foo?subject=bar But yeah, mailto: should not be broken, it's documented as a feature. Sorry for posting non-sense. http://manpages.ubuntu.com/manpages/hardy/man1/exo-open.1.html http://manpages.ubuntu.com/manpages/lucid/man1/xdg-open.1.html COMPOSING EMAILS exo-open allows users and developers to open the preferred email composer from the command line by simply invoking exo-open mailto:USER@HOST.TLD. This will open the composer window with USER@HOST.TLD as the recipient. This syntax is supported by all MailReaders. In addition the MailReaders that ship as part of libexo also support extended mailto:-URIs (but be aware that user-defined mailers do not necessarily support this), which allows you to also specify default values for the subject and the body of the mail, add additional recipients (both Cc: and To:) and attach files to emails. For example mailto:foo@foo.org?cc=bar@bar.org&subject=Foo&attach=/foo/bar.txt tells the composer to start an email to foo@foo.org and bar@bar.org with Foo in the subject and the file /foo/bar.txt attached to the message.
(In reply to comment #5) > (In reply to comment #3) > > This fix breaks uri scheme handling since it assumes a valid uri must > > contain a slash after a colon > > > > (In reply to comment #2) > > > Fixed in exo, commit d11199b. > > Indeed, perhaps: return (s[0] == ':' && s[1] != '\0'); > > This way "mailto:foo" would be valid, but "http:" wouldn't. I've tested this fix, and as expected works perfectly fine. Here's the patch bug #10098.