326034 - Gopher: add preference for mozTXTToHTMLConv

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect)

Description

[Cameron Kaiser [:spectre]]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060203 Camino/1.0rc1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060203 Camino/1.0rc1

The text (itemtype 0) handler for Gopher shouldn't try to interpret text as URLs, particularly because ASCII art is prevalent in the Gopher community, and also because it usually guesses wrong for URLs embedded in paragraphs anyway. It tends to be more of a hindrance than a help.

For example, the script here generates a "phases of the moon" image studded with mailto's if there are any @'s in it.

Reproducible: Always

Steps to Reproduce:
(as above)

Actual Results:  
(as above)

Expected Results:  
No links should be made.

Rather than increase the complexity of the gopher text handler to accomodate weirder cases, I submit it should not be trying to parse itemtype 0 for URLs in the first place. Leave that for itemtype h if people really want it.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

> Rather than increase the complexity of the gopher text handler

Note that the code in question is not gopher specific. It is also used, for example, by mailnews.

Comment 2

[Aaron J. Angel]

Maybe at least make it a configuration option.

Comment 3

[Cameron Kaiser [:spectre]]

I would be fine with that as a compromise.

I note this is still UNCONFIRMED -- anyone else observing the behaviour?

Comment 4

[Aaron J. Angel]

Yes.  Still happens in 2.0.

Comment 5

[Cameron Kaiser [:spectre]]

Followup on this; look at

gopher://gopher.floodgap.com/0/feeds/tidbits/2007/Mar/5/1

Here, the URL interpreter is taking everything between < >, *including* the < >. (Ironically, it acts correctly for the URL at the top.)

I'm not sure if this is more appropriate to complain about here, or in bug 39042, which seems to be the only other bugrep of significance related to this.

Comment 6

[benc]

-> NEW. 

This behavior is rooted in the original implementation (probably a de facto design decision).

I'd be interested getting a comment from anyone working on the add-on/javascript implementation, if they can fix this.

I suggest creating a pref called:

network.gopher.mozTXTToHTMLConv

...okay, maybe someone could come up with a pref label that improves on the idea.

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

we're not adding more prefs to gopher!